Page History
...
ICANN Contractual Compliance (Compliance) has a robust training program to ensure all team members that are responsible for processing complaints related to accuracy are familiar with the contractual obligations under the Registrar Accreditation Agreement (RAA) and the Whois Accuracy Program Specification in the RAA (Specification). Compliance has designated Subject Matter Experts (SME) related to accuracy requirements and an assigned Lead to train staff and oversee the processing of complaints and contracted party cases. Compliance’s enforcement actions and training are guided by the contractual requirements within the RAA, Registry Agreements, and ICANN policies. In addition to reliance on the related contractual requirements within these agreements and policies, Compliance utilizes a hands-on approach to training. To independently process complaints and cases in this area, team members must demonstrate an understanding of the Registration Data Directory Service (RDDS), requirements relating to both display and accuracy of Registration Data (including modifications under the Temporary Specification for gTLD Registration Data), as well as the ability to identify valid complaints and registrar compliance. Accuracy SMEs and the Lead perform regular quality assurance reviews of cases.
Accuracy Complaints
2. Previously Whois accuracy complaints were presumably mainly the result of publicly available registration data, but what kind of complaints is Compliance seeing now?
ICANN Contractual Compliance receives a variety of complaints related to the accuracy of Registration Data, including but not limited to complaints concerning:
A. Accuracy of Registration Data that is available in the public Registration Data Directory Services (RDDS), i.e. not redacted (examples include where registrar is not required to apply redactions under Appendix A, Section 2.1 of the Temporary Specification for gTLD Registration Data (Temporary Specification) and does not apply Appendix A, Section 3; registrar applies redaction but is required to display Registration Data based on Consent of the data subject, or full Registration Data is displayed where the domain is registered using a privacy or proxy service).
B. Accuracy of the Registrant, Admin, and/or Tech Email value(s), which are redacted pursuant to Appendix A, Section 2.5 of the Temporary Specification but the displayed email or web form does not facilitate communication with the relevant contact.
C. Accuracy of the underlying Registration Data that is redacted in the RDDS, and the reporter has provided evidence of having obtained the data from the registrar, or another reliable source such as the registrant.
3. What is the main cause for complaints being rejected by ICANN Compliance instead of being passed on to registrars?
Complaints received by ICANN Contractual Compliance that are not passed on to registrars are generally closed as out of scope of the contractual requirements under the Registrar Accreditation Agreement (RAA) and ICANN Policies. The majority of these are closed because: 1) the reporter did not provide evidence sufficient to support a claim that the Registration Data is inaccurate and ICANN was unable to independently confirm an inaccuracy in the public Registration Data; or 2) the reporter did not understand that the Registration Data is redacted pursuant to the Temporary Specification for gTLD Registration Data, i.e. the reporter believed that Registration Data was missing. Additional examples of out of scope complaints include those referring to ccTLDs, registrants contacting ICANN to update Registration Data, and complaints about Registrant Data of a valid privacy or proxy service provider (i.e. reporter believed the registrar must display the privacy/proxy service customer’s own personal data in the RDDS, rather than data pertaining to the privacy or proxy service provider).
4. To what extent will ICANN Contractual Compliance respond to complaints that a registrant is using contact information that does not belong to them. That is, although the information is syntactically correct, the complainant claims that it is not being legitimately used by the registrant. This is particularly relevant to registrations associated with legal entities (the classic example is Facebook) but is not limited to them.
ICANN Contractual Compliance (Compliance) enforces contractual requirements on the contracted parties, not registrants. Registrants do not have agreements with ICANN. Compliance requires that all complaints concerning inaccurate Registration Data be supported by information or evidence of the alleged inaccuracy, including those involving a registrant that is "using contact information that does not belong to them". If a reporter provides the requisite supporting information or evidence, ICANN will initiate a notice or inquiry with a registrar. Examples of these types of complaints include: 1) complaint from a Privacy or Proxy (P/P) Service Provider that alleges that the registration is not registered using its service, but the information in the Registration Data Directory Service displays the P/P Service Provider’s contact information without authorization; 2) complaint from a representative of a legal person that alleges the registration is using the entity’s contact information without authorization.
5. In past meetings, ICANN Compliance has stated in the past that complaints are “usually” from the Registrant. Does ICANN provide any metrics on the Data Inaccuracy complaints from Registrants/Registered Name Holders and third parties? If so can ICANN Compliance provide those numbers.
Transition to the Naming Services portal (NSp) on 29 August 2020 provided ICANN Contractual Compliance greater functionality and improved data-capturing functionalities, including the ability to collect data concerning reporter type, including: Registrant-Former; Registrant-Current; Law Enforcement Authorities, Consumer Protection, Government or Data Protection Agency; Intellectual Property Lawyer/Brand Protection; Authorized Representative; Information Security Researcher; and Other. Note that the reporter type refers to the capacity in which the reporter submitted the complaint, which is selected by the reporter at the time of submission and is not determined by ICANN Contractual Compliance.
...
Additionally, while ICANN Contractual Compliance lacks the context of the statement referenced above that “complaints are ‘usually’ from the Registrant”, it is believed that this may be in reference to other complaint types that involve contractual obligations directly impacting registrant rights with respect to the domain name registration, such as domain renewal and/or transfer. With respect to complaints concerning inaccurate Registration Data specifically, as reflected above, third-party complainants submit the majority of complaints.
6. Regarding ICANNs relationship with alternative dispute resolution providers, in WIPO UDRP Proceeding D2021-1050, the Panelist detailed multiple “inaccurate disclosures” regarding the registrant of the domain name in question and other “misconduct by the Respondent and by the Registrar.” The Panelist further wrote that “[t]his is an issue that the Panel believes should be addressed by ICANN, and the Panel requests that the Center share this decision with ICANN so that ICANN may consider whether to impose restrictions on such behavior by registrars.
...
a. Can ICANN confirm if WIPO ever contacted ICANN compliance in connection with this dispute and what if any actions did ICANN Compliance take?
b. Does ICANN Compliance have a formal reporting channel for UDRP and URS providers to share information with ICANN compliance regarding false or inaccurate Registrant data?
ICANN confirms that the issue referenced in this question has been reported to ICANN and that ICANN org is in the process of reviewing it. However, please note that ICANN’s scope in regard to this issue is limited to enforcement of current agreements and consensus policies.
...
With regard to the ability for UDRP and URS providers to report inaccurate Registrant data, they may do so through the channels that have always been available to the UDRP and URS providers, which are the publicly facing complaint forms available here: https://www.icann.org/compliance/complaint. Complaint submissions through these forms allow ICANN Contractual Compliance to track, monitor, and respond to complaints which contribute to metrics and reporting.
7. “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”. (RAA Whois Accuracy Program Specification)
In receipt of an inaccuracy complaint does ICANN compliance track the actual days it takes for the registrant to become compliant? Is this reported by the registrar? How many domain names are terminated vs suspended?
...
While ICANN Contractual Compliance does not separately track closures relating to termination vs suspension, it notes that termination of a registered name occurs infrequently and generally applies where the registrar determines the inaccuracy constitutes a breach of its registration agreement (for example, willful failure to provide accurate information). The number of complaints closed as suspended vs. updated is published on the monthly dashboard available here.
8. “However if the complaint is about identity (e.g., the registrant is not who they say they are), Contractual Compliance may ask the registrar to provide further information concerning their findings and the results of their investigation specific to the facts of the complaint”. (Blog post “ICANN Organization Enforcement of Registration Data Accuracy Obligations Before and After GDPR”)
When a registrar provides further information concerning their findings does ICANN compliance track this information and look for trends of abuse?
...
ICANN Contractual Compliance does not track individual details of registrar responses to each complaint. However, it attempts to identify patterns and systemic issues of noncompliance within and across all of the complaint types. This effort is useful in identifying trends of issues and most importantly in identifying opportunities to conduct outreach or additional proactive monitoring.
9. Not all inaccuracy complaints are sent to ICANN compliance many registrars suggest reporting inaccuracy complaints directly to the registrar. Are there any stats on domain names suspended as a result of inaccuracy complaints that were made directly to the registrar that are requested in an audit of the registrar by ICANN compliance?
The ICANN Contractual Compliance Audit Program has not requested statistics on domain names that are suspended as a result of inaccuracy complaints made directly to the registrar and without involving ICANN. The Registrar Accreditation Agreement does not require registrars to report this information to ICANN.
...
Verification and Validation
10. How does ICANN define and differentiate between existing verification and validation requirements?
Verification and validation requirements are set forth in the Whois Accuracy Program Specification (Specification). Verification is the process by which a registrar confirms or corrects the accuracy of Registration Data by contacting and receiving an affirmative response from the Registered Name Holder (RNH) in the manner prescribed by the Specification.
...
Validation is the process by which a registrar ensures that the presence and format of Registration Data for all required fields is consistent with applicable standards.
Validation
11. What criteria does ICANN Compliance use to evaluate compliance with validation requirements?
Registrars are required to provide ICANN Contractual Compliance with both the results of their validation and the method used for validation. Examples of methods of standard formats include RFC 5322 for email addresses, ITU-T E.164 notation for the format of international telephone numbers and for the format of postal addresses the UPU Postal addressing format templates, the S42 address templates (as they may be updated) or other standard formats for the applicable territory.
...
ICANN Contractual Compliance may evaluate the Registration Data in accordance with the standard format confirmed by the registrar.
12. What are the validation requirements for *each* of the data elements required to be collected by the registrar?If possible, use the four level scale of V0, V1, V2, V3.
V0 = No validation required.
...
In accordance with Section 1(f) of the Specification, registrars must verify the email address OR the telephone (V2 - operational validation). Please see responses below for further details concerning verification requirements and enforcement.
13. Are registries and/or registrars permitted to perform or impose a higher level of validation?
Yes, provided that the validation is performed in compliance with applicable laws, regulations, and ICANN agreements and policies.
14. Are registrars required to provide the validation level along with the data element in their responses to ICANN Compliance or third party requestors, either as part of the response or in their documentation?
Please see responses to questions 11 and 12 above. The RAA does not require registrars to provide the “validation level” along with the data element in their responses to ICANN Compliance or third-party requestors.
Verification
15. “Whois-related complaints that are processed by ICANN as a "data format" issues (as opposed to "data accuracy" issues) do not invoke an obligation for the registrar to validate or verify Whois information. Examples of "data format" issues include a missing country code for a telephone number (as long as the number otherwise contains the proper number of digits for that country) or an email address that is written with "(at)" instead of "@." In such cases, the registrar is required to correct the data formatting issue but is not required to contact the Registered Name Holder to verify the formatting correction” (see Advisory: Clarifications to the 2013 Registrar Accreditation Agreement (RAA) Whois Accuracy Specification)and “For those that remain open, Contractual Compliance initiates an investigation into the registrar's compliance with the contractual requirements explained above, including the obligation to take reasonable steps to investigate the claimed inaccuracy. The "reasonability" of the steps will depend on the type of inaccuracy reported. For example, a report of a nonfunctional email address may only require the registrar to perform email verification to ensure the email is functioning” (seehttps://www.icann.org/resources/pages/registration-data-accuracy-obligations-gdpr-2021-06-14-en))
a. What criteria does ICANN Compliance use to evaluate compliance with verification requirements in addition to those already spelled out above?
Registrars are required to provide ICANN Contractual Compliance with evidence that the verification required by the Registrar Accreditation Agreement (RAA)'s Whois Accuracy Program Specification occurred and the registrar received an affirmative response from the Registered Name Holder (RNH), and Account Holder (AH), if different. Registrars may designate the method used (email or telephone) and manner in which the verification is performed.
...
ICANN Contractual Compliance notes that the obligation to take reasonable steps to investigate a claimed inaccuracy is not limited to compliance with verification (and validation) requirements and reasserts that taking “reasonable steps to investigate” may require additional actions by the registrar depending on the type of inaccuracy reported.
16. When Contractual Compliance is given access to contact information that is normally redacted, is there an indication of which field(s) have been verified by the Registrar?
ICANN Contractual Compliance is not familiar with registrars providing contact information in a manner that indicates verification by field.
17. The RAA calls for the e-mail address and phone number(s) to be verified within 15 days of (1) the registration of a Registered Name sponsored by Registrar, (2) the transfer of the sponsorship of a Registered Name to Registrar, or (3) any change in the Registered Name Holder with respect to any Registered Name sponsored by Registrar, Registrar will, with respect to both Whois information and the corresponding customer account holder contact information related to such Registered Name. In case 2), if only one of the two verifiable fields has been changed, it is not clear if the Registrar must verify the new one (if the other has previously been verified).
a. What is Contractual Compliance’s interpretation of the Registrar requirement? To be specific, if the phone number has previously been verified, and the registrant changes the e-mail address, must it be verified?
This question appears to be related to Section 1 of the Whois Accuracy Program Specification of the Registrar Accreditation Agreement (RAA). For clarity, please note that pursuant to Section 1(f), registrars must verify the email address OR the telephone, but are not required to verify both.
...
Further, if the registrant has additional domain names already registered with the gaining registrar and the registrar previously performed verification of the email or the telephone, “re-verification” may not be required.
18. “Within 15 days of the registration or inbound transfer of a domain name, or a change to the registrant information, a registrar must (…) and 2) verify the email address or the telephone number of the registrant and the account holder (if different) by sending a communication and requiring an affirmative response in a manner designated by the registrar (“verification”). If the registrar does not receive an affirmative response from the registrant, it must verify the information manually or suspend the registration until it can verify it.” (see https://www.icann.org/resources/pages/registration-data-accuracy-obligations-gdpr-2021-06-14-en).
a. What process is acceptable to ICANN compliance to verify an email address manually.
b. Is this method tracked and if so, how many registrations are verified manually?
Manual verification is not defined by the Registrar Accreditation Agreement or the Whois Accuracy Program Specification and the methods used for manual verification may vary by registrar.
...
For registrations that are the subject of a compliance complaint, ICANN Contractual Compliance does not track information related to the number of cases where the registrar has confirmed that the registration was verified manually. Note that manual verification is rarely reported to ICANN Contractual Compliance.
Temporary Specification
19. Under the Temporary Specification, if a request is made to disclose all contact information, and the registrar/registry choses to accept the disclosure request, is Contractual Compliance of the view that all of the requested contact information MUST be disclosed, or may the registrar/registry release just some of the requested information (ie it may disclose the email address but not the phone number)?
Registrars are required to “provide reasonable access to Personal Data in Registration Data to third parties on the basis of a legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.” (emphasis added). ICANN Contractual Compliance recognizes that there are situations where the provision of “reasonable access” may result in the disclosure of only certain Registration Data elements, the disclosure of all Registration Data elements, or denial of access if the interests of the requestor are overridden by the interests of fundamental rights and freedoms of the data subject.
...
Privacy / Proxy Registrations
20. Neither the Temporary Specification nor the Interim Registration Data Policy modified the RAA requirements for registrars to validate and verify registrant contact information and to investigate claims of inaccuracy.
a. Does ICANN compliance require the underlying contact information of a Proxy/Privacy registration to be validated and verified?
b. If so, are inaccuracy reports treated differently?Is data collected and tracked?
Requirements under the Whois Accuracy Program Specification apply to the validation of fields under Section 3.3.1 of the Registrar Accreditation Agreement and verification of the Registered Name Holder (RNH) and Account Holder (AH), if different. Specifically, Section 1 indicates that the requirements apply to “both Whois information and the corresponding customer account holder contact information.” Validation and verification requirements apply to all gTLD domain name registrations, regardless of whether they are registered using a Privacy or a Proxy (P/P) Service Provider.
...
Current interpretation of existing accuracy requirements
21. As part of the accuracy scoping team’s effort to undertake a fact based survey of the current state of accuracy in the ICANN context, registrars proposed the following working definition of accuracy based on current contractual and consensus policy requirements (https://mm.icann.org/pipermail/gnso-accuracy-st/2021-October/000086.html):
Accuracy shall be strictly defined 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 proposing this working definition registrars are not suggesting that this is what the definition of accuracy should be, but rather capturing what it currently is to inform the work of the scoping team.
...
Registrant vs. Registered Name Holder
22. Is ICANN Compliance or ICANN Legal aware of any instances where any Contracting Party has argued that the terms “registrant” and the “Registered Name Holder” are not equivalent. If so, can ICANN Org summarize this divergent position taken by the contracting party and ICANN Org’s response and how any dispute was resolved.
ICANN Contractual Compliance is aware of at least one instance of a contracted party asserting the position that the terms “Registrant” and “Registered Name Holder” are not equivalent. While the details of compliance cases are confidential, ICANN does not distinguish between the two and considers the terms interchangeable. As an example, the Transfer Policy uses the terms “Prior Registrant”, “New Registrant” and “Registered Name Holder” without distinction. A “Change of Registrant” is a material change of the “Registered Name Holder’s name or organization”, including the contact information.
...
Reasonable and commercially practicable / technically and commercially feasible
23. There are multiple terms in the 2013 RAA referencing “reasonable and commercially practicable”; “commercially reasonable efforts”; and “commercially practical updates”.With regard to this language we have several questions:
a. What standard does ICANN Compliance currently use in determining commercially “practicable” and “reasonable”?
In determining compliance with obligations that require a registrar’s “commercially practicable” and/or “reasonable” efforts or actions, ICANN Contractual Compliance (Compliance) applies the standard of commonly accepted industry practice.
...
In all instances, Compliance will require the registrar to detail the steps taken and will consider whether those steps were reasonable considering the specificities of the complaint at hand and the applicable contractual requirements.
b. Has ICANN Legal provided guidance to ICANN Compliance on how to determine commercially “practicable” and “reasonable”
Legal advice is privileged and confidential.
c. Has this expectation been conveyed to the CPs?
During a compliance investigation, all information/evidence required from the contracted party to demonstrate compliance under the applicable contractual requirements (including those that refer to “reasonable” steps) is conveyed to the relevant contracted party. In addition, ICANN Contractual Compliance addresses any questions the contracted party may have - related to expectations or otherwise - during the processing of each complaint. Further, ICANN Contractual Compliance participates in outreach activities to explain contractual requirements and the contractual compliance process, and produces webinars concerning compliance across different areas.
d. When was the current standard for “practicable” and “reasonable” adopted and what are the mechanisms for modifying this standard?
Each compliance matter is reviewed on a case-by-case basis. This has not changed with time. Rather, the timing of each review and application of the standard explained above will depend on the specific requirement being enforced. For example, application with respect to the “reasonability” pertaining to abuse-related obligations under Section 3.18 of the Registrar Accreditation Agreement (RAA) did not commence until the 2013 RAA became effective, as these obligations were not included in prior RAA versions.
e. If a standard does not exist, does ICANN Org anticipate creating one and when?
See response to 23 (a) and 23 (d) above.
24. Section 1-e of the RAA WHOIS ACCURACY PROGRAM SPECIFICATION states “Validate that all postal address fields are consistent across fields (for example: street exists in city, city exists in state/province, city matches postal code) where such information is technically and commercially feasible for the applicable country or territory.
a. To what extent does ICANN understand that this is being done (that is, it is deemed by registrars to be technically and commercially feasible)?
ICANN has not studied the extent to which individual registrars are currently taking steps contemplated in Section 1e of the WHOIS Accuracy Program Specification. This provision is not yet in force-see the RAA Transition Addendum at Section 6: “ICANN and the Registrar Whois Validation Working Group (as defined below) will work together to identify and specify an appropriate set of tools to enable Registrar to complete the across field validation specified in Section 1(e) of the Whois Accuracy Program Specification to the Agreement (the "Across Field Validation"). When such tools are mutually agreed between ICANN and the Registrar Whois Validation Working Group, ICANN shall provide the Registrar written notice of such agreement (which notice shall specify and describe the agreed upon tools). Effective on the one hundred eightieth (180th) calendar day following delivery of such notice by ICANN, Registrar shall comply with the obligations specified in Section 1(e) of the Whois Accuracy Program. Until such time, ICANN will not enforce compliance with such obligations.
...
ICANN is currently in the process of updating the community on status of Across-Field Address Validation (AFAV) implementation efforts. Information and updates to the community will be provided in the near future.
b.If it is not done, how is this contract clause enforced or what other processes are in place to ensure compliance?
See response to (a) above. This provision is not yet in force.
...
Accuracy Reporting System (ARS)
25. When the ARS was suspended because under the Temporary Specification the ARS could no longer effectively be carried out exactly as it had before, did the ICANN make any effort to see if the ARS could continue with a modified procedure (such as requesting the contact information from registrars)?
ICANN org made the decision to pause further ARS reports following the GDPR being implemented and subsequent adoption of the Temporary Specification. Additionally, inquiries made by registrars as to whether it is permissible to provide certain registration data to ICANN in response to a WHOIS inaccuracy ticket issued by ICANN Contractual Compliance as a result of the ARS caused ICANN org to reconsider continuing with the ARS.
...
