[gtld-tech] RDAP Features Missing from the Draft Profile Related to Current Policy Initiatives

[Hollenbeck, Scott]

Others have shared comments on the RDAP features described in the draft operational profile. I'd like to address features that aren't mentioned in the profile that could help address known operational issues with WHOIS. At least some of these should be given serious consideration in order to take advantage of the opportunity we have to address WHOIS issues as part of a transition to RDAP.

In RFC 7482 I described a number of issues with the WHOIS protocol that RDAP was designed to address, including:

o  lack of standardized command structures;
o  lack of standardized output and error structures;
o  lack of support for internationalization and localization; and
o  lack of support for user identification, authentication, and access control.

The profile addresses the need for standardized command structures, output structures, and error structures. It is incomplete in terms of support for internationalization/localization, user identification, authentication, and access control.

There are a number of active WHOIS-related policy efforts that can produce RDAP implementation requirements. It's not unreasonable to require implementation changes to add new features as these efforts produce results, but I'd like to avoid having to undo or remove features driven by policies that may be in conflict with the current profile proposal. Examples:

Expert Working Group on gTLD Directory Services (EWG)
https://community.icann.org/pages/viewpage.action?pageId=40175189

The EWG (of which I was a member) produced a lengthy final report that includes a number of recommendations that were intended to address many of the issues associated with WHOIS. The final report included a number of recommendations focused on data privacy. As-is, the profile perpetuates the WHOIS "all data available to everyone" policy. I'd very much prefer to start with a more limited approach to data access that can be broadened as we decide how best to implement the RDAP features that provide identification, authentication, authorization, and access control security services.

Thick WHOIS:
http://gnso.icann.org/en/group-activities/active/thick-whois

The profile describes a number of features that assume implementation of a "thick" registry. Two large top-level domain registries (.com and .net) are currently "thin" registries. There's still work to be done to determine how best to implement RDAP as the thick vs. thin policy discussion evolves. I would not want to be required to implement thick WHOIS knowing that there is a looming RDAP transition requirement. I am also a little concerned about the possibility of being required to implement thick RDAP without a thorough understanding of how it works in the evolving world of laws focused on protecting personally identifiable information (PII). It would be helpful if the profile included proposed implementation requirements for thin registries.

WHOIS Policy Review Team
https://community.icann.org/display/whoisreview/WHOIS+Policy+Review+Team

This team published its final report in May 2012. Among other things, the recommendations documented in the report address data accuracy and internationalized domain names (IDNs) and internationalized registration data. If we assume that issues with data accuracy are at least somewhat associated with current WHOIS requirements for public disclosure of PII, it may be wise to consider inclusion of RDAP security services that can be used to protect against unauthorized disclosure of PII.

Draft Final Report from the Expert Working Group on Internationalized Registration Data
https://gnso.icann.org/en/issues/ird/ird-draft-final-10mar15-en.pdf

The profile includes provisions for the representation of IDNs as either A-labels or U-Labels. It doesn't describe requirements to return responses containing internationalized registration data. Noting that internationalized registration data is referenced in Appendix E, it would be helpful to note that such requirements are being deferred (assuming that they are indeed being deferred and were not inadvertently omitted).

Scott