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

[Peter Saint-Andre <[e-mail]>]

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

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.
> 
> To oversimplify, "expert review" seems to be designed for a
> situation in which the expert is basically performing an
> extended sanity check -- are all of the bits of the template
> complete and do they satisfy the rules, does the applicant
> understand what they are asking for, and so on.
> 
> What the URN discussions seem to highlight is that a few
> enhanced requirements would be desirable in some cases, e.g.,
> 
> (i) The "expert" has a significant tutorial role, not just a
> passive registration-checking one.  Of course, for some
> registries, that role is served by requirements for submission
> to a mailing list.

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.

> (ii) There is enough going on in some registries and the
> applications used to get entries into them, that it is better to
> have an expert team who can examine an application from
> different points of view and discuss it among themselves as well
> as with the applicant.   That would be rather more like a design
> team than like a shared expert job where two or more people
> alternate reviews.  This idea of an "expert team" could be
> considered a variation on the "consultation with a set of
> technology experts" or "multiple designated experts... work[ing]
> together in evaluating a request",described in Section 3.2 of
> 5526, but would make all of the members of that team accountable
> to IANA and the community.
> 
> (iii) Especially for URNs and probably for some other things,
> requirements for persistence and stability put a real premium on
> high-quality and stable documentation.  There are good reasons
> to not move to "Specification Required", but equally good
> reasons to strongly encourage such specifications, possibly
> including "provide document or explain why not" provisions in
> templates.  That obviously puts some additional burden on the
> expert process to try to cajole the document(s) into existence
> or to approve the exception.
> 
> (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.

> In several cases, the right text for expert review appears in
> Sections 3.1 and 3.2, but the "Expert Review" definition in
> Section 4.1 doesn't explicitly incorporate the relevant parts of
> those sections or treat them as options that may be specified.
> 
> My reading of 5226 is that it just provides convenient templates
> and that all of the above are allowed by putting the right words
> into an IANA Considerations section.    There have been problems
> before when some IESG member has trying to treat the categories
> as normative with only a choice among them (it is easy to read
> support for that view into statements like "...guidelines for
> authors on the specific text that must be included..." in the
> 5226 abstract), but I hope those days are over.
> 
> 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).

> 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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/