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

From: John C Klensin <[email-masked]>
Date: Wed, 04 Mar 2015 10:16:44 -0500

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.

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

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.

Does that about cover it?  Does anyone want to suggest text?

     john

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 26 Mar 2015 21:03:54 -0600

> 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 
[email-masked] list indicates that this is important.)

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

> Some of that discussion is hinted

True. However, it seems to me that this can be handled by allowing 
versioning of registrations.

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

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

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 Mar 2015 09:54:54 -0400

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

>> 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 [email-masked] list indicates that this is
> important.)

Ack.

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

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

>> 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.
> 
> registration to be reflected in a standards track document, I
> would suggest the following somewhat simplified set of
> principles:
> 
> 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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 27 Mar 2015 10:37:36 -0600

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

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

> 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

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.

> approved, standards-track, RFC or, for obvious errors, an

Agreed.

Peter