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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 May 2013 21:23:38 +0100

FYI

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of IESG
> Secretary
> Sent: 24 May 2013 21:05
> To: [email-masked]
> Cc: [email-masked]
> 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]

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 24 May 2013 13:31:28 -0700

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 <[email-masked]> wrote:
>> (http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml)
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 May 2013 21:50:14 +0100

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

> From: Ulrich Herberg [mailto:[email-masked]]
> Sent: 24 May 2013 21:31
> To: [email-masked]; roll WG
> Subject: Re: [Roll] FW: Revised Early Allocation for
draft-ietf-roll-trickle-mcast

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 24 May 2013 13:57:56 -0700

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

---

From: Ralph Droms <[email-masked]>
Date: Sat, 25 May 2013 06:53:37 -0400

> other drafts in the future.

I'll make an explanation here as I initially submitted the request for an early allocation.

Some early allocations are requested to cooperate with other SDOs that produce documents dependent on IETF documents and code point allocations.  In this specific case, I requested the early allocation on behalf of ZigBee Alliance, which has incorporated a reference to draft-ietf-roll-trickle-mcast in its "ZigBee IP Specification" (ZigBee Public Document 13-002r00; available for free available by request here: http://www.zigbee.org/Specifications/ZigBeeIP/Download.aspx).

An early allocation in a case like this is unusual; the IETF prefers that SDOs wait to publish their own documents until the referenced IETF documents are published (or, at least, in the RFC Editor queue and unlikely to change).  I requested the early allocation as ZA has had a deadline in place for publication of "ZigBee IP Specification" for some time and it seemed to me, at the time I made the request, that draft-ietf-roll-trickle-mcast was unlikely to change the codepoint before publication.

- Ralph

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 25 May 2013 11:54:18 +0100

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

> Sent: 24 May 2013 21:58
> To: [email-masked]
> Cc: roll WG

---

From: Ulrich Herberg <[email-masked]>
Date: Sat, 25 May 2013 09:19:54 -0700

Thank you, Ralph and Adrian for the clarification.

Ulrich