How ICANN pressures 'net engineers to give it behind-the-scenes control of the web
We must have IANA! We must have IANA!
Behind-the-scenes efforts by ICANN's lawyers to force the internet community to grant it perpetual control of critical internet functions have been exposed.
Citing a cultural default of openness and transparency, negotiation teams from both the regional internet registries (RIRs) and the Internet Engineering Task Force (IETF) have made details of their discussions over the IANA contract public. The IETF is probably best known to Reg readers as the people maintaining and developing the library of crucial RFC standards that are the blueprints of the internet and computer networking.
In revealing the conversations, the negotiation teams have put a spotlight on apparent duplicity between ICANN's public statements and its private behavior, and show just how far the organization is willing to go to secure control of the contract currently held by the US government – but which it intends to take over by the end of the year.
Earlier this month at a meeting in San Francisco, representatives from the negotiation team dealing with the "numbers" part of the IANA contract – the job of allocating IP addresses – stunned audience members when they revealed ICANN was refusing to accept the consensus document that the internet community had developed over the course of a year unless it specifically stated that ICANN would run the IANA functions forever.
IANA: What's at stake?
The US government contracts non-profit ICANN to run the so-called IANA functions – a body that runs the highest level of the world's DNS, allocates IP addresses, and ensures developers can agree on the same numbers and protocols when writing software that communicates over the 'net. It's what keeps the internet as we know it glued together.
That crucial contract is coming to an end, and because the US wants to step away from ruling the internet like an unelected king, the future of the IANA functions is being explored by a panel of experts called the Community Working Group (CWG). ICANN, of course, would love to run IANA all by itself, simply put.
A series of slides [PDF, pgs 17-27] outlined the negotiation, including one that read: "ICANN has verbally represented that they will reject any proposed agreement in which ICANN is not deemed the sole source prime contractor for IANA functions in perpetuity."
Incredibly, ICANN appears adamant that the US Department of Commerce and Congress will give California-based ICANN that role forever – despite both institutions having made statements that would strongly suggest otherwise.
The same slide reads: "ICANN asserts that neither NTIA [the Department of Commerce's National Telecommunications and Information Administration] nor US Congress will approve any transition plan which leaves open the possibility of a future non-US IANA Functions Operator."
This stance directly contradicts a statement given by ICANN's chairman Steve Crocker just a few weeks earlier in which he said in public that there was "nothing fundamental in them [the numbers and protocols proposals] that we have a problem with, full stop.”
The presentation then explicitly recognizes the benefit to the RIRs of having adopted a principle of transparency over how the IANA functions are negotiated. A slide reads: "Our transparency principle continues to benefit our community, in that we all now understand ICANN’s starting position in the negotiation. Without a transparency principle, only a handful of people would be aware of the state of the conversation, and they might not be aware of the precedents in this area. As in open-source software development, more eyes on a problem yield a better solution."
Next up: protocols
A very similar story has emerged from the IETF and its separate negotiation over the protocols aspects of the IANA contract.
On Thursday, the chairmen of the IETF, the IETF Administrative Oversight Committee (IAOC) and Internet Architecture Board (IAB) – Jari Arkko, Tobias Gondrom and Andrew Sullivan, respectively – published a carefully worded update that revealed that ICANN was also refusing to accept wording changes to the annual "Supplemental Agreement" between the two organizations.
The same issues seem to be at the heart of it: recognition that ICANN may not in future be the IANA functions operator.
"After some iterations, we arrived at text that we think captures the IETF consensus," the chairmen noted, "but ICANN has informed us that they are unable to agree to that text right now."
The chairmen have said they will not release the actual text that ICANN is refusing without agreement from all parties, but they did give a clear explanation over the issues it covers:
In that document the community sought to have some facts acknowledged as part of any IANA transition plan:
- The protocol parameters registries are in the public domain. It is the preference of the IETF community that all relevant parties acknowledge that fact as part of the transition.
- It is possible in the future that the operation of the protocol parameters registries may be transitioned from ICANN to subsequent operator(s).
The update reveals that ICANN again argues that the US government would not accept such an agreement. It reads: "ICANN told us that, in their opinion, agreeing to that text now would possibly put them in breach of their existing agreement with the NTIA."
Sponsored: Becoming a Pragmatic Security Leader