> On Sep 12, 2018, at 17:15, Peter van der Stok <[email protected]> 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?) Grüße, Carsten > > 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 protected]> wrote: >> On Sep 11, 2018, at 22:25, Michael Richardson <[email protected]> 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 protected] >> https://www.ietf.org/mailman/listinfo/core >> >> _______________________________________________ >> Anima mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
