MIME-Version: 1.0
References: 
 <CABCOCHRdLaCVxx+iPitC1TGie8j_pQ3QyRYmi-x+iH4f1_t48Q@mail.gmail.com>
 <103eb52f-982a-40bc-b674-ab3f8c1238e9@nic.cz>
 <CABCOCHTGwQqN7tBJNWBb50k0zsqRSXHgp6_Vye6UmT-_072P=g@mail.gmail.com>
 <7459EBFB-BD49-45D3-9691-F0E820932F01@tzi.org>
 <CABCOCHSyS8pnifXAFXq-Dy_79D=6HBEVhhf02zoym6KMVoWXug@mail.gmail.com>
 <33C5EEFA-7635-4025-B8B3-3F245744C517@tzi.org>
 <bf468e47-7989-4e47-b834-5f8c54d1b424@nic.cz>
 <7F085D26-E0D1-4194-95BA-20806163F79C@tzi.org>
 <63dcdb4a-34fc-4d7e-ad07-36f1d6f6461e@nic.cz>
 <05A4FC5A-EFBD-497A-BAAD-AAC81FF22BB6@tzi.org>
 <CABCOCHRNKMi3du3ZEQ=AroTUhnjGt_qG5OzHX7tD9BFekpuDmg@mail.gmail.com>
 <25D15C4C-3FFB-4BE1-8E33-10A27F18380B@tzi.org>
 <CABCOCHSZr2vhNEG2Euc_w9SOZwuyLOW8Vw=p_-aJu8jRSeHNLg@mail.gmail.com>
 <7BAE5EFE-C80D-4DD1-AC91-2ABB1DD0F15E@tzi.org>
In-Reply-To: <7BAE5EFE-C80D-4DD1-AC91-2ABB1DD0F15E@tzi.org>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 21 May 2026 12:44:02 -0700
Message-ID: 
 <CABCOCHTLFVoTkcZJvoCfo3pM9nVmWvCDrtmiHAf=-jS9GYRk_A@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary="0000000000000bed960652592302"
Message-ID-Hash: O3U5UZQUN4UMRAU3M6FWJQEECU6SRCJX
CC: Vojtech Vilimek <vojtech.vilimek@nic.cz>,
 "yang-tooling@ietf.org" <yang-tooling@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5Byang-tooling=5D_Re=3A_Issues_with_IANA_YANG_SID_registry?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/yang-tooling/r0E5k_Z2vi6etEha_f_I0pf8_VI>

--0000000000000bed960652592302
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 21, 2026 at 11:51=E2=80=AFAM Carsten Bormann <cabo@tzi.org> wro=
te:

> On May 21, 2026, at 20:42, Andy Bierman <andy@yumaworks.com> 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=E2=80=99m 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 =E2=80=9Cobsolete=E2=80=9D can stay in t=
he 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=E2=80=99m not sure that we had a lot of discussion about even listing t=
he
> dependencies in the SID file.
> It seems to me this is useful information for diagnostics.
> I=E2=80=99m 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=C3=BC=C3=9Fe, Carsten
>
>
Andy

--0000000000000bed960652592302
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 21,=
 2026 at 11:51=E2=80=AFAM Carsten Bormann &lt;<a href=3D"mailto:cabo@tzi.or=
g">cabo@tzi.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">On May 21, 2026, at 20:42, Andy Bierman &lt;<a href=3D"mailt=
o:andy@yumaworks.com" target=3D"_blank">andy@yumaworks.com</a>&gt; wrote:<b=
r>
<br>
A lot of good input.<br>
<br>
One point where constrained and capable implementations might differ:<br>
<br>
&gt; I think we are OK if the tools ignore unknown item entries and handle =
NID encoding as well as SID.<br>
<br>
I=E2=80=99m not entirely sure what tools this sentence was about.<br>
I do surely want to be able to run constrained implementations that never o=
perate on any name-based addresses.<br>
<br></blockquote><div><br></div><div>It would be rare (and an NBC change) f=
or a standard grouping to remove nodes,</div><div><span class=3D"Q6ibn ng" =
style=3D"border-style:none;background:none">so</span> missing SIDs should n=
ot happen.=C2=A0 Extra SIDs are more likely, and a tool</div><div><span cla=
ss=3D"Asgive ng" style=3D"border-style:none;background:none">should</span> =
not reject the entire SID file if a path node is not found for a data item =
entry.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
Note that SID mappings marked as =E2=80=9Cobsolete=E2=80=9D can stay in the=
 SID file, in case we hit an older set of dependencies that still needs the=
m.<br>
<br>
Oh, and:<br>
<br>
&gt; Our client ignores the dependency list in the SID file and goes with<b=
r>
&gt; whatever the server YANG library is reporting.<br>
<br>
I=E2=80=99m not sure that we had a lot of discussion about even listing the=
 dependencies in the SID file.<br>
It seems to me this is useful information for diagnostics.<br>
I=E2=80=99m less sure whether there is any operational use.<br>
<br></blockquote><div><br></div><div>Maybe warnings should be generated if =
the dependency list is not the same as an implemented list.</div><div><br><=
/div><div>Consider the task of updating a megarange.</div><div><br></div><d=
iv>Use the current megarange state (e.g. all existing SID files) plus the c=
urrent set of YANG modules.</div><div>Generate a new SID file for every mod=
ule, even if the module did not change.=C2=A0 If the SID file <span class=
=3D"Q6ibn ng" style=3D"border-style:none;background:none">changed</span></d=
iv><div><span class=3D"Q6ibn ng" style=3D"border-style:none;background:none=
">then</span> a new one has to be generated.=C2=A0 The old dependency list =
is <span class=3D"Q6ibn ng" style=3D"border-style:none;background:none">not=
</span> checked.</div><div><br></div><div>This implies build and release pr=
ocedures for SID files, which are still quite TBD.</div><div><br></div><div=
>There are other ways the SID file might not match the YANG module revision=
s in the server</div><div><br></div><div>Mod A augments <span class=3D"Asgi=
ve ng" style=3D"border-style:none;background:none">basemod(v1)</span></div>=
<div>Mod B augments <span class=3D"Asgive ng" style=3D"border-style:none;ba=
ckground:none">basemod(v2)</span></div><div><br></div><div>The server is on=
ly allowed to implement 1 revision of basemod, so 1 of the SID files</div><=
div>(either Mod A or Mod B) will not match the server implementation.</div>=
<div><br></div><div><br></div><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
Gr=C3=BC=C3=9Fe, Carsten<br>
<br></blockquote><div><br></div><div>Andy</div><div>=C2=A0</div></div></div=
>

--0000000000000bed960652592302--