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?
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). Jason From: netmod <netmod-boun...@ietf.org> On Behalf Of Andy Bierman Sent: Friday, June 9, 2023 2:30 PM To: Jan Lindblad <j...@tail-f.com> Cc: NetMod WG <netmod@ietf.org> 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 <j...@tail-f.com<mailto:j...@tail-f.com>> 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 <a...@yumaworks.com<mailto: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<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
