The US Department of Commerce has announced the date of its RFP for the IANA contract, stating that only wholly US-based organizations are welcome to apply.
Commerce, via the National Telecommunications and Information Administration, said it intends to accept proposals from potential contractors between November 4 and December 4.
Among other things, the IANA contract is what gives ICANN its powers over the domain name system’s root – its ability to delegate gTLDs and ccTLDs to registries.
It is due to expire at the end of March next year, having been extended from its original expiry date of September 30. ICANN is of course the favorite candidate.
ICANN had asked for a longer-term or more arms-length contract, to dilute the perception that IANA is too US-centric, but NTIA has indicated that it intends to decline that request.
However, the duration of the contract has been changed.
The current IANA contract was a one-year deal, with four one-year renewal options. The next will be for a three-year base period, followed by two two-year renewal options, according to Commerce.
“The current unilateral structure of the IANA functions contract should evolve to meet the needs of the global community,” ICANN CEO Rod Beckstrom said during his opening remarks at ICANN’s 42nd public meeting in Dakar, Senegal yesterday.
He noted that the US government originally said, in a 1998 white paper, that ICANN would ultimately take over the IANA functions entirely, cutting it off from government.
“We hope that progress towards the vision articulated by the US government’s white paper will be made in the next agreement and we hope and we expect to see a roadmap for the realization of this vision in the future,” Beckstrom said.
Now that Commerce has made such a big deal out of the fact that only US-based organizations are welcome to apply to run IANA, that goal seems further away.
It’s also notable that the next IANA contract will be a single document.
The NTIA had previously floated the possibility of splitting it into three functions – protocol management, DNS root management and IP address allocation – but the idea was not well-received.