Re: [DNSOP] Adam Roach's Discuss on draft-ietf-dnsop-attrleaf-13: (with DISCUSS and COMMENT)

Adam Roach <> Tue, 09 October 2018 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CBC4129619; Tue, 9 Oct 2018 12:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bLE_vHq8vpK6; Tue, 9 Oct 2018 12:33:29 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07C6D1277C8; Tue, 9 Oct 2018 12:33:29 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w99JXNOP039888 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Oct 2018 14:33:24 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be
To: Dave Crocker <>, The IESG <>, Warren Kumari <>
Cc: Tim Wicinski <>,,,,
References: <> <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Tue, 9 Oct 2018 14:33:18 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] Adam Roach's Discuss on draft-ietf-dnsop-attrleaf-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Oct 2018 19:33:30 -0000

On 10/9/18 2:21 PM, Dave Crocker wrote:
> On 10/9/2018 2:45 PM, Adam Roach wrote:
>> This is based on an assumption that document authors who add 
>> enumservices are more likely to notice the need [1] to add their 
>> service name to two tables than the IANA are. Given the respective 
>> levels of rigor, that seems like a losing bet.
> There is certainly a substantive discussion to have about this, since 
> the working group did.
> But I'll suggest something simple, in the hope that it actually 
> simplifies things in process terms:
>      This issue was discussed at some length within the working group,
>      including disagreements of the sort you raise now. Eventually the
>      working group finally settled on the choices made in the draft.

That's a fair point. I still believe that this arrangement makes the 
situation as it pertains to URL RRs worse rather than better, but I'm 
willing to call myself in the rough here. If another AD sees fit to 
DISCUSS this issue, I will support them. But I'll clear my own discuss 
now, as it seems that we've reached a difference of opinions regarding 
harm rather than demonstrable harm.