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

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:


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.

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
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.

This article comes from ICANNWatch

The URL for this story is: