--On Thursday, October 02, 2014 06:47 -0700 The IESG
<iesg-secretary@xxxxxxxx> wrote:
> The IESG has received a request from an individual submitter
> to consider the following document:
> - 'Guidelines for Writing an IANA Considerations Section in
> RFCs' <draft-leiba-cotton-iana-5226bis-08.txt> as Best
> Current Practice
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action.
>...
I congratulate the authors on producing a document that
improves on RFC 5226 in a number of significant ways. On the
other hand, it seems to be a full ten pages longer than 5226
and to go into hugely more detail. In some cases, that detail
is an advantage; in others, it may overspecify things in ways
that either require more exceptions or that can be used to
force particular registries into inappropriate models.
Unlike some other reviewers, I believe that this document is
not ready for publication and that its publication in its
current form might actually be harmful. While I have looked
through other reviews, this one is based on as close to a clean
reading as possible, therefore it might be redundant in some
areas with others or even with comments for which dispositions
have already been suggested. On the other hand, I've tried to
avoid nit-picking and small issues, so the absence of an issue
below does not mean that I consider it insignificant.
Some very general comments follow and are then followed by
comments about narrower or editorial issues, but all of them
should be considered as evidence that the document needs
serious work, perhaps by a wider group of people organized more
along WG lines.
Observation: The comments below have been considerably informed
by other discussions in recent months including those in the
URNBIS WG, ones about registry interactions with other
organizations, and others about the "charset" registry and
external claims that it is not working and should be ignored.
Very few, if any, of the comments are the result of pure
theorizing.
G.1 This document is not entirely about IANA Considerations
Sections and departs far more from that topic than RFC 2434
did. Instead, it contains a good deal of tutorial material
about how IANA works and about its procedures (Section 7 about
references from registries is a particularly striking example);
a great deal of material about alternate review procedures, how
they work and how policies about them are structured; various
other policy issues, etc. The comments below reflect that much
wider scope. It may be entirely appropriate to have all of
this material in a single document but, if it is, the title and
abstract should be adjusted accordingly. If it is not, the
document should be split into pieces, perhaps with one covering
"IANA Considerations Sections", another covering "Models for
Registration Application Reviews", etc. Or perhaps it should
be further modularized, breaking out "Expert Review" into a
separate document and recasting much of the "IETF Review",
"Standards Action", and "IESG Review" sections into updates to
RFC 2026 (and making the parts of this that change much easier
to maintain). There are also a number of "what goes where"
statements that have traditionally been under the authority of
the RFC Editor (especially since they affect multiple streams),
not IANA or the IESG. If those are to remain, esplicit signoff
from the RFC Editor should be obtained and then noted in the
document.
G.2 Especially in the light of discussions about IANA
transition and its implications, this document should be
extremely careful when describing the IETF-IANA relationship.
It might be desirable to remove that discussion entirely,
leaving it to other documents but, if it is retained,
statements like those in the Abstract and Introduction that
imply or state that all IETF protocol registries are
coordinated by IANA should be adjusted ("most" or "usually" in
the relevant sentences might be sufficient) or otherwise toned
down.
G.3 The predecessors of this document have often been turned
into Procrustian beds about possible registration policies,
albeit with a choice of beds by the prospective registrant.
Text that says that the methods presented should be used when
possible but those statements has been used to justify a very
high bar. In addition, statements such as "their use is
encouraged when appropriate" (Section 2.3.1, first paragraph),
"Note that the well-known policies are not exclusive..." (near
the end of Section 2.3.1), and "However, use of these terms is
strongly RECOMMENDED" (first paragraph of Section 4) convey
different impressions even if they are not actually
contradictory. The intent of providing some models has been
distorted often enough into "choose one of these and live with
it" that the document should be made much more explicit that
these are well-understood models but that variations on them,
or even different approaches, may be better in some
circumsntances and are expected to occur and be used.
G.4 It seems to me that the Expert Review model (see Section
4.5, which appears to claim that "Designated Expert" is
obsolete terminology and Section 5, which prefers that term)
has evolved in practice into at least three separate models,
with the separation obsecured by the current text. I think
those models are:
(1) A registration process manager. Where there is a
mailing list that is expected to be the real evaluator of
registration applications, this role is much like that of a
WG Chair, determining when consensus has been reached,
controlling discussions that are going seriously off-topic,
etc. Note that this person may not have to be a
significant and recognized subject matter expert about the
registry in question, which may be an advantage.
(2) An expert reviewer or set of reviewers with a chair or
lead. These people may be supported by a mailing list, but
are expected to make the actual decisions rather than
relying on list consensus.
(3) An expert consultation process whose job it is to help
refine registration applications and advise would-be
registrants about details and alternatives. Except in the
most nonsensicial of cases, the decision as to when to tell
IANA to go ahead and make the registration ultimately
belongs, not to the experts (or mailing list consensus) but
to the would-be registrant.
I believe that clarifying those options could both prevent the
need for debates about one-off situations and make this
document clearer and stronger.
G.5. Partially as a corollary to the comment in G.1 above, I
wonder about the level of detail in Section 2.1 and the
implicit assumption that none of it will change. Real
experience (of the "running code" persuasion) tells us that the
current "find things by looking though an alphabetical
hierarchical structure with names that have been selected using
a number of different theories over the years" is problematic
for anyone who is not an expert on IANA and its registries.
Should things evolve in the directon of search mechanisms for
registries, protocols, and contents --something that some of us
have advocated on and off for years-- this much detail in this
document may become problematic. It would be far better to
have IANA product a discussion of how the registry system is
structured in another document (not necessarily in the RFC
series) and then have this specificaton summarize that at a
very high level and point to it.
G.6. The discussion about delegated namespaces seems a little
fuzzy. It is fairly clear for namespaces that are completely
delegated to one entity and for hierarchical name spaces where
some piece of the hierarchy is given a delegation-specific name
and then handed off. But it is easy to imagine [part of] a
namespace being delegated to multiple bodies (especially a set
of SDOs) for evaluation of applications with each one able to
hand something to IANA as approved and IANA performing only an
FCFS check on names or numbers. This is particularly relevant
to the first paragraphs of Section 4 which seem to imply that
partitioning namespaces into ranges and using hierarchical
allocations are the only possible delegation modes.
G.7 While the document says that delegated entities can and
should make up their own rules, I think it might add that we
have found the methods outlined in Section 4 to be useful and
probably worth understanding as procedures are designed.
G.8 We have a problem area when the community believes that a
high level of evaluation (e.g., "IETF Review" or "Standards
Action" is important because of the nature of the registry or
items being registered, but also discovers that the skill,
knowledge, and talent needed to do that level of evaluation is
not present in sufficent quantity in the community. I don't
know of any general solution, but it is a concern that the
document might at least note.
G.9 For substantially all methods of reviewing and approving
registrations, actual rejection of a value registration request
on any grounds other than redundancy or refusal of the
applicant to comply with application requirements (or obvious
silliness) should be treated as a serious matter and carefully
explained and documents. This is an especially important
requirement when issues of design preferences (see "taste
enforcement" in E.1 below), relationships that could be
construed as conflicts of interest (see paragraphy 4 of Section
5.2 but also consider IESG members, etc.), or the IETF's
obligations as stewards of these registries for the rest of the
Internet community might come into play. Note that this does
not just apply to experts and goes well beyond the "defend
their decisions to the IETF community" language of Section 3.2
(and of 5226) and that I'm actually far more concerned about
the appearance of an orderly, careful, and fair process to
external communities [1].
G.10 The attention of the community and of the RFC Editor
should be explicitly called to the change in the last paragraph
of Section 9.2. There is a case to be made that requiring
"nothing is necessary" paragraphs can clutter up documents,
make them harder to read and understand, and set nasty
precedents.
------
Mostly editorial although some substantive issues are involved:
E.1 Section 2.3 paragraph 8 discusses the "it's not worth
doing..." problem. Similar issues can arise when outside
groups are convinced that the IETF is using the registration
approval process as a taste enforcement mechanism or other
barrier to entry rather than, e.g., a clear interoperability
issue. I believe the document should warn against that risk as
well, nothing that the general issue may affect "IESG Approval"
in Section 4.10 as well.
E.2 Section 3.4 ("Early Allocation") says "IANA normally takes
its actions when a document is approved for publication." It
should be more clear about what happens with FCFS and other
models where there is no document to be approved for
publication.
E.3 As indiretly mentioned in item G.4 above, the first
paragraph of Section 4.3 essentially claims that "Designated
Expert" is obsolete terminology. If is is, then Section 5
should be revised to reflect that. If it is not, then "in
earlier editions of this document" should be removed from 4.3
and the rest of 4.3 rationalized. More generally, there are
several situations in which terminology has changed over time.
While I think this "expert" example is the worst one, if they
cannot be fixed and rationalized, Section 1 might reasonably
contain a paragraph or table (as a separate subsection or part
of 1.3) that shows the relationship between old terms and new,
preferrec, terms.
E.4 There are a number of places where the document cites "the
period when RFC 2434 was in effect" or experience with or since
that document was published. Either they all need to be
reviewed in the light of what should be said about 5226 and
similar statements added about experience with 5226, or they
should be torn out and replaced by introductory material that
talks generically about experience and points to Section 13 of
the present document. That Section may need further review and
expansion when the inline references are removed.
E.5 Paragraph 4 of Section 1 would be easier to read and more
consistent with other comments in the document and above if the
second sentence of that paragraph read "This document defines
several frameworks...". If it is not an implicit reference to
Sections 3 and/or 4 and 5, the sentence should be clarified in
some other way, but it seems apparent to me that there is not
just one "framework".
E.6 One of the interesting issues in how an IANA Consideration
section is to be written is whether instructions to IANA should
be written in the future tense, as instructions, or whether
they should be written in the past, as if the instructions had
already been carried out. There have been an incident or two
in the past in which the first, especially in documents
updating others, has cause IANA to erroneously conclude that
they don't need to take action. I believe there have been a
few incidents in which the RFC Editor has failed to change
future tense to past after actions have been taken (and authors
have failed to catch the issues on AUTH48, perhaps because
nothing showed on on diffs). The IESG should be sure that
IANA and the RFC Editor have thought through this and are in
synch and then this document should make the desired model very
clear rather than expecting readers to deduce it from context.
Note the interaction between this topic and Section 8, which,
by the way, uses the future tense in its example.
E.7 Section 6, last sentence, should probably be expanded to
include other IETF actions, including the "IESG Approval" model
when RFCs are not involved.
E.8 This draft cites RFC 2119 but is inconsistent in the
extreme about whether terms like "SHOULD" and "MUST" are
capitalized, including in some cases that are clearly normative
requirements. The various cases (sic) should be carefully
examined, rationalized, and made consistent prior to
publication.
-------------
Notes:
[1} I share the concern of Eliot and others that, if we impose
more requirements on various elements of the process,
especially the Experts needed for Expert Review, volunteers may
become harder to find. However, especially in the current
politically-charged environment, claims of capricious behavior
or favoritism of organizations that provide significant support
of the IETF can be incredibly damaging. The defense against
such claims is careful, open, and well-documented decisions.
--------------
--john