Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf

Dave Crocker <> Wed, 18 July 2018 16:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B52D11311B7 for <>; Wed, 18 Jul 2018 09:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L0gm0KyGyWBF for <>; Wed, 18 Jul 2018 09:21:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 001B01311B4 for <>; Wed, 18 Jul 2018 09:21:39 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w6IGOCgh004498 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Jul 2018 09:24:12 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1531931053; bh=By3e6emDx9RM77hgW/BJR7+0clNk560PhFqnVOUNoeA=; h=Subject:To:References:From:Cc:Reply-To:Date:In-Reply-To:From; b=lMLausFBodw5YZyobE7m0zNp0xdQCU2eEjz08rX6m5xWJFxcYzQh2TzSXV9j50/Wq +2S2vtSRvHVOKVwFaaab8e4Ues1+zBFuq/QzV7pJj2Cwm5WPrlJ1Y4xMiKdtww/ajN dR9+XBfN00npdaIiSB4CpdvK19jSgQXNGUcXE3sw=
To: "Murray S. Kucherawy" <>
References: <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Wed, 18 Jul 2018 09:21:33 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] Review of draft-ietf-dnsop-attrleaf
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Jul 2018 16:21:42 -0000


I'm responding to Murray's impressive proofreading details offlist, but 
there are some points he raises that might need wg discussion:

On 7/18/2018 8:17 AM, Murray S. Kucherawy wrote:
> The DNS is case-insensitive so this is a minor point, but would there be 
> any benefit to specifying that the registry only records the 
> all-lowercase version of an underscore name?

Mumble.  The registry entries, of course, are not DNS entities.  So 
aspects of registry use might care, such as for comparisons.

And since uniqueness is the whole goal, forcing entries to use a single 
case simplifies comparison.  I'm inclined to do as Murray suggests.

> The text specifically calls for a stable reference. Do we have guidance 
> about what constitutes such a thing? I believe IANA has its own 
> guidelines to that end; are they available to the Designated Expert?

I'm inclined to let IANA raise this if they see and issue and then let 
them drive the resolution of this point.

> Section 6:
> I have doubts that SECDIR would accept this one-sentence comment. I 
> suggest saying something more specific, like:
> "This document establishes a registry, and encourages a slight 
> reorganization of attributes stored in the DNS. It establishes no new 
> security issues."

The first clause is redundant and makes sense to have here only either 
if the readers of this section haven't read the rest of the document, or 
if the clause is useful to what follows.  I believe neither applies here.

I don't understand the 'encourages' statement but suspect I don't agree.

That leaves language that is equivalent to the existing language...

> Section 6.1:
> This seems to me to be content that belongs in its own section outside 
> of Section 6 since it doesn't seem to me to be a security issue, but 
> it's worth saying. Maybe give it its own section between what's now 
> Sections 3 and 4?

Well, I agree it's awkward where it is, but gosh.  An entire major 
section?  For such a small and explanatory -- rather than 
specification/normative bit of text? Mumble.

If no one minds, I would rather make it Section 1.4, just after the 
sub-section tht describes the construct.  I think it actually works well 

Dave Crocker
Brandenburg InternetWorking