IETF Logo Mail Archive

Re: [urn] NID registration policy (was: Re: Fwd: New Version Notification for draft-blanchet-urn-ianachange-00.txt)

Marc Blanchet <marc.blanchet@viagenie.ca> Wed, 31 July 2013 12:43 UTC

Return-Path: <marc.blanchet@viagenie.ca>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078CF21F9F4F for <urn@ietfa.amsl.com>; Wed, 31 Jul 2013 05:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrMhQW-DaKcu for <urn@ietfa.amsl.com>; Wed, 31 Jul 2013 05:43:11 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7321F9EED for <urn@ietf.org>; Wed, 31 Jul 2013 05:43:11 -0700 (PDT)
Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 780B0403CF; Wed, 31 Jul 2013 08:43:10 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <51F90556.5020205@stpeter.im>
Date: Wed, 31 Jul 2013 14:43:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3DCA5279-6E44-48EE-BB64-6F3C3C91AB8C@viagenie.ca>
References: <20130731115043.24006.31384.idtracker@ietfa.amsl.com> <2D26CCA9-73B8-4F29-8AA9-25A11C824AD0@viagenie.ca> <51F90556.5020205@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1508)
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] NID registration policy (was: Re: Fwd: New Version Notification for draft-blanchet-urn-ianachange-00.txt)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 31 Jul 2013 12:43:13 -0000

Le 2013-07-31 à 14:38, Peter Saint-Andre <stpeter@stpeter.im> a écrit :

> On 7/31/13 1:55 PM, Marc Blanchet wrote:
> 
>> making
>> registration of urn formal namespace much less burden on IESG by having
>> Expert review.  
> 
> We will discuss this on Friday, but here are some considerations:
> 
> The current RFC 5226 policy ("IETF Consensus") requires publication of
> an RFC that is approved for publication by the IESG. This means that an
> Area Director needs to sponsor it, it needs to undergo IETF Last Call, etc.
> 
> A less restrictive policy would be "RFC Required". This means that
> someone could, for instance, publish an RFC through the Independent
> Submissions stream, see https://www.rfc-editor.org/indsubs.html
> 
> An even less restrictive policy would be "Specfication Required", which
> means that someone could publish a document via some other standards
> development organization (or even a stable website - the rules are a bit
> fuzzy).
> 
> A yet more loose policy would be "Expert Review", which in practice
> means that someone would simply need to send a completed template to the
> urn-nid@ietf.org list.

In some ways, "Specification Required" may be more loose than Expert Review, because if the requestor "just" point to a "dumb" specification, then he may get the assignment. i.e. the existence of the specification does not mean you know what you are doing... (well, we can spin off a discussion on that statement, but that is not the point).

So I'm in favor of "expert review", lightweight, that would have knowledge to verify that the requestor know what he is doing.  The template (the other topic) shall contain a request to URL to a document from the requestor about the usage they intend to do with the URN.  So this way, there is also an "hidden Specification Required".

Marc.

> 
> In any case, I think we need to provide guidelines to reviewers (since
> in all cases review happens on the urn-nid list). Here is a document
> that provides similar guidelines for another IANA registry:
> 
> https://datatracker.ietf.org/doc/draft-ietf-ipfix-ie-doctors/
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/

v2.23.0 | Report a Bug | By Email