ICANN News

your unofficial source for daily ICANN news and commentary

Thursday, February 23, 2006

 

Registry Operators: On Objections to Settlement
 

From the Registry Constituency website:

Registry Operators’ Submission
Re: Objections to the Proposed Verisign Settlement

The undersigned registry operators submit this statement in response to certain objections being voiced with respect to the proposed registry agreement between ICANN and Verisign for operation of the .com registry. We are concerned that many of the objections being voiced in this debate reflect either (i) a serious misreading of the actual terms of the proposed agreement or (ii) a very worrisome perspective about the extent to which individual members of the ICANN community can and/or should be empowered to dictate the terms and conditions contained in ICANN’s commercial agreements with DNS service providers. While this statement is submitted by the undersigned members of the registry constituency, our concerns involve fundamental checks and balances built into the ICANN process that are designed to protect both registries and registrars alike.

A Brief History of ICANN’s Policy Authority

ICANN was conceived from the beginning as an organization with a limited charter. This understanding is reflected in ICANN’s by-laws, which contemplate policy development only on issues within ICANN’s mission statement. As specifically set forth in the ICANN by-laws, for examples, only mission-related issues are properly the subject of a PDP.


As articulated in its mission statement, ICANN is responsible for coordinating specified technical functions including:

The allocation and assignment of domain names, IP addresses and numbers, and protocol port and parameter numbers; and
The operation and evolution of the DNS root name server system.
ICANN is also responsible for policy development “reasonably and appropriately related to these technical functions.”

The limited nature of ICANN’s mission is also reflected in the original contracts between ICANN and NSI, and in every registry agreement (RA) and registrar accreditation agreement (RAA) executed since that time. In its original agreements with ICANN, for example, NSI agreed to comply with “consensus” policies adopted by ICANN provided (i) that such policies did not unreasonably restrain competition and (ii) that the policies related to:

Issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability and/or stable operation of the Internet or domain-name system;

Registry policies reasonably necessary to implement consensus policies relating to registries and/or registrars; or

Resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names).
The parties also acknowledge that ICANN should have policy-making authority in certain other areas (e.g., to develop the UDRP) involving issues that, while specifically considered in the White Paper, may not have been strictly technical in nature. To avoid subsequent disagreements about these issues, the original registry agreements and registrar accreditation agreements contained a list of specific areas in which ICANN was deemed to have legacy policy authority, as follows:

Allocation principles (e.g., first-come/first-served, timely renewal, holding period after expiration; surviving registrars);

Prohibitions on warehousing or speculation;

Reservation of SLD names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and single-letter/digit names); and

Dispute resolution policies related to registration of domain names.

Taken together, the general policy making authority granted to ICANN to preserve the stability and security of the DNS and the legacy policy authority listed above created a “picket fence” around ICANN’s authority. ICANN could establish policy and/or best practices affecting issues outside the picket fence, but could not mandate registry and registrar compliance with such policies. ICANN’s ability to impose policy prospectively on registries and registrars was further constrained by procedural safeguards (ICANN’s first PDP) designed to demonstrate the presence of a “true consensus” - i.e., the absence of substantial objections.

When the first new TLDs came online in 2001, the “picket fence” was retained, with only minor refinements. This was no accident: even though operators of the new registries had virtually no bargaining power, the agreements reflected the community’s settled understanding about ICANN’s authority. ICANN was empowered to impose policies - even prospectively - on DNS service providers in a limited number of areas related to interoperability, technical reliability, operational stability, the safety and integrity of the Registry Database.

By 2002, it was widely (but not universally) conceded that the standard for measuring consensus laid out in the Registry Agreements and the Registrar Accreditation Agreements was unworkable. The standard by which consensus was measured - the absence of substantial opposition - was a barrier to policy development. Accordingly, as part of ICANN’s “evolution and reform (ERC)” process, ICANN amended its by-laws to include the GNSO PDP process. Under that process, ICANN could develop and adopt consensus policies, even in the face of substantial opposition, so long as the policy area was within ICANN’s mission statement and ICANN followed specified procedures in developing such policies.

