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

Dave Crocker <dhc@dcrocker.net> Thu, 29 March 2018 17:06 UTC

Return-Path: <dhc@dcrocker.net>
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 C14EA120047 for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 10:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 ps13WaQLVBzP for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 10:06:50 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C4C1273B1 for <dnsop@ietf.org>; Thu, 29 Mar 2018 10:06:50 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w2TH8G6O028109 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Mar 2018 10:08:16 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1522343296; bh=Zw5k6rylUJgOFzalhdRau3uTo8JW4uz6oaKK9R56zYU=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=DWBJ14uA+XQpdeDuWoEhcvPn+03zRo8pWGGkeu8d+jHcypD72JoQUxQnqJvO+8GMJ QEI9R4xO5VLb5mWc+uw7eWVeXZMh60gk4dPAFH1rvUBmxsyzEYQGGEMck8pwAbJjpU CsUcGvwS9Z4xu0P7Uxye2nJkhu1aSy2CiFEFN/Gw=
To: Paul Vixie <paul@redbarn.org>
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>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Reply-To: dcrocker@bbiw.net
Message-ID: <9cbc682a-33a9-fa7b-b88b-f392d79840fb@dcrocker.net>
Date: Thu, 29 Mar 2018 10:06:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <5ABD14D3.80005@redbarn.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pHaX3IuUZNo7_TCxDzvZIp_Q5VA>
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:06:53 -0000

Paul,

On 3/29/2018 9:31 AM, Paul Vixie wrote:
>>> in: 1.1. _Underscore Scoping
>> ...
>>> s/[RFC1035]/[RFC952]/ (first occurrence)
>>
>> hmmm. I suggest listing both, since RFC1035 both cites the precedence of
>> RFC952 as well as supplying an (apparently redundant) formal syntax
>> specification for host name.
> 
> the reference to 952 in 1035 is only in the bibliography, and does not 
> specifically discuss its relationship to A RR owner names or to MX RR 
> targets. if you can show me the part of 1035 you think is relevant to 
> the definition of a host name, i'd like to see it.

The text in RFC 1035 I have in mind is:

 > 2.3.1. Preferred name syntax
...
> When creating a new host name,
> the old rules for HOSTS.TXT should be followed.  This avoids problems
> when old software is converted to use domain names.
> 
> The following syntax will result in fewer problems with many
> 
> applications that use domain names (e.g., mail, TELNET).
> 
> <domain> ::= <subdomain> | " "
> 
> <subdomain> ::= <label> | <subdomain> "." <label>
> 
> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

So, no, it doesn't explicitly cite the RFC number, but I read it as 
citing the substance.


>>> 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/
>>
>> Sorry, not understanding the issue(s). Please clarify.
>>
>> Here's my guess at the concern:
>>
>> SRV is viewed as not generic and/or doesn't have scaling problems?
>>
>> ...
> 
> 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>


>>> 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.

Note, for example, that RFC 1034 says:

 > 2.4. Elements of the DNS
...
>      The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
>      specifications for a tree structured name space and data
>      associated with the names.  Conceptually, each node and leaf
>      of the domain name space tree names a set of information, and
>      query operations are attempts to extract specific types of
>      information from a particular set.

which is not language that lends itself towards saying that an RR type 
has its own namespace.  I don't see anything in RFC 1035 that works for 
that view, either.


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net