Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-09.txt

Dave Crocker <dhc@dcrocker.net> Fri, 25 May 2018 03:14 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 2733112D7F3 for <dnsop@ietfa.amsl.com>; Thu, 24 May 2018 20:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] 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 0WTTW5ezVVzu for <dnsop@ietfa.amsl.com>; Thu, 24 May 2018 20:14:14 -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 65D231242F5 for <dnsop@ietf.org>; Thu, 24 May 2018 20:14:14 -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 w4P3GE87017791 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 May 2018 20:16:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1527218175; bh=5MGFHk4LOD4MXkKOhg/+Xbl70OlArePS7o8GrSNLfic=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=qDzJ0pm6bX6w44RDtMKNUvkv6VN0mcNmXsAPa73EQ41paMMwkps4UnQ1vVZR6pes0 sp8B6SbwbQtpIeDYfu/jD4lUUBb1A129Zbtm8aKY/Iq2LQTO5lKUByP1SzxfWl4xMz 5kT09oNmpq0jhOClLAff8EgQzCHppxx9ez3SOk5c=
To: John Levine <johnl@taugh.com>, dnsop@ietf.org
References: <20180523231142.475222705F62@ary.qy>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Reply-To: dcrocker@bbiw.net
Message-ID: <a731d660-688f-da49-6dee-65c40cb878f9@dcrocker.net>
Date: Thu, 24 May 2018 20:14:07 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <20180523231142.475222705F62@ary.qy>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tkDcTkCB_GG9lxSxOsvPVDqWA0A>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-09.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: Fri, 25 May 2018 03:14:16 -0000

On 5/23/2018 4:11 PM, John Levine wrote:
> I took a look at -attrleaf and -attrleaf-fix and the both look good to me.
> 
> The language about parent names is correct but a little confusing.  If
> I can figure out a less confusing way to reword it I'll pass it along.


Since it seems to be the only place with the string "parent name", I 
assume you mean:

> Scaling Benefits
> ...
> An
> increasingly-popular approach, with excellent scaling properties,
>  places the RRset 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. 


How about:

An
increasingly-popular approach, with excellent scaling properties,
places the RRset under a specially-name branch, which is in turn under 
the node name that would otherwise contain the RRset.  The rules for 
naming that branch define the context for interpreting the RRset.  That 
is, rather than:

     domain-name.example
          /
        RRset

the arrangement is:

     _branch.domain-name.example
       /
     RRset



d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net