Apologies for this coming in at the last minute, but the volume
level on the IETF list about unrelated issues (mostly the IETF
100 issues) and some other priority topics have prevented me
(and possibly others) to give this document the attention it
deserves or noticing that the nominal cutoff had come and gone.
I note the Gen-Art review showed up after 17 May, so probably
others are suffering from the same problem.
This is an old and much-reviewed document. It has undergone
significant refinement with each iteration. I think many of us
who have been too busy to do active reviews in this round have
proceeded on the assumption that issues raised in prior
reviews/Last Calls have been addressed.
Unfortunately, based on very quick skimming, at least one
important one -- IIR discussed at some length earlier -- has not
been reflected (at least in -13). I have no idea whether that
reflects a more general problem. The issue is the possibility
of a 13th well-known policy, especially in combination with the
"not strictly required... strongly recommended ... not without
good reason and explanation" language. The latter is only a
half-step away from a rigid "have to pick one of these" policy,
with that step historically taking the form of a single AD
saying "you haven't proven that none of these options will work
to my satisfaction" and then insisting on it. Because we've got
counterexamples, that is a bad way to set standards.
The specific cases I have in mind involve expert review and
parameters that have a way of becoming controversial, in part
because having two values that are really approximations of the
same thing can be (for those parameters) confusing and
destructive or when the role of the expert is really to advise
on getting the right information into the registrations rather
than deciding whether a registration is acceptable or not. For
either of those situations, a single designated expert-Tsar may
not be appropriate. If the person is hyper-responsible and
extremely knowledgeable, the stress and blame levels are likely
to get too high. If not, well, appeals are an undesirable way
to resolve registration disputes, not only because of the time
and resources they take but because some (many?) registrants are
likely to decide that code point squatting is a better model
than working through the IETF process.
Recommendation: Either create another option that recognizes the
many flavors of expert review, including the possibility of
teams who are required to reach at least rough consensus or
soften the "use these unless you can prove otherwise" language
cited above to make it clear that there are likely to be
variations on a few of these approaches, notably Expert Review,
that, if well-documented and reasonably well-justified, are
still considered within the scope of that category and
conforming/ consistent with the document and its recommendations.
Again, essentially these same comments have been made in Last
Calls on earlier versions of this document and are hence part of
the record the IESG should be considering.
Again, sorry to be flagging this, and reminding people of the
earlier discussions, at such a late date.
best,
john
--On Tuesday, April 19, 2016 07:16 -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-12.txt> as Best
> Current Practice
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the ietf@xxxxxxxx mailing lists by
> 2016-05-17.
>...