Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

Paul Vixie <paul@redbarn.org> Thu, 29 March 2018 17:30 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 BC0EA12D879 for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 10:30:22 -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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 zwqxWz2o3VYU for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 10:30:20 -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 2EEFA127419 for <dnsop@ietf.org>; Thu, 29 Mar 2018 10:30:20 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:79db:134b:9441:9ec] (unknown [IPv6:2001:559:8000:c9:79db:134b:9441:9ec]) (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 0C0D47594C; Thu, 29 Mar 2018 17:30:20 +0000 (UTC)
Message-ID: <5ABD22AA.7080509@redbarn.org>
Date: Thu, 29 Mar 2018 10:30:18 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.24 (Windows/20180302)
MIME-Version: 1.0
To: dcrocker@bbiw.net
CC: dnsop@ietf.org
References: <152225104695.29861.12372554810426800977@ietfa.amsl.com> <5ABBE1D3.9050608@redbarn.org> <22b570aa-c552-d060-c115-e98bbb86efa1@dcrocker.net> <5ABD14D3.80005@redbarn.org> <9cbc682a-33a9-fa7b-b88b-f392d79840fb@dcrocker.net>
In-Reply-To: <9cbc682a-33a9-fa7b-b88b-f392d79840fb@dcrocker.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FOZiribSYPMu-qQ6GxW7WmD_spA>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.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: Thu, 29 Mar 2018 17:30:22 -0000


Dave Crocker wrote:
> The text in RFC 1035 I have in mind is:
>
>  > 2.3.1. Preferred name syntax
...
> So, no, it doesn't explicitly cite the RFC number, but I read it as
> citing the substance.

i think it's non-normative and should not be referenced in your 
document. this text:

> However, when assigning a domain name for an object, the prudent user
> will select a name which satisfies both the rules of the domain system
> and any existing rules for the object, whether these rules are published
> or implied by existing programs.

...does not require or prohibit. and in your example:

> When creating a new host name,
> the old rules for HOSTS.TXT should be followed.

...is not using a modern SHOULD, it's general advice only.

bizarrely, we are then greeted by this text:

> The labels must follow the rules for ARPANET host names.  They must
> start with a letter, end with a letter or digit, and have as interior
> characters only letters, digits, and hyphen.  There are also some
> restrictions on the length.  Labels must be 63 characters or less.

it says "must", and if this is to be seen as a modern MUST, then it is 
true of all labels, and SRV updated 1035. also, the famous example of 
3com.com required a change to the SRI-NIC policies of its era, but was 
never backported to 1035. so, this text is clearly archaic.

whereas, in 952 we have the following. (more commentary below the break.)

> GRAMMATICAL HOST TABLE SPECIFICATION
>
>    A. Parsing grammar
>
>       <entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>]
>          [":" [<opsys>]  [":" [<protocol list>] ]]] ":"
>       <addresses> ::= <address> *["," <address>]
>       <address> ::= <octet> "." <octet> "." <octet> "." <octet>
>       <octet> ::= <0 to 255 decimal>
>       <names> ::= <netname> | <gatename> | <domainname> *[","
>          <nicknames>]
>          | <official hostname> *["," <nicknames>]
>       <netname>  ::= <name>
>       <gatename> ::= <hname>
>       <domainname> ::= <hname>
>       <official hostname> ::= <hname>
>       <nickname> ::= <hname>
>       <protocol list> ::= <protocol spec> *["," <protocol spec>]
>       <protocol spec> ::= <transport name> "/" <service name>
>          | <raw protocol name>
>
>    B. Lexical grammar
>
>       <entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>]
>       <entry-text>  ::= <print-char> *<text>
>       <blank> ::= <space-or-tab> [<blank>]
>       <keyword> ::= NET | GATEWAY | HOST | DOMAIN
>       <hname> ::= <name>*["."<name>]
>       <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
>       <cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
>       <opsys>   ::= ITS | MULTICS | TOPS20 | UNIX...etc.
>       <transport name> ::= TCP | NCP | UDP | IP...etc.
>       <service name> ::= TELNET | FTP | SMTP | MTP...etc.
>       <raw protocol name> ::= <name>
>       <comment> ::= ";" <text><cr><lf>
>       <text>    ::= *[<print-char> | <blank>]
>       <print-char>  ::= <any printing char (not space or tab)>

