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

Barry Leiba <barryleiba@computer.org> Fri, 09 January 2015 03:50 UTC

Return-Path: <barryleiba.mailing.lists@gmail.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 30D531A1B60; Thu, 8 Jan 2015 19:50:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 e9Z5DM5Rk3-9; Thu, 8 Jan 2015 19:50:38 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CCE1A1A36; Thu, 8 Jan 2015 19:50:38 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id at20so13162375iec.5; Thu, 08 Jan 2015 19:50:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6sLGI9jJjUej5tmI/jkvUZaJH7hLXi5uXYltWSjHGBc=; b=hWPHDEdEMU3xAjYq2JC6mx9U13yHgI+GqipAUAAMalpLnyjl+8DhU5Q5XL/xRPCcGM 0h31DcI7CjViDAXIdf3Fe/9qfkPSeQLUBY1HzgX/UkJWLd7TM7Dm+cP4qz4uwHlGnmji J0l7bqJMuJaFM6sH/pKFkjXn2gkWrDAOrPq4/nI3LJEFASk54Th4Go1gXxdGlrtwZCdM +oHeCw5QRdYipHjikFxJvEwaLkOovMeNsRcc+QJC59jd7Ms93C9Xx8KDRsB0tucpTS9t jzw7BZ7SaN4ADyReqwx7wjtQGCvwBbN2nUshKoSWpvr9yAxSGRuocXY928trGg5a1L/6 WgaA==
MIME-Version: 1.0
X-Received: by 10.50.127.241 with SMTP id nj17mr403548igb.22.1420775434290; Thu, 08 Jan 2015 19:50:34 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.107.173.83 with HTTP; Thu, 8 Jan 2015 19:50:34 -0800 (PST)
In-Reply-To: <1D6DD11066A060EED966B640@JcK-HP8200.jck.com>
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> <1D6DD11066A060EED966B640@JcK-HP8200.jck.com>
Date: Fri, 09 Jan 2015 11:50:34 +0800
X-Google-Sender-Auth: hpAp2RfeRpa1H5U2clV19dHK82o
Message-ID: <CAC4RtVAAw7VHg-XqFaDYgPi_OOzScRMAXx6XEwqHh+WFJ6YfEQ@mail.gmail.com>
Subject: Re: [urn] continued use of urn-nid@ietf.org list
From: Barry Leiba <barryleiba@computer.org>
To: John C Klensin <john-ietf@jck.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/3gJNb_d3FDWr9MrYeOm5EWgbGuY>
Cc: urn-nid@ietf.org, "urn@ietf.org" <urn@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: Fri, 09 Jan 2015 03:50:41 -0000

Closing the loop on this:

> Again, I'll defer to your decision about not combining the two
> lists now, but note that, IMO, the continued separation is
> weakening the work of this WG and increasing the risk of bad
> results.

Thanks.  So here's the deal:

1. The IESG has just given approval for draft-higgs-hbbtv-urn, and as
soon as he posts a new version I'm going to let it go out.  That
covers the in-process ones.

2. I will not start processing on any other URN namespace requests
until this WG has finished the update.

3. I'll watch the time-frame on that, and reserve the right to
reconsider at some point.

Fair?

Barry

On Tue, Dec 30, 2014 at 10:28 PM, John C Klensin <john-ietf@jck.com> wrote:
>
>
> --On Monday, December 29, 2014 15:37 -0500 Barry Leiba
> <barryleiba@computer.org> wrote:
>
>>>> 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
>>
>> 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.
>>
>> I strongly disagree with blocking pending ones.  There is only
>> one, and there's no reason to stop it now.  If you see
>> something wrong with it, say so specifically.  If not, let it
>> be approved, and we'll deal only with the future now.
>
> Some observations below, but I'm going to defer to you on this
> because I just don't have time or energy to both have a long
> discussion and to make progress on the URNBIS WG documents.
>
>> The urn-nid list is not a secret, and anyone here who thinks
>> they need to scrutinize NID requests now more strongly than
>> earlier... need only go there and do so.  It would be sillier
>> to have those requesting NIDs post to and follow this list,
>> which goes far beyond what they know or care to know.
>
> I was actually thinking about the issue the other way around.
> It has long been my experience that anyone who is active in the
> IETF, knows where to find things or who to ask, and have lots of
> time on their hands can find or follow just about anything that
> amuses them.  There have historically been exceptions, but they
> are few and becoming fewer.   However, one of several issues
> with URNBIS is that people are coming into the discussions with
> the perspective of one particular set of needs and advocating
> for them on the implicit assumption that, if those needs are
> accommodated, everything else will be taken care of [1].
>
> The result is that we aren't getting a sufficient number of
> perspectives and that increases the risks that we will get
> something seriously wrong by omitting consideration of an
> important case.  So my thinking was to create a situation in
> which someone proposing a new URN namespace and NID was more or
> less forced, as a condition for getting that NID, to follow and
> participate in the WG, primarily wrt two questions:
>
>         (i) Would any of the changes being proposed either hurt
>         or help setting up their namespace, and any others
>         similar to it that they can think about, be defined in a
>         way that is clear, reasonable, and natural?
>
>         (ii) Are there additional changes that should or should
>         not be made that would be significant from their
>         perspective?
>
> Now, one could figure out other ways to ask those questions than
> having them emerge in a dialog with the WG, and try to assure
> that we got answers, then forcing applicants onto the on the URN
> mailing list and holding the applications until the WG signed
> off.  But, right now, it appears to me that we are not, and have
> not been, getting those answers from the perspective of any
> recent applicants other than Sean, and he hasn't been involved
> for very long.
>
>>> 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.
>>
>> Hm.
>> I don't see it that way.  What I say above has always applied,
>> and the existing documents shunted the work over to urn-nid
>> for good reason. It's been quite a good thing, really, through
>> most of the life of this working group, that it hasn't
>> directly been on the hook for reviewing and approving NID
>> requests.  Participants here can be presumed to know well that
>> urn-nid is where those go, and to know well how to go there
>> too.
>
> See above.
>
>>...
>>> 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
>>
>> Please, let's not do that.  Let's just include that in the
>> above "what's done is done" category, and let it finish.
>> Unless you see specific harm, of course, which you absolutely
>> should comment on.
>
> I actually commented, at some length, on the GSMA/IMEI
> namespace(s) (now RFC 7254 and 7255).  Those comments went
> nowhere, including no useful responses from the authors or GSMA.
> I considered making a fuss during the last round of IETF Last
> Call (and, if necessary, on appeal) and concluded that
>
>  (i) I'm reluctant to tell another standards body what
>         they need, even though I'd be a lot happier if there was
>         some sort of roadmap rather than "this request now and
>         maybe there will be others later";
>  (ii) I don't see a particular example, in its own
>         namespace and with its own NID, as being especially
>         harmful -- especially since nothing says "you get to use
>         this as a precedent" -- even if there were serious
>         problems with it;
>  (iii) URNBIS wasn't nearly far enough along for us to
>         have a serious discussion about one GSMA namespace and
>         qualifiers of various sorts (?-components ?) that would
>         identify different uses of that namespace.  I do note
>         that, AFAIK, the situation with GSMA is rather different
>         from that with ISO/TC 46.  In the latter case, there are
>         separate registration authorities and oversight
>         arrangements for, e.g., ISSN and ISBN.  If the
>         registrations arrived, de novo, under the procedures
>         outlined in 2141bis (and the former 3406bis), they would
>         almost certainly arrive from different applicants.
>         GSMA, again AFAIK, is a little more monolithic, so it
>         would be reasonable to press for "one organization, one
>         broad set of topics, one namespace" or at least for an
>         explanation of why that was not appropriate;
>  (iv)  I just don't have time to both fight individual
>         URN namespace battles (unless they are obviously
>         critical-path), try to drag i18n work along, and pay
>         attention to anything else IETF-related.
>
>
>>...
>> I am mostly happy to hold the future requests up, and I think
>> it's not unreasonable to do that, provided that we do put a
>> time limit on it.
>
> Again, see the discussion of motivation above.
>
>> The possible exception is "lex", which has been held up very
>> long already.  It is, on the other hand, one that I find
>> problematic for a number of reasons, and when the authors have
>> responded to my last comments to them I'm inclined to ask you,
>> John, to be its document shepherd... which may, in itself,
>> throw it into the "delayed" pile (if you share my concerns, at
>> least some of them, and/or have your own).
>
> In the interest of future discussion and to keep this note from
> getting longer, I'll reply separately on that subject.
>
> Again, I'll defer to your decision about not combining the two
> lists now, but note that, IMO, the continued separation is
> weakening the work of this WG and increasing the risk of bad
> results.
>
> best,
>     john
>
>
> [1] There are more negative versions of that story, including
> "as long as my needs are met, I don't care about anything else",
> but such hypotheses are unnecessary to my point.
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn