Andy,
I think you have a lot of good points in this discussion, but here is one I
don't quite understand.
You state that the addition of leaf three in the 1.1.0 version of grouping A
would be BC. 7950 sec 11 lists things you are allowed to do and still call your
module BC. By which rule in section 11 would you argue that the 1.1.0 change is
BC? To me, this addition of a mandatory leaf in an existing grouping, appear
not to be covered in any of the BC cases. It also breaks the architectural idea
expressed in the first paragraph of sec 11:
[...] changes to published modules are not allowed
if they have any potential to cause interoperability problems between
a client using an original specification and a server using an
updated specification.
Also, if your comment about SIDs not being updated as imported modules change
is true, that is indeed a major problem for the SID generation.
Best Regards,
/jan
> On 8 Jun 2023, at 21:18, Andy Bierman <a...@yumaworks.com> wrote:
>
> 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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
