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

[Michael Richardson <[e-mail]>]

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"
      },

(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.

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.

    > 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*