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

John C Klensin <john-ietf@jck.com> Sun, 13 September 2015 17:51 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BDD1B56CD for <urn@ietfa.amsl.com>; Sun, 13 Sep 2015 10:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyU63oDBDAJO for <urn@ietfa.amsl.com>; Sun, 13 Sep 2015 10:51:05 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665811B56C8 for <urn@ietf.org>; Sun, 13 Sep 2015 10:51:05 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZbBQd-000NyX-QA for urn@ietf.org; Sun, 13 Sep 2015 13:51:03 -0400
Date: Sun, 13 Sep 2015 13:50:58 -0400
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <65C29163B6F527DF836969A9@JcK-HP8200.jck.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/oR6NYgd0QK0qWD_44kbIYH5_2Yc>
Subject: [urn] Approval process for new URNs based on non-IETF standards
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Sep 2015 17:51:07 -0000

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