Re: [DNSOP] Alissa Cooper's Discuss on draft-ietf-dnsop-attrleaf-fix-04: (with DISCUSS and COMMENT)

Dave Crocker <dhc@dcrocker.net> Wed, 10 October 2018 19:16 UTC

Return-Path: <dhc@dcrocker.net>
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 155D4124BE5; Wed, 10 Oct 2018 12:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level:
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net
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 WnZNMt1tEVAu; Wed, 10 Oct 2018 12:16:22 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6771F120072; Wed, 10 Oct 2018 12:16:22 -0700 (PDT)
Received: from [172.16.20.49] ([64.80.128.22]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w9AJGfuT003769 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Oct 2018 12:16:42 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1539199003; bh=utjnb9aLubfWhPkb9RYxME7MxRrCdVyzkZZUCoN9Slk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ozljb/kPG/gBEzgTzopESEKhxeHDgYT1BN1tWBjdvTBYI57XRoAnCBayEJHFz/z9B AoEWZC+oqC/vaQAFOGU/TSs8+NO6iuo+08qqI2Jot/dStvZQLfGIejMqFit4M+7B// qwrom+LDblqIMKLBPyQcb1+CsdGb4GWE48cDlBA0=
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>, draft-ietf-dnsop-attrleaf-fix@ietf.org, Benno Overeinder <benno@NLnetLabs.nl>, dnsop-chairs@ietf.org, dnsop@ietf.org
References: <153918317300.5920.8885858667343705361.idtracker@ietfa.amsl.com> <daf2d0f4-bf62-aa72-f830-75f56a526801@dcrocker.net> <55BDE165-4C8A-4D0D-8777-C1169D83CEEC@cooperw.in>
From: Dave Crocker <dhc@dcrocker.net>
Message-ID: <14906e5d-3fda-a2f5-00b9-a377277ff10d@dcrocker.net>
Date: Wed, 10 Oct 2018 15:16:24 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <55BDE165-4C8A-4D0D-8777-C1169D83CEEC@cooperw.in>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Y2tMebLSNUYG-YY_Ey6rIHpIziY>
Subject: Re: [DNSOP] Alissa Cooper's Discuss on draft-ietf-dnsop-attrleaf-fix-04: (with DISCUSS and COMMENT)
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: Wed, 10 Oct 2018 19:16:24 -0000

Alissa,

On 10/10/2018 2:48 PM, Alissa Cooper wrote:
>> On Oct 10, 2018, at 2:32 PM, Dave Crocker <dhc@dcrocker.net> wrote:
>> On 10/10/2018 10:52 AM, Alissa Cooper wrote:
>>> 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.
>>
>> 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?
> 
> 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.


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.



d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net