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

[Carsten Bormann <[e-mail]>]

On 2023-03-27, at 03:01, Michael Richardson <[e-mail]> wrote:
> 
> 
> Carsten Bormann <[e-mail]> wrote:
>> 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 don't know if you are agreeing or disagreeing withme.

I don’t know that either… Let’s find out.

>>> I have reread RFC8126 section 4.1 vs 4.2.
> 
> IANA has two different things, Experimental Use vs Private Use.
> For SIDs, I'm not really sure what the effective difference would be.

The difference RFC 8126 makes is the scope of the use.
Experimental is for an experiment, for which is " it's important
to make clear any expected restrictions on experimental scope.  "
Private use doesn’t require this effort: “ It is the responsibility of the sites making use
   of the Private Use range to ensure that no conflicts occur (within
   the intended scope of use).”.

>>> 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”.
> 
> Yes, I know.
> My point is that things get made public in different ways.
> I think that Private Use allocations should never be public, but Experimental
> Use might be.

That might be a useful difference.

>>>> 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.)
> 
> We've resisted writing that SID values are made "final" at WGLC, because I
> think that we didn't want to write IETF-specific instructions into YANG-SID.
> But, I think that is what we want for IETF stream documents.

WGLC is a bit early for anything final anyway.  IESG approval is more like it.
(But then things might change in AUTH48, if they are broken enough.
But then, if things are broken, the rules will only be of limited help.)

Grüße, Carsten