Subject: Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

From: John C Klensin <[email-masked]>
Date: Tue, 31 May 2016 10:19:01 -0400

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
<[email-masked]> 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 [email-masked] mailing lists by
> 2016-05-17.
>...

---

From: Barry Leiba <[email-masked]>
Date: Tue, 31 May 2016 11:08:38 -0400

Hi, John.  Thanks for the review, and no worries that it's "late"; I'd
rather get this right.

I thought that what you're asking for is covered by very strongly
pressing for instructions/guidance to the designated expert(s), and
I'm very happy to expand that text to be more clear about some of the
variations that guidance might take.  I'd much prefer that to any
attempt at multiple versions of expert review, because I think that
any number of those we come up will will engender others that other
people will think of, and there'll be too many.

Rather, if we talk more about the things to consider in guiding the
DE, I think we'll be in a better place.  If you give me your opinion
on whether you think that's a good path and could resolve your
concern, I'll work on text to try out.

Barry

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 May 2016 12:09:08 -0400

--On Tuesday, May 31, 2016 11:08 -0400 Barry Leiba
<[email-masked]> wrote:

> Hi, John.  Thanks for the review, and no worries that it's
> "late"; I'd rather get this right.

Thanks.

> I thought that what you're asking for is covered by very
> strongly pressing for instructions/guidance to the designated
> expert(s), and I'm very happy to expand that text to be more
> clear about some of the variations that guidance might take.
> I'd much prefer that to any attempt at multiple versions of
> expert review, because I think that any number of those we
> come up will will engender others that other people will think
> of, and there'll be too many.
> 
> Rather, if we talk more about the things to consider in
> guiding the DE, I think we'll be in a better place.  If you
> give me your opinion on whether you think that's a good path
> and could resolve your concern, I'll work on text to try out.

I had thought about another category, perhaps Expert Review Type
1 and Expert Review Type 2 for two reasons.  One is that "expert
decides" is really different from "expert process advises in
getting an adequate specification together, but the final
decision to register lies with the applicant.  That is a little
like Expert Review, a little like Specification Required, but,
because the expert does not have the final word, is a bit like
FCFS as well.  Your section 4.12 covers alternative options
reasonably well (I'm trying to be careful about not letting a
desire for perfection block progress here) but not mixtures of
them.

The second is that I, and I know at least some others, have a
far too large collection of scars from situations in which a BCP
was issued on a "this is often helpful and you should do it
unless you have a reason to do something else and are clear what
you are doing" basis and then turned, a few years later, into a
rigid requirement that was inescapable in the absence of very
strong IETF consensus determined after an energy-sapping battle.
Prior versions of "Writing IANA Considerations..." and RFC 2119
have been the most obvious sets of guidelines treated that way,
but there have certainly been others.

Doing whatever is needed with better guidance to the Experts may
solve the first problem (but only if it can be made clear that
it is ok for WGs (or equivalent) to specify situations in which
the experts get to advise and persuade to the best of their
ability but have no (or extremely narrow) authority to reject
anything) but probably does not address the second, especially
in the presence of the very strong guidance about using one of
the listed methods I cited in my earlier note.

I'm happy to try to study -14 and suggest text, but it won't be
today.

best,
    john

---

From: Barry Leiba <[email-masked]>
Date: Tue, 31 May 2016 12:16:25 -0400

> I'm happy to try to study -14 and suggest text, but it won't be

Well, let me take a first pass at that.  I know what I'd like to say
about expert reviewer guidance, and I don't object to softening the
"you really ought to use these" language a little -- I think I can do
that while still maintaining what we already have rough consensus on.

Look for a -15, probably after Thursday's telechat.

Barry