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

John C Klensin <john-ietf@jck.com> Mon, 26 March 2018 14:38 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 291701275F4; Mon, 26 Mar 2018 07:38:20 -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 AOl4D5VImvzK; Mon, 26 Mar 2018 07:38:19 -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 D835C12420B; Mon, 26 Mar 2018 07:38:18 -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 1f0TGL-000Fky-9e; Mon, 26 Mar 2018 10:38:17 -0400
Date: Mon, 26 Mar 2018 10:38:11 -0400
From: John C Klensin <john-ietf@jck.com>
To: "John R. Levine" <johnl@iecc.com>
cc: art@ietf.org, dnsop@ietf.org
Message-ID: <0DC55A40A5F920C5F41AB044@PSB>
In-Reply-To: <alpine.OSX.2.21.1803260915260.19119@ary.local>
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> <1DF1564CC2B88726B2B54CF4@PSB> <5AB89C4C.7090300@redbarn.org> <4C79BE1080735A41C8697C8D@PSB> <alpine.OSX.2.21.1803260915260.19119@ary.local>
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/0DLW9dtHb1nF7JhGrq3lPSG6Eaw>
Subject: Re: [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 14:38:20 -0000


--On Monday, March 26, 2018 09:44 +0100 "John R. Levine"
<johnl@iecc.com>; wrote:

>...
>>> i have reproduced your entire second suggestion here,
>>> because i think  it's solid. rrset atomicity means you're
>>> right, and that underbar'ed  labels need only be unique
>>> within an RRTYPE, and any registry of such  labels can and
>>> therefore should be per-RRTYPE.
> 
> Technically, you are completely correct.  But since the
> namespace is in effect infinite I would just as soon not have
> to explain to anyone why _foo for SRV means the same thing as
> _foo for URI but different from _foo for TXT.  As we've seen
> it's hard enough to understand the separate second level
> underscore namespaces and we're stuck with them.

Ah, but pulling them together into one registry is our old
problem, in disguise, of trying to control behavior by what we
allow to be registered.   If, for example, I'm stupid enough to
use "_tcp" as the label of a TXT RR, a single registration tree
won't stop me or cause any DNS problems, it will just help me
add to the confusion.   If they are separated, I'm at least
marginally encouraged to document what I'd doing. 

At least as I see it, the purpose of a registry like this is to
help non-stupid people avoid conflicts and to provide
documentation pointers for information about the keywords.
Especially if the registry is not expected to grow to a huge
number of entries, asking IANA to create an alphabetical index
of all label keywords (I'm resisting "_Node Name" because I
don't believe this is really a namespace) that could link names
to particular subregistries (possibly more than one) would not
be a big deal.  

By contrast, Table 1 of the I-D is 

                    +-------------+-----+------------+
                    | _NODE NAME  | RR  | REFERENCE  |
                    +-------------+-----+------------+
                    | _tcp        | SRV | [RFC2782]  |
                    | _udp        | SRV | [RFC2782]  |
                    | _sctp       | SRV | [RFC2782]  |
                    | _dccp       | SRV | [RFC2782]  |
                    | _domainkey  | TXT | [RFC6376]  |
                    | _spf        | TXT | [RFC7208]  |
                    | _dmarc      | TXT | [RFC7489]  |
                    | _vouch      | TXT | [RFC5518]  |
                    +-------------+-----+------------+ 

While not very large, it is sorted by RRTYPE and then not sorted
in any obvious way.  Were it to grow significantly, one would
either want the same sort of index or would want to sort it by
label string ("_Node name") and then create an index by RRTYPE. 

If we are going to separate "SRV" out, as you and several other
have argued is necessary, we've got two separate registries
already -- SRV and "everything else", with the latter consisting
exclusively of TXT.  So, again, going to two subregistries and
provision for expansion from a table that is halfway there
anyway does not seem to me to be a big deal while being closer
to the reality of the DNS (as Paul explained better than I
could).

best,
   john