Re: [urn] RFC 5226 and enhanced versions of "expert review"

[John C Klensin <[e-mail]>]

--On Monday, August 12, 2013 13:13 -0600 Peter Saint-Andre
<[e-mail]> wrote:

> Hi John, thank you for pursuing this topic. I agree with most
> everything you've written here. A few comments inline.

Sorry it has taken me so long to get back to you.  Proposed
specific text for a new Section 7 (with appropriate renumbering)
is attached.  It requires some small editorial cleanups as well
-- I'm sending you XML for everything I caught in the hope that,
if you and the WG like the text, this can just be merged modulo
whatever editorial work you decide to do on my first-draft
writing style.

Those reading the attached should note that I've made several
decisions in the direction of keeping this as process-light as
possible, deferring several types of decisions to the IESG,
IANA, the expert team, or otherwise.  My hope in doing so is
that we can end up with as much process as needed and no more
and that, where possible, small process adjustments can be made
as needed without having to either open or ignore this document.

A few comments and an additional suggestion or two below (with
lots of earlier text elided).

> On 8/10/13 3:46 AM, John C Klensin wrote:
>> Hi.
>> 
>> Recent discussions and tentative decisions in the URN WG point
>> to a sort of enhancement or fork in the way I (and I think
>> others) have traditionally understood the "expert review"
>> section of RFC 5226.
>...
> As you are well aware, some tutoring does happen on some of
> the existing lists (say, URI scheme registrations), but it is
> less intensive than what we foresee for URN namespace
> registrations.

I've used "mutual education" in the proposed text for two
reasons: unlike "tutoring", it cannot be interpreted as
pejorative and I actually expect that the subject matter and
namespace experts will educate the IETF-designated ones as much
as vice versa.  I hope the desired level of intensiveness comes
across.

>...
>> (iv) RFC 5226 provides that an expert review is conducted in
>> accordance with "review criteria as documented with the
>> protocol" (Section 3.2), but does not contain an explicit
>> statement that such advice to the expert(s) as to what to
>> review and consider, what the conditions are for rejection,
>> etc., SHOULD be part of any document that specifies "expert
>> review". Relying one the generic criteria in Section 3.2 is
>> really not desirable nor is the statement about "required
>> documentation and review criteria" in Section 4.1.   To be
>> clear, that is "SHOULD" in the "do it it or explain why now"
>> sense.
> 
> In Berlin, Michelle Cotton pointed me to an I-D that provides
> more detailed instructions for reviewers related to a
> particular registry:
> 
> https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/
> 
> So there is precedent for doing something beyond just pointing
> to the buckets in RFC 5226.

There is _lots_ of precedent.  The only issue is whether a stink
arises on either IETF LC or in the IESG.  I guess we will have
to deal with those problems if they arise.

>...
>> So, a question:
>> 
>> Does Peter simply incorporate the URN version of the above
>> into 3406bis with a little textual help from me (if he wants
>> or needs it)?  Or do I spin up a short I-D that provides an
>> update to 5226 that explicitly adds an enhanced version of
>> expert review with the above as additional options?  A third
>> possibility is to do this as an exceptional case for URNs,
>> then treat the URN case as a sort of process experiment (one
>> that does not require 3933) to justify a 5226 update somewhat
>> later.
> 
> Given the IPFIX example cited above, I think we can make the
> guidelines in 3406bis more detailed than what's provided in
> RFC 5226 (i.e., your first option).

Proposed text attached, as noted above.   Putting it in required
tuning elsewhere and I've taken a shot at that.  But it is
editorial, rather than substantive, so it is probably best that
the WG look at it in context with whatever changes Peter is
making.

Added high-level suggestion:

I have not tried to fix (or otherwise modify) the template other
than to tentatively adjust an introductory sentence and add
"this item is required" sentences to the first three items.   I
do suggest that you remove as much discussion as to how specific
subsections should be filled in to Section 6 (or elsewhere).
That would have two advantages.   First, if the template itself
runs three or four pages, it will be perceived as long, complex,
and hard to complete no matter what is actually there.  If we
want to bias things toward getting more namespaces that are in
use registered, we should minimize that perception.  Second,
there is enough information in the non-template parts of this
document that, if someone who wants to submit a registration has
to read it, that would be A Good Thing.

>> p.s. If an update to 5226 is prepared, there are a few other
>> glitches that ought to be fixed or patched.  For example, 5226
>> explicitly contemplates creation of a registry by an
>> independent submission RFC.  But it says that all designated
>> experts are appointed by the IESG.  It is not hard to imagine
>> that, as we continue to open things up, a registry would be
>> created via an ISE process (or via the IAB or IRTF stream)
>> for which the IESG should not be the appointment body because
>> there is no "relevant Area Director" and the IESG lacks any
>> expertise to figure out who is and is not expert.  So, IMO,
>> 5226upd should, first, suggest that registry-creating
>> documents specify selection criteria for experts and, second,
>> make IESG appointments simply an option for registries
>> created by other than IETF processes. Perhaps some IESG
>> advice and consent model would be appropriate for the latter,
>> but that is probably as far as it is reasonable to go.
>> 
>> Note that the above may also require small adjustments to
>> statements about removing experts and who settles deadlocks
>> and deals with non-responsive experts.  Because an RFC is
>> required to create a registry, "stream manager" language may
>> be appropriate.
> 
> IMHO that's excellent input for
> draft-leiba-cotton-iana-5226bis, which was last updated very
> recently.

Ack.  Barry, consider yourself provided with input and pass
along as appropriate.

best,
   john