Input to Expert Working Group on gTLD Directory Services Comments and Queries on RDS

[Operations-AFCC]

Dear EWG,

First of all, we would like to express our appreciation for embarking on this endeavor. We fully agree that starting with a clean slate is crucial for defining the next generation of registration data and we encourage you to collaborate with the community in order to bring a better, holistic product.

RSA's Anti-Fraud Command Center (AFCC) is a veteran player in the infosec landscape, focusing on fighting online fraud and malicious activities.
Analyzing WHOIS data is the bread and butter of our business so we find it as a great opportunity to contribute and to shape the next generation of the WHOIS infrastructure.

We have carefully read the relevant documents and FAQ and would like to share our inputs and raise some questions:


·         Purpose-Driven Data Access and Disclosure -

o   We suggest to employ a flexible RBAC that will enable authorized users to obtain full information and even bypass privacy protection services, especially users like LEA, non-LEA, white hats, etc.;

o   Will the ARDS enforce query limits?

·         New Data Set -

o   It is not entirely clear how is the new registration data set look like and which data elements are mandatory;

o   When can we expect to see the new format?;

o   Will RDS be available just as a text or in additional formats (e.g.: XML)?;

·         Resellers - we often see not only proxy/privacy providers but also resellers; we believe that resellers should disclose their end subscriber as well;

·         ccTLDs -

o   This comment is general to ICANN as we get the appreciation that guidelines and regulations legislated by ICANN are mandatory for gTLDs and not always being respected by ccTLDs registries. Sometimes they absorb or comply with these guidelines in a significant delay. We do not fully understand that in general and wonder if the RDS is the next generation 'WHOIS' for all types of domain names, or not;

o   Nowadays we encounter plenty of ccTLD registries that maintain registration information in the local language (e.g.: Brazil, Taiwan, China, and more); we suggest to enforce a rule to require uniform registration form in English (perhaps in addition to the local language);

o   Would RDS be a 'one stop shop'? Would it be possible to query all registries (of both gTLDs and ccTLDs) under one roof?

·         Registration Data Elements - we suggest to consider the following data elements as mandatory and to audit them on a regular basis:

o   The domain's purpose or the domain's usage purpose. While we believe that scammers and fraudsters who register domains to commit online fraud wouldn't be honest in filling this field, we also believe that if this field is mandatory and if provision of false information would be considered as breaking the terms of registration, it would be an effective avenue to reduce fraud;

o   Clearer and more conclusive statuses. The current statuses (e.g. ClientTransferProhibited et al) are sometimes vague;

o   Registrant identifier - serial number, ID or any other unique identifier;

o   Registrar identifier - serial number, ID or any other unique identifier. We encounter multiple variations of the same entity;

·         Tracking - it would be handy to be able to see previous versions of the RDS record. When a registrant update something in the registration info (even just extends the registration) it shows when the WHOIS 'last updated' but there is no reference to what updated;

·         API - would it be possible to obtain RDS info via API?

·         Implementation - would RDS apply only for new domain names or for existing domain names as well? How much time do you believe it will take to transfer the existing registration info into RDS?


We are looking forward to collaborating with you.
Thank you for opening this important initiative to public comments.


Kind Regards,
Oren David

Oren David | AFCC Operations Manager | Online Threats Managed Services (OTMS) | RSΛ, The Security Division of EMC | O: +972-9-9732237; M: +972-54-3076670 | e: oren.david at rsa.com<mailto:oren.david at rsa.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/input-to-ewg/attachments/20140806/c81c5e96/attachment.html>