Subject: [Ianaplan] A draft for your review

From: Eliot Lear <[email-masked]>
Date: Sat, 30 Aug 2014 09:32:25 +0200

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.

Subject: New Version Notification for draft-lear-iana-icg-response-00.txt
From: <[email-masked]>
To: Eliot Lear <[email-masked]>, Russ Housley <[email-masked]>, "Russ Housley" <[email-masked]>, Eliot Lear <[email-masked]>
Date: Fri, 29 Aug 2014 23:39:16 -0700

A new version of I-D, draft-lear-iana-icg-response-00.txt
has been successfully submitted by Eliot Lear and posted to the
IETF repository.

Name:		draft-lear-iana-icg-response
Revision:	00
Title:		Draft Response to the Internet Coordination Group Request for Proposals on IANA
Document date:	2014-08-30
Group:		Individual Submission
Pages:		17
URL:            http://www.ietf.org/internet-drafts/draft-lear-iana-icg-response-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lear-iana-icg-response/
Htmlized:       http://tools.ietf.org/html/draft-lear-iana-icg-response-00

Abstract:
   This document contains the a draft response to a request for
   proposals from the IANA Stewardship Transition Coordination Group
   regarding the protocol parameters registries.  It is meant to be
   included in an aggregate proposal that also includes contributions
   covering names and addresses that will be submitted from their
   respective operational communities.  The IETF community is invited to
   comment and propose changes to this document.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 30 Aug 2014 15:29:34 +0200

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:[email-masked]]On Behalf Of Eliot Lear
Sent: samedi, 30. août 2014 09:32
To: [email-masked]
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.

---

From: S Moonesamy <[email-masked]>
Date: Sat, 30 Aug 2014 07:38:33 -0700

Hi Eliot,
At 00:32 30-08-2014, Eliot Lear wrote:
>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:
>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.

   "The IETF is a global voluntary standards organization whose goal is
    to make the Internet work better [RFC3595]."

The IETF cannot be a MIB module. :-)

Quoting from the draft:

   "The customer of the IANA protocol parameters function is the Internet
    Engineering Task Force (IETF)."

The above is inconsistent with a stated IETF position.

   "1.  The IETF protocol parameter registry function has been and
       continues to be capably provided by the Internet technical
       community."

What is the "Internet technical community"?

   "The IETF uses the IANA protocol parameter registries for
    this purpose."

The above is not aligned with the stated position of the IETF.

Quoting two parts of the responses out of context:

   "It is important to note that the IETF includes anyone who wishes to
    participate, including anyone from ICANN or the RIRs, and many people
    from those organizations regularly do."

   "In-person attendance is not required for participation, and many
    people participate in email discussions that have never attended
    an IETF meeting."

I scanned the ietf@ mailing list archives and I did not find anyone 
from ICANN or the RIRs participating on that mailing list.

   "Because of the nature of the agreement, questions of jurisdiction are
    immaterial."

Why are questions of jurisdictions immaterial?

   "Any modifications to the protocol parameter registry function
    should be made using the IETF process"

The above is incorrect.

The IETF responses are not well-formulated in my opinion.  There 
isn't any reference to the IANA Functions contract.

As this topic has been mentioned I'll comment.  From 
https://www.icann.org/resources/pages/bylaws-2012-02-25-en

   "The mission of The Internet Corporation for Assigned Names and Numbers
    ("ICANN") is to coordinate, at the overall level, the global Internet's
    systems of unique identifiers, and in particular to ensure the stable
    and secure operation of the Internet's unique identifier systems.  In
    particular, ICANN:

    1. Coordinates the allocation and assignment of the three sets of unique
     identifiers for the Internet, which are

       "c. Protocol port and parameter numbers."

ICANN may have to adjust its bylaws if RFC 6220 is to be followed.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 Aug 2014 08:30:24 +1200

Hi,

I will review the draft carefully in due course, but I want to react
briefly to a couple of Richard's comments:

On 31/08/2014 01:29, Richard Hill wrote:
...

> 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?

I believe that we should explicitly not mention a legal venue. We should simply
stick to the IAB being in charge and the IESG being the technical decision
taker in case of doubt. We never, ever want to suggest that a court has
authority. (And if we did, we would definitely not want it to be a national
court anyway.)

...

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

IANAL, but that "notwithstanding" clause seems logically redundant. The existing
text (which was ratified by the ICANN Board in 2000) leaves no loophole. Personally
I think the risks in changing even one word in the existing MoU are too great.

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

While I'd love to see it happen, I think it's a separable issue so
should be left out of scope for now.

   Brian

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 31 Aug 2014 12:07:10 +0200

Dear Brian,

Thank you for these thoughtful comments.

Please see additional comments embedded below.

Best,
Richard

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: samedi, 30. août 2014 22:30
> To: [email-masked]
> Cc: Eliot Lear; [email-masked]; Russ Housley
> Subject: Re: [Ianaplan] A draft for your review
> 
> 
> Hi,
> 
> > 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?
> 
> I believe that we should explicitly not mention a legal venue. 

