Re: [Ianaplan] A draft for your review

"Richard Hill" <rhill@hill-a.ch> Sat, 30 August 2014 13:29 UTC

Return-Path: <rhill@hill-a.ch>
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 3F9F81A0309 for <ianaplan@ietfa.amsl.com>; Sat, 30 Aug 2014 06:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham
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 LAga3-N7y2Fb for <ianaplan@ietfa.amsl.com>; Sat, 30 Aug 2014 06:29:52 -0700 (PDT)
Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [IPv6:2001:1600:2:5:92b1:1cff:fe01:18cc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372F41A029D for <ianaplan@ietf.org>; Sat, 30 Aug 2014 06:29:51 -0700 (PDT)
Received: from Laurie (adsl-89-217-22-32.adslplus.ch [89.217.22.32]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id s7UDTdTD015066; Sat, 30 Aug 2014 15:29:39 +0200
From: Richard Hill <rhill@hill-a.ch>
To: Eliot Lear <lear@cisco.com>, ianaplan@ietf.org
Date: Sat, 30 Aug 2014 15:29:34 +0200
Message-ID: <GLEAIDJPBJDOLEICCGMNIEEACKAA.rhill@hill-a.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <54017E09.8060504@cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/T7P19CaTEG0SF6lDOrFKCE1x9v0
Cc: Russ Housley <housley@vigilsec.com>
Subject: Re: [Ianaplan] A draft for your review
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: rhill@hill-a.ch
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: Sat, 30 Aug 2014 13:29:55 -0000

Dear Eliot and Russ,

Thank you very much for this excellent draft.

I have some comments, some minor, some rather more substantive.

1) In section 1, the draft says "In that announcement, NTIA asked the Internet Corporation for Assigned Names and Numbers (ICANN) to establish a process to deliver a proposal for transition."

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." 

2) In section 2, Part I, the proposed IETF response is "The customer of the IANA protocol parameters function is the Internet Engineering Task Force (IETF)."

I think that this is literally true, but I think it is also worth noting here (as the draft does later on) that the real users of the protocol parameters are various implementers.  So perhaps this could be modified to read: "The customer of the IANA protocol parameters function is the Internet Engineering Task Force (IETF), which acts on behalf of the numerous implementers that use specific parameter values."

3) In section 2, Part III, at the end, the proposed IETF response is "Because of the nature of the agreement, questions of jurisdiction are immaterial."  I don't think that this is appropriate, because the agreement in question might well be considered a contract. I don't see any choice of law or venue clause in the MoU or its 2014 Supplemental Agreement, so I think that the current situation would better be reflected as follows:

"Because of the nature of the agreement, and its dispute resolution and escalation clauses, it is not expected that any disputes would arise that would require court interventions."

And you might wish to add "Should any such disputes arise, the jurisdiction would be the compentent jurisdiction depending on the nature of the dispute and the parties to the dispute."

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.

5) In section 2, part IV, the proposed IETF response is "No changes are required, as over the years since the creation of ICANN, the IETF, ICANN, and IAB have together created a system of agreements, policies, and oversight mechanisms that covers what is needed."

I would suggest that this be slightly modified to read "No operational changes are required, ..."

The reason for this change is that some non-operational changes may be required, see below.

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.

So I would propose to add, at the end of that section, the following three paragraphs.

"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. That article should be modified to make it clear that, as specified in RFC 2860, it is the IETF that has the overall responsibility for the coordination and allocation and assignment of the protocol parameters.

"And item 4 of RFC 2860 should be modified to read as follows:

"4. Agreed technical work items.  ICANN agrees, notwithstanding any provisions in its Bylaws or other corporate documents that might be construed differently, that during the term of this MOU it shall cause IANA to comply ..."

For reference, item 4 of RFC 2860 currently reads "4. Agreed technical work items. ICANN agrees that during the term of this MOU it shall cause IANA to comply ..."

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 and, if so, whether anything should be proposed to deal with that issue, such as proposing that the entity that performs the IANA function should have immunity of jurisdiction, or that the entity should have redundant sites in more than one jurisdiction.

If there is support for dealing with that issue, then some text could be added.  

Thanks again for the great work and best,
Richard

-----Original Message-----
From: Ianaplan [mailto:ianaplan-bounces@ietf.org]On Behalf Of Eliot Lear
Sent: samedi, 30. août 2014 09:32
To: ianaplan@ietf.org
Cc: Russ Housley
Subject: [Ianaplan] A draft for your review


Dear colleagues,

I have posted a -00 draft that seeks to respond to the most current version of the RFP I could get my hands on.  Would you kindly provide some thoughts about it?  I am most particularly concerned about substance at the moment.  The sorts of things I'm looking for are these:

Is the text in the "IETF Response" accurate and in fact responsive to the question? 
Is there anything missing? 
Is there anything that does not parse well?  Did you think "Huh??" when you read a sentence? 
My intent is to have a second version out prior to the cutoff for the Honolulu meeting as a candidate for the IANAPLAN working group to adopt, assuming the working group is chartered.

Kind thanks to Russ Housley and the members of the IAB IANA Strategy Program for their very helpful contributions.  I've indicated myself and Russ as editors, because we have not been the only ones to insert text on this.

Eliot
ps: I am aware that the formatting could stand some improvement.  I will work on that for the next version.