Re: [DNSOP] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

P Vix <> Tue, 20 March 2018 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD521126C25; Tue, 20 Mar 2018 11:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aN6czR3HfwjQ; Tue, 20 Mar 2018 11:32:55 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F1F7120047; Tue, 20 Mar 2018 11:32:55 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id C3A467594C; Tue, 20 Mar 2018 18:32:53 +0000 (UTC)
Date: Tue, 20 Mar 2018 18:32:51 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----1Q3QBX7P194JQ0KXMLC7R7IOUKD2B5"
Content-Transfer-Encoding: 7bit
To:, "John R. Levine" <>, Applications and Real-Time Area Discussion <>
From: P Vix <>
Message-ID: <>
Archived-At: <>
Subject: Re: [DNSOP] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Mar 2018 18:32:59 -0000

Harmonization for the sake of harmonization is bad, and very little Internet System technology gets it. Just do new stuff better.

On March 20, 2018 6:11:08 PM UTC, "John R. Levine" <> wrote:
>After some back and forth with Dave, I realized I missed what seems to
>to be a large change: this draft redefines the naming rules for SRV and
>The current rule is that SRV is _service._protocol where the protocol
>from a short list including _tcp and _udp and the service is from the
>Service Name and Transport Protocol Port Number Registry most recently 
>defined by RFC 6335.  This draft proposes that the service names now
>from a newly defined second-level name registry in the draft. The URI 
>record uses the same namespace, but nobody believes it's widely used so
>it's less of an issue.
>This seems to be a large change for very little benefit, and 
>unlikely to be backward compatible unless we can identify every service
>name now in use with SRV which seems unlikely.
>> G'day. This concerns an activity in dnsop, but the wg chair has quite
>> reasonably suggested running a significant, proposed change past apps
>> since the work affects a number of existing and future apps efforts. 
> (In 
>> fact, the effort was first triggered by the DKIM work, more than 12
>> ago...)
>> The domain of discourse is _underscore domain names, used for
>defining a 
>> special place to use some DNS resource records, such as TXT and SRV.
>> There are quite a few, existing documents that define such use, all
>> the benefit of a common registry.  Hence the danger of name
>collision.  The 
>> attrleaf effort is seeking to define a registry for holding existing 
>> _underscore names and defining new ones.
>> Besides defining the registry, the task requires updating existing 
>> specifications to use it.  The attrleaf draft has attempted to
>perform both 
>> tasks in a single document, but this has made for a confused and
>> document. (There's a larger lesson here, in spec writing...)
>> More recent discussions (well, actually, last August) in dnsop,
>> toward splitting registry definition from existing document updating,
>and the 
>> note below points to a new draft that does the first.  The note also
>> out the plan for the updating document.
>> Comments?
>> d/
>> -------- Forwarded Message --------
>> Subject: [DNSOP] Fwd: New Version Notification for 
>> draft-ietf-dnsop-attrleaf-03.txt
>> Date: Mon, 19 Mar 2018 17:35:29 -0700
>> From: Dave Crocker <>
>> Reply-To:
>> Organization: Brandenburg InternetWorking
>> To: dnsop <>
>> Folks,
>> I'll limit what should be an extensive and elaborate apology to just
>> I'm sorry for the year of inactivity.
>> The -03 version should provide some useful substance of progress.
>> I've gone over last summer's comments and the -03 version should
>reflect what 
>> the wg agreed to.  Basically, it has been significantly streamlined, 
>> essentially to reflect a clean-sheet model of the world. That is, it
>> deal with the ugliness that SRV, et al, created.  It merely
>establishes the 
>> two registries we need, long term, and populates them.  This document
>> have continuing utility.
>> -03 defines two registries, 'global' and 'second-level'.  I'm
>suspicious of 
>> how short the global one is, though it does make sense.
>> As noted in the document, absent major concerns with the substance of
>> document, please send me or the list s/old/new/ types of change
>> and if the change is for a reference, I'd love the suggestion to be 
>> <reference> xml...
>> A second document will attempt to fix up the uglinesses in some
>> documents, to get them to align with a world that has these
>registries. It 
>> should be viewed as a transitional document, though we all know how
>> 'transitions' are in the Internet...
>> Deciding how to pursue that reasonably has been the effort.  The
>changes this 
>> 'fixes' document defines will be to documentation, but not to
>> operation.  Existing uses in the field will be preserved.
>> Here's the approach I'm taking:
>> 1. Simple underscore usage
>>   For many/most specifications that use underscore naming, the text
>> says to use it.  They are straightforward.
>>   These specifications need to be listed in this document,
>explicitly, so 
>> that later updates to them will know to deal with the revisions
>called for by 
>> this document.
>>   But this document doesn't really need s/old/new kinds of precise
>> for them. Rather than provide precise language for changing each of
>these, I 
>> propose to provide some generic text, and generic IANA
>Considerations.  This 
>> will permit this Fixes document to be cited as Updating those RFCs.
>> 2. SRV and URI
>>   These need more detailed text, very much in the s/old/new style.
>>   The current text in them does a use-by-reference of existing tables
>> defined for other purposes.  The Update text will, instead, specify a
>> requirement for adding entries in the Global or Common Second-Level 
>> registries.
>> d/
>> -------- Forwarded Message --------
>> Name:		draft-ietf-dnsop-attrleaf
>> Revision:	03
>> Title:		DNS Scoped Data Through '_Underscore' Naming of Attribute 
>> Leaves
>> Document date:	2018-03-19
>> Group:		dnsop
>> Pages:		14
>> URL:
>> Status:        
>> Htmlized:       
>> Htmlized: 
>> Diff:
>John Levine,, Primary Perpetrator of "The Internet for
>Please consider the environment before reading this e-mail.
>DNSOP mailing list

Sent from my Android device with K-9 Mail. Please excuse my brevity.