Scott Hollenbeck is a fellow of industry standards and technology in the chief technology officer organization, where he manages a team of engineers and researchers who focus on exploring innovation opportunities and emerging technologies. Scott has more than 30 years of expertise in the Domain Name System space, applications programming, systems architecture, network engineering, information security, financial analysis, and personnel management.
Prior to joining Verisign in 1998, Scott held management and engineering positions with Xerox Corporation. There, he chaired a cross-corporate group responsible for interoperability testing of all Xerox network and desktop software products. Before Xerox, Scott served as a first lieutenant officer in the U.S. Air Force.
Scott has authored many internet protocol standards, including: the Extensible Provisioning Protocol, a standard protocol for the registration and management of internet infrastructure data, including domain names; and the Verisign Registry-Registrar Protocol, a pre-cursor of EPP developed for use in the Verisign Shared Registration System; and most recently, he has co-authored the Registration Data Access Protocol, a standard protocol that was designed to replace the WHOIS protocol. He has been a contributor to several industry efforts related to domain names and internet security, such as internationalized domain names, public key cryptography, Secure/Multipurpose Internet Mail Extensions, the Extensible Markup Language, the Transport Layer Security protocol, and the ENUM protocol.
He has also served in various capacities on the Internet Corporation for Assigned Names and Numbers’ Expert Working Group on generic top-level domain directory services; the Internet Engineering Task Force’s Internet Engineering Steering Group; and the Web Extensible Internet Registration Data Service, Registration Protocols Extension, Extensible Provisioning Protocol Extensions, and Transport Layer Security working groups.
Scott holds a Master of Science in computer science and a graduate certificate in software engineering from George Mason University and a Bachelor of Science in computer science from the Pennsylvania State University.
In Parts I and II of this series of blog posts I described the need for a registration operations industry association. At the end of Part II, I wrote that Part III will describe “an opportunity for everyone that’s interested in discussing this topic in a live environment.” The large number of people attending ICANN 51 in Los Angeles presents the best chance of discussion with many potential participants being in the same place at the same time. Let’s take advantage of that proximity.
Verisign will host a workshop for all interested people during the week of ICANN 51. The event will be held at the Hyatt Regency Century Plaza hotel (the same venue for ICANN 51, though this event is not affiliated with ICANN) on the morning of Thursday, October 16, 2014, to discuss the challenges of registration technical operations and to explore ways to address those challenges. We’ve set up a website at www.regiops.net to provide information, describe the event, and allow people to register. We’re asking people to register in advance so we can make sure that we have a large enough room reserved and that we provide enough food for breakfast and lunch.
In Part I 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?
Since 2001 there have been occasional conversations on technical mailing lists exploring the concept of creating an independent industry association or consortium of domain registration operators. My recent experiences with the evolution of extensions to the Extensible Provisioning Protocol (EPP) have convinced me to look at these suggestions more closely, and I’m now convinced that this is an idea worth exploring.
“Registration Operations” refers to the technical tasks, such as the development, deployment, and ongoing systems administration of EPP, performed by registries and registrars to provide registration services. While EPP is used to provide domain name registration and management services, registration operations also include the tasks performed by Regional Internet Registries (RIRs) to provide address registration and systems administration services.
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.