The ERC process not only embraced the concept of the “picket fence” - it incorporated those substantive constraints into ICANN’s bylaws in the form of a mission statement. Post-ERC registry and registrar agreements continued (as they do to this day) to limit the scope of permissible topics for mandatory specifications and policies. In effect, registrars and registry operators confirmed their agreement to abide by subsequently developed ICANN policies so long as those policies were (i) necessary to facilitate interoperability, technical reliability, operational stability on the DNS or the Internet, and the safety and integrity of the Registry Database, or (ii) covered by ICANN’s legacy authority.

Some might argue that the constraints on ICANN’s policy authority are artificial, and should be abandoned. That would be a mistake. The protections of the picket fence and the procedural safeguards are today - just as they were when first agreed - the ultimate source of ICANN’s legitimacy. Private commercial actors - registries and registrars - voluntarily ceded to ICANN, via contractual undertakings, the authority it needed to fulfill ICANN’s legitimate mission. ICANN’s authority is legitimate because the delegation of authority was necessary, but no more than needed, to create policy in areas requiring coordination. ICANN is recognized as a legitimate private standards setting body because its authority answers but does not exceed that needed to perform its legitimate coordinating functions. Absent these constraints, ICANN’s authority would be vulnerable to challenges under the competition laws of most countries participating in ICANN through the GAC.

The Registry Agreement


Notwithstanding the arguments of some of those opposed to the Verisign settlement, the new agreements - including the Verisign agreement - are, with regards to fundamental policy considerations, entirely consistent with the prior agreements.

First, the new agreements obligate registry operators to agree in advance to comply with consensus policies as they are developed in the future.

Second, the new agreements include a picket fence not dissimilar to those found in every registry agreement since 1999. Registry operators must promise to comply with existing and prospective “consensus policies" relating to a very familiar set of issues, including:
Issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS; Functional and performance specifications for the provision of registry services;
Security and stability of the registry database for the TLD;
Registry policies reasonably necessary to implement consensus policies relating to registry operations or registrars; or
Resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names).
As before, the agreements specifically grandfather policies relating to name allocation, warehousing, speculation, IP protection, Whois data, and registration disputes.

As a result, the undersigned registry operators believe that in general, while registries are not equal and there are fundamental differences between sponsored and non-sponsored TLDs, the future agreements and contract renewals should be made consistent with the .com agreement as applicable, and that Registries should be treated on an equitable basis.

Those objecting to the proposed agreement for .com ignore the fundamental continuity and focus instead on presumptions of renewal and the pricing authority. But unless those who object can make a reasonable case that the disputed terms and conditions threaten ICANN’s ability to preserve interoperability, stability, and security, they are not properly the subject of ICANN consensus policy-making.

As a threshold matter, consensus policies must fit within the constraints ICANN has acknowledged from the start - i.e., in order to be binding on registries and registrars, the resulting policies must be reasonably necessary to facilitate interoperability, security and stability of the Internet or the DNS, or relate to the resolution of disputes regarding the registration (as opposed to the use) of domain names.

The GNSO has recently undertaken to draft terms of reference for a PDP to establish the terms and conditions under which existing registry agreements will be renewed. Because this draft TOR is presumably motivated by dissatisfaction about the new registry agreements in general, and the proposed agreement for .com in particular, it provides important context for the objections to the proposed registry agreement for the .com TLD. Accordingly, the scope of the proposed PDP is relevant to the Board’s consideration of the Verisign settlement, and weaddress below certain provisions of the draft TOR that appear to be parallel objections to the .com agreement.

Registry Agreement Renewal. The draft TOR asks “What benefits does the ICANN community derive from presumptive rights of renewal?” This is simply the wrong question. Unless a reasonable case can be made that such presumptions pose a threat to interoperability, security, and/or stability, the question of renewal presumptions can not be a subject for consensus policy making and must, we submit, be resolved through commercial negotiations. Again, that is not to say that the GNSO council is not entitled to develop a view. For example, the draft PDP TOR might appropriately ask:

