Subject: Re: [core] [Anima] documenting SID usage in IETF specification

From: Peter van der Stok <[email-masked]>
Date: Sat, 03 Nov 2018 18:12:15 +0700

Hi all,

Jut to conclude and come to a decision.
SID files are included in the I-D and RFC.
SID allocation is handled by comi.space as is; remains the maintenance
question of comi.space.
Once I-D goes to RFC, SIDs are administrated by IANA. It would be good
if comi.space is made aware of that.

Can these principles and the IANA registry become part of the
ietf-core-sid draft?
There are currently two registries proposed in core-sid:
- a YANG range registry
- a YANG module assignment

The latter may actually contain the sid files that are used and IANA
should check that no numbers are used twice.

Any suggestions?

Peter
Andy Bierman schreef op 2018-09-12 23:32:

> On Wed, Sep 12, 2018 at 9:14 AM, Carsten Bormann <[email-masked]> wrote:
> 
>>> On Sep 12, 2018, at 17:15, Peter van der Stok <[email-masked]> wrote:
>>> 
>>> Hi all,
>>> 
>>> The numbering of the SIDs in our case should be as stable as possible after publication as RFC.
>>> A permanent assignment of the numbers, like the content-format numbers, would be very much appreciated.
>>> Using the same already allocated numbers for other RFCs would be quite disastrous.
>> 
>> Yes, I think that part is clear.
>> 
>> What Andy pointed out is that we also need to have an idea of how to evolve a draft in a way that minimizes damage from changing those numbers during the development of that draft.  So we need to start allocating and managing SID numbers early in their lifetime, at least from the point of time when a draft is becoming an "implementation draft" (as opposed to just an idea that wants to be discussed).  That is not something we have traditionally done with IANA registrations, which are traditionally considered a scarce resource and thus should only be assigned to finished (or near-finished, hence "early allocations") protocols.
>> 
>> My proposal would be:
>> 
>> -- have a more explicit way of designating drafts as Implementation Drafts.   Basically, any SIDs allocated before that are without protection,  but once we have an Implementation Draft, the SIDs used in that will not be re-used.  (Intermediate versions between Implementation Drafts would again have any new SIDs in unprotected state until another Implementation Draft is declared.)
>> 
>> -- have a way to include the SID file in the document (draft, RFC).  This is not beautiful, but unless we invent another representation for that information, that is the interchangeable form.  (If we do invent another representation, maybe we should always use that?)
> 
> Thanks for summarizing the issue and also for a very practical solution. 
> The SID file needs to be included in the I-Ds and the RFC. 
> The Implementation Draft idea sounds like the old discussions about "working group snapshots" 
> but it very useful info to know the difference: 
> 
> - the module and SID assignments are not stable at all and MAY change at any time in the future 
> - the module and SID assignments are from an Implementation Draft and SHOULD remain the same in future revisions 
> 
> - the module and SID assignments are from an RFC and MUST remain the same in future revisions 
> 
>> Grüße, Carsten
> 
> Andy 
> 
>>> 
>>> Maintenance of (part of) the comi.space by a organisation like IANA could be a possibility.
>>> 
>>> Peter
>>> Andy Bierman schreef op 2018-09-12 01:32:
>>> 
>>>> 
>>>> 
>>>> On Tue, Sep 11, 2018 at 3:12 PM, Carsten Bormann <[email-masked]> wrote:
>>>> On Sep 11, 2018, at 22:25, Michael Richardson <[email-masked]> wrote:
>>>>> 
>>>>> SHOULD ietf-core-sid say something about this?
>>>> 
>>>> Yes, we should have a common way of handling SID allocations in RFCs.
>>>> 
>>>> draft-ietf-core-sid sounds like a natural way to place this, but what goes into what document is often a question of who has time to write something at a particular point in time.  So let's discuss this with the authors.
>>>> 
>>>> In any case, this probably should stay at the level of a suggestion more than prescribing a normative way of doing things -- the conventions we use for this may evolve faster than the rest of the technical content of draft-ietf-core-sid.
>>>> 
>>>> 
>>>> You probably want to make a clear distinction between Internet Drafts with volatile SID assignments
>>>> and RFCs with permanent SID assignments.
>>>> 
>>>> Do you want early implementation (of modules using SID)  to be as painful as possible or as seamless as possible?
>>>> Renumbering SID assignments may be extremely disruptive to actual deployments.
>>>> Correctness of a SID file within a source document is not the same thing as correctness of all SID files
>>>> across an entire administrative domain.
>>>> 
>>>> I agree the administration of SID assignments is out of scope for CORE WG but punting
>>>> the problem to vendors or operators will not be good enough.
>>>> 
>>>> 
>>>> 
>>>> Grüße, Carsten
>>>> 
>>>> 
>>>> Andy
>>>> 
>>>> 
>>>> _______________________________________________
>>>> core mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/core [1]
>>>> 
>>>> _______________________________________________
>>>> Anima mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/anima [2]

Links:
------
[1] https://www.ietf.org/mailman/listinfo/core
[2] https://www.ietf.org/mailman/listinfo/anima

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Nov 2018 20:32:31 +0700

On Nov 3, 2018, at 18:12, Peter van der Stok <[email-masked]> wrote:
> 
> The latter may actually contain the sid files that are used and IANA should check that no numbers are used twice.

While that is always a good thing: How could that happen?

Grüße, Carsten

---

From: Peter van der Stok <[email-masked]>
Date: Sat, 03 Nov 2018 20:45:47 +0700

Hi Carsten,

there are two sides to your question:
- How do we convince IANA to take the responsibility
- How will they check the SID files: Like they check the content-format
numbers and others

Was there a third side?

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Nov 2018 21:34:01 +0700

> - How do we convince IANA to take the responsibility

That depends a lot on the scale.  There will be hundreds of modules, each potentially with hundreds of SIDs.
So we are creating a problem on the scale of IANA’s biggest registry (Private Enterprise numbers, PENs).
I’m not sure that is realistic.

> - How will they check the SID files: Like they check the content-format numbers and others

The allocation is based on mega-ranges.  What people do within their allocations should really be their business.
Only for the IETF range we may want to go into more detail, and that should be based on allocating ranges for the modules.
The only thing that needs to be checked is that all SIDs of a module are within the range allocated to the module, and that those allocations don’t overlap.

Grüße, Carsten

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 05 Nov 2018 11:38:06 +0700

Hi Carsten,

My proposal for the handling of SIDs is the following:

During the development of a YANG module described in an Internet draft,
the allocation of SIDs is handled by the comi.space facility.
A range is allocated to the module in the non-RFC range; during the
development of the draft, the range can be changed and the allocation to
individual YANG names can be changed.

Once the draft is accepted to become RFC, the following actions should
be taken:
- The SID range for every module in the future RFC is allocated from the
RFC range. (This means changing the SID values)
- The contents of the SID files (one per module) are included in the
RFC.
- IANA registers the module names, RFC number, and the SID range
allocations.
- IANA registers the YANG name to SID map for every module in the RFC.

we could ask IANA to provide an extension to YANG parameter registry
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

It contains presently a YANG module registry. (as specified in RFC6020,
section 14.1)
Suggestion to create next to yang module registry a sid module registry.
Currently, IANA makes a version of the yang module available, so
maintaining a sid file should be possible as well (IMO)

Comments will be appreciated,

Peter 

Carsten Bormann schreef op 2018-11-03 21:34:

> So we are creating a problem on the scale of IANA's biggest registry (Private Enterprise numbers, PENs).
> I'm not sure that is realistic.
> 
> The only thing that needs to be checked is that all SIDs of a module are within the range allocated to the module, and that those allocations don't overlap.
> 
> Grüße, Carsten