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
- [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Paul Vixie
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Dave Crocker
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Phillip Hallam-Baker
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Paul Vixie
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Dave Crocker
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Paul Vixie
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf… Dave Crocker
- Re: [DNSOP] namespaces, I-D Action: draft-ietf-dn… John Levine