Link (content reproduced below): 

Also (content not reproduced below)

=============

Dear ICANN org colleagues,

 

Please find below the follow up questions that the Registration Data Accuracy Scoping Team has following its review of the following materials, amongst others:

 

 

As the team continues its deliberations, further questions may arise, but we hope that with the list below we have identified the most pertinent ones.

 

Best regards,

 

Michael Palage

Chair, Registration Data Accuracy Scoping Team

 

-------------------------------

 

Compliance staff training

 

  1. How are ICANN staff members trained on assessing accuracy complaints? Are there guidelines for review? How is the quality of review assessed?


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.

 

From December 2020 through November 2021, ICANN received the following complaints related to Registration Data Inaccuracy:

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.

 

Further, details regarding compliance complaints processed through ICANN Contractual Compliance’s informal resolution process are considered confidential.

 

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?


ICANN Contractual Compliance ensures that registrars fulfill the requirements in their agreements with ICANN org. As there is no requirement for registrars to maintain records concerning the number of days a registrant takes to correct reported inaccuracies (where applicable), or provide such records to ICANN, ICANN Contractual Compliance does not collect or monitor this metric.

 

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.

V1 = Syntactic validation

V2 = Operational validation

V3 = Identity validation


In accordance with the Whois Accuracy Program Specification (Specification), Sections 1(a) through 1(d), registrars are required to perform syntactic validation (V1) as follows:

 

  • Values are present for all fields required under the RAA for the applicable country or territory
  • Registrant/Admin/Tech/Other Email are in the proper format with RFC 5322s
  • Registrant/Admin/Tech/Other Phone and Fax are in the proper format according to the ITU-T E.164 notation for international telephone numbers
  • Registrant/Admin/Tech/Other Street, City, State/Province, Postal Code, and Country are in the proper format for the applicable country or territory as defined in UPU Postal addressing format templates, the S42 address templates (as they may be updated) or other standard formats

 

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.

 

For new registrations transferred in, validation and verification must be performed unless the registrar has already successfully completed the procedures required by Section 1 on the identical contact information (emphasis added), i.e., any change to the contact information will require re-verification.

 

Additionally, ICANN Contractual Compliance notes that Paragraph 4 of the “Advisory: Clarifications to the 2013 Registrar Accreditation Agreement (RAA) Whois Accuracy Specification” states the following:

 

In cases where a registration is transferred to a gaining registrar, and in the course of the transfer, the gaining registrar obtains consent to the transfer via the Form of Authorization from the Registered Name Holder or Account Holder via means that would fulfill the verification requirements of section 1(f)(i) of the Specification, the gaining registrar does not need to repeat the verification process on the contact data if there are no material changes to that contact data.

 

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.

 

Although the requirements focus on Registration Data displayed in the Registration Data Directory Service (RDDS), accuracy requirements concerning underlying customer information for P/P registrations may apply under the Specification in limited circumstances, depending on how the services are set up. For example, if the underlying customer is also the Account Holder, or where the service provides an anonymized email that forwards to the underlying customer email (such that an inaccurate underlying email would result in a bounce-back from the email in the public Registration Data).

 

ICANN Contractual Compliance (Compliance) also notes that Section 3.7.8 of the Registrar Accreditation Agreement (RAA) requires that upon notification by any person of an inaccuracy in the contact information associated with a Registered Name, registrars must take reasonable steps to investigate that claimed inaccuracy.

 

Concerning the collection/tracking of data, Compliance understands this question to inquire whether it tracks whether a complaint is regarding Registration Data of a P/P Service Provider or the underlying customer contact information. Noting that contractual obligations with respect to accuracy of Registration Data for domain name registrations utilizing a P/P Service Provider do not differ, ICANN does not track or collect separate metrics. 

 

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.

 

