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(_at_)jck(_dot_)com>
wrote:
--On Tuesday, May 31, 2016 11:08 -0400 Barry Leiba
<barryleiba(_at_)computer(_dot_)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