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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
