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