On Fri, Jun 9, 2023 at 1:23 AM Jan Lindblad <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> 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
