Re: [urn] Expert reveiw and draft-ietf-urnbis-rfc2141bis-urn-09

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

--On Thursday, March 26, 2015 21:03 -0600 Peter Saint-Andre -
&yet <[e-mail]> wrote:

> On 3/4/15 8:16 AM, John C Klensin wrote:
>> We agreed some time ago that URN registrations for Formal
>> namespaces and their NIDs should be shifted from IETF
>> Consensus (see Section 4.3 of RFC 3406) to Expert Review and
>> that Expert Review should apply to Informal Namespaces as
>> well.
> 
> Although I don't recall a decision to use Expert Review for
> informal namespaces, I think it makes sense for both formal
> and informal namespaces to use the same procedure. (Recent
> discussion on the [e-mail] list indicates that this is
> important.)

Ack.

>> There has been some discussion in the WG (and the IETF more
>> generally) about issues with registration Expert Review,
>> especially for registrations that are expected to be reflected
>> in standards track documents.
> 
> I'm not sure what the criteria are for saying that certain
> registrations are "expected to be reflected in standards track
> documents" (only within the Internet Standards Process?)
> whereas others are not.

I think it is a matter of registrant intent.  Someone who uses
the Expert Review registration process to create an NID and bind
it to a namespace definition should not then submit an I-D
asking for standards-track status.  More specifically, if such
an I-D is submitted and, when IETF discussions starts, the
registrant says "already registered, can't make technical
changes", any RFC publication has to be an Informational spec
that describes what is registered, not a standards-track
document.    I can imagine an exception in which the registrant
(or someone else) comes back a few years later and says "this
thing that was registered earlier has been widely deployed, has
proven useful and to not cause any problems, please
standardize", but that is a different situation -- and, because
there would be little value added, one I'd expect to be
exercised about as often as we move documents to full standard
(or less often) whether the effort at that time was to process a
new document or reclassify an existing one.

>> Some of that discussion is hinted
>> at in draft-ietf-urnbis-ns-reg-transition, but it has not yet
>> been reflected in 2141bis.
>> 
>> For those who have not followed the other discussion, one key
>> problem is that, if something is registered with particular
>> properties and specifications and then the authors want to
>> standardize the technology, the IETF is told that discussion
>> of design choices is out of order because the registration
>> cannot be changed.  That is, I hope obviously, bad news.
> 
> True. However, it seems to me that this can be handled by
> allowing versioning of registrations.

Except that, if there is _any_ deployment in places that are
hard to change, and the IETF decides that, e.g., what the
registration describes as a duck is really a rabbit, a
registration change is likely to cause interoperability
problems.   We could adopt some new rules that would encourage
NIDs that look like "john.20150327a" and give special
interpretations to the relationship between it and
"john.20150327b" and "john.20150401" but I don't think we want
to go there... and that registrants would probably not take
advantage of it if we did.

>> I think we are headed in the following direction, but want to
>> get confirmation (or corrections) from the WG before Peter
>> and I start struggling with draft text:
>> 
>> (1) We want Expert Review, with the guidance that now appears
>> in Sections 7 and 9, for namespaces that are not intended to
>> be standardized in/by the IETF.
>> 
>> (2) For namespaces intended for standardization, IETF
>> Consensus is necessary for registration although a
>> preliminary expert review may be helpful.
>> 
>> (3) While namespaces that are essentially overlays on
>> identifier standards produced and managed by other standards
>> bodies, the Expert Review process is intended more as an
>> advisory and coordination on rather than one or acceptance or
>> rejection and some sort of "fast track" procedure (and/or
>> even a different review process) may be in order.  I would
>> hope we can explicitly give the IESG some flexibility in
>> those situations rather than having to spell everything out
>> in 2141bis.
>> 
>> (4) For namespaces that do not fall into categories (2) or
>> (3), we have a strong preference for registration, even
>> poor-quality registrations that only assure uniqueness of
>> NIDs, over a slow and/or onerous registration approval
>> process that encourages use of names without registration.
> 
> In my ignorance of the aforementioned criteria for expecting a
> registration to be reflected in a standards track document, I
> would suggest the following somewhat simplified set of
> principles:
> 
> 1. The registration policy is always Expert Review.
> 
> 2. It is preferred for each registration request to be
> accompanied by a stable specification.
> 
> 3. If such a specification is on the standards track within
> the IETF, then the specification (but not the registration)
> requires IETF consensus. (It might be appropriate to register
> the namespace in a preliminary fashion before publication of
> the specification.)

I'm not sure I know what "register in a preliminary fashion"
means.  Again, the case I'm most concerned about is one with
which we've got significant (bad) experience in other types of
namespace registrations.   It goes like:

 (i) Application is submitted for a registration using
	the template.
 (ii) Because the Expert Review and special mailing list
	typically consists of a small group of people talking
	with each other, a possibly-significant issue is not
	noticed and the application is registered.
 (iii) Applicant submits an I-D describing the
	registration and asking for publication and standards
	track status. 
 (iv) For one reason or another, the IETF doesn't do a
	Last Call for an extended period.  During that time, the
	I-D is updated several times to improve the description,
	but without making substantive changes.
 (v) The applicant community starts using the system or
	namespace as registered, achieving significant
	deployment.
 (vi) The IETF review process turns up technical
	deficiencies (or even just some improvements that might
	be made) that some people believe are significant.
 (vii) The applicant says "even if you are right, the
	name and namespace are registered and in use at this
	point, so cannot be changed".
 (viii) The IETF is then stuck and so is the applicant.
	Either we decide that standardization provides no
	marginal value and public the I-D as Informational (see,
	e.g., the recent publication approval for a DNS URI
	RRTYPE) or a standards track document is approved
	despite know technical deficiencies because the IESG
	decides those deficiencies are not sufficiently
	important to be blocking.

Note that the above does not assume any malice or deliberate
attempt to commit an end run of the standardization process
(although I believe we have seen examples of that too).  And
that is the point.  If someone is going to ask for
standardization, the process needs to be more like:

 (i) Development of a first-draft I-D that contains the
	filled-in template in IANA Considerations, not just the
	template itself.
 (ii) Submission, registration discussion mailing list,
	and expert review of the I-D, resulting in a report and
	recommendation to the IETF, not registration.  This
	review is likely to catch most serious problems early
	and presumably guarantees that someone takes a careful
	look at both template and specification.
 (iii) Submission of the I-D for IETF review and Last
	Call with the Expert Review report made available to the
	community and treated as a Shepherd report or supplement
	to one.
 (iv) Normal IETF processing, including possible changes
	to the I-D and template.
 (v) Registration as part of the usual approval and
	publication process.

An assumption in the above distinction is that the IETF
standardization process adds value in the review process.  If it
is just a stamp of approval and endorsement... well, a lot of us
are wasting out time here.  But, if the value is really in the
standardization process itself, than someone who asks for
standards track status probably wants the more extensive review
even (or especially) if it changes the spec or template
namespace definition.

Now, it seems to me that reserving the name from when the
process is started to when it concludes (successfully or not)
would be helpful.  But a name that goes into the conventional
Expert Review and spends some time there is also de facto
reserved during the process because the Expert would presumably
reject an NID application (or encourage applicants to sort it
out) if a registration request for the same NID is already being
considered, so I don't see a need for a special procedure, much
less IANA registration of any sort, to avoid the obvious bad
case.

> 4. Registrations can be modified by submitting a revised
> version of the completed template.

Same problem as above.  If the namespace is established by
registration (with or without a stable spec that might be an
Informational RFC), then any stability or compatibility issues
between older and newer versions are the responsibility of the
registrant (the revised template rules in the draft requires
that they explain what they are).  But, if the namespace is
specified in a standards-track document, a revision is an IETF
concern and the registration should be modified only by an
approved, standards-track, RFC or, for obvious errors, an
IESG-approved erratum.

     john