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> Thu, 03 August 2017 12:49 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 E1D0C131EB1; Thu, 3 Aug 2017 05:49:39 -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 ByRf7-i4eSGH; Thu, 3 Aug 2017 05:49:30 -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 B7C3D12EC13; Thu, 3 Aug 2017 05:49:29 -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 1ddFZ9-0005Kn-CL; Thu, 03 Aug 2017 08:49:27 -0400
Date: Thu, 03 Aug 2017 08:49:19 -0400
From: John C Klensin <john-ietf@jck.com>
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
cc: urn@ietf.org, barryleiba@computer.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-ns-reg-transition@ietf.org
Message-ID: <C70F2B56E2B83E0B6DD2C91F@PSB>
In-Reply-To: <ea50202b-d7d5-4452-0597-51d01a9333e3@nostrum.com>
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>
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/GmDInp962xJQeWywmCUbPWSWWqI>
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: Thu, 03 Aug 2017 12:49:40 -0000
--On Wednesday, August 2, 2017 13:18 -0500 Adam Roach <adam@nostrum.com> wrote: > On 8/2/17 10:04, John C Klensin wrote: >> If "preferably" >> is turning in "mandatory", we need to have two discussions, >> one about the authority boundary between the IESG and the RFC >> Editor and the other about where in RFC 2026 and its updates >> the IESG is given authority to make policy by issuing >> statements rather than determining and reflecting IETF >> community consensus. > > > Thanks for sending me down the path of determining authority > here, as it has made me realize that I was confused about the > basis for insisting that Obsoleted documents be explicitly > listed in the Abstract. > > It turns out that the 2011 IESG statement of "preferably" is a > weak restating of a 2008 IETF-consensus decision to approve > version 1.9 of the "ID-Checklist" document, which clearly > states that the Abstract of a document needs to list obsoleted > and/or updated documents (cf. > <https://www.ietf.org/id-info/checklist.html#anchor6>; §3, > 1.D, first bullet: "if your document obsoletes or updates a > previous RFC, then... say so in the abstract"). > > And so I am forced to concede that my "No Objection" was made > in error. Since the form of this document actively goes > against IETF community consensus regarding the form of > IETF-stream RFCs, I realize that this should have been a > "Discuss." I will be adjusting my ballot accordingly. Thank > you again for pointing me in the correct direction, and I > apologize for the error. >... Adam, Silly me. I was about to propose a compromise in this area -- one that I hoped would allow the document to move forward, for me to be able to get back to RFC 3188bis and for you and the IESG to get back to more important work -- and either didn't do it soon enough or should have just kept my mouth shut and sorted this out with the RFC Editor. I was sufficiently appalled by your decision that I needed to take overnight to raise my confidence that I was not overreacting. Sadly, I don't think I was overreacting. Consequently, unless this DISCUSS can be resolved in some other way today, I will submit a formal appeal against your use of a blocking DISCUSS on an essentially editorial matter that puts form over substance and that is abusive of working group decisions and the Last Call and IESG review processes. In addition to the narrow issues in this particular case, the appeal is likely to raise the following issues: (1) The need to clarify the boundary between the IESG's authority, reflecting community consensus, over matters of content for documents in the IETF Stream and the RFC Editor's authority over editorial matters. General guidance and statements of preference notwithstanding, I believe that existing documents and long-standing tradition make rules about the editorial (as distinct from substantive) content and structure the exclusive province of the RFC Editor, with the only important exception being the provision for the IESG to demand "as is" publication of IETF Stream documents. The requirement is (2) The pattern of migration of "guidance" or "recommendations" into firm requirements ("rules") on which a blocking DISCUSS can be based and publication of such requirements only in IESG statements rather than archival documents of record. I note that Section 5 of RFC 3710 (the IESG Charter) makes a distinction between "problems and how to avoid them" and "commonly used guidelines" on the one hand and "rules" on the other. While that document says that the latter are "commonly published as BCP RFCs", I suggest that substituting poorly-indexed and non-archival "statements" or "checklists" for such RFCs sets a trap for the inexperienced or unwary and is hence inconsistent with a predictable and fair process. (3) Imposition of specific blocking rules involving the use or applicability of terms such as "obsolete[s]" and "historic" is inappropriate when it is generally recognized in the community that those terms are insufficiently defined and inconsistently applied. The way to solve those problems of definition and application involves a proposal for what should be done, community discussion and consensus, and RFC publication, not dropping a DISCUSS on a single document that was either arbitrarily chosen or that was singled out because one of the author-editors chose to push back on an editorial "preference". The observation that the IESG has not seen fit to initiate a community-based effort (such as a WG) to clarify those definitions makes a DISCUSS based on the use of those terms particularly questionable. (4) There are some specific issues with the checklist statement you cite that make it subject to different interpretations and highlight the issues identified in (2) above. For example: (4.1) As noted in erratum 5076, a statement similar to "this document obsoletes RFC 4687" is a citation whether an anchor appears there or not, yet C(1)(B) of the checklist prohibits citations. (4.2) C(1)(C) references "section 4.5 in https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt" in a context that can only be interpreted as normative, yet that link is dead (leads to a 404 error) and the document to which it referred became obsolete (sic) when RFC 7322 was published if not earlier. To save you the time of checking, Section 4.5 of RFC 7322 is not about abstracts. (4.3) C(1)(D), which you have cited in support of the presumed requirement, says "if your document obsoletes or updates a previous RFC, then: say so in the abstract". However, "say so" appears to be general guidance, not a requirement for specific language. The abstract in draft-ietf-urnbis-ns-reg-transition-08 includes "This document clarifies the status of relevant older RFCs...", which I contend is consistent with the checklist "say so" statement. Had you requested that statement be expanded to say "...document clarifies the status of relevant older RFCs and formally makes two of them historic...", I would have made a bad face but, unless my co-author, the WG Chairs, or the WG disagreed, I would have made the change and we would not be having this discussion. If the IESG (or even a single AD) is going to treat a particular document as a set of requirements that justifies a blocking DISCUSS, then it is obligated to maintain them so that statements are clear and normative references are usable. Failure to do so makes application of the documents or statements in that way fundamentally unfair. (5) Even if none of the considerations outlined above applied, it would be inappropriate to use a blocking DISCUSS because the guidance in a particular document violates a "rule" or "checklist item" when that guidance has existed for a long time and has never been enforced consistently. regards, 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