Re: [Roll] FW: Revised Early Allocation for draft-ietf-roll-trickle-mcast

["Adrian Farrel" <[e-mail]>]

All allocations are permanent (until they are deprecated).

All code points mentioned in I-Ds are nonsense until they appear in a registry.
Thus, an I-D that says allocate the value x from this registry, is just being
hopeful and anyone implementing it (or, more important, anyone deploying it) is
taking a gamble.

Thus, early allocation is invented to handle the case where an I-D is reported
to be stable, and implementations are starting or well advanced toward
deployment (again, look at RFC 4020). This can help bridge the gap between
documentation and deployment which would otherwise be gated on RFC publication.

Note that this issue does not arise for new protocols that create their own
registries because in those cases there is no competition for codepoints in
existing registries.

A

> -----Original Message-----
> From: Ulrich Herberg [mailto:[e-mail]]
> Sent: 24 May 2013 21:58
> To: [e-mail]
> Cc: roll WG
> Subject: Re: [Roll] FW: Revised Early Allocation for
draft-ietf-roll-trickle-mcast
> 
> Adrian,
> 
> thank you very much for the explanation.
> 
> Is there any good reason for early (permanent) allocations? As long as
> a document still changes, this same problem could occur again for
> other drafts in the future.
> 
> Regards
> Ulrich
> 
> On Fri, May 24, 2013 at 1:50 PM, Adrian Farrel <[e-mail]> wrote:
> > The general problem with early allocation is that the entry is placed in the
> > IANA registry and from that point onwards folk can rightfully interpret the
> > codepoint as having the meaning documented in the registry. Therefore, there
> > might reasonably be implementations (code or 'just' diagnostic tools like
> > sniffers) that have shipped and that use the old code point.
> >
> > The way that IANA handle this is that they deprecate and do not claim back
until
> > the registry is crowded, allowing as long as possible before re-use.
> >
> > As it happens, with this registry, there is a preference for allocations
based
> > only on the "rest" bits even though the entries are tracked separately on
the
> > full 8 bits. Thus, in this case, the new and old codepoints are effectively
the
> > same.
> >
> > For more details on early allocations read RFC 4020 and
> > https://datatracker.ietf.org/doc/draft-cotton-rfc4020bis/
> >
> > Cheers,
> > Adrian
> >
> >> -----Original Message-----
> >> From: Ulrich Herberg [mailto:[e-mail]]
> >> Sent: 24 May 2013 21:31
> >> To: [e-mail]; roll WG
> >> Subject: Re: [Roll] FW: Revised Early Allocation for
> > draft-ietf-roll-trickle-mcast
> >>
> >> Adrian,
> >>
> >> does "deprecated" mean that this code point is not useable again for
> >> other protocols? Why can't it be "Unassigned" again (since the draft
> >> is not yet published as RFC)?
> >>
> >>
> >> Thanks
> >> Ulrich
> >>
> >> On Fri, May 24, 2013 at 1:23 PM, Adrian Farrel <[e-mail]> wrote:
> >> > FYI
> >> >
> >> >> -----Original Message-----
> >> >> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> >> IESG
> >> >> Secretary
> >> >> Sent: 24 May 2013 21:05
> >> >> To: [e-mail]
> >> >> Cc: [e-mail]
> >> >> Subject: Revised Early Allocation for draft-ietf-roll-trickle-mcast
> >> >>
> >> >> IANA is requested to revise the early allocation previously made for
> > draft-ietf-
> >> >> roll-roll-trickle-mcast.
> >> >>
> >> >> In the "Internet Protocol Version 6 (IPv6) Parameters" registry
> >> >> (http://www.iana.org/assignments/ipv6-parameters/ipv6-
> parameters.xml)
> >> >> in the "Destination Options and Hop-by-Hop Options" sub-registry...
> >> >>
> >> >> Please revise the entry that reads
> >> >> 0x4D 01 0 01101 Trickle Multicast Option [draft-ietf-roll-trickle-mcast]
> >> >> to read
> >> >> 0x4D 01 0 01101 Deprecated
> >> >>
> >> >> Please create a new early allocation entry that reads
> >> >> 0x6D 01 1 01101 MPL Option [draft-ietf-roll-trickle-mcast]
> >> >
> >> > _______________________________________________
> >> > Roll mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/roll
> >