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

John C Klensin <john-ietf@jck.com> Mon, 26 March 2018 16:14 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 17CAC124B17; Mon, 26 Mar 2018 09:14:19 -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 o0f_n43H-usk; Mon, 26 Mar 2018 09:14:14 -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 744AC126CC4; Mon, 26 Mar 2018 09:14:09 -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 1f0Ul6-000Fx5-D2; Mon, 26 Mar 2018 12:14:08 -0400
Date: Mon, 26 Mar 2018 12:14:02 -0400
From: John C Klensin <john-ietf@jck.com>
To: Martin Hoffmann <martin@opennetlabs.com>
cc: art@ietf.org, dnsop@ietf.org
Message-ID: <32837C4DF5CB5BDD00DAD0FD@PSB>
In-Reply-To: <20180326171842.0eacbdc4@smaug.local.partim.de>
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> <20180326171842.0eacbdc4@smaug.local.partim.de>
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/7HwHLjAamEKJX1dfvzO8UCQ-Z7o>
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 16:14:19 -0000


--On Monday, March 26, 2018 17:18 +0200 Martin Hoffmann
<martin@opennetlabs.com>; wrote:

> John C Klensin wrote:
>> 
>> 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 [...]
> 
> This sort of thing already happens: Both SRV and TLSA use the
> _tcp and _udp labels. Perhaps the difference is subtle since in
> both cases the label denotes the transport protocol. But names
> do represent different things -- a service provided for a
> logical entity v. a port of a physical host.

The current text of the I-D, as I read it, is intended to bind
the use of a given string to a given RRTYPE.  From the abstract:

	"The purpose of the Underscore registry is to avoid
	collisions resulting from the use of the same
	underscore-based name, for different services."

Subtle or not, that is a collision.   I would much prefer to see:

  SRV [sub]registry
     ...
     _tcp  [RFC2782]
     ...

  TLSA subregistry
     ...
     _tcp  [RFCnnnn]
     ...

rather than
      _tcp SRV  [RFC2782][RFCnnnn]

the former would also make it easy to say whatever needs to be
said about second-level strings.

> Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and
> OPENPGPKEY all use underscore labels and are currently missing
> from the initial table in section 3.1.

Sigh.

   best,
    john

p.s. Some nit-picking in the hope of general improvements to the
document.  At least for me, the terminology and background
explanation needs careful review.  In particular 

(1) The text in Section 1.1 says

	'the DNS rules for a "host" (host name) are not allowed
	to use the underscore character... legal host names
	[RFC1035]'

1035 does not say that.  Its section 2.3.1 is about what is
preferred, not what is required (or "legal").  It says "should"
and "preferred", but there is no requirement.  As far as I know,
there has never been a serious attempt to turn that preference
into a requirement.  Indeed, RFC 8121 says exactly the opposite
and, if there were a prohibition, RFC 6055 would have been
largely unnecessary.

(2) While, AFAICT, it is correct or close to it, the terminology
describing the DNS tree structure is awkward.  For example, in
"_foo._tcp.example.com", it is probably incorrect to refer to
"_tcp" as a leaf node because it has substructure.  The
statement 

	"Each globally-registered underscore name owns a
	distinct, subordinate name space"

does not work if _foo._bar.examplle.com is valid for one RRTYPE
but not for a different one (this is another argument for both
associating "namespace" terminology with a keyword-RRTYPE pair
and a subregistry approach, but the current language is
problematic even if we stick with the current model.   And,
because a casual reader might associate "global" and
"right-most" with TLDs and get confused about whether the DNS
tree is considered "root up", "root down", or "root right",
those terms would probably benefit from an explicit terminology
section that describes this documents view of the tree.