Whether you mention it or not, the legal venue exists.  Either party to the agreement (ICANN or ISOC) could take the other to court, arguing that the agreement is a contract.

>We 
> should simply
> authority. 

As noted above, there is no way to prevent one party from taking the other to court.  What the outcome might be is anybody's guess.

>(And if we did, we would definitely not want it to be 
> a national
> court anyway.)

I definitely agree with that.  But the only way to ensure that a national court cannot get involved is to specify an arbitration clause, something like:

"Any disputes arising out of or in connection with this agreement shall be finally settled by binding arbitration under the [commercial | international] arbitration rules of the [American Arbitration Association | Swiss Chambers' Arbitration Institution] by three arbitrators.  The language of arbitration shall be English.  The seat of arbitration shall be [New York, New York | Geneva, Switzerland].  The agreement shall be governed by the law of [California | New York | Switzerland]."

Obviously other possibilites exist for the bits in square brackets (I'm using the symbol | to indicate the option to choose one of the possibilities).

> > "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 ..."
> 
> IANAL, but that "notwithstanding" clause seems logically 
> redundant. 

I wouldn't be so sure about that.  The agreement is indeed clear, but what may not be clear is whether ICANN explicitly agreed that the agreement takes priority over its Bylaws.

The ICANN Board has a fiduciary duty faithfully to abide by the ICANN Bylaws.  Since the Bylaws imply that the Board is the ultimate decision-making authority, the Board might feel that the Bylaws have prededence over the agreement.

Of course if that ever happened ISOC could cancel the agreement, but, in accordance with the cancellation clause, that would leave ICANN in charge for six months, until ISOC establishes some other mechanism.

The possibility that the ICANN Board might override an IETF decision clearly does not arise at present, because the IANA Functions contract between ICANN and NITA specifies (in 1.2.9) that ICANN will implement the IETF policies/instructions.

But the issue here is how to replace that contract.  Once that contract is gone, there should be, in my opinion, some formal recognition by ICANN that it is not the ultimate authority, the ultimate authority is still the IETF.

That is, I think that something like the language in question is needed to replace the current contract between NTIA and ICANN. 

>The existing

What risks do you have in mind?

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

---

From: Eric Burger <[email-masked]>
Date: Sun, 31 Aug 2014 14:28:10 -0400

Anyone can take anyone to court anywhere. Both the Internet Society and ICANN are setting up offices that could be potential venues all over the world. Any one we chose today will be a bad one tomorrow. If we do not need to specify a venue today, and we have managed without one for the past decade and a half, let’s not start now.

On Aug 31, 2014, at 6:07 AM, Richard Hill <[email-masked]> wrote:

> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan

---

From: Eric Burger <[email-masked]>
Date: Sun, 31 Aug 2014 14:42:22 -0400

I like the humor, like the MIB dig. However, for the substantive comments, we should fix. 

Inline.

On Aug 30, 2014, at 10:38 AM, S Moonesamy <[email-masked]> wrote:

> [snip]
> What is the "Internet technical community”?

I think the disconnect is /direction/ for the IANA protocol parameters function comes from the IETF, which is an embodiment of the Internet technical community. The /input/ for the function is capably provided, not the /function/ itself. The language needs fixing.

How about:
The Internet technical community, through the IETF, has in the past and for the foreseeable future will provide direction to the IANA protocol parameter registry.

> The above is not aligned with the stated position of the IETF.

It is not that it is not aligned with the stated position of the IETF, it is that it is the IETF community, including implementers, “the IETF's primary users of the IETF standards and other documents,” that use the IANA protocol parameter registries. How about:

Many IETF protocols make use of commonly defined protocol parameters. Implementers use these parameters. Implementers are the IETF's primary users of the IETF standards and other documents.  A globally available registry contains the parameter values and a pointer to documentation of the associated semantic intent. This registry, the IANA protocol parameter registry, provides this service to ensure consistent interpretation of these parameter values by independent implementations.

> I scanned the ietf@ mailing list archives and I did not find anyone from ICANN or the RIRs participating on that mailing list.

RIR and ICANN people regularly come to IETF meetings, which means they participate. As we say, in-person attendance is not required for participation. Likewise, email discussions are also not required for participation. Thus, there is no inconsistency. Moreover, participation does not require posting. I will bet there are a lot of ICANN and RIR people subscribed (i.e., participating) to IETF email lists.

> Why are questions of jurisdictions immaterial?

See my other note to Richard.

>   should be made using the IETF process"

How? Any text for what you think it is / should be?

> 
> The IETF responses are not well-formulated in my opinion.  There isn't any reference to the IANA Functions contract.
> 
> As this topic has been mentioned I'll comment.  From https://www.icann.org/resources/pages/bylaws-2012-02-25-en
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 01 Sep 2014 08:02:04 +1200

On 31/08/2014 22:07, Richard Hill wrote:
...
> What risks do you have in mind?

Pressure to change something more fundamental as a result of
opening the document up at all for this relatively small
point.

   Brian