Re: [netmod] Module updates in imported modules

[Andy Bierman <[e-mail]>]

On Tue, Jun 13, 2023 at 8:48 AM Jason Sterne (Nokia) <[e-mail]>
wrote:

> Hi Andy,
>
>
>
> From my read of 7950, adding a mandatory leaf to a grouping isn’t allowed.
> Section 11 lists every case of allowable changes. Can you point out what
> statement(s) you feel allow it?
>





   The "grouping" statement is not a data definition statement and, as
   such, does not define any nodes in the schema tree.



IMO the constraints in sec 11. apply to the schema tree (i.e., uses
expansion) but the text is not clear about that.
E.g., many constraints are ignored within an sx:structure. The context of
the uses-stmt matters.

The same grouping can be used for the first time in 1 module and not be an
update,
so the mandatory node rule does not apply.

So incrementing the grouping module major-version if any possible uses
expansion leads to NBC changes is required.



>
> If there is some ambiguity about that in RFC7950 personally I think any
> clarification would be to make it not-allowed (aka NBC). The module A that
> defines a grouping (or a typedef, or the name of a choice, etc, etc)
> doesn’t know how other modules will import module A, or augment module A.
>
>
>
> So a client/app (or developer of that client/app) that uses modules A, B
> and C in your original example would “trigger” on the fact that module A
> had an NBC change. The developers would then examine the changes to A and
> determine how those impact them (by seeing where that grouping is used,
> whether the client uses those nodes, etc).
>

Perhaps an example showing an NBC change to an imported module should be
added.


>
> Jason
>

Andy


>
>
> *From:* netmod <[e-mail]> *On Behalf Of *Andy Bierman
> *Sent:* Friday, June 9, 2023 2:30 PM
> *To:* Jan Lindblad <[e-mail]>
> *Cc:* NetMod WG <[e-mail]>
> *Subject:* Re: [netmod] Module updates in imported modules
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
>
>
>
>
> On Fri, Jun 9, 2023 at 1:23 AM Jan Lindblad <[e-mail]> wrote:
>
> 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.
>
>
>
>
>
> I think this text applies to schema nodes (i.e., uses expansion, not
> groupings).
>
> Adding a mandatory leaf to a grouping is allowed.
>
>
>
> The NBC change occurs here because it is an augment using a mandatory
> NP-container.
>
> The same "uses" in a P-container or a list is not an NBC change.
>
>
>
> My point is that none of the protections in these drafts work because the
> module
>
> with the "uses" is not the module being changed.  Even when A(2.0.0) is
> used by a server,
>
> none of the protections work because module C never gets updated, just A.
>
>
>
>
>
> 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.
>
>
>
>
>
> The SID file for module C is created and uses A(1.1.0).
>
> Over time new revisions of A are published.
>
> A server can choose any revision of A in its implementation.
>
> A client hardwired to expect A(1.1.0) could still work with A(1.2.0).
>
> The node 'three' would be encoded as text and not a SID.
>
> A client hardwired to expect A(1.1.0) may not still work with A(2.0.0).
>
> The node 'two' would be encoded as a number and not a string anymore.
>
> However, this exact situation can occur if the server uses a deviation to
> replace the type for leaf 'two'.
>
>
>
> Every time a new revision of any imported module gets updated, a new SID
> file may be needed.
>
> E.g: 3 revisions of C.sid:
>
>
>
>  - module C using A(1.1.0)  == [default sid-file-version=0]
>
>  - module C using A(1.2.0)  == sid-file-version=1
>
>  - module C using A(2.0.0)  == sid-file-version=2
>
>
>
> It is valid for a server to use any 1 of the 3 revisions of module A.
>
> Of course, this is a "hello world" example. A "real world" example will be
> much more complicated.
>
> Allowing NBC changes to YANG makes the problem more complicated as well.
>
>
>
>
>
> Best Regards,
>
> /jan
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On 8 Jun 2023, at 21:18, Andy Bierman <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
>