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

Peter Saint-Andre - &yet <peter@andyet.net> Sun, 13 September 2015 22:15 UTC

Return-Path: <peter@andyet.net>
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 314891A1BB8 for <urn@ietfa.amsl.com>; Sun, 13 Sep 2015 15:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 l6HfBoOJx-Nh for <urn@ietfa.amsl.com>; Sun, 13 Sep 2015 15:15:38 -0700 (PDT)
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285941A8869 for <urn@ietf.org>; Sun, 13 Sep 2015 15:15:38 -0700 (PDT)
Received: by ioii196 with SMTP id i196so147789061ioi.3 for <urn@ietf.org>; Sun, 13 Sep 2015 15:15:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=WO08hw24tY2SHVZcSOLXIXZoiI5oTadPklG+vG53hMI=; b=KZRpEwPbQIpxp7h7YG6b6L+Qsbg8xFG/T7NObfI9FGZrtdBKPEpcXFnmrSnxlzH9sl XkuRGfdZBKgWH/uL4Y1d7sMtT5BbLRZGevPsRFHq+eTcN/yacsY9UPuh6GX+g29vij8/ ouo62Jnl0zboVkog7SyJ3UmJtA+/pRRYS8FZ+hOQqTARSDDJiURlUypoXgN/Ud/g8O6Q QzJVyUVRPUlkgWhtgh6zlelsN/3GKrHAbUgZREYi6daGH0jFQC7Ki4ZngfMOZl0J49F8 JNubjI343qK+E6Kn1YP0yuGdZXRnMwOEkJKna9kz/Kac7b2PgcvYJW/XRRU4YjdFVTAJ pENw==
X-Gm-Message-State: ALoCoQna27UTbbFXLPEqdVjroiyfWD3YWSI/DKA0yLexcagsdLBhPL9YJ0pyu18FGXpC5gZG6uNb
X-Received: by 10.107.164.201 with SMTP id d70mr20735411ioj.127.1442182537429; Sun, 13 Sep 2015 15:15:37 -0700 (PDT)
Received: from aither.local ([2601:282:4201:ef5b:84b7:bca2:8957:b371]) by smtp.googlemail.com with ESMTPSA id hh9sm4359875igb.18.2015.09.13.15.15.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Sep 2015 15:15:36 -0700 (PDT)
To: John C Klensin <john-ietf@jck.com>, urn@ietf.org
References: <65C29163B6F527DF836969A9@JcK-HP8200.jck.com>
From: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <55F5F587.2060207@andyet.net>
Date: Sun, 13 Sep 2015 16:15:35 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <65C29163B6F527DF836969A9@JcK-HP8200.jck.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/mYtA8iqjYaF3dogAJ9dv_E6ads0>
Subject: Re: [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 22:15:40 -0000

On 9/13/15 11:50 AM, John C Klensin wrote:
> 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

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

> (or equivalent, if Peter
> gets -13 finished before agreement is reached on this):

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

>    -----------
>
> (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:

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?

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

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

Peter

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