Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix

Alissa Cooper <alissa@cooperw.in> Mon, 22 October 2018 10:19 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68DA128C65 for <dnsop@ietfa.amsl.com>; Mon, 22 Oct 2018 03:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=x1RmcShc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UZ3b/6Ej
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 N-3EEoQJND1L for <dnsop@ietfa.amsl.com>; Mon, 22 Oct 2018 03:19:49 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E372D1274D0 for <dnsop@ietf.org>; Mon, 22 Oct 2018 03:19:48 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 094A3221F3; Mon, 22 Oct 2018 06:19:48 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 22 Oct 2018 06:19:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=R wIFUZrQwKKhuHOcZ15oCQEskvTGm+eNyv8UhEygTCM=; b=x1RmcShcBWVqYUcDP ZKmhHQl0suCRpRPubYcYtYuY5lUpE8g/PrNl1SFhfoX9t6rNl6/du5kFP0Shri/x BtVbGhrn4861Cqca4hYjFAyS56C8Of7AiQ0Wr+fM41s6qhwYk/dMoPV6FzIT+ANS xXVgz5ebyqj9oWPgLMA4cxRBFAoUZjaQ7m1F7++Y76Qc2P4KvFhBGhJ3LX8zZJgq dra+WW5wPTcKMpgqcQ1H8YquHm1mJPXskoTWBocWevOCXnlXPbJHdMNXVTN5ENMa QPY3f4GPiZHpi2idxPDFKrIxs4FbN5ZKmvtKIo/dG+4+mKaH/frp4ScrX6YWmnP2 O+3BQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=RwIFUZrQwKKhuHOcZ15oCQEskvTGm+eNyv8UhEygT CM=; b=UZ3b/6EjRVQgClpe2N7sj7AhtLQkxsGXWgrOgpvNrmCXOp7JOZ0Yz8PDu H+yTPGJl0okXa5pZoEeCyB9R8ZDip6cY7dQRvT45hvfhzDN/V5G7EBGSy8W1nhHx Ll5Phl5ghjPcuTebx9MP7If9oS5RfIFa8wvjBDbrJ23pPV0TBxTlqoqoswdjuS75 76HSGCxR1dVq/hiMNfVLUA74mh7plIIpfODCSkGhut/HrM8uLz0qROQix1vWbfdU ipAoNCgeP7vvkg+vknLwQesz9ZLvC56C16P4YiSvnq47Fvx3rNkp8VyZXis3B5CP oq4tZ5dew2XoudmTB87IenHKcLSHg==
X-ME-Sender: <xms:Q6TNW3HlQkj5xOYyQ6Wwa-A0XuoeRpL3K01f45DLb6DHEttZqYyjAQ>
X-ME-Proxy: <xmx:Q6TNW6qgLua2ynJkC3Ec4SZJG8JBvYnLi6sIccBXbfwn-KbH4Gntqg> <xmx:Q6TNW-9nqUPd4-6Ud-M12qki6fL0GssSRjWxj5UqbqTHCXEw1lw1wA> <xmx:Q6TNW75RDitoPSKpDdqqKhi5wqBQ4eX_OT8VhTmCcdagyVDF_ZTz8g> <xmx:Q6TNW4j6aEly_kKXM03ofzvFTEW--1t0_7f-A-QU3ULc5vRQK3c32Q> <xmx:Q6TNWyrj8Y2a7VxaEP67Wk7-YhosfJklgmOl3WWqTnu8ljr30a0cZw> <xmx:Q6TNW9Xb8j4tPRItCtjayMg0AmHAgAaKA1Gm7A4K4G34dxyJ3LryRw>
Received: from alcoop-m-c46z.fios-router.home (pool-108-51-22-212.washdc.fios.verizon.net [108.51.22.212]) by mail.messagingengine.com (Postfix) with ESMTPA id CE651102ED; Mon, 22 Oct 2018 06:19:46 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <7ceb4930-ce09-9757-eaa1-ee34fc3c3539@dcrocker.net>
Date: Mon, 22 Oct 2018 06:19:46 -0400
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E84C03E-D5AE-4439-AD37-3E6D60E10F7F@cooperw.in>
References: <CAHw9_i+Hi_y2W+5sSLuZvtM0nLHVR=y5R--3D-UB2_W3TYJ8JA@mail.gmail.com> <27c9d56e-abd6-1ab1-029d-514036151517@dcrocker.net> <C43FBD7D-FA2A-4C47-8B61-B40A62FFA5F1@cooperw.in> <7ceb4930-ce09-9757-eaa1-ee34fc3c3539@dcrocker.net>
To: Dave Crocker <dcrocker@bbiw.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uIv8XbMfLTffzkTl29aAGvQuvPA>
Subject: Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Oct 2018 10:19:52 -0000

Thanks, glad there wasn’t a thread that I missed. Given Warren’s quick progress on this I suspect there is not any value for me to respond further to your points below. 

