Cross-community discussion on next-generation gTLD registration directory services (RDS) policy requirements

Event report

Mr Chuck Gomes (Chair, Next-Generation gTLD Registration Directory Services (RDS) Policy Development Process (PDP)Working Group) gave a brief introduction to the next generation RDS PDP process, defining the purpose as collecting, maintaining, and providing access to generic top-level domain (gTLD) name registration data and considering safeguards for protecting the data.

He also described the three phases involved in this process: phase one, examining all requirements for gTLD registration data and directory services at a high level; phase two, developing detailed policies to satisfy those requirements; and phase three, creating any necessary implementation and coexistence guidance. He said that they were tasked on trying to reach consensus on what are the fundamental requirements for gTLD registration data. They are supposed to consider: users and purposes and associated access, accuracy, data elements, and privacy requirements. Fundamental question to be answered by ICANN60: is a new policy framework and Next-Generation RDS needed to address the requirements that they are developing? If yes, what cross-cutting requirements must any next-generation RDS address, including coexistence, system model, and cost, benefit, and risk analysis requirement? If not, does the current WHOIS policy framework sufficiently address these requirements? If not, what revisions are recommended to the current WHOIS policy framework to do so?

Dr Jin Galvin (Afilias and Vice-chair Security and Stability Advisory Committee (SSAC)) gave an overview of the draft statement of purpose which includes collecting, maintaining, and providing access to data. He noted that consensus had been reached by the working group on four specific purposes for registration data and RDS, which include, among others, the purpose to provide information about the lifecycle of a domain name and its resolution on the Internet.

Mr Rod Rasmussen (member, SSAC) explained that other purposes of the RDS was to facilitate dissemination of gTLD registration data of record, such as domain names and their domain contacts and name servers, identify domain contacts, and facilitate communication with domains contacts associated with gTLD names. He stated that the purpose of gTLD registration data in the RDS will be defined later in this PDP.

There were questions raised on the need for this exercise.

Responding to questions on the accuracy and relevance of the data published currently in WHOIS and whether there was a discussion of elements of data being collected to bridge the gap, Gomes noted that currently the focus was on thin data, or Minimum Public Data Set (data sufficient to identify the sponsoring registrar, status of registration, creation and expiration dates for each registration, name server data, the last time the record was updates in its WHOIS data store, and the URL for the registrar’s WHOIS service) and that the thick data of people and its administration was not under discussion.

Two questions were raised:  How does this address the basic EU data protection criteria and how will protection of the data based on the four parameters raised in the statement of purpose be addressed. Further, if the four parameters are used by people, how can they be protected from phishing, malware, etc. The need to include consumer protection and public safety from domain name abuse into the statement of purpose was emphasised. A respondent also pointed that there was no consensus of what items should be in the statements.

The issue of anti-abuse of registration data was also raised along with a question on how to  include public interest in the definition of accountability of data processing, privacy, and data protection.

On the review and discussion of preliminary agreements reached in relation to gated access to registration data, the deliberation was on what steps are needed to control access to gTLD registration data in the Minimum Public Data Set. Should gTLD registration data in the Minimum Public Data Set be public or should access be controlled. During the discussion, it was shared that per the draft working group agreement (no. 20), gTLD registration data must be accessible without requester identification, authentication, or stated purpose and there should be no policy that prevents RDS operators from applying operational controls, such as rate limiting and Captcha, provided they do not unreasonably restrict legitimate access (no. 21). There was also a discussion on what guiding principles should be applied to Minimum Public Data Set access.

On the issue of review and discussion of Preliminary Agreements reached in relation to privacy, there were discussions on what gTLD registration data in the Minimum Public Data Set should be collected, stored, and disclosed. The working group is now pursuing independent legal analysis to inform its deliberation on key concepts for data protection and privacy. There were questions raised on the words used in the document, on the existing gTLD RDS policy, and on lack of discussion on free speech.

A face-to-face meeting on 28 June will consider the cross-community session inputs to deliberate on key concepts for elements that go beyond the Minimum Public Data Set, along with the additional goals.