hello FEATURE advertise YANG 1.1 modules in NETCONF capabilities#587
Closed
vjardin wants to merge 2 commits intoCESNET:develfrom
Closed
hello FEATURE advertise YANG 1.1 modules in NETCONF capabilities#587vjardin wants to merge 2 commits intoCESNET:develfrom
vjardin wants to merge 2 commits intoCESNET:develfrom
Conversation
The libyang v4 migration (5ab029a) simplified the YANG version filter in _nc_server_get_cpblts_version() from two separate checks to a single "mod->version != version" comparison. This broke the LYS_VERSION_UNDEF (0) case: since all parsed modules have version 1 or 2, the condition (1 != 0) is always true and every module is skipped. As a result, nc_server_get_cpblts() -- which passes LYS_VERSION_UNDEF to mean "all versions" -- returns only base protocol capabilities with zero model capabilities. Guard the check with "version &&" so that LYS_VERSION_UNDEF disables filtering, restoring the pre-5ab029a behavior. Signed-off-by: Vincent Jardin <vjardin@free.fr> Fix: 5ab029a (lib UPDATE move to libyang v4)
nc_send_hello_io() hardcoded LYS_VERSION_1_0 when generating server capabilities, so only YANG 1.0 modules appeared in the <hello> message. YANG 1.1 modules -- the majority of modern YANG models -- were invisible to clients inspecting capabilities. RFC 7950 section 5.6.4 requires that YANG 1.1 modules be discoverable via ietf-yang-library, but does not prohibit listing them in <hello>. In practice, clients commonly rely on hello capabilities to determine server support. Use LYS_VERSION_UNDEF so that all implemented modules are advertised regardless of YANG version. Signed-off-by: Vincent Jardin <vjardin@free.fr>
Author
Contributor
|
This is actually in the introduction of RFC7950 (emphasis mine):
That's a standard from 2016. I wonder -- what client fails to implement this YANG 1.1 semantics and still supports the YANG 1.1 features of the models? |
Author
|
good point ! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix
nc_server_get_cpblts()regression from the libyang v4 migration (5ab029a): the simplified version filtermod->version != versionbrokeLYS_VERSION_UNDEF(0), causing zero model capabilities to be returned. Guard with version && to restore the "all versions" semantics.Additionally, change
nc_send_hello_io()from LYS_VERSION_1_0 to LYS_VERSION_UNDEF so that YANG 1.1 modules -- the majority of modern YANG models -- are advertised in the server capabilities alongside YANG 1.0 ones.RFC 7950 section 5.6.4 requires YANG 1.1 modules be discoverable via ietf-yang-library but does not prohibit listing them in
<hello>. In practice, clients commonly rely on hello capabilities to determine server support.Tested with netopeer2
test_hello(new test) verifying both YANG 1.0 (edit1.yang) and YANG 1.1 (notif2.yang) modules appear in session capabilities.