Guidelines for Writing an IANA Considerations Section in RFCs
draft-narten-iana-considerations-rfc2434bis-09

It is my understanding that the following statement:
 "since IANA URLs are not guaranteed to be stable in the future"
is not actually true in many cases as IANA goes to significant effort
to preserve IANA URL stability (the last time stability was broken
was rightly broken was the move from isi.edu to iana.org and I see
no reason to repeat such a move).  While this document has been
delayed too long by the IESG for too little improvement, I would be
happier with the document if this statement was simply removed as a
BCP has no business making value judgments about operational matters.

At the recent IESG plenary we discussed to what degree rules should
be written down vs. left to the reasonable person principle.  It's my
opinion this draft errors on the side of writing down too much and
may be worse than its predecessor for that reason in some areas.  I
hope this does not cause problems in the future.  Overspecified rules
can make it more difficult to apply the reasonable person principle.

IANA registry URLs should be stable unless the registry is renamed (or
presently under-specified) and I would encourage use of such URLs in
RFCs as that aids protocol implementers unfamiliar with the maze of
IETF/IANA/RFC web pages in finding protocol extensions, but IANA
should have discretion on this topic so any text that leaves
IANA discretion is fine with me.

Two IANA ideas I've seen used recently that I like (not a suggestion to
change the draft now, unless the authors/shepherd wish to do so):

1. the concept of provisional registration, for example in the
email/news/http headers registry.  This provides a way to easily reserve
a name during experimentation/draft phase to avoid collision, while
clearly marking it as undesirable for interoperability in the registry.

2. for protocol extension names, the use of a naming convention that
prevents implementations of drafts from colliding with the final
published specification.  For example, the use of
"X-DRAFT-W05-QRESYNC" in draft-ietf-lemonade-reconnect-client-06.txt.

Does the following need to be broken out into a terminology section?

>    In this document, we call the set of possible values for such a field
>    a "name space"; its actual value may be a text string, a number or
>    another kind of value. The binding or association of a specific value
>    with a particular purpose within a name space is called an assigned
>    number (or assigned value, or sometimes a "code point", "protocol
>    constant", or "protocol parameter"). Each assignment of a value in a
>    name space is called a registration.

Page 11:

>              behind "permanent and readily available" is that a document
>              can be reasonably be expected to easily be found long after

s/be reasonably/reasonably

>    It should be noted that it often makes sense to partition a name
>    space into multiple categories, with assignments within each category
>    handled differently. For example, many protocols now partition name
>    spaces into two (or even more) parts, where one range is reserved for
>    Private or Experimental Use, while other ranges are reserved for
>    globally unique assignments assigned following some review process.
>    Dividing a name space into ranges makes it possible to have different
>    policies in place for different ranges.

Suggest finding a nice example to reference here.

DHCP FooBar example on Page 15 needs column alignment.

For consistency, the "tbd1" in the table on page 16 should probably be "TBD1"

(Comment updated for version -09): I'm OK with the new text in 
Section 5.1; however, Section 4.2 needs the same update (that 
in some cases, URLs could be left in).