Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf

Dave Crocker <> Wed, 03 August 2016 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2920012D8A3 for <>; Wed, 3 Aug 2016 15:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F7QVhLxg2zRz for <>; Wed, 3 Aug 2016 15:20:27 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C723212D674 for <>; Wed, 3 Aug 2016 15:20:26 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u73ML5Er030241 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 3 Aug 2016 15:21:06 -0700
To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <>, Tim Wicinski <>
References: <> <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Wed, 3 Aug 2016 15:20:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Aug 2016 22:20:28 -0000

On 7/20/2016 1:59 AM, Patrik Fältström wrote:
> On 20 Jul 2016, at 7:57, Tim Wicinski wrote:
>> This draft is not just looking at SRV records, but TXT records which document such behavior.
> And URI.


I think I didn't respond to this:  URI showed up after the original 
drafting of the doc, but yes it needs to be included.  However after 
some very basic research it appears that the URI RR does not yet have 
traction.  So the current doc needs to account for its existence but I 
think it does not create additional registry entries, especially since 
it emulates SRV.

Subordindate Table(s):

More significant is the handling of the second-level underscore node 
name for the two-level naming constructs (where the upper-level is a 
protocol string, used by SRV and URI.  Ray had suggested a way to deal 
with this quite a long time ago and I promptly forgot what it was.  When 
the topic renewed during Berlin, I finally gravitated towards a model 
that luckily was along the lines he proposed...

In practical terms, the second-level underscore names need to be 
registered explicitly, although one might think the SRV doc has covered 
this by pointing to a table.  By my reading, that reference is more 
conceptual than a detailed registry reference.

The set of protocol (upper-level) names is small and should be in the 
registry explicitly.  One might argue that the reference to the separate 
protocol table suffices but this is a case that seems better handled by 
the mild redundancy.

As for the second-level underscore names, I propose that they /also/ be 
registered in this one table.  In theoretical terms, one could argue for 
a separate table, or maybe many of them (one under each top-level 
underscore protocol name) but that purity-drive choice seems somewhere 
between inefficient and silly.

If we thought there would be lots of independent uses of the same name, 
but under different upper-level underscore (protocol) names, we'd need 
all the separate, subordinate names.  And indeed, this is what bogged me 
down originally.

But no one, including me, so far thinks this is a realistic need.  So 
finding a way to simplify this down to one table seems eminently reasonable.




   Dave Crocker
   Brandenburg InternetWorking