Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf

Dave Crocker <dhc@dcrocker.net> Fri, 06 July 2018 16:54 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 E0913130F86 for <dnsop@ietfa.amsl.com>; Fri, 6 Jul 2018 09:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 BfzO_cx_uFKm for <dnsop@ietfa.amsl.com>; Fri, 6 Jul 2018 09:54:05 -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 C45F1130EC9 for <dnsop@ietf.org>; Fri, 6 Jul 2018 09:54:05 -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 w66GuWhC000655 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Jul 2018 09:56:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1530896192; bh=U/GiyzXKY167vxyszKB0zOqMg5drSp70CVc13qR+ukw=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=Jil4qCQoIWY5XJ3Piy/91VRJ8gl/W2f2mJAbvc0/F/RQYhIoLF5rddDfLVtDBEuao jttcaBtPtP41VX5Jc8tdEXtZv3nYxJQXf7JnRvk1c9anN5jmb7e+NeKdUK95mjbcuA /OJe7JRv1hwslij42+KCxUjEzXLwd7lUv6Dm/TgI=
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Benno Overeinder <benno@NLnetLabs.nl>
Cc: DNSOP WG <dnsop@ietf.org>
References: <60eb1c1a-5a3a-5908-27c1-7b3cf587eb14@NLnetLabs.nl> <20180706152250.n7242t2holox6bgq@nic.fr> <349edb95-48ff-41a2-4cda-1c9ed44f7c63@bbiw.net>
Reply-To: dcrocker@bbiw.net
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <ca94cc49-5da1-fdd2-254c-7741a275bb18@dcrocker.net>
Date: Fri, 6 Jul 2018 09:53:58 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <349edb95-48ff-41a2-4cda-1c9ed44f7c63@bbiw.net>
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/puhuZNxCdGYzXUf3SajodWCuOjw>
Subject: Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-attrleaf
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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, 06 Jul 2018 16:54:12 -0000

On 7/6/2018 8:39 AM, Dave Crocker wrote:
>> Editorial: 'that is they are the "top" of a DNS branch, under a
>> "parent" domain name.' I assume that "top" is used instead of "apex"
>> because the sentence does not always refer to the top of a zone?
> 
> 'zone' is almost certainly not the term to apply here.  While it 
> encompasses a sub-tree, its boundary is not explicit in a domain name.
> 
> The DNS is a hierarchy.  I would have though 'top of a sub-branch' was 
> therefore clear, concise and accurate.  Again, if there is other 
> phrasing that is more established, we should use it.  But I'm not used 
> to seeing 'apex', though it's certainly a more erudite choice...


I went back and looked at the terminology draft that is in last call. I 
assume that is where 'apex' came from.

However I'll claim that none of the language in that section of the 
document actually covers what is being described here, because this 
isn't about 'zones'...

FWIW, my sense is that the term zone has actually become quite ambiguous...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net