The longer it was delayed, the more conspicuous its absence became. Yet ICANN and Verisign have finally come to an agreement on a contract to perform the vital domain name root management functions. The draft was published for public review two days ago.
The root zone management agreement (RZMA) controls how root zone changes actually get implemented and pushed out to the root server operators. Controlled primarily by a Cooperative Agreement between NTIA and Verisign that dates back to 1991, and which also regulates Verisign’s provision of the .COM domain, the root zone management process has been relatively mysterious and opaque until now. In line with the move toward non-governmental governance of the DNS, we are now moving toward the provision of these functions via an explicit contract between ICANN and Verisign.
While all eyes were focused on public, multistakeholder development of a proposal to end NTIA’s control of the IANA functions and to reform ICANN’s accountability mechanisms, reform of the root zone management process was left to private negotiations between ICANN and Verisign. Under pressure from the ICG, however, ICANN did agree to make the draft agreement available for public review.
Judging from the late date, ICANN and Verisign had difficulty coming to agreement on the terms of an RZMA. Although we have no inside information about the negotiations themselves, one can speculate about two possible sticking points. It seems that the RZM Agreement got bundled with the renewal of Verisign’s .COM registry contract, so it is possible that Verisign leveraged ICANN’s pressing need for a Root Zone Manager to get an immediate extension of the term of its .COM agreement for another six years. The RZMA was released with an amendment to the .COM registry agreement. Those who wish to comment on the amendment can do so as part of the comments on the modification of the .COM agreement, which is part of a formal public comment process.
The other possible sticking point was indemnification and liability limits. Many observers have wondered whether the removal of the U.S. government from the loop would subject ICANN and/or Verisign to impossible levels legal liability, including antitrust liability, for problems related to DNS performance. Section 9 limits the liability of Verisign and ICANN to certain fixed limits, and both ICANN and Verisign indemnify each other from certain things in Section 7. Section 7 (d) limits Verisign’s liaibility to $6 or 9 million per claim and $26 million in aggregate, which means that ICANN might have to cover any additional cost. It must have been difficult for the two parties to agree on this very specific level of risk they would accept.
Under the RZMA Verisign will perform these functions:
- Technical validation of the data provided by ICANN as part of a Root Zone Change Submission
- Notification of ICANN whether the change data is valid or not
- Edit, generate and DNSSEC sign the new Root Zone File (RZF), and publish it
- Notification of the root server operators of its availability
- Serve as the Zone Signing Key operator
- Perform an Emergency Root Zone File Regeneration at ICANN’s request
Verisign would perform these functions over an 8 year term. ICANN would pay Verisign a monthly service fee of $25,000 ($300,000/year) to do it. This is a tiny payment – pocket change for Verisign, if one does not take into account the value of the .COM extension. It is, therefore, a good deal for ICANN and its ‘taxpayers’. Verisign’s payment will also include reimbursement for all fees, expenses, duties, taxes or other charges imposed on Verisign by a Governmental Authority. Verisign may increase the service fee if it provides written notice to ICANN 400 days beforehand, but that would give ICANN enough time to trigger a transition process.
The agreement includes a change control process that allows the agreement to incorporate other services and to tighten the SLAs. Importantly, the agreement defines a Community Transition Process that can move the RZM functions to someone else. After five (5) years into the initial term, either Party may initiate the Community Transition Plan in accordance with the transition process in Section 8(b)(ii) of the agreement. If things go down that road, ICANN will convene a “RFP Committee” to develop a request for proposals to find a new operator. There can also be an Emergency RZM Transition Preparation Notice. These aspects of the agreement need to be studied more carefully.
One potentially controversial issue that was discussed by the community during the transition was whether ICANN itself should take over the root zone management function, or keep it separate. In general, most people wanted to avoid greater concentration of power in ICANN’s hands so they favored sticking with a separate RZM. The current RZMA leaves the door open to an eventual absorption of those functions by ICANN, but it would require a community approval process to get there.
One question going forward is how (and when) the NTIA Cooperative Agreement will be modified to reflect the new arrangements. Post-transition, it is not clear whether the Cooperative Agreement is needed at all. An NTIA run by Democrats may want to keep it, as Amendments 30 and 32 in effect constitute government economic regulation of Verisign’s wholesale prices; a Republican NTIA may not. But who know? Conservative Republicans are busily working against the transition, so perhaps they now favor government regulation of the Internet economy, just as Trump, Cruz and others seem to have abandoned the GOP’s former commitment to free trade.
A part of the agreement that is sure to inflame the jurisdiction debates in Work Stream 2 of ICANN’s reform process makes it clear that Verisign can “suspend any of the Services and/or Additional Services, in whole or in part, and/or the provisioning of any portion of the Verisign System to comply with applicable Laws.”
Verisign’s right to suspend includes, in each case, only to the extent necessary to comply with such Law, (A) revoking the right of access granted in Section 4(b) (License to Verisign RZMS), suspending or otherwise restricting ICANN’s access to the Verisign RZMS, and/or the provisioning of any other Services and/or Additional Services; (B) stopping the acceptance of Service Data from ICANN; (C) delaying, denying, deleting, freezing, or transferring the Root Zone File and (D) taking such other action, all as required to comply with such Law. Verisign shall, to the extent permitted by such Law, notify ICANN prior to taking any such action and shall, in any case, if permitted by such Law, notify ICANN immediately after taking any such action.
These powers could be abused by a U.S. government that wanted to seize control of the root and take it away from the ICANN regime. However, ICANN would still have the right to change RZM operators if there was undue political interference with the root zone management arrangement.
The linkage of the RZMA to the .COM agreement may also provoke some controversy. To us the .COM extension itself is not objectionable, and with presumptive renewal as a settled policy, it may not make much difference whether Verisign got a 6-year renewal now or 2 years from now. But the justification offered for this linkage is irritating: “Given the unified nature of the present Cooperative Agreement, much of the root zone infrastructure itself is inextricably intertwined with Verisign’s TLD operations for .com.” This seems to imply that .COM and the root zone are inextricably connected. They should not be. The RZM function is distinct from, and should be fully separable from, the right to operate the .COM top level domain, which constitutes about 44% of the domain name registry market. Admittedly, there may be efficiencies (both in cost and reliability) in piggybacking some RZM functions on Verisign’s massive infrastructure supporting .COM – though no one has done a public economic study about the nature or scope of those efficiencies. But still the two functions should be distinct and separable, both technically and policy-wise. The policy issues affecting the ownership, performance and regulation of .COM are completely different from those affecting the RZM service.
On the whole the RZMA is a positive step forward. It makes explicit – technically, economically, and legally – what is involved in managing the root zone, and it provides for necessary emergency and transfer procedures.
I’m not sure how paying 300K per year to VeriSign for a service that VeriSign previously provided at no cost is a “good deal”. But I suppose you mean that the actual cost of providing the service might be far higher.