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

[Andy Bierman <[e-mail]>]

On Fri, Feb 13, 2026 at 2:56 AM Michael Richardson <[e-mail]>
wrote:

>
> Vojtech Vilimek <[e-mail]> wrote:
>     mcr> beginning of the range could go to the end.  I suggest (you)
> write an
>     mcr> I-D updating RFC9595 to suggest this BCP.  I don't propose we
> publish
>     mcr> it, but rather keep it around for RFC9595bis and/or RFC9254bis,
> which
>     mcr> I think we might decide we ought to do in a year or so.
>
>     > I understood the consensus from the interim to be _NO_ SIDs for
>     > choice/case at all, as they never occur in instance data anyway.
>
> Yes, but if someone wants NIDs, then we might want to assign them from the
> end of the range.  And you pointed out that we assign a bunch of SIDs
> from the beginning of the range for a few book-keeping purposes.
> For instance:
>       {
>         "namespace": "module",
>         "identifier": "ietf-voucher",
>         "sid": "2450"
>       },
>       {
>         "namespace": "data",
>         "identifier": "/ietf-voucher:voucher",
>         "sid": "2451"
>       },
>
>

Yikes.

The algorithm in RFC 9595 is simple and robust.
Also, either choice/case is always encoded or never encoded.
There are no user options for adding choice/case back.
Since the path string omits these nodes, it is impossible to list them in a
SID dile anyway.



> (from rfc8366bis, ietf-voucher)
>
> The first one is the module entry point.  It needs to be the first item as
> it
> gets the range value, and subsequent entries delta against it.
> The second one... I'm not even quite sure what it is.  It's for the
> grouping
> maybe?   It could go at the end of the range.
>
>
The module name is not always first.
Try generating a SID file with pyang of ietf-snmp.yang in the 'yang' repo.

In this example, the main module is only first because the list is in
alphabetical order.
This seems correct.  pyang does not follow the include-stmt order, since
this can change.

    "item": [
      {
        "namespace": "module",
        "identifier": "ietf-snmp",
        "sid": "1000"
      },
      {
        "namespace": "module",
        "identifier": "ietf-snmp-common",
        "sid": "1001"
      },
      {
        "namespace": "module",
        "identifier": "ietf-snmp-community",
        "sid": "1002"
      },
      {
        "namespace": "module",
        "identifier": "ietf-snmp-engine",
        "sid": "1003"
      },
      {
        "namespace": "module",
        "identifier": "ietf-snmp-notification",
        "sid": "1004"
      },
      {
        "namespace": "module",
        "identifier": "ietf-snmp-proxy",
        "sid": "1005"
      },
      {
        "namespace": "module",
        "identifier": "ietf-snmp-ssh",
        "sid": "1006"
      },
      {
        "namespace": "module",
        "identifier": "ietf-snmp-target",
        "sid": "1007"
      },
      {
        "namespace": "module",
        "identifier": "ietf-snmp-tls",
        "sid": "1008"
      },
      {
        "namespace": "module",
        "identifier": "ietf-snmp-tsm",
        "sid": "1009"
      },
       .......



There is a bug inpyang that needs to be fixed.

     {
        "namespace": "data",
        "identifier":
"/ietf-snmp-common:snmp/ietf-snmp-vacm:vacm/view/name",
        "sid": "1187"
      }

There is no such thing as a submodule namespace, but thanks for
highlighting why
I fought to keep them out in YANG in 2005.

There is only the ietf-snmp module namespace, not the ietf-snmp-common
namespace
augmented by the ietf-snmp-vacm namespace.

The biggest problem with SIDs is related to the fact that YANG does not
mandate the use of
specific imported modules, but SID does, because the expansion is done at
publish-time.


Carsten and Andy point out that the allocation rules would ideally be
> deterministic, so that one might not need the .sid file.  I understand
> why one retrieves YANG modules and SID files from the target device,
> because
> an orchestrator/*CONF manager doesn't know which version of the model the
> device is using.  I feel like it ought to just be a semver number, and the
> rest should come from the manufacturer, but that won't work ... at least
> not yet.
>
>
YANG is explicitly unordered in several ways, especially groupings,
augments, and submodules.
The ietf-snmp module has all 3, including submodules augmenting each other.

    > The
>     > old behavior of the PYANG is considered wrong and needs to be
> rewritten
>     > together with the new erratum/draft-rfc9595bis.
>
>



> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>
>

Andy


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