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

Dave Crocker <> Thu, 29 March 2018 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E29D212E040 for <>; Thu, 29 Mar 2018 14:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xwP2QHq55lo6 for <>; Thu, 29 Mar 2018 14:44:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98DE712E03F for <>; Thu, 29 Mar 2018 14:44:42 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w2TLk8eo020286 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Mar 2018 14:46:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1522359969; bh=zy3DiqfqU+j5da5iX7p8Ky922iRXf9h2Lmtw1mbYFaU=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=k4HAxRBsUKBp+m7BwpOk997hhV3gQVLDMku2G3dOCcydoLxnLjNQmz5OntCVA/3Bg EnKn8QO8wtiVB6zhmqRPlst4CMPaWnU8BexJmfYWGZ3kA2IW1BgW67hXnkBVz/sded 1CRnmVTKKsr3H08cHi4yWs/Mpmsvyp+sCz2mwsbo=
To: Paul Vixie <>
References: <> <> <> <> <> <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Thu, 29 Mar 2018 14:44:35 -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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Mar 2018 21:44:45 -0000

On 3/29/2018 10:30 AM, Paul Vixie wrote:
> 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.

Thanks for the detailed explication.  I think it's odd to have a DNS 
naming-related discussion that does not cite either of the seminal 
standards documents for domain naming, but I suppose there's isn't much 
downside at this place in the document, to cite only RFC 952.

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

To me, that's an example of the problem with citing only that document: 
It is not definitive on 'host name'.  That RFC 1035 isn't, really, 
either was my reason for wanting to cite both.  But anyhow, the next 
version will have only 952.

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

oops.  quite correct.

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

Oh.  Alas, I'm still not seeing how this is helpful pedagogy for the 
average reader.  Let's suspend this until the next version and see how 
the doc sits with folks.


Dave Crocker
Brandenburg InternetWorking