Re: [core] [IANA #1269224] Early review: draft-ietf-core-sid (IETF 116)

[Carsten Bormann <[e-mail]>]

On 24. Mar 2023, at 22:31, Michael Richardson <[e-mail]> wrote:
> 
> 
> IANA has been extra vigilant this round.
> I am adding the WG to the list, since these are mostly my opinions.
> (However, I believe that I'm re-stating WG consensus)
> 
> Amanda Baber via RT <[e-mail]> wrote:
>> 1) Section 6.4.2 says, 'The range of 60,000 to 99,999 (size 40,000) is
>> reserved for experimental YANG modules. This range MUST NOT be used in
>> operational deployments since these SIDs are not globally unique which
>> limit their interoperability. The IANA policy for this range is
>> "Experimental use".' However, Table 3 says that the policy is
>> "Experimental/Private use." Which is correct?
> 
> I think that while it's for "experimental" YANG modules, the implication is
> that they are for Private Use.  

I think they actually were meant for private, experimental use.
Even in private use, you should not fill up this space with your private needs.
You should use those for experiments only.

> I have reread RFC8126 section 4.1 vs 4.2.
> I think that we want the Private Use policy.  The implication being that the
> values would never escape the lab or be used across the Internet.
> 
> Our goal is to make the friction required to acquire space so low that
> essentially nobody would use these values.  They might be used in test data,
> in examples, libraries, but never on the wire.
> 
>> 2) Possible timing issue: Section 6.4.2 says that the publication of
>> the YANG module is required for SID allocation. It also says that the
>> RFC must contain a link to the .sid file. Section 6.5.1 calls for a
>> link to the .yang file in one of the registry fields.
> 
> It does say:
> 
>      -  The Expert MUST verify that the YANG module for which this
>         allocation is made has an RFC (existing RFC) OR is on track to
>         become RFC (early allocation with a request from the WG chairs
>         as defined by [BCP100]).
> 
> I think that we expect early allocation for nearly every WG document.
> My idea is that early allocation occurs at WG adoption, at which point all
> values are unstable.
> 
>> However, while we register the YANG module name when the IESG approves
>> the document, we don't post the YANG module itself until after the RFC
>> Editor publishes the document.
> 
> I observe that yang catalog scrapes YANG modules out of individual drafts
> and essentially they get "published" at that point.

That is not core-sids concept of “published”, which is “all numbers are now stable and you can treat this as final”.
But making a final version available as the result of approval is a good objective.
Making revisions of the “unpublished” (i.e., widely published with the draft, but not final) revisions available in a good way is also an objective — here yangcatalog.org could help.
> 
>> Does this present a problem if a document wants to publish a YANG
>> module and a .sid file simultaneously? Can the .sid file be published
>> before the YANG module file is present in the IANA registry, or would
>> we also wait until after RFC publication to publish the .sid file
>> (which means that the RFC's URL for the .sid file wouldn't actually be
>> created until a day or two after publication)?
> 
> The sid values can be allocated before the YANG module is published.
> I agree that the RFC-editor's URL for the .sid file wouldn't be present until
> the document is at the RPC.
> 
>> 3) Another possible issue: if we have a SID file for a YANG module
>> called ietf-example, and another document comes along and provides a
>> new version of ietf-example, do we update the link in the "IETF YANG
>> SID Registry" to point to the new version of the YANG module, or
>> continue pointing to the old one?
> 
> Yes, we would do that when the document is published.

(And I would expect that old revisions of both are also accessible, somewhere.)

Grüße, Carsten