This week's post on DNSSEC requirements for new gTLDs piqued my curiosity - what exactly are the differences between the registry agreements ICANN has executed to date and the proposed registry agreement in the DAGv3 with respect to technical standards requirements? A quick review of the documents reveals a stark difference.

In existing registry agreements, the language concerning standards in existing tld agreements is not overly prescriptive. It deals with maintaining stability of the DNS, requiring registries to be

compliant with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs sponsored by the IETF

but allowing them to choose which standards they implement as long it does not create

a condition that adversely affects the throughput, response time, consistency or coherence of responses to Internet servers or end systems.

On the other hand, the language proposed in the DAGv3 registry agreement is a huge change. It is very specific about required technical standards. In addition to the language above, it identifies more than 30 IETF RFCs and BCP documents with which operators under contract with ICANN must comply. They cover everything from DNS name server operations and Extensible Provisioning Protocol (EPP), to Domain Name System Security Extensions (DNSSEC), Internationalized Domain Names (IDNs), and Internet Protocol version 6 (IPv6).

One could simply view this as identifying an operational baseline as the TLD namespace expands. However, it is important to differentiate between when ICANN is requiring compliance with long-established, widely used standards and when it is pushing or compelling acceptance and use of standards that have not been established in the market (e.g. IPv6 and DNSSEC). The former would essentially be consistent with the practice the IETF, a voluntary standardization organization, has long followed. However, the later reflect various special interests' ability to influence and leverage ICANN's contractually-based policy regime to achieve their preferred outcomes, regardless of what the market decides.

====

DAGv3 Proposed Registry Agreement on Standards Compliance (pg. 9)

"Registry Operator shall implement and comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to (i) the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472; and (ii) provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3735, 3915, 5730, 5731, 5732, 5733 and 5734.

Registry Operator shall implement Domain Name System Security Extensions (“DNSSEC”). During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and 4310 and their successors, and follow the best practices described in RFC 4641 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the practice and policy document (also known as the DNSSEC Policy Statement or DPS) describing key material storage, access and usage for its own keys and the registrants’ trust anchor material.

If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply with RFCs 3490, 3491, and 3492 and their successors and the ICANN IDN Guidelines at , as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices as specified in the ICANN IDN Guidelines.

Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described in BCP 91. Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of this Agreement; e.g. Whois (RFC 3912), Web based Whois, IRIS (RFC 3981 and related RFCs). Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a TLD accredited Registrar willing to operate the SRS over IPv6."