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

[Andy Bierman <[e-mail]>]

On Thu, Feb 12, 2026 at 7:57 AM Esko Dijk <[e-mail]>
wrote:

>
> On 2/12/26 16:33, Andy Bierman wrote:
>
>
> On Thu, Feb 12, 2026 at 3:53 AM Michael Richardson <[e-mail]>
> wrote:
>
>>
>> A reason why I think we need a bit more than just an errata is because I
>> don't really understand the CORECONF use cases that would require
>> SIDs/NIDs
>> for choice nodes.  That's likely because I haven't written an
>> orchestrator.
>>
>>
> I don't know if there any use cases for CORECONF.
>
>
> Prior to the CoRE interim call, we talked I think about situations where a
> client would like to query for / filter on all items that exist in a
> sub-branch of the 'schema tree', with reference to e.g. a choice or case
> node. I haven't seen a practical example of this yet.
>
> Something that the non-constrained protocols do allow in certain
> situations. Whether CORECONF has a practical use case for it, and whether
> the constrained device would be able to parse such a complex request, I
> don't know. Maybe its CORECONF server can just send 5.00 and be rid of it
> :-)
>
> In the interim call it was mentioned that such use cases are still
> possible,  using the full string to encode the query/filter. So, a SID as a
> shorthand name would not be available for this use case because it's not
> assigned to case/choice nodes.
> What we aim for is that for a vast majority of constrained use cases the
> message sizes are nice and small; and SID deltas stay small for the vast
> majority of use cases.
>
>
>
> Either the example that shows no choice/case nodes is wrong, or the text
> that says
> every schema item has an entry is wrong.
>
> The CoRE interim plan is to adapt the text to what was intended and shown
> in the example (Appendix A of 9595).
> There was some discussions whether errata are sufficient, or whether a new
> draft is needed. (Current assumption is errata - we try that first.)
>


OK -- this is a big change to the code since the 'old' SID files are not
compatible with 'new' tools.

IMO, this is a trade-off that favors the intended use case.
All the schema items supported in RFC 9595 are used in existing management
protocols.
The choice and case nodes are not present in any XML or JSON
representations used
in NETCONF or RESTCONF.  (Except maybe proprietary filters).

The NETCONF WG is adopting a draft to use it in RESTCONF.
There is also UDP-Notif, which supports XML, JSON, and CBOR for
notification messages only.
The SID file format needs to be stable to support these standard protocols.



> Esko
>


Andy