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

[Barry Leiba <[e-mail]>]

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

On Tue, May 31, 2016 at 10:19 AM, John C Klensin <[e-mail]> wrote:
> 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
> <[e-mail]> 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 [e-mail] mailing lists by
>> 2016-05-17.
>>...
>