[Date Prev]   [Date Next]   [Thread Prev]   [Thread Next]   [Date Index]   [Thread Index]

Sponsored TLD RFP
  • To: stld-rfp-comments@xxxxxxxxx
  • Subject: Sponsored TLD RFP
  • From: Edward Hasbrouck <edward@xxxxxxxxxxxxx>
  • Date: Thu, 26 Jun 2003 14:13:13 -0500
  • Reply-to: Edward Hasbrouck <edward@xxxxxxxxxxxxx>

[The following comments were sent to <canada@icann.org> 25 June 2003.  That was the address for comments originally posted with the draft RFP on the ICANN Web site.  Today the address on the ICANN Web site for comments on this topic was changed to <stld-rfp-comments@icann.org>. I don't know if my original submission was received or entered into the record of yesterday's ICANN Public Forum in Montreal, and I am re-sending it to this new address.  Nor can I tell how many other comments may not have been received, recorded, or brought to the attention of the ICANN Board of Directors in a timely manner because of the unpublicized change in the address for comments.]

I request that the following comments be entered into the record of the ICANN Public Forum at the Board of Directors meeting in Montreal, 25 June 2003, in regard to the agenda item entitled, "Sponsored TLD RFP":

This item was added to the agenda of the Montreal meeting and this Public Forum, as posted on the ICANN Web site, and a draft request for proposals (RFP) for new sponsored top-level domains was posted to the ICANN Web site for public review and comment, only yesterday, 24 June 2003.

As a result of this lack of advance notice, neither I nor anyone else (except perhaps those who might have been briefed in advance, in secret, in violation of ICANN's by-laws, on the agenda and/or the draft RFP) can yet provide a comprehensive review or critique of the draft RFP.

Accordingly, I cannot and will not comment in detail today on the draft RFP. Instead, I will limit these comments to a few of what seem to me to be the key defects in the process of selecting and introducing new sponsored top-level Internet domains, and the key issues which should be considered by the ICANN Board of Directors and by others (such as the U.S. Department of Commerce) who may be called upon to consider ICANN's recommendations for the addition of new TLD's to the root name servers:

(1) As I've just noted, there has been only one day for public review of the draft RFP.  This does not constitute a meaningful opportunity for public review, comment, or input into the decision.  In particular, it does not constitute either a "bottom-up" consensus development process, or a process conducted with the "maximum feasible" openness and transparency, as required by ICANN's contracts with the U.S. Dept. of Commerce and ICANN's own by-laws.

If the ICANN Board of Directors is to act in accordance with their legal obligations, the Board should defer any action on this proposal -- made just yesterday -- to a future Board meeting, to provide adequate time for community consideration of the proposal, and of alternative courses of action or inaction, and the possibility to develop a consensus on how ICANN should proceed. Accordingly, I request that the Board take no action on this proposal (the draft RFP) at this meeting.

(2) The short notice for this agenda item and the draft RFP ensure that the comments received at this forum will not be representative of the extent of community concern about this issue.  If you receive few complaints or other comments, that will be an indication of how few people even knew that this issue was to be discussed -- not an indication that few people care about this issue.  Even if they happened to check the ICANN We site yesterday, it is obviously impossible on a single day's notice for most concerned stakeholders to attend the public forum, or even to prepare comments like these for electronic submission.  For example, I am unable to present these comments and discuss them with you in person because I canceled my reservations and plans to travel to the Montreal meeting when this issue, in which I was primarily interested, did not appear on the agenda as of the time the meeting actually began on Monday of this week.

(3) Regardless of how this specific decision on the draft RFP is conducted, it is apparent to essentially all outside observers that there is not, in fact, a consensus in the Internet community on the question  of new TLD's.  There is intense controversy, with almost no points of general agreement except that ICANN has botched the process and made almost no one happy. 

I don't think ICANN necessarily can make everyone happy (not that ICANN has actually tried to develop a consensus), but it is important that ICANN be honest with itself and with outsiders about the lack of consensus around these decisions. Any attempt by ICANN to represent a decision on new TLD's as reflecting a "consensus" within the Internet community of stakeholders will be a lie.  That's already obvious, I think, but I also think it important that the record of this forum reflect that fact, so that neither ICANN nor external observers (such as the U.S. Dept. of Commerce) can claim that they believe that all interests have been satisfied or that a consensus actually exists.

(4) The problems of noncompliance by gTLD sponsors with their sponsorship contracts with ICANN, identified by myself and others in the previous round of ICANN public comments on the TLD process, continue unabated.  The "proof of concept" round of new TLD's continues to prove only that the concept is not working, at least with respect to openness, transparency, and accountability to affected stakeholders.

ICANN has taken no action whatsoever to enforce its sponsorship contracts, to bring TLD sponsors into compliance, or to withdraw ICANN's delegation of decision-making authority (for which delegated decision-making ICANN, not the TLD sponsor, is legally and fiscally liable) from sponsors who are not exercising their decision-making authority in accordance with their contractual commitments to ICANN.  There is still no process for oversight of delegated decision-making by TLD sponsors, either with the sponsors themselves, with ICANN, or with any external oversight body (except, perhaps, the U.S. Dept. of Commerce). 

I again urge the ICANN Board, as I did in my comments to the public forum at the Rio meeting, to exercise your oversight authority and legal responsibility to ensure that TLD sponsors are complying with their contracts with ICANN and, in the exercise of delegated decision-making authority, that they are complying with ICANN's own by-laws and contractual commitments.  And I urge the U.S. Department of Commerce, in evaluating any future recommendations by ICANN for the addition of new TLD's to the root name server, to take into consideration ICANN's demonstrated total failure to date to ensure compliance by TLD sponsors with the commitments in their charters and in ICANN's by-laws.

(5) The commentary accompanying the draft RFP on the ICANN Web site -- presumably prepared by ICANN staff -- says that there would be "less risk in proceeding presently with a limited number of new sTLD's" than with new unsponsored TLD's (uTLD's). 

That view is clearly and fundamentally erroneous.  Most of the policies for a uTLD are determined by ICANN itself.  For an sTLD, authority to determine those policies is delegated to the sponsor.  Much, much more authority is delegated to the sponsor of an sTLD than to the administrator of a uTLD.  And because ICANN is legally and fiscally liable for the exercise of delegated decision-making authority, approval of an sTLD carries much more weight and risk for ICANN, and should be undertaken only after much more careful consideration than a uTLD.

(6) On first (and, perforce, hasty) review, the main difference between the draft RFP and the process discussed in past ICANN documents and meetings is the limitation of the RFP to proposals by the small group of would-be sponsors whose proposals were considered, and passed over, in the 2000 round of applications for new TLD's.  Absent some compelling reason for this limitation, this new condition of the RFP appears designed unjustly to favor those previously unsuccessful applicants.  

New would-be applicants might have difficulty preparing proposals as quickly as those who had applied in 2000, or might be unwilling to risk the application fee.  But those are not reasons for ICANN to forbid them to try, if they so choose.  

The only apparent plausible explanation for restricting the RFP is a desire to favor one or more of the unsuccessful 2000 applicants.

There have been persistent, credible, rumors of cronyism, favoritism, and back-room deals by ICANN staff and Board members throughout the new TLD application, selection, and approval process, in 2000 and continuing to date.  These rumors have been strongest with respect to SITA's application for .aero and IATA's application for .travel. 

In late 2001, shortly before the .aero sponsorship agreement between ICANN and SITA was approved by the ICANN Board, I interviewed Ms. Rosa Delgado -- SITA's principal negotiator with ICANN -- at length about the process of negotiating and drafting the agreement.  In the course of that interview, I asked Ms. Delgado why and how travel agents and some other categories of entities, included in SITA's proposals, had been excluded from eligibility to register in .aero under the final agreement.

Ms. Delgado said that, "We [SITA] tried really hard" to include travel agents and some other categories in .aero, but that Mr. Louis Touton of ICANN's staff -- the principal drafter of the .aero agreement, according to Ms. Delgado -- insisted that travel agents could not be included in .aero because "They will be in .travel".  She said that Mr. Touton told her definitely that .travel would be approved.

I found, and still find, Ms. Delgado's statement credible and convincing. SITA's application to sponsor .aero was already on the verge of approval, and Ms. Delgado had nothing to gain by blowing the whistle on a secret deal for eventual approval of .travel.  Indeed, she appeared not to realize the significance of what she was saying -- she obviously thought it was an open secret that ICANN staff had already promised .travel to IATA, even though the decision would supposedly be made by, and would eventually have to be ratified by, the ICANN Board of Directors.

Ms. Delgado told me no one was present at most of the discussions between SITA and ICANN except herself and Mr. Touton. If I am unable to confirm her statement from another source, or from personal observation, that is entirely ICANN's own fault: it would have been feasible to permit interested journalists such as myself to observe the TLD agreement negotiations, and to review the written records of them.  Since it was feasible, it was required by the "maximum extent feasible" clause of ICANN's by-law on openness and transparency.  The decision based on those impermissibly closed negotiations, like most of ICANN's decisions, thus remains subject to legal challenge and nullification for not having been made in accordance with the procedural requirements of the by-laws.

In the context of these past statements by Mr. Touton, any attempt to limit the pool of eligible applicants to those, like IATA's application for .travel, that were passed over in 2000, deserves the strictest scrutiny as to whether it is made for valid reasons, or whether it is made as part of a scheme to rig the selection criteria to ensure the approval of .travel, to fulfill an illegitimate, but long-standing, secret commitment to IATA for approval of .travel sponsorship by IATA or a "front" group for IATA's interests.  And the U.S. Department of Commerce should and would, quite properly, reject any recommendation for .travel to be entered into the root name server if that recommendation by ICANN appears to be based on such an unauthorized staff promise or manipulation of the application eligibility criteria.


Edward Hasbrouck

author, "The Practical Nomad: How to Travel Around the World"
and "The Practical Nomad Guide to the Online Travel Marketplace"

background and previous comments on this topic:

[Date Prev]   [Date Next]   [Thread Prev]   [Thread Next]   [Date Index]   [Thread Index]

Privacy Policy | Terms of Service | Cookies Policy