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

Doug Barton <dougb@dougbarton.us> Wed, 24 November 2010 02:15 UTC

Return-Path: <dougb@dougbarton.us>
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 B97B428C183 for <dnsop@core3.amsl.com>; Tue, 23 Nov 2010 18:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level:
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 Y8Klf+BQm+rb for <dnsop@core3.amsl.com>; Tue, 23 Nov 2010 18:15:13 -0800 (PST)
Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by core3.amsl.com (Postfix) with ESMTP id 63A0928C1AF for <dnsop@ietf.org>; Tue, 23 Nov 2010 18:15:13 -0800 (PST)
Received: (qmail 25868 invoked by uid 399); 24 Nov 2010 02:16:11 -0000
Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Nov 2010 02:16:11 -0000
X-Originating-IP: 127.0.0.1
X-Sender: dougb@dougbarton.us
Message-ID: <4CEC7569.6040104@dougbarton.us>
Date: Tue, 23 Nov 2010 18:16:09 -0800
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101028 Thunderbird/3.1.6
MIME-Version: 1.0
To: Joe Abley <jabley@hopcount.ca>
References: <B35360B6-0DB9-49CB-B68E-09DFFFB1ACA0@icann.org> <31FCAB67-9E3E-4E2B-957F-1A1F628AA8FB@hopcount.ca> <20101117091928.GA30093@nic.fr> <4CE9E942.20906@dougbarton.us> <0E561274-43FE-4657-951E-74C8FF0FD307@hopcount.ca> <4CEC43DC.1060709@dougbarton.us> <E7796748-6880-4928-B96D-0024E27E98D5@hopcount.ca> <4CEC69C5.3040209@dougbarton.us> <7B9EF625-1E25-42BE-9546-61C5B7EFC6DA@hopcount.ca>
In-Reply-To: <7B9EF625-1E25-42BE-9546-61C5B7EFC6DA@hopcount.ca>
X-Enigmail-Version: 1.1.2
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF DNSOP WG <dnsop@ietf.org>
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: Wed, 24 Nov 2010 02:15:14 -0000

On 11/23/2010 17:35, Joe Abley wrote:
>
> On 2010-11-23, at 20:26, Doug Barton wrote:
>
>> On 11/23/2010 16:19, Joe Abley wrote:
>>>
>>> 1. there is no restriction to be inferred from RFC 1123 that TLD
>>> labels be alphabetic;
>>
>> Unqualified "yes" to this.
>
> I presume you appreciate that not everybody shares your opinion on
> this.

Hence the word "incorrectly" in the diff I supplied.

It's also probably worth pointing out that I have been diligently trying 
to avoid the even-more-painful rathole of attempting to forensically 
determine the true meaning and intent behind the words. That said I have 
fairly strong suspicions with pretty good foundations that I understand 
why it was written the way it was, and I _still_ don't agree that the 
document, as written, defines a protocol restriction.

One could also travel down the more-painful-still rathole of things like 
'confirmation bias' that motivate people to see "evidence" of what they 
have always believed to be true even when it isn't there, but I'm pretty 
sure we don't want to go there.

>>> 2. it is better for deployed software to break than for the IETF
>>> to involve itself in anything resembling policy.
>>
>> A qualified "yes" here. I'm saying that in _this_ situation, the
>> IETF does not and should not have a policy role, and should limit
>> its commentary to the technical. There is (rather obviously at this
>> point) no _technical_ reason that TLD labels should be
>> all-alphabetic.
>
> Well, beyond the expectation in deployed software this should be the
> case. That's an operational consideration that I think is reasonable
> to describe as technical.

... which is why I'm willing to compromise as far as including a "Here 
be dragons" in your draft. But you could reductio this argument all the 
way down to not doing IDN TLDs at all, and solve the whole problem. For 
that matter, >3 character TLDs were clearly a mistake. Do you want to 
tell Cary that his delegation has been revoked, or should I?

The "deployed software will break" argument can be used as a reason not 
to do anything you choose to apply it to, especially in DNS. But whether 
it's worth it or not is a policy question. I'll say it one (hopefully) 
last time. There is no _technical_ reason why TLD strings cannot include 
digits, and the IETF should not say that there is.

>> Furthermore I am saying that the benefits of keeping the TLD
>> namespace open to all technically possible values outweigh the
>> costs. [...]
>
> I thought you weren't interested in discussing policy in the IETF?
> :-)


Doug (... and I'd have gotten away with it too, if it weren't for you 
meddling kids!)

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/