Verisign posted preliminary public comments on the “Mitigating the Risk of DNS Namespace Collisions” Phase One Report released by ICANN earlier this month. JAS Global Advisors, authors of the report contracted by ICANN, have done solid work putting together a set of recommendations to address the name collisions problem, which is not an easy one, given the uncertainty for how installed systems actually interact with the global DNS. However, there is still much work to be done.
On Dec. 12, 2013, the Internet Engineering Steering Group (IESG) announced the formation of a new working group, Extensible Provisioning Protocol Extensions (eppext). The working group was formed to create an internet Assigned Numbers Authority (IANA) registry of Extensible Provisioning Protocol (EPP) extensions and to review specifications of extensions for inclusion in the registry. EPP is the standard domain name provisioning protocol for generic top-level domain (gTLD) name registries that operate under the auspices of the Internet Corporation for Assigned Names and Numbers (ICANN). It is also used by a number of country code top-level domain (ccTLD) registries.
The “E” in EPP has been both a blessing and a curse. EPP uses features of the Extensible Markup Language (XML) that provide “hooks” for protocol extensions. These hooks make it easy to specify new functionality without having to modify EPP itself. That’s the blessing. The curse has been that easy extensibility has led to multiple independent specifications that describe similar functionality. In a 2010 presentation, Patrick Mevzek (developer of the Net::DRI Perl library that implements EPP) described XML namespaces used in 68 distinct extensions. He further described three different extensions created by different registry operators to provide domain “undelete” functionality. This duplicity of effort makes implementation much more complicated for anyone developing EPP clients.
Some background information will help explain how we got here.