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

[Ballot comment]
(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).

[Ballot comment]
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.

[Ballot comment]
Section 4.2 says that registry URLs will be removed from the RFC prior to final publication.  We discussed this on Tuesday in Philly; I'm not sure if we came to a definite conclusion, but I remember many folks supported allowing registry URLs in RFCs. Maybe rephrase to "current editorial policy is to remove URLs; this may change in the future"?

[Ballot comment]
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.

[Ballot discuss]
The document is good, and I want to see 2434 updated. This is not a blocking issue, but I would like to discuss it in the IESG before the document is approved.

Does the fact that we have now 'Specification Required' and 'RFC Required' as separate policies imply that we do assume that in some cases specifications can be originated from out of the IETF? If so why do not we say this explicitly? What does 'readily available public specification' mean in this context - that the specification is freely available without any 'membership' conditions as IETF specifications are? Also 'specification' means approved specification, not work-in-progress, right?

Note that we have do work with other SDO and even with vendors in the case of IANA ifTypes values allocation, which has an Expert Review policy. Here we actually require specifications when we perform the review, but these need not be public;ly available. Of course, the experts need to provide them for the expert review to happen, and they usually do when they are required after having applied for an ifType value with IANA

[Ballot comment]
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"?

[Ballot comment]
>          Value    Description          Reference
>          --------  -------------------  ---------
>          tbd1      Foobar              [RFCXXXX]

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

[Ballot comment]
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"

[Ballot discuss]
Section 3: Sometimes we appoint more than one designated expert to IANA. There has been discussion about whether this means all experts must respond when queried, whether one response is adequate, etc. The doc, in Section 3 and elsewhere, seems to imply that there is only one expert assigned for a given name space. I don't think this matches current reality.

In the definition for "IETF Review" we have this sentence: "To ensure adequate community review, such documents are shepherded through the IESG as AD-sponsored documents with an IETF Last Call," which could imply that it is only valid for AD-sponsored documents (e.g., not those from a WG). If that is the intent, I'd like to know why as I think that is problematic. If it's not, then clarification is necessary. Perhaps the author is considering any document that comes to ballot as "AD-Sponsored" even if it comes from the WG?

Interesting sentence: "IESG Approval would be appropriate, however, in cases where expediency is desired and there is strong consensus for making the assignment (e.g., WG consensus)." - I would think that most people would not consider a process which required IESG approval to ever be "expedient." - particularly given:

>            The following guidelines are suggested for any evaluation
>              under IESG Approval:
>
>              - The IESG can (and should) reject a request if another
>                path is available that is more appropriate and there is
>                no compelling reason to bypass normal community review.
>
>              - before approving a request, the community should be
>                consulted, via a "call for comments" that provides as
>                much information as is reasonably possible about the
>                request.

I have two problems with this suggested IESG approval path. First, "if another path is available" should be clarified (assuming this is a correct assumption) to mean  "another path of registration." I'm afraid that this text might be construed as being about evaluating competing solutions vs. simply about whether another path of registration for the value in question exists whcih should be used. Second, the "call for comments" seems ill-defined, and I'm afraid could end up as trouble down the road. I'd much rather this be something clear like "IETF Last Call" or "WG Last Call" etc. If not that, at least a better definition of what this really means so that we don't end up trying to figure that out during an appeal one day in the future.

I wonder if we should have "WG Consensus or Designated Expert" which essentially means that, as long as a WG exists, WG last call suffices, and after the WG is closed an expert is appointed. This is almost the same as assigning chairs to the expert positions, except that it implies more WG involvement as long as the WG exists, and doesn't require keeping chairs and experts in sync.

What about RFC4020? It seems strange to ignore it.

Section 8 on "Mailing Lists" doesn't seem to say a much, what's the real point behind this section?

[Ballot discuss]
Section 3: Sometimes we appoint more than one designated expert to IANA. There has been discussion about whether this means all experts must respond when queried, whether one response is adequate, etc. The doc, in Section 3 and elsewhere, seems to imply that there is only one expert assigned for a given name space. I don't think this matches current reality.

In the definition for "IETF Review" we have this sentence: "To ensure adequate community review, such documents are shepherded through the IESG as AD-sponsored documents with an IETF Last Call," which could imply that it is only valid for AD-sponsored documents (e.g., not those from a WG). If that is the intent, I'd like to know why as I think that is problematic. If it's not, then clarification is necessary. Perhaps the author is considering any document that comes to ballot as "AD-Sponsored" even if it comes from the WG?

Interesting sentence: "IESG Approval would be appropriate, however, in cases where expediency is desired and there is strong consensus for making the assignment (e.g., WG consensus)." - I would think that most people would not consider a process which required IESG approval to ever be "expedient." - particularly given:

>            The following guidelines are suggested for any evaluation
>              under IESG Approval:
>
>              - The IESG can (and should) reject a request if another
>                path is available that is more appropriate and there is
>                no compelling reason to bypass normal community review.
>
>              - before approving a request, the community should be
>                consulted, via a "call for comments" that provides as
>                much information as is reasonably possible about the
>                request.

I have two problems with this suggested IESG approval path. First, "if another path is available" should be clarified (assuming this is a correct assumption) to mean  "another path of registration." I'm afraid that this text might be construed as being about evaluating competing solutions vs. simply about whether another path of registration for the value in question exists whcih should be used. Second, the "call for comments" seems ill-defined, and I'm afraid could end up as trouble down the road. I'd much rather this be something clear like "IETF Last Call" or "WG Last Call" etc. If not that, at least a better definition of what this really means so that we don't end up trying to figure that out during an appeal one day in the future.

I wonder if we should have "WG Consensus or Designated Expert" which essentially means that, as long as a WG exists, WG last call suffices, and after the WG is closed an expert is appointed. This is almost the same as assigning chairs to the expert positions, except that it implies more WG involvement as long as the WG exists, and doesn't require keeping chairs and experts in sync.

What about RFC4020? It seems strange to ignore it.

Section 8 on "Mailing Lists" doesn't seem to say a

[Ballot comment]
Personally, I think IANA registry URLs should be stable unless the
registry is renamed (or presently under-specified) and 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.

[Ballot discuss]
I object to this statement "All such URLs, however, will be removed from
the RFC prior to final publication."  This is a change in procedure from
RFC 2434 (that was not documented in section 10), does not reflect
current practice, and it removes a desirable capability (having a
persistent registry URL).  Specifically, RFC 4790 creates a registry
with persistent IANA URLs that was done in consultation with IANA.
Removing this discretion from IANA makes the process too rigid for the
future.

IANA Last Call comments:

We understand this document to be guidelines for authors for IANA
considerations sections in their documents. This document does
not request IANA actions itself.

IANA has sent additional comments to the authors regarding minor
text updates.