Page History

The purpose of this initiative is to review the 2013 Registrar Accreditation Agreement’s Whois Accuracy Program Specification.

This paper provides an outline for a review of the 2013 Registrar Accreditation Agreement’s Whois Accuracy Program Specification (“Whois Accuracy Specification”). This paper reviews the requirements in the Whois Accuracy Specification and summarizes input from ICANN staff and the Registrar Stakeholder Group regarding areas where the Specification could potentially be improved.

ICANN seeks public comments on the questions and suggestions identified below and any other issues that might be considered through this review.

The 2013 Registrar Accreditation Agreement's Whois Accuracy Program Specification ("Specification") created substantial new requirements for ICANN-accredited registrars for the validation and verification of Whois information and customer account holder information.

The Specification requires ICANN to review the terms and conditions, in consultation with the Registrar Stakeholder Group. 

The Specification requires registrars to validate registrant and account holder information within 15 days of registration, transfer, or registrant or account holder data change. The validation process requires registrars to ensure that required fields are filled and that email addresses, postal addresses, and telephone numbers are in a proper format. Cross-field postal address validation is envisioned, but not required until ICANN and the cross-field validation working group of registrars agree that the process is commercially and technically feasible.

The Specification also requires registrars to verify registrant and account holder email addresses or telephone numbers within 15 days of (a) registration, transfer, or registrant or account holder data change; or (b) a bounce or other evidence of inaccuracy. The verification process requires an affirmative response—a non-response by a registrant requires either manual verification by the registrar or suspension of the domain registration.

The Specification requires registrars to delete or suspend domain name registrations in cases of willful provision of inaccurate or unreliable data; willful failure to update data promptly; and a registrant's failure to respond to a registrar's data accuracy inquiry for over 15 days.

ICANN staff has reviewed the Specification and shared comments and observations, and solicited the same from the Registrar Stakeholder Group. We now seek public feedback through this comment forum.

ICANN Staff Input

The observations below were primarily provided by ICANN's Contractual Compliance team and are based on their experiences in enforcing the Specification and on registrar feedback received during the course of compliance inquiries.

Section 1

1. It would be helpful to clarify the difference between "validation" and "verification" or use different terminology, because the distinction is often lost in translation.

For example, the terms could be defined as follows, or as otherwise defined through this review:

Verification: The process by which a registrar confirms or corrects the accuracy of Whois data by contacting and receiving an affirmative response from the Registered Name Holder.  

Validation: The process by which a registrar ensures that the format of Whois data is consistent with standards.

1. It might be helpful to clarify what is intended by "manual verification" in Sections 1, 2, and 4, in order to help prevent unnecessary suspensions of domain names.
2. We might wish to make explicit that validation and verification are not required upon renewal (absent a change to contact data, etc.). Similarly, we might clarify that data can be validated/verified before registration (to help prevent suspension of new registrations).

Section 2

1. Section 2 requires registrars to re-validate and re-verify changed fields. If the registrant does not respond to the verification attempt, the registrar must either manually verify the data or suspend the registration. The section should be more explicit that suspension would also be required if the validation failed.

Section 5

1. This section currently reads: "Upon the occurrence of a Registered Name Holder's willful provision of inaccurate or unreliable WHOIS information, its willful failure promptly to update information provided to Registrar, or its failure to respond for over fifteen (15) calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder's registration, Registrar shall either terminate or suspend the Registered Name Holder's Registered Name or place such registration on clientHold and clientTransferProhibited, until such time as Registrar has validated the information provided by the Registered Name Holder."  We believe verification should be required, in addition to validation, where a domain name was suspended due to inaccurate Whois data, since the inaccurate data presumably passed validation checks already.

Registrar Stakeholder Group Input

The Registrar Stakeholder Group ("RrSG") provided ICANN with the following questions and suggestions for updates to the Specification. A redlined version submitted by the RrSG containing these suggested revisions is attached.

Section 1

