On Wed, Sep 12, 2018 at 9:14 AM, Carsten Bormann <[email protected]> wrote:
> > > > 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?) > > 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 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
