Hi Michael,
I'm not entirely sure I understand to include the YANG revision in it,
since really it should cross YANG revisions.
Yes, the latest revision .sid file will include all of the prior SIDs
with all of the same values, since they aren't allowed to change.
However, one could *generate* (locally) a .sid file where the prior
number assignment is not properly taken into account, so that different
SID values emerge. In such case that logic doesn't hold.
Also, when used together with an older YANG module revision, a newer
.sid file will have too many SIDs included, included ones for path
expresssions that don't work (i.e. give error) on the older YANG module.
So this makes it very hard for a user to actually use this .sid file for
the older revision; since it will be unclear for users whether they
should ignore the "erroring-out" SID elements or whether they should
start worrying that they have the wrong .sid file!
To avoid any confusion and doubt, it seems best practice to combine
YANG/.sid files of exactly one revision date and use these together.
I guess we should also be including the sid file "inline" the RFC in an
appendix. I kinda hate that (and I hate having the YANG file in the RFC
too), but we don't have a better answer yet.
I would also think that's a good idea. What RFC 9595 basically
specifies (Section 6.4.3) for developers/authors like us is to include
the complete generated draft .sid file in the I-D, which is then
extracted from it and validated by an expert team.
At time of RFC publication, the section/appendix with this draft needs
to be removed again and instead a link to the final info is included.
I'm assuming we do have these experts present somewhere :)
"""
6.4.3. Publication of the ".sid" File
During an RFC's publication process, IANA contacts the designated expert
team ("the team"), who are responsible for delivering a final ".sid"
file for each module defined by the RFC. For a type-3 developer
(SID-oblivious; see Section 2.4), the team creates a new ".sid" file
from each YANG module; see below. For a type-2 (SID-aware) developer,
the team first obtains the existing draft ".sid" file from a stable
reference in the approved draft; for a type-1 (SID-guiding) developer,
the team extracts the ".sid" file from the approved draft.
"""
Esko
> This is the way to know to which YANG module revision a given .sid file
> belongs to. E.g. files could be stored in an IETF FTP directory.
Yes, but since SIDs are never re-used, whatever the latest file should apply
to all revisions...
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