The Council instructions to the scoping team (https://community.icann.org/display/AST/2.+Council+Instructions+to+Scoping+Team) include the following charge:

 

  1. Enforcement and reporting: The Scoping Team will assess the measures, including proactive measures, used by ICANN Compliance to monitor, measure, enforce and report on the accuracy obligations as specified in the Registry Agreements (RAs) and Registrar Accreditation Agreement (RAA). This assessment will include consideration of what compliance with the existing contractual data accuracy obligations means. The Scoping Team shall, with reference to the resources that will be included in the index of relevant resources cited below, consider whether there is an agreed definition of registration data accuracy and, if not, consider what working definitions should be used in the context of the Scoping Team's deliberations. Particular attention should be given to the definition that ICANN Compliance employs for “accuracy” in ICANN’s contracts. Note, this does not preclude any subsequent effort from formalising the definition(s) that should be applied in the context of any existing and/or new accuracy requirements that may be developed.

 

Does ICANN Compliance agree with the working definition proposed by registrars? What definition does ICANN compliance employ for “accuracy” in ICANN’s contracts? Given the above instructions from council, the scoping team is attempting to understand ICANN compliance’s definition of accuracy, and what compliance with existing contractual data accuracy obligations means to better inform our work.

 

ICANN Contractual Compliance (Compliance) does not employ its own definition of accuracy, but relies on requirements within the Registrar Accreditation Agreement (RAA) to determine registrar requirements as it pertains to the accuracy of Registration Data.

 

In addition to validation and verification requirements within Section 1 of the Whois Accuracy Program Specification (Specification), “upon notification by any person of an inaccuracy in the contact information associated with a Registered Name sponsored by Registrar, [Registrar must] take reasonable steps to investigate that claimed inaccuracy. In the event the Registrar learns of inaccurate contact information associated with a Registered Name it sponsors, it shall take reasonable steps to correct that inaccuracy.” (Section 3.7.8 of the Registration Accreditation Agreement (RAA)).

 

Further, Section 4 of the Specification requires additional verification procedures if the registrar has any information suggesting that the contact information in Section 1(a) through 1(f) is incorrect. Section 5 of the Specification requires that registrars take additional action to terminate, suspend or place a registration on hold upon the occurrence of a Registered Name Holder’s willful provision of inaccurate or unreliable WHOIS information.

 

Based on the above, Compliance notes that accuracy requirements are not limited to the “syntactical accuracy” of the Registration Data elements and the operational accuracy of the email or telephone number. Particularly, in instances where the registrar is in possession of any information that suggests that the contact information is inaccurate, or the RNH willfully provided inaccurate or unreliable contact information. For example, the RNH provided Registration Data that passes format validation, but is patently inaccurate (such as Registrant Name: Mickey Mouse; Registrant Postal Address: 1234 Main Street, Disneyland, CA 00000, USA; Registrant Email: mickeymouse@example.com) 

 

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.

 

With that in mind, the determination is made on a case-by-case basis, considering factors such as complaint details and substantiation, as well as all evidence and explanation provided by the contracted party while addressing Compliance’s questions during the compliance investigation.

Examples:

  • [Section 3.7.8 of the Registrar Accreditation Agreement (RAA)] The obligation to take reasonable steps to investigate a claimed inaccuracy may require actions that will depend on the type of inaccuracy reported. For example, a reported nonfunctional email address may only require the registrar to perform email verification while a registrar addressing an alleged inaccurate postal address might also request proof of address from the registrant (e.g., copies of utility bills).
  • [Section 3.12 of the RAA] The obligation to use commercially reasonable efforts to enforce compliance with the provisions of the registrar-reseller agreement that relate to the provisions of Registrar Services may require actions that will depend on the type of noncompliance that results from a reseller’s actions or inactions. For example, to ensure its resellers display mandatory information on their websites, a registrar may implement monitoring processes whereby the registrar periodically looks at its resellers' websites. Meanwhile, to ensure compliance with obligations related, for instance, to the renewal or transfer of domain names, a registrar may include such obligations in its registrar-reseller agreement and attach consequences for contract non-compliance.

 

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.

 

There have been discussions/conversations within the org regarding other options, such as using escrow data or Bulk Registration Data Access (BRDA), but these have not been thoroughly investigated as viable alternatives. Substantial study would be needed to ensure consistency with all requirements in ICANN policies and agreements, and applicable laws and regulations.

 

ICANN org has made the Board aware that the ARS is on hold via its twice-annual CEO reports to the Board. ICANN org first noted in its January 2019 report that “[t]he cycle 7 report of the ARS has been paused as we consider updates to the process based upon GDPR and changes to available public registration data as a result of Registry and Registrar implementation of the Temporary Specification.” And further in April 2019:

 

“The ARS remains paused as ICANN org assesses the effects of General Data Protection Regulation (GDPR). Based on the lack of predictable publicly available registration data and given the community work from the GNSO’s Expedited Policy Development Process (EPDP) on Temporary Specification for gTLD Registration Data, ICANN org believes it may be prudent to continue to pause and consider the impact of the EPDP efforts and assess our ability to effectively administer ARS.”


--

Follow-up Questions

1.How is the Compliance team trained on GDPR specifically?

ICANN Contractual Compliance enforces the Registrar Accreditation Agreement, Registry Agreements and Consensus Policies, and its staff are extensively trained on these agreements and policies. ICANN Contractual Compliance does not enforce laws or regulations which are outside the contractual scope of the ICANN organization. Accordingly, the ICANN Contractual Compliance team does not undergo GDPR specific training (or that of any other law or regulation), but subject-matter experts do maintain a general awareness of GDPR issues relevant to their areas of compliance expertise. Each contracted party must ensure its own processing complies with GDPR, where applicable, as well as any other applicable laws and regulations

2. Are the metrics from Compliance based on complaints received? (Answer: yes.) Would be interested to know – prior to the GDPR, how did ICANN perform these checks?

As noted in real-time during the discussion, metrics from Compliance are based on complaints received. Prior to the transition to the Naming Services portal (NSp) on 29 August 2020, ICANN did not track complaints received by reporter type, as the level of granularity in reporting was limited within the legacy system. ICANN Contractual Compliance’s monthly dashboard contains historical data about complaints received/closed that are related to accuracy which is available here. Additional information specifically addressing complaints received before and after GDPR went into effect is available here.

3. What is the status of the DPA negotiation between ICANN org and contracted parties?

Following the Board’s adoption of the EPDP Phase 1 Recommendations, ICANN org and a group of registry and registrar representatives designated by the CPH have been working on a document to implement EPDP Phase 1 Recommendations 19 and 20. At present, we are aiming to produce a draft Data Processing Specification to the Registry Agreement and Registrar Accreditation Agreement, which, once finalized, a contracted party could elect to enter into for purposes of data protection compliance. We have made significant progress toward a draft that will, once tentatively agreed, be shared with the Implementation Review Team (IRT) for feedback. In late 2021, ICANN org and the CPH group held extended discussions regarding remaining open issues with the aim to bring this effort to completion in the near term. We expect that this will be ready to share with the IRT prior to the draft Registration Data Policy document (the product of the EPDP Phase 1 IRT’s work) being published for public comment.

4. Is the ability for ICANN to share any of the training materials possible? (For example, it has been difficult for the group with respect to wordsmithing. If there are documents regarding clarity on these issues, it would be very helpful.)

ICANN Contractual Compliance utilizes written training materials, as well as regular in-person and phone/video training sessions conducted by senior staff. These training materials contain information about our systems, internal procedures and processes and are, therefore, confidential. Such materials, however, do not seek to define or interpret contractual requirements, and use the defined terms and requirements within the Registrar Accreditation Agreement, Registry Agreements, and Consensus Policies.

5. With respect to Q3, it discusses issues that are out of scope. How would a third complainant ever file a complaint regarding the accuracy of registrant data behind a P/P service? When is a compliant in scope and when is it out of scope?

ICANN refers the team to the prior response to question #20. In-scope complaints pertaining to customer data of a P/P Service Provider are limited. For example, if the underlying customer is also the Account Holder, or where the service provides an anonymized email that forwards to the underlying customer email (such that an inaccurate underlying email would result in a bounce-back from the email in the public Registration Data).

ICANN additionally notes that the majority of P/P services are “Proxy Services”, which are “service[s] through which a Registered Name Holder licenses use of a Registered Name to the P/P Customer in order to provide the P/P Customer use of the domain name, and the Registered Name Holder's [RNH] contact information is displayed in the Registration Data Service (Whois) or equivalent services rather than the P/P Customer's contact information.” (See Section 1.3 of the Specification of Privacy and Proxy Registrations). In such cases, the “registrant data” is the data of the Proxy Service/RNH.

6. With respect to the engagement you are doing on the NIS2…exactly what kind of purpose are you lobbying for? How does it fit with ICANN’s controller role?  Who else do you think should be able to avail themselves of that “legitimate purpose” role to check accuracy?  Do you envisage outsourcing and how would that work?  Who are you engaging with, the EC or the DPAs?

As regards the ongoing negotiations on NIS2, ICANN org is engaging with the co-legislators, i.e. the European Parliament and the Council of the EU. The purpose of the engagement is to explain how the DNS works, highlight what the community is working on, and identify the challenges the community is facing with respect to the application of GDPR to registration data in the context of the ICANN policy making. This engagement is with the aim to ensure that deliberations and decisions relating to the DNS in NIS2 are made with a full understanding of the current situation and possible impact of the proposed legislation.

With respect to registration data accuracy, ICANN org provided information about the requirements to perform due diligence checks as developed by the ICANN community and applied through contractual  structures with the contracted parties, as well as information about how ICANN compliance enforces these requirements, including how GDPR has affected ICANN compliance’s ability to enforce accuracy requirements.

Regarding the question, “How does it fit within ICANN’s controller role[?] (emphasis added)”, the intended meaning of “it” is unclear. However, as regards the “purpose,” if a purpose for registration data processing and recognition of a legitimate interest in processing that data (where the GDPR applies), were codified in a European directive and in turn in implementing member state laws, this could provide helpful clarity for any controller of the processing of personal data within registration data. The question (“Do you envisage outsourcing and how would that work?”) is also unclear (what would ICANN be potentially outsourcing?) and, thus, an answer on this aspect of the question cannot be provided.

7. On the answer to Q21, the second to last line includes the term “patently inaccurate”. How is "patently inaccurate" determined? For example, the name Mickey is an actual name. There are times where data may look fishy but it is, in fact, correct. How does ICANN org make this determination?

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.



  • No labels