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

John C Klensin <john-ietf@jck.com> Wed, 04 March 2015 15:16 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 3741E1A6EDB for <urn@ietfa.amsl.com>; Wed, 4 Mar 2015 07:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Pc0X5yWfy7Ul for <urn@ietfa.amsl.com>; Wed, 4 Mar 2015 07:16:50 -0800 (PST)
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 C8E541A6EF9 for <urn@ietf.org>; Wed, 4 Mar 2015 07:16:50 -0800 (PST)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1YTB2X-0008j7-Ss for urn@ietf.org; Wed, 04 Mar 2015 10:16:49 -0500
Date: Wed, 04 Mar 2015 10:16:44 -0500
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <7248E8A902BB366E16773856@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.35
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/S7Rox_7sQo-itIttlo_CarD-_lc>
Subject: [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: Wed, 04 Mar 2015 15:16:55 -0000

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.

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

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.

Does that about cover it?  Does anyone want to suggest text?

     john