[DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

John C Klensin <john-ietf@jck.com> Mon, 26 March 2018 06:37 UTC

Return-Path: <john-ietf@jck.com>
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 45D36126B72; Sun, 25 Mar 2018 23:37:06 -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, 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 YMfdV3_NwYJk; Sun, 25 Mar 2018 23:37:04 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA713126BF6; Sun, 25 Mar 2018 23:37:04 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1f0LkZ-000EbU-Ij; Mon, 26 Mar 2018 02:36:59 -0400
Date: Mon, 26 Mar 2018 02:36:53 -0400
From: John C Klensin <john-ietf@jck.com>
To: "John R. Levine" <johnl@iecc.com>, Dave Crocker <dcrocker@bbiw.net>
cc: art@ietf.org, dnsop@ietf.org
Message-ID: <1DF1564CC2B88726B2B54CF4@PSB>
In-Reply-To: <alpine.OSX.2.21.1803211507380.9666@dhcp-935d.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> <A7711F58-5145-49E8-9158-B2F94D0EABBF@redbarn.org> <7c168dc1-2ea7-d47e-78b7-0380e5d0aa84@dcrocker.net> <alpine.OSX.2.21.1803211104210.9553@ary.local> <5244d327-f8ea-1590-c663-1d92e0b194c4@dcrocker.net> <5F44FA5B42805C52479DE491@PSB> <alpine.OSX.2.21.1803211507380.9666@dhcp-935d.meeting.ietf.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/o7n099L4H65elbwspvkcUooFBh0>
Subject: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.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: Mon, 26 Mar 2018 06:37:06 -0000

Taking another look at this now that the IETF dust has settled.

First, when I wrote my earlier note on the 21st, I had just
glanced through the spec, not studied it, and was under the
impression that either the SRV entries and registry would not be
affected or that all entries in the SRV registry would be folded
into the new one.  The former would be fine, the latter
plausible if it could be done smoothly but I gather there are
reasons why it cannot.

Two additional, possibly more important, thoughts after reading
-05 more closely...

(1) The introductory material in the I-D seems to imply that use
of labels styled with "_" is a reasonable alternative to
creating a new label type.  My impression has been that, while
there is nothing we can change about what is done and deployed,
there has been community consensus that it is a bad idea and
that changes have been made to the procedures for defining and
registering new RRTYPEs to reinforce the principle that new
RRTYPEs should be used and to make their use easier.
"Significantly challenging over the life of the DNS" is
undoubtedly correct, but that should not be, and presumably is
not, the situation today or in recent years.   I believe this
document should not be advanced until that material is changed
to be clear that use of underscore or similar conventions may be
a reality but is not a desirable substitute for separate RRTYPEs
(with or without that convention as appropriate).

(2) I'd encourage people to think through another possibility.
I'm not sure it is the right answer, but it is worth more
consideration than this draft (at least at -05) appears to be
giving it.  The issues associated with QTYPE=ANY
notwithstanding, it is not clear to me that the set of labels
starting with "_" constitute a namespace, any more than the set
of labels starting with "xn--" do.  It is just a naming
convention that identifies the labels as keywords with defined
meaning.   From that point of view, namespaces are actually
per-RRTYPE and the right way to design this document would be as
a registry of "_"-introduced keywords, with subregistries for
each RRTYPE with which those keywords can be used.  Given the
way the DNS works, at least as I understand it, there is no DNS
protocol conflict between
     _foo IN XYZ Data1
and
     _foo IN ABC Data2

Using the same keyword in both cases may be a bad idea but the
zone files don't care and, given that queries are typically made
for QNAME and QTYPE (etc.) and not the name alone (i.e., with
QTYPE=ANY) except for other purposes, I see some advantages of
[sub]registry-per-RRTYPE rather than pretending that every label
starting with "_" is the same namespace.  Of course, one of them
is that there is no need to treat SRV as a special, legacy, case
or even debate that.   The coverage of the current document
would be simply a subregistry for SRV (reorganized from the
current registry, but that is simply an IANA organizational
matter, not a change to what is registered, protocols, etc.,
plus a subregistry for RRTYPE=TXT and provisions for other
subregistries as might be needed in the future.

Organizing things that way would have at least one additional
advantage: while FCFS may be appropriate for some RRTYPEs, other
procedures may be appropriate for others.  In a way, SRV is a
good example of that distinction.

Again, that might not be the right thing to do on balance, but I
think it should be examined carefully as an alternative to
trying to treat "everything starting with '_' as long as it
occupies a particular place in the tree" as a namespace.

best,
    john