Guidelines for Writing an IANA Considerations Section in RFCs
RFC 5226

Note: This ballot was opened for revision 09 and is now closed.

(Jari Arkko) Yes

Comment (2007-10-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
>           Value     Description          Reference
>           --------  -------------------  ---------
>           tbd1      Foobar               [RFCXXXX]

It seems that using TBD instead of tbd would be clearer.

(Ron Bonica) Yes

(Ross Callon) Yes

(Lisa Dusseault) Yes

(Lars Eggert) Yes

(Sam Hartman) Yes

Comment (2007-10-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I agree with Mark's discuss comment that multi-expert registries need
to be supported.

(Russ Housley) Yes

(Cullen Jennings) Yes

(Jon Peterson) Yes

(Tim Polk) Yes

Comment (2007-10-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
As in Mark's Discuss and Sam's comment, cases where the designated expert role is shared
among multiple people should explicitly be allowed.  Section 3.2 discusses the appointment
of designated experts by the IESG.  Perhaps we could add a paragraph after the next to last
paragraph (following "the IESG will appoint replacements if necessary") along the following lines:

  In addition, the IESG may choose to appoint multiple individuals as
  designated experts for a particular registry.  For example, multiple
  designated experts may be required to limit the workload for name
  spaces with large numbers of registration.  Where multiple designated
  experts have been appointed, IANA shall designate a primary for
  each request, who shall be responsible for carrying out the
  evaluation.  The mechanism(s) for selecting the primary designated
  expert for a particular request is left to IANA.

I hope this text also addresses Michelle's concerns.

(Dan Romascanu) (was Discuss) Yes

(David Ward) Yes

Magnus Westerlund Yes

Comment (2007-10-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think "Magnus Westerland" in the acknowledgment section is actually me as I have commented on the document. Could I please have my last name correctly spelled "Westerlund"?

(Pasi Eronen) No Objection

Comment (2008-03-27)
No email
send info
(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).

(Chris Newman) (was Discuss) No Objection

Comment (2008-03-26)
No email
send info
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 to 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.

(Mark Townsley) (was Discuss) No Objection

Comment (2007-10-16)
No email
send info
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"