In Part 1 of this series of blog posts I described the need for an industry association of operators to discuss the technical tasks, such as the development, deployment, and ongoing systems administration of the Extensible Provisioning Protocol (EPP), performed by registries and registrars to ensure interoperability and share best practices when providing registration services. In this blog post I’ll describe a way to make that happen.

I’ve spoken to a number of registrars who have described the challenges they face in implementing the many different EPP extensions being developed by registry operators. Here’s a concrete example: the Net::DRI Perl implementation of an EPP client includes contact extensions for 24 different registries. A registrar that wishes to manage contacts with those registries needs to implement a contact extension for each one! With the addition of new gTLDs and many new registry operators with new business models the number of extensions can only increase. How would an industry association address these challenges and reduce confusion for everyone? How could an association be structured?

The primary purpose of an association would be to facilitate communication and technical coordination among implementers and operators of the EPP protocol and its current extensions to address interoperability and efficiency obstacles. Other registry-registrar technical interactions, such as the implementation and deployment of the IETF’s Registration Data Access Protocol (RDAP), would also be appropriate. In scope activities could also include cooperation on the development of new EPP extensions, interoperability/conformance testing, and development of tools and software development kits. Marketing, policy development, and protocol standardization would be explicitly out of scope.

Using the 24 contact extensions as an example, discussion among operators could have identified areas of common need. Those common needs could be collapsed into a single extension used by multiple registries, reducing extension duplication and lowering the implementation barrier for registrars. An association could make it easier for those discussions to take place.

The association could be a non-profit, membership-based organization. Membership should be open to all interested industry members, including domain name registrars, gTLD/ccTLD registries, second-level domain registries, and parties providing software or back-end services to the foregoing. Address registries might eventually be interested in membership if we do decide to address RDAP operations.

Setting up and running a new technical forum can be expensive and time consuming, but alternatives exist to creating one from scratch. The IEEE-ISTO is structured to allow new associations to be formed both at a relatively low cost and with a high level of flexibility in terms of charter development and membership management. Using the ISTO does not mean this would be an IEEE standards effort. The ISTO just provides the operational framework and administrative services to multiple, independent technical industry associations.

Cost should be relatively low. ISTO monthly fees could be as low as $3K-$4K per month. We would need to ensure that the membership fees cover the costs. Some of the functions (like maintaining a web site or a mailing list) could be provided by members to reduce the cost.

IEEE/ISTO is one option for an association framework. There are others that leverage existing organizations. For example, it might be possible to charter an IETF working group focused on developing guidelines for registration operations, similar to the way the dnsop working group develops guidelines for the operation of DNS software and services and for the administration of DNS zones. The IETF has generally not chartered long-running working groups with open-ended milestones, so this might not be a viable option. A new association could drive standards by bringing proposals to the IETF after they’ve gained a measure of consensus within the operator community.

There are other organizations that count registration operators as members. The challenge with all existing organizations is that their primary mission is something other than technical registration operations. A new association creates an opportunity to bring registrars and registries together to discuss consolidating and simplifying the technical interfaces between our systems and to address other operational issues without having to worry about mission confusion.

In my third and final post in this series I will describe an opportunity for everyone that’s interested in discussing this topic in a live environment.