Subject: [urn] Approval process for new URNs based on non-IETF standards

From: John C Klensin <[email-masked]>
Date: Sun, 13 Sep 2015 13:50:58 -0400

Hi.
A recent request to register a URN associated with an external
standard involving a scientific community whose work lies well
outside the normal scope and expertise of the IETF brought up an
issue that I think we briefly discussed on-list but that never
made it into 2141bis.  The current particular issue involves
draft-blanchet-ccsds-urn-00.txt (A Uniform Resource Name (URN)
Namespace for the Consultative Committee for Space Data Systems
(CCSDS)) about which Barry wrote the WG earlier today.  

In the most general scenario of interest, a URN registration
request arrives from some specialized scientific or professional
community.  The IETF, and experts it designates, are generally
not in a good position to evaluate the request on the basis of
its subject matter.  We might offer advice about formats or
URN-specific issues but, ultimately, the right place to make the
decisions about the substantive matters and any tradeoffs is in
the relevant community, not the IETF.   Unfortunately, lack of
knowledge has never prevented the IETF community from having
opinions and expressing them loudly.  That can lead to
frustration and impatience on the part of the submitting
organization, reactions that, in turn, tend to discourage
registrations.

We encountered a similar issue in thinking about media types and
developed the idea of delegating most of the responsibility in
such situations to "recognized standards-related organization"
(see Section 3.1 of RFC 6838 for the current version, but
variations on the idea go back many years).  Adapting that model
to URNs seems wise to me.

If there is agreement about that as a principle, I suggest we
make approximately the following changes to Section 7 or
draft-ietf-urnbis-rfc2141bis-urn-12 (or equivalent, if Peter
gets -13 finished before agreement is reached on this):

  -----------

(1) At the end of Section 7.1, add:

	"While the registration templates are the same, slightly
	different procedures are used depending on the source of
	the registration."

(2) Change the title of Section 7.2 to "Registration Policy and
Process: Community Registrations".

(3) Add a new Section 7.3, titled "Registration Policy and
Process: Fast Track for Recognized Standards Development
Organizations and Scientific Societies" that reads:

	The IETF recognizes that situations will arise in which
	URN namespaces will be created to either embed existing
	and established standards or to reflect scientific
	knowledge, terminology, or information organization that
	lie well outside the IETF's scope or the likely subject
	matter knowledge of its Designated Experts.  In
	situations in which the registration request originates
	from, or is authorized by, a recognized
	standards-related organization or scientific society, a
	somewhat different procedure is available at the option
	of that body:
	
	1.  The namespace registration template is filled out
	and submitted as in steps 1 and 2 above.
	
	2. A specification is required that reflects of points
	to the needed external standards or specifications.
	Publication in the RFC Series or through an IETF process
	(e.g., posting as an Internet Draft) is not expected and
	would be appropriate only under very unusual
	circumstances.
	
	3.  The reviews on the discussion list and by the
	designated experts are, however, strictly advisory, with
	the decisions about what advice to accept and the length
	of time to allocate to the process strictly under the
	control of the external body.
	
	4.  When that body concludes that the application is
	sufficiently mature, they will request that IANA will
	complete the registration for the NID and IANA will do
	so.
	
	A similar model is available for recognized
	standards-related organizations registering Media Types.
	The document describing that mechanism [RFC6838]
	provides somewhat more information about the general
	concept.

(4) Renumber Section 7.3 and its subsections as appropriate.

(5) Add the following sentence to Section A.4:

If the registrant is a recognized standards development
organization or scientific society requesting the fact track
registration procedure (See Section 7.3), that information
should be clearly indicated in this section of the template.

  -----------

If this model is adopted, draft-ietf-urnbis-ns-reg-transition
will probably need some tuning but we can deal with that when
appropriate.

    john

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Sun, 13 Sep 2015 16:15:35 -0600

On 9/13/15 11:50 AM, John C Klensin wrote:
> draft-ietf-urnbis-rfc2141bis-urn-12

