| At Large Membership and Civil Society Participation in ICANN |
|
|
|
|
|
 |
 |
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
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 |
|
|
 |
 |
|
|
|
[ 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. ]
|
|
| |
|
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
|
|
The Fine Print:
The following comments are owned by whoever posted them.
We are not responsible for them in any way.
|
|
 |
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
]
|
|
|
 |
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
]
|
|
|
|
 |
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. |

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
|