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" <jo...@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 <d...@dcrocker.net>
>> Reply-To: dcroc...@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, jo...@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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
