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

P Vix <paul@redbarn.org> Tue, 20 March 2018 18:32 UTC

Return-Path: <paul@redbarn.org>
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 BD521126C25; Tue, 20 Mar 2018 11:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN6czR3HfwjQ; Tue, 20 Mar 2018 11:32:55 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1F7120047; Tue, 20 Mar 2018 11:32:55 -0700 (PDT)
Received: from [172.17.8.83] (unknown [188.21.3.0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (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: <alpine.OSX.2.21.1803201804440.8940@dhcp-8344.meeting.ietf.org>
References: <f7b85bac-b050-5003-2df0-a48b1ef2f929@dcrocker.net> <e1f41670-ada8-eaac-468c-c712b338a10b@dcrocker.net> <alpine.OSX.2.21.1803201804440.8940@dhcp-8344.meeting.ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----1Q3QBX7P194JQ0KXMLC7R7IOUKD2B5"
Content-Transfer-Encoding: 7bit
To: dnsop@ietf.org, "John R. Levine" <johnl@iecc.com>, Applications and Real-Time Area Discussion <art@ietf.org>
From: P Vix <paul@redbarn.org>
Message-ID: <A7711F58-5145-49E8-9158-B2F94D0EABBF@redbarn.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2Xh2sK7or88mwIZkj14HUxnhImQ>
Subject: Re: [DNSOP] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: 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" <johnl@iecc.com>; wrote:
>After some back and forth with Dave, I realized I missed what seems to
>be 
>to be a large change: this draft redefines the naming rules for SRV and
>
>URI.
>
>The current rule is that SRV is _service._protocol where the protocol
>is 
>from a short list including _tcp and _udp and the service is from the
>IANA 
>Service Name and Transport Protocol Port Number Registry most recently 
>defined by RFC 6335.  This draft proposes that the service names now
>come 
>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.
>
>R's,
>John
>
>
>> G'day. This concerns an activity in dnsop, but the wg chair has quite
>
>> reasonably suggested running a significant, proposed change past apps
>folk, 
>> 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
>years 
>> 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
>without 
>> 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
>confusing 
>> document. (There's a larger lesson here, in spec writing...)
>>
>> More recent discussions (well, actually, last August) in dnsop,
>pointed 
>> toward splitting registry definition from existing document updating,
>and the 
>> note below points to a new draft that does the first.  The note also
>charts 
>> 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 <dhc2@dcrocker.net>;
>> Reply-To: dcrocker@bbiw.net
>> Organization: Brandenburg InternetWorking
>> To: dnsop <dnsop@ietf.org>;
>>
>> Folks,
>>
>> I'll limit what should be an extensive and elaborate apology to just
>this: 
>> 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
>doesn't 
>> deal with the ugliness that SRV, et al, created.  It merely
>establishes the 
>> two registries we need, long term, and populates them.  This document
>should 
>> 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
>the 
>> document, please send me or the list s/old/new/ types of change
>suggestions, 
>> 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
>existing 
>> 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
>glacial 
>> '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
>existing 
>> 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
>merely 
>> 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
>detail 
>> 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:
>https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-03.txt
>> Status:        
>https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>> Htmlized:       
>https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-03
>> Htmlized: 
>https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf
>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-03
>>
>>
>
>Regards,
>John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for
>Dummies",
>Please consider the environment before reading this e-mail.
>https://jl.ly
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop

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