Re: [art] Call for Consensus: Re: On BCP 190
John C Klensin <john-ietf@jck.com> Tue, 20 August 2019 20:35 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70921200A1 for <art@ietfa.amsl.com>; Tue, 20 Aug 2019 13:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 p-dUchn-8WYC for <art@ietfa.amsl.com>; Tue, 20 Aug 2019 13:35:23 -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 EA493120090 for <art@ietf.org>; Tue, 20 Aug 2019 13:35:22 -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 1i0Aqb-000LR0-EL; Tue, 20 Aug 2019 16:35:17 -0400
Date: Tue, 20 Aug 2019 16:35:10 -0400
From: John C Klensin <john-ietf@jck.com>
To: Adam Roach <adam@nostrum.com>, Mark Nottingham <mnot@mnot.net>
cc: Jacob Hoffman-Andrews <jsha@letsencrypt.org>, ART Area <art@ietf.org>, Devon O'Brien <devon.obrien@gmail.com>
Message-ID: <4FA97CBBC395799300730D88@PSB>
In-Reply-To: <cecdb623-b6cd-ab60-12d2-b5030c0692b9@nostrum.com>
References: <58BF6171-03BB-4F83-940F-3A101EFDD67F@mnot.net> <CAN3x4Q=Jo1uBvfCG6CSrociYgdG+E4jq+4cB1txPjgboth2q9g@mail.gmail.com> <372FA049-7B33-4981-A0E0-41BD454CB770@mnot.net> <CAN3x4QmJsfx48MdhcBB+XWX+vfv=skSR2Z6kNPBWGVobvzNuFA@mail.gmail.com> <004601d5450d$62b33220$28199660$@acm.org> <CAN3x4Q=XR+=ugv6HEmOgsA6v64GkQ+4u-Hk+OBQ0Lp9jn-Cy=A@mail.gmail.com> <D154BA24-5027-4FAF-8779-CBA5533D24A1@mnot.net> <3000e948-14e6-80d2-e8e6-766d309c361c@nostrum.com> <ed64dc0e-5b71-63ec-cbac-85673c51109a@nostrum.com> <301DF34E4C5601BCA4D2BCBF@PSB> <A27BC0BC-B60A-44AD-B75B-859C71B0706A@mnot.net> <E02E5D4BA18EF0155B0EAE95@PSB> <80bb60b7-cdc7-0df8-6a33-726839b15dfe@nostrum.com> <C4BE71284D3C8DCA4F8F2187@PSB> <cecdb623-b6cd-ab60-12d2-b5030c0692b9@nostrum.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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/art/UwwAai9pKgrsmZDIYWF7wXFe96I>
Subject: Re: [art] Call for Consensus: Re: On BCP 190
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2019 20:35:25 -0000
--On Tuesday, August 20, 2019 14:22 -0500 Adam Roach <adam@nostrum.com> wrote: > On 8/20/19 1:33 PM, John C Klensin wrote: >> I'd >> be happier with a statement from you that, instead of saying >> that you are clearing the Discuss because Mark is working on a >> revision > > > Thanks for giving me a chance to clear this up, since it's not > what I meant, although I can see how the structure of my email > may inadvertently give that impression. > > The rationale for clearing my DISCUSS is: > >> I think that these responses combined with the input received >> during IETF 105 are a weak signal that that there is support >> for adjusting BCP 190 at least to the extent necessary to >> allow the "provisioned directory prefix" approach used by CT. > > > The mention of updating the document is a follow-on from this > observation, but not at all the rationale for clearing the > discuss. That helps. But it also takes us full circle because: * RFC 7320 is either normative, and the 2119 language in it lays out firm requirements, or it isn't. It reads as it it is normative, it contains MUST statements, and it cites 2119 normatively. Both that, and the discussions of the last few weeks, strongly imply that the community thinks it is normative and its author thought it was normative at the time it was approved. * Nothing in that document, or in any more general IETF procedural specification I can find, gives either a single AD or the IESG the authority to waive a normative requirement of a standards-track document without at least an IETF Last Call that addresses the specific issue and, normally, a Last Call on a new document that waives or eliminates the requirement in question. * Independent of how you interpret the discussions of the last few weeks (we agree that there is at least weak consensus within the ART Area that 7320 needs some adjustment), there is, AFAIK, no posted document that makes those adjustments or allows the IESG to make exceptions, much less an IETF Last Call on such a document. * Given that, whatever agreement you see (and cite) does not justify your taking a position that sounds a lot like "well, BCP 190 prohibits this but there is a 'weak signal that that there is support for adjusting BCP 190' and therefore never mind what it actually says". The IESG does not have the authority and withdrawing the Discuss and having the IESG let this go through has the appearance of the IESG thinking that whatever it wants to do supercedes most or all of the IETF's procedural rules about document approval. Because I'd rather have a discussion than have this note interpreted as a thread, I promise to not appeal should the IESG follow that course, but I suggest it would set a precedent about claims of IESG authority independent of even a pretense of IETF consensus that the IETF would probably come to regret. So, it would seem to me that, without violating any fundamental procedures and in the interest of Doing the Right Thing and unblocking the CT document, you (and the IESG) could do any of the following. The first would involve a certain amount of nose-holding, but, IMO, that is far less objectionable than simply kissing off our procedures. (1) Go back to what I thought you said and approve this with a clear understanding that either a replacement for 7320 or an action to deprecate it, killing its advice until a more temperate replacement was approved. (2) Put normative language into the CT document pointing to Mark's draft. That would allow the IESG to approve it but would introduce an RFC Editor normative reference hold on publication. I don't know whether that would block important work or not. (3) Have someone write a document that either deprecates 7320 or updates it sufficiently to turn it into general guidance, not a collection of normative requirements. Push that document through the system (presumably requiring a four-week LC). (4) Have someone write a document that adds language to 7320 to update it to allow the IESG to make exceptions on its own judgment and without community consensus. Same comment about pushing that document through and four-week Last Calls. (5) Section 6.4 of 2026 has been widely interpreted as not requiring a replacement document to change the classification of a standard. So, presumably the IESG could reclassify 7320 to Informational or Historic on the basis of a Statement. I'd hope that would involve an IETF Last Call too, but I'm not sure that is a firm requirement (remember that, once upon a time, the RFC Editor could reclassify documents on his own initiative). I'm open to other ideas if you have them, but I think that going down the path toward a "never mind what BCP 190 says, do what seems sensible on the IESG's say-so" decision would be a really bad idea for the future of the IETF. Because I really do want to see progress here, if you conclude that (3) or (4) above is the right course of action and you can't find a volunteer, I'll try to push everything else in my queue aside and do some writing. Again, from my perspective, the problem here is RFC 7320, not the new work. And, if there is a lesson here, it is either "no more documents like that, especially as normative Standards Track documents disguised as BCPs" or "if we are going to have one, even as an Applicability Statement, it MUST (sic) include a clear exception procedure. Sorry about this, but I've very concerned about the precedents this would set. best, john
- [art] On BCP 190 Mark Nottingham
- Re: [art] On BCP 190 Leif Johansson
- Re: [art] On BCP 190 Mark Nottingham
- Re: [art] On BCP 190 Leif Johansson
- Re: [art] On BCP 190 Mark Nottingham
- Re: [art] On BCP 190 Leif Johansson
- Re: [art] On BCP 190 Adam Roach
- Re: [art] On BCP 190 Leif Johansson
- Re: [art] On BCP 190 Adam Roach
- Re: [art] On BCP 190 Mark Nottingham
- Re: [art] On BCP 190 Leif Johansson
- Re: [art] On BCP 190 Mark Nottingham
- Re: [art] On BCP 190 Melinda Shore
- Re: [art] On BCP 190 Leif Johansson
- Re: [art] On BCP 190 Mark Nottingham
- Re: [art] On BCP 190 Melinda Shore
- [art] Is CT single-use origins or not? (Re: On BC… Adam Roach
- Re: [art] Is CT single-use origins or not? (Re: O… Jacob Hoffman-Andrews
- Re: [art] On BCP 190 Jacob Hoffman-Andrews
- Re: [art] Is CT single-use origins or not? (Re: O… Adam Roach
- Re: [art] On BCP 190 Mark Nottingham
- Re: [art] On BCP 190 Jacob Hoffman-Andrews
- Re: [art] On BCP 190 Mark Nottingham
- Re: [art] On BCP 190 Tony Finch
- Re: [art] On BCP 190 Mark Nottingham
- Re: [art] On BCP 190 Tony Finch
- Re: [art] On BCP 190 Jacob Hoffman-Andrews
- Re: [art] On BCP 190 Larry Masinter
- Re: [art] On BCP 190 Carsten Bormann
- Re: [art] On BCP 190 Jacob Hoffman-Andrews
- Re: [art] On BCP 190 Mark Nottingham
- [art] Call for Consensus: Re: On BCP 190 Adam Roach
- Re: [art] On BCP 190 Jacob Hoffman-Andrews
- Re: [art] Call for Consensus: Re: On BCP 190 Carsten Bormann
- Re: [art] Call for Consensus: Re: On BCP 190 Mark Nottingham
- Re: [art] On BCP 190 Stephen Farrell
- Re: [art] Call for Consensus: Re: On BCP 190 Rob Sayre
- Re: [art] On BCP 190 Tony Finch
- Re: [art] Call for Consensus: Re: On BCP 190 Rob Stradling
- Re: [art] Call for Consensus: Re: On BCP 190 Adam Roach
- Re: [art] Call for Consensus: Re: On BCP 190 John C Klensin
- Re: [art] Call for Consensus: Re: On BCP 190 Melinda Shore
- Re: [art] Call for Consensus: Re: On BCP 190 Mark Nottingham
- Re: [art] Call for Consensus: Re: On BCP 190 John C Klensin
- Re: [art] Call for Consensus: Re: On BCP 190 Ben Campbell
- Re: [art] Call for Consensus: Re: On BCP 190 John C Klensin
- Re: [art] Call for Consensus: Re: On BCP 190 Adam Roach
- Re: [art] Call for Consensus: Re: On BCP 190 Adam Roach
- Re: [art] Call for Consensus: Re: On BCP 190 John C Klensin
- Re: [art] Call for Consensus: Re: On BCP 190 Adam Roach
- Re: [art] Call for Consensus: Re: On BCP 190 John C Klensin
- Re: [art] Call for Consensus: Re: On BCP 190 Adam Roach
- Re: [art] Call for Consensus: Re: On BCP 190 Adam Roach
- Re: [art] Call for Consensus: Re: On BCP 190 John C Klensin
- Re: [art] Call for Consensus: Re: On BCP 190 Larry Masinter