ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

[ga] FW: Comment from the gTLD Registry Constituency


This is from the gTLD Constituency and has been sent to the ERC Committee.  I know this should spark some interesting debate.
 
Subject: Comment from the gTLD Registry Constituency

The Registry Constituency has been a vocal supporter of reform from its inception.  In fact, many of the Registries joined in a letter to the Department of Commerce expressing our support for the reform efforts.  One of the main reasons that we supported ICANN reform from the beginning was because of the perceived inefficiencies of the current DNSO. The result of such inefficiencies has led those parties that have contracts with ICANN (namely, the gTLD Registries and gTLD Registrars) to become disenfranchised with the current policy development process.  Too often, political games have been played to overshadow the voices of the Registries and the Registrars in the current process, even though it is recognized that most, if not all, of the proposed policies affect the contracted parties in a way that is much different than those parties that are not under contract with ICANN. Unfortunately, as the ERC process has evolved, the inefficiencies of the current DNSO appear to be re-emerging.

As the ERC properly realized, not all stakeholders are equally affected. The registrars and registries are contractually bound to comply with any ICANN consensus policies.  New or changed policies can have a significant financial impact on their operations.  We believe that the protection of registrar and registry rights as contracting parties within the proposed GNSO is an important and essential safeguard.

The registrars and registries are willing to work with the non-contracting parties within the same supporting organization, the GNSO, to make the ICANN process work, but only if the safeguards proposed by the ERC in the Second Implementation Report are adopted.  These includes, most significantly, the provision giving contracted parties equal voting representation as those that are not under contract with ICANN.

This is a critical step in the right direction. We are concerned that those constituencies that are not governed by ICANN to adopt ICANN policies (or the so-called user constituencies), which may be grossly under-representative of their actual constituents (see http://www.icannwatch.org/essays/palage-representativeness-2.0.pdf), are attempting to obtain an unfair super majority in the new GNSO. In addition, the model advocated by the non-contracted parties allows this small subset of under-represented users to dictate our business practices regardless of whether such policies are feasible to implement from a business perspective.

Their latest comments and proposed vote within the current DNSO further illustrates our point.  If the NC Resolution is adopted, it will be adopted 4-2 (assuming the ccTLDs do not vote because they will not be a part of the future GNSO).  The DNSO will use this result to state that 4 of the 6 constituencies have voted against equal representation for contracting/non-contracting parties.  They will manipulate this vote to state that 2/3 of the DNSO voted against the the ERC's proposal and will therefore state that a "consensus" (2/3) is against the ERC proposal.  They will proclaim a "consensus" even though two of the arguably most affected constituencies (those under contract with ICANN) will have voted against it.  This "consensus" of course, as you will recognize, will be completely artificial, in that the contracted parties will have voted against it.  How could that be consensus?

This is precisely what the contracted parties have been subjected to over the past several years and cannot be allowed to continue if ICANN were to be serious about reform.  The ERC recognized this in their latest paper and I submit that we hope that the ERC stays true to its course about bringing meaningful change within the ICANN process.

Best regards,

Jeffrey J. Neuman, Chair of the gTLD Registry Constituency

 
 
 


<<< Chronological Index >>>    <<< Thread Index >>>