[core] Re: CoRE WG Virtual Interim 2026-04-22 RFC9595 Errata implementation

[Andy Bierman <[e-mail]>]

On Mon, May 4, 2026 at 4:05 PM Vojtech Vilimek <[e-mail]>
wrote:

> Hi Andy, Michael, Carsten and all,
>
> On 4/30/26 7:56 PM, Andy Bierman wrote:
> >
> >
> > On Thu, Apr 30, 2026 at 10:41 AM Michael Richardson
> > <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >
> >     Esko Dijk <[e-mail]
> >     <mailto:[e-mail]>> wrote:
> >          > So in this case the prior single leaf was an optional item?
> >
> >     I have to think about whether, in a prior case, that leaf had to be
> >     optional.
> >     I guess if it goes from required->optional (make a choice), that
> >     would be a
> >     semantic change.
> >
> >          > Then it
> >          > seems like the optimal solution to keep the SID for that
> >     leaf, and
> >          > assign new SIDs for the new leaves. If the single leaf is
> >     deprecated in
> >          > a new version of the YANG module, then a 'new single leaf'
> >     will be
> >          > added that gets a new SID.
> >
> >     One could also go from a choice to a single leaf.
> >     That effectively obsoleting all the other choices, but at some
> >     point, one
> >     might want to clean up the YANG.  I don't know if choice with a
> >     single choice
> >     is rejected somewhere as nonsense.
> >
> >          > Whether the specs and the tooling also say this is another
> >     question - I
> >          > didn't investigate :)
> >
> >
> >
> > I don't see why this NBC change is special.
>
> Because the only change might be that the node previously was not in
> choice+case but in the updated revision it is.
>
> To make the discussion easier, let us consider an example:
>
>    container box {
>      leaf a { type uint32; }
>    }
>
> The change to following is not permitted by current YANG:
>
>    container box {
>      choice extensible-exclusivity {
>        case case-a {
>          leaf a { type uint32; }
>        }
>        case case-b {
>          leaf b { type string; }
>        }
>        // possibly more cases augmented by other modules
>      }
>    }
>
> Note that all leafs that does not have "mandatory true;" are optional.
>
> If I understand the YANG rules correctly, change between examples is not
> possible, partly because the leaf on schema path "/mod:box/a" is lost
> from the YANG module. The mentioned leaf must be removed because the
> names of the case's children are imported into the choice's parent
> namespace.
>
>
Changing the schema path string from /box/a to
/box/extensible-exclusivity/case-a/a
breaks any modules that used /box/a in an augment or deviation statement.
It is an NBC change in YANG.

It is true that the leafref and SID path string (/box/a) did not change.
IMO not an interesting cornercase.

What if the updated YANG changed from a leaf to a container?

    container box {
       container a;
    }

Just another NBC change. All path strings (and SID assignments) remain the
same.

>From an operational POV, clients need to be YANG aware (by whatever means)
to align with the server YANG library contents.


Andy

I don't think this is NBC from the functionality point of view. If only
> the client is aware of the newer revision, then client MUST send valid
> messages. Client message containing leaf "b" is rejected because it is
> not understood by the server. If only the server is aware if the newer
> revision, everything works because client never sends both leaf "a" and
> "b" instantiated in the same message.
>
> Micheal: The example is simplistic. Does this show what you are asking
> about?
>
> All: Do you agree?
>
> > While the sid-file-status is 'unpublished', a tool should expect NBC
> > changes in the YANG modules.
> > For 'published' modules, NBC changes are not allowed, but they still
> > occur occasionally.
>
> So we declare stability we couldn't provide, great. What is the whole
> effort for then? (Feel free to understand the question as of rhetorical
> nature.)
>
> >
> > IMO the SID should be tied to the path string, even if that node changes
> > semantics over time.
> > It is up to the YANG designer to create a new node/path and obsolete the
> > old path.
>
> What path do you mean? Absolute schema path? (Absolute) Data path?
> String representation of NID?
>
> Based on WG discussions, we converged to the .sid file defining
> (ideally) a mapping from SID to NID.
>
> Carsten: Could you please provide a (more) formal definition of NID?
> We discussed this matter on the interim but if we define the NID as
> the instance data path without predicates, there are corner cases that
> do not work.
>
> Such as:
>    rpc time-compare-and-swap {
>      input {
>        leaf expected { type yang:date-and-time; }
>        leaf operand { type yang:date-and-time; }
>      }
>      output {
>        leaf operand { type yang:date-and-time; }
>      }
>    }
>
>    container box {
>      container a { container b {
>        action bound {
>          input {
>            leaf in { type uint32; }
>          }
>          output {
>            leaf result { type string; }
>          }
>        }
>      } }
>    }
>
> What is the NID for following schema paths:
>    - time-compare-and-swap/input/operand
>    - time-compare-and-swap/output/operand
>    - time-compare-and-swap/input
>    - time-compare-and-swap/input
>    - box/a/b/bound/input/in
>    - box/a/b/bound/output/result
>    - box/a/b/bound/input
>    - box/a/b/bound/output
>
> Because the input and output nodes are not really a part of the instance
> paths. Actions have more complex paths. It is dependent on the data
> format used, but generally the rpcs and actions are sent as:
> context + children of input, or context + children of output.
> E.g. CORECONF differentiate inputs from outputs by type of the message
> (request vs. response).
>
>
> Have a nice day!
>
> Best regards,
> Vojtech Vilimek
> CZ.NIC z.s.p.o.
>
> >
> >
> > Andy
> >
> >
> >
> >          > On 4/28/26 21:34, Michael Richardson wrote:
> >          >> Thank you for working on this.  For me, the still outstanding
> >          >> question,*AT THE YANG LEVEL* is when introducing a choice,
> where
> >          >> previously there was only a single leaf, *AND* the single
> >     leaf is now
> >          >> one of the choices... is that a*semantic* change that SHOULD
> >     result in
> >          >> a new SID being allocated?
> >          >>
> >          >> I'd like to say*no*, as doing so is an unnecessary breaking
> >     change.
> >          >> Tooling didn't agree a few months (years?) ago, so we backed
> >     out the
> >          >> choices from RFC8366bis, even though they made semantic
> sense.
> >          >>
> >          >> I'd like to change that.
> >
> >     --
> >     Michael Richardson <[e-mail]
> >     <mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )
> >                 Sandelman Software Works Inc, Ottawa and Worldwide
> >
> >     **       My working hours and your working hours may be different.
> >             **
> >     ** Please do not feel obligated to reply outside your normal working
> >     hours **
> >
>