[GNSO-Accuracy-ST] Description of current accuracy requirements and enforcements - staff support team suggestion

[Volker Greimann]

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 at 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/specification-13-applications
> <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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-accuracy-st/attachments/20220315/fc0b9511/attachment-0001.html>