Alissa

> On Oct 19, 2018, at 11:52 AM, Dave Crocker <dhc@dcrocker.net> wrote:
> 
> On 10/19/2018 3:05 AM, Alissa Cooper wrote:
>>> I'll also note that I gave this feedback to Alissa directly,
>>> earlier and she did not respond to it.  That failure to engage is
>>> just one more problem with this Discuss.  (And it hearkens back to
>>> years ago when ADs would do this sort of thing regularly.  Not me,
>>> of course, but some...)
> 
>> Could you point out which message I did not respond to? After your
>> last message in the thread about my DISCUSS we had the telechat and
>> from my discussion there with Warren it seemed we had agreed on a way
>> forward, which seemed more appropriate for him to communicate back
>> than for me to.
> 
> 
> Alissa,
> 
> Thanks for asking.
> 
> My wording was too facile, because I was frankly trying to avoid getting into the detail.
> 
> More accurate wording would have that you responded once, superficially and inaccurately, and then failed to respond.
> 
> 
> The exchange was:
> 
>  1) On 10/10/2018 7:52 AM, Alissa Cooper wrote:
>> DISCUSS:
>> I think this document needs to state explicitly which updates apply to which
>> existing RFCs. That is, I would expect to see in sections 2.1,  2.2, and 2.3
>> the list of which documents are updated by each section. I realize this can be
>> intuited, but typically for avoidance of doubt authors specify precisely which
>> updates apply to which documents. This will also clear up the unused references
>> that idnits is pointing out
> 
>  2) On 10/10/2018 11:32 AM, Dave Crocker wrote:
>> What is the downside of using the existing text, as compared against
>> the effort (and delay -- quite possibly infinite) caused by
>> requiring development of the considerable detail that you are calling
>> for?
>> My question is not about the difference in cleanliness but about serious, practical risk.
> 
> 
>  3) On 10/10/2018 11:48 AM, Alissa Cooper wrote:
>> I think the downsides are (1) people reading the documents updated by
>> this document are confused about which parts of the update apply,
>> and (2) it sets a precedent that one RFC can update another without 
> > being specific about what is being updated.
>> I’m not asking for considerable detail, I’m asking for each of 2.1,
> > 2.2, and 2.3 to specify which documents out of the list in the Updates
> > header they update.
> 
> 
>  4) On 10/10/2018 12:16 PM, Dave Crocker wrote:
> > So by my count, that requires going over roughly 35 documents (again)
> > to audit and document this additional detail.
> >
> > My guess is that the burden on someone updating one of those
> > documents, seeing the reference to -fix, and being able to properly
> > determine whether their document revision needs to attend to the
> > section on TXT RRset usage and/or SRV RRset usage and/or URI RRset
> > usage is minimal, and the risk of their getting it wrong is zero.
> 
> and THEN you stopped responding.
> 
> 
> Above, I say 'superficially' because the two reasons you gave are intuitively appealing but lack the effort needed to balance against cost. That is, they are easy, pro forma tags, appealing in the abstract.  Casually deciding to add a task that is likely to take hours -- for someone you aren't paying to do the work -- is problematic, absent serious benefit.  This task doesn't come close.
> 
> I say 'inaccurately' on several counts.
> 
> First, consider the format and content of the -fix subsections of concern here.  Any editor who is revising one of the cited documents and can't figure out which of the 3 sub-sections applies to their document has bigger problems.  (Alternatively if folk really believe this is a decision moment that has any serious likelihood of the editor's making an error, we need to word those subsections better.)
> 
> Second, the assertion of 'precedent' presumes a policy that doesn't exist, as I had noted.  Worse, I fear you haven't reviewed all prior RFCs that did updating, to establish that it is at least a de facto policy.
> 
> But while ad hoc assertion of a non-existent policy is serious in the abstract, it is a minor point compared to the reality of this particular draft:  I am pretty sure we have never had an RFC that updated 35+ other documents.  Even better is that you are not calling for these subsections to match the precise and complete string-editing style typical for updating RFCs, since that would require 35+ subsectons and dramatically more work.
> 
> In other words, pragmatics require that this draft already be distinct, so citing 'precedent' fails on the facts.
> 
> That is why your not responding further was problematic.
> 
> The latter part of your latest note (quoted at the beginning of this message) points to a larger issue that I'm sure no one wants to pursue, namely the idea that an IESG discussion away from the working group and the author can make absolute decisions with no further discussion or recourse.  No matter how excellent the AD, they aren't a principal actor for the work being discussed.
> 
> Late-stage review and suggestions often produce significant benefit, but they also often lack context and encourage a failure to balance cost against benefits.  And in particular when the call for change comes from the IESG stage, there are two problematic forces: overworked folk lacking the time and inclination to engage in serous discussion and eager folk just wanting to finally get the darn thing published.  That encourages appeasement rather than careful consideration.
> 
> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net