IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry
draft-fairhurst-ipdvb-ule-iana-07

[Ballot comment]
I was almost going to DISCUSS this first point, but I'm sure you all will take it under advisement, and I'm not sure the world ends if you don't:

Section 3 says:

  Allocations in the ULE Next-Header Registry are to be assigned by
  IANA using the "Expert Review" policy defined in [RFC5226].
  Applications must include a reference to a specification of the next
  header extension in a standards document.  An IETF standards-track
  RFC can provide such a reference.  Other specifications are also
  permitted.  The expert shall advise IANA on whether a particular
  specification constitutes a standards document.

That sounds to me like "Specification Required", not "Expert Review". "Specification Required" implies Expert Review anyway. Is this a simple error, or have I missed something?

I suggested in my reply to Adrian that you move the information in 3.2, but you could just as easily change the section title to "Expert Review Guidelines". Still, please consider the rewrite as I suggested, which avoids all of the MUSTs.

I find the line "IANA MUST NOT allocate values greater than 511 (decimal)." Seems like overkill.

That this document is Standards Track is weird to me. Then again, so do all of the other choices. :-)

[Ballot comment]
In this text:

1.  Introduction

  o  Section 3 specifies that new allocations in the ULE Next-Header
      registry are to be assigned by IANA using the "Expert Review"
      policy and provides guidance to the expert reviewer.

You give a reference to RFC 5226 on a later use of "Expert Review", but not here on first use. That's not going to confuse IANA, but for other readers, you might consider including the reference here.

[Ballot comment]
My esteemed IESG colleagues reviewed the IANA considerations, the RFC 2119 keywords, and the nits.
I'll trust them and sleep like a baby :-)

[Ballot comment]


A few nitty-nits:

- 2.1: 3.1415 is a decimal value. I assume you mean integer.

- 2.1: I don't get how an 8 bit value "corresponds" to a 16
bit value. I assume that's obvious to someone who knows ULE.

- 3: would an IRTF I-D aiming to be an experimental RFC
count as a "standards document"?

[Ballot comment]
Further to Alissa's point, it seems to me that we often say "SHOULD" when we mean "MUST (but we know that some people will ignore it)".  As I see it, that's still "MUST".  People will ignore what they want to ignore, and we should specify what we think is right to specify, and not waffle because we think we won't be taken seriously.

That said, no objection here... just a comment.

[Ballot comment]
Further to Adrian's point, if this document is using 2119 language to say "Authors of specifications (see Section 3.0) SHOULD contact IANA to request a new value to be allocated in the ULE Next-Header registry," what are the exceptions when someone who is specifying a new next header value in a specification might not register that value with IANA? This would seem to undercut/contradict the sentence that follows, "Such an allocation is REQUIRED for any method that is to be standardised." If the first sentence just used lowercase "must" this wouldn't be an issue.

[Ballot comment]
Hope that the "this document proposes" language will be resolved before
this is published as an RFC.

---

I don't know how susceptible to RFC 2119 language IANA will prove to be.
Similarly, I'm not sure that authors of specifications can be made
conformant.

It's not important (to me) but I think English is a fine language for
stating such things without recourse to upper case.

IESG/Authors/WG Chairs:

IANA has reviewed [draft-enter-here].  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, the rules for registration in the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry at

http://www.iana.org/assignments/ule-next-headers/

are to be revised. The maintenance rules are to be changed to Expert Review as defined by RFC 5226.

Second, also in the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry at

http://www.iana.org/assignments/ule-next-headers/

the values in the range decimal 144-159 (0x80-0x8f, hexadecimal) are to be marked as "Reserved for Private Use" and will not be allocated by IANA.

Third, also in the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry, located at:

http://www.iana.org/assignments/ule-next-headers/

an additional explanatory note will be added to the registry as follows:

"The Mandatory Extension Headers registry allocates values in the range 0-255 (decimal). These values are used to identify mandatory extension headers. The registered value corresponds to the 16-bit Type value for the mandatory extension header or the specified protocol.

The Optional Extension Headers registry allocates values in the range 256-511 (decimal). These values are used to identify optional extension headers. The registered value corresponds to the 16-bit Type value that would be used for an optional extension header with a header length (H-LEN) of 1."

IANA understands that these are the only actions required to be completed upon approval of the document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IANA Guidance for Managing the ULE Registry) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Guidance for Managing the ULE Registry'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-02-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document proposes an update to RFC 4326 to clarify and update
  the allocation rules for the Unidirectional Lightweight Encapsulation
  (ULE) next header registry.  This registry is used by ULE and Generic
  Stream Encapsulation (GSE) to record the codepoints of extension
  headers and protocols supported by these encapsulation protocols.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-fairhurst-ipdvb-ule-iana/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-fairhurst-ipdvb-ule-iana/ballot/


No IPR declarations have been submitted directly on this I-D.