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

Reply via email to