> 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@xxxxxxx> wrote: > > > --On Tuesday, May 31, 2016 11:08 -0400 Barry Leiba > <barryleiba@xxxxxxxxxxxx> 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 > >