Re: [urn] Adam Roach's Discuss on draft-ietf-urnbis-ns-reg-transition-08: (with DISCUSS and COMMENT)
John C Klensin <john-ietf@jck.com> Sat, 05 August 2017 12:37 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 5BE26131CDC; Sat, 5 Aug 2017 05:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 O1SLrISgUbxM; Sat, 5 Aug 2017 05:37:56 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 A3031131CE7; Sat, 5 Aug 2017 05:37:56 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ddyKz-000A0s-HI; Sat, 05 Aug 2017 08:37:49 -0400
Date: Sat, 05 Aug 2017 08:37:42 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
cc: urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-ns-reg-transition@ietf.org
Message-ID: <3697C9447D3D8F548171E3AD@PSB>
In-Reply-To: <b336d8f4-473b-52cd-6ff9-5d981d19738f@it.aoyama.ac.jp>
References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> <F0FFEA34B46FAA03A8D4AF61@PSB> <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> <C3ADC07D57A905E7C4B3137A@PSB> <ea50202b-d7d5-4452-0597-51d01a9333e3@nostrum.com> <C70F2B56E2B83E0B6DD2C91F@PSB> <b336d8f4-473b-52cd-6ff9-5d981d19738f@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.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: <https://mailarchive.ietf.org/arch/msg/urn/XLYJtOMKJM0z12v5k9eGOs4Ph6M>
Subject: Re: [urn] Adam Roach's Discuss on draft-ietf-urnbis-ns-reg-transition-08: (with DISCUSS and COMMENT)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 05 Aug 2017 12:37:59 -0000
--On Friday, August 4, 2017 17:36 +0900 "Martin J. Dürst" <duerst@it.aoyama.ac.jp> wrote: > Hello John, Adam, > > I'm currently on a plane heading for vacations, so I very much > hope that by the time you get this email, things have cooled > down a bit rather than escalating further. Martin, Thanks for the wise and calming words. If I were seeking to recall Adam over this, they would be entirely appropriate, but I am not. This is a matter of an appeal from a particular AD decision that I believe is out of line and that is _exactly_ what appeals are intended for: to ask the IESG, and, if necessary, the IAB and ISOC to review a particular decision, think about it a bit more, determine whether it was appropriate and, if it is not, to then take whatever actions are needed to adjust and avoid unnecessary recurrences. The bar for what seem to be blocking DISCUSS positions -- ones that have the character of "unless the IESG overrides my position, I am not going to let this go through until my concerns are reflected by changes in the I-D" rather than "I think this issue needs further consideration and discussion" is critical to the efficient and effective functioning of the IETF. I believe that its being set too low is one of the reasons important work has been migrating away from the IETF. More important for this particular issue, the IESG has been asked repeatedly to change names or procedures so that the intent that separates those two very different DISCUSS procedures was made clear. I note that issue was included in at least one appeal over 11 years ago and that, AFAICT, the IESG has, in the subsequent decade, neither taken action on that issue or explained why not -- itself, IMO, as significant violation of the intent of the appeals model and a threat to fairness. Because of that, I would feel obligated to produce a formal appeal and carry it forward even if Adam changed his mind about the DISCUSS. > It may seem like Adam is singling out this draft, but he only > recently became an AD, and to support that claim, it would be > necessary to show that he on-purpose ignored the same issue in > other drafts that have recently come up to the IESG. Maybe > he's just trying to do his best as a new AD. Or maybe he is > just trying to give a bit more attention to an issue that is > somewhat more important to him than to other IESG members; > that's definitely not something that other ADs haven't done in > the past. Again, if I were contemplating a recall, you would be absolutely correct about a pattern of bad behavior. I am not, although whether I even have the right to contemplate such things raises other issues. No such pattern is required for an appeal of a particular action. You can legitimately question whether an appeal in this case should simply say "this is a bad decision, please reconsider it" or whether it is appropriate for me to point out that, intentionally or not, the action raises other questions including, in this case, the authority (as inviolable rules rather than general guidance or preferences) of IESG statements or positions (especially those not published in the RFC Series), the question of whether general editorial decisions and style-setting for the RFC Series lie with the IESG or the RFC Editor, and those issues of the bar for blocking DISCUSSes and the IESG's failure to adequately distinguish between the two despite at least on earlier appeal. One unfortunate, but I presume unavoidable, aspect of this is that Adam was not on the Thursday IESG call when this draft was on the agenda. Because he was not available to participate in the discussion and did not submit any clarifying material in advance, the document, rather than being considered and probably advanced or even specifically rescheduled, could not be discussed and was dropped into an "AD followup" state with, so far, no scheduled date for more of a discussion. Whatever else you may think of my response to Adam's note announcing the DISCUSS, it was an explicit indication to Adam (and anyone else watching) that I intended to make this an appeal issue and an outline of the issues I intended to raise. That sort of indication, essentially a "please reconsider this, if possible, before it gets out of hand" is a _requirement_ of an appeal of an AD action. > As for RFC numbers in abstracts, how exactly to show them can > be left to the RFC Editor. >... But that is exactly the point. Adam's position, as I understand it, is that the IESG has set those rules and neither WGs nor the RFC Editor has any discretion. > Every reader will know how to get > more information by going to the references section of the > main document even if the number isn't styled as a reference. > The concept of 'well-known RFC number' is very relative; there > may be RFC numbers that the potential readers of the document > know quite well even though the 'average' RFC reader won't. > Also, if I as a reader don't know an RFC number that's > obsoleted, then that's a very good signal that I may not have > to care. If we still want to help the reader more, an > additional phrase giving the title may also help. I'm not > saying that because I think that these RFC numbers need to be > in the abstract, just to say that it won't be the end of the > world if they are. I think the comments above would be excellent input to a discussion about whether the RFC Editor should do and what the guidelines should be. The issue here is whether the RFC Editor should even have that authority/ discretion of whether this type of editorial content is not only specified by the IESG in some materials I believe are imprecise and badly-worked as well as illegitimate as rules (Adam presumably disagrees) and than an appropriate basis for blocking documents until they conform with an AD's interpretation of those IESG specifications (Adam presumably disagrees with that too). >... > I strongly suggest that John take down his threat of an > appeal, and Adam take down the discuss, and that you both, if > necessary with the help of others, figure this out with less > heat. Not a threat, but a promise. If either the underlying issues here did not go well beyond that particular action and that particular editorial decision or if appeals were the heavyweight action you seem to assume, I would not have written that note. best, john
- [urn] Adam Roach's No Objection on draft-ietf-urn… Adam Roach
- Re: [urn] Adam Roach's No Objection on draft-ietf… John C Klensin
- Re: [urn] Adam Roach's No Objection on draft-ietf… Eric Rescorla
- Re: [urn] Adam Roach's No Objection on draft-ietf… Adam Roach
- Re: [urn] Adam Roach's No Objection on draft-ietf… John C Klensin
- Re: [urn] Adam Roach's No Objection on draft-ietf… Adam Roach
- Re: [urn] Adam Roach's Discuss on draft-ietf-urnb… John C Klensin
- Re: [urn] Adam Roach's Discuss on draft-ietf-urnb… Martin J. Dürst
- Re: [urn] Adam Roach's Discuss on draft-ietf-urnb… John C Klensin
- Re: [urn] Adam Roach's Discuss on draft-ietf-urnb… Adam Roach
- Re: [urn] Adam Roach's Discuss on draft-ietf-urnb… Spencer Dawkins
- Re: [urn] Adam Roach's Discuss on draft-ietf-urnb… Alexey Melnikov