[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Consideratio
From:       Barry Leiba <barryleiba () computer ! org>
Date:       2016-05-31 16:16:25
Message-ID: CAC4RtVAfots-C5JVg-vVMeYiXjFHV1P-x+kudHCqScG8j-cJfQ () mail ! gmail ! com
[Download RAW message or body]

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

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

On Tue, May 31, 2016 at 12:09 PM, John C Klensin <john-ietf@jck.com> wrote:
>
>
> --On Tuesday, May 31, 2016 11:08 -0400 Barry Leiba
> <barryleiba@computer.org> 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
>
>

[prev in list] [next in list] [prev in thread] [next in thread]