[yang-tooling] Re: SID file issues

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Carsten,

It appears that my previous email added further confusion rather than clarity.  I'll try again ;-)

Sorry, but my email wasn't clear.  I still read RFC 9254 and RFC 9595 as effectively assigning SIDs to data node paths in the data tree (rather than paths to data items in the schema tree) and a few other things that are helpful to identify.  I.e., I have always thought that they are logically directly equivalent to what is being encoded when using CBOR with named identifiers (also equivalent to JSON/XML naming of path elements).

The RFCs and terminology in those documents are probably not as clear as could be (and I agree that the base terminology that you are reference and trying to build from is confusing), but I think that the examples in RFC 9595 are correct, at least to my reading.

For me the real question is that by not assigning some nodes to items in the schema tree whether we are preventing some useful use cases - Andy has given a list of some use cases where it is helpful/necessary to have SIDs assigned to other nodes in the schema tree.

One option could be:

  *
Bis RFC 9595 to also assign SIDs to items in the schema tree.  Point out that some SIDs (e.g., below a choice/case) effectively represent two paths, one in the schema tree and the equivalent condensed path in the data tree.
  *
Folks that don't need to care about SIDs for choice/case can just ignore them (perhaps there is some very slight negative memory/performance impact).

Kind regards,
Rob


From: Carsten Bormann <[e-mail]>
Date: Tuesday, 3 February 2026 at 17:27
To: Rob Wilton (rwilton) <rwilton=[e-mail]>
Cc: Andy Bierman <[e-mail]>, Michael Richardson <[e-mail]>, [e-mail] <[e-mail]>
Subject: [yang-tooling] Re: SID file issues

On 2026-02-03, at 17:21, Rob Wilton (rwilton) <rwilton=[e-mail]> wrote:
>
> FWIW, and putting aside the slightly confusing name for SID, I read RFC 9595 as giving SIDs out to data nodes rather than YANG schema nodes + few extra useful things, i.e., the things as per:

Thank you for chiming in.

The list you give includes data nodes, and a few extra useful things, so I’m not quite sure what the above sentence is trying to say.

One aspect that confused us a lot is that a data node is not a node in the data tree, but a schema node that happens to be about data (RFC 7950).
So any way to identify a data node is a way to identify (some) schema nodes.

We have instance identifiers to identify "a particular node in a data tree” (RFC 7950), identifying a “data tree node” (this term is used in RFC 7950 only in an overview table given in Section 4.2.4 for Section 9.

RFC 9254 also defines a superset "representation node" as:
      A node in a representation tree, i.e., a data tree node, or a
      representation of a schema node, such as a YANG data structure, a
      notification, an RPC, or an action.

SIDs are not instance identifiers, because you have to complement SIDs with list keys to obtain an instance identifier.

SIDs are unsigned integers that stand for text strings, which are defined as “name-based keys” (in the sense of a CBOR map key, not a YANG list key).
We need to understand those name-based keys to understand SIDs.

OK, I think I have thrown enough terms on the table...

Grüße, Carsten

_______________________________________________
yang-tooling mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]