Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available

Eric Brunner-Williams <ebw@abenaki.wabanaki.net> Mon, 21 July 2014 19:41 UTC

Return-Path: <ebw@abenaki.wabanaki.net>
X-Original-To: internetgovtech@ietfa.amsl.com
Delivered-To: internetgovtech@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9E41A00AB for <internetgovtech@ietfa.amsl.com>; Mon, 21 Jul 2014 12:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.134
X-Spam-Level: *
X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334] autolearn=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 OB60itPdmIfK for <internetgovtech@ietfa.amsl.com>; Mon, 21 Jul 2014 12:41:30 -0700 (PDT)
Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6C11A0398 for <internetgovtech@iab.org>; Mon, 21 Jul 2014 12:41:28 -0700 (PDT)
Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id s6LJesCS083859 for <internetgovtech@iab.org>; Mon, 21 Jul 2014 12:41:06 -0700 (PDT) (envelope-from ebw@abenaki.wabanaki.net)
Message-ID: <53CD6CBC.40804@abenaki.wabanaki.net>
Date: Mon, 21 Jul 2014 12:40:44 -0700
From: Eric Brunner-Williams <ebw@abenaki.wabanaki.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internetgovtech@iab.org
References: <A193D048-2B67-469A-93BA-C61BB362DA75@vigilsec.com> <53CD1E8A.1060804@acm.org> <FA4238C4-ADDC-435F-9591-E3B074C2F6F6@vigilsec.com> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info> <53CD4A4B.4090507@abenaki.wabanaki.net> <20140721174703.GB17107@mx1.yitter.info>
In-Reply-To: <20140721174703.GB17107@mx1.yitter.info>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/wSgt844TQ6DP0tPP2scMffnSRE8
Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available
X-BeenThere: internetgovtech@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <internetgovtech.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=unsubscribe>
List-Archive: <http://www.iab.org/mail-archive/web/internetgovtech/>
List-Post: <mailto:internetgovtech@iab.org>
List-Help: <mailto:internetgovtech-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 19:41:32 -0000

Andrew,

If I wrote that there was "something wrong with that", you're response 
would be ... responsive.

You've observed that, in your opinion, "names fall squarely into ICANN's 
purview", and I've pointed out that there are examples where the policy 
of the GNSO, the only ICANN ByLaws entity with responsibility for names 
policy, has been altered by third-parties.

See also Avri's note on some restrictions on labels offered by some 
third-parties.

Eric

P.S. Exactly what is wrong with 5 octet labels? With 4 octet labels? 
With 3 octet labels? And finally, with 2 octet labels?

P.P.S. Exactly what is wrong with a terminal label consisting only of 
characters in the 0-9 range, that is not completely cured by a 
requirement that the next subordinate label contain one or more 
characters from the range g-z?

On 7/21/14 10:47 AM, Andrew Sullivan wrote:
> On Mon, Jul 21, 2014 at 10:13:47AM -0700, Eric Brunner-Williams wrote:
>
>> When applicants (note the plural) sought single Han script character
>> (necessarily 5 or more octets) labels in the IANA root, the IETF's
>> liaison objected, and when an applicant sought to use only
>> characters in the 0-9 range as a label in the IANA root, again, the
>> IETF's liaison objected.
> Right.  What's wrong with that?  In that case, we've actually created
> a formal mechanism for the IETF to deliver its opinions to ICANN -- a
> liaison.  Also, because all the relevant communities (IETF, ICANN, all
> the RIRs) run open, community-driven processes, people can have a foot
> in both worlds: there's nothing that says you have to participate in
> only one community.  I think you'd be seeing a very different set of
> proposals if some of these communities were closed.  But they're not,
> and I don't think it's worth inventing a process for a problem we
> don't have.
>
> Anyway, by and large, there are three areas of interest here with
> three associated communities _qua_ community.  I'm not sure I see how
> trying to mix that up (and invent a complete new process by which we
> co-ordinate across these communities in real time) is better than
> saying, "Just use the existing processes we have for the three broad
> areas."
>
> Now, are there some corner cases?  Of course.  But reasonable
> engineering says that, for a one-time event, you can deal with the
> small number of corner cases one at a time by hand, rather than create
> a process.
>
> Best regards,
>
> A
>