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

Dear Milton,

Thank you for your comments.  I believe you have accurately explained
why it would be difficult to change the text in this draft.  Because
your email contains a suggestion for the IAOC, I have forwarded your
message to them for their consideration.  Thank you also for providing
the quote from Mr. Shatan, which I have forwarded to Jorge Contreras,
the IETF's counsel for his information.

Regards,

Eliot

On 12/8/14, 11:14 PM, Milton L Mueller wrote:
> 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.

signature.asc
Description: OpenPGP digital signature