- Quick Links
Clarification of Legal Issues from ccNSO Launching Group Questions
Date:28 January 2004
To: ccNSO Launching Group
Subject: Clarification of Legal Issues from ccNSO Launching Group Questions
Date: 28 January 2004
The ccNSO Launching Group forwarded a set of questions it had received from the community, requesting clarification of legal issues surrounding the ccNSO. Please find below my response to these questions.
1) What is the legal nature of the ccNSO, and thus what is the ccNSO / ICANN relationship?
A - The Internet's domain name system was established and put into place under the direction of Jon Postel, pursuant to research contracts from the United States' Government. Subsequently, it was decided that a global, consensus-based management organization would be more appropriate in developing and implementing the relevant DNS framework of technical parameters and procedures, taking into account the interest of all relevant Internet users. Further developing Jon Postel's work into a new arrangement however necessitated a careful transition mechanism which would not jeopardize the stability and functioning of the Internet itself. As a result, it was decided to maintain the new organization's location at the very premises of where the technical facilities were located, namely Marina Del Rey, California. In addition, it was necessary to find a legal base for the organization which would allow it to operate in a manner consistent with its mission. The Californian law system allowed for the creation of a public benefit non-profit corporation, a legal structure similar to a public trust in other legal systems. Accordingly, ICANN was provided with such legal status. In November 1998, the United States Department of Commerce ("DOC") first entered into a Memorandum of Understanding ("MOU") with ICANN. The MOU granted ICANN responsibility for, among other things, the technical management of the domain name system.
The supporting organization concept was utilized in the creation of ICANN, so that various Internet community groups could participate in the "consensus" management model, upon which ICANN was founded. A supporting organization, such as the ccNSO will be when launched, is a group that will have no formal legal structure and will not be an independent entity that exists outside of ICANN. That is, the ccNSO is a part of ICANN.
ICANN's organizational structure has been previously set out. In a letter from ICANN's counsel regarding the role and function of the various supporting organizations from August 2000 to the US Internal Revenue Service, it stated as follows:. "In response to your questions regarding the organization, purpose, and authority of the Supporting Organizations ("SOs") of the Internet Corporation for Assigned Names and Numbers ("ICANN"). [..] the ICANN SOs are consensus-based advisory bodies within the ICANN framework. The SOs are not independently organized entities. Rather, they are, in effect, internal ICANN working committees whose primary purpose is to make policy recommendations to ICANN's Board of Directors and to ensure that those recommendations are made only after receiving input from members of the Internet community interested in those issues."
ICANN, the ICANN SOs, and various working groups continually post draft and final policy discussions and recommendations and solicit public comment. This represents an open and dynamic consensus-building process which actively encourages participation by all interested members of the general public.
The ICANN SOs have been carefully organized and composed to encourage and administer broad-based public participation in the Internet policy formulation process. The SOs provide a framework for identifying policy issues regarding the technical management of the Internet, and a conduit for receiving and addressing public comment. Rather, the SOs are a loosely structured public forum allowing ICANN to consider all viewpoints when crafting Internet policy, as it relates to ICANN's "Mission" and "Core Values" as defined in ICANN's By-Laws, Article I, Sections 1 and 2.
See also questions 5, 7, 8, and the respective answers to these questions.
2) Is delegation and re-delegation a policy issue or an operational issue? If one or the other, why? Also, where and how is it defined in the by-law?
A - The Internet Assigned Numbers Authority (the IANA), as part of the overall administrative functions associated with management of the domain-name system root performed by ICANN, is responsible for receiving requests for delegation and re-delegation of top-level domains, investigating the circumstances pertinent to those requests, and reporting on the requests. For the duration of the transition regime, ICANN's involvement is provided under the contract for performance of the IANA function between the United States Government and ICANN. Under that contract, ICANN performs the IANA function, which includes receiving delegation and re-delegation requests concerning ccTLDs, investigating the circumstances pertinent to those requests, and making its recommendations and reporting actions undertaken in connection with processing such requests.
So to clarify, it is a policy issue in respect to the setting or re-setting of the "rules" for delegations and re-delegations and an operational issue in respect to the carrying out of those rules.
Delegations and re-delegations are not defined by ICANN's by-laws. It is important to note that policy development in this area will likely occur and such policy development will involve the ccNSO.
To date, in acting on re-delegation requests, the IANA currently follows the practices summarized in "Internet Domain Name System Structure and Delegation" (ICP-1), defined in the policy development processes of its constituent bodies, and thus the global Internet community, and decided on that basis by the ICANN Board. ICP-1 represents an update of the portions of RFC 1591 (which was issued in March 1994) dealing with ccTLDs, and reflects subsequent documents and evolution of the policies followed by the IANA through May 1999.
3) To what extent do non-cc-PDP developed policies apply to ccNSO members?
A - This is answered by Article IX, Section 4, Clause 10 which states:- "Policies shall apply to ccNSO members by virtue of their membership to the extent, and only to the extent, that the policies (a) have been developed through the ccPDP as described in Section 6 of this Article, and (b) have been recommended as such by the ccNSO to the Board, and (c) are adopted by the Board as policies, provided that such policies do not conflict with the law applicable to the ccTLD manager which shall, at all times, remain paramount. In addition, such policies shall apply to ICANN in its activities concerning ccTLDs." Beyond that, the same policies that would apply to non-ccNSO member will apply to a ccNSO member.
4) Article IX.4.10. reads:
"A ccNSO member may provide a declaration stating that (a) implementation of the policy would require the member to breach custom, religion, or public policy, and (b) failure to implement the policy would not impair DNS operations or interoperability, giving detailed reasons supporting its statements. After investigation, the ccNSO Council will provide a response to the ccNSO member's declaration. If there is a ccNSO Council consensus disagreeing with the declaration the response shall state the ccNSO's Council's disagreement. Otherwise, the response shall state the ccNSO Council's agreement. If the ccNSO Council disagrees, the ccNSO Council shall review the situation after a six-month period. At the end of that period, the ccNSO Council shall make findings."
The above paragraph describes a relatively complex procedure, but seems to lack a crucial adjudication part and consequence part. Therefore, it describes how the council will come to determine the "truth" of a member's declaration, but it does not specifically state what the implications are if the ccNSO Council "agrees" with the member's declaration.
Therefore, the question that this paragraph raises is: based upon what principles & criteria will the council determine "disagreement" or "agreement" and what are the consequences of either?
Additionally, it is anticipated that clarification of Article IX.4.10 may be addressed in some clarifications to this section of the bylaws.
A - There are no prescribed principles and criteria for the Council to determine disagreement. There are no consequences specified for disagreement by Council as to any aspect of a member's declaration, other than the impact of the formalized ccNSO Council's publicly-stated disagreement. Article IX 4.10 was drafted specifically to allow a ccNSO member to opt out with no consequences but to allow the ccNSO Council to publish a document saying that it disagreed with the opt out.
5) What are ICANN's and the ccNSO's enforcement powers to "enforce" their policies on ccNSO members?
A - ICANN's enforcement powers over a ccNSO member are no different than policy enforcement powers over a non-ccNSO member.
The ccNSO does not have 'policies' to enforce. The ccNSO may have its own internal rules but that is a matter for it to decide upon. The ccNSO makes policy recommendations to the board and if those recommendations become policy the ccNSO has no role in 'enforcement' of that policy. The ccNSO does however have the right to say that it disagrees with a member opting out of that policy (see 4 above).
6) What are ICANN's and the ccNSO's rights, powers, and enforcement methods to terminate ccNSO membership?
A - There are no specific rights powers, or enforcement methods uniquely created or provided to ICANN to terminate a ccTLDs membership of the ccNSO. The ccNSO itself may wish to put in place an internal mechanism to allow for termination of membership but that is a matter for the ccNSO.
7) What is the implication of termination (voluntarily or forcefully) by a ccTLD, i.e., what legal obligations, in ICANN's views will remain?
A - The ccNSO is not beholden to, or controlled by, any one group, industry, government, business entity, or viewpoint. If a ccTLD leaves the ccNSO, it is treated like any other ccTLD that is not a member of the ccNSO.
Joining the ccNSO does not create a contractual relationship with ICANN, and thus there are no doctrines or other aspects of California or US law that will impose any associated burden.
8) What is the difference between a ccNSO member and a non-member (former or never been member) when dealing with the applicability of the general ICANN by-law clauses, terms, and conditions, paragraphs, etc?
A - There is no difference; the main reason to become a ccNSO member is simply to stand together with your fellow ccTLDs to have a voice in developing and/or changing policy that effects ccTLDs.
If you have any additional questions or we may further clarify the answers above, please feel free to contact us.
John O. Jeffrey
General Counsel, ICANN
cc: ccNSO Launching Group
Dr. Paul Twomey