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

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.

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.

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.

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

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. :-)

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.

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"?