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)


     
    Country-Code Top Level Domains (ccTLDs) IANA procedures for ccTLD nameserver change
    posted by tbyfield on Wednesday March 26 2003, @07:08PM

    ICANN's faceless "IANA function" has posted "Procedures for Handling Requests by ccTLD Managers to Change Nameservers," scheduled to "be effective" on or by the end of this month. Its stated purpose "is to streamline the procedures for ordinary changes" to the root zone -- an issue over which ICANN has driven ccTLDs to distraction.



    Given ICANN's furious efforts to force the ccTLDs into signing a one-size-fits-all contract -- first by refusing to make requested nameserver changes, then later by trying to strongarm the ccTLDs into handing over their zone files ("basically a stupid mistake," as Vint Cerf put it) -- the mere existence of any procedure amounts to something of an about-face for "IANA." But is it really? Barely any mention is made of how long each step of the procedure should take. Granted, ICANN can't take responsibility for the speed with which a ccTLD acts (but see the Names Council's 13 September 2002 proposed resolution noting "widespread dissatisfaction of ccTLD Managers about the ICANN failing to its IANA Function duty" in the wake of the KPNQwest bankruptcy). And it certainly can't take responsibility for the speed with which the Department of Commerce acts. But it can provide basic quality-of-service assurances that ICANN itself will balance diligence with haste, if even in a form as nonbinding as a boy-scout pledge to try to do right. The fact that this document doesn't do so is either telling or an indication that ICANN's legal resources are incompetent -- take your pick. (The number of typos suggests that the whole thing is a hasty affair -- coming as it did just a few days before the Rio meeting.) And let no one doubt for a moment that ICANN is quite capable of making an argument like "Sure we said we'd do that -- but we didn't say when." If the ccTLDs don't have enough experience with ICANN's quibbling and obstruction, they need only think back to the tortured readings by which ICANN's policy staff concluded that ICANN's bylaws never said anything about a second At Large "selection." These new "procedures definitely don't say anything about deadlines.

    The preamble claims in notably ambiguous syntax to "modif[y] the procedures followed by the IANA as of 19 March 2003," without providing any indication of (e.g., a link to) what the prior procedure was. And it doesn't seem like the ccTLDs have heard of any prior procedure either: the incipient "ccTLD Constituency of the DNSO"/World Wide Alliance of Top Level Domain-names 7 June 2002 statement on Tracking IANA Database Changes makes no mention of it (though it does speak of "delays in carrying out various IANA functions and the lack of emergency change procedures"); and nor does their 28 July 2002 statement on ICANN Services to ccTLD Working Group seem to mention any prior procedure.

    Hilariously, the new procedure involves -- only -- the Dreaded Email Template, beloved by old-time registrants and netizens:

    CCTLD MODIFICATION TEMPLATE v.1.3
    
    1.  Purpose/Description.............:
    
    2.  Top-Level Domain Name...........:
    
    Sponsoring Organization
    3a. Organization Name (Registrant)..:
    3b. Street Address..................:
    3c. City............................:
    3d. State...........................:
    3e. Postal Code.....................:
    3f. Country Code (2 letter).........:
    
    Administrative Contact
    4a. (omitted)
    4b. (I)ndividual or (R)ole?.........:
    4c. Name............................:
    4d. Organization Name...............:
    4e. Street Address..................:
    4f. City............................:
    4g. State...........................:
    4h. Postal Code.....................:
    4i. Country Code (2 letter).........:
    4j. Phone Number....................:
    4k. Fax Number......................:
    4l. Email Address...................:
     [...]
    
    Look familiar?

    There's nothing inherently wrong with this splendid example of a "communications based regime," and indeed it does have some real virtues -- for example, a paper-trail in the form of email headers (which is better than the evidence ICANN accepted when it redelegated the Afghanistani ccTLD; context here). But, as noted above, the ccTLDs have been less than pleased with the lack of emergency procedures; and it isn't at all hard to imagine scenarios in which out-of-band communications would be preferable to, if not crucial for, a properly vetted change. The failure to include such an option (and the lack of any requirement for additional security, such as PGP/GPG signing) is reminiscent of ICANN's dubious CRADA reports, recently demolished by Karl Auerbach.

    In light of the growing restiveness of the ccTLDs, I suppose it's good to see ICANN respond, however feebly, to their concerns. However, since the document states that the procedure was "coordinated" (there's that word again) in conjunction with "members of the ICANN Security and Stability Advisory Committee" and "a group of ccTLD managers," I was more than a little curious about which ccTLD managers were involved. Was it the ICANN equivalent of, to lift a barb from the Financial Times, a motley "coalition of the billing" -- say, Afghanistan, Australia, Burundi, Japan, Kenya, Laos, Malawi, and Sudan? So I asked Mary Hewitt. Her answer: "The CCNSO." Well, gee, if it was the CCNSO why didn't the document say so? It may well be that these procedures were in fact crafted by a reasonably and formally delegated group of ccTLD admins; if so, I expect that, in their abidingly patient way, the ccTLDs as a whole viewed even a feeble, flawed procedure as an improvement over nothing. But, really, it's an abject spectacle to see ICANN, which has yet to formulate what real services it provides to the ccTLDs, subject them to this kind of nonsense. If the task of defining these procedures had been left to the CCs, they would have done a much more thorough and much more secure job of it years ago; but that's what happens when ICANN "coordinates" things.

    For general grain-of-salt context, see ICANN's ccTLD info page. However, for more timely context, see two new ccTLD documents from the Rio meeting: the "Resolutions adopted by the ccTLD Managers meeting in Rio de Janeiro, Brazil, March 25 2003 concerning the Recommendations of the ccNSO Assistance Group," and the "Communique of the Country Code Top Level Domain Managers meeting in Rio De Janeiro, Brazil." The latter is particularly noteworthy in this regard:

    The IANA function

    The group spent time considering the questions and challenges in defining the IANA function. The IANA function, as it pertains to ccTLDs, should be a neutral technical function that accepts changes from recognised ccTLD managers, and reflects those changes in the official database of ccTLDs and communicates them to the DNS root zone.

    The group decided to assist in the development of technical specifications for the operation of the IANA service, from wherever that service may come.

    A draft operating policy formulated by an ad-hoc committee addressing IANA's zone transfer requirement, and consequently ccTLD name server change procedures, was received by the group. Concerns were expressed that the proposed policy was incomplete, and left areas open to interpretation. The ccTLDs agreed to formulate a response to the draft.

    Diehard ICANNauts such as erstwhile policy chief-advisor-whatever Andrew McLaughlin insist -- as recently as on 17 March, at the "ICANN, ccTLD, and the Legacy Root" conference -- that fuzzy-headed ICANN critics don't understand that IANA is "really" distinct from ICANN. Fine: let it be so. I'm sure all those fuzzy-headed ccTLDs would be very pleased with, as Spinoza put it, an improvement of the understanding.

     
      ICANNWatch Login  
    Nickname:

    Password:

    [ Don't have an account yet? Please create one. It's not required, but as a registered user you can customize the site, post comments with your name, and accumulate reputation points ("karma") that will make your comments more visible. ]

     
      Related Links  
  • ICANNWatch.org
  • IANA
  • ICANN
  • Vinton G. Cerf
  • strongarm the ccTLDs into handing over their zone files
  • put it
  • proposed resolution
  • Tracking IANA Database Changes
  • ICANN Services to ccTLD Working Group
  • Dreaded Email Template
  • communications based regime
  • the evidence ICANN accepted
  • here
  • CRADA reports
  • demolished
  • Security and Stability Advisory Committee
  • Afghanistan
  • Australia
  • Burundi
  • Japan
  • Kenya
  • Laos
  • Malawi
  • Sudan
  • info page
  • Resolutions adopted by the ccTLD Managers meeting in Rio de Janeiro, Brazil, March 25 2003 concerning the Recommendations of the ccNSO Assistance Group
  • Communique of the Country Code Top Level Domain Managers meeting in Rio De Janeiro, Brazil
  • improvement of the understanding
  • Procedures for Handling Requests by ccTLD Managers to Change Nameservers
  • More on Country-Code Top Level Domains (ccTLDs)
  • Also by tbyfield
  •  
    This discussion has been archived. No new comments can be posted.
    IANA procedures for ccTLD nameserver change | Log in/Create an Account | Top | 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.


    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