Something along the lines of what you propose seems reasonable to me.

> (or equivalent, if Peter

My goal is to get -13 published by the end of this week (i.e., September 
18th).

I have two concerns about "scientific societies":

1. The IETF has experience in judging when another organization is an 
SDO, but not in judging when it is a scientific society.

2. It seems to me that the realm of organizations that might deserve to 
be on the fast track is not limited to scientific ones. What about 
organizations whose purpose is cultural (e.g., the British Museum), 
scholarly (e.g., the London Philological Society), educational (e.g., 
TERENA - see RFC 6338), governmental (e.g., the United Nations), 
military (e.g., NATO), charitable (e.g., Creative Commons), professional 
(various industry consortia), and so on?

> should be clearly indicated in this section of the template.

Aside from the questions I raise above, this model seems reasonable to me.

Peter

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

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 15 Sep 2015 15:35:53 +0900

Hello John, others,

> gets -13 finished before agreement is reached on this):

I agree with Peter that in general, this is reasonable.

Why not simply say "is not necessary".

> 	control of the external body.

I agree that this should be the case for the content aspect of the 
request (what stuff is given URNs,...), but I think we should make 
extremely clear that the overall syntactic restrictions that the spec 
makes are not up for negotiation or reinterpretation.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Tue, 15 Sep 2015 10:04:33 -0400

Hi.

I'm responding to Martin's note as a convenience, but some
things below address Peter's comment and a brief offlist
conversation.

--On Tuesday, September 15, 2015 15:35 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

>...

This is mostly a textual matter and I don't feel strongly about
it one way or the other.  FWIW, what I was thinking when I wrote
the above was that, in general, when we are dealing with other
bodies that have their own approval and publication procedures,
we let them finish whatever they are doing and publish and we
then either reference their publication or work our permission
to republish in the RFC Series.  The disadvantage of having an
I-D posted and considered in the IETF is that the risks of
inconsistent specifications resulting from two groups tuning
things in different directions and creating inconsistencies are
significant (especially if the IETF community starts making
modifications it may not understand to documents it doesn't
understand, which was exactly the case that the Media Types
mechanism and this proposal were intended to bypass).

But, while that was my reasoning and the answer to "why not", I
again don't feel strongly about this so, if others prefer "not
necessary", go for it (although a sentence about understanding
the consequences or being clear about change control would seem
useful).

> I agree that this should be the case for the content aspect of
> the request (what stuff is given URNs,...), but I think we
> should make extremely clear that the overall syntactic
> restrictions that the spec makes are not up for negotiation or
> reinterpretation.

While I agree, my usual concerns about the protocol police and
the advantages of having even bad stuff registered and known
kick in.  So the WG has a choice that applies to both this fact
track case and the normal one:  Assume some organization decides
that it is going to use something that looks like a URN (e.g.,
something that looks like a URI starts with "urn:") but that
violates "overall syntactic restrictions", design assumptions,
or something else fundamental.  If we cannot convince them to
not do that, is the Internet better off with a registration that
can identify the non-conforming use or not registering it at all
but hoping that no one will use or notice it (or that our
condemnation through silence will prevent its use).   

At the moment, my instinct says that we are better off with the
documentation, even if it means creating an extra section of the
registry or a registration category for non-conforming names and
namespaces just to reduce the odds or name conflicts and
identify the uses.  I think the Internet is better off that way
than if we try to pretend the usage doesn't exist.

None of that suggests that we should be willing to negotiate or
reinterpret.  The question is only about what we do if, e.g.,
someone has a namespace and syntax that uses "#" as an
introducer that has absolutely nothing to do with the 3986
requirements for fragments.

Noting that exactly the same question applies to non-conforming
URI schemes as to non-conforming URN namespaces, I don't feel
strongly about this or feel a need to spend a lot of time on it
because I think that the number of cases in which someone will
come forward and say "I have this namespace and URN syntax for
it that violates a bunch of your rules but want to register it
with you anyway" will be very few, maybe few enough to be safely
ignored.  However, if we are going to make strong statements
about what people cannot do, I think we need to understand and
should consider the issue.

