[urn] Review comments on 2141bis-15

John C Klensin <john-ietf@jck.com> Fri, 18 March 2016 19:02 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DAD12D5AC for <urn@ietfa.amsl.com>; Fri, 18 Mar 2016 12:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 nf_reUwrzI03 for <urn@ietfa.amsl.com>; Fri, 18 Mar 2016 12:02:27 -0700 (PDT)
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 DF2B612D540 for <urn@ietf.org>; Fri, 18 Mar 2016 12:02:16 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1agzf5-000MwD-Pk for urn@ietf.org; Fri, 18 Mar 2016 15:02:15 -0400
Date: Fri, 18 Mar 2016 15:02:10 -0400
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <F219C62FDC94D8733398A95F@JcK-HP8200.jck.com>
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.10
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/BHSkOaz8gKbjvCg5vpM_XpqIgqE>
Subject: [urn] Review comments on 2141bis-15
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 18 Mar 2016 19:02:39 -0000

Hi.

It has now been 3 1/2 weeks since Sean posted his three (or
perhaps four, depending on how one counts) sets of review
comments on draft-ietf-urnbis-rfc2141bis-urn-15 on 21 February.
There has been, AFAICT, one response, from Martin Dürst, on the
22nd, clarifying my earlier comments somewhat and, IMO at least,
reinforcing and extending some of Sean's.  There were also some
comments from Martin on the topic of URNs for media types and
related issues, picking up on a thread that started, IIR, on
another list.  As far as I can tell, that media type thread has
no impact on 2141bis although we [1] should perhaps review the
examples to be sure that they are clear.

I've been silent (except for responses to Cathy Meadows's thread
on a quite separate topic) since then.  Part of the reason for
that is that I wss very busy with some other issues but the more
important part is that I've hoped others from the WG would
actually comment on the issues involved.  There has been no
traffic on the list other than that triggered by
draft-martin-urn-globus (on which we've been copied for
information about new namespace registration requests) since 22
February.   Anyone feeling like checking that or otherwise
looking at old traffic should see the list archive at 
https://mailarchive.ietf.org/arch/search/?email_list=urn

I believe the Globus registration request does raise one issue
that should be checked by the WG.  I'll post my specific concern
about it within a short time after posting this note.

I am writing only as an individual participant -- decisions
about how or if the WG should proceed would have to come from
the co-chairs or AD and the thoughts below are just my
perspective. 

That silence is not a good sign.  A reasonable assumption when a
draft is posted, there are comments criticizing that draft and
claiming that the work should not go forward without those
comments being resolved, and there is no response from the rest
of the WG is that the WG has run out of energy and no one cares
any more.  In a way, a debate in which only Sean, myself, and
Martin are participating is even worse in terms of assessments
of the WG's energy level and ability to reach meaningful
consensus about anything.

I plan to post responses to Sean's specific comments soon (they
were mostly written a few weeks ago but I need to review them to
be sure I haven't changed my mind or left significant loose
ends).   However, I'm not sure that they are even worth the
effort if the silence from others is to continue or if, as
suggested below, almost no one cares.  The comments below are
therefore very general and more about the question of how (or
if) to proceed than about the details.

Based on discussions while 2141bis-14 and -15 were being
proposed, I want to offer an alternate hypothesis about the
silence that, if true, may suggest some changes in how we go
forward.  The hypothesis is that, while there may be general
agreement that the separation of q-component and r-component is
important and that both components are useful, very few people
in the WG actually care at this point about how r-components are
defined as long as we can move forward.  

Sean's earlier comments about r-components led us to modify
2141bis (in -15) to provide syntax for an explicit resolverID
but to leave details about semantics of r-components and their
applicability, resolverID registration, syntax of the string,
etc. -- very nearly everything other than that small bit of
syntax -- for future work, basically forbidding
standards-compliant use of r-components until that work is done.
That was intended as a compromise to allow us to move forward.
If it is not sufficient, e.g., if a long list of questions
starting with the requirements for resolvers to be assigned an
ID and the scope of resolverIDs have to be sorted out, answered,
and documented, then we have a problem.   There may be other
possibilities, but I can see the following options:

(i) We conclude that those questions are really blocking for the
WG.  If that is the case, then, unless there is a big infusion
of energy from somewhere, we had best just shut down now.   To
be clear, I don't think that Sean has raised any issues that
cannot be resolved; I just see getting them resolved in the
current WG as taking a very long time, perhaps years, to reach
consensus that we can claim is valid and informed.  It could
even require some experimental work and documents -- some of the
ideas are fairly close to the whatever boundary exists between
"research" and "engineering".

(ii) We do whatever is needed to move past those questions,
postponing them for future work.  I don't have a strong option
as to whether that would be better facilitated by leaving the
text that discusses r-components more or less as it appears in
-15 (i.e., including the "resolverID" distinction) or whether it
would be better to tear that out and just leave specification of
r-components for future work although my intuition tells me that
the present arrangement leads to lower risk of serious later
interoperability or compatible expansion problems.   If we do
that, there is an opportunity to create a WG to work on those
issues although, if I were an AD evaluating such a request, I'd
want to see very strong evidence that there is actually energy
to do the work.  However, with or without that follow-on WG, we
do whatever handwaving is needed in 2141bis, finish up whatever
is needed in other respects, and get things to IESG for
processing.

(iii) We just give up, avoiding having to decide between (i) and
(ii).

I assume my person preference is clear -- if we can make the
decisions implied by (ii), I think I could get -16 out this
weekend and we could, at least in principle, wrap things up
before the end of the month (and hence before IETF).

But the WG (or at least the co-Chairs and AD) need to decide, at
least IMO.

best,
    john





[1] "We" the WG, not just "we" the editors of 2141bis.