[yang-tooling] Re: SID file issues / .sid file differences in pyang and core-wg/pyang

[Andy Bierman <[e-mail]>]

On Wed, Feb 4, 2026 at 6:28 AM Carsten Bormann <[e-mail]> wrote:

> On 2026-02-04, at 15:13, Esko Dijk <[e-mail]> wrote:
> >
> > Hi Carsten,
> >
> > I thought "YANG item" is defined in RFC 9254 Section 2:
> >
> > item:
> >     A schema node, an identity, a module, or a feature defined using the
> YANG modeling language.
> >
> > So this would include the choice/case schema nodes.
>
> Yes.
>
> > Or is there a difference between "YANG item" and "item" ? -- in which
> case I'm officially lost. Interestingly RFC 7950 doesn't define "YANG item"
> but still uses the term.
>
> They use it in the English sense for “things an identifier identifies” in
> Section 6.2/6.2.1.
>
> > If it was not intended to assign a SID to each "item", but rather only
> to a subset of items i.e. the ones listed in Section 3.2 of RFC 9254, I can
> understand that.
>
> Right.  Where do we need those SIDs?
> I think Andy has pointed out there are usages of schema node identifiers
> that we didn’t consider.
> I think that is a valid observation.
> One aspect of YANG that didn’t receive a lot of attention during the
> definition of YANG-CBOR was “augment”.
> While this is less important for many constrained applications, we sure
> want to support that.
>
> I’m not clear whether we need RFC 9254 Section 3.3 "YANG item identifiers
> implemented using names” here, which are the ones paired with SIDs in
> “.sid” files.
>
>

The name is just a local-name. It has the same context issues as XML and
JSON.
A SID is a mapping from a number to an absolute-path-string.

e.g

106 == /example-box:box/a_choice/case_b/b   NOT 'b'

So anyplace a SID is needed, a path string could be used instead. (Current
situation).




> > If we assign to all "items" then we get quite some SID values that
> aren't used in practice, in an actual data tree serialization in CBOR. This
> sounds less useful for a majority of use cases.
> >


It appears skipping choice/case is intentional in the RFC design,
although it is not clear.  During review, I assumed the usage of YANG ABNF
meant that all the
schema nodes included by that ABNF are supposed to get SIDs.

Somebody looking at the RFC 9595 examples and not the YANG RFC would assume
that these
schema nodes are skipped.

IMO it would be better to give these nodes SID assignments but not critical
if they are skipped.



> > If we assume that SIDs only assigned to a subset of items is the
> intention of RFC 9595, this this text and maybe 9254 would need fixing I
> believe.
>
> The intention was for an automatic tool to hit all useful "YANG item
> identifiers implemented using names”.
> We might or might not be extending our understanding of this set right now…
>
>
I was hoping independent tools would come up with the
same SID assignments given the same set of input files.

Manual SID management is not a good solution for YANG Push.
Automatic generation of completed (stable) YANG modules is far more
important.

Andy

A manually parameterized tool might do something different, but so far we
> didn’t have a need for that (except for supplying a list of previous
> assignments to be reused during evolution).
>
> > Can you confirm that YANG item is the same as "item" in RFC 9254, or
> otherwise give some hints about their (intended) difference?
>
> I think we are using “item” occasionally in place of “YANG item" to reduce
> tedium, and of course in “CBOR data item”.
> So I think we should be careful to say “YANG item” when we mean that.
> I think the definition in Section 2 focuses on saying there are other
> items than those whose names we use to build instance identifiers.
> The most useful/important definition of "YANG item identifiers implemented
> using names” is in 6.13.2; we'll want to make sure we don’t break this (cf.
> 6.13.1):
>
>    CBOR diagnostic notation: [1734, "bob", "admin", "france”]
>
> Grüße, Carsten
>
>