Re: [urn] continued use of urn-nid@ietf.org list

John C Klensin <john-ietf@jck.com> Thu, 25 December 2014 17:21 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C7D1A8843; Thu, 25 Dec 2014 09:21:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.31
X-Spam-Level:
X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 cOzYi1Nyud-j; Thu, 25 Dec 2014 09:21:54 -0800 (PST)
Received: from bsa2.jck.com (ns.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 857F11A8842; Thu, 25 Dec 2014 09:21:54 -0800 (PST)
Received: from h8.int.jck.com ([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 1Y4C6e-000GVV-Nk; Thu, 25 Dec 2014 12:21:48 -0500
Date: Thu, 25 Dec 2014 12:21:43 -0500
From: John C Klensin <john-ietf@jck.com>
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>, Peter Saint-Andre - &yet <peter@andyet.net>, Sean Leonard <dev+ietf@seantek.com>, urn@ietf.org, Barry Leiba <barryleiba@computer.org>
Subject: Re: [urn] continued use of urn-nid@ietf.org list
Message-ID: <844A0581B9447C7703322432@JcK-HP8200.jck.com>
In-Reply-To: <549A58E4.30206@it.aoyama.ac.jp>
References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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-nid/cp32XXF6npn0odvJS8PX6KIdadk
Cc: urn-nid@ietf.org
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Dec 2014 17:21:59 -0000

(Barry and IESG explicitly copied)

--On Wednesday, December 24, 2014 15:10 +0900 "\"Martin J.
Dürst\"" <duerst@it.aoyama.ac.jp> wrote:

> On 2014/12/24 04:19, Peter Saint-Andre - &yet wrote:
>> On 12/23/14, 12:13 PM, Sean Leonard wrote:
>>> Maybe.
>>> 
>>> But there are two distinct controversies: 1) whether a
>>> proposed NID follows the URN rules sufficiently to permit
>>> registration, and 2) what the URN rules should be. It is
>>> very difficult for people who are trying to get work done
>>> under 1), to get sucked into debates about 2).
>> 
>> Ah, I am thinking of the post-URNBIS context. Once we finish
>> 2141bis, the debates will be done. Or so I hope. :-)
> 
> I agree. Even now, the traffic isn't terribly high when
> averaged over a month or so, and while Sean definitely has a
> point, it's good that people who discuss the overall framework
> get exposed to actual examples and vice versa.
> 
> So I think we should put "urn@ietf.org" into the draft as the
> address for review/discussions of namespace proposals, with
> the understanding that this will attain force when the draft
> is published as an RFC.

Actually, I think we should go a step further.  I think we
should celebrate the new year and expected rapid progress in the
WG by blocking all pending and future URN namespace
registrations by referring them to the WG for formal review
until 2141bis is approved and becomes the new procedure.  The
problem is that, as we debate details of what should be
permitted in URN strings, it is at least theoretically possible
to slip registrations through a small mailing list and and
indifferent and noisy IETF LC process that would then give us
additional legacy compatibility problems.

I note that RFC 3406 not only requires IETF Consensus for new
URN namespaces but explicitly quotes the portion of RFC 2434
pointing to referral to relevant WGs, so it has probably been an
error to approve new URN namespaces since this "bis" WG came
into being without formally asking the WG for it consensus
opinion.

What is done is done and I think it would be ill-advised to
reopen the reviews on any namespace already approved and either
registered or in some phase of the post-approval publication
process, but I believe that the IETF Last Call on
draft-higgs-hbbtv-urn should not be closed out and an IESG vote
taken until this WG has formally reviewed it for conformance to
our plans going forward and that authors or proponents of 

draft-atarius-dispatch-meid-urn
draft-atarius-dispatch-meid-urn-as-instanceid
draft-benjemaa-vbs-urn
draft-seantek-certspec-04
draft-seantek-rdf-urn-00
draft-seantek-xmlns-urn-00
draft-snell-social-urn-01
draft-spinosa-urn-lex-09

should be notified that their drafts [1] are going to be
referred to the WG for formal review when IETF Consensus
approval is formally requested.   Their alternative, of course,
is to encourage this WG to finish its work, after which a more
streamlined procedure will be in place.  If any of those authors
or would-be registrants believe their requests are urgent, let
them convince the WG, noting that a WG-approved request should
go through the IETF approval process more quickly and might even
qualify for a two-week Last Call. 

In addition, while I would hope to not delay it, someone should
send a note to this list requesting a quick review of
draft-murdock-nato-nid-03 when it appears.

I hope we can accomplish this change by an administrative
decision rather than by document-by-document appeals based on
the language of RFC 3406, the fact that there is a relevant WG,
and that the referrals have not been made.

    john



[1] List produced by a quick pass through the I-D Datatracker;
may not be complete.