Re: [DNSOP] [Ext] A nudge on the new terms in draft-ietf-dnsop-terminology-bis

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 13 February 2017 23:34 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 D5C8C12998C for <dnsop@ietfa.amsl.com>; Mon, 13 Feb 2017 15:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 c2cRGw2qlcoL for <dnsop@ietfa.amsl.com>; Mon, 13 Feb 2017 15:34:37 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B94812958B for <dnsop@ietf.org>; Mon, 13 Feb 2017 15:34:36 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0CCF8284E51; Mon, 13 Feb 2017 23:34:36 +0000 (UTC)
Date: Mon, 13 Feb 2017 23:34:35 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Message-ID: <20170213233435.GF24579@mournblade.imrryr.org>
References: <390DDFE7-E70F-4E4E-96AB-AECFE25672E0@vpnc.org> <310D014B-1B3F-420C-A411-DEF6A67016D5@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <310D014B-1B3F-420C-A411-DEF6A67016D5@icann.org>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qncg6tFMEfFNRYUr-7fWtLHQ-JE>
Subject: Re: [DNSOP] [Ext] A nudge on the new terms in draft-ietf-dnsop-terminology-bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dnsop@ietf.org
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: Mon, 13 Feb 2017 23:34:39 -0000

On Fri, Feb 10, 2017 at 01:12:28PM +0000, Edward Lewis wrote:

> I have a fundamental problem with that, meaning that a document within
> DNSOP is defining domain names.  Work I did to write (the still in progress)
> draft on Domain Names has led me to believe that domain names are a concept
> beyond the DNS protocol.  On the other hand, the DNS protocol and operators
> of it, deserve to have a definition in place, so I'm not totally convinced
> this is a bad idea.
> 
> Diving into the definition contained in the draft though, it needs work.  Referring to:
> 
> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-04, for "Domain Name" and "Label" :
> 
> ) Domain name:  An ordered list of zero or more labels.
> 
> ) Label:  An ordered list of zero or more octets and which makes up a
>        portion of a domain name.
> 
> This is a circular definition which makes it quite meaningless.  E.g., "A
> is a string of B's" and "B is a component of A."

The definition is not as circular as it may seem.  A domain is a
sequence of labels, and a labels is a sequence of octets.  My beef
would be with the "zero or more" part, as applied to labels, since
zero length labels (if construed as actual labels rather than just
termination sentinels) do not occur except to terminate a domain
name.  Otherwise, if the zero length terminator is a label, then
domains have at least one (terminal zero-length) label.

I would also be tempted to not designate relative names as "domain
names".  To me, those are just sequences of labels that make up an
initial part of a domain name.

Not sure whether such hair splitting is needed.  The important
take-away from the definitions is that the document defines domain
names abstractly, as nodes on a rooted acyclic directed graph with
siblings distinguished by distinct non-empty octet strings known
as labels.  The sequence of labels from a node up to the root is
its domain name.  Such domain names can then represented in various
semantically equivalent forms.

-- 
	Viktor.