ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    This discussion has been archived. No new comments can be posted.
    NewTLDs : The Long and Winding Road | Log in/Create an Account | Top | 51 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Re:ICANN Board postponing further sTLDs
    by RFassett on Thursday October 30 2003, @06:12AM (#12572)
    User #3226 Info | http://www.enum.info
    "it's kind of hard to suggest the next round of application fees is justifiable."

    I agree with your view on principle as usual but this "plan for action" for a limited number of sTLD's outlined a new process for applicant evaluation. There are really 2 risks of application: 1) you go through all of the time, effort, and expense necessary to put forward an application of quality that is far in addition to the application fee itself and 2) after doing as much, the application is not successful, for whatever reason including (for this RFP) clear language that the Board could simply not allow entry even if the third party evaluation process recommended it. But, the point being these are known risks for interested parties to evaluate whether they want to participate with the "invitation". Just as in Nov 2000, "7-10" was a risk known upfront, supported by the community, for reasons mostly of being a "testbed" (something "that had never been done before"...remember that?) and most in the community supported this rationale (from the advice of the unnamed technical experts) under the assumption it was "a start"...not an end. All interested parties knew of this risk upfront and some chose to participate, and some did not.

    As far as the application fee goes for this RFP, they could have had a tiered fee: those without material changes to their previously submitted application would pay less than new guests. But, either way, the applicant knows they are paying for their own evaluation meaning they are taking the financial risk and NOT ICANN. This was inherent to the RFP. So, to blame a lack of financial resources, including people, is a straw horse. If the application fee needs to be $100k for new guests, then make it $100k and see how many guests respond to the invitation...because it would be their decision to evaluate. Shelving the RFP simply means their has been a change of mind over inviting new guests that might feel vested, just like the 2000 applicants are "on hold" rather than "turned down". Personally speaking, I think they are turned down because it was not stated upfront there would be an ability to achieve a degree of "standing" simply as a result of filing as part of the testbed. This did not materialize until after the fact and those interested parties that made the business decision not to file but instead wait until the next opportunity (for what are now quite obvious reasons of risk) were suddenly shafted...and that's a major flaw.

    Because, as we sit here today, a problem that seems to have stymied this RFP process is that there might be new applicants that come forward applying for the same string as a testbed applicant. And ICANN could not get around this problem...including establishing a formal independent review process for those applicants from 3 years ago that rightfully requested as much. So, the Board has shelved it all together...no new invitations period that has little, in my mind, to do with "lack of resources" because the applicant foots this bill (applicant risk) and the Board could disallow any application recommended by the third party evaluation (applicant risk).

    By the way, I think when there is talk about the "testbed is dead" that this means the unsuccessful 37 applicants will have to get back in line. Is this "right"? Is sitefinder "right"? Is there much in DNS that is "right"? Go talk to those that said it HAD TO BE "7-10" for this answer. But as far as processes are concerned, there were known risks in 2000 just as there were known risks with this RFP. Some would choose to participate, and some would walk away. What has been reneged upon is the agreement from the community to limit the testbed to 7-10 on the advice of the technical experts but where it was understood new opportunities to participate would be forthcoming. This has long been reneged upon. And, if one can't trust the processes then I am not sure how the entity responsible for the process can expect to be trusted in return, absent of honest explanation and without the straw horses....is my opinion. Because I could come up with a ton of better, more reasonable, reasons to shelve this RFP than what has been supplied for the community to accept....and I think most could do the same.
    [ Reply to This | Parent ]
    Re:ICANN Board postponing further sTLDs by RFassett
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  


    Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com