RE: [Ianaplan] Last Call: <draft-ietf-ianaplan-icg-response-06.txt>

[Milton L Mueller <[e-mail]>]

These comments are a response to the last call on the IETF's Draft Response to the Internet Coordination Group Request for Proposals (hereafter, "IANA Plan draft"). These comments are submitted by the Internet Governance Project (http://internetgovernanceorg). 

In our view, the IANA Plan draft is an incomplete but marginally acceptable proposal. It did achieve rough consensus in the working group, and IGP went along with that rough consensus based on a final set of modifications that responded to some of our concerns. 

Rough consensus could only be achieved, however, by avoiding rather than resolving some major points of contention. Instead of specifying particular changes that need to be made during the transition, the draft sets out some general "requirements" and authorizes "any supplemental agreement(s)" that might be necessary to achieve them: 

"What is necessary as part of transition is the completion of any supplemental agreement(s) necessary to achieve the requirements outlined in our response in Section III of this RFP." 
(Response to Section IV, page 14, IANA Plan Draft)

Presumably, these supplemental agreement(s) are to be developed by the IAOC and negotiated with ICANN, though the IANA Plan Draft's failure to clearly specify this is one of its weaknesses. 

We understand that the IANA Plan draft could not become more specific without sacrificing higher levels of support in the WG. But we also believe that the unresolved issues are extremely significant to the IETF and to the future of Internet governance. We believe that the dominant faction in the IANA Plan WG was too focused on current satisfaction with IANA service and not sufficiently focused on providing a resilient, long-term institutional framework for global internet governance, which is what the NTIA and ICG are asking for. 

However, the IANA Plan draft does authorize the IETF and its legal advisors to negotiate new "supplemental" agreements with ICANN. These comments are intended to provide information to the IETF's leadership regarding what the unresolved issues were, why it is important to resolve them, and how it might respond to them with supplemental agreements. Nothing advocated here is inconsistent with the IANA Plan Draft. 

The "requirements" specified in the draft are: 
 1. A formal acknowledgement by ICANN or any future IANA functions operator that the protocol parameters registries are in the public domain

 2. In the event of a decision by IETF to change its IANA functions provider, it asks for a formal acknowledgement by ICANN that: 
    a) ICANN will carry out the obligations established under C.7.3 and I.61 of the current IANA functions contract with the NTIA. (C.7.3 requires ICANN to have a plan in place to transition the IANA functions to another operator, and I.61 requires ICANN to cooperate with a new operator to maintain continuity of service.)
    b) ICANN, the IETF, and subsequent operator(s) will work together to minimize disruption in the use the protocol parameters registries or other resources currently located at iana.org

While we enthusiastically support these requirements and view them as a good basis for the IETF's response to the ICG, we think 1) and 2)b) are underspecified and thus create the potential for conflict in the future. We also have doubts about the ability of the current MoU to make any "acknowledgement" by ICANN of 2)a) legally binding. 

A significant segment of the Working Group wanted the IANA Plan draft to call specifically for the transfer of the iana.org domain and the IANA trademark, which are currently held by ICANN, to the IETF or the IETF Trust. Such an approach would cost ICANN nothing while upholding the principle that the IANA protocol registry is a service provided to IETF by ICANN rather than a permanent, 'owned' feature of ICANN, Inc. Continued ownership of the domain and trademark by ICANN raises the switching costs of changing the IANA functions contractor and could lead to confusion in the event of an unfriendly change. We found the arguments against requesting the transfer of the domain and trademark to be specious and untransparent; in effect, opponents were claiming that asking for these resources would lead to punitive or undesirable counter-demands from ICANN, though no evidence for this claim was ever offered. 
Similarly, a significant segment of the IANA Plan WG wanted the relationship between IETF and ICANN to become a more formal contractual one. As John Curran, the CEO of the American Registry for Internet Numbers, wrote: 

"There was one potentially significant concern raised in WG last call that was not accommodated - specifically, adding a requirement for strengthened legal and contractual IANA arrangements for the post-NTIA period. The draft doesn't preclude stronger legal/contractual measures, but it also does not note such as a specific requirement for future IANA arrangements." 

We believe that there are serious ambiguities about the legal/contractual status of RFC 2860, which describes the MoU between the IETF and ICANN, and these ambiguities could become problematic in the future. The issues were best described by Greg Shatan, a lawyer working as one of the chairs of the IANA functions transition process in the names operational community, as follows:  

Shatan: [I]n the [2000 MoU between the IETF and ICANN], the IETF is identified as an "unincorporated association."  An "unincorporated association" is an odd bird among organizations.  My understanding of the situation (and this is in no way a "legal opinion") is this:  An unincorporated association is an organization of two or more members joined under an agreement of some sort, but not formally incorporated.  Traditionally, an unincorporated association has generally been viewed as not having "legal personality" (i.e., not a legal entity), and thus not capable of entering into contracts.  Where an unincorporated association (UA) purported to enter into a contract, typically U.S. law would disregard the UA and regard this as an agreement made by each of the members of the UA, who would then be considered personally liable under the agreement.  This has changed somewhat over the years, as a number of states have enacted laws redefining how UAs are regarded.  This is a matter of state law in the U.S., so the treatment of UA's varies by state.  So, what law applies to IETF as a UA?  Since this is a state law question, it would generally be the state/jurisdiction where the IETF is domiciled, or (in the specific instance of a contract such as the ICANN MoU) the law of the contract.  I have not found a statement of where the IETF is domiciled; however, if it is part of ISOC (which it seems to be), then I would note that ISOC is incorporated in Washington, D.C. and is headquartered in Virginia.  So it is likely to be either DC or Virginia law that applies.  Under the current law of Washington, DC (enacted in 2012) a UA is deemed to be a legal entity with a separate existence from its members.  If a UA is a legal entity, then it can enter into an agreement.  More particularly, if IETF is an unincorporated association under DC law, it is a legal entity and can enter into contracts.  However, I believe the catch is this -- if IETF is considered to be a legal entity because we are applying DC law, it stands to reason that it is a legal entity existing under DC law.  In other words, the "jurisdiction" of the IETF would be Washington, DC...  A brief check of Virginia law seems to indicate that Virginia has not adopted laws deeming a UA a "legal entity."  Therefore, if Virginia law applies, it appears that IETF is not a legal entity, and is not actually capable of entering into an agreement in its own name (or, if it does, the agreement could be deemed to be an agreement entered into by all of its members collectively).  Note that I am referring to current law -- the law in 2000 (when the ICANN MoU was signed) might have been different (and probably less accepting of UAs as legal entities).  I also note that I am somewhat skeptical about the statement in the ICANN MoU that IETF is an unincorporated association, since its characteristics don't fit well with the typical definition of a UA, but perhaps IETF has an explanation for this statement.  Finally, if IETF is not a legal entity, but is viewed as a part of ISOC, it is possible that the ICANN MoU could be viewed legally as an agreement entered into by ISOC (but this has its issues, including whether the IETF Chair and the IAB Chair who signed the ICANN MoU have the authority to bind ISOC).

In conclusion, we would recommend that the IAOC utilize the discretion given to it by the IANA Plan draft to develop stronger legal and contractual arrangements with ICANN regarding the iana.org domain, the IANA trademark, and the conditions under which a transfer of the IANA functions contract to another operator could take place. The fact that IETF is currently happy with ICANN's IANA service should not prevent it from pro-actively putting into place a resilient legal and contractual framework to prepare for future contingencies. We believe that in the context of a politically sensitive transition supervised by the NTIA that ICANN would cooperate fully with these more specific requirements. 

One of the widely expressed concerns about the IANA transition is that each of the three operational communities (names, numbers and protocols) will have distinct contractual relationships with the IANA functions operator. While this capability maximizes the accountability of the IANA functions contractor to each individual operational community, it raises questions about what the status of the IANA functions provider will be if one of them wants to use a different IANA operator and the others don't. We believe that the transfer of the IANA trademark and domain to the IETF would contribute to a unifying mechanism. If IETF held these identifier resources in trust for the Internet community, it would be in a stronger position to ensure that, even if there were separate IANA operators for one or all of the three (names, numbers and protocols), that there would be some form of coordination and unity among them. As the origin of Internet protocols, the domain name space and the IP address number space, we see the IETF as the most appropriate entity to hold these resources.