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.

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

Full text of the procurement "synopsis":

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

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

Description

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

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.

"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?