--On Sunday, September 13, 2015 16:15 -0600 Peter Saint-Andre -
&yet <[email-masked]> wrote:

> 1. The IETF has experience in judging when another
> organization is an SDO, but not in judging when it is a
> scientific society.

I'm not in a good position to debate "experience", but note that
"scientific societies" were explicitly recognized a decade ago
in RFC 4288.  FWIW, while we have never formalized a
relationship or, AFAIK, even seriously discussed doing so, but,
for those who don't know, there is a body known as the
International Council of Scientific Unions (ICSU) whose
membership (and the membership of its their subsidiaries and
ICSU formal affiliates) comes fairly close to an authoritative
list.   In that sense, "scientific societies" may actually be
easier to make objective judgments about than SDOs where, for
example, the boundaries between "trade association", "industry
consortium", and "SDO" may get very subjective and difficult to
evaluate fairly.  But see below.

> 2. It seems to me that the realm of organizations that might
> deserve to be on the fast track is not limited to scientific
> ones. What about organizations whose purpose is cultural
> (e.g., the British Museum), scholarly (e.g., the London
> Philological Society), educational (e.g., TERENA - see RFC
> 6338), governmental (e.g., the United Nations), military
> (e.g., NATO), charitable (e.g., Creative Commons),
> professional (various industry consortia), and so on?

What we did in RFC 4288 and the later 6838 was to leave
"recognized" completely in the hands of the IESG without even
trying to spell out criteria.  In a way, that turns the
criterion into "are you, IESG, willing to trust this body
sufficiently to give up some authority to it".  In the media
types case, I don't believe that there has ever been controversy
about the decisions the IESG has made.  Neither the IESG nor the
community have felt the need for a formal application procedure
for someone to be recognized as a standards body (or whatever).
I take those as good signs and suggest that it would be wiser to
say, perhaps, "recognized SDOs, scientific societies, and
similar bodies" and then drop the subject in 2141bis, leaving it
to the IESG to figure out what to "recognize" and what
constitutes "similar".

FWIW, some notes about Peter's "what about" list.  Picking the
first example and based on discussions in other contexts, the
British Museum is _very_ unlikely to try to create or register
something that has broad international or long-term implications
as an individual initiative.  They are historically much more
likely to take the idea to an international industry association
(perhaps ICOM), UN body (UNESCO or ECOSOC more generally), or
someone we would almost certainly recognize as a standards body
(like ISO TC 46).    So that may be a non-problem.  Conversely,
one of the reasons I want to pass this to the IESG rather than
trying to lay out lists of bodies or even specific
guidelines/criteria, while the British Museum would be fine
_and_ is unlikely to generate a direct, single-organization,
request, I suspect we would be less enthused about waiving
expert review, etc., for the National Museum of Lower Slobbovia
or, given recent events, the Caliphate Museum Authority of
Palmyra.  

The idea of picking a list (or an organization that keeps a
list) rather than having the IETF try to figure one out on a
case-by-case basis has a very long tradition with IANA, long
before ICANN.  Country-code TLDs would not exist, at least in
the form we know them, had Jon not found ISO 3166 and been able
to use it an authoritative list of both entities who would
qualify and the codes to be used -- he felt that having IANA try
to figure out what was or was not a "country" or how its name
should be code would quickly lead to madness.  A few other TLDs
with global scope would have been created had their proponents
been able to come up with an authoritative, generally recognized
and accepted list of second level eligibility.  It probably
doesn't apply here and would presumably be part of a hint to the
IESG anyway, but use of ICSU membership and their subsidiaries
and affiliates could be the basis for a similar
externally-generated and maintained list if that were needed.
Probably worth keeping the principle in mind.

    john

[1]