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

Sean Leonard <dev+ietf@seantek.com> Sun, 11 January 2015 07:36 UTC

Return-Path: <dev+ietf@seantek.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 9CE401A1B1A; Sat, 10 Jan 2015 23:36:07 -0800 (PST)
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_HELO_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 wgjKDfNj2-o6; Sat, 10 Jan 2015 23:36:05 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BDB1A0087; Sat, 10 Jan 2015 23:36:05 -0800 (PST)
Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7F9FC22E1F4; Sun, 11 Jan 2015 02:36:01 -0500 (EST)
Message-ID: <54B2279C.2020203@seantek.com>
Date: Sat, 10 Jan 2015 23:34:52 -0800
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "urn-nid@ietf.org" <urn-nid@ietf.org>, "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] continued use of urn-nid@ietf.org list
References: <5499BA48.5060807@andyet.net> <5499BED1.104@seantek.com> <5499C04C.6040605@andyet.net> <549A58E4.30206@it.aoyama.ac.jp> <844A0581B9447C7703322432@JcK-HP8200.jck.com> <CALaySJJU1XdwrOyTdJ4nobrW8=piQ40Z0=Ay-5KvJY9-iGTEYQ@mail.gmail.com>
In-Reply-To: <CALaySJJU1XdwrOyTdJ4nobrW8=piQ40Z0=Ay-5KvJY9-iGTEYQ@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/p3u_6YZvuH750C1CAs-87XDneOY>
Cc: John C Klensin <john-ietf@jck.com>, Barry Leiba <barryleiba@computer.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: Sun, 11 Jan 2015 07:36:07 -0000

I am catching up on e-mail and, other than my parenthetical note about a 
couple of drafts, was unable to respond to this thread until now.

On 12/29/2014 12:37 PM, Barry Leiba wrote:
>>> So I think we should put "urn@ietf.org" into the draft as the
>>> address for review/discussions of namespace proposals[...]
>>> Actually, I think we should go a step further.  I think we
>>> should celebrate the new year and expected rapid progress in the
>>> WG
> One can hope, and I do.
>
>> 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.
and:
> and that authors or proponents of
>
> [drafts]
>
> 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.

I completely disagree with, and would like to point out the 
contradiction in terms, about: "I think we should celebrate...rapid 
progress...*by blocking all pending and future [work]...*"

With all due respect to the technical acumen of the URNBIS participants, 
that WG has been around for a couple of years already and has failed to 
produce thus far. There has been change of personnel, directional 
problems, etc. Moreover, the group did not meet at IETF 91.

Meanwhile there are a number of URN NID proposals that have languished 
or have been blocked for seemingly obscure technical reasons, or because 
people are evaluating the proposals based on shifting sands (i.e., 
URNBIS drafts) rather than objective, consensus-based criteria (RFC 
2141, RFC 3406, etc.).

People are debating about angels on the head of a pin, while 
implementers, in good faith, are trying hard to build applications and 
deliver them to market that make use of this technology area.

If proposed NIDs don't match opinions in the URNBIS work, maybe that 
should be a clue that (shifting) concepts around URNs is not delivering 
the value that folks need to get out of this work. Practice should 
inform the theory. And, in particular, drafts initiated up to now 
(really, up until URNBIS finishes producing) should not be held up.

Thus, the proposal "not [to] start not start processing on any other URN 
namespace requests until [the URNBIS] WG has finished the update" is 
both unfair to participants and technically unsound.

(Under the current rules, new formal URN namespace registrations require 
IETF Consensus. Therefore if any particular proposed NID conflicts with 
the clear direction of the URNBIS work, a sufficiently small faction of 
motivated URNBIS participants can block it anyway. That alone should get 
proposed namespace authors and URNBIS participants to play nice, without 
making one camp beholden to the other.)

Thank you,

Sean