You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Link: For Scoping Team Final Org Responses to Data Accuracy Scoping Team Questions .pdf

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

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?
  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?
  3. What is the status of the DPA negotiation between ICANN org and contracted parties?
  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.)
  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?
  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?
  7. On the answer to Q21, the second to last line where the term “patently inaccurate” is used, how is this determined? For example, the name Mickey is an actual name. There are times where data may look fishy but is, in fact, correct. How does ICANN org make this determination?
  • No labels