In 1905, philosopher George Santayana famously noted, “Those who cannot remember the past are condemned to repeat it.” When past attempts to resolve a challenge have failed, it makes sense to consider different approaches even if they seem controversial or otherwise at odds with maintaining the status quo. Such is the case with the opportunity to make real progress in addressing the many functional issues associated with WHOIS. We need to think differently.

Over the last several years a large number of people have worked diligently to explore real alternatives in both technology and policy. On the technology front, the Internet Engineering Task Force (IETF) published a series of RFC documents in March 2015 that specify the Registration Data Access Protocol (RDAP). In 2013, ICANN formed an Expert Working Group (EWG) on generic Top-Level Domain (gTLD) Directory Services. This group produced its final report in June 2014. Both of these efforts were focused on finding new ways to provide registration data directory services by replacing WHOIS.

Current Deficiencies

Fast forward to October 2015 and ICANN-54. On Wednesday, Oct. 21, a session was held to discuss an ICANN proposal for an RDAP implementation profile for use by generic gTLD registries and registrars. During the session (at approximately 38:16 of the audio transcript) an ICANN staff member described a number of steps that are needed to provide “complete functionality equivalence with WHOIS.” What is the benefit of replacing WHOIS with something that is functionally equivalent—and thus functionally deficient? RFC 7482 describes the following WHOIS protocol deficiencies:

• Lack of standardized command structures
• Lack of standardized output and error structures
• Lack of support for internationalization and localization
• Lack of support for user identification, authentication and access control.

Recommendations

The EWG on gTLD Directory Services was formed in February 2013 to “define the purpose of collecting and maintaining gTLD registration data, and consider how to safeguard the data” and to “provide a proposed model for managing gTLD directory services that addresses related data accuracy and access issues, while taking into account safeguards for protecting data.” The group’s final report recommended that “a new approach be taken for registration data access, abandoning entirely anonymous access by everyone to everything in favor of a new paradigm that combines public access to some data with gated access to other data.”

RDAP was designed to address the WHOIS deficiencies and the EWG recommendations, but the proposed profile only provides the benefits of standardized command, output and error structures. The profile does not address internationalization and localization of contact information. The profile also does not include support for RDAP’s user identification, authentication and access control features. These features are needed to provide data privacy by restricting data access to appropriately authorized users. As currently written, the profile continues the practice of exposing personally identifiable information to anyone who asks. With these much-needed features excluded it would be more reasonable to defer implementation until we have clear consensus on the associated policies. No work will have to be undone in the future if we need to develop additional protocol specifications and add features later.

Our Opportunity to Address the Issues

This issue—the plan to not include support for RDAP’s internationalization and data privacy supporting features—is where the profile is setting our industry up for failure. An RDAP implementation that fails to address the most significant issues with WHOIS turns unsolved WHOIS problems into unsolved RDAP problems, and the history of failure to resolve WHOIS deficiencies repeats itself. I’ve authored an Internet-Draft document that describes one way to address the data privacy problem. There are almost certainly other approaches worth considering. It will take time to consider our options and think through the policy implications associated with data privacy, but that would be time well spent given the evolving nature of data privacy laws and practices in the different legal jurisdictions where gTLD registries and registrars do business. The risk of conflict with these laws and practices needs to be considered to ensure that RDAP implementation, deployment and operation remains a commercially reasonable undertaking.

The profile notes that additional protocol specifications are needed to map Extensible Provisioning Protocol (EPP) domain status codes to RDAP status codes, extend RDAP search capabilities and extend RDAP to include events that describe the registrar expiration date and the date of the most recent database update. The proposed profile implementation schedule includes milestones for the availability of these specifications as RFCs in 2016, but as of today only the domain status mappings are described in an Internet-Draft. If we’re going to take the time to develop these features, why should we not take the time to address the internationalization/localization and data privacy features as well? Without these features RDAP produces little more than a JSON-encoding of today’s WHOIS data.

I’m also concerned about the approach being taken to develop the profile itself. The IETF has a long tradition of documenting protocol implementation profiles using the Internet-Draft and Informational RFC publication process. Here are a few recent examples:

• Adobe’s RTMFP Profile for Flash Communication (RFC 7425)
• Suite B Profile for Transport Layer Security (TLS) (RFC 6460)
• Suite B Profile of Certificate Management over CMS (RFC 6403)

The registry industry used the IETF process to develop the RDAP protocol specifications. We should use the same IETF process to document an RDAP implementation profile.

With RDAP we have a historic opportunity to address the most pressing WHOIS deficiencies. If we fail to take advantage of this opportunity we run the risk of RDAP becoming yet another failed attempt to replace WHOIS. ICANN will open a public comment period for their implementation profile proposal within the next few weeks. Be sure to read the proposal and share your opinions. It’s time to take a different approach.