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