From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Vojtech Vilimek <vojtech.vilimek@nic.cz>, yang-tooling@ietf.org
In-Reply-To: <936f5ef6-3830-405b-9c71-3539e1fb69f5@nic.cz>
References: 
 <CABCOCHTP52cfDVeguY3iYbzJqmCfg-z5cMeFz-y_3vNw250TEg@mail.gmail.com>
 <56406098-2B8F-402B-BE6A-AE9FEA9D7217@tzi.org>
 <CABCOCHQR30cSFqoFiYrj-PhX42r9o8zkSz9idVSOZYOyLD4A4A@mail.gmail.com>
 <ee28c8c1-fe81-4f9f-ba36-b60c74b5d156@iotconsultancy.nl>
 <CABCOCHR-oo5xK2bbagDUtK=1Mi5dBLjNT8r=4Y4QSJoFs0SgRA@mail.gmail.com>
 <b1256b3f-794b-40e8-a7e8-d1395fa7aa0d@iotconsultancy.nl>
 <EE144B22-21ED-46E8-8963-3D5639F377E9@tzi.org>
 <CABCOCHSzgtHZ3YpEwCrCtXBTFjusidzP3aCDbeJySM36toFoeA@mail.gmail.com>
 <81BE63E4-AB15-4 298-8A63-94726BD7F024@tzi.org>
 <CABCOCHTC-VTk5gBY7O95Au8eUF84pgVA2q4z7d8kY8N4hsFVtw@mail.gmail.com>
 <6E107270-5943-4615-A221-24FC6A66D914@tzi.org>
 <CABCOCHR32FgW_y54KTomJcD+kaFn_yqupr1-zCJJyHsPEoxX5g@mail.gmail.com>
 <CABONVQZTqmiGPW3WdEABPeLCwiJXoXxnWZqEo2zVVt0wLto-6g@mail.gmail.com>
 <CABCOCHR2ObrvyBW2B+vEQYWyo74XJz0S4SgLhPDDFnDvxSB--w@mail.gmail.com>
 <1519353.1770459201@dyas> < 0ce1cdae-219c-40ec-bffc-1da6c1c0cd6a@nic.cz>
 <2318293.1770897407@dyas> <936f5ef6-3830-405b-9c71-3539e1f
 b69f5@nic.cz>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Fri, 13 Feb 2026 11:56:23 +0100
Message-ID: <2376313.1770980183@dyas>
Message-ID-Hash: TSRC3FP2SG6FQGYXXJAU7YJKO5IS5HIX
Precedence: list
Subject: =?utf-8?q?=5Byang-tooling=5D_Re=3A_SID_file_issues_/_=2Esid_file_differences?=
	=?utf-8?q?_in_pyang_and_core-wg/pyang?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/yang-tooling/59Uao-cBk-zeB32_TkTIzqC3j3Y>

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Vojtech Vilimek <vojtech.vilimek@nic.cz> 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 publ=
ish
    mcr> it, but rather keep it around for RFC9595bis and/or RFC9254bis, wh=
ich
    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 no=
t yet.

    > The
    > old behavior of the PYANG is considered wrong and needs to be rewritt=
en
    > together with the new erratum/draft-rfc9595bis.

=2D-
]               Never tell me the odds!                 | ipv6 mesh network=
s [
]   Michael Richardson, Sandelman Software Works        | network architect=
  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails  =
  [


=2D-
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-                      *I*LIKE*TRAINS*




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmmPA1cACgkQlUzhVv38
QpDqKgf+I889CwPcrnxdObeF9onKTXsVxX+MuI+5zMpDHB00asdW63OXiV40lzus
q0/JJp6X/eKyjc9vi2nBZvQfZtKcaB+YZcUt7Nbszvm1rsDrlh+ploTPD5g0emnA
8PUWqRjEen8wBb3Ky+RpUQEA47oHBg8wrGiPSTvEB4ZmCa8ECOaaY2VnAKsAUROJ
V/Gd13As+n4eIcU+MJqZY9PgQYzCHPUUgBgjf7hoL0dxUchfJPWeUzWeWGuzlHzs
z67MRsvnIF5/OS340svD/qXfZcujI6MYXp63IwYHUAehQLzHHVq6ltzGX0w30tlG
xvWXPChSwCbnwMZgUjTI2tHuiAypzA==
=hD84
-----END PGP SIGNATURE-----
--=-=-=--