Subject: [yang-tooling] Re: Issues with IANA YANG SID registry
From: Andy Bierman <[email-masked]>
To: Carsten Bormann <[email-masked]>
Cc: Vojtech Vilimek <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 21 May 2026 12:44:02 -0700
List-Id: "Contributing to and tracking the progress of YANG tooling, as it concerns IETF work that uses YANG." <yang-tooling.ietf.org>

On Thu, May 21, 2026 at 11:51 AM Carsten Bormann <[email-masked]> wrote:

> On May 21, 2026, at 20:42, Andy Bierman <[email-masked]> wrote:
>
> A lot of good input.
>
> One point where constrained and capable implementations might differ:
>
> > I think we are OK if the tools ignore unknown item entries and handle
> NID encoding as well as SID.
>
> I’m not entirely sure what tools this sentence was about.
> I do surely want to be able to run constrained implementations that never
> operate on any name-based addresses.
>
>
It would be rare (and an NBC change) for a standard grouping to remove
nodes,
so missing SIDs should not happen.  Extra SIDs are more likely, and a tool
should not reject the entire SID file if a path node is not found for a
data item entry.

> Note that SID mappings marked as “obsolete” can stay in the SID file, in
> case we hit an older set of dependencies that still needs them.
>
> Oh, and:
>
> > Our client ignores the dependency list in the SID file and goes with
> > whatever the server YANG library is reporting.
>
> I’m not sure that we had a lot of discussion about even listing the
> dependencies in the SID file.
> It seems to me this is useful information for diagnostics.
> I’m less sure whether there is any operational use.
>
>
Maybe warnings should be generated if the dependency list is not the same
as an implemented list.

Consider the task of updating a megarange.

Use the current megarange state (e.g. all existing SID files) plus the
current set of YANG modules.
Generate a new SID file for every module, even if the module did not
change.  If the SID file changed
then a new one has to be generated.  The old dependency list is not checked.

This implies build and release procedures for SID files, which are still
quite TBD.

There are other ways the SID file might not match the YANG module revisions
in the server

Mod A augments basemod(v1)
Mod B augments basemod(v2)

The server is only allowed to implement 1 revision of basemod, so 1 of the
SID files
(either Mod A or Mod B) will not match the server implementation.

Grüße, Carsten
>
>
Andy