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

Peter Saint-Andre - &yet <peter@andyet.net> Fri, 27 March 2015 03:04 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 0D1D31A90B2 for <urn@ietfa.amsl.com>; Thu, 26 Mar 2015 20:04:00 -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 tkVTpECGbJav for <urn@ietfa.amsl.com>; Thu, 26 Mar 2015 20:03:58 -0700 (PDT)
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (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 31C631A909E for <urn@ietf.org>; Thu, 26 Mar 2015 20:03:58 -0700 (PDT)
Received: by igbqf9 with SMTP id qf9so9482250igb.1 for <urn@ietf.org>; Thu, 26 Mar 2015 20:03:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P0IRG+pQQEa3CB3tg/spyTe/tZ6m1e4l2XhE2PFX5Vc=; b=mySX3Gi1aZ3UkCD9p27CBpRwZOAlhvzSD3B81SnYfRyu0tarpKJIYNuNVLKQ4zgIIw ryJr6Zs5bqzL1doOPq1urUoWVsk4k1LjOJcWGOoEWoBFJxyL32mFRMZe3u5KifjVjBR+ Qugp2rJPUFRtXv2OnPxQ33TiQOLGZNwKF6rr3114Hyqq3EUoMinki8nb5YVCvyLktMzx IMEEmFbhcy8XoOZgrnIDhLRqeJWTuqRqUTlqAactnT2/exZI2+NXocl3/bXbWshrHBlP sTA0sfXVk/Mx8Vm/g5pchU9Vioz+Vhali1iu1amYdDc2NvV2hLo5nZZtH/LEoi6iaVEz k3jg==
X-Gm-Message-State: ALoCoQlALbplVWG6Bd6716lUwFUG0RvGbvd6XAr8t7g995n4u2y/sR7/74egs82lD4sDUj2ihS1C
X-Received: by 10.107.11.226 with SMTP id 95mr15867286iol.5.1427425437517; Thu, 26 Mar 2015 20:03:57 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id lo1sm549696igb.1.2015.03.26.20.03.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Mar 2015 20:03:56 -0700 (PDT)
Message-ID: <5514C89A.8090204@andyet.net>
Date: Thu, 26 Mar 2015 21:03:54 -0600
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, urn@ietf.org
References: <7248E8A902BB366E16773856@JcK-HP8200.jck.com>
In-Reply-To: <7248E8A902BB366E16773856@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/aiBPw2IXheIxqoqXYymdJWbyyrs>
Subject: Re: [urn] Expert reveiw and draft-ietf-urnbis-rfc2141bis-urn-09
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: <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: Fri, 27 Mar 2015 03:04:00 -0000

On 3/4/15 8:16 AM, John C Klensin wrote:
> 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.

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 
urn-nid@ietf.org list indicates that this is important.)

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

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

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

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

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/