Re: [dnsext] BOF on variants for ICANN San Francisco

Doug Barton <dougb@dougbarton.us> Wed, 09 March 2011 19:35 UTC

Return-Path: <dougb@dougbarton.us>
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 B2EDC3A69D1 for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 11:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level:
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=1.047, BAYES_00=-2.599, GB_I_INVITATION=-2]
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 KfVnu132P5cP for <dnsext@core3.amsl.com>; Wed, 9 Mar 2011 11:35:45 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 5231C3A698B for <dnsext@ietf.org>; Wed, 9 Mar 2011 11:35:45 -0800 (PST)
Received: (qmail 11112 invoked by uid 399); 9 Mar 2011 19:36:58 -0000
Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 9 Mar 2011 19:36:58 -0000
X-Originating-IP: 75.60.237.91
X-Sender: dougb@dougbarton.us
Message-ID: <4D77D6D8.9070609@dougbarton.us>
Date: Wed, 09 Mar 2011 11:36:56 -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.15) Gecko/20110304 Thunderbird/3.1.9
MIME-Version: 1.0
To: Eric Brunner-Williams <ebw@abenaki.wabanaki.net>
References: <EE8A5F5A-26CD-474A-B983-32948A06DEBD@icann.org> <4D77D2AF.7010203@abenaki.wabanaki.net>
In-Reply-To: <4D77D2AF.7010203@abenaki.wabanaki.net>
X-Enigmail-Version: 1.1.2
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dnsext@ietf.org
Subject: Re: [dnsext] BOF on variants for ICANN San Francisco
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, 09 Mar 2011 19:35:46 -0000

On 03/09/2011 11:19, Eric Brunner-Williams wrote:
> I commend ICANN's staff variant project team for communicating (via Kim)
> a notice to the DNSEXT WG.
>
> I can recall no prior ICANN organized "IDN" activity to which an open
> invitation to the DNS (or IDN) technical community was offered -- every
> such activity I contributed to was due to accidental discovery on my
> part, not an invitation by ICANN.

One can pontificate on length at all the various individuals or groups 
that need/deserve special invitations to such an event. Or, one could 
realize that ICANN has been holding regular, public, and well-publicized 
events on the IDN topic since no later than 2004 (which is the first 
time I participated as a staff member).

> Unfortunately, the less than useful "variant" nomenclature is used, so
> one has to guess, assuming one differentiates between the issues
> presented by two very large character repertoires with a large
> intersection, character repertoires with sparse sub-repertoires of
> positionally dependent combining characters, character repertoires with
> pervasive diacriticals, or character repertoires with sparse or
> singleton pairs, the actual scope of work to be allocated to ICANN or
> the IETF.

ICANN meetings are primarily populated by policy-focused individuals, 
not technologists. An expectation that such individuals would develop 
the level of technical knowledge described above is not rational. 
Further, the term "variant" has a relatively well understood meaning in 
the TLD policy context, where it is generally understood to be a 
simplification of several thorny technical problems.

On the other hand, you and I agree that the fact ICANN is continuing to 
reach out the the technical community on this topic is a good thing.

> Unfortunately also, the temporal properties of "synchronized domains",
> the result of some prior, and limited consultation between participants
> to both the IETF and ICANN, is not noted as very difficult to achieve
> and not removed from the possible areas of work to be undertaken, at
> least by an IETF WG.

I don't think anyone involved thinks it's an easy problem, but maybe it 
hasn't been removed "from the possible areas of work to be undertaken" 
because some of us are actually working on it. :)


hth,

Doug

-- 

	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/