Re: [DNSOP] draft-liman-tld-names-04

Eric Brunner-Williams <ebw@abenaki.wabanaki.net> Mon, 29 November 2010 18:40 UTC

Return-Path: <ebw@abenaki.wabanaki.net>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8B23A6C26 for <dnsop@core3.amsl.com>; Mon, 29 Nov 2010 10:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.717
X-Spam-Level:
X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWij4qnmUs6M for <dnsop@core3.amsl.com>; Mon, 29 Nov 2010 10:40:55 -0800 (PST)
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id 6813028C0D7 for <dnsop@ietf.org>; Mon, 29 Nov 2010 10:40:53 -0800 (PST)
Received: from limpet.local (cpe-67-255-5-237.twcny.res.rr.com [67.255.5.237]) by abenaki.wabanaki.net (8.14.4/8.14.4) with ESMTP id oATHFZD4063487 for <dnsop@ietf.org>; Mon, 29 Nov 2010 12:15:36 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net)
Message-ID: <4CF3F3EA.70208@abenaki.wabanaki.net>
Date: Mon, 29 Nov 2010 13:41:46 -0500
From: Eric Brunner-Williams <ebw@abenaki.wabanaki.net>
Organization: wampumpeag
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: dnsop@ietf.org
References: <20101124142303.GB19441@shinkuro.com> <alpine.LSU.2.00.1011251734170.4075@hermes-2.csi.cam.ac.uk> <20101125175247.GH21047@shinkuro.com> <alpine.LSU.2.00.1011261558520.4075@hermes-2.csi.cam.ac.uk> <D8E75C03-0322-4594-BB27-D825AB429EA6@hopcount.ca> <C4FB358F-53D1-4A2B-A3A4-1C07222C0B51@dotat.at> <1E1C9726-46B6-4891-A1A4-9D71A90EFE47@hopcount.ca> <20101127185010.GB56062@farside.isc.org> <79DC22E8-18BC-44B1-8874-D094844D9E94@dotat.at> <8CEF048B9EC83748B1517DC64EA130FB43E00387CC@off-win2003-01.ausregistrygroup.local> <20101129143919.GE33199@shinkuro.com> <4CF3C0BA.1050307@abenaki.wabanaki.net> <alpine.LSU.2.00.1011291605210.4075@hermes-2.csi.cam.ac.uk> <4CF3DDD1.90201@abenaki.wabanaki.net> <alpine.LSU.2.00.1011291742380.4075@hermes-2.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.1011291742380.4075@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [DNSOP] draft-liman-tld-names-04
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 29 Nov 2010 18:41:00 -0000

On 11/29/10 12:59 PM, Tony Finch wrote:

> That's an informal description of the formal syntax defined in RFCs 608,
> 810, 952.

hierarchical names appear in 921, not 608 or 810, and 952 references 921.

> I am confused. You say double hyphens were forbidden then you say they
> were permitted.


it would be wicked difficult to change something from forbidden to 
permitted if the underlying rational for the restriction were in 
fielded implementations which were interoperable over some ranges of 
test values.

on the other hand, anything forbidden by policy alone may be 
permitted, and permitted in a non-fictive sense, by a mere change of 
policy.

a restriction which may be relaxed is proof of (a) overspecification 
error in a mechanism specification, or (b) absence of specification in 
a mechanism specification, usually known as a policy statement.

a restriction which must be further restricted is proof of (a) 
underspecification error in a mechanism specification, or (b) a 
restriction of policy.

we seem to be discussing the first case, not the second, when 
discussing texts prior to liman's. we seem to be discussing the second 
case, not the first, and with no claim of underspecification of 
restriction of policy, when discussing liman's text.

> I think your earlier message meant that before RFC 1123 the allocation
> policy did not exactly match the permitted syntax, e.g. double hyphens and
> single character labels were permitted by the syntax but not allocated;
> initial digits were not permitted by the syntax but were allocated (and
> eventually the documented syntax caught up with the policy).
>
> I also think you are agreeing with my argument that alpha-only TLDs are a
> policy matter.

i thought that was obvious, but yes, and more broadly, that 
over-constraint is a distraction at best, and potentially worse than a 
mere distraction. no one should have any illusions about the scope of 
error possible, as there are two roots right now, and managing the 
requirements for their increased divergence seems prudent.

and my preference is for no i-d at all at this point. i don't want to 
be in cartagena next week or san francisco next spring or ... and hear 
someone say "the ietf made us do it" for some unfortunate value of "it".

-e