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

Our Mission
ICANN for Beginners
About Us
How To Use This Site
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) Nominet Speaks Out on ccTLD Policy Development Process
    posted by DavidP on Tuesday November 19 2002, @08:03AM

    Nominet UK, the registry for the .uk ccTLD, has submitted a number of very interesting comments on ICANN's "Preliminary Recommendation on Policy-Development Process" for the newly-formed ccNSO. It's a hard-hitting condemnation of ICANN's attempts to expand the IANA function to include policy-making for the ccTLDs, well worth reading. Because the Nominet submission doesn't seem to be posted anywhere at the moment, we've included the full document below.

    A few weeks ago, in a report on the Shanghai meetings, I suggested that "ICANN's outrageous and heavy-handed attempts to condition ccTLD changes to name server records in the root zone file on its ability to download the ccTLD zone files may have awakened this constituency to the potential consequences of ICANN's domination of the DNS." The Nominet submission seems, to me, to confirm this -- all to the good, in my view. The bottom line: "the IANA function is a vital, but relative simple function almost entirely concerned with the management of a small database. Policy issues are relatively small (compared to those with the gTLDs), and should be developed by consensus." This, Nominet "notes with disappointment," may "only be possible outside of the current ICANN structure."

    Thus, the comment continues, ICANN should stay out of the ccTLD policy-making arena entirely because it is not an "appropriate or legitimate vehicle" for setting ccTLD policy. Each ccTLD should "develop its own policies according to local laws, customs, and regulatory and business environment," and the function of the new ccNSO should be only to advise on the contours of ICANN policy towards ccTLD managers, not ccTLD policy.

    Food for thought. The full statement follows.


    Nominet UK Public Position Statement on the Preliminary Recommendation on Policy-Development Process by ICANN's ccNSO Assistance Group.

    Nominet UK, the national registry for .uk domain names, is grateful for the opportunity to comment on the preliminary recommendations on the policy development process, as published by ICANN's ccNSO Assistance Group on 11 November 2002.

    As a preamble, Nominet fully endorses the decision made by members of the country code Top Level Domain (ccTLD) Registries at the last ICANN meeting in Shanghai to withdraw from the Domain Name Supporting Organisation (DNSO) in order to explore alternative ways of managing the IANA function and, more generally, the interests of the ccTLD community.

    As to the preliminary recommendations, Nominet cannot comment in detail on many of the points within the document, as it is in substantive disagreement with the principles that appear to be behind them. Nominet has therefore set out its position below:

    1. The preliminary recommendation appears to set no bounds on what policy can be made. Nominet does not recognize ICANN or its various actual and putative supporting organizations as an appropriate or legitimate vehicle for determining Nominet's own policy, or indeed the policy of any other ccTLD manager. Specifically the remit of an advisory organization to ICANN should be limited to advising ICANN on ICANN's own policy toward ccTLD managers. If ccTLD managers require their own policy advice, they should obtain it elsewhere as they see fit. Nominet distinguishes this from the sharing of best practice between ccTLD managers, which, as stated below, it considers important, and Nominet accepts that ICANN might have a useful role to play in this respect. Each ccTLD manager needs to develop its own policies according to local laws, customs, and regulatory and business environment, as well as the demand for registrations. The requirement for this can be seen by the diversity of policies amongst the current ccTLD registries: compare, for instance, the policies Nominet (running the UK registry) and AFNIC (running the French Registry). Whilst Nominet can convincingly argue, with respect to the UK, that it has the best and most appropriate policies, it cannot argue that those policies are thus necessarily appropriate for France. Undoubtedly the converse is true with respect to AFNIC. Hence policy of ccTLD operators should, as per RFC1591, be determined in consultation primarily with the local internet community, rather than ICANN or other ccTLDs. Many ccTLD managers already have effective mechanisms of determining their own policies in this way. For instance, Nominet maintains a Policy Advisory Board to provide advice on the development of policy to its Council of Management, and act as a conduit for consultation with Nominet's various stakeholders. Its membership comprises two non-executive directors of Nominet, representatives of up to five appointed organizations, plus eight Nominet members who are elected by Nominet's own membership (i.e. the industry). The appointed organizations provide representatives of government, industry organizations, consumer bodies, and the intellectual property constituency.

    2. The proposed structure adds unnecessary layers of procedure, bureaucracy and expense. ICANN, as the current IANA operator, should bear in mind that IANA's function with respect to ccTLDs should be to record the details of the nameservers within the root zone file, to change these on the instruction of the designated ccTLD manager, and to publish the root zone file to root server operators. In respect of ccTLDs, there is no requirement on ICANN to exceed these simple IANA functions. Maintaining a database of a few hundred records does not require a policy organization with Task Forces, Regional Statements and so forth. Responding to requests to change secondary nameservers does not require a policy formulated by committee, it requires a simple protocol. The only areas of ccTLD policy which might be thought to impinge on the operator performing these IANA functions are those concerning redelegations - the equivalent of changing maintainer objects in the database. Any such decisions to redelegate should be made by the national government concerned in consultation with the internet community of that country, and the existing and proposed ccTLD operator, and neither by ICANN, IANA, nor by vote of other ccTLD operators. Provided the appropriate national government makes an authenticated request to the IANA operator, and that request is not successfully appealed by the existing manager (as to the consultation), the operator should act on it. Appeals should be heard by a panel of independent experts external both to the IANA operator and the country involved. Questions as to the identity of the national government connected with a ccTLD, for instance after revolution or civil war, should be left to the ISO 3166 Maintenance Agency (to determine the mapping between the ccTLD and a UN recognized country only), and the appropriate UN body (to determine the recognized national government of that country). These functions should not be duplicated by the IANA operator. Nominet believes that ICANN has made a fundamental error in overplaying its role in respect of the ccTLDs beyond that of the current IANA operator, perhaps due to a mistaken belief as to the applicability to the ccTLDs of ICANN's wider role to date with respect to gTLDs in policy making, and regulation (such as registrar accreditation); this appears to be borne out by the fact that whilst the ccTLD operators have been asked to contribute a third of ICANN's budget, much of the expenditure is devoted to gTLD issues and dealing with internal US politics entirely unconnected with any matters pertinent to ccTLDs. Any reform should concentrate on reducing bureaucracy and costs within ICANN, and increasing its operational effectiveness, rather than the converse, which would be the effect of this proposal. An IANA function such as Nominet describes would, however, be comparatively cheap to run.

    3. The remit of the ccNSO should specifically exclude operational matters. These should be the purview of operational contracts between ccTLD manager and the IANA operator describing that operator's obligations to perform the IANA functions as described above, and equally technical requirements on the ccTLD manager. Nominet recognizes the vital role of IANA, and thus underlines the need for any such contracts to have service levels detailed within them. Nominet notes with disappointment that ICANN has so far been unwilling to enter into any form of contract describing the operational functions it purports to perform as IANA, despite several initiatives by the ccTLD community (for example from CENTR).

    4. Nominet does not accept the "Region Structuring" proposed. Firstly, such structuring would only make sense if it were perceived that there was greater homogeneity of views amongst regions than between regions. Secondly, this causes duplication and confusion with other regional bodies such as CENTR.

    5. Nominet UK does not accept the implied "one ccTLD one vote" structure, which contrasts notably with ICANN's views on financial contributions. However, instead of proposing alternative complicated structures of no doubt equally dubious electoral and democratic validity, Nominet proposes that ICANN should concentrate on development of policy by consensus. Decisions made through the proposed voting process, and no doubt any other, will always be subject to accusations of invalidity. Nominet reminds ICANN that its function in this respect is to operate a database. Far more complex issues within the industry have been successfully determined in this manner, for instance the proceedings of RIPE (operating a rather larger database), and the IETF. Nominet notes that confrontational acts by ICANN, such as its threats to withhold provision of essential services such as management of changes to addresses, name servers etc in an attempt to enforce the party concerned into a contractual relationship which is unacceptable to almost all ccTLDs, have done little to contribute to an atmosphere where policy can be made by consensus.

    6. The section on Board Voting (clause 13b) exemplifies much that is wrong with this proposal. Either the decisions of the ccNSO should be binding on ICANN, or they should not be. This clause in essence says the decisions will be binding unless ICANN's board thinks that they ought not to be binding, rather making the entire already heavyweight process a charade. Stripping away the otiose wording, this voting process is the exact logical equivalent of: "The Board shall adopt the policy according to the Council if and only if Board believe such a policy is in the best interests of the ICANN community and ICANN". As this is the actual substance, it would be more honestly phrased if the document stated it in this manner, as opposed to maintaining the pretence that the policy is binding on ICANN.

    In summary, Nominet restates the IANA function is a vital, but relative simple function almost entirely concerned with the management of a small database. Policy issues are relatively small (compared to those with the gTLDs), and should be developed by consensus. Nominet retains its position of supporting the need for a lightweight overarching body performing these IANA functions at an economical rate. It should also work on best practices for country code operators on a consensual basis, in parallel with, and in consultation with, organisations such as CENTR. Nominet notes with disappointment that it appears increasingly likely that this may only be possible outside of the current ICANN structure.

      ICANNWatch Login  


    [ 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
  • report on the Shanghai meetings
  • Nominet UK,
  • "Preliminary Recommendation on Policy-Development Process"
    This discussion has been archived. No new comments can be posted.
    Nominet Speaks Out on ccTLD Policy Development Process | Log in/Create an Account | Top | 3 comments | 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.
    Re: Nominet Speaks Out on ccTLD Policy Development
    by fnord (groy2kNO@SPAMyahoo.com) on Tuesday November 19 2002, @04:06PM (#10206)
    User #2810 Info
    Sudan, Kenya, and Afganistan, all well-known centers of massive internet packet switching. ICANN is picking off the small stuff (and bought off stuff like .au) one at a time until they can claim to have enough ccTLDs under contract that it runs into double digits, or less than 10% of the TLDs. Those three proposed new gTLDs might just put them over the top! They can then claim overwhelming consensus and continue apace.

    I sure hope the ICANN staff has a Plan B because no-one with two brain cells to rub together is buying this crap. Er, um, does the US DOC have two collective brain cells to rub together, there's the rub. -g

    [ Reply to This | Parent ]
    • 1 reply beneath your current threshold.
  • 1 reply beneath your current threshold.

  • 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