Dear All,

Based on the discussions to date, the staff support team would like to put forward a suggestion in the hope that this conversation around the ‘working definition’ can be considered complete for now so that the group can focus on other pertinent issues. As we have explained previously, our understanding of the reference to a ‘working definition’ as part of assignment #1 was to ensure that whenever there would be a reference to ‘accuracy requirements’, there would be a common understanding of what these entail today. That does NOT preclude future discussion and/or consideration of what these should be, but that conversation needs to be informed by the findings of assignment #1 and #2. As such, we would like to propose the following:

Instead of using the term ‘working definition’ which has led to confusion, the Accuracy Scoping Team instead confirms that the following is its understanding of CURRENT accuracy requirements and enforcements. This understanding does not preclude in any way possible changes to these requirements and enforcement in the future based on the work of the scoping team and/or subsequent efforts.  

Accuracy under the current requirements, as spelled out in the Registrar Accreditation Agreement (RAA) as well as Consensus Policies, is understood as syntactic accuracy of the registration data elements provided by the Registered Name Holder or Account Holder as well as the operational accuracy of either the telephone number or the email address.

To be determined to be syntactically accurate, the contact must satisfy all requirements for validity (see Whois Accuracy Program Specification Sections 1b-d). For example, for email addresses all characters must be permissible, the “@” symbol is required, and there must be characters before the “@” symbol.

To be determined to be operably accurate, the contact must be operable as defined in the Whois Accuracy Program Specification Section f. The RAA currently requires validation of syntactical accuracy and verification of operational accuracy including an affirmative response from the Registered Name Holder for either email or phone.

In addition, upon notification of an alleged inaccuracy or if the Registrar learns of inaccurate contact information, the Registrar must take reasonable steps to investigate that claimed inaccuracy and correct inaccuracy. Additional verification procedures apply if the registrar has any information suggesting that contact information is incorrect. If a Registered Name Holder willfully provides inaccurate or unreliable registration data information, the registrar will take additional action to terminate, suspend or place a registration on hold.

Furthermore, in addition to the requirements in the RAA and Consensus Policies, a number of Registry Agreements also contain some specific requirements in relation to accuracy that apply to that specific TLD, such as, for example, .AERO, .BANK or any spec 13 Registry operator (see for further details https://newgtlds.icann.org/en/applicants/agb/base-agreement-contracting/specification-13-applications). 

Again, agreeing on this description of what is currently required and enforced, does not preclude a conversation about what the different parties think it should evolve to (or not) based on data that is gathered as part of assignment #2, but that conversation needs to be informed by that data in order to be productive.

We hope this is helpful. We look forward to receiving your feedback.

Caitlin, Berry and Marika