It has been my distinct pleasure to serve on ICANN’s Expert Working Group on gTLD Directory Services (EWG). We put in many long months and what seemed like countless hours of research, discussion, meetings, and deliberations on how to tackle a clean-slate approach to gTLD directory services, popularly known as “WHOIS”. In our Final Report [PDF], the Expert Working Group (EWG) recommended a Registration Directory Service (RDS) to replace today’s WHOIS, providing a next-generation system to better meet the needs of the evolving global Internet with greater accuracy, privacy, and accountability.

A great deal of discussion covering the many issues involved in this project occurred throughout the community during our work and continues to this day. The report is lengthy and comprehensive; yet still not a finely detailed blueprint of what a next generation system might be. As the community looks towards taking these issues forward via GNSO processes, many questions have been asked about the nature and rationale of our recommendations. There has also been a fair amount of speculation about our recommendations that could benefit from more background to provide for informed discussion and debate. To help inform the community, I thought it would be useful to share my own thinking on some of the more frequently asked questions surrounding the RDS. These thoughts reflect my own opinion and are not necessarily reflective of any group consensus or input. I do hope to capture the essence of what is in and behind the EWG’s report.

Why did the EWG recommend a Synchronized RDS?

During our time together, the EWG examined numerous potential models for an RDS. Several of these were outlined in our preliminary, update, and final reports, and beyond those published, we considered many other variants and combinations. We narrowed those models down to several likely candidates for further examination. After carefully considering the pros and cons associated with several possible models, the EWG recommended a synchronized model as the best way of implementing the proposed RDS.

What is the SRDS?

The Synchronized RDS (SRDS) model would provide a single point of uniformly-controlled and logged access to data that is continually pulled from a globally-distributed set of validators, registries and registrars, each of which is responsible for collecting data from contacts and registrants.

In the SRDS model, data is not centrally collected or stored. Rather, the SRDS model provides a single conceptual point of access, policy enforcement, and logging for gTLD registration data, spanning domain names issued by all gTLD registries.

The SRDS would, in near real time, receive registration data updates from thick registries and validators, pushed to the SRDS over EPP. Synchronized data would be readily available to the SRDS to speed queries and searches, but data collection and validation would still be performed by a large, distributed network of entities (registrars/resellers and validators) interacting with their customers (registrants and contact holders).

Is the SRDS centralized?

No. The SRDS is a large, highly-distributed ecosystem composed of many independently-operated ICANN-contracted parties: an RDS operator, gTLD registries, registrars and resellers, and validators.

Even the “core SRDS”—the conceptual component that provides access, enforcement, and logging—would be deployed using engineering best practices to achieve fault tolerance, high availability, and load balancing, including geographically-diverse data centers, robust diverse connectivity, and redundant infrastructure at each data center.

The SRDS does NOT require a single centralized database containing all gTLD registration data, and the EWG did not recommend that such a database be created. Rather, the EWG recommended a synchronized architecture as the most effective and efficient way to deliver proposed RDS benefits. Although choosing an RDS operator or locations for RDS data centers was beyond the EWG’s remit, our final report recommended that data be stored in multiple places in a consistent, coordinated way.

Why did the EWG recommend the SRDS model?

In reaching consensus on the SRDS model, the EWG carefully considered a Federated RDS (FRDS) model, as well as Regional, Opt-Out, and Bypass models, all compared against today’s WHOIS model and a specified set of criteria. Following a detailed comparison and cost analysis of the two most promising models—the FRDS and SRDS—the EWG recommended the SRDS.

We believe the SRDS model provides “one stop shopping,” reduces confusion for requestors, and creates an opportunity to deliver internationalized access through translation and transliteration. The SRDS model provides greater accountability and ability to track/audit data and access across TLDs. It makes it easier to apply appropriate data protection measures uniformly, using a rules engine to enforce a single RDS privacy policy that understands and respects the laws of every applicable jurisdiction. The SRDS model also provides the most efficient support for Reverse Query and WhoWas search capabilities.

Finally, based on a detailed study of costs performed by IBM, the SRDS model minimizes many costs. First, WhoWas and Reverse Query costs would grow exponentially as the number of Reverse Queries rises. More importantly, the FRDS model would require much more from every registry operator—including handling of high-volume, time-sensitive transactions and significant storage for WhoWas data. This affects not only implementation costs, but ongoing costs associated with operations, support, maintenance, and testing. Simply put, the SRDS is less complex than the FRDS.

Doesn’t the SRDS model elevate risk of abuse and attack?

As a “Big Data” source of highly valuable data, there is clearly potential for attack or abuse if not properly secured, audited and maintained. However, this risk may be no greater than risk posed by a highly distributed model with inconsistent and less easily-audited security measures. In fact, both the SRDS and FRDS models evaluated by the EWG produced similar results when evaluated against their impact on security. There are always security risks when increasing distribution of data (e.g., increased attack surface, ability to capture data in-transit between non-similar systems, inconsistent security postures and attack knowledge of disparate operators, difficult to recognize a coordinated attack due to lack of centralized monitoring)—but these risks are necessary in order to achieve a goal of dispersing data so that only a portion of it may be exposed to a breach. Depending on your risk assessment and priorities, these risks can far outweigh the benefits, particularly when one remembers that a large amount of the protected data could be exposed by an attack against any single member of a FRDS.

Finally, one must also put into perspective the risk of exposure of the data being protected. While names, addresses, e-mail addresses, and phone numbers of domain contact holders are certainly PII (Personally Identifiable Information), the RDS would not store more sensitive data like credit card information or government ID numbers. Further, there are many mechanisms built into the process to allow for domain registrants and their designated contacts to protect this personal data using privacy or proxy services or other third-party representatives. The argument that the RDS would create a giant database of extremely sensitive data that would be heavily attacked simply doesn’t hold much water when examined with these real-world, risk-based factors in mind.

To learn more about the proposed RDS, please read our report and FAQs.