Page History

...

• For Scoping Team Final Org Responses to Data Accuracy Scoping Team Questions .pdf
• 1_19_22 Org Answers to Follow-up Questions from Data Accuracy Scoping Team.pdf
• Final ICANN Org Compliance Responses to Accuracy Scoping Team Questions April 22'.pdf

Also (content not reproduced below)

...

ICANN Contractual Compliance takes into account the totality of the information/evidence available. For instance, in the example provided, a fictional address “1234 Main Street, Disneyland, 00000, USA” combined with the Registrant Name “Mickey Mouse”, would be sufficient to suggest that the data is incorrect. ICANN Contractual Compliance further notes that it does not independently make determinations of accuracy, but may initiate a notice or inquiry where the information/evidence suggests that such contact information is incorrect.

==========

Follow up questions (responses received 6 April 2022)

1. The 2013 RAA Whois Accuracy Program Specification section 4 requires a Registrar take certain actions if it has any information that specific RDDS fields are wrong (fields references are any of the name, postal address, e-mail address, voice telephone number, and (where available) fax number).The example given in section 4 of having such information is: “Registrar receiving a bounced email notification or non-delivery notification message in connection with compliance with ICANN's Whois Data Reminder Policy or otherwise”. In the view of ICANN Compliance, does this example apply only to Registrars who happen to monitor such email bounce or non-delivery notifications, or are Registrars obliged to do such monitoring?

Section 4 of the Whois Accuracy Program Specification (Specification) applies to all registrars that have “any information suggesting that the contact information specified in Section 1(a) through 1(f) of [the Specification] is incorrect” and is not limited to registrars who proactively monitor email bounce or non-delivery notifications. Information suggesting an inaccuracy in the RDDS Registration Data may come from sources other than a registrar’s self-monitoring, including ICANN Contractual Compliance (Compliance) in the event it receives a report containing sufficient evidence of inaccuracy (including a bounced email notification or non-delivery notification message).

The Registrar Accreditation Agreement (RAA) and the Specification do not contain requirements for a registrar to monitor bounce back or non-delivery notifications of email communications it sends to its registrants or other contacts as contained in Section 1 of the Specification. However, if through a registrar’s own practices it becomes aware of information that suggests the contact information is inaccurate, the obligations described under Section 4 of the Specification do apply.

2. If a Registrar is obliged to monitor such email notification of non-delivery, are they similarly required to monitor other delivery methods (such as postal mail failure to deliver, or a message to through the Registrar’s domain management portal never being viewed)?

Not applicable, see response to question 1 above.

3. If a Registrar is obliged to do such monitoring, does ICANN Compliance audit this requirement?

Not applicable, see response to question 1 above.

4. Section 4 goes on to require that “Registrar must verify or re-verify, as applicable, the email address(es) as described in Section 1.f…” With respect to the reference to “email address(es)”, since the information about inaccuracy may be about any of the name, postal address, e-mail address, voice telephone number, and (where available) fax number, is the Registrar only required to verify or re-verify the email addresses (even if the inaccuracy was in respect to one of the other fields)? If other fields are included, please be specific as to what fields must be verified or re-verified.

Verification, as described under Section 4 of the Specification, applies to the email address(es) of the Registered Name Holder (RNH), and Account Holder (AH), if different. Note however that registrars must also take reasonable steps to investigate a claimed inaccuracy (RAA Section 3.7.8), which may not be limited to verification or re-verification of the email address(es), and can include additional actions necessary to address the inaccuracy (or alleged inaccuracy).

5. The ICANN Org comments on the RrSG definition of accuracy saying that accuracy requirements are not limited to syntactical and operational accuracy implies that it may also include the requirement that the field contents are in fact associated with the RNH, and lacking such association, they may be deemed inaccurate. Is this an accurate reading of the ICANN Org comment, and if not, please explain just what the characteristics are that might make such fields inaccurate (in cases which are not as blatant as Mickey Mouse residing on Main Street of Disneyland)?

ICANN is not clear what the phrase “associated with the RNH '' means in the context of this question. Upon notification of an inaccuracy in contact information, registrars are required to investigate, and, where applicable, correct any inaccuracy. Compliance will enforce this requirement where a registrar has any information to suggest that the contact information listed in Section 1 of the Specification is incorrect. Some examples of reported inaccuracies are provided below in an effort to help describe what characteristics may be sufficient to suggest an inaccuracy in the contact information in the RDDS (other than syntactical accuracy and operational accuracy of the email and/or telephone, as described in Section 1(f) the Specification):

• An individual reports that their home address is used in Registration Data for a domain name that is not associated (or is no longer associated) with that address;
• Business entity address/telephone/etc. used in Registration Data by someone not authorized to use and/or not associated with that business entity (e.g. ex-employee continues utilizing address of employer);
• Privacy or Proxy Service contact information used in Registration Data for a domain name that is not or is no longer utilizing that P/P Service.