Hi, It is not clear how the new drafts work for changes in imported groupings. This is a very common design pattern.
module A { // version 1.0.0 grouping A { leaf one { type string; } leaf two { type string; } } } module A { // version 1.1.0 grouping A { leaf one { type string; } leaf two { type string; } leaf three { type string; mandatory true; } } } module B { container top; } module C { import A { prefix A; } import B { prefix B; } augment "/B:top" { container C { uses A:A; } } } In this example, the server starts out with module A(1.0.0). Modules B and C are some versions (doesn't matter). In a new server release, ONLY module A has been updated to 1.1.0. This is a BC change to the grouping so no major version update. Modules B and C are byte-exact and not changed at all. However now there is an NBC change caused by module C from a BC change in module A. (augment a mandatory node) module A { // version 2.0.0 grouping A { leaf one { type string; } leaf two { type uint32; } leaf three { type string; mandatory true; } } } Even if there is an NBC change to a grouping module, it is only apparent from compiling a specific YANG library, not from the individual modules. There is only an NBC change if the server chooses A(2.0.0). (out of scope here) Since module C never changed, the SID file for module C may not be changed, especially if module A is a standard module. If A(1.1.0) or (2.0.0) is used by the server then the SID for /top/C/three is missing. The module update draft should mention NBC issues from groupings. Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod