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 rea!
son 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, bu!
t 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 I!
P address number space, we see the IETF as the most appropriate entity to hold
these resources.