Re: [Ianaplan] A draft for your review

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 01 September 2014 08:41 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB541A01AF for <ianaplan@ietfa.amsl.com>; Mon, 1 Sep 2014 01:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.559
X-Spam-Level: **
X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 ZoHsoaiOs_ev for <ianaplan@ietfa.amsl.com>; Mon, 1 Sep 2014 01:41:46 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AA51A024C for <ianaplan@ietf.org>; Mon, 1 Sep 2014 01:41:46 -0700 (PDT)
Received: from crankycanuck.ca (unknown [81.213.20.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3CC0D8A031 for <ianaplan@ietf.org>; Mon, 1 Sep 2014 08:41:44 +0000 (UTC)
Date: Mon, 01 Sep 2014 11:41:38 +0300
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: ianaplan@ietf.org
Message-ID: <20140901084137.GA92502@crankycanuck.ca>
References: <54017E09.8060504@cisco.com> <GLEAIDJPBJDOLEICCGMNIEEACKAA.rhill@hill-a.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <GLEAIDJPBJDOLEICCGMNIEEACKAA.rhill@hill-a.ch>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/BLmNwjopJJ0xhujkV2Bih9WriXQ
Subject: Re: [Ianaplan] A draft for your review
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Sep 2014 08:41:47 -0000

Hi,

On Sat, Aug 30, 2014 at 03:29:34PM +0200, Richard Hill wrote:
> 
> I think that it would be better to include the full mandate, and to say: "In that announcement, NTIA asked the Internet Corporation for Assigned Names and Numbers (ICANN) to establish a process to deliver a proposal to transition key Internet domain name functions to the global multistakeholder community." 
> 

What does that add?  In particular, that suggests that the only think
NTIA was interested in was domain name functions, in which case the
protocol parameters registry would be irrelevant.  But we cannot
possibly read it that narrowly, of course, since the protocol
parameters are also in some sense covered by the NTIA-ICANN agreement.

> function is the Internet Engineering Task Force (IETF), which acts
> on behalf of the numerous implementers that use specific parameter
> values."

I would be strongly opposed to such a change.  The IETF does not act
"on behalf" of anyone.  We are not a representative body.  The IETF
acts for itself.

> 4) Related to the above, should consideration be given to adding a
> proper dispute resolution clause, that is, including choice of law
> and venue, to the agreement?  For example, that the venue for any
> disputes would be the seat of ISOC, which is the legal entity
> involved from the IETF side.

This suggests that the IETF's responsibility for these protocol
parameters should be submitted to some other body for arbitration.  I
don't think that's correct.  

> 6) In section 2, part IV, under "Transition Implications", the IETF response is "No structural changes are required." This is correct, but I think that some contractual changes are required in order to make it clear that the ultimate authority for the protocol parameters is IETF, not ICANN.
> 

> "At present, article I.1 of the ICANN Bylaws implies that ICANN has
> the overall responsibility for the coordination and allocation and
> assignment of the protocol parameters.

I don't read the Bylaws that way, and I don't think it's a plausible
interpretation.  The text says, "Coordinates the allocation and
assignment of the three sets of unique identifiers for the Internet,"
which does not imply overall responsibility for the allocation at all.
Overall responsibility is for co-ordination, which is, in my view,
exactly right.

> 7) There was extensive discussion (but no agreement) on the IANA
> Transition mailing list regarding whether or not the fact that a US
> court could, in theory, order ICANN/IANA to do something contrary to
> agreed community policies is an issue

Yes, of course.  US (and other countries') courts make bad rulings all
the time.  I don't think that the correct question is, "Is this an
issue?"  The correct question is whether it is an issue worth dealing
with in advance, particularly since it is hard ot know exactly how we
ought to deal with it.  In my view, the answer is, "No."  I think
there is at least as great a threat from creating another new large
bureaucracy as there is from some court issuing a bad decision that
affects us in an important way.

-- 
Andrew Sullivan
ajs@anvilwalrusden.com