Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment

Eric Brunner-Williams <ebw@abenaki.wabanaki.net> Wed, 23 February 2011 16:43 UTC

Return-Path: <ebw@abenaki.wabanaki.net>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B533A690A for <dnsext@core3.amsl.com>; Wed, 23 Feb 2011 08:43:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.229
X-Spam-Level:
X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 Cd4zUXPik-gX for <dnsext@core3.amsl.com>; Wed, 23 Feb 2011 08:43:30 -0800 (PST)
Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.133]) by core3.amsl.com (Postfix) with ESMTP id 9DC5B3A68C5 for <dnsext@ietf.org>; Wed, 23 Feb 2011 08:43:30 -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 p1NEvnnc052853 for <dnsext@ietf.org>; Wed, 23 Feb 2011 09:57:50 -0500 (EST) (envelope-from ebw@abenaki.wabanaki.net)
Message-ID: <4D653959.8070107@abenaki.wabanaki.net>
Date: Wed, 23 Feb 2011 11:44:09 -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.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: dnsext@ietf.org
References: <20110216165921.GW96213@shinkuro.com> <3B90ED2E-980D-4B01-889F-447D66D0B58D@insensate.co.uk> <20110216174011.GZ96213@shinkuro.com> <20110218143653.GC84482@bikeshed.isc.org> <20110218151209.GF66684@shinkuro.com> <4D5EEE09.4080405@dougbarton.us> <20110218222950.GL74065@shinkuro.com> <4D5F270F.20401@abenaki.wabanaki.net> <199C7B2B4228461FB024E59A990DB46D@ics.forth.gr> <4D641DB6.4090705@necom830.hpcl.titech.ac.jp> <20110222205617.GS53815@shinkuro.com> <4D64489B.7020901@necom830.hpcl.titech.ac.jp> <713D992A-1DB9-4F72-9D18-8E923AD51D8D@icsi.berkeley.edu> <4D647551.5060602@necom830.hpcl.titech.ac.jp> <A0895032-7141-4289-8C38-D8A4D287A9E9@ICSI.Berkeley.EDU> <4D649C0B.40905@necom830.hpcl.titech.ac.jp> <24BA1B5B-5FA3-4A94-8174-B82066702D57@ICSI.Berkeley.EDU>
In-Reply-To: <24BA1B5B-5FA3-4A94-8174-B82066702D57@ICSI.Berkeley.EDU>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [dnsext] we need help to make names the same, was draft-yao-dnsext-identical-resolution-02 comment
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2011 16:43:31 -0000

i think there are two unrelated issues:

>> dynamic generation is not feasible at all.

first, there are zones who's editors generate updates with on the 
order of 1 time/day, and zones who's editors generate updates with an 
order of 100 times/day.

requirements for the CNOBI business model is not a general requirement.

restated, for a large number of zones, including a plurality of zones 
who's editors have a contractual relation with a technical 
coordinating body, dynamic generation is simply not present or in plan.

> Remember, a cluster solution is ONLY needed for those heavily loaded authorities (TLDs, cc-TLDs) which require case insensitivity in non ASCII text, which is not all that many anyway.

second, overlooking the persistent error of using case to reason about 
caseless character repertoires, there is very limited experience with 
this use case at present.

it is possible that one or more arabic script registries, of arbitrary 
contractual or memorandum or other documented policy stripe, will 
elect to map arabic script labels and latin script labels (see "chat 
arabic").

i don't want to itemize the possible pairings (or poly pairings) that 
operators may choose to attempt, whether uniform or conditional in 
their zones, though i'm trying to write a candidate policy document 
for a technical coordinating body.

i simply want to suggest that "heavily loaded" may have a bi-modal 
distribution, and correlate to operators which map labels as a 
default, e.g., the .cn and similar operators for labels containing 
characters from the sc and tc repertories, and operators which do not 
map labels as a default, e.g., operators pursuing the CNOBI business 
model and monitizing each nominally distinct label.

> An authority that has more like a few hundred base names can just run on a single system, cache all the common cases, and call it good.

i hope this is several orders of magnitude lower than obtains for 
authorities offering a zone or zones in or between which label mapping 
for script and identifier support is offered.

hope springes eternal, etc.

-e