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)

    IANA Bring on the IANA Competitors
    posted by michael on Monday February 03 2003, @01:34PM

    ICANN's power rests on three contracts that it has with the US government:
    1. the Memorandum of Understanding (as amended),
    2. a technology-transfer agreement called a CRADA (as amended and amended), and
    3. the strangest government procurement contract in history: a zero-dollar "purchase" by the US government of services for the IANA function

    Of these three agreements, arguably the one that rests on the most unsteady foundations is the IANA contract -- if only because it has to be awarded according to rules that give other people a (theoretical) chance to bid. Now, the US government has announced it wishes to award IANA to ICANN again. Bad idea. Very bad idea.

    To begin with, there's something weird and unsavory about a zero-dollar procurement contract. This is most certainly NOT what Congress had in mind when it created procurement authority for the Commerce department. It's a handy device, though, as it lets commerce give "IANA" the use of a federal resource along with the authority to recover costs for it.

    Which leads to the second problem. ICANN's power to extort fees from people is vastly strengthened by it's "IANA" role. By conflating its IANA role with its ICANN role when charging, for example, ccTLDs, ICANN avoids having to explain how much of what it bills them is for "IANA" jobs and how much is for "ICANN" jobs.

    Of course, when it comes to openness and transparency -- even in the limited ways ICANN defines that at the best of times -- that never applies to the black hole of IANA. ICANN never gives advance notice of IANA re-delegations (although in other contexts, ICANN is happy to say that ccTLD administration has spill-over consequences so it needs to be considered globally. And ICANN never seeks public comment on redelegations. Plus, ICANN unilaterally changes the rules (ICPs 1, 2 & 3).

    But that isn't the worst of it. Amazingly, the entity to which the US government proposes to sole-source the IANA function has proven that it is worse than incompetent -- it's guilty of extortion. We've written several times about the rage of ccTLD administrators who find that they cannot get ICANN (under its IANA hat) to make simple change in the IP addressing information, or change addresses in contact information. These are unquestionably necessary administrative tasks that require almost no effort, and take only a few minutes each. ICANN delayed them for weeks and weeks. Why? No, not incompetence. Worse: ICANN let it be known that only the ccTLDs who signed its "obey and pay" contracts would get speedy service. ccTLDs reluctant to submit to ICANN's authority and to its budget demands (but, we promise, no more than a 15% increase per year), would just have to settle for second class service or none. Even if this endangered the stability of the internet ... repeatedly. The ccTLDs were not pleased.

    The way this newly announced procurement works is as follows: by publishing its notice on January 28th, Commerce announced its belief that "the property or services needed by the executive agency are available from only one responsible source and no other type of property or services will satisfy the needs of the executive agency." The world has ten days from then -- until the end of this week -- to submit sufficient proof that there's another qualified bidder. If one comes forward, Commerce will open a competitive bid -- and probably move heaven and earth to give the award to ICANN anyway, for Commerce understands full well just how central the IANA function is to ICANN's power.

    Indeed, that understanding is the foundation of the one bright spot in this manoeuver: Commerce plans to put ICANN on a short leash, coterminous with the deadlines in the other agreements: "The period of performance for this effort will be three years, with a six month base period, two one-year options, and one six month option. The Government will award this purchase order on April 1, 2003."

    Meanwhile, it's up to the world to put in evidence of a credible counter-bid. Unlikely in a short time? Yes. Impossible? No. And although the deck starts out stacked against any interloper, there are also powerful forces at work that might support the right sort of new bidder. For a long time the IETF has made it clear that would like some of the IANA functions back. The ccTLDs have been at work developing their own IANA plan, based of a fee-for-service model (anathema to ICANN, since IANA would stop being the leverage used to drive part of the cash engine). Foreign governments might find that splitting a piece off ICANN furthered their goal of internationalizing the root. (As far as I know, the ITU is not the sort of body that can bid for this job; just as well really, given the ITUs latest wild talk). And, if the right applicant came forward, it might do the job fairly, openly, and properly.

    Even if a new applicant were to be rejected on this round, the very existence of a technically and politically credible alternative would change ICANN politics for the better. But there's not much time....

    Find other ICANNWatch stories on IANA.

    Full text of the procurement "synopsis":

    D -- Operation of the Internet Assigned Numbers Authority (IANA) functions.

    General Information

    Document Type: Presolicitation Notice
    Solicitation Number: Reference-Number-NTIA909-3-0050CH
    Posted Date: Jan 28, 2003
    Original Response Date: Feb 28, 2003
    Original Archive Date: Mar 15, 2003
    Current Archive Date:
    Classification Code: D -- Information technology services, including telecommunications services

    Contracting Office Address

    Department of Commerce, National Oceanic and Atmospheric Administration (NOAA), Acquisition and Grants Office, SSMC4 - Room 7601/OFA61 1305 East West Highway, 7th Floor, Silver Spring, MD, 20910


    This is a notice of intent to issue a sole-source, no-cost purchase order to the Internet Corporation for Assigned Names and Numbers (ICANN) 4676 Admiralty Way, Suite 330, Marina del Rey, CA 90292. The period of performance for this effort will be three years, with a six month base period, two one-year options, and one six month option. The Government will award this purchase order on April 1, 2003. The Contractor shall support the operation of the Internet by performing three interdependent, technical coordinating functions, known as the Internet Assigned Numbers Authority (IANA) functions. First, the Contractor shall coordinate the assignment of technical protocol parameters. This function involves the review and assignment of unique values to numerous parameters (e.g., operation codes, port numbers, object identifiers, protocol numbers) used in various Internet protocols. This function also includes dissemination of listings of assigned parameters through various means (including on-line publication) and the review of technical documents for consistency with assigned values. Second, the Contractor shall perform administrative functions associated with root management. This function primarily involves facilitation and coordination of the root zone of the domain name system (DNS). It includes receiving requests for and making routine updates of the country code top level domain contact and name server information. Third, the Contractor shall provide overall responsibility for the allocation of IPv4 and IPv6 delegations of IP address space. This function includes delegation of IP address blocks to regional registries for routine allocation, typically through downstream providers, to Internet end-users within the regions served by those registries. It also includes reservation and direct allocation of space for special purposes, such as multicast addressing, addresses for private networks, and globally specified applications. This procurement is being conducted under the authority of 41 U.S.C. 253(c)(1) - only one responsible source, which applies when the services required by the agency are only available from one responsible source and no other type of service will satisfy the agency's needs. The Department of Commerce continues to transition technical management of the Internet Domain Names System to the private sector. This process began during June 1998 when the Department of Commerce issued a Statement of Policy: Management of Internet Names and Addresses, 63 Fed. Reg. 31741 (1998) in which it indicated that the U.S. Government would continue to participate in the technical management of the DNS during the transition to maintain Internet stability and continuity of services. On November 25, 1998, the Department of Commerce, through the National Telecommunications and Information Administration, and ICANN entered into a Memorandum of Understanding (MOU) through which the parties are jointly designing, developing and testing the mechanisms, methods, and procedures that should be in place and the steps necessary to transition DNS management to the private sector. As set forth in the Statement of Policy and the MOU, the original target date for completing the transition to private sector management was September 30, 2000. While significant progress has been made towards the transition, some work remains to be completed. Part of this transition process relates to the continued performance of the critical Internet technical coordinating functions, collectively known as the IANA functions. These functions were previously performed under contract between the Defense Advanced Research Projects Agency (DARPA) and the University of Southern California (USC) as part of a research project known as the Terranode Network Technology (TNT). As the TNT project neared completion and the DARPA/USC contract neared expiration in 1999, the U.S. Government recognized the need for the continued performance of the IANA functions as vital to the stability and smooth functioning of the Internet. On December 24, 1998, USC entered into a transition agreement with ICANN under which ICANN secured directly from USC, all necessary resources, including key personnel, intellectual property, and computer facility access critical to the continued performance of the IANA functions. Having assumed these key resources and associated privatization responsibilities under the MOU, ICANN is the only responsible entity that can continue to provide seamless performance of the IANA functions, and thus, maintain the security, stability, and reliability of the Internet. Offeror's who believe they can meet this requirement are required to submit in writing an affirmative response demonstrating a comprehensive understanding of the requirements set forth. All written responses must include a written narrative statement of capability, including detailed technical information demonstrating their ability to meet the above requirements. The response must be sufficient to permit agency analysis to establish a bonafide capability to meet the requirements. Failure to submit such documentation will result in the Government proceeding as stated above. A determination by the Government not to open the requirement to competition based upon responses to this notice is solely within the discretion of the Government. Affirmative written responses must be received no later than 10-days after publication of this synopsis. See Note 22.

    Original Point of Contact

    Loren Sunell, Contract Specialist, Phone 301-713-0838 x121, Fax 301-713-0809, Email loren.sunell@noaa.gov - Carol Silverman, Contracting Officer, Phone 301-258-4505 x226, Fax 301-258-4525, Email csilverman@doc.gov

    Place of Performance

    Address: 4676 Admiralty Way Suite 330 Marina del Rey, CA
    Postal Code: 90292
    Country: USA

      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
  • IANA
  • ITU
  • IETF
  • US Nat'l Telecom & Info Admin.
  • zero-dollar procurement contract
  • endangered the stability of the internet
  • repeatedly
  • ccTLDs were not pleased
  • IETF has made it clear that would like some of the IANA functions back
  • their own IANA plan
  • ITUs latest wild talk
  • ICANNWatch stories on IANA
  • the procurement "synopsis"
  • Memorandum of Understanding
  • amended
  • amended
  • amended
  • a zero-dollar "purchase" by the US government of services for the IANA function
  • agreements
  • US government has announced it wishes to award IANA to ICANN again
  • More on IANA
  • Also by michael
    This discussion has been archived. No new comments can be posted.
    Bring on the IANA Competitors | Log in/Create an Account | Top | 4 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.
    There are many parts of IANA
    by phoffman@proper.com on Monday February 03 2003, @03:54PM (#11082)
    User #2063 Info
    The discussion of the IETF maybe wanting a different IANA conflates IANA's control of the contents of the root zone with its other work for the IETF. With respect to the latter, see draft-iab-iana-00.txt [ietf.org], which is not an official statement of any kind but does show how the IETF might carve out what it needs from a future IANA.

    Someone has to be responsible for the content of the root zone. The decision of what goes into the root zone is clearly a mix of techincal, political, and policy items. The technical items include things like the NS records and glue records. The political items are the entire list of nameservers for any particular country. The most obvious policy item is the number of non-ccTLDs listed and who owns them.

    It is fine for IANA to be in charge of the technical items on its own. IANA should take explicit direction from ICANN on political and policy issues, and it should only do so only after publication of messages that anyone can read.

    Off-topic: IANA should get out of the IP address business. The RIRs are capable of ding this themselves.

    [ Reply to This | Parent ]
      Re:There are many parts of IANA
      by KarlAuerbach on Monday February 03 2003, @08:32PM (#11085)
      User #3243 Info | http://www.cavebear.com/
      I'm not sure I quite understand what you are saying.

      I absolutely agree that ICANN/IANA ought to be entirely out of the IP address allocation business.

      And I see no reason why ICANN ought to have any role in the job of handlng the "IANA Considerations" parts of RFCs.

      Nor do I see any reason why ICANN/IANA ought to have any role in the mechanical and clerical job of updating NS records for TLDs, all TLDs.

      Nor do I see any reason why IANA needs to validate TLD zone contents beyond that which is strictly and directly necessary to ensure that the delegation linkage from the root to each TLD is well formed. (This checking, by the way does not require a zone transfer - it can be done completely and with minimal intrusion using standard DNS queries.)

      ICANN's staff has said to me that it considers it appropriate for ICANN to induce a contract with ICANN as a precondition to the delivery of IANA services - such as the updating of ccTLD NS records - which is to my way of thinking a statement to the effect that ICANN is willing to sacrifice the actual operational stability of the Internet for no purpose other than to elevate ICANN.

      ICANN has transformed the ability to suggest to the US Dep't of Commerce's NTIA what TLDs ought to appear in the root into a power to dictate trademark policy on a worldwide basis. That is a role that has abolutely nothing with the technical job of IANA.

      IANA has been trusted. However, IANA will lose (if it has not already lost) that trust because it is being used as a hammer to shape ICANN's non-technical institutional and political agendas.

      The choice of who gets the nod to operate a ccTLD ought to be based on objective principles objectively applied. The choice ought not to be colored, cheapened, and discredited by bureaucrats who stand to benefit if they can use that IANA power to get one of the candidates to sign a contract with ICANN.

      The answer that is obvious to me, if not to the US Dept of Commerce, is that ICANN should not have any institutional linkage to the IANA mechanisms used to who gets to operate each ccTLD. In other words, the present practice of having commingled staff, comingled offices, comingled finances, and comaingled goals must be ended. With regard to ccTLD matters, ICANN and IANA should be divorced.

      ICANN and IANA have been so comingled that it is impossible to ascertain who of ICANN's staff makes what IANA decision, who of ICANN's staff has been involved in each IANA decision, or how much time or money ICANN's staff has spent wearing IANA hats. ICANN is making a gift to the US government by providing these services for no charge, that gift may or may not be appropriate, but no one can tell how much that gift costs.

      That leaves the issue of those TLDs that are not ccTLDs and not for administrative purposes (the latter including, for instance, in-addr.arpa).

      The answer to that question is the hardest, but the guideline we ought to follow is this: The IANA role should be insulated from politics and should be structured to deal only with those questions that a) directly concern the ability of the Internet to reliably, accurately, and swiftly deliver packets from a source IP address to a destination IP address and b) directly concern the ability of the DNS roots and TLDs to reliably, accurately, and swiftly process DNS transactions.

      Issues, such as the degree to which the domain name system is to be made the handmaiden of the trademark industry are not matters that ought to be allowed to intrude on the delivery of IANA services.
      [ Reply to This | Parent ]
    Copyright in the Root Zone?
    by isquat on Monday February 03 2003, @04:03PM (#11083)
    User #3363 Info | http://i.squ.at/
    Is this the key text of the document?

    "On December 24, 1998, USC entered into a transition agreement with ICANN
    under which ICANN secured directly from USC,
    all necessary resources, including key personnel,
    intellectual property,
    and computer facility access

    critical to the continued performance of the IANA functions.
    Having assumed these key resources and associated privatization responsibilities under the MOU,
    ICANN is the only responsible entity that can continue to provide seamless performance of the IANA functions..."

    So they actually say, that ICANN acquired things from ISI (USC) that are necessary to do the IANA functions and which nobody else could bring together?

    Like what?

    Intellectual Property? What are they talking about? The Copyright in the root-zone?

    Does ICANN have very special hardware, which nobody else could put together? Software? Staff?

    [ Reply to This | Parent ]
  • 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