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

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

On 3/27/15 7:54 AM, John C Klensin wrote:
>
>
> --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.

OK, that helps.

Most of the URN NID registrations to date have been processed in 
informational RFCs. I could see that continuing to some extent (since 
IMHO it's helpful to both registrants and reviewers if we write things 
up in the form of an I-D). I think part of the reason for this is that 
most of the registrations that I'm aware of have come from what we might 
loosely consider other SDOs - they're not defining standards track 
protocols (that just happen to be registering URN NIDs), but have their 
own standalone identifier space that might be used in some  protocol. 
And even one those less common occasions where they are defining a 
standards track protocol, the URN namespace is not directly part of that 
protocol - the example I'm most familiar with is XMPP, where the 
protocol was defined in RFC 3920 (now RFC 6120) whereas the URNs are 
used for extensions to the core protocol (RFC 4854).

>>> 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'm trying to figure out how common these cases might be. And I don't 
think it would be the IETF who decides that a duck is really a rabbit, 
it would be the biological community who decides that they need to make 
some tweaks to the definitions of an existing identifier space, or more 
likely to the namespace registration. IMHO we don't want to discourage 
people from fixing things (say, the biologists decide that there are 
some security concerns and want to update the URN NID registration).

In any case, the updated registration would also go through Expert 
Review so significant issues could be flagged at that point, no?

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

I'd be fine without that - I thought you had suggested it in your 
original note.

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

Although I agree that we want to avoid the sorts of scenarios you've 
outlined, I tend to think that it's less likely with URN NID 
registrations (see above about most requests coming from other SDOs) 
than it is with things like URI schemes.

However, building in some safeguards seems reasonable, as long as it 
doesn't unnecessarily complicate things for the vast majority of 
registrations.

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

Agreed.

Peter