Do presumptions of renewal pose a threat to interoperability, security, and stability of the Internet and DNS, or undermine existing consensus policies on name allocation, warehousing, Whois data, and registration disputes?

While the undersigned registry operators believe that the answer is a rather emphatic “no,” we have no objection to a serious debate on the question.

Registry Agreements and Consensus Policies. The draft TOR asks whether registry contract provisions should ever be immune from the obligation to abide by consensus policies. This could be an interesting question, and properly constructed, within the scope of a PDP. But it is simply not on the table in connection with the new registry agreements: nothing in any of the new sTLD agreements, in the .net agreement or in the proposed .com agreement with Verisign permits a registry operator to ignore a policy that is (1) adopted in accordance with the PDP procedures, and (2) necessary to preserve the interoperability, security, and stability of the Internet.

Whatever one thinks about proposed agreement between ICANN and Verisign for the .com registry, it does not except Verisign from the obligation that all registry operators have to comply with applicable consensus policies. To the extent that the proposed contract has language that does not appear in other new agreements, that language is nothing more than a belt-and-suspenders exercise that, given the circumstances under which this contract was negotiated, should surprise no one. The fact that ICANN cannot expand the scope of its consensus policy authority beyond interoperability, stability, and security and the legacy policy authority areas is consistent with ICANN’s mission statement and reflected in every registry agreement ever negotiated. Simply put, ICANN does not have the authority to adopt a new mission and then unilaterally obligate registries or registrars to comply with related policies.

The Importance of Negotiating Flexibility

The GNSO is, of course, free to recommend whatever course of action its members agree on. Likewise, individual members of the ICANN community are free to express their views on the proposed settlement. But the community should understand that an issue outside the picket fence cannot be moved inside simply by considering it under the procedural rules set out in the GNSO PDP. Policies and policy recommendations related to issues outside the picket fence simply are not “consensus policies” and are not, as a result, binding on either registries or registrars except as a result of commercial negotiations.
In our view, the vast majority of objections to the .com agreement pertain to issues that are not within the picket fence and that have to date been addressed in commercial negotiations. Those who object to the agreement are, in effect, second-guessing the ICANN Board, and demanding a seat at the negotiating table to negotiate issues outside of ICANN’s mission. The ICANN Board should proceed with extreme caution, and address its critiques head on, without setting a precedent that will complicate ICANN’s ability to take care of business for years to come.

The job of the ICANN Board is to serve the community by exercising its informed judgment based on the best available information. Some of that important information may be proprietary, and not on the public record. Some of that information may relate to the fiduciary obligations of the ICANN Board and properly not on the public record. By acceding to the demands of a few with respect to commercial issues outside of ICANN’s core mission the Board deprives the community of its informed judgment, limits its future negotiating flexibility and, at the same time, makes it increasingly difficult to resist those who would use ICANN’s agreements with DNS service providers to create an anti-competitive regulatory regime. In negotiating agreements with registry operators, ICANN must retain the authority to respond to the commercial realities in which any particular registry operates. This requires that ICANN have the ability to modify its position with respect to fees, renewal terms, the introduction of new registry services, and other issues that may well vary from registry to registry. The Board must retain the authority to actually make a deal that the registry operators on the other side of the table can rely on. Tying the hands of the ICANN board in these areas makes little sense.

While ICANN’s mission includes the promotion of competition, this role is best fulfilled through the measured expansion of the name space and the facilitation of innovative approaches to the delivery of domain name registry services. Neither ICANN nor the GNSO have the authority or expertise to act as anti-trust regulators. Fortunately, many governments around the world do have this expertise and authority, and do not hesitate to exercise it in appropriate circumstances.

Signed by:

Afilias (.info)
Employ Media (.jobs)
Global Name Registry (.name)
NeuLevel (.biz)
PIR (.org)
VeriSign (.com and .net)

February 20, 2006

Weekly Archives

January 29   February 05   February 12   February 19   February 26   March 05  

This page is powered by Blogger. Isn't yours?

More blogs about ICANN.
Technorati Blog Finder