1. Section 1 of the Specification requires registrars to validate and verify Whois information and corresponding customer account holder information when a domain name is registered, transferred, or when the Registered Name Holder is otherwise changed. This section should be amended to require validation and verification only when a domain name is registered, not when a domain name is transferred or when there is any change in the Registered Name Holder. The transfer-related requirement is the most harmful part of this provision and should be removed since law enforcement recommendations that called for validation and verification did not target domain name transfers.
2. Section 1(a) requires validation of the presence of data for all fields required under RAA Subsection 3.3.1 (https://icann.org/2013raa#3.3.1) in a proper format for the applicable country or territory. The "proper format" requirement should be deleted because it duplicates a requirement in Section 1(d).
3. Section 1(d) requires registrars to validate that postal addresses are in a proper format for the applicable country or territory as defined in UPU format templates, the S42 address templates, or other standard formats. This should be amended to consider alternative, non-UPU formatting sources.
4. Section 1(e) requires registrars to validate that all postal address fields are consistent across fields where such information is technically and commercially feasible. This requirement should be deleted.
5. Section 1(f)(i) requires registrars to verify the email address of the registered name holder (and, if different, the account holder) by sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the registrar. This section should be amended to delete the required process, giving registrars leeway to choose the process they will use to verify the email address.
6. Section 1(f)(ii) requires registrars to verify the telephone number of the registered name holder (and, if different, the account holder) by either calling or sending an SMS to the registered name holder providing a unique code or calling the registered name holder's telephone number and requiring the registered name holder to provide a unique code that was sent to the registered name holder. This section should be updated to delete the required processes, giving registrars leeway to choose the process they will use to verify telephone numbers.
7. Section 1(f) states that if a registrar does not receive an affirmative response from the registered name holder, the registrar shall either verify the applicable contact information manually or suspend the registration. This should be updated to provide a 45-day window for the registered name holder's response.
8. It is unclear what Section 1(f) means by "verify the applicable contact information manually." This section should be amended to add an example "i.e. email or telephone number."
9. In Section 1(f), are there any other options short of suspension of a registration if a registrar does not receive an affirmative response from the registered name holder?

Section 2

1. Section 2 requires registrars to validate and verify changed fields in Whois or the corresponding account information within fifteen calendar days after receiving any changes to the contact information. This should be updated to only require validation and verification when a change is "substantial."
2. Section 2 states that if a registrar does not receive an affirmative response from the registered name holder, the registrar shall either verify the applicable contact information manually or suspend the registration. This should be updated to clarify that the registrar's duty to verify the contact information or suspend the registration arises if the registrar has not received an affirmative response within forty-five days. This should also be updated to provide examples of "applicable contact information," "(i.e., email or telephone number)."

Section 4

1. Section 4 states that if a registrar has any information suggesting that Whois or account holder information is incorrect, the registrar must verify or re-verify the email address(es). This should be updated to add the word "substantiated" before "information," which would force complainants to provide evidence of their claims and could reduce the number of inaccuracy complaints that would trigger re-verification.
2. Section 4 states that "…Registrar must verify or re-verify, as applicable, the email address(es) as described in Section 1.f (for example by requiring an affirmative response to a Whois Data Reminder Policy notice)." This should be amended to state that "…Registrar must verify or re-verify, as applicable, the incorrect information."
3. Section 4 should be amended to provide registered name holders a forty-five day window to respond to a registrar communication regarding potentially incorrect Whois or account information before the registrar must either manually verify the applicable information or suspend the registration.

Section 5

1. Section 5 requires registrars to either terminate or suspend a registered name holder's registered name or place such registration on clientHold and clientTransferProhibited status upon a registered name holder's failure to respond for over fifteen calendar days to inquiries by the registrar concerning the accuracy of contact details. This requirement should be limited to instances when registrar inquiries concerning the accuracy of contact details are substantiated.

Section 6

1. Section 6 states that the terms and conditions of the Specification are to be reviewed by ICANN in consultation with the Registrar Stakeholder Group on or about the first anniversary of the date that the 2013 RAA was first executed by a registrar. This section should be amended to require an annual review of the Specification, but no more than once per twelve calendar months.

Section 7

1. Section 7 should be re-numbered Section 8.
2. A new section 7 should be added: "Registrars are permitted to engage third parties (e.g. Resellers) to deliver these services, but recognize that they, as the signatory to the RAA, are ultimately responsible for ensuring compliance with these requirements."

In addition to these specific suggested edits and questions, the RrSG urged ICANN to keep in mind the goal of universal acceptance:

"If we are to have universal acceptance of TLDs and IDNs, increased pressures on validation/verification might work against the goal of greater internationalization of the namespace, at least in the short term.

As discussions move toward enabling registrants to enter WHOIS data in their own script / language, it is foreseeable that many may want to use an IDN email address.  If we are to support and encourage universal acceptance, there will need to be some relaxation of the rules to account for universal acceptance issues in internationalized email addresses and contact data."

• 2013 RAA Whois Accuracy Specification
• ICANN Staff Input on 2013 RAA Whois Accuracy Specification [PDF, 260 KB]
• Registrar Stakeholder Group input on 2013 RAA Whois Accuracy Specification [PDF, 140 KB]