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

On Wed, Sep 12, 2018 at 9:14 AM, Carsten Bormann <cabo@tzi.org> wrote:

>
>
> > On Sep 12, 2018, at 17:15, Peter van der Stok <stokcons@bbhmail.nl>
> 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 <cabo@tzi.org> wrote:
> >> On Sep 11, 2018, at 22:25, Michael Richardson <mcr+ietf@sandelman.ca>
> 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
> >> core@ietf.org
> >> https://www.ietf.org/mailman/listinfo/core
> >>
> >> _______________________________________________
> >> Anima mailing list
> >> Anima@ietf.org
> >> https://www.ietf.org/mailman/listinfo/anima
>
>