[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.
- [urn] Review comments on 2141bis-15 John C Klensin