Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-02.txt

John Dickinson <jad@sinodun.com> Sun, 14 June 2015 17:05 UTC

Return-Path: <jad@sinodun.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621E11B302C for <dnsop@ietfa.amsl.com>; Sun, 14 Jun 2015 10:05:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 wyZZ_976FJ6O for <dnsop@ietfa.amsl.com>; Sun, 14 Jun 2015 10:05:50 -0700 (PDT)
Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E5F1B3031 for <dnsop@ietf.org>; Sun, 14 Jun 2015 10:05:50 -0700 (PDT)
Received: from [62.232.251.194] (port=19582 helo=jads-MacBook-Air.local) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <jad@sinodun.com>) id 1Z4BLn-0001CP-WF for dnsop@ietf.org; Sun, 14 Jun 2015 18:05:46 +0100
Message-ID: <557DB465.7050007@sinodun.com>
Date: Sun, 14 Jun 2015 18:05:41 +0100
From: John Dickinson <jad@sinodun.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20150526153132.306.56516.idtracker@ietfa.amsl.com> <alpine.LSU.2.00.1506050005550.30373@hermes-1.csi.cam.ac.uk> <081EDE00-3FB4-4135-8CE7-149F73E4A74A@vpnc.org>
In-Reply-To: <081EDE00-3FB4-4135-8CE7-149F73E4A74A@vpnc.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - sinodun.com
X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: jad@sinodun.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/9jC4BCdOrTCWQ4l_bLCyUuUo-x0>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 14 Jun 2015 17:05:52 -0000


On 05/06/2015 17:50, Paul Hoffman wrote:
> Thanks again for the in-depth review. A few comments below.
>
> On Jun 4, 2015, at 5:35 PM, Tony Finch <dot@dotat.at> wrote:
>> The definition of "authoritative data" is still wrong.
> We have done the best we can with this, given that RFC 1034's definition is in dispute.
Typo: I think you mean parent-side not parent-size.

A few other things that have confused me in the past:

In-bailiwick: Informal discussion (in the bar at IETF meetings) suggests 
to me that most people are confused by this term. To me and about 50% of 
the people I have asked it means "Data for which the server is 
authoritative and *not* data for which the server is an authoritative 
ancestor". To me that is more in keeping with the dictionary definition 
of bailiwick. However, at least 50% of people in the bar felt 
differently. IMHO I think this is a term that should be deprecated and 
replaced by "in zone" or "in domain".

Some RR types are described as "class independent" (See RFC4034) I am 
not sure of the exact meaning of this (despite Roy's attempts to educate 
me) and would like to see it defined here.

Also mention of A-Label, U-Label any other IDN terminology might be useful.

regards
John