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

[Peter van der Stok <[e-mail]>]

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 <[e-mail]> wrote:
> 
>>> On Sep 12, 2018, at 17:15, Peter van der Stok <[e-mail]> 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 <[e-mail]> wrote:
>>>> On Sep 11, 2018, at 22:25, Michael Richardson <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/core [1]
>>>> 
>>>> _______________________________________________
>>>> Anima mailing list
>>>> [e-mail]
>>>> 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