Dear Caitlin, Berry and Marika, Thank you for your helpful approach. I support the approach of defining the current requirements as the baseline for our discussions. I agree that settling this matter will allow us to move forward. Best, -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Tue, Mar 15, 2022 at 3:10 PM Marika Konings <marika.konings@icann.org> wrote:
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/spec... <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
_______________________________________________ GNSO-Accuracy-ST mailing list GNSO-Accuracy-ST@icann.org https://mm.icann.org/mailman/listinfo/gnso-accuracy-st
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.