since the _ was chosen as nonconflicting, and since you desire to 
explain what it is we aren't conflicting with, and since the RFC 1035 
language is both non-normative and archaic by inspection, i really think 
that 952 is the correct, and only correct, reference to use.

as a side node, RFC 952 permits host names of only 24 characters or 
less, including those which have interior periods for RFC 921 purposes. 
therefore, a protocol lawyer could say that any name longer than 24 
characters, or beginning with a number, was by definition 
non-conflicting with RFC 952, and needs no underscore to achieve same. i 
do not harbor this view, and i believe that the LEXICAL GRAMMAR section 
is more definitional than the ASSUMPTIONS section of RFC 952.






>>>> in: 1.2. Scaling Benefits for TXT, SRV, and URI Resource Records
>>>>
>>>> s/SRV,//; S/"SRV",//
>>>> OR s/Some resource records are generic and support a variety of
>>>> uses.//;
>>>>    s/Their use can scale poorly.*different uses\.//;
>>>>    s/increasingly-popular//; s/approach,/approach/
...
>> it's not increasingly popular, it doesn't scale poorly, and it's not
>> generic. so you can either remove those descriptions of SRV, or you
>> can remove SRV as the object of your description, or you can finesse it.
>
> Trying to eliminate the issue entirely, is this sufficient:
>
> <section title="Scaling Benefits">
>
> <t>Some resource record types are used in a fashion that can create
> scaling problems, if an entire RRset associated with a domain name is
> aggregated in the leaf node for that name. An increasingly-popular
> approach, with excellent scaling properties, places the RR under a
> node having an underscore-based name, at a defined place in the DNS
> tree under the 'parent' name. This constrains the use of particular
> <spanx style="verb">RR</spanx> types associated with that parent
> name. A direct lookup to the subordinate leaf node produces only the
> desired record types, at no greater cost than a typical DNS
> lookup.</t>
>
> <t>The definition of a underscore global registry, provided in this
> specification, primarily attends to the top-most names used for
> coping an RR type; that is the _underscore "global" names. </t>
>
> </section>

it's almost 100% of the way there. but, you should say "places the 
RRset" since an RR never travels singly except in zone files, and all 
underscore-using applications i know of will accept more than one RR 
having the same name, class, and type -- thus, they process RRsets, 
which travel as RRsets on the wire, and the fact that an RRset contains 
RRs is unimportant in and of itself -- and describing it this way is 
confusing. an RRset with one RR may seem to be a degenerate case, but 
it's essential (respects law of least astonishment) to think of it that way.

>>>> in: 2. DNS Underscore Scoped Entry Registries Function
>>> ...
>>>> /name space/name space, just as every RR type owns a distinct,
>>>> subordinate name space./
>>>
>>> An RR type owns a name space? I don't understand what that means or how
>>> it is correct.
>
> While I think I see a computer science basis for saying that an RR type
> has a namespace, I'm continuing to find the point more confusing than
> helpful, and fear that other readers will, too.
>
> At the least, can you point me to official documents that explain that
> view? I've looked around a bit an haven't found such a specification or
> discussion.

it only contains a namespace for the purposes of your underscore 
registry. no use of _TCP by any other RR type will conflict with the use 
of _TCP by SRV, for example. thus, each RR type effectively has its own 
registry, whose names need only be unique within that registry. you may 
prefer to call it a dictionary rather than a namespace in order to avoid 
confusion around what other DNS RFC's call a "namespace".

-- 
P Vixie