ACDEFGHIJKLMNOPQRSTUVWXYZAAABACADAEAFAGAHAIAJAKALAMANAOAPAQARASATAUAVAWAXAYAZBABBBCBDBEBFBGBHBIBJBK
1
Timestamp
Please provide your name:
Please provide your affiliation
Are you providing input on behalf of another group (e.g., organization, company, government)?
If yes, please explain:
Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
Please choose your level of support for Recommendation #1:
If your response requires an edit or deletion of Recommendation #1, please indicate the revised wording and rationale here.
Choose your level of support of Recommendation #2:
If your response requires an edit or deletion of Recommendation #2, please indicate the revised wording and rationale here.
Choose your level of support of Recommendation #3:
If your response requires an edit or deletion of Recommendation #3, please indicate the revised wording here.
Choose your level of support of Recommendation #4:
If your response requires an edit or deletion of Recommendation #4, please indicate the revised wording and rationale here.
Choose your level of support of Recommendation #5:
If your response requires an edit or deletion of Recommendation #5, please indicate the revised wording and rationale here.
Choose your level of support of Recommendation #6:
If your response requires an edit or deletion of Recommendation #6, please indicate the revised wording and rationale here.
Choose your level of support of Recommendation #7:
If your response requires an edit or deletion of Recommendation #7, please indicate the revised wording and rationale here.
Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
Choose your level of support of Recommendation #8:
Do you recommend a change to the wording of Recommendation 8? If so, please indicate proposed edits and rationale here.
Choose your level of support of Recommendation #9:
Do you recommend a change to Recommendation 9? If so, please indicate proposed edits and rationale here.
If you do not agree with the proposed SLA matrix and/or accompanying description, please provide your rationale and proposed alternative language.
Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
Choose your level of support of Recommendation #10:
If your response requires an edit or deletion of Recommendation #10, please indicate the revised wording and rationale here.
Choose your level of support of Recommendation #11:
If your response requires an edit or deletion of Recommendation #11, please indicate the revised wording and rationale here.
Choose your level of support of Recommendation #12:
If your response requires an edit or deletion of Recommendation #12, please indicate the revised wording and rationale here.
Choose your level of support of Recommendation #13:
If you believe edits are needed for Recommendation #13, please propose edits and rationale here.
Choose your level of support of Recommendation #14:
If you do not support Recommendation #14, please provide proposed edits and rationale here.
Choose your level of support of Recommendation #15:
If you believe edits are needed for Recommendation #15, please propose edits and rationale here.
Choose your level of support of Recommendation #16:
If you believe changes are needed for Recommendation #16, please provide proposed edits and rationale here.
Do you want to save your progress and quit for now? You will be able to return to the form to complete at a later time.
Choose your level of support of Recommendation #17:
Choose your level of support of Recommendation #18:
If you do not support Recommendation #18, please provide proposed edits/changes and rationale here.
Choose your level of support of Recommendation #19:
If you do not support Recommendation #19, please provide proposed edits or changes and rationale here.
What existing processes / procedures, if any, can be used to meet the above responsibilities?
If no suitable existing processes / procedures can be used, what type of mechanism should be created factoring in: Who should guidance be provided to? How is guidance developed / agreed to? How should it be structured?
What information is needed to ensure the continuous evolution of SSAD?
How is guidance of the Mechanism expected to be implemented?
Choose your level of support of Implementation Guidance #i:
If you do not support Implementation Guidance #i, please provide proposed edits or changes and rationale here.
What type of reporting should be required as part of SSAD?
Are there any recommendations the EPDP Team has not considered? If yes, please provide details below.
Are there any other comments or issues you would like to raise pertaining to the Initial Report? If yes, please enter your comments here. If applicable, please specify the section or page number in the Initial Report to which your comments refer.
2
2/9/2020 12:36:17qutebaQuteba@gmai.chatNonoYes
3
2/18/2020 12:42:04Dr. Milton Mueller
Professor, Georgia Institute of Technology
Yes
Internet Governance Project, Georgia Institute of Technology
No, I would like to continue to the next section
Support Purpose as written
Significant change required: changing intent and wording
The words "public policy task" should be replaced with "law enforcement tasks." Public policy is a far too broad basis for giving governmental authorities access to registration data. Governmental actions in this area acquire their legitimacy from law. Although not all laws are proper and legitimate, there is at least a level of transparency and due process that is normally followed in their passage, and they are subject to judicial review. A government can claim that virtually anything it wants to do is a "public policy task." The claims of governments for special accreditation status cannot be based on "public policy" claims.

The term "Consumer rights organizations" should be replaced by "Governmental consumer protection agencies." Many nongovernmental organizations claim to support "consumer rights." The current wording opens the door to too many entities.

Replace the wording "Cybersecurity authorities, including national Computer Emergency Response Teams (CERTs)," with "Legally constituted cybersecurity authorities, such as national Computer Emergency Response Teams (CERTS)". Once again, we think it is essential to limit this form of accreditation to governmental agencies.
Support Recommendation as written
Support Recommendation intent with wording change
The title of this Recommendation should be "Third Party Justifications." The sentence "Third parties MAY submit data disclosure requests for specific purposes such as..." should be changed to "Third parties MAY submit data disclosure requests with justifications such as..."
The wording change makes it more accurate and avoids confusion with the vexed debate over Whois purposes that held up consensus in earlier reports.
Support Recommendation as written
Support Recommendation intent with wording change
On the whole this recommendation is good. We propose a minor wording change at the end of the 4th paragraph. Delete the words, "nor can refusal to disclose be solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name." This is too specific for a policy recommendation and seems to be nothing more than special pleading by a particular interest group intended to bias consideration of certain kinds of claims. We know of no cases where disclosure requests to law enforcement or private actors have been denied based solely on a foundation of "alleged IP infringement in content on a website." Including this language may just encourage IP interests to contest justified disclosure denials. No legitimate rights are undermined or threatened by deleting this language.
Recommendation should be deleted
Most of this Recommendation (Parts 1, 2 and 3) merely repeats what other parts of the initial report say, notably Recommendation 6. The parts that are not repetitive are poorly thought out or objectionable.
The part of the recommendation that says "a Contracted Party MAY request the Central Gateway to fully automate all, or certain types of, disclosure requests" is not consistent with the requirement that automated disclosure must be legally permissible. A contracted party could request automation when it is not legally permissible, and this recommendation does not provide any checks on that. It encourages contracted parties to save time and money by sacrificing the data protection rights of their customers.
The part that suggests that law enforcement agencies should be able to automate ALL requests is neither justified nor legally permissible. It is routinely true that LEAs must get warrants or subpoenas to disclose private information; the mere fact that they are LEAs does not relieve them of basic privacy protections.
Automated disclosures raise important legal questions, which this Recommendation does not resolve. Automation of disclosure poses a real danger that all of the legal rights for data subjects could be bypassed by a system that essentially recreates the open-access Whois for any accredited user.
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
Clarification is needed regarding this statement: "Support the ability of a requestor to submit multiple domain names in a single request." We think this bullet point should be deleted.
Recommendation #3 specifies all the elements that go into a request. In a request with multiple domain names will all these things be the same? We fail to see how a request that combines multiple domains can conform to Rec 3, unless it is the same registrant and the same justification. We fail to see how the authorization process described in Recommendation #6 can be conducted if dozens of different domains with different registrants and justifications are combined in the same request.
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
On the whole, this Recommendation is acceptable, although a lot depends on the implementation details. We recommend one minor change:
It currently says, "Accreditation applicants MAY be charged a to-be-determined non-refundable fee proportional to the cost of validating an application." We believe that "MAY" should be changed to MUST here. We are concerned that entities that offer accreditation for free will not be trustworthy.
Intent and wording of this recommendation requires amendment
We agree with all the language regarding automation of requests. We do not approve of the language regarding automation of disclosure. Specifically we disagree with this paragraph:

"The SSAD MUST allow for automation of the processing of well-formed, valid, complete, properly-identified requests from accredited users with some limited and
specific set of legal basis and data processing purposes which are currently described in Preliminary Recommendation #7 but still under discussion. These requests MAY be automatically processed and result in the disclosure of non-public RDS data without
human intervention."

We note that this recommendation does not mention "legally permissible" as is required by other parts of the report. This oversight must be fixed.

We note that where there is no human intervention, it is impossible to know whether the legal bases or data processing purposes are valid for a specific request. We note the clear risk that parties requesting data could lie and assert rationales that would lead to automated disclosure even if they were not applicable.
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Delete recommendation
We view a threat that the mechanism for "evolution" of SSAD could become a Trojan Horse whereby hard-fought consensus policy decisions can be undermined or negated by small groups acting outside of public view. We do see a need for updating administration of the SSAD but believe that any such changes must stay within the bounds of policy set by the EPDP.
A subcommittee of the GNSO Council can engage in long-term oversight of the SSAD's administration.
We oppose strongly any attempt to make expanding automation part of the mandate of the SSAD. We see no need to expand the categories of disclosure requests that an be automated.
We see evolution of categories of requests as an administrative detail that could be handled by the gateway operator (ICANN or ICANN-contractor) unilaterally as long as changes did not impact policy. We note that the operator of the TMCH
We see the SLA Matrix as a matter of compliance to be negotiated by ICANN and the Contracted Parties.
An existing process (GNSO council subcommittee) can be used
We object to the term "continuous evolution." We believe there should be a stable, firm and largely unchanging set of policies governing the SSAD which can be changed via PDPs. We recognize a need for updating and revising implementation details in ways that do not change policy or "evolve" it into something new.
The administrator can propose operational improvements; the GNSO Council subcommittee can review them to see if they implicate policy or alter policy or might have bad effects. Council approval should be required to go forward. In some cases public comment might be useful and required.
Delete implementation guidance
As noted in an earlier comment, we think the bundling of multiple domain names into the same request undermines the policy requirement in Recommendation 8 regarding the weighing and evaluation of requests, unless the system can automatically dis aggregate the requests and send them on to the CPs in an individualized form. We think it amounts to a de facto form of automated disclosure and skirts legal review processes.
1. Aggregate data about the volume of requests, request categories, and disclosure decision rate should be published quarterly by ICANN.
2. Data about requests should be broken down by domain name, by the requestors' corporate identity (e.g., Facebook, Inc., California Attorney General, etc.) and by category (e.g., trademark, copyright, cybersecurity, etc). Also on a quarterly basis
3. Data about disclosure rates should be broken down by the contracted party's corporate identity (e.g., Network Solutions, Gandi, etc.). Also on a quarterly basis
4. Data about registrant objections to disclosure and any complaints to Data Protection Authorities should be published on a quarterly basis
The comments were only permitted to address specific recommendations. Some of the text prior to the recommendations, e.g. pages 5 - 13. reflects assumptions that were challenged in our comments on the recommendations. We assume that if changes are made in response to our comments on the recommendations, that these changes will also be reflected in the preceding text of the report.

We'd also like to commend the support staff for their hard work in bringing this together
4
2/21/2020 8:15:32IP DepartmentVKGP SA dba VanksenNo
No, I would like to continue to the next section
Support Purpose intent with wording change
Fees:
The accreditation service will be a service that is financially sustainable and not dissuasive to any category of requestor.
No opinion
Support Recommendation as written
Support Recommendation as written
Significant change required: changing intent and wording
The response time should be no longer than 5 business day.
No opinion
Recommendation should be deleted
There is no justification in allowing requests to be submitted in an automatic way. Such a possibility would be an open door to system abuses.
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
Automated submissions should not be made possible.
Support recommendation as written
Support recommendation as written
No opinion
Delete recommendation
No, I wish to continue to the next section
Support recommendation as written
No opinion
Support recommendation as written
Support implementation guidance as written
5
3/23/2020 15:30:24Franck Journoud
Motion Picture Association
No
No, I would like to continue to the next section
Support Recommendation intent with wording change
MPA recommends adding to the Accreditation Recommendation, and to the SSAD, the concept of Trusted Notifiers. Trusted Notifiers would be entities or individuals with recognized subject matter expertise who would undergo additional scrutiny, either at the time they are initially accredited and/or in an ongoing manner, to recognize or establish their accuracy and their track record of good faith and compliant use of the SSAD in support of their work monitoring, investigating and acting against specific use cases of illegal activity and domain abuse.
Support Recommendation as written
Significant change required: changing intent and wording
The use of “standardization” as the objective of this Recommendation is unclear. Since requests are to be submitted to a single central computerized gateway, their criteria and content won’t be merely standardized but “uniform.” If however “standardization” refers to the goal of ensuring that each category of requests – e.g. copyright infringement requests, cybersecurity requests, etc. – is standardized so that requests can be more speedily processed, we wholeheartedly support this objective.

With that objective in mind, we ask that this Recommendation state that the gateway’s submission process must be as user-friendly, clear and self-explanatory as possible. To this end, MPA also asks that this Recommendation explicitly provide that the gateway shall offer to requestors features that maximize the efficiency of the request process (e.g. default settings and options such as fields regularly used by the requestor and the ability to reuse the same request content, for several requests.

We also ask that the wording of Recommendation 3 be aligned with that of Recommendation 6: in c) replace “specific rationale” and “basis or reason for the request” with “legitimate interest or other lawful basis”; and in e) replace “adequate, relevant and limited to what is necessary” with “necessary.”
Support Recommendation as written
Support Recommendation intent with wording change
The gateway will be an automated, computerized system. Therefore, it should be required to provide a response that indicates the receipt of a valid request in a manner that is “immediate and synchronous” rather than merely “without undue delay”, as one would ask of a human. This would align the wording of the first paragraph with that of Recommendations # 8 (Response Requirements) and 16 (Automation.)
Support Recommendation intent with wording change
Bullet point 1
MPA asks for the following changes:
● Align the wording with that of the automation Recommendation to read "legally permissible and technically feasible."
● “Not explicitly prohibited” is unclear. Is it implicitly prohibited? This policy will in fact affirmatively allow automated review where it is “legally permissible”, so replace it with “allowed.”

Bullet points 2 and 3
No comments.

Bullet points 4 and 5
As a general matter, this Recommendation must be improved to reach the goal of making the SSAD “predictable, transparent and efficient” for requestors (see p.15); and minimize the operating costs and compliance burden of the CPs (by avoiding unnecessary repeated reviews of the same standard and legally valid language in a multitude of requests) to allow them to focus their efforts on atypical or potentially confusing requests. Therefore, we ask that:
a. The Mechanism for the Evolution of SSAD shall develop, and suggest to requestors, model language for each of the elements of a SSAD request. It should be developed on the basis of the use cases created by the EPDP (https://community.icann.org/display/EOTSFGRD/d.+Use+Cases) as well as proposals by CPs, experts, requestors and the gateway (whose logs will show what statements are accepted or rejected, and why). This model language should include in particular:
i. Language about legitimate purposes;
ii. Language about intended uses that correspond to legitimate purposes;
iii. Lists of data elements that are necessary for each legitimate purpose, with corresponding statements explaining their necessity. (we are concerned in particular that CPs will struggle to meet their obligation, under GDPR and this policy, to assess the necessity of processing for a requestor: how would they know what data is operationally and – in foreign countries if not in their own – legally necessary to inquire into, investigate, remedy, litigate or prosecute a wide variety of situations, from copyright infringement to phishing to botnet threats to consumer scams to crime? How would they regularly update this knowledge to keep pace with evolving threats and the techniques and legal environments of those who counter them?)
iv. Language clarifying each of the balancing test factors (e.g. language about combinations of data elements or data sharing that might create a higher risk, so that requestors can commit to avoiding certain combinations of data or certain types of data sharing.)
b. Requestors shall remain free to use their own language in their requests (e.g. request more or fewer data elements and/or provide their own statements of necessity) for the CP’s review.
c. CPs shall be required to accept as satisfying the corresponding requirement of this policy any element of a request that uses the model language.

Bullet point 4
The language of the second to last paragraph of p.26 needs to be edited:
“If the answer to any of the above questions is no, the Contracted Party MAY deny the request, or require further information from the requestor before proceeding to bullet #5 below.”
That’s appropriate if the request lacks a lawful basis, not if the lack of necessity relates to some but not all of the requested data elements. We ask for the following change:
“If the request lacks a lawful basis to process the data, the Contracted Party MAY deny the request, or require further information from the requestor before proceeding to bullet #5 below. If a requested data element is not necessary, the Contracted Party MAY refuse to disclose it, or require further information from the requestor before proceeding to bullet #5 below.”

Bullet point 5
In the first sentence: GDPR only protects personal data and the EPDP should not extend onerous and unnecessary privacy protections like the balancing test of GDPR’s article 61f to non-personal data. As a result, we ask that “may” be changed to “must.”

In the second sentence: not all EPDP members may agree whether the balancing test can only be done by humans, so instead of referring to “meaningful human review” as the purpose of bullet point 5 this sentence should more consensually refer to the “balancing test”. We also note that bullet point 6 does not, in fact, provide for “meaningful human review.” We thus ask for the following change:
“The purpose of bullet point #5 is to determine whether the data requested contains personal information, and if it does to determine how the balancing test should be performed.”

Balancing test factors: the CP should be required to weigh, as an additional factor in its balancing test, the importance of the interests of the requestor, including but not limited to the protection of rights. We ask that the policy explicitly include the following examples of fundamental rights enshrined by the Universal Declaration of Human Rights: right to property and to its protection (UDHR, Article 17) and right to intellectual property and to its protection (UDHR, Article 27.)

Bullet point 6
We ask that any proposed revision of bullet point 5 be subject to prior review by the ICANN community of stakeholders.

Support Recommendation intent with wording change
Bullet point 1
We ask for the deletion of “and is confirmed during the implementation phase”. The policy should be the policy. The implementation phase isn’t an opportunity to rewrite it: that requires a new Policy Development Process.

Implementation Guidance
Limiting the use of automated disclosure, when the SSAD ‘goes live’, to just two use cases is not sound policy because it violates the SSAD’s objectives of predictability and efficiency (p.15.) It is also unnecessary under GDPR: as the Belgian DPA reminded ICANN Org during their February 14, 2020 meeting, “It is not how the disclosure decision is made that matters, but to be able to demonstrate that any algorithm automating decision-making considers the criteria required for such a decision to be compliant with the GDPR.” (see ICANN CEO Goran Marby’s blog post at https://www.icann.org/news/blog/icann-meets-with-belgian-data-protection-authority) Therefore, we ask that all the use cases proposed by the BC (https://community.icann.org/download/attachments/126424070/Use%20Cases%20That%20Support%20Automated%20Disclosure%20Decisions%20v2.01.docx?version=1&modificationDate=1581343809000&api=v2) be automated.

Additionally, to incorporate the use case of a “clear cut” trademark claim proposed by the BC, we ask that the policy make it clear that CPs should not evaluate the merits of a trademark claim (and instead determine that one exists which meets the criteria in the BC document.)

Additionally, we ask for automated disclosure in response to requests:
• where the registrant has consented to make their registration data public;
• made by officers of the court, under penalty of perjury, that include a good faith assertion that a clearly identified and protectable IP right is being infringed through use of an identified domain name (https://www.americanbar.org/news/reporter_resources/midyear-meeting-2020/house-of-delegates-resolutions/101b/)
No, I wish to continue to the next section
Support intent of recommendation with edits
The IPC generally supports Recommendation #8, but believes the following revisions to the recommendation will make the SSAD more efficient.

a) and b): no comments.

c): we ask that the gateway’s recommendations be automated as much as possible, rather than made by gateway staff. To do this, the gateway manager must be directed to use Machine Learning and leverage the gateway’s logs: what types of requests are accepted and denied, which requestors have a high or low disclosure rate, what makes a request clear cut, etc.

d): we ask for deletion of the second sentence. Recommendation 9 does not envisage that there is a “number of requests” beyond which a CP’s non-compliance with its SLA is excused, certainly not without being time-bound. Instead, a CP’s obligation is to have enough personnel to respond to requests in a timely fashion and with enough capacity to account for fluctuations.

e): we offer edits (in ALL CAPS) for the first sentence to ensure that disclosure denials are properly motivated, communicate useful information to ICANN Compliance and the requestor, and give the requestor the right to complain but also have the denial reversed on appeal:
“Responses where disclosure of data (in whole or in part) has been denied must BE SENT TO THE REQUESTOR AND THE CENTRAL GATEWAY (WHICH WILL THEN IMMEDIATELY FORWARD IT TO ICANN COMPLIANCE) AND include: A rationale sufficient for the requestor to understand the reasons for the decision, including, for example, an analysis and explanation of how the balancing test was applied (if applicable); AND (IF APPLICABLE) EVIDENCE SUPPORTING THE DENIAL, SUCH AS EVIDENCE THAT THE REQUESTED DATA IS NOT NECESSARY TO THE REQUESTOR’S STATED PURPOSE, OR WHERE IT IS ALREADY PUBLICLY AVAILABLE. Additionally, in its response, the entity receiving the access/disclosure request must include information on how public registration data can be obtained, AND ON HOW, IF THE REQUESTOR IS OF THE VIEW THAT ITS REQUEST WAS DENIED ERRONEOUSLY, THE REQUESTOR MAY FILE A COMPLAINT AND APPEAL WITH ICANN COMPLIANCE.”

f): we ask that the criteria for urgent requests be clarified with examples, to help requestors (who risk losing their right to make urgent requests if they get it wrong too often) and avoid having CPs urgently process requests that aren’t in fact urgent.

First paragraph of p.31: we are concerned that the language isn’t aligned with e): the first paragraph of p.31 requires the CP to inform not only the requestor but also ICANN Compliance of a denial when a disclosure “would be in violation of applicable laws or result in inconsistency with these policy recommendations”, while e) only requires informing the requestor of the denial: does that mean there are other grounds for denying a request than “violation of applicable laws or inconsistency with these policy recommendations”? We therefore ask that this paragraph be deleted and that, as we propose above, its requirement about informing ICANN Compliance be moved into paragraph e.

Second paragraph of p.31: when a requestor is of the view that its request was denied erroneously, the requestor should be able to complain to ICANN Compliance but also have the denial reversed if ICANN Compliance finds it was unwarranted. Additionally, ICANN Compliance must be required to investigate all complaints, and not just “be prepared to investigate” them. ICANN Compliance must render its decision within 5 business days.
Support intent of recommendation with edits
MPA asks for the following changes to this Recommendation.

Changes regarding priority level 3 (normal requests)
• Impose a 5-business day limit for every request—CPs must be required to respond to EVERY request within 5 business days. When that limit is exceeded, the gateway must automatically inform ICANN Compliance. ICANN Compliance shall immediately investigate the CP, and issue a Breach Report that shall include: the findings of the investigation, the penalties imposed by ICANN Compliance, and the measures ordered by ICANN Compliance to ensure the CP returns to compliance. Potential penalties shall take into account previous instances of non-compliance with this SSAD policy. Immediately, the gateway shall publish the Breach Report and send it to each requestor whose request did not receive a response within 5 business days. Imposing this 5-day cap would also require that the form 1-form 2 enforcement mechanism be abandoned.

• If a 5-day limit isn’t imposed—We ask for the inclusion in the Recommendation of the content of this document developed by the BC and CPH https://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200304/72314f67/EPDPPhase2SLAproposaldetailclarification-0001.pdf and we ask that form 1 and form 2 be strengthened, as follows:
1. Form 1: when a CP exceeds its 5-day target, ICANN Compliance shall be required to develop a Remedial Plan for the CP within 5 business days, on the basis of the review it has done with the CP. Each Remedial Plan shall be immediately published by the gateway, along with the CP’s response to the Remedial Plan.
2. Form 2: every request should receive a response within 10 business days: that should not be just the maximum average. When a CP exceeds its 10-day compliance obligation, ICANN Compliance shall be required to investigate the CP and issue a SLA Breach Report. The SLA Breach Report shall include: the findings of the investigation; any previous form 1 Remedial Plan developed by ICANN Compliance for the CP in question; the measures ordered by ICANN Compliance to ensure the CP returns to compliance; and the penalties imposed by ICANN Compliance. Potential penalties shall take into account the CP’s degree of implementation of its previous form 1 Remedial Plan(s), and any other instance of non-compliance with this SSAD policy. Immediately, the gateway shall publish the SLA Breach Report and send it to each requestor whose request did not receive a response within 10 business days. A breach of the 10 business days SLA is a breach of the RAA, unless ICANN Compliance provides an explanation to the contrary in its SLA Breach Report.
3. The review of SLA targets shall be done with Recommendation 19’s procedure for the Mechanism for the Evolution of the SSAD.

Changes regarding priority levels 1 and 2
1. Instead of one business day, MPA asks that urgent requests receive a response within 24 hours. Given the gravity of its circumstances, an urgent request filed on a Friday cannot potentially wait until Monday for a response.
2. To help avoid confusion and abuse of the priority 1 and 2 levels, Recommendations 9 and 8.f need to be clarified as follows:
a. Require requestors to provide evidence that their requests warrant a priority 1 or 2 designation;
b. Provide examples of such evidence, and state that if such evidence is confidential a sworn affidavit shall suffice.
3. For the avoidance of doubt, Recommendation 9 should include this sentence from Recommendation 8: “the use of ‘Urgent’ SSAD Requests is not limited to LEA.”

Finally, the EPDP should require ICANN to set, and ensure its and its contractor’s compliance with, requirements for the Central Gateway (including its uptime SLA, performance SLA, user support features and availability), set at industry standard levels. 
No, I wish to continue to the next section
Support intent of recommendation with edits
First paragraph: we ask for the following edit (add text in ALL CAPS) to the last sentence: “For the avoidance of doubt, every request does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered BY ICANN COMPLIANCE in the event of apparent misuse.”

a), through e): no comments.
Support intent of recommendation with edits
a) through e): no comments.

f) and g) and i): we are concerned about potential misuse of these three provisions to prevent legitimate disclosures or inhibit their legitimate effect. We therefore ask for the following changes:
• Add text to f): “the CP may not pro-actively inform, or offer to pro-actively inform, registrants of disclosure requests once it has received them. The CP may not condition its approval of a disclosure request to the registrant’s consent, or absence of objection, to the request.”
• Edit text of g): while the GDPR provides a right to erasure, it is unclear what “erasure” refers to in this context: erasure from what record? It should be clear that it does not mean erasure from the CP’s registration record or from the requestor’s records.
• Add a new bullet j): “The domain name that is the subject of a disclosure request shall be locked (using the UDRP definition) during the pendency of a disclosure request.”

h): align the language here with the first paragraph of Recommendation 13: the “privacy policy for the SSAD and standard language (relating to the SSAD) to inform data subjects” should be developed by all SSAD stakeholders, and not just ICANN and the CPs.

i): we ask that the text clarify that requests that require confidentiality because of “the nature of legal investigations or procedures”:
o are not limited to criminal investigations or to other investigations (e.g. many civil investigations require confidentiality);
o are not limited to investigations by governmental agencies (most civil investigations are conducted by private parties.) This also requires that the word “authority” be replaced with “entity”.
Support intent of recommendation with edits
(a) No comment.

(b) We ask that the following sentence (on p.36) be modified:
“In the event the entity receiving requests makes a determination based on abuse to limit the number of requests a requestor, further, to point b, the requestor MAY seek redress via ICANN org if it believes the determination is unjustified.”
It should clarify who makes the initial determination, who may review it, and what the review shall focus on It should read instead (changes in ALL CAPS):
“In the event the CENTRAL GATEWAY MANAGER makes a determination based on abuse to limit the number of requests a requestor CAN MAKE, further to point b, the requestor may APPEAL THIS DETERMINATION AND THE LIMITS IT IMPOSES TO ICANN COMPLIANCE.”

(c) This policy should allow reverse lookup: if disclosure has been granted for one domain, the CP should be required to disclose to the requestor the other domains registered by the same registrant, at least in cases where the request’s purpose is to act against the registrant’s alleged domain abuse or illegal activity, because of the significant likelihood that such abuse or illegality is taking place on the registrant’s other domains. The fact that the requestor has not found these other domains yet is not indicative of the absence of abuse or illegality there. And once these domains have been disclosed to the requestor, the requestor will still need to satisfy applicable legal and judicial requirements if he intends to take legal action.
Support intent of recommendation with edits
First paragraph
Instead of “taking into account” the EPDP’s final recommendations (which makes the recommendations mere indicative guidance rather than actual policy), the various agreements should “conform to” the recommendations.
Support intent of recommendation with edits
There will be circumstances where the first and second sentences contradict each other. We recommend the following edit (in ALL CAPS):

“The EPDP Team recommends that requestors must confirm that they will store, protect and dispose of the gTLD registration data in accordance with applicable law. Requestors must retain only the gTLD registration data for as long as necessary to achieve the purpose stated in the disclosure request, UNLESS OTHERWISE REQUIRED TO RETAIN SUCH DATA FOR A LONGER PERIOD UNDER APPLICABLE LAW.”
Support intent of recommendation with edits
Second and third paragraph
We ask for the deletion of the word “initially” from the first sentence of the second paragraph, to clarify that the cost of developing, deploying and operationalizing the system shall be borne entirely by ICANN Org etc., rather than just “initially.” Accordingly, the reference to “whereby historic costs may be considered” should also be deleted from the first sentence of the third paragraph.

Seventh paragraph (starting with “the SSAD SHOULD NOT”)
We would like specifics regarding the suggested legal risk fund and why such a fund is necessary. All businesses and systems operate subject to some legal risk, so it is not clear why this system necessitates a special fund for its legal risks.
Support recommendation as written
No, I wish to continue to the next section
Support intent of recommendation with edits
Support recommendation as written
Intent and wording of this recommendation requires amendment
We ask that the increased centralization of disclosure decision-making be explicitly added to the list of responsibilities of the Mechanism.

We also ask that this policy provide that the Mechanism must be given sufficient resources to obtain the legal advice it needs to support its work.
We ask that this Mechanism represent the entire ICANN community, rather than only the GNSO, e.g. it should include representatives of ALAC, GAC and SSAC whose perspectives and expertise is important and who represent SSAD requestors not otherwise represented on the GNSO.
Support implementation guidance as written
ccTLDs are subject to their own policies. However, since some of them have followed the example of ICANN and terminated open access to WHOIS, they may be open (now or later) to the notion of participating in the SSAD. The EPDP should provide explicitly for that possibility in this policy.
Centralized decision-making remains critical to MPA
The Belgian DPA has told ICANN Org that its letter “was not meant to deter the development of a centralized model” and “a centralized model is worth exploring and it seems to be a better, “common sense” option in terms of security and for data subjects.” (per the blog post of ICANN CEO Goran Marby.) When asked if “the contracted political parties [could be] just the processors and ICANN in the role of making decisions for WHOIS disclosure can be the controller and [the representatives of the Belgian DPA] said ‘yes that’s also a possibility’.” (per the February 27, 2020 comments to the EPDP of ICANN Government & IGOs Engagement Senior Director Elena Plexida.)
Therefore, we ask that the EPDP review and adapt its report using a centralized disclosure decision model.

Clarity and enforceability of the requirements
1. MPA believes it is absolutely essential that this policy be enforceable, rather than lay down aspirations and expectations that parties to the SSAD – in particular requestors and CPs – can choose to ignore. Therefore, we ask that ICANN Compliance immediately review the Initial Report to identify any requirement that is either not enforceable or difficult to enforce, e.g. because it is too vaguely worded, subjective, conditioned or only expressed as a “may” or “should.”

2. We are concerned about the use, throughout the report, of the words “expect”, “expected” and “expectation” – as in “The EPDP Team expects that the following types of disclosure requests can be fully automated” (p.29), or “The EPDP Team expects implementation to reasonably determine how many may be submitted at a time and consistent with the Query Policy” (footnote, p.36.) These formulations are inherently ambiguous: they might express a hard requirement (akin to “must”/”shall”), a recommended requirement (akin to “should”) or a possibility without a preference (“may.”) For the sake of clarity and enforceability of the SSAD policy, we ask that every single instance of “expect”, “expected” and “expectation” be reviewed and replaced with “must”, except for specific instances where the EPDP decides to use “should” or “may.”

3. The Initial Report makes very inconsistent use of “Implementation Guidance.” In most instances, it is not distinguishable from the requirements of this proposed policy: it is not more or less important, detailed or binding (e.g. on p.31: “The Central Gateway Manager MUST confirm that the request is syntactically correct, including proper and valid Authentication and Signed Assertions”: this should be policy, not Implementation Guidance.) We ask that the EPDP systematically review every instance of Implementation Guidance to confirm whether it should be policy or not.

Registration data accuracy

The ICANN community has long known that registration data inaccuracy was a major problem. Spending two years building an elaborate policy, technical system and set of enforcement mechanisms to tightly control access to frequently inaccurate registration data makes little sense – and yet, with the recent GNSO Council’s decision, that is where we are. MPA is profoundly disappointed. This situation must be effectively and fully remedied rapidly. CPs cannot continue to process, and soon give access to, registration data that is inaccurate, in flagrant violation of the GDPR.
6
3/6/2020 8:04:15Delphine Sarbach
Federation of the Swiss Watch Industry
NoYes
7
3/16/2020 9:13:12Sylvia SandersPernod RicardYes
We are providing input as domain name professional working at Pernod Ricard
No, I would like to continue to the next section
Support Recommendation intent with wording change
The Accreditation Authority: (m) User groups/categories referred to should be better defined. Does it mean Companies, Not-Profits, individuals, etc.?

Accredited entities or individuals: "store, protect and dispose of the gTLD registration data..." should this say gTLD registration data or simply "registration data"? What about ccTLD's?
No opinionDefinitions
Significant change required: changing intent and wording
The idea that the domain name registrant information will need to be requested individually for every domain name is fine BUT once a registrant is identified, will we be able to get a reverse WHOIS to show other domain names registered in order to combine them into one Complaint or recovery process? How can we determine what other domain names a registrant holds in order to determine if this is a cybersquatter who has registered various domain names covering one or more of our brands?

Is the idea that once a registrant is identified, we will need to submit further SSAD requests to search on the registrant name and/or the registrant's email address?

Or will the SSAD request contain another tier - identify the domain - then further identify other domains owned by the same registrant using name and/or email address?
Support Recommendation as written
Support Recommendation intent with wording change
The last line in the recommendation: "....consistent with the recommendations outlined below." is not clear. Perhaps "consistent with the guidelines laid out in the Preliminary Recommendation #6. " Contract party Authorization".

Also, a maximum timeline for the acknowledgement should be defined here (not just "without undue delay").
Support Recommendation as written
Support Recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support intent of recommendation with edits
The proposal outlines a timeline for the Contracted party to respond. Is there a timeline for the Central Gateway manager to respond?

Regarding Priority 2 - this is confusing to us as it should mean do we INTEND to file a UDRP/URS ... not HAVE WE ALREADY filed a UDRP/URS. What is the correct interpretation? Per the example give before the chart, it appears to mean ALREADY FILED; why would we create an SSAD request on a domain where a UDRP has already been filed (WIPO will tell us that information)?

Perhaps we are completely misinterpreting this Priority. Does it mean that WIPO will also create SSAD Requests and their requests are Priority 2?

In the Paragraph "In Phase 1, Registrar response....." everywhere else, the registrar is being referred to as the "Contracted Party"... unless we are confused as to what "contracted party actually means". Please correct the wording in that instance as "Contracted Party" to remain consistent with the rest of the document.

Phase 1 response time is 4 days for SSAD Priority 3 requests and 10 days in Phase 2. We do not understand why the time would increase. Shouldn't it decrease as the process becomes more familiar and possibly automated?
There is reference in this Recommendation to RDS. The acronym RDS is not defined in the document (please define).
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Intent and wording of this recommendation requires amendment
The question regarding how to get a listing of other domain name registrations a registrant may have still is an issue. In short, how will we be able to file one complaint against multiple domain name registrations vs. 1 complaint per registration if we cannot get something similar to a "reverse whois"?
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
For clarity, we are a Corporation that has many subsidiaries/affiliates - we request on behalf of all of these entities. Please clarify if only ONE SSAD is necessary for us (so we only pay the cost of validating ONE user) - not one per subsidiary/affiliate.

Also, are we interpreting the Recommendation that there will be a charge PER domain information request? If so, per the PLACEHOLDERS section, exactly how would you determine if a resubmitted request is new or not & needs to be charged again? Perhaps a "subscription" charge would be more suitable vs. a per domain charge.
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
Data information requests could be structured similar to GoDaddy's or Denic request forms for registrant information. Their forms are clear, user friendly & easy to submit.
---Who should guidance be provided to?
[RESPONSE]: Apologies, This question is not clear. Are you asking how input from the users can be submitted & handled?
---How is guidance developed / agreed to? --
[RESPONSE]: Again, if we are referring to input from the users of the system, perhaps a "suggestion box" on the request screen and/or annual surveys to the users
--- How should it be structured?
[RESPONSE]: I would anticipate this SSAD System to be similar to the TMCH set-up: A portal for domain information requests, support requests, feedback area, accreditation status and the activity request log (recommendation #17).
Once the system is functional, an advisory committee, made up of registries, registrars & accredited users, could be set up to review if the system is working as planned & to offer recommendations.
Information Bulletins in an "Information/update section" in the SSAD Request Portal. Emails should be sent to accredited users to indicate there is new information/guidance entered into the portal.
Intent and wording of this implementation guidance requires amendment
Include how we are able to get reverse WHOIS information.
Number of requests; number approved; number denied (& why - a category system); types of entities (Natural individuals vs. Legal Individuals (companies)), length of time to respond. Regarding Automation on the completeness of request forms - how many required modification and why (what fields are not being completed properly). Count on requests by domain name extension (this will give a view as to the extensions of main concern to the community). Country of the registrants where information was returned to the requestor (this will give a view of what country the registrants are from that have the most questionable registrations)
not at the moment
Again, we stress the absence of our ability to obtain reverse whois information. Simply returning a list of other domain names registered by the same registrant (name/email) would greatly assist in reducing UDRP complaint costs.
8
3/23/2020 10:28:34Marianne GeorgelinAfnicNo
No, I would like to continue to the next section
Significant change required: changing intent and wording
Some questions are not addressed in this recommandation:
- How will ICANN choose the identity providers? Based on which criteria?
- What will be the cost/fees of such accreditation? How will these costs/fees be determined? Who will bear those costs?
Support Recommendation intent with wording change
The whole process is complicated to understand. The implementation of this recommandation will require to accompany gov. authorities in all the steps of this accreditation process.
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Significant change required: changing intent and wording
When reading the recommandation, it is unclear whether the automated disclosure will be directly processed by the central gateway or by the contracted party to which the request is made. In other words, who will disclose the data? Our understanding of the SSAD is that the data never passes through the central gateway and remains at the contracted party level to be directly disclosed to the requestor by the contracted party. The central Gateway should never have access to Whois data otherwise, the whole system would be legally questionnable. Based on this assumption, how will this automation work?
No, I wish to continue to the next section
Support intent of recommendation with edits
Criteria for Urgent SSAD requests are not defined precisely enough and could lead to abusive requests.
No opinion
No, I wish to continue to the next section
Support recommendation as written
No opinionNo opinion
Support recommendation as written
Support recommendation as written
Intent and wording of this recommendation requires amendment
"It is the EPDP Team’s expectation that the SSAD will ultimately result in equal or lesser costs to Contracted Parties compared to manual receipt and review of requests."

The two past years of GDPR implementation have demonstrated that the costs for gTLDs like geo/brands are closed to 0 due to the total absence of request. It is though very unlikely that the SSAD will ultimately result in equal or lesser costs to these contracted parties compared to a manual processing of the requests.
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support recommendation as written
Intent and wording of this implementation guidance requires amendment
It should be clearly stated that disclosure of personal by contracted parties shall remain on a case by case basis.
9
3/19/2020 4:25:36Hend BAKLOUTI
Insance Nationale des Télécommunications de Tunis (GAC representative)
Yes
I am Enginner at Instance Nationale des Télécommunications de Tunis (Tunisian Regulation Authority) and Tunisia GAC representative
No, I would like to continue to the next section
Significant change required: changing intent and wording
The accrediting authority role can be performed either by ICANN or by a management entity overseen by ICANN. However, If ICANN will take over operational management tasks, its role can no longer be limited to the control of registrars. For the second option which consists in designating an entity which will ensure the accreditation of SSAD users, it is essential to detail the selection process of this entity, the necessary qualifications of this entity and in which case this entity can be de-accredited.
No opinionNo OpinionNo OpinionNo opinionNo opinionNo opinion
No, I wish to continue to the next section
Support intent of recommendation with edits
In order to limit abuse of the SSAD, the Central Gateway Manager must refuse any new request for the same data by the same requestor made prior to 72 hours from the initial request. Otherwise, documented justifications are needed.
No opinion
No, I wish to continue to the next section
No opinionNo opinion
Support intent of recommendation with edits
The Central Gateway Manager must be able to save, as far as possible, a history of the different requests, in order to keep traceability of exchanges between the SSAD / requestor / contracted parties. In case of SSAD violation relating to a public disclosure of non-public data, such information may be useful in determining the responsible.
No opinionNo opinion
Support intent of recommendation with edits
From a financial point of view, and in case that a fee system for disclosure requests will be adopted, it is necessary to reimburse requestors if their request is rejected as they have not used the required data.
Support intent of recommendation with edits
In order to guarantee the transparency of the disclosure procedure, it is necessary to consider the automation of this procedure as an urgent priority for the development of the SSAD. The disclosure algorithm must also be accessible and transparent. Disapproval cases must necessarily be explicit and communicated to the requestor.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In order to guarantee the transparency of the disclosure procedure, it is necessary to consider the automation of this procedure as an urgent priority for the development of the SSAD. The disclosure algorithm must also be accessible and transparent. Disapproval cases must necessarily be explicit and communicated to the requestor.
No opinionNo opinion
10
3/19/2020 10:25:38Javier GonzálezANDEMAYesANDEMA
No, I would like to continue to the next section
Support Recommendation intent with wording change
- The Accreditation Authority must be defined
- It is not defined in what case the Accreditation Authority may work with external or third-party Identity Providers
No opinionNo Opinion
Support Recommendation as written
No opinion
Support Recommendation as written
Support Recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
- Do not allow automated submissions to be made
- A historic of the requesters must be public available to keep the traceability
Support recommendation as written
Support recommendation as written
No opinion
Delete recommendation
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support recommendation as written
No opinion
11
3/20/2020 0:55:05Mette AndersenRegistrant and registryYesLEGO System A/S
No, I would like to continue to the next section
Significant change required: changing intent and wording
While fully supporting the premise that there be an accreditation policy for SSAD users, we need more clarity on the Identity Providers. For example, for trade mark issues, given their global mandate and access to trade mark registries/databases, we strongly advocate that this task should fall to WIPO.

Under “implementation guidance” (p. 20), we believe that “information asserting trade mark ownership” should be clarified to ensure that service providers and/or lawyers acting on behalf of the trade mark owners should also be eligible for accreditation.
Significant change required: changing intent and wording
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. We would suggest that para c, auditing (p23), should read “Audits should be conducted by the auditor designated by the applicable national / regional law”.
No OpinionNo Opinion
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgment of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible for the Contracted Party and should be the preferred action for urgent requests as set out in recommendation 9.
4. If the CP decides that “the answer to any of the questions is no” thus denies the request, there must be the possibility to appeal, given that this will by default be a subjective decision.
5. Assessment of impact:
• While of course impact on data subjects ought to be considered, this should be extended to also consider public interest (e.g. consumer protection, the security of the DNS etc.) well as impact on the requestor (right to property etc.).
• Nature of the data: if this is for a legal, and not natural, person then the data should be disclosed, given that data for legal persons does not fall within the GDPR.
• Reasonable expectations of the data subject: complying with the law, e.g. not disrupting the security of the DNS or trying to mislead or dupe consumers, is clearly “reasonable” and this should be specified.
• Requestors also have “interests or fundamental rights and freedoms”, including the right to property. This should form part of the balancing equation.
• If the CP denies the request, which by default will be a subjective decision, there must be a possibility to appeal.
• Implementation guidance: “an interest is deemed legitimate so long as...”. “Examples... include establishment, exercise or defence of legal claims”.
Support Recommendation intent with wording change
Implementation guidance: add “As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents”.
No, I wish to continue to the next section
Support intent of recommendation with edits
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
• Response targets for priority 3 requests are far too long for trade mark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the target is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.
• It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5 day target in Phase 1, nor that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
f) Disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail. At a minimum, we request these wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor;
g) Similarly, the “right to erasure” cannot be used to mask a fraudulent or criminal registrant. Knowing that a request has been made as to your data cannot be a blanket excuse for erasing data as this will seriously hinder enforcement actions.
Support intent of recommendation with edits
• b3) We cannot help but note the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.
• b4) Not every high volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.
• If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinion
Support recommendation as written
No opinionNo opinion
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
The Contracted Parties/Central Gateway Manager should also be regularly audited, not least so as to be able to identify repeat cases of unsubstantiated denials or non-response.
No opinion
Whatever mechanism is chosen, we strongly advocate for the GAC and SSAC to be fully involved.
Support implementation guidance as written
Data accuracy: while this has been discussed to some level within the EPDP Team, and some questions have been posed to Bird & Bird, it is essential that accuracy of the data held within the WHOIS be addressed. We strongly support the creation of a small team within the EPDP as soon as possible to consider this further. To expend so much effort and so many resources on ensuring the processing of and access to regsitrant data without any attempt to ensure its accuracy is unconscionable. This is inline not only with the views of the BC and IPC, but also the GAC and ALAC.
12
3/20/2020 1:03:06Mette M. AndersenRegistry and registrantYesLEGO Juris A/S
No, I would like to continue to the next section
Support Recommendation intent with wording change
While fully supporting the premise that there be an accreditation policy for SSAD users, we would prefer more clarity on the Identity Providers. For example, for trade mark issues, given their global mandate and access to trade mark registries/databases, we strongly advocate that this task should fall to WIPO.

Under “implementation guidance” (p. 20), we believe that “information asserting trade mark ownership” should be clarified to ensure that service providers and/or lawyers acting on behalf of the trade mark owners should also be eligible for accreditation.
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. We would suggest that para c, auditing (p23), should read “Audits should be conducted by the auditor designated by the applicable national / regional law”.
No OpinionNo Opinion
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgment of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible for the Contracted Party and should be the preferred action for urgent requests as set out in recommendation 9.
4. If the CP decides that “the answer to any of the questions is no” thus denies the request, there must be the possibility to appeal, given that this will by default be a subjective decision.
5. Assessment of impact:
• While of course impact on data subjects ought to be considered, this should be extended to also consider public interest (e.g. consumer protection, the security of the DNS etc.) well as impact on the requestor (right to property etc.).
• Nature of the data: if this is for a legal, and not natural, person then the data should be disclosed, given that data for legal persons does not fall within the GDPR.
• Reasonable expectations of the data subject: complying with the law, e.g. not disrupting the security of the DNS or trying to mislead or dupe consumers, is clearly “reasonable” and this should be specified.
• Requestors also have “interests or fundamental rights and freedoms”, including the right to property. This should form part of the balancing equation.
• If the CP denies the request, which by default will be a subjective decision, there must be a possibility to appeal.
• Implementation guidance: “an interest is deemed legitimate so long as...”. “Examples... include establishment, exercise or defence of legal claims”.
Support Recommendation intent with wording change
Implementation guidance: add “As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents”.
No, I wish to continue to the next section
Support intent of recommendation with edits
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
• There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
• Response targets for priority 3 requests are far too long for trade mark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the target is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.
• It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5 day target in Phase 1, nor that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No opinion
Support intent of recommendation with edits
f) Disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail. At a minimum, we request these wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor;
g) Similarly, the “right to erasure” cannot be used to mask a fraudulent or criminal registrant. Knowing that a request has been made as to your data cannot be a blanket excuse for erasing data as this will seriously hinder enforcement actions.
Support intent of recommendation with edits
• b3) We cannot help but note the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.
• b4) Not every high volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.
• If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinion
Support recommendation as written
No opinionNo opinion
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
The Contracted Parties/Central Gateway Manager should also be regularly audited, not least so as to be able to identify repeat cases of unsubstantiated denials or non-response.
No opinion
Whatever mechanism is chosen, we strongly advocate for the GAC and SSAC to be fully involved.
Support implementation guidance as written
Data accuracy: while this has been discussed to some level within the EPDP Team, and some questions have been posed to Bird & Bird, it is essential that accuracy of the data held within the WHOIS be addressed. We strongly support the creation of a small team within the EPDP as soon as possible to consider this further. To expend so much effort and so many resources on ensuring the processing of and access to regsitrant data without any attempt to ensure its accuracy is unconscionable. This is inline not only with the views of the BC and IPC, but also the GAC and ALAC.
13
3/20/2020 7:38:30Delphine Sarbach
Online Enforcement Team
No
No, I would like to continue to the next section
Significant change required: changing intent and wording
“SSAD MUST only accept requests for access/disclosure from accredited organizations, companies, associations and individuals”.
The terms “companies, associations” shall be added, in order to explicitly include the participation of all types of legal person in this process.
Support Recommendation as written
No OpinionNo Opinion
Support Recommendation as written
Significant change required: changing intent and wording
“”1. For the avoidance of doubt, automated review is not explicitly prohibited encouraged where it is both legal legally and technically permissible”
In order to deal with request without undue delay and to allow predictability for requestor in the outcome, it is best to promote automated reviews.
-“If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below.”
In order not to penalize requestor, the Contracted party shall provide requestors with the opportunity to overcome flaws in their request.

"4. each request SHOULD be evaluated individually (i. e. each submission should contain a request for data related to a single domain. if a submission related to multiple domains, each must be evaluated individually."
If the information requested are the same for more than one domain, it should be possible to put more than one in a same request, to not lose time for both parties.

“-Implementation Guidance “[…] :
• An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws
• Examples of legitimate interests include: (i) enforcement of legal claims, (ii) prevention of fraud and misuse of services (iii) IP infringements, (iv) physical, IT and network security)”
Mentioning explicitly counterfeit is necessary, to avoid any potential misunderstanding

Significant change required: changing intent and wording
• “Requests from Law enforcement in local or otherwise applicable jurisdictions
• Responses to UDRP and URS Providers for registrant information verification
• Reponses from accredited party with history of Valid disclosure requests “
Considering the number of potential requests and to avoid delays in the answers, it is recommended to extend the scenario of automated disclosure requests.
No, I wish to continue to the next section
Intent and wording of this recommendation requires amendment
“As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY will provide a recommendation an instruction to the contracted party whether to disclose or not. The contracted party MAY will have to follow this recommendation instruction. If the contracted Party decides not to follow […]”
The non-binding nature of the recommendation of the central gateway manager makes this body lose all legitimacy since its proposals may or may not be applied by the contracted parties. It would be more efficient and logical that Central gateway manager, issues a decision which the contracted party will have to follow. It would avoid creating additional delays and misunderstandings.
No opinion
No, I wish to continue to the next section
Intent and wording of this recommendation requires amendment
“The requestor :
a) must only request data from the current RDS data set (no historic data) as well as the historic RDS data set”
This is to avoid starting from scratch and losing all data that was available before.

“Contracted Parties and SSAD:
a) MUST return current data or a subset thereof in response to a request (no historic data , as well as the historic RDS data set”
e) Where required by applicable law, MUST perform a balancing test before processing the data
No need since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.
Intent and wording of this recommendation requires amendment
“The EPDP team recommends the SSAD, in whatever form it eventually takes, MUST:
[…]
• Support requests for current data, as well as historical registration data registration’s history.”
This is to be in line with previous comments
No opinionNo opinion
Intent and wording of this recommendation requires amendment
"The objective is that the SSAD is financially self-sufficient without causing any additional fees for registrants. Data subjects MUST NOT bear the costs for having their data disclosed to third parties; requestors of the SSAD data should primarily bear the costs of maintaining this system. ICANN MAY contribute to the (partial) covering of costs for maintaining the Central Gateway."
The cost must be divided and if the use by the registrants is unlawful, this would be normal that they pay.
"b) Rejected applicants MAY re-apply, but the new application(s) MAY be subject to the application fee."
if rejected, the applicants must have no fee, they have no service.
"d) Accredited users and organizations MUST renew their accreditation periodically."
To be deleted, no renewal periodically, once accepted, must stay, unlesse the situation changes.

There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the the party seeks the data because its rights have been infringed. It would be like a double sanction on the shoulders of a victim.
Therefore, the costs shall be bear by ICANN.
Let’s not forget that the more the system will be automatized, the less costly it will be.
No opinion
No, I wish to continue to the next section
No opinionNo opinionNo opinionNo opinion
14
3/20/2020 8:18:49
Meriem BOURAHLA-LOUDIYI
BIOFARMAYes
No, I would like to continue to the next section
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support implementation guidance as written
15
3/20/2020 8:28:12Sarina Edwards Employee TUI AG YesTUI AG
No, I would like to continue to the next section
No opinionNo opinionNo OpinionNo OpinionNo opinionNo opinionNo opinion
No, I wish to continue to the next section
No opinionNo opinion
No, I wish to continue to the next section
No opinionNo opinionNo opinionNo opinionNo opinionNo opinionNo opinion
No, I wish to continue to the next section
No opinionNo opinionNo opinionNo opinion
This is a final summary of TUI AG`s opinion - as we are not able to answer the questions in the given depth.

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

The introduction of a centralized hybrid model for SSAD which could be managed centrally by ICANN seems to be a positive step towards facilitating access to domain owner data, especially for trademark owners.

However, the proposed hybrid model would only provide ICANN with centralized access to the individual registries and a time-based component for response times. At best, this would relieve the burden of documenting the numerous abuse e-mail addresses given in the Whois extracts and the time limit in order to obtain faster information as to whether or not owner data can be disclosed as soon as an infringing domain becomes known.

In any case, however, the central problem with which trademark owners have to deal in their daily work with domain registrations of third parties is not addressed, because as described in the last paragraph, it is still left to the registries to decide whether or not to disclose the date of the domain owner. Therefore, the model of a one-stop-shop for the distribution of disclosure requirements proposed here seems to be only an administrative step but not a step towards giving trademark owners the necessary support to adequately protect and legally defend their trademarks.

However, the DENIC procedure offers serious support in this respect. DENIC offers trademark owners the opportunity to assert a legitimate interest in the owner data of a .de domain (in writing) and then submit the respective data for the purpose of legal action or out-of-court settlement. Such a procedure is particularly suitable for intercepting unnecessary legal disputes in an earlier case and for reaching an agreement.

A similar possibility is offered by the local arbitration proceedings within the UDRP, however, these proceedings do not apply to all top-level domains and are therefore often not a suitable method for trademark owners, also in view of the high costs and the time component of several weeks.

16
3/20/2020 8:42:01PICARD StephanieSOMFY ACTIVITES SAYes
In charge of trademarks and domain name matters
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed".
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
Yes
17
3/20/2020 9:33:39Domain managerSERVIERNo
No, I would like to continue to the next section
Support Recommendation intent with wording change

Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change

Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority
Support Recommendation as written
Support Recommendation intent with wording change

There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change

Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits

We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.


Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits

In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
Support intent of recommendation with edits

b3) We cannot help but notice the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.

b4) Not every high-volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.

If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinionNo opinion
Support intent of recommendation with edits

There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the party seeks the data because its rights have been infringed. This would be like a double sanction on the shoulders of a victim. Therefore, the costs shall be borne by ICANN. Let’s not forget that the more the system will be automatized, the less costly it will be.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits

The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response
Support intent of recommendation with edits

We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance with edits
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more are more numerous.

It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names, and notably those used for the sale and promotion of counterfeit goods.
Those websites are increasingly numerous and often with proven links with transnational organized crime. Several surveys show that nowadays, when a consumer buys a fake product online, most of the times he is himself a victim as he got duped.
Allowing accredited parties to have access to data of domain names involved in the sale of counterfeit goods is the only way to begin to take action against their owner.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
Indeed, GDPR application should not lead to the loss of compelling and vital data (i.e. WHOIS data).

Regarding data accuracy:
While this has been discussed to some level within the EPDP team, it is essential that accuracy of the data held within the WHOIS be addressed.
We strongly support the creation as soon as possible of a small team within the EPDP to consider this further. To expend so much effort and so many resources on ensuring the processing of and access to registrant data without any attempt to ensure its accuracy is unconscionable. This is in line with the views of the GAC and ALAC.

In our increasingly connected world, we should definitely consider the offline world components as equivalent to the online world ones. Besides, it is important that people going to a website, are capable of knowing who the registrant is. It is a matter of Transparency and Trust.
Moreover, protection of the consumer is essential in the online world where the source of the products can easily be hidden. Therefore, having the registration data publicly available would enable consumers to check the trustworthiness of a website in a more reliable way than looking at the website content. Of course, it would be even more useful if the data provided by the registrant is verified.
18
3/20/2020 9:47:05Laurent DhennequinComité ColbertYes
I answer on behalf of the Comité Colbert, a French association gathering French luxury companies and Cultural institutions
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.

Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
Support intent of recommendation with edits
b3) We cannot help but notice the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.

b4) Not every high-volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.

If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinionNo opinion
Delete recommendation
There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the party seeks the data because its rights have been infringed. This would be like a double sanction on the shoulders of a victim. Therefore, the costs shall be borne by ICANN. Let’s not forget that the more the system will be automatized, the less costly it will be.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more are more numerous.
It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names, and notably those used for the sale and promotion of counterfeit goods.
Those websites are increasingly numerous and often with proven links with transnational organized crime. Several surveys show that nowadays, when a consumer buys a fake product online, most of the times he is himself a victim as he got duped.
19
3/21/2020 2:46:57MARTINI-BERTHONLawyerYes
Law firm Marchais & Associés
Yes
20
3/21/2020 14:20:27Franck JournoudIPCNo
No, I would like to continue to the next section
Support Recommendation intent with wording change
The IPC supports the framework and principles outlined in this recommendation and believes it will form a solid foundation to ensure an effective, efficient and legally sound access to the SSAD system.

We believe however that it should be improved to include the concept of an Accredited Entity who is also a Trusted Notifier. Accredited Entities who are also Trusted Notifiers are subject matter experts that have been additionally vetted to monitor and investigate issues of illegal activity and abuse. Befitting their designation, Accredited Entities who have been vetted to be a Trusted Notifier have an established reputation for accuracy, a recognized relationship with the ecosystem and a proven record of following the defined process for requesting access to non-public Registration Data via the SSAD.

The accreditation period should be as long as possible, to reduce the burden of having to frequently seek re-accreditation.

There should be a specified appeal mechanism for any decisions to de-accredit an accredited user on the basis of an alleged violation of the system.
Support Recommendation intent with wording change
Under “Objective of accreditation,” the statement “SSAD SHOULD ensure reasonable access….” ought to be changed to “SSAD MUST ensure reasonable access….”

Under “Accreditation procedure,” the statement “This authority SHOULD publish the requirements….” ought to be changed to “This authority MUST publish the requirements….”
Support Recommendation intent with wording change
Regarding the intent of the recommendation. The recommendation should clarify what is meant by “standardization” in this context. In other instances, the Interim Report uses “standardization” and “standardized” in the context of how the Contracted Parties decide whether to disclose or not. Here, since requests will be submitted via a centralized SSAD Central Gateway, the gateway will have a unique - rather than merely “standardized” - set of information the requestor must submit. However, if “standardization” refers to standardization between different types of requests (between cybersecurity, IP enforcement, consumer protection, etc.), then we support this objective and ask that this meaning be spelled out.

Regarding the wording of the recommendation. First, the Central Gateway should present lists of pre-populated fields to the requestor (e.g. a list of third party purposes/justifications.) These lists may or may not be exhaustive, depending on the fields. This would streamline the request and decision-making process and thus help the SSAD reach its predictability objective. Second, the wording of Recommendation 2 needs to be aligned with that of Recommendation 6:
in c) replace “specific rationale” and “basis or reason for the request” with “legitimate interest or other lawful basis”; and
in e) replace “adequate, relevant and limited to what is necessary” with “necessary.”
Support Recommendation as written
Support Recommendation intent with wording change
The wording of the first paragraph should be aligned with the wording of Recommendations # 8 (Response Requirements) and 16 (Automation), to read: “The EPDP Team recommends that the Central Gateway provide an immediate and synchronous response that indicates the receipt of a valid request”, rather than “without undue delay”, which won’t be a problem for an automated system and will maximize its efficiency. There is no reason to impose on a computer system a promptness requirement that is more appropriate for humans.
Support Recommendation intent with wording change
The IPC supports this Recommendation with the following proposed changes.

Incorporate the clarifications offered by the BC in this document https://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200304/72314f67/EPDPPhase2SLAproposaldetailclarification-0001.pdf into the final EPDP Phase 2 report.

Mirroring a policy recommendation from the RPM WG Initial Report (https://gnso.icann.org/sites/default/files/file/field-file-attach/rpm-phase-1-initial-18mar20-en.pdf), the IPC recommends that the Registry Agreement and Registrar Accreditation Agreement include a provision stating that the contracted party shall not act in such a way as to have the effect of circumventing the purpose of SSAD, e.g. defaulting to denials of disclosure to meet SLAs etc.

Changes regarding priority level 3 (normal requests)
1. Each disclosure request MUST receive a substantive response in 5 business days or less. When it doesn’t, the gateway shall send an automated alert to ICANN Compliance and ICANN Compliance shall investigate without undue delay.
2. SLA enforcement form 1 needs to be strengthened.
a. In addition to requiring that a CP that does not meet its 5 day response target “participate in a review with [ICANN] Compliance to establish the root cause for exceeding the average response time expectation”, ICANN Compliance shall be required to develop a Remedial Plan on the basis of the review. Each Remedial Plan shall be published by the gateway.
3. SLA enforcement form 2 needs to be strengthened.
. Every breach of the 10 business days SLA shall be investigated by ICANN Compliance and result in a SLA Breach Report.
a. The SLA Breach Report shall include: the findings of the investigation; any previous form 1 Remedial Plan developed by ICANN Compliance for the CP in question; and the penalties imposed by ICANN Compliance.
b. The gateway shall publish the SLA Breach Report.
c. To determine potential penalties, in addition to complaint volumes and CP size, ICANN Compliance shall take into account: whether and to what extent the CP had implemented all its previous form 1 Remedial Plan; and all aspects of a CP’s compliance with the requirements of this SSAD policy.
d. The gateway shall without delay send the SLA Breach Report to each requestor whose request did not receive a response within 10 business days during the relevant time period from the CP in question.
e. A breach of the 10 business days SLA is a breach of the RAA, unless ICANN Compliance provides an explanation to the contrary in its SLA Breach Report.
4. Our recommendations for the mechanism by which the SLA targets shall be reviewed are the same as those we make for the Mechanism for the Evolution of the SSAD (Rec 19.)

Changes regarding priority levels 1 and 2
1. Currently, urgent requests are proposed to be addressed in one business day. The IPC raises concern that if an urgent request is made on a Friday, it will not be addressed until three calendar days later. In these urgent cases, the IPC thinks it best to have a 24 hour response time.
2. To avoid misuse of the priority 1 and 2 levels, the report should require evidence. Recommendation 9 only requires the requestor to assert a priority level, whereas Recommendation 8 (see f), under Urgent SAD requests) mentions “requests for which evidence is supplied to show an immediate need for disclosure.” Recommendation 9 should therefore: a. explicitly require the requestor to provide evidence supporting his assertion that a request is a priority 1 or 2; b. provide examples of what evidence would be sufficient for each priority level; and c. if confidential or legally privileged evidence cannot be provided, allow the evidence to be provided in the form of affidavits.
3. The procedure for setting the priority level should be clarified. The following sentence is unclear, as it seems to imply incorrectly that it is the gateway that sets the priority level: “When selecting a priority, the Central Gateway Manager will clearly state the criteria applicable for an Urgent Request and the potential consequences of abusing this priority setting.” The sentence should instead read: “When a requestor sets the priority level of a request as Priority 1 or 2, the Central Gateway will clearly state the criteria applicable for these priority levels and the potential consequences of abusing these priority settings.”
4. For the avoidance of doubt, Recommendation 9 should include this sentence from Recommendation 8: “the use of ‘Urgent’ SSAD Requests is not limited to LEA.”
Finally, this recommendation should include an SLA for the Central Gateway’s uptime, set at an industry standard level such as 99.9%.
Support Recommendation intent with wording change
The IPC believes that automation of the receipt, authentication, and transmission of SSAD requests as well as automated disclosure of non-public registration data is an important and positive mechanism that will allow more efficient response to DNS abuse. However, as currently written, Recommendation #7 too narrowly limits the types of disclosure requests that are authorized for Day 1 automation, listing only: (1) Requests from Law Enforcement in local or otherwise applicable jurisdictions; and (2) Responses to UDRP and URS Providers for registrant information verification.
The IPC believes this strict limitation is a counter-productive way to implement the otherwise very useful and efficient mechanism of automation. Rather, there should be full automation from Day 1 for as many types of disclosure requests as are practically and legally possible. At a minimum, the IPC suggests Recommendation #7 be revised to include, on top of the initial two types of requests listed above, the following:
1. Requests where:
a. the data subject is a legal person [to the extent that such information is not publicly available in WHOIS]; and/or
b. neither the data subject nor the Contracted Party are subject to EU law [to the extent that such information is not publicly available in WHOIS]; and/or
c. the data subject has consented to make their registration data public;
2. Requests that are made by officers of the court, made under penalty of perjury, and include a good faith assertion that a clearly identified and protectable IP right is being infringed through use of an identified domain name; (https://www.americanbar.org/news/reporter_resources/midyear-meeting-2020/house-of-delegates-resolutions/101b/)
3. Requests relating to domains registered in new gTLDs that only permit legal entities to register domain names (e.g., .BANK)
4. The other use cases identified and examined by the EPDP team (https://community.icann.org/download/attachments/126424070/Use%20Cases%20That%20Support%20Automated%20Disclosure%20Decisions%20v2.01.docx?version=1&modificationDate=1581343809000&api=v2)
The language in subsection 1 “(and is confirmed during the implementation phase)” is confusing and potentially problematic. The policy should not require confirmation during the implementation phase; it should simply be implemented. Also in subsection 1 the reference to “the criteria established in these policy recommendations” is too ambiguous. This recommendation should clearly include all requirements for a request to qualify for automation.

The IPC cautions that Contracted Parties should neither be asked nor expected to evaluate the merits of a potential trademark claim or the need for a trademark investigation. We appreciate the desire to reduce Contracted Parties’ risk, and to protect data subjects’ privacy rights, and we remain committed to these objectives. However, we must caution that delegating trademark-related access requests to contracted parties does not further these interests, and actually increases risk.
Finally, the IPC believes that if the Mechanism for the evolution of SSAD identifies additional categories of requests that could be fully automated, the SSAD must
allow for automation of their processing and the requests must be
automatically processed and result in the disclosure of non-public RDS data
without human intervention if legally permissible.
No, I wish to continue to the next section
Support intent of recommendation with edits
The IPC believes that automation of the receipt, authentication, and transmission of SSAD requests as well as automated disclosure of non-public registration data is an important and positive mechanism that will allow more efficient response to DNS abuse. However, as currently written, Recommendation #7 too narrowly limits the types of disclosure requests that are authorized for Day 1 automation, listing only: (1) Requests from Law Enforcement in local or otherwise applicable jurisdictions; and (2) Responses to UDRP and URS Providers for registrant information verification.
The IPC believes this strict limitation is a counter-productive way to implement the otherwise very useful and efficient mechanism of automation. Rather, there should be full automation from Day 1 for as many types of disclosure requests as are practically and legally possible. At a minimum, the IPC suggests Recommendation #7 be revised to include, on top of the initial two types of requests listed above, the following:
1. Requests where:
a. the data subject is a legal person [to the extent that such information is not publicly available in WHOIS]; and/or
b. neither the data subject nor the Contracted Party are subject to EU law [to the extent that such information is not publicly available in WHOIS]; and/or
c. the data subject has consented to make their registration data public;
2. Requests that are made by officers of the court, made under penalty of perjury, and include a good faith assertion that a clearly identified and protectable IP right is being infringed through use of an identified domain name; (https://www.americanbar.org/news/reporter_resources/midyear-meeting-2020/house-of-delegates-resolutions/101b/)
3. Requests relating to domains registered in new gTLDs that only permit legal entities to register domain names (e.g., .BANK)
4. The other use cases identified and examined by the EPDP team (https://community.icann.org/download/attachments/126424070/Use%20Cases%20That%20Support%20Automated%20Disclosure%20Decisions%20v2.01.docx?version=1&modificationDate=1581343809000&api=v2)
The language in subsection 1 “(and is confirmed during the implementation phase)” is confusing and potentially problematic. The policy should not require confirmation during the implementation phase; it should simply be implemented. Also in subsection 1 the reference to “the criteria established in these policy recommendations” is too ambiguous. This recommendation should clearly include all requirements for a request to qualify for automation.

The IPC cautions that Contracted Parties should neither be asked nor expected to evaluate the merits of a potential trademark claim or the need for a trademark investigation. We appreciate the desire to reduce Contracted Parties’ risk, and to protect data subjects’ privacy rights, and we remain committed to these objectives. However, we must caution that delegating trademark-related access requests to contracted parties does not further these interests, and actually increases risk.
Finally, the IPC believes that if the Mechanism for the evolution of SSAD identifies additional categories of requests that could be fully automated, the SSAD must
allow for automation of their processing and the requests must be
automatically processed and result in the disclosure of non-public RDS data
without human intervention if legally permissible.
Intent and wording of this recommendation requires amendment
The IPC supports this Recommendation with the following proposed changes.

Incorporate the clarifications offered by the BC in this document https://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200304/72314f67/EPDPPhase2SLAproposaldetailclarification-0001.pdf into the final EPDP Phase 2 report.

Mirroring a policy recommendation from the RPM WG Initial Report (https://gnso.icann.org/sites/default/files/file/field-file-attach/rpm-phase-1-initial-18mar20-en.pdf), the IPC recommends that the Registry Agreement and Registrar Accreditation Agreement include a provision stating that the contracted party shall not act in such a way as to have the effect of circumventing the purpose of SSAD, e.g. defaulting to denials of disclosure to meet SLAs etc.

Changes regarding priority level 3 (normal requests)
1. Each disclosure request MUST receive a substantive response in 5 business days or less. When it doesn’t, the gateway shall send an automated alert to ICANN Compliance and ICANN Compliance shall investigate without undue delay.
2. SLA enforcement form 1 needs to be strengthened.
a. In addition to requiring that a CP that does not meet its 5 day response target “participate in a review with [ICANN] Compliance to establish the root cause for exceeding the average response time expectation”, ICANN Compliance shall be required to develop a Remedial Plan on the basis of the review. Each Remedial Plan shall be published by the gateway.
3. SLA enforcement form 2 needs to be strengthened.
. Every breach of the 10 business days SLA shall be investigated by ICANN Compliance and result in a SLA Breach Report.
a. The SLA Breach Report shall include: the findings of the investigation; any previous form 1 Remedial Plan developed by ICANN Compliance for the CP in question; and the penalties imposed by ICANN Compliance.
b. The gateway shall publish the SLA Breach Report.
c. To determine potential penalties, in addition to complaint volumes and CP size, ICANN Compliance shall take into account: whether and to what extent the CP had implemented all its previous form 1 Remedial Plan; and all aspects of a CP’s compliance with the requirements of this SSAD policy.
d. The gateway shall without delay send the SLA Breach Report to each requestor whose request did not receive a response within 10 business days during the relevant time period from the CP in question.
e. A breach of the 10 business days SLA is a breach of the RAA, unless ICANN Compliance provides an explanation to the contrary in its SLA Breach Report.
4. Our recommendations for the mechanism by which the SLA targets shall be reviewed are the same as those we make for the Mechanism for the Evolution of the SSAD (Rec 19.)

Changes regarding priority levels 1 and 2
1. Currently, urgent requests are proposed to be addressed in one business day. The IPC raises concern that if an urgent request is made on a Friday, it will not be addressed until three calendar days later. In these urgent cases, the IPC thinks it best to have a 24 hour response time.
2. To avoid misuse of the priority 1 and 2 levels, the report should require evidence. Recommendation 9 only requires the requestor to assert a priority level, whereas Recommendation 8 (see f), under Urgent SAD requests) mentions “requests for which evidence is supplied to show an immediate need for disclosure.” Recommendation 9 should therefore: a. explicitly require the requestor to provide evidence supporting his assertion that a request is a priority 1 or 2; b. provide examples of what evidence would be sufficient for each priority level; and c. if confidential or legally privileged evidence cannot be provided, allow the evidence to be provided in the form of affidavits.
3. The procedure for setting the priority level should be clarified. The following sentence is unclear, as it seems to imply incorrectly that it is the gateway that sets the priority level: “When selecting a priority, the Central Gateway Manager will clearly state the criteria applicable for an Urgent Request and the potential consequences of abusing this priority setting.” The sentence should instead read: “When a requestor sets the priority level of a request as Priority 1 or 2, the Central Gateway will clearly state the criteria applicable for these priority levels and the potential consequences of abusing these priority settings.”
4. For the avoidance of doubt, Recommendation 9 should include this sentence from Recommendation 8: “the use of ‘Urgent’ SSAD Requests is not limited to LEA.”
Finally, this recommendation should include an SLA for the Central Gateway’s uptime, set at an industry standard level such as 99.9%.
No, I wish to continue to the next section
Support intent of recommendation with edits
Preamble: “For the avoidance of doubt, every request does not have to go through an enforcement procedure; the enforcement mechanism MAY, however, be triggered in the event of apparent misuse.” Comment: It should be clarified regarding who can trigger the enforcement mechanism regarding “apparent misuse.” The Centralized Gateway Manager? A Contracted Party? A third-party?

(a) Limiting requested data to only the current RDS data will impose a challenge on brand owners and other third-party requestors. There are a number of reasons it is very important to have the ability to also obtain historical data, for instance to learn the approximate date on which that registrant acquired the domain name (which may differ from the domain’s original creation date by a prior registrant). Accordingly, there should be an option to also obtain historical data that is retained by the Contracted Party upon request.

(b) The “representations” required by this portion of the Recommendation must not be unduly burdensome and should, ideally, be satisfied by a check-the-box list of common reasons for such requests (with a catch-all “Other” checkbox and free text field for stating uncommon reasons). As for the “corresponding purpose and lawful basis for the processing”, the comments set forth pertaining to Preliminary Recommendation #3 “Criteria and Content of Requests” are incorporated here as well.

(c) No comment. We support this criterion.

(d) It is unclear what is meant by the “representation regarding the intended use of the requested data”. If this simply means that the requestor represents that the stated intended use is the actual intended use, then this should be satisfied by a simple checkbox. However, if its meaning is intended to be broader and mean that the intended use must be specifically stated, this seems to be redundant to other parts of the process set out in the recommendations. If the latter is the case, then the representation should be satisfied by a standardized check-the-box list of common intended uses (with a catch-all “Other” checkbox and free text field for stating uncommon uses). Further, the “representation that the requestor will only process the data for the stated purpose(s)” should be satisfied with a simple checkbox.

(e) No comment.

Support intent of recommendation with edits
As an initial matter, same comments as above regarding who/how mechanism is triggered regarding “apparent misuse.”

(a) No comment.

(b) See comments pertaining to Recommendation 10 concerning disclosure of historical data.

(c) No comment.

(d) Comments on logging appear in the Logging section, Recommendation 17.

(e) With respect to the “balancing test”, the comments pertaining to the balancing test set out in Recommendation 6 are incorporated here as well.

(f) The term “reasonable request” as used in this context (as opposed to the disclosure request context) should be further defined so as to avoid any improper denials of requested data and any unnecessary delays in processing the same. This section should also clarify that the “request” in this context is by the data subject itself.

(g) While we do not object to this concept in principle, and agree that such rights are prescribed under certain laws like GDPR, the right to erasure cannot be presented or used as a means of preventing disclosure of data in connection with a reasonable request that has met the applicable balancing test or other criteria for disclosure.

(h) The “privacy policy for the SSAD and standard language (relating to the SSAD) to inform data subjects” should be developed by the SSAD stakeholders and put out for public comment to ensure clarity, accuracy, and neutrality.

(i) It is important that “the nature of legal investigations or procedures” not be limited to criminal investigations by law enforcement or other governmental entities. There are situations where civil investigations may require that requests be kept confidential from the data subject (e.g., where counterfeit goods may be quickly sold or destroyed by a data subject in an attempt at frustrating the enforcement of intellectual property rights). It may be helpful to explicitly confirm this in this section.

Finally, The IPC recommends: that the domain name that is the subject of a disclosure request be locked (using the UDRP definition) during the pendency of a disclosure request; and that any notice to data subjects of disclosure requests not be permitted during the pendency of a disclosure request.
Support intent of recommendation with edits
(a) No comment.

(b) The reference to “ICANN org” as used in this section should be made more specific [“In the event the entity receiving requests makes a determination based on abuse to limit the number of requests a requestor, further, to point b, the requestor MAY seek redress via ICANN org if it believes the determination is unjustified.”] Which part of ICANN Org specifically would have responsibility? ICANN Compliance?

(c) In addition to disclosure relating to “specific domain name[s]” identified in a request, provision should be made for disclosure, upon request, of all domain names owned by the same registrant who is the owner of a specific domain name that is the subject of the initial request about which the Contracted Party to whom the request is directed has such additional information. In addition, EPDP should consider introducing some kind of “trusted requestor” program to expedite responses to similarly-situated requests from a trusted requestor based on pre-defined criteria and use cases. This will help alleviate the cost of examining each request “on its own merits” where the same requestor who has previously demonstrated a pattern of good faith, reasonable, and well-founded requests, submits further requests of a substantially similar nature. Finally, we reiterate our other comments regarding disclosure of historical registration data.
Support intent of recommendation with edits
In general, we support the concept of using appropriate agreements, such as terms of use, a privacy policy and a disclosure agreement to provide rights, duties and obligations concerning access and disclosure of data through SSAD. However, such agreements must be carefully drafted and vetted by the community so that they accurately reflect EPDP policy recommendations and not impose additional obligations or duties or provide imprecise access or disclosure rights. All SSAD stakeholders should be involved in developing these agreements. The EPDP should also clarify how a code of conduct would relate to terms of use and the other agreements discussed in this recommendation, and consider whether all of these agreements could be covered under a single terms of use document.

We recommend the following revised wording of Recommendation 13:

“The EPDP Team recommends that appropriate agreements, such as terms of use for the SSAD, a privacy policy and a disclosure agreement are put in place that accurately reflect the recommendations of the final reports of the EPDP Team. These agreements are expected to be developed and negotiated by all SSAD stakeholders, taking the below implementation guidance into account and any such draft agreements will be published for public comment prior to implementation.”

With respect to recommendations concerning proposed Terms of Use, we would suggest that a standard of mere “misrepresentation” to trigger requestor indemnification should be revised to an “intentional, reckless or willful misrepresentations” standard.

Further we note the text stating “The EPDP recommends, at a minimum, the privacy policy SHALL include: Relevant data protection principles, for example,”. This sentence appears to abruptly cut off - were there supposed to be particular examples listed here?

Further, we note the text stating “Applicable prohibitions Disclosure”. Should this say “Applicable prohibitions on Disclosure”? Please clarify.
Support intent of recommendation with edits
We support the intent of this recommendation but note that the second sentence of Recommendation 14 might create a contradiction with the requirement of the first sentence in cases where the registration data must be retained under law applicable to the requestor for other reasons or for a longer duration not specific to achieving the purpose of original disclosure. Accordingly, we would suggest the following revision to the wording of Recommendation 14:

“The EPDP Team recommends that requestors MUST confirm that they will store, protect and dispose of the gTLD registration data in accordance with applicable law. Requestors MUST retain only the gTLD registration data for as long as necessary to achieve the purpose stated in the disclosure request, unless otherwise required to retain such data for a longer period under applicable law.”
Support intent of recommendation with edits
There needs to be a delineation in costs between the development of the SSAD system and its operational costs. We agree that development costs should be initially borne by ICANN Org and Contracted Parties, but that subsequent operational costs should be covered on a cost recovery basis that may take into account historical costs within reasonable parameters.

EPDP should clarify in this recommendation what it means by “smaller operators” in the context of disproportionately high burdens - it seems to imply contracted parties, but it is unclear. No fees for accreditation or disclosure requests must be so high for any class of user or accreditation applicant so as to circumvent their ability to make meaningful use of the SSAD. Overall, the financial burden on all parties to the system should be equal or at least proportionate. System costs should be a component of audits.

We would also support allocation of ICANN Org budget toward offsetting the costs for maintaining the Central Gateway and in general for setting up and maintaining this system.

We would like further specifics regarding the suggested legal risk fund and why such a fund is necessary as part of the costs of this system. All businesses and systems operate subject to some legal risk, so it is not clear why this system necessitates a special fund for its risks.

Finally, this section refers to “input from ICANN Org concerning the expected costs of developing, operationalizing and maintaining the three different models.” This should be updated now that three models are not being considered.
Support recommendation as written
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The IPC agrees that the SSAD needs to have sufficient audit mechanisms to enable monitoring and compliance with law and with ICANN policy. There might be a drafting oversight in this recommendation since it merely “expects” that auditing is done to ensure compliance, but it does not explicitly recommend auditing contracted parties. IPC formally suggests that Recommendation 18 explicitly recommend to audit contracted parties’ compliance with this policy.
Support intent of recommendation with edits
With the added input from the Belgian DPA that a centralized model is a “better, ‘common sense’ option in terms of security and for data subjects”, the EPDP should complete its work based on such a centralized model. This could eliminate the need for such a mechanism to gradually shift the SSAD toward greater centralization.
This Mechanism, if it exists, must represent the entire ICANN community, and not only the GNSO. It should take into account SSAD users including law enforcement, cybersecurity, intellectual property owners and agents, and other types of end users.

The Mechanism’s remit should be to act unidirectionally toward centralization and automation of all cases possible under the law, and the Mechanism must not be able to unwind centralization established by the EPDP without objective evidence of legal risk. It should have sufficient resources to obtain the legal clarity required to justify the centralization of more use cases over time.

The challenge in developing such a Mechanism is that it must be able to require automation for new request types without that power crossing “the picket fence” or being considered to be policy making under the GNSO’s remit. The challenge associated with creating such a unicorn further evidences that a centralized SSAD is better.
ICANN, the GNSO and EPDP cannot enact policies for ccTLDs, but some of them have followed the example of ICANN and terminated open access to WHOIS. Therefore, we expect that some may want to follow suit again and participate in the SSAD. The EPDP should reflect on the implications and provide explicitly for ccTLD participation.
As noted above, the EPDP should revisit the possibility of a fully or more centralized SSAD model, in light of apparently inconsistent comments on this subject, calling into question whether such an approach would actually be impermissible under GDPR. IPC would strongly prefer a more centralized/automated approach to SSAD that is more reflective of the historical WHOIS system in terms of querying and disclosure of data.
The EPDP must also present a recommendation for a mechanism for obtaining historical data, to the extent such data is retained by Contracted Parties/ICANN. Historical data is often critical to many legitimate third-party purposes for which SSAD is being created, for instance in order to help trace the chain of title of particular domain names which may be relevant in the course of certain legal disputes (e.g. a UDRP or URS case), to cybersecurity measures, or to law enforcement, among other possible reasons.
21
3/22/2020 1:51:10Roland De Meersman
Belgian Association Anti-Counterfeiting
No
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
Support intent of recommendation with edits
b3) We cannot help but notice the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.

b4) Not every high-volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.

If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinionNo opinion
Support intent of recommendation with edits
There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the party seeks the data because its rights have been infringed. This would be like a double sanction on the shoulders of a victim. Therefore, the costs shall be borne by ICANN. Let’s not forget that the more the system will be automatized, the less costly it will be.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more are more numerous.
It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names, and notably those used for the sale and promotion of counterfeit goods.
Those websites are increasingly numerous and often with proven links with transnational organized crime. Several surveys show that nowadays, when a consumer buys a fake product online, most of the times he is himself a victim as he got duped.
Allowing accredited parties to have access to data of domain names involved in the sale of counterfeit goods is the only way to begin to take action against their owner.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
Indeed, GDPR application should not lead to the loss of compelling and vital data (i.e. WHOIS data).

Regarding data accuracy:
While this has been discussed to some level within the EPDP team, it is essential that accuracy of the data held within the WHOIS be addressed.
We strongly support the creation as soon as possible of a small team within the EPDP to consider this further. To expend so much effort and so many resources on ensuring the processing of and access to registrant data without any attempt to ensure its accuracy is unconscionable. This is in line with the views of the GAC and ALAC.
In our increasingly connected world, we should definitely consider the offline world components as equivalent to the online world ones. Besides, it is important that people going to a website, are capable of knowing who the registrant is. It is a matter of Transparency and Trust.
Moreover, protection of the consumer is essential in the online world where the source of the products can easily be hidden. Therefore, having the registration data publicly available would enable consumers to check the trustworthiness of a website in a more reliable way than looking at the website content. Of course, it would be even more useful if the data provided by the registrant is verified.
22
3/22/2020 10:20:37Eirini PatsiIPC memberNo
No, I would like to continue to the next section
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation intent with wording change
Evaluation of the merits of the specific request' (2nd bullet) recommendation to include a decision tree of cases to whether or not to grant data and a certain common request of merits
Support Recommendation intent with wording change
Introduce a specific deadline instead of 'without undue delay' -par.1
Support Recommendation as written
Support Recommendation as written
No, I wish to continue to the next section
Support intent of recommendation with edits
Recommend to consider 'fraud' against public through a phishing attack as included to Urgent SSAD requests. It is crucial to not underestimate financial loss for the public. (Many sources recommend phishing is part of combined financial activities, that can unveil further illegal activities of the actors)
Support intent of recommendation with edits
Most internet and DNS abuse requires a 24/7 responce.
Consider changing the SLA from ' 1 business day' to 24hours.
No, I wish to continue to the next section
Support recommendation as written
Support intent of recommendation with edits
Recommendation to include additional point: 'Must return real' (not anononimed data)
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
Regarding public/individual requests, there should be made a distinction for this type of fees between the public and organisations. The public shall be able to retain access without unbearable costs.
Support recommendation as written
No, I wish to continue to the next section
No opinionNo opinion
Support recommendation as written
Support implementation guidance as written
23
3/22/2020 10:57:09Romain MalletCHANELNo
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
Support intent of recommendation with edits
b3) We cannot help but notice the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.

b4) Not every high-volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.

If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinionNo opinion
Support intent of recommendation with edits
There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the party seeks the data because its rights have been infringed. This would be like a double sanction on the shoulders of a victim. Therefore, the costs shall be borne by ICANN. Let’s not forget that the more the system will be automatized, the less costly it will be.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more are more numerous.
It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names, and notably those used for the sale and promotion of counterfeit goods.
Those websites are increasingly numerous and often with proven links with transnational organized crime. Several surveys show that nowadays, when a consumer buys a fake product online, most of the times he is himself a victim as he got duped.
Allowing accredited parties to have access to data of domain names involved in the sale of counterfeit goods is the only way to begin to take action against their owner.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
Indeed, GDPR application should not lead to the loss of compelling and vital data (i.e. WHOIS data).

Regarding data accuracy:
While this has been discussed to some level within the EPDP team, it is essential that accuracy of the data held within the WHOIS be addressed.
We strongly support the creation as soon as possible of a small team within the EPDP to consider this further. To expend so much effort and so many resources on ensuring the processing of and access to registrant data without any attempt to ensure its accuracy is unconscionable. This is in line with the views of the GAC and ALAC.
In our increasingly connected world, we should definitely consider the offline world components as equivalent to the online world ones. Besides, it is important that people going to a website, are capable of knowing who the registrant is. It is a matter of Transparency and Trust.
Moreover, protection of the consumer is essential in the online world where the source of the products can easily be hidden. Therefore, having the registration data publicly available would enable consumers to check the trustworthiness of a website in a more reliable way than looking at the website content. Of course, it would be even more useful if the data provided by the registrant is verified.
24
3/22/2020 17:46:11Steve DelBianco
ICANN Business Constituency (BC)
Yes
ICANN Business Constituency (BC)
No, I would like to continue to the next section
Support Recommendation intent with wording change
No assurance of Whois data accuracy is enumerated, and this threatens to disrupt the integrity of Whois at the outset. Though neither GDPR nor any other law protects fake data, this report shirks the responsibility of ensuring accuracy as part of an accountable and effective Whois framework.

Based on the Implementation Guidance that concludes Recommendation #1, the EPDP clearly recognizes the importance of accuracy and accountability for accreditation applicants that will be required to present “a business registration number and the name of the authority that issued this number,” along with “information asserting trademark ownership”. A significant proportion of Whois data is inaccurate and the absence of an accuracy and accountability framework for that data set contradicts the principles the EPDP seeks to establish for the SSAD accreditation policy as well as the principles of GDPR itself: as the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with

Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”

While specific suggestions are outlined below, the BC adds here that the EPDP team’s recommendations can be improved by including the concept of an Accredited Entity who is also a Trusted Notifier. Accredited Entities who are also Trusted Notifiers would be subject matter experts that have been additionally vetted to monitor and investigate issues of illegal activity and abuse. Trusted Notifiers would have an established reputation for accuracy, a recognized relationship with the ecosystem and a proven record of following the defined process for requesting access to non-public Registration Data via the SSAD.

Principle d): The BC prefers that disclosure decisions be automated/centralized to the greatest extent possible and limit to the greatest extent possible the number of individualized disclosure decisions being made by individual registry operators and registrars. Further, the BC supports that references to “registrar,” “registry,” and “central gateway manager” be changed to “Controller,” as that is what GDPR requires. Limiting to “Controller” would allow the recommendation to scale according to the ultimate decision on who the “Controller” is in this scenario.

Principle h): The report should define which types of requests could be responded to in an automated manner. For purposes of disclosure, the BC supports automated or quasi-automated (i.e. human review by the central managing authority for provision of required information) access/disclosure decisions in cases of well-founded allegations of abuse (e.g., cybersquatting, phishing, trademark or copyright infringement, etc.), as evidenced in the assertions and supporting materials produced in connection with same/with the disclosure request itself.

Principle i): Does the referred-to code of conduct comply with Art. 40 of the GDPR and will it contain mechanisms which enable the body referred to in Art. 41(1) to carry out the mandatory monitoring of compliance with its provisions by the controllers or processors which undertake to apply it? Further, how is the Accreditation Authority the “authority” on the proper application of data protection laws? The report should clarify.

Principle j): The BC poses the following:
Regarding the definition of eligibility requirements for accredited users, will this be reviewed and revised over time with learnings from the accreditation process? Preliminary eligibility requirements may be unnecessarily exclusive.

Regarding identity credential revocation procedures, there must be an appeal or escalation process enumerated.

Regarding “requirements beyond the baseline listed [above] may be necessary for certain classes of requestors,” these should be available to applicants prior to application.

Principle k): This language should be sharpened to be more specific, if in fact it refers to an appeal or escalation process. Such a mechanism must include due process checks and balances.

Principle l): In addition to accredited authorities being audited for compliance, so should the accreditation provider to ensure compliance with timely and reasonable accreditation grants. The report also should detail how often the audits should occur.

Principle n): The cadence of reports “on a regular basis” should be enumerated.

Principle o): “Abuse of the system” should be defined and differentiated (if applicable) from violation of the code of conduct.

Principle p): Regarding “abuse of the system,” the report should also identify who supervises the accreditation authority in the instance of “abuse” on its part (e.g., over-restrictive granting of credentials or arbitrary revocation of credentials).

Principle q): While the BC appreciates the notion of graduated penalties, again here, there should be included an appeal or escalation process in the event of a dispute over penalties or potential revocation.

Principle r): Will graduated sanctions be enumerated in advance? Will graduated sanctions be uniform across all accreditation authorities? There may be entities seeking accreditation from multiple providers.

Principle t): Again here, an appeal mechanism should be included.

Principle u): The BC poses the following:
Regarding “prevent abuse of data received,” the term “abuse” should be defined.
Regarding “de-accreditation if they are found to abuse use of data,” due process and checks and balances should be required.

Principle v): Regarding a “demonstrable threat to the SSAD,” the BC advises there needs to be a definition and metric so that decisions are objective and not subjective.
Regarding fees, the BC recommends updating the language of that recommendation to read: The accreditation service will be a not-for-profit service that is financially sustainable.

Regarding implementation guidance, the BC offers the following:

a): “Recognized, applicable and well-established organizations” needs definition as it applies to supporting the Accreditation Authority. Also, the recommendation does not identify who would provide “vetting” as it applies to Recommendation j [above].

b): “Information asserting trademark ownership” could be clarified – does this refer to information demonstrating ownership of a trademark by the accredited party or that the accredited party is acting on behalf of a trademark owner (or both)? What kinds of information would this entail? A copy of TM registration / certificate? Power of Attorney or other form demonstrating agency?

d): When the team recommends that “logged data SHALL only be disclosed, or otherwise made available for review,” by whom is the review conducted? Is this part of a formal process? This needs clarification.
Support Recommendation intent with wording change
a): In the definitions section, “public policy task” needs a definition.

b): Wording change: The BC recommends changing “SHOULD” to “MUST.”

b) continued: Regarding the section describing an accreditation procedure, does the EPDP team envision this as any different than the accreditation procedure outlined earlier in the report? Or would this section envision a separate channel for access for government entities (including LEA)? Clarification is needed.

c): Regarding accreditation by countries’ or territories’ government body or its authorized body, does this refer only to national governments? The BC may predict that localized jurisdictional authorities may seek accreditation; exclusive vesting such authority to national bodies may prove bureaucratic and unnecessarily slow for sub-national and other government entities to obtain accreditation. This needs to be carefully considered and clarified.

c) continued: Are cybersecurity authorities “public” or government-sanctioned only? Or would this include private cybersecurity teams?

d): Regarding “country/territory nominated Accreditation Authority,” this too is undefined. Does it refer to nomination by a country/territory body? Would that exempt a city’s police department, for example, or would that department have to queue with others applying to the country/territory government to determine eligibility?

e): Referring to the recommendation that an “accreditation process SHOULD take account of a number of requirements,” are these requirements subject to review or expansion by the community? Does the authority make those decisions independently? This needs clarification and higher prioritization as well.

e) continued: Regarding the recommendation that “The requirements SHALL be listed and made available to eligible government entities,” the BC asks whether they should be made generally available, without pre-determining which entities might be eligible?

e) continued: In the bulleted recommendations, the BC advocates for the following wording changes/additions:
Be subject to graduated penalties and, ultimately, de-accreditation if they are found to violate any of these requirements.
Provide due process mechanisms in review, de-accreditation and graduated penalties processes.

f): Regarding the Accreditation Procedure, will the authorities, or the accreditation scheme, be reviewed by the community from time to time, in case of the need for revisions sourced from the community? The BC recommends this.

f) continued: In the same paragraph describing the Accreditation Procedure, the BC recommends changing SHOULD to MUST.

f) continued: At the end of the list of bullets, the EPDP team recommends that “The accreditation authority reserves the right to update what credentials or other material are required for accreditation.” The BC asks that this recommendation include a provision that proper advance notice is required for changes to requirements and terms.

a): Regarding the recommendation that “Each accreditation authority SHOULD determine an appropriate time limit,” the BC advocates for uniformity of time limits among accreditation providers, in order to lessen user confusion.

c): The EPDP team’s recommendation reads: “Audits SHOULD be conducted by either the data protection authority or by the country/territory designated auditor.” The BC poses the following:
How is a data protection authority vested to perform this kind of audit? Wouldn’t they be performing their own independent reviews of this system pursuant to their obligations to enforce applicable privacy law?
This system would need a mechanism to maintain independence from the accreditation authority so as not to be subject to undue influence.

d): The BC recommends a complaint procedure that not only deals with unauthorized access to or improper use of data, but also a procedure that addresses complaints about the accreditation authority itself.

e): With regard to the following EPDP team recommendations:
“Accreditation is required for a party to participate in the access system (SSAD). Unaccredited parties can make data requests outside the system, and contracted parties should have procedures in place to provide reasonable access.” The BC suggests this be required to be equivalent to the Temp Spec’s reasonable access requirements and appropriate service level agreements.
“Accredited entities will be required to follow the safeguards as set by the disclosing system.” The BC suggests that this requirement track applicable law and not safeguards provided by the disclosing system.
“Disclosure of RDDS data to the type of third parties MUST be made clear to the data subject. Upon a request from a data subject inquiring about the exact processing activities of their data within the SSAD, relevant information SHOULD be disclosed as soon as reasonably feasible. However, the nature of legal investigations or procedures MAY require SSAD and/or the disclosing entity keep the nature or existence of these requests confidential from the data subject. Confidential requests can be disclosed to data subjects in cooperation with the requesting authority, and in accordance with the data subject's rights under applicable law.” Will there exist mechanisms to rectify improper disclosure by the accrediting entity or controller of the existence or nature of a confidential disclosure request?

f): The BC observes the lack of appeal or due process recommendations in this section, and advocates for their inclusion. Further, in the bullet list, “special circumstances” needs definition.
Support Recommendation intent with wording change
Regarding f (request type), the BC observes that this self-designation of priority could be misused.
Perhaps the centralized system can automatically designate priority levels based on the nature of the request (e.g. LEA criminal investigations are flagged as priority, cybersecurity as next highest priority, IP/consumer protection as next highest priority, etc.).
Support Recommendation intent with wording change
At the end of the first bullet (“Registered name holder consent, contract or responses to registered name holders’ requests exercising their right of access”), the BC suggests a closer look at GDPR, which may require access under these circumstances.

Regarding the final bullet (“Assertion of one of these specified purposes does not guarantee access in all cases but will depend on evaluation of the merits of the specific request, compliance with all applicable policy requirements, and the legal basis for the request.”), the BC reflects the comment immediately above -- under some of the enumerated purposes, the GDPR requires disclosure (e.g. Right of Access).
Support Recommendation intent with wording change
Regarding the following recommendation: “The EPDP Team recommends that the response time for acknowledging receipt of a SSAD request by the Central Gateway Manager MUST be without undue delay.” -- the BC urges the EPDP to agree to a more specific and firm timeframe for acknowledging receipt. We suggest a wording change to specify two to four hours and see no reason why acknowledgement of receipt could not be automated like most technological ticketing systems.

Another wording change recommendation: Where the report states “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”, the BC suggests changing the wording to “with a response indicating that the request is incomplete…” Current wording makes it sound like the Central Gateway Manager is sending an incomplete response.
Support Recommendation intent with wording change
● In the first bullet point of this recommendation, which addresses the fact that automated review is not expressly prohibited where legally and technically permissible, the BC suggests it could be helpful to prioritize elaboration on scenarios where automated review would be possible, and further where automated disclosure may be possible. In addition, this should perhaps read “legally permissible and technically feasible for the Contracted Party”.
● Regarding the third bullet, the BC recommends changing “contracted party” to “controller.” This change should be made throughout the document as appropriate.
● With regard to the following: “Are the data elements requested necessary to the requestor’s stated purpose?”, the BC notes this is subjective and not objective review. A statement of necessity, for example, a legal claim, cannot necessarily be assessed by a contracted party. This should be changed to verify that a reasonable statement of necessity has been made.
● The BC notes the following recommendation:
“The Contracted Party MAY evaluate the underlying data requested once the validity of the request is determined under bullet point #4 above. The Contracted Party’s review of the underlying data SHOULD assess at least: Does the data requested contain personal data?”

The BC urges a language change from “MAY” to “MUST” and recommends rewording “under bullet point #4 above,” which is confusing when the document contains multiple bullet points. Further, the EPDP team should add a bullet documenting that if not prevented by applicable law, data MUST be released (GDPR does not prevent disclosure of legal person data).

Regarding the following recommendations, in order:

● “The Contracted Party SHOULD evaluate at least the following factors to determine whether the legitimate interest of the requestor is not outweighed by the interests or fundamental rights and freedoms of the data subject. No single factor is determinative; instead the authorization provider SHOULD consider the totality of the circumstances outlined below:”

The BC reiterates that “authorization provider” should be changed to “controller,” with the change populated throughout.
o “Assessment of impact. Consider the direct impact on data subjects as well as any broader possible consequences of the data processing. Whenever the circumstances of the disclosure request or the nature of the data to be disclosed suggest an increased risk for the data subject affected, this shall be taken into account during the decision-making.”

The BC recommends a language change to include the provision that the controller MUST consider the public interest and legitimate interests pursued by the requestor to, for example, maintain the security and stability of the DNS.

o “Nature of the data. Consider the level of sensitivity of the data as well as whether the data is already publicly available.”

This recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g., legal vs. natural person).

o “Scope of processing. Consider information from the disclosure request or other relevant circumstances that indicates whether data will be [securely] held (lower risk) versus publicly disclosed, made accessible to a large number of persons, or combined with other data (higher risk), provided that this is not intended to prohibit public disclosures for legal actions or administrative dispute resolution proceedings such as the UDRP or URS.”

The BC is unclear on how combination with other data presents a higher risk. The EPDP team should clarify.

● “Reasonable expectations of the data subject. Consider whether the data subject would reasonably expect data to be processed/disclosed in this manner. Whenever the circumstances of the disclosure request or the nature of the data to be disclosed are material to the legal, efficient, and transparent operations of the DNS, a reasonable expectation by the data subject to preserve these objectives should be assumed.

o “Status of the controller and data subject. Consider negotiating power and any imbalances in authority between the controller and the data subject.”

The BC is unsure how this is relevant, when it is known that the disclosing party, under the proposed system, will be a registry operator or registrar. The EPDP team should clarify.

o “Legal frameworks involved. Consider the jurisdictional legal frameworks of the requestor, Contracted Party/Parties, and the data subject, and how this may affect potential disclosures.”

The BC submits that if no applicable law would prohibit disclosure, then disclosure should be mandatory.

o The BC recommends the addition of the following language to the end of this bullet list:

Recognition of human rights impacts. Consider Article 17 of the Universal Declaration of Human rights, that states (1) Everyone has the right to own property alone as well as in association with others. (2) No one shall be arbitrarily deprived of his property. Consider Article 27, concerning the “right to the protection of the moral and material interests resulting from any scientific, literary or artistic production of which he is the author.”

● Finally, the BC reiterates this section of its input regarding Recommendation 1: While specific suggestions are outlined below, the BC adds here that the EPDP team’s recommendations can be improved by including the concept of an Accredited Entity who is also a Trusted Notifier. Accredited Entities who are also Trusted Notifiers would be subject matter experts that have been additionally vetted to monitor and investigate issues of illegal activity and abuse. Trusted Notifiers would have an established reputation for accuracy, a recognized relationship with the ecosystem and a proven record of following the defined process for requesting access to non-public Registration Data via the SSAD.

● The BC recommends the following wording changes to the end set of recommendation #6:

o Where the recommendation reads: “If, based on consideration of the above factors, the Contracted Party determines that the requestor’s legitimate interest is outweighed by the interests or fundamental rights and freedoms of the data subject, the request may be denied. The rationale for the denial MUST be documented and logged and MUST be communicated to the requestor, with care taken to ensure that no personal data is revealed to the requestor within this explanation.”

The BC believes such a denial must be appealable, with documentation provided to the entity seeking the data regarding procedures for appeal.

o Where the recommendation reads: “The application of the balancing test and factors considered in bullet point #5 SHOULD be revised as appropriate to address applicable case law interpreting GDPR, guidelines issued by the EDPB or revisions to GDPR that may occur in the future.”

The BC believes such revisions should be subject to community review.

o In the section labeled Implementation Guidance, the BC recommends the following wording changes:

● An interest is [DELETE generally] [ INSERT deemed ] legitimate so long as it can be pursued consistent with data protection and other laws.
● Examples of legitimate interests include: (i) [DELETE enforcement] [INSERT establishment, exercise or defense] of legal claims;
Support Recommendation intent with wording change
The BC recommends the following wording changes:

1. The Central Gateway Manager MUST confirm that all required information as per preliminary recommendation #3 ‘criteria and content of requests’ is provided and that the request meets the criteria established in these policy recommendations (and is confirmed during the implementation phase) to qualify [DELETE as] [INSERT for] an automated disclosure request.

2. Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor [INSERT indicating that the request is incomplete,] [DELETE with an incomplete request response, ]detailing which required data is missing, and provide an opportunity for the requestor to amend its request.

Finally, where the EPDP team recommends: “With respect to disclosure requests that would be sent to a Contracted Party for manual evaluation, a Contracted Party MAY request the Central Gateway to fully automate all, or certain types of, disclosure requests. A Contracted Party MAY retract or revise a request for automation that is not required by these policy recommendations at any time.”, the BC:

agrees with the Belgian DPA’s input to ICANN Org (see https://www.icann.org/news/blog/icann-meets-with-belgian-data-protection-authority ) regarding its preference for a centralized model as a better, “common sense” model -- the BC supports a centralized system; and

believes there should be a notice period before retraction or revision would go into effect. Otherwise this could unduly prejudice requestors who are anticipating an automated process.

Under implementation guidance, the BC asserts the following:

As cited, “The EPDP Team expects that the following types of disclosure requests can be fully automated (in-take as well as response) from the start:

Requests from Law Enforcement in local or otherwise applicable jurisdictions.”

Clarification is needed here regarding “local or otherwise applicable jurisdictions.” Is this local to the registry, registrar, CGM, ICANN, registrant? All of the above?

The BC advocates for the following to be added to this bulleted list:

Requests for disclosure of data not prohibited for release by applicable law.

Finally, where the EPDP says: “The EPDP Team will further consider if other types of disclosure requests can be fully automated Day 1. Over time, based on experience gained and/or further legal guidance, the Mechanism for the evolution of SSAD is expected to provide further guidance on which types of disclosure requests can be fully automated.”, the BC asserts the following:

It would be helpful to also automate responses to trademark or copyright owners or their agents who demonstrate ownership of IP rights (and agency, if needed) and provide evidence supporting a reasonable need to investigate a domain for cybersquatting, trademark or copyright infringement, phishing, or related activity involving potentially unauthorized use of the requestor’s (or their client’s) property.

“Over time” should be defined more precisely. Perhaps a one-year timeframe is appropriate.
Yes
Support intent of recommendation with edits
The BC offers the following input regarding the following recommendations:

For the Central Gateway Manager:

a): …the Central Gateway Manager MUST provide, [INSERT within 24 hours,] an opportunity for the requestor to amend and resubmit its request.

b): Regarding “the responsible Contracted Party,” the EPDP team should clarify how this is determined. Is it sent to the registrar or registry? Both? At the option of the requestor?

c): Regarding “the Central Gateway Manager MAY provide a recommendation to the Contracted Party whether to disclose or not. The Contracted Party MAY follow this recommendation.”, the BC respectfully inquires about how and when would this be determined and on what basis? Inconsistent CMG replies could be viewed as prejudicing/advantaging certain parties which could be problematic for the system as a whole. Further, this appears to be the insertion of another balancing test, which the BC does not favor. At the very least, this additional layer of “recommendation” requires enhanced transparency: if the CGM’s recommendation to the CP is to not disclose, then this recommendation, along with a rationale, must be shared with the requestor.

For Contracted Parties:

a): The BC recommends the following wording change: MUST provide a disclosure response [DELETE without undue delay] within 72 hours.

b): Where the recommendation reads: “Additionally, in its response, the entity receiving the access/disclosure request MUST include information on how public registration data can be obtained.”, the BC finds that responses should also describe how to appeal a determination or re-submit a request in order to address reasons for denial, and describe whether/how applicable law prohibits the disclosure of data.

f) With regard to urgent SSAD requests: Where the recommendation details “the criteria to determine...an urgent request”, the potential economic harm and risk to livelihoods that result from phishing attacks, credit card fraud, and other crimes that threaten financial devastation and lead to SSAD requests should be accounted for. Additional criteria like “devastating financial harm” should be considered.

e): Where the recommendation reads: “Contracted Parties MUST maintain a dedicated contact for dealing with Urgent SSAD Requests which can be stored and used by the Central Gateway Manager, in circumstances where an SSAD request has been flagged as Urgent. Additionally, the EPDP Team recommends that Contracted Parties MUST publish their standard business hours and accompanying time zone in the SSAD portal (or in another standardized place that may be designated by ICANN from time to time.”, the BC points out that there are provisions in the RAA about 24/7 availability of abuse mitigation contacts and proper resourcing. Why not the same for “urgent” requests if they involve threat to human life or other imminent harm?

Further in the recommendations under #8, the EPDP team writes: “If a requestor is of the view that its request was denied erroneously, a complaint MAY be filed with ICANN Compliance. ICANN Compliance should be prepared to investigate complaints regarding disclosure requests under its enforcement processes.” The BC strongly believes that language should be added here giving ICANN Compliance authority under the Registrar Accreditation Agreement to enforce. Further, language needs to be added about resources afforded to Compliance to handle this, and a timeline for investigations. Otherwise, they will languish.

Implementation guidance:
b) The CGM’s “incomplete request response” needs to be issued in a timely manner -- the BC suggests within 24 hours.
Support intent of recommendation with edits
● Where the EPDP team writes: “Priority is a code assigned to requests for disclosure that contain agreed to, best effort target response times.”, the BC asks what if best efforts repeatedly fall short of target response times? Is there a remediation path, and can it be mandated?
● Regarding: “In Phase 1, registrar response targets for SSAD Priority 3 requests will be five (5) business days.”, the BC advocates an at maximum three (3)-day response time, noting that Friday and weekend attacks are already a common practice designed to exploit response downtimes.
● Regarding: “In Phase 2, Contracted Party compliance targets for SSAD Priority 3 requests will be ten (10) business days.”, the BC finds this to be far too long and advocates for a three (3)-day response time.
● Where the EPDP team recommends: “The SSAD will calculate Contracted Party’s mean compliance target every 3 months. If the Contracted Party’s mean compliance target exceeds ten business days, Contracted Party will be subject to compliance enforcement.”, the BC finds that language needs to be added to the RAA to allow Compliance to enforce. Similarly, it is insufficient to suggest only a Compliance inquiry for the failure to provide a rationale for missing the five-day target in Phase 1 and highlights the need for enforcement measures and procedures.
● Regarding: “Small Team recommends SSAD response times and associated statistics be as transparent as legally permissible in order to improve the SSAD and keep the community informed.”, the BC favors elucidation of a publication schedule in order to improve transparency and accountability. We recommend at least every 90 days.
● Finally, where the EPDP team writes: “These requests MAY be automatically processed and result in the disclosure of non-public RDS data without human intervention if legally permissible.”, the BC requests additional detail be added. Any requests that can legally be automated MUST be. Further, who decides whether/ when such automated disclosure is legally permissible?
Please refer to the BC’s reply to Recommendation 9 question 25 for specifics.
Support intent of recommendation with edits
● Regarding: “For the avoidance of doubt, every request does not have to go through an enforcement procedure; the enforcement mechanism MAY, however, be triggered in the event of apparent misuse.”, this could be clarified regarding who can trigger a misuse enforcement mechanism (e.g., the Central Gateway Manager, a third party, etc.).
Support intent of recommendation with edits
● Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”, the BC repeats that this could be clarified regarding who can trigger a misuse enforcement mechanism (e.g., the Central Gateway Manager, a third party, etc.).
● f): The BC recommends additional language, as follows: “MUST disclose to the Registered Name Holder (data subject), on reasonable request [INSERT by the data subject] , confirmation of the processing of personal data relating to them, per applicable law;”. The BC, however, would consider an exemption to this language in the event of sensitivity of law enforcement investigations.
Stated another way, a “right to erasure” should not be used to mask a fraudulent or criminal registrant. A criminal made aware of a request for personal data cannot serve as a blanket open door to erasing that data, as it would seriously impact law enforcement actions.
● The BC further recommends the addition of an item j in the alphabetized list, which would read: MUST disclose data where such disclosure is not prohibited by or required by applicable law.
Support intent of recommendation with edits
● a): The term “appropriate action” needs definition, including the enumeration of graduated penalties.
● 4): This recommendation needs to be re-written. As written, a controller failing SLAs for its own reasons would penalize the submitter, who may not be acting in an abusive way.
● Where the EPDP team writes: “As with other access policy violations, abusive behavior can ultimately result in suspension or termination of access to the SSAD.”, the BC is concerned this allows too much latitude for termination. It would be prudent to include graduated penalties vs. the “cliff” of sudden termination, similar to how ICANN warns a registrar prior to revoking their accreditation.
● Regarding the following: “In the event the entity receiving requests makes a determination based on abuse to limit the number of requests a requestor, further, to point b, the requestor MAY seek redress via ICANN org if it believes the determination is unjustified.”, more specificity is required regarding WHERE within ICANN org relief can be pursued. Further, the RAA should be amended to detail enforcement measures.
● Regarding the footnote that reads: “The EPDP Team expects implementation to reasonably determine how many may be submitted at a time and consistent with the Query Policy.”, the BC suggests following UDRP rules where, if it can reasonably be argued that there is common ownership of domains at issue, there is no limit to joinder.
Support intent of recommendation with edits
● Overall, the principles and disclosures listed under “Policy for SSAD Users” should be mirrored and made clear to registrants in registrant agreement as required by GDPR and other applicable laws.
● The BC applauds giving consideration to RAA updates in order to ensure compliance with the recommendations.
● Regarding agreements for SSAD users, the BC asks the EPDP team to consider whether or not such an agreement would be redundant to the code of conduct and other agreements.
Support recommendation as written
Support intent of recommendation with edits
● Where the EPDP team writes: “The subsequent running of the system is expected to happen on a cost recovery basis whereby historic costs may be considered.”, the BC asks for clarification on the parameters of “historic costs.”
● Regarding: “Similarly, some of the cost of running the SSAD may be offset by charging fees to the users of the SSAD.”, fees, if charged, should be based strictly on a cost recovery model.
● The BC notes that fees may violate data privacy laws that prevent companies from selling personal information -- the EPDP team should take care in this regard.
● The BC agrees that “The SSAD SHOULD NOT be considered a profit-generating platform for ICANN or the contracted parties.” However, the statement that “Funding for the SSAD should be sufficient to cover costs, including for subcontractors at fair market value and to establish a legal risk fund.” is vague. A legal risk fund seems excessive.
● Regarding: “The EPDP Team also recognizes that the SSAD fee structure may need to be reviewed over time.”, the BC recommends adding language about frequency of reviews and by whom.
Support intent of recommendation with edits
● The EPDP team writes: “This automation allows for efficient queue management on the discloser’s side and assists in ensuring the principal (sic) of "predictability" is met.” The BC advises that predictability is met only if there’s a communication to the requestor outlining timing expectations. Otherwise, requestors are left uninformed.
● Where the EPDP team recommends: “These requests MAY be automatically processed and result in the disclosure of non-public RDS data without human intervention.”, the BC believes, again, that any requests that can be responded to in an automated manner MUST/SHOULD be.
Support Recommendation with Edits ● Regarding: “Logs MUST be retained for a period sufficient for auditing and complaint resolution purposes, taking into account statutory limits related to complaints against the controller”, the BC advises the retention period must be sufficiently long, at least at first, to accommodate all parties’ adoption to the system and to support “evolution” of automation efforts.
● Where the EPDP team recommends that “Disclosure decisions including a written rationale must be stored and put in escrow so it can be accessed by ICANN and the contracted parties in case of objections or legal claims raised to support a legal defense.”, the BC believes this also should include the same latitude for compliance purposes by ICANN, such as responding to complaints, auditing contracted parties, and/or enforcing against parties not meeting their disclosure obligations.
● The BC recommends further that data to measure disclosure/non-disclosure rates (along with decisional rationale) MUST be logged and archived, that data MUST be analyzed and measured, then audited and publicly reported (after ensuring personal information is removed).
Support intent of recommendation with edits
● Regarding: “If ICANN outsources the accreditation authority function to a qualified third party, the accrediting authority MUST be audited periodically to ensure compliance with the policy requirements as defined in the accreditation preliminary recommendation.”, the BC recommends audits yearly for the first three years, then every two years following. We recommend the same for audit frequency of identity providers.
● In terms of auditing the Accreditation Authority, if ICANN org is not the authority, would the authority be required to audit governmental entities, or would any authority be exempt from auditing governmental entities?
● The BC suggests an audit of Controllers to ensure proper disclosures -- e.g., no controllers that systematically deny or ignore requests through SSAD.
Support intent of recommendation with edits
The BC advises that any working group “controlling” the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
25
3/23/2020 0:33:47Marc Van den Broeck
PRE-DARPA in BSD resources in address space NOT EQUAL TO "DOMAIN" as IANA/ICANN/ gTLD designs contributor as INDUSTRY STOCK DNSSEC ON ROOT FAILS g.gtld-servers.net serial (1584889483)
Yes
AS Company And Person off Future Systems bvba BE the register in 2008 off the generic 3th ""<country us-ascii 2 >""".<dot>"""==>zone ==>overrulles by

beside that i inform based on experience u have and can be checked based on 3 ussues
NSA that asks to be hacked is never the people globally sees as criminalls and "hackers"
NSA calls DARPA i know DARPA ,but we never as DARPA calls the '80s,90s closed non access by any so called "what i need to do for best pgrammer", as i receive due manny portals that now are complete not where i comminocate but by@vdnm2 which was a irc they serialized it from 1998 in 2012 as future@futsys.be this domain is iana registry due Tucows ,2008 iana did a register in dnsbelgium.be, 2 issues,first as rfc approved accept by company and in person is the whois my iana guarantee,as i pay yearly for operations,but the domainname stays ,i see now registrars in explaining from domain selling with renewall
that's trading in extensions a domain u own the domainname with domain as guarabtic it was the com crisis but the solution 2008 cretaed so far that ISP on ripe suddenly without any approval made a PTR to mail.futsys.be as excuse for else your mail wouldn't work,
and this is not tracking byt by google futsys.be gave not sites,but in web a fraglent off my private account in sending a message, that's not possible unless the site runs on a vm based registrar,and Combell.be,nl,com,is such what cnames in nl to com creates but this is dnsbelgium as assigned by iana on based off contract in faith,IANA Inc doesn't appear today they gave a VAT off belgium,but they are in provision in frif AS can operate in a address pool as company in BE My question how does that match if the company is in LLC?, so i file in ripe as betflix streamed over akamai ,then AS /24 and thats ok, send back saying the announcement on root is for AS not confirm , reply i had to use a ns for delegation, so now 2 negative advice closed here iana /icann think what i try with NSA false positives is not election clintion,but Defense off arpa runs in reverse
No, I would like to continue to the next section
Significant change required: changing intent and wording
in full dnssec routerdomain commes on unbound in as 5.in-addr.arpa==>signs by header nc the sig as key fcretaes the rrsig of soa header and pushes findkey in state secure itself by com as sec
info is here criticall due it refers against validator:<content>
unbound:,info:validator:SUPER_Sub signed in trust as insec by rrsig out soa{ domain *.vmx3550.com) Super_sub means it is on right a domain asvmx3550.com is child in rdns off a UP but on rdns, , which I take serious,and if it's no issue, I push something that is not some ducky,i will respect public but if private claims I don't respect Private as Company this is execute in word and code target as sinleton hope you understand mathmatics what the effect gives
Recommendation should be deleted
document is html/here you refer sections that are set in json fields out DOM but access from parsing in html wich is service worker in html only possible on <div class= refering sw:as a .js but this is iframe as document without any way to accept this is what i know,question is does they think i care off angular copyright in scrto by google,godady,mircrosoft and anymore?if i can break 2 browsers same system that they collapse litterly, as devops,microsoft HQ Amsterdam,and Ireeland oakland yard, as i stay in arled but the border is long passed zero days ,are only in"cloud" events, if "cloud" wants can push out -"-+"cloud"+- in polar,as cloud sells east-west Canada AI pokemon go was 100% says enough how users behave ,but as i'm crazy but Hawkings gave a message in brains,we debate off issues and problems but take the cause off the problem out and do invention the species that think being above natyre is religiongof science nort south is what protects kosmic radioation, else maybe restudy the 1970's BEL-LABS 6 minutes duration because they worked without sequence time is extreme imprtant that's why trans-atlantic is on south off cable the glass in light compensate delays, eartg gas during its rotation off year also in digonal insecentiql exis you don't think this matters but the reason south is is what north hits US solar in lights out you run in fooling a IP but that IP you fool must TIME ,latency off 1second, suoergateways, what in foolish you try ,put all as dumb screen,,if I take in H5 you believe i stay in esxii, isee in the IPMI what i must , vlan1
Yes
26
3/23/2020 1:28:19ChunKuang WeiIndividualNo
No, I would like to continue to the next section
No opinion
Support Recommendation intent with wording change
Question 1:
According to Section “Accreditation of governmental entities” in Preliminary Recommendation #2 that “Whether an entity should be eligible is determined by a country/territory nominated Accreditation Authority. This authoritymay be either a countries’/territories’ governmental agency (e.g. a Ministry) ordelegated to an intergovernmental agency,” could there be any explanation or examples of the situation where an intergovernmental agency would be suggested for Accreditation Authority by a country/territory?
Question 2
Accreditation Authority plays a critical role by confirming and verifying the identity of the disclosure requestor before any access procedure resumes. Due to the fact that SSAD copes with the distribution of highly-sensitive personal data, and that the structures of administrative agencies vary from country/territory to country/territory, we hence encourage governments around the world to assign their official administrative agency as their Accreditation Authority.
No OpinionNo OpinionNo opinionNo opinionNo opinion
No, I wish to continue to the next section
No opinionNo opinion
No, I wish to continue to the next section
No opinionNo opinion
● f): The BC recommends additional language, as follows: “MUST disclose to the Registered Name Holder (data subject), on reasonable request [INSERT by the data subject] , confirmation of the processing of personal data relating to them, per applicable law;”. The BC, however, would consider an exemption to this language in the event of sensitivity of law enforcement investigations.
No opinion
● 4): This recommendation needs to be re-written. As written, a controller failing SLAs for its own reasons would penalize the submitter, who may not be acting in an abusive way.
No opinionNo opinionNo opinion
● Regarding: “Similarly, some of the cost of running the SSAD may be offset by charging fees to the users of the SSAD.”, fees, if charged, should be based strictly on a cost recovery model.
Support recommendation as written
As noted in Initial Report that (1) “the EPDP Team expects that aspects of the SSAD such as intake of requests, credential check, request submission validation (format & completeness, not content) could be automated,” that (2) “The SSAD MUST allow for the automation of an immediate and synchronous response ... such responses include a "ticket number" or some kind of unique ID to allow for future queries (status, updates, deletion, etc.),” these conducts not only fulfill the majority’s expectations of an automated system and the providing of an unified online Portal, but also guarantee the predictability of the process of disclosure request to a certain degree as well as the efficiency of crime prevention and trademark maintenance by law enforcement agencies and trademark holders. With these efforts, we foresee a win-win situation reached between ICANN and the governments around the world, and a force of stabilization introduced to the order of the Internet.
No, I wish to continue to the next section
No opinionNo opinionNo opinionNo opinion
27
3/23/2020 2:33:11Carole TRICOIRECompanyNo
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
Support intent of recommendation with edits
No opinionNo opinion
Support intent of recommendation with edits
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more and more numerous.
It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names, and notably those used for the sale and promotion of counterfeit goods.
Those websites are increasingly numerous and often with proven links with transnational organized crime. Several surveys show that nowadays, when a consumer buys a fake product online, most of the times he is himself a victim as he got duped.
Allowing accredited parties to have access to data of domain names involved in the sale of counterfeit goods is the only way to begin to take action against their owner.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
Indeed, GDPR application should not lead to the loss of compelling and vital data (i.e. WHOIS data).

Regarding data accuracy:
While this has been discussed to some level within the EPDP team, it is essential that accuracy of the data held within the WHOIS be addressed.
We strongly support the creation as soon as possible of a small team within the EPDP to consider this further. To expend so much effort and so many resources on ensuring the processing of and access to registrant data without any attempt to ensure its accuracy is unconscionable. This is in line with the views of the GAC and ALAC.

In our increasingly connected world, we should definitely consider the offline world components as equivalent to the online world ones. Besides, it is important that people going to a website, are capable of knowing who the registrant is. It is a matter of Transparency and Trust.
Moreover, protection of the consumer is essential in the online world where the source of the products can easily be hidden. Therefore, having the registration data publicly available would enable consumers to check the trustworthiness of a website in a more reliable way than looking at the website content. Of course, it would be even more useful if the data provided by the registrant is verified.
28
3/23/2020 3:22:09David SaussinanLegal director Yes
UNIFAB - Union des Fabricants
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
Stated another way, a “right to erasure” should not be used to mask a fraudulent or criminal registrant. A criminal made aware of a request for personal data cannot serve as a blanket open door to erasing that data, as it would seriously impact law enforcement actions.
Support intent of recommendation with edits
● Where the EPDP team writes: “As with other access policy violations, abusive behavior can ultimately result in suspension or termination of access to the SSAD.”, the BC is concerned this allows too much latitude for termination. It would be prudent to include graduated penalties vs. the “cliff” of sudden termination, similar to how ICANN warns a registrar prior to revoking their accreditation.
No opinionNo opinion
Support intent of recommendation with edits
● The BC notes that fees may violate data privacy laws that prevent companies from selling personal information -- the EPDP team should take care in this regard.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.

As there was no possibility to comment on Recommendation #17, here are our proposed edits/changes to that recommendation:

Regarding: “Logs MUST be retained for a period sufficient for auditing and complaint resolution purposes, taking into account statutory limits related to complaints against the controller”; we advise the retention period must be sufficiently long, at least at first, to accommodate all parties’ adoption to the system and to support “evolution” of automation efforts.

Where the EPDP team recommends that “Disclosure decisions including a written rationale must be stored and put in escrow so it can be accessed by ICANN and the contracted parties in case of objections or legal claims raised to support a legal defense.”; we believe this should include for compliance purposes by ICANN, such as responding to complaints or auditing contracted parties.
We further recommend that data to measure disclosure rates MUST be logged and archived, that data MUST be analyzed and measured, then audited and publicly reported.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Whatever mechanism is chosen, we strongly advocate for the GAC and SSAC to be fully involved.
N/AN/AN/A
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more are more numerous.
N/A
It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names, and notably those used for the sale and promotion of counterfeit goods.
Those websites are increasingly numerous and often with proven links with transnational organized crime. Several surveys show that nowadays, when a consumer buys a fake product online, most of the times he is himself a victim as he got duped.
Allowing accredited parties to have access to data of domain names involved in the sale of counterfeit goods is the only way to begin to take action against their owner.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
Indeed, GDPR application should not lead to the loss of compelling and vital data (i.e. WHOIS data).

Regarding data accuracy:
While this has been discussed to some level within the EPDP team, it is essential that accuracy of the data held within the WHOIS be addressed.
We strongly support the creation as soon as possible of a small team within the EPDP to consider this further. To expend so much effort and so many resources on ensuring the processing of and access to registrant data without any attempt to ensure its accuracy is unconscionable. This is in line with the views of the GAC and ALAC.
In our increasingly connected world, we should definitely consider the offline world components as equivalent to the online world ones. Besides, it is important that people going to a website, are capable of knowing who the registrant is. It is a matter of Transparency and Trust.
Moreover, protection of the consumer is essential in the online world where the source of the products can easily be hidden. Therefore, having the registration data publicly available would enable consumers to check the trustworthiness of a website in a more reliable way than looking at the website content. Of course, it would be even more useful if the data provided by the registrant is verified.
29
3/23/2020 3:29:02Marie Pattullo
AIM - European Brands Association
Yes
AIM - European Brands Association
No, I would like to continue to the next section
Support Recommendation intent with wording change
While fully supporting the premise that there be an accreditation policy for SSAD users, we would prefer more clarity on the Identity Providers. For example, for trade mark issues, given its global mandate and access to trade mark registries/databases, we strongly advocate that this task should fall to WIPO.

Under “implementation guidance”, we believe that “information asserting trade mark ownership” should be clarified to ensure that service providers and/or lawyers acting on behalf of trade mark owners should also be eligible for accreditation.
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national Data Authorities have the mandate to “audit” their national Law Enforcement Authorities. We would suggest that para c, auditing, should read “Audits should be conducted by the auditor designated by the applicable national / regional law”.
No OpinionNo Opinion
Support Recommendation intent with wording change
A reasonable time limit for sending the acknowledgment of receipt should be provided, e.g. 2 to 4 hours.
Support Recommendation intent with wording change

1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible for the Contracted Party and should be the preferred action for urgent requests as set out in recommendation 9.
4. If the CP decides that “the answer to any of the questions is no” and thus denies the request, there must be the possibility to appeal, given that this will by default be a subjective decision.
5. Assessment of impact:
• While of course impact on data subjects ought to be considered, this should be extended to also consider public interest (e.g. consumer protection, the security of the DNS etc.) well as impact on the requestor (right to property etc.).
• Nature of the data: if this is for a legal, and not natural, person then the data should be disclosed, given that data for legal persons does not fall within the GDPR. We also note that when it is obvious that there is an engagement in commercial activities (i.e. the site linked to the domain name contains product offers), the data should also be disclosed, to protect market transparency and respect the interests of both consumers and competitors, given that in commercial relations the GDPR is not applicable, whatever the legal form of the trader.
• Reasonable expectations of the data subject: complying with the law, e.g. not disrupting the security of the DNS or trying to mislead or dupe consumers, is clearly “reasonable” and this should be specified.
• Requestors also have “interests or fundamental rights and freedoms”, including the right to property. This should form part of the balancing equation.
• If the CP denies the request, which by default will be a subjective decision, there must be a possibility to appeal.
• Implementation guidance: “an interest is deemed legitimate so long as...”. “Examples... include establishment, exercise or defence of legal claims”.
Support Recommendation intent with wording change
Implementation guidance: add “As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents”.
No, I wish to continue to the next section
Support intent of recommendation with edits
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also has the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
• Response targets for priority 3 requests are far too long for trade mark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the target is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.
• It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5 day target in Phase 1, nor that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
Support intent of recommendation with edits
No opinion
Support recommendation as written
No opinionNo opinion
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
The Contracted Parties/Central Gateway Manager should also be regularly audited, not least so as to be able to identify repeat cases of unsubstantiated denials or non-response.
No opinion
Whatever mechanism is chosen, we strongly advocate for the GAC and SSAC to be fully involved.
Support implementation guidance as written
Data accuracy: while this has been discussed to some level within the EPDP Team, and some questions have been posed to Bird & Bird, it is essential that accuracy of the data held within the WHOIS be addressed. We strongly support the creation of a small team within the EPDP as soon as possible to consider this further. To expend so much effort and so many resources on ensuring the processing of and access to registrant data without any attempt to ensure its accuracy is unconscionable. This is inline not only with the views of the BC and IPC, but also the GAC and ALAC.
30
3/23/2020 4:43:02Bota OanaNexperteam B.V.YesNexperteam B.V.
No, I would like to continue to the next section
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
A wording modification recommendation is required to avoid any confusion. The intent of the WG will not be changed.
Point b) should read “MUST return data or subset thereof which is current at the time a request is processed”
Rationale:
This modification is necessary to make it clear that the disclosed data may change after the disclosure has been made. If no locking measures have been applied such as in the case of a UDRP, the RNH remain free to operate any change to the RDS data for their domain name.
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support recommendation as written
No opinion
31
3/23/2020 4:59:40Mark Wilson
Business Constituency member
No
No, I would like to continue to the next section
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation intent with wording change
Second bullet "evaluation of the merits of the specific request"
Recommend that the final policy should include a matrix table to define use-cases of common requests, the merits behind and if the request should be granted or refused
Support Recommendation intent with wording change
Paragraph 1 "without undue delay"
Recommend that SLAs should be introduced to ensure overall SLAs are maintained
Support Recommendation as written
Support Recommendation as written
No, I wish to continue to the next section
Support intent of recommendation with edits
Urgent SSAD Requests section f)
Urgent request criteria should include "the imminent threat of consumer financial loss", such as in the case of an active Phishing attack. The impact of these financial losses to consumers cannot be underestimated and in many cases can be a life-changing event that we all have a duty to address
Support intent of recommendation with edits
"Urgent Request SLA of ""1 business day""
Recommend changing this SLA to ""24 hours"" as the request criteria for urgent requests would not keep to convenient business hours. The internet and DNS Abuse occurs 24/7 and the SLAs for responses should match this."
No, I wish to continue to the next section
Support recommendation as written
Support intent of recommendation with edits
"i) Confidentiality of disclosure requests
In order for this to be effective, the definition of ""confidential requests"" versus non-confidential requests is needed, possibly linked to defined purpose of each request
Recommend an additional point after Point b)
New Point) MUST return real data (no anonomized data);"
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
Support recommendation as written
No, I wish to continue to the next section
No opinionNo opinion
Support recommendation as written
Support implementation guidance as written
32
3/23/2020 6:11:12MullerHermes International No
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.

Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”

Support intent of recommendation with edits
● Regarding the footnote that reads: “The EPDP Team expects implementation to reasonably determine how many may be submitted at a time and consistent with the Query Policy.”, the BC suggests following UDRP rules where, if it can reasonably be argued that there is common ownership of domains at issue, there is no limit to joinder.
No opinionNo opinion
Support intent of recommendation with edits
Regarding: “The EPDP Team also recognizes that the SSAD fee structure may need to be reviewed over time.”, the BC recommends adding language about frequency of reviews and by whom.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more are more numerous.
No clear rules for WHOIS redaction for legal entities and natural entities:
We think that the GDPR WHOIS redaction is inconsistently enforced across different providers and there is no clear distinction for redactions for legal entities and natural entities.
The spirit of GDPR is to protect individual’s privacy but the majority of the registrars hide all WHOIS which we don’t believe was adequate. ICANN should, at the very least, have appropriate/consistent guidance for WHOIS disclosure policy and a policy for different WHOIS data displays – differing between commercial use of the domain name and personal use of the domain name as well as legal entities versus natural entities – as this can affect our decision when taking action if we can see a domain name is official or likely registered by a legitimate business. This can also help brand owners to verify any potential affiliation internally and help enforcement agencies to form an appropriate takedown strategy.

The Data accuracy is fundamental to fight against malicious use of WHOIS and natural person protective rules from GDPR : No assurance of Whois data accuracy is enumerated, and this threatens to disrupt the integrity of Whois at the outset. It is essential that accuracy of the data held within the WHOIS be addressed.
Thus, if the ICANN and its partners would require holders of NDDs used for commercial purposes to identify and register as such (as companies or individual persons with a commerciale activities) it will at least reduce the number of counterfeits seller which can obtain a domain name and it will increase and facilitate the obtention of accurate information in the WHOIS.

Though neither GDPR nor any other law protects fake data, this report shirks the responsibility of ensuring accuracy as part of an accountable and effective Whois framework. A significant proportion of Whois data has been and remains inaccurate.

Invalid WHOIS claim no longer available to tackle maliciously registered domains:
We cannot prove that a domain is registered with invalid WHOIS, as the data is redacted.
It was always counterfeiters’ practice to register domain names with invalid WHOIS; ICANN allowed for domain reports based on Invalid WHOIS that would prove registrant’s malevolence. Right now, since WHOIS is hidden/redacted, we have no longer option to report it based on invalid WHOIS. In fact, GDPR application shouldn’t be correlated with the loss of compelling and vital data (i.e. WHOIS data).

It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names notably those selling counterfeit goods.
Those websites are more and more numerous and often controlled by organized crimes. Surveys show, that nowadays, when a consumer happened to buy a fake online, most of the times he s himself a victim as he got duped.
Having access to data, is of a domain name selling fakes, is the only way to get its owner to stop its activity.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
33
3/23/2020 6:13:48Alice GensseHermès InternationalNo
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents."
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
Support intent of recommendation with edits
b3) We cannot help but notice the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.

b4) Not every high-volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.

If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinionNo opinion
Support intent of recommendation with edits
There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the party seeks the data because its rights have been infringed. This would be like a double sanction on the shoulders of a victim. Therefore, the costs shall be borne by ICANN. Let’s not forget that the more the system will be automatized, the less costly it will be.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more are more numerous.
No clear rules for WHOIS redaction for legal entities and natural entities:
We think that the GDPR WHOIS redaction is inconsistently enforced across different providers and there is no clear distinction for redactions for legal entities and natural entities.
The spirit of GDPR is to protect individual’s privacy but the majority of the registrars hide all WHOIS which we don’t believe was adequate. ICANN should, at the very least, have appropriate/consistent guidance for WHOIS disclosure policy and a policy for different WHOIS data displays – differing between commercial use of the domain name and personal use of the domain name as well as legal entities versus natural entities – as this can affect our decision when taking action if we can see a domain name is official or likely registered by a legitimate business. This can also help brand owners to verify any potential affiliation internally and help enforcement agencies to form an appropriate takedown strategy.

The Data accuracy is fundamental to fight against malicious use of WHOIS and natural person protective rules from GDPR : No assurance of Whois data accuracy is enumerated, and this threatens to disrupt the integrity of Whois at the outset. It is essential that accuracy of the data held within the WHOIS be addressed.
Thus, if the ICANN and its partners would require holders of NDDs used for commercial purposes to identify and register as such (as companies or individual persons with a commerciale activities) it will at least reduce the number of counterfeits seller which can obtain a domain name and it will increase and facilitate the obtention of accurate information in the WHOIS.

Though neither GDPR nor any other law protects fake data, this report shirks the responsibility of ensuring accuracy as part of an accountable and effective Whois framework. A significant proportion of Whois data has been and remains inaccurate.

Invalid WHOIS claim no longer available to tackle maliciously registered domains:
We cannot prove that a domain is registered with invalid WHOIS, as the data is redacted.
It was always counterfeiters’ practice to register domain names with invalid WHOIS; ICANN allowed for domain reports based on Invalid WHOIS that would prove registrant’s malevolence. Right now, since WHOIS is hidden/redacted, we have no longer option to report it based on invalid WHOIS. In fact, GDPR application shouldn’t be correlated with the loss of compelling and vital data (i.e. WHOIS data).

It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names notably those selling counterfeit goods.
Those websites are more and more numerous and often controlled by organized crimes. Surveys show, that nowadays, when a consumer happened to buy a fake online, most of the times he s himself a victim as he got duped.
Having access to data, is of a domain name selling fakes, is the only way to get its owner to stop its activity.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
34
3/23/2020 6:59:06Myrtha Hurtado Rivas
Global Head Trademarks & Domain Names
Yes
I'm submitting the answers on behalf of Novartis in my role as Head of Trademarks & Domain Names
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. Since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.
We support the point of view that in alignment with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves, what if all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.

Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.
In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
Support intent of recommendation with edits
b3) We cannot help but notice the difference in treatment of registrants and requestors. We fully agree that it is totally unacceptable for both registrants and requestors to use false, stolen or counterfeit credentials.
b4) Not every high-volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.
If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinionNo opinion
Support intent of recommendation with edits

There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the party seeks the data because its rights have been infringed. This would be like a double sanction on the shoulders of a victim. Therefore, the costs shall be borne by ICANN. Let’s not forget that the more the system will be automatized, the less costly it will be.
Support intent of recommendation with edits

The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which number continues to increase exponentially.
It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names, and notably those used for the sale and promotion of counterfeit goods.
Those websites are increasingly numerous and often connections to transnational organized crime has been proven. Several surveys show that nowadays, when a consumer buys a fake product online, most of the times he is himself a victim as he got duped.
Allowing accredited parties to have access to data of domain names involved in the sale of counterfeit goods is the only way to begin to take action against their owner.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
Indeed, GDPR application should not lead to the loss of compelling and vital data (i.e. WHOIS data).

Regarding data accuracy:
While this has been discussed to some level within the EPDP team, it is essential that accuracy of the data held within the WHOIS is addressed.
We strongly support the creation of a small team within the EPDP to consider this further in the nearest future. To spend so much effort and so many resources on ensuring the processing of and access to registrant data without any attempt to ensure its accuracy is counterproductive.
Data accuracy:
In our increasingly connected world, we should definitely consider the offline world components as equivalent to the online world ones. Besides, it is important that people going to a website, are capable of knowing who the registrant is. It is a matter of Transparency and Trust.
Moreover, protection of the consumer/patient is essential in the online world where the source of the products can easily be hidden. Therefore, having the registration data publicly available would enable consumers/patients to check the trustworthiness of a website in a more reliable way than looking at the website content. Of course, it would be even more useful if the data provided by the registrant is verified.

__________________________________________________________________________________
There was no entry field for comments regarding recommendation #17:

Regarding: “Logs MUST be retained for a period sufficient for auditing and complaint resolution purposes, taking into account statutory limits related to complaints against the controller”; we advise the retention period must be sufficiently long, at least at first, to accommodate all parties’ adoption to the system and to support “evolution” of automation efforts.

Where the EPDP team recommends that “Disclosure decisions including a written rationale must be stored and put in escrow so it can be accessed by ICANN and the contracted parties in case of objections or legal claims raised to support a legal defense.”; this should include responding to complaints or auditing contracted parties in order to ensure compliance by ICANN.
We further recommend that data to measure disclosure rates MUST be logged and archived, that data MUST be analyzed and measured, then audited and publicly reported.
35
3/23/2020 8:26:27Stéphanie Leguay
French anticounterfeiting comittee
No
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons
Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.
Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum. It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
Support intent of recommendation with edits
b3) We cannot help but notice the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.

b4) Not every high-volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.

If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinionNo opinion
Support intent of recommendation with edits
There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the party seeks the data because its rights have been infringed. This would be like a double sanction on the shoulders of a victim. Therefore, the costs shall be borne by ICANN. Let’s not forget that the more the system will be automatized, the less costly it will be.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more are more numerous.
It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names, and notably those used for the sale and promotion of counterfeit goods.
Those websites are increasingly numerous and often with proven links with transnational organized crime. Several surveys show that nowadays, when a consumer buys a fake product online, most of the times he is himself a victim as he got duped.
Allowing accredited parties to have access to data of domain names involved in the sale of counterfeit goods is the only way to begin to take action against their owner.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
Regarding data accuracy:
While this has been discussed to some level within the EPDP team, it is essential that accuracy of the data held within the WHOIS be addressed.
We strongly support the creation as soon as possible of a small team within the EPDP to consider this further. To expend so much effort and so many resources on ensuring the processing of and access to registrant data without any attempt to ensure its accuracy is unconscionable. This is in line with the views of the GAC and ALAC.
In our increasingly connected world, we should definitely consider the offline world components as equivalent to the online world ones. Besides, it is important that people going to a website, are capable of knowing who the registrant is. It is a matter of Transparency and Trust.
Moreover, protection of the consumer is essential in the online world where the source of the products can easily be hidden. Therefore, having the registration data publicly available would enable consumers to check the trustworthiness of a website in a more reliable way than looking at the website content. Of course, it would be even more useful if the data provided by the registrant is verified.
36
3/23/2020 8:27:37Sophie SojferHermès InternationalNo
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.

Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
Support intent of recommendation with edits
b3) We cannot help but notice the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.

b4) Not every high-volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.

If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinionNo opinion
Support intent of recommendation with edits
There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the party seeks the data because its rights have been infringed. This would be like a double sanction on the shoulders of a victim. Therefore, the costs shall be borne by ICANN. Let’s not forget that the more the system will be automatized, the less costly it will be.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more are more numerous.
No clear rules for WHOIS redaction for legal entities and natural entities:
We think that the GDPR WHOIS redaction is inconsistently enforced across different providers and there is no clear distinction for redactions for legal entities and natural entities.
The spirit of GDPR is to protect individual’s privacy but the majority of the registrars hide all WHOIS which we don’t believe was adequate. ICANN should, at the very least, have appropriate/consistent guidance for WHOIS disclosure policy and a policy for different WHOIS data displays – differing between commercial use of the domain name and personal use of the domain name as well as legal entities versus natural entities – as this can affect our decision when taking action if we can see a domain name is official or likely registered by a legitimate business. This can also help brand owners to verify any potential affiliation internally and help enforcement agencies to form an appropriate takedown strategy.

The Data accuracy is fundamental to fight against malicious use of WHOIS and natural person protective rules from GDPR : No assurance of Whois data accuracy is enumerated, and this threatens to disrupt the integrity of Whois at the outset. It is essential that accuracy of the data held within the WHOIS be addressed.
Thus, if the ICANN and its partners would require holders of NDDs used for commercial purposes to identify and register as such (as companies or individual persons with a commerciale activities) it will at least reduce the number of counterfeits seller which can obtain a domain name and it will increase and facilitate the obtention of accurate information in the WHOIS.

Though neither GDPR nor any other law protects fake data, this report shirks the responsibility of ensuring accuracy as part of an accountable and effective Whois framework. A significant proportion of Whois data has been and remains inaccurate.

Invalid WHOIS claim no longer available to tackle maliciously registered domains:
We cannot prove that a domain is registered with invalid WHOIS, as the data is redacted.
It was always counterfeiters’ practice to register domain names with invalid WHOIS; ICANN allowed for domain reports based on Invalid WHOIS that would prove registrant’s malevolence. Right now, since WHOIS is hidden/redacted, we have no longer option to report it based on invalid WHOIS. In fact, GDPR application shouldn’t be correlated with the loss of compelling and vital data (i.e. WHOIS data).

It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names notably those selling counterfeit goods.
Those websites are more and more numerous and often controlled by organized crimes. Surveys show, that nowadays, when a consumer happened to buy a fake online, most of the times he s himself a victim as he got duped.
Having access to data, is of a domain name selling fakes, is the only way to get its owner to stop its activity.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
37
3/23/2020 8:56:28etienne VANDAMMEHermès InternationalNo
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
Where it is noted:
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Support Recommendation intent with wording change
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
Where it states:
“• Requests from Law enforcement in local or otherwise applicable jurisdictions;
• Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
Support intent of recommendation with edits
b3) We cannot help but notice the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.

b4) Not every high-volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.

If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinionNo opinion
Support intent of recommendation with edits
There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the party seeks the data because its rights have been infringed. This would be like a double sanction on the shoulders of a victim. Therefore, the costs shall be borne by ICANN. Let’s not forget that the more the system will be automatized, the less costly it will be.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
No clear rules for WHOIS redaction for legal entities and natural entities:
We think that the GDPR WHOIS redaction is inconsistently enforced across different providers and there is no clear distinction for redactions for legal entities and natural entities.
The spirit of GDPR is to protect individual’s privacy but the majority of the registrars hide all WHOIS which we don’t believe was adequate. ICANN should, at the very least, have appropriate/consistent guidance for WHOIS disclosure policy and a policy for different WHOIS data displays – differing between commercial use of the domain name and personal use of the domain name as well as legal entities versus natural entities – as this can affect our decision when taking action if we can see a domain name is official or likely registered by a legitimate business. This can also help brand owners to verify any potential affiliation internally and help enforcement agencies to form an appropriate takedown strategy.

The Data accuracy is fundamental to fight against malicious use of WHOIS and natural person protective rules from GDPR : No assurance of Whois data accuracy is enumerated, and this threatens to disrupt the integrity of Whois at the outset. It is essential that accuracy of the data held within the WHOIS be addressed.
Thus, if the ICANN and its partners would require holders of NDDs used for commercial purposes to identify and register as such (as companies or individual persons with a commerciale activities) it will at least reduce the number of counterfeits seller which can obtain a domain name and it will increase and facilitate the obtention of accurate information in the WHOIS.

Though neither GDPR nor any other law protects fake data, this report shirks the responsibility of ensuring accuracy as part of an accountable and effective Whois framework. A significant proportion of Whois data has been and remains inaccurate.

Invalid WHOIS claim no longer available to tackle maliciously registered domains:
We cannot prove that a domain is registered with invalid WHOIS, as the data is redacted.
It was always counterfeiters’ practice to register domain names with invalid WHOIS; ICANN allowed for domain reports based on Invalid WHOIS that would prove registrant’s malevolence. Right now, since WHOIS is hidden/redacted, we have no longer option to report it based on invalid WHOIS. In fact, GDPR application shouldn’t be correlated with the loss of compelling and vital data (i.e. WHOIS data).

It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names notably those selling counterfeit goods.
Those websites are more and more numerous and often controlled by organized crimes. Surveys show, that nowadays, when a consumer happened to buy a fake online, most of the times he s himself a victim as he got duped.
Having access to data, is of a domain name selling fakes, is the only way to get its owner to stop its activity.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
38
3/23/2020 8:58:12Masson
HERMES INTERNATIONAL
No
No, I would like to continue to the next section
Support Recommendation intent with wording change
Where it is noted: “SSAD MUST only accept requests for access/disclosure from accredited organizations and individuals”; the terms “companies, associations” shall be added in order to explicitly include the participation of all types of legal persons in this process.

In addition, there is no guarantee of the accuracy of WHOIS data listed. This put at risk from the beginning the validity of WHOIS. Neither the GDPR nor any other law projects fake data. But, since we know from experience that WHOIS data is often inexact, this report should also aim at ensuring correctness of WHOIS.

As the GAC and ALAC stated in their joint Statement on the EPDP: “In accordance with Article 5 of the GDPR, every reasonable step must be taken to ensure the accuracy of the data in view of the purposes for which it is processed.”
Support Recommendation intent with wording change
Law Enforcement Authorities will of course need to be accredited according to the relevant national laws; we do not feel that it would be appropriate to presuppose that national data authorities have the mandate to “audit” their national Law Enforcement Authorities. Thus, we would suggest that paragraph c – Auditing (page 23) should read:

“Audits should be conducted by the auditor designated by the applicable national / regional law”.
Support Recommendation intent with wording change
“The EPDP Team recommends that each SSAD request MUST include all information necessary for disclosure decision, including the following information: […]
e) A list of data elements requested by the requestor, and why the data elements requested are adequate, relevant and limited to what is necessary;
f) Request type (e.g. Urgent)”;

We would:
- Delete “and why the data elements requested are adequate, relevant and limited to what is necessary” in e) because it would be too burdensome to each time explain again the reasons;
- Completely delete f) because we ask ourselves what is all requests are declared as urgent? It would be better to deal with requests based upon receipt, rather than on a declarative level of priority.
Support Recommendation as written
Significant change required: changing intent and wording
There should be a reasonable time limit for sending the acknowledgement of receipt, e.g. 2 to 4 hours.
Support Recommendation intent with wording change
Where it is noted: “1. For the avoidance of doubt, automated review is not explicitly prohibited where it is both legally and technically permissible.”; we would suggest replacing “explicitly prohibited” by “encouraged” in order to deal with requests without creating undue delay and allow predictability for requestor in the outcome, it is best to promote automated reviews.

Where it is noted: “If the answer to any of the above questions is no, the Contracted Party MAY deny the request or require further information from the requestor before proceeding to bullet 5 below”; we would suggest deleting “deny the request or” in order to not penalize requestors. In fact, the Contracted party shall provide requestors with the opportunity to correct any flaws in their request.

We also suggest inserting a 6.: “Best efforts must be made for the entire process to be done within a reasonable timeframe so that it does not become a lengthy procedure.”

Regarding the following: “Nature of the data – Consider the level of sensitivity of the data as well as whether the data is already publicly available.”; this recommendation should include that the controller MUST consider whether the data is covered by applicable law (e.g. as it is done in the offline world).

Regarding the following: “Legal frameworks involved – Consider the jurisdictional legal frameworks of the requestor, Contracted party/parties, and the data subject, and how this may affect potential disclosures.”; we think that if no applicable law should prohibit disclosure, then disclosure should be mandatory.

Where it is noted: “Implementation guidance […]: • An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws; • Examples of legitimate interests include: (i)enforcement of legal claims, (ii) prevention of fraud and misuse of services, (iii) physical, IT and network security.”; we would add: “(iv) IP infringements”. In fact, mentioning counterfeit explicitly is necessary, in order to avoid any potential misunderstanding.
Support Recommendation intent with wording change
“ Requests from Law enforcement in local or otherwise applicable jurisdictions;
Responses to UDRP and URS Providers for registrant information verification”.
We would add a 3rd bullet point as follow: “• Requests from accredited parties with a history of valid disclosure requests”. In fact, considering the number of potential requests and to avoid unnecessary delays in the answers, it is recommended to extend the scenario of automated disclosure requests.

Where it is noted: “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor, with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.”; we would suggest deleting “with an incomplete request response” and replace it by “indicating that the request is incomplete”.

In the implementation guidance, add the following:
“As a priority, consideration should be given to automating disclosure requests for intellectual property rights holders and their approved agents.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We would replace “As part of its relay to the responsible Contracted party, the Central gateway manager […] MAY provide a recommendation to the contracted party whether to disclose or not. The Contracted party MAY follow this recommendation. If the contracted party decides not to follow […]” by “As part of its relay to the responsible Contracted party, the Central Gateway manager will provide an instruction to the contracted party whether to disclose or not. The contracted party will have to follow this instruction” and delete the rest of the sentence.

On top of that, we want to highlight the following elements:
• Timelines for the confirmations from the Central Gateway Manager in both cases should be specified as being within 24 hours.
• If the CGM’s recommendation to the CP is negative, this must be disclosed, with rationale, to the requestor.
• “Contracted parties must provide a disclosure response within 72 hours...”.
• In case of denial of a disclosure request from a CP, there must be a clear and rapid appeal procedure.
• ICANN Compliance’s role cannot be limited to a possibility of investigation of complaints. It is imperative that it also have the ability to enforce, including sanctions where appropriate, within reasonable timelines.
• Implementation guidance: an “incomplete request response” should be issued by the CGM within 24 hours.
Support intent of recommendation with edits
There should be a procedure to deal with parties that regularly or consistently miss “best effort target response times”.
Automated answers shall be extended to avoid creating unnecessary delays. All requests shall be dealt with chronologically based upon receipts. Working on establishing a hierarchy of priorities for requests would lead to using time which shall be better dedicated to actually deal with requests. Considering that requests are made for important and urgent matters, answers shall be given for manual process within 24 hours.

Response targets for priority 3 requests are far too long for trademark, phishing, credit card fraud (etc.) cases, and in particular we cannot understand why the targets is doubled in Phase 2 given that more experience with a system would normally reduce such timelines. Both targets should be 3 working days at a maximum.

It is not sufficient that ICANN Compliance could open an “inquiry” for failure to provide rationale for missing the 5-day target in Phase 1, not that there will be “compliance enforcement” for missing the Phase 2 mean compliance target. There must be clear enforcement procedures, including applicable sanctions.
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
In the “Contracted parties and SSAD” section, we would completely delete e) “Where required by applicable law, MUST perform a balancing test before processing the data.” since the decision to disclose would be taken by the Central gateway manager, which indeed will have carried out the balancing test already.

In the “Contracted parties and SSAD” section, part f), we request the following wording changes: “MUST disclose to the Registered Name Holder (data subject), on reasonable request by the data subject, confirmation of the processing of personal data relating to them, per applicable law without disclosing the identity of the requestor.” In fact, disclosure of the request to a registrant which is, inter alia, operating a fraudulent, phishing or counterfeit site would alert them that the brand owner (and/or LEA) is on their tail.

Where the EPDP team writes: “For the avoidance of doubt, every response does not have to go through an enforcement procedure; the enforcement mechanism may, however, be triggered in the event of apparent misuse.”
This could be clarified regarding who can trigger a misuse enforcement mechanism (e.g. the Central Gateway Manager, a third party, etc.).

We further recommend the addition of an item “J” in the alphabetized list, which would read: “MUST data disclose data where such disclosure is not prohibited by or required by applicable law.”
Support intent of recommendation with edits
b3) We cannot help but notice the difference in treatment of registrants and requestors. While we fully agree that it is totally unacceptable for a requestor to use false, stolen or counterfeit credentials, there is no acceptance that some registrants will do the same. This adds to the pressing need for improvements of data accuracy.

b4) Not every high-volume request will be abusive and non-abusive requestors should not be held responsible for another party’s failure to meet its SLAs.

If there is a “determination based on abuse”, we would suggest an escalation towards suspension/termination to guard against arbitrary decisions and allow for appropriate rectifications.
No opinionNo opinion
Support intent of recommendation with edits
There is absolutely no reason why a legitimate party requesting for a valid disclosure of data should bear the cost. Especially if we consider the case where the party seeks the data because its rights have been infringed. This would be like a double sanction on the shoulders of a victim. Therefore, the costs shall be borne by ICANN. Let’s not forget that the more the system will be automatized, the less costly it will be.
Intent and wording of this recommendation requires amendment
The rule should be automation, and the manual process (when the criteria are not met), the exception. It would be much more efficient, quick and cheap.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
The Contracted Parties / Central Gateway Manager should also be regularly audited, so as to be able to identify repeat cases of unsubstantiated denials or non-response.
Support intent of recommendation with edits
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
We advise that any working group controlling the evolution of the SSAD MUST include the GAC, ALAC and SSAC; further, their decisions should not be subject to reversal by the GNSO.
Support implementation guidance as written
This process would indeed be very useful to cope with the reality of infringing domain names which intend to be more are more numerous.
No clear rules for WHOIS redaction for legal entities and natural entities:
We think that the GDPR WHOIS redaction is inconsistently enforced across different providers and there is no clear distinction for redactions for legal entities and natural entities.
The spirit of GDPR is to protect individual’s privacy but the majority of the registrars hide all WHOIS which we don’t believe was adequate. ICANN should, at the very least, have appropriate/consistent guidance for WHOIS disclosure policy and a policy for different WHOIS data displays – differing between commercial use of the domain name and personal use of the domain name as well as legal entities versus natural entities – as this can affect our decision when taking action if we can see a domain name is official or likely registered by a legitimate business. This can also help brand owners to verify any potential affiliation internally and help enforcement agencies to form an appropriate takedown strategy.

The Data accuracy is fundamental to fight against malicious use of WHOIS and natural person protective rules from GDPR : No assurance of Whois data accuracy is enumerated, and this threatens to disrupt the integrity of Whois at the outset. It is essential that accuracy of the data held within the WHOIS be addressed.
Thus, if the ICANN and its partners would require holders of NDDs used for commercial purposes to identify and register as such (as companies or individual persons with a commerciale activities) it will at least reduce the number of counterfeits seller which can obtain a domain name and it will increase and facilitate the obtention of accurate information in the WHOIS.

Though neither GDPR nor any other law protects fake data, this report shirks the responsibility of ensuring accuracy as part of an accountable and effective Whois framework. A significant proportion of Whois data has been and remains inaccurate.

Invalid WHOIS claim no longer available to tackle maliciously registered domains:
We cannot prove that a domain is registered with invalid WHOIS, as the data is redacted.
It was always counterfeiters’ practice to register domain names with invalid WHOIS; ICANN allowed for domain reports based on Invalid WHOIS that would prove registrant’s malevolence. Right now, since WHOIS is hidden/redacted, we have no longer option to report it based on invalid WHOIS. In fact, GDPR application shouldn’t be correlated with the loss of compelling and vital data (i.e. WHOIS data).

It is crucial that ICANN and other actors of EPDP Phase 2 process understand the importance and reality of the fight against infringing domain names notably those selling counterfeit goods.
Those websites are more and more numerous and often controlled by organized crimes. Surveys show, that nowadays, when a consumer happened to buy a fake online, most of the times he s himself a victim as he got duped.
Having access to data, is of a domain name selling fakes, is the only way to get its owner to stop its activity.
That is why regaining access to WHOIS data is our main preoccupation in the application of EPDP Phase 2.
39
3/23/2020 10:50:24Alessandra Romeo,
MARQUES External Relations Officer
Yes
MARQUES European Association of Trade Mark Owners
No, I would like to continue to the next section
Support Recommendation intent with wording change
At the outset, we would like to flag our overarching comments given in response to Q46.

Marques supports the intent behind recommendation #2, but is concerned by the lack of any specificity and detail in key areas. There appears to be an expectation that that this detail will be fleshed-out by the later implementation team, or even by the Accreditation Authority itself – even this presently seems ambiguous and unclear.

Examples of areas where there is ambiguity and/or greater clarity would benefit:
• Signed assertions (g) are listed under the “Requirements of the Accreditation Authority”. Certainly, the Accreditation Authority needs to be able to manage such assertions, but the information to be provided by a party seeking accreditation should be grouped in one place.
• The signed assertions required for a one-off basis versus a regular user are unclear and some appear to relate rather to a specific SSAD request. E.g. the “trademark ownership/registration” information is potentially case-specific. The process will need to allow for a user to be accredited and then to associate additional rights to their existing accreditation on an ongoing basis, as required. The “purpose of the request” and “legal basis of the requestor” would also seem to have the potential to be case-specific
• What precisely are these assertions? E.g. Is it expected that there will be a set of declarations such as “to comply with the law on storage/retention” or will there be an actual set of standards as to how that retention is to be effected and the maximum length of time that the data may be store? Who will be making that decision? As drafted, it appears this may simply be left to the Accreditation Authority – if that is the intent, this seems unwise since this is a contentious area.
• Paragraph (i) is also listed under “Requirements of the Accreditation Authority” and refers to a base line “code of conduct”. This also appears to imply that the creation of the code of conduct is this being left to the Accreditation Authority, and although there is a mention of the need for a description of the extent of stakeholder consultation this falls short of an actual obligation to consult. Since breach of the code of conduct can have serious implications for an accredited user (o) there must be a proper consultative process.
• Lack of any specificity as to the dispute resolution and complaints process (k).
• Lack of specificity as to the graduated penalties for a user (q). Where is it envisaged that the responsibility for developing this will lie? Since different community interests will have strong and opposing views on how such a graduated process should apply, this needs to be expanded-upon.
• What is a “demonstrable threat to the SSAD” (v) and who is determining this? This should not be a unilateral decision of the Accreditation Authority, there should be some agreed boundaries.

Review and update definitions and provide a full set of definitions for the Policy in one place: Prior to the publication of the Final Report it would be beneficial to review and ensure all terms which are being used as defined terms within the Policy are captured in a single “Definitions” section. Presently, some later recommendations include the addition of new definitions, and some terms which appear to be intended as defined terms are not so defined. For example, the term “Requestor” is capitalised and used within definition of “Authentication”, but is not separately defined. Elsewhere, it is used without capitalisation. This should be standardised as part of the clean-up of the Final Report.
Support Recommendation as written
Support Recommendation intent with wording change
It would be helpful to make clearer what is required for an SSAD request, in particularly under (b) and (c). We refer to our comments under Recommendation #1 above regarding the signed assertions. If the intent is that during the accreditation process the existence of and ownership of a specific legal right (such as a registered trademark) and/or authority to make the request on behalf of the owner will be verified, then presumably this is not required to be duplicated as part of the SSAD request, but we do not find this entirely clear.

During implementation, to the extent that the information required to satisfy paragraphs (a) to (f) can be presented to the requester as a set of tick boxes, drop down options or the like, then this will speed up both the submission and the evaluation of requests.
Support Recommendation as written
No comment required
Support Recommendation intent with wording change
Support Recommendation intent with wording change
Bullet Point #1: Replace “automated review is not explicitly prohibited” by wording to the effect that automated review is possible or permissible. The present is language will tend to be interpreted negatively.

Bullet Point #4: Clarification is required, either within bullet point #4 or in the implementation notes, that in making its threshold determination it is not the role of the contracted party to act as judge and make an assessment of whether the requestor would be able to bring and win an anticipated legal claim. The requestor may have a legitimate interest or other lawful basis in having the data disclosed to them, even though the outcome of that disclosure is to allow the requestor to determine that they have no claim (for example because the registrant has some personal defence) or that it is not appropriate for them to pursue the proposed claim at this time (for example because more investigation is now required). Such an assessment, frequently, cannot be made until the relevant registrant data is provided, and it is not the role of the contracted party to prevent that assessment taking place.

We strongly support the final paragraph. It is important that this language is retained. In particular, it is important to retain the wording “nor can refusal to disclose be solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name”. It has been the experience of some of Marques’ members that some contracted parties appear to be under the mistaken impression that the only reason a brand owner would require to know the registrant data for a domain name is if they intended to investigate and take an action against the domain name itself (e.g. by means of a URS or UDRP action).
Significant change required: changing intent and wording
Whilst we note and support the idea that the system will effectively learn over time and that further guidance and further types of automated disclosure will be developed, we consider that the current list (requests by law enforcement and responses to URS/UDRP Providers) is too restrictive. Disclosure for the purposes of investigating and enforcing trademark rights has the capacity to be appropriate for automation. In particular, the scenario identified in the Draft Use Cases where a trademark is recorded in the TMCH and the domain is or contains the identical trademark is appropriate for compulsory automation. Disclosure, in such a case, would seem to always be appropriate in order to allow the requestor to further investigate, determine whether further action is appropriate and to bring such action. As stated at recommendation #6 above, it is not a part of the relevant assessment by the contracted party whether the requestor is guaranteed of a successful claim.

There are also other scenarios where automation is entirely appropriate from the outset, for example where it is clear from the registrant data as recorded that this is not personal data, or where a particular TLD has eligibility restrictions such that no natural persons are eligible to register names. Since this data is not personal data it MUST, under recommendation #6, be disclosed and so is ideally suited to automation.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support Recommendation intent with wording change
Support intent of recommendation with edits
No, I wish to continue to the next section
Intent and wording of this recommendation requires amendment
Significant change required: changing intent and wording. Marques disagrees with the proposal that requests may only be made for data from the current RDS data set. Historic data can be essential to provide a complete picture, for example in case of suspected cyberflight.
Intent and wording of this recommendation requires amendment
Significant change required: changing intent and wording. As above, Marques disagrees with the proposal to limit data only to current data and to exclude historic data. Historic data can be essential to provide a complete picture, for example in case of suspected cyberflight.
No opinionNo opinion
Support recommendation as written
Support intent of recommendation with edits
Marques supports the proposed distinction between development and operational costs.

We agree that development costs be borne by ICANN and that this might include a contribution by Contracted Parties, however it is more difficult to see how such costs could be fairly attributed than the subsequent operational costs. In the case of registrars, for example, those who operate a corporate/brand protection model are likely to have a portfolio of names which will receive significantly fewer queries than retail registrars and so the SSAD is, relatively speaking, of less value to them. Similarly, a small retail registrar might, proportionately speaking, have a much higher volume of queried names than a larger one, depending on how they operate their business. The most appropriate cost mechanism would seem to be to have ICANN incur the initial build costs and to recover the Contracted Party contribution in a manner which reflects their usage.

Regarding running costs of the SSAD, to be offset by charging users of the system, both accredited requestors and contracted parties would be considered users of the system.

We note that the EPDP Team recognises that fees may differ depending on volume of requests, type of user, or other factors. What the actual applied factors are would seem to be a very important detail, that ought to be agreed on now rather than leaving this to implementation. Marques believes that the fairest way is to apply fees based on volume of usage, probably by applying a series of tiers which start with a sufficiently low-query volume tier so as not to be disproportionately onerous for the occasional user.
Support intent of recommendation with edits
See our comments above regarding the types of requests suitable for automation from the outset.
No, I wish to continue to the next section
No opinion
Support recommendation as written
Support recommendation as written
Any Mechanism should involve the input of directly affected parts of the community, in particular the contracted parties and SSAD users including business and intellectual property interests, law enforcement, cybersecurity, and other end users.

It should be the aim of the Mechanism to seek to move as many use case-types to full automation as possible, bearing in mind the legal and operational considerations.
As an overarching comment, Marques feels that in a number of areas, the exact intent of the EPDP team is not clear to third parties who are not deeply involved in the discussions. The likelihood is that, in many cases, the EPDP team know what they intend, but this is not necessarily clear and obvious to the outsider.

Marques is supportive in principle of the work that the EPDP Phase 2 working group is doing and the proposed recommendations. However, these proposed recommendations appear to essentially present a high-level framework for an SSAD, whilst leaving all the detail outstanding and without a clear path for how the further work will be progressed, by whom, or in what timescale. Much of this detail is fundamental and likely to be contentious. In order to adopt these recommendations, the community needs to know what it is agreeing to, and currently this really is not the case. An externally imposed deadline, even if that is as a result of the unavailability of the well-regarded Chair, is not a sufficient reason for leaving the essential detail unresolved.

Brand owners require timely and cost-effective access to accurate information on those who register abusive domains in order to protect the internet users who are there customers. We thank the EPDP team for their work to this end.
40
3/23/2020 10:57:07Ray FassettEmploy Media LLCNo
No, I would like to continue to the next section
No, I wish to continue to the next section
No, I wish to continue to the next section
No, I wish to continue to the next section
If a registrant provides consent, a contracted party should not be prohibited from collecting additional information that could be made available through either RDDS or SSAD. The work of the EPDP WG both Phase 1 and Phase 2 should not preclude contracted parties from offering enhanced or innovative services for data collection and/or display when proper consent of the registrant has been obtained for the purpose the data was collected.
41
3/24/2020 14:20:04At-Large StaffICANN Policy StaffYes
At-Large Advisory Committee (ALAC)
No, I would like to continue to the next section
Support Recommendation intent with wording change
Accreditation is an important element of the SSAD as it saves the time and effort required by decision-making entities to verify the requestor, provides external assurance that the requestors have been verified and reduces the load on the SSAD. However, the ALAC is concerned that given the fact that requests to SSAD can only be submitted by accredited users, the accreditation process could end up being a bottle neck, limiting access to the system. We therefore see that the accreditation entity in addition to having a uniform baseline application procedure and accompanying requirements should also have a clear timeline for its process and response.  
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation intent with wording change
The recommendation requires the contracted party to determine if the requestor provided legitimate interest or other lawful basis in processing the data and if the data requested is necessary to the requestors stated purpose. If the answer is affirmative the contracted party examines if the requested data contains personal data, if not then the data is disclosed without further consideration. We note that there is no need to examine the lawful basis and legitimate interest of the requestor if no personal data is required. Non-personal information is not protected under GDPR and all requestors are accredited users thus their identity is verified, this is an unnecessary step that:

a) may allow the rejection of a request where the requested data is not protected under GDPR or  b) may delay the response to a request that includes non-personal information.
Support Recommendation intent with wording change
The EPDP team has indicated only two types of disclosure requests that can be automated from the start. We note that automation provides consistency, sustainability and quicker response time. We recommend trying to put forward more types of disclosure requests for automation by seeking the advice of the DPA’s. Such requests should cite explicit classes of requests and the rationale for allowing automated disclosure. 

This work can be done during the implementation phase but must explicitly be described in the final report.
No, I wish to continue to the next section
Support recommendation as written
Support intent of recommendation with edits
Urgent requests that are defined as circumstances that pose an imminent threat to life, serious bodily injury, critical infrastructure (Online and offline) or child exploitation, are critical situations that require immediate responses. According to the recommendation, the urgent response is one business day that is if the request is submitted on a Friday afternoon the response could be provided on Monday that is after three days, we regard this as a very long response period for an urgent request and recommend that the response time is within 24 hours instead of one business day.

The RAA already calls for 24 hour staffing for certain types of urgent requests and this class of disclosure request should be treated similarly.

In addition, the EPDP team should clarify the priority and thus the expected response times for cases of typical DNS abuse, including phishing, malware, and fraud. Furthermore, if the processing of any request is taking longer than the to-be-agreed duration, the responder should be required to inform the requester and record the reasons for the delay.
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
The phrase “Data subjects MUST NOT bear the costs for having their data disclosed to third parties” is too vague and subject to mis-interpretation. Registrants, directly or indirectly are the prime source of revenue to ICANN and a major source of revenue to contracted parties. So the costs borne by ICANN and contracted parties implicitly (which this recommendation allows) DOES ultimately come from registrants.

The wording should be changed to say, “A Registrant should not be subjected to explicit additional charges associated with the operation of the SSAD”.

In addition, the ALAC strongly believes that the fee structure must provide preferential treatment to CSIRTS, CERTS, academic research, and similar non-profit endeavors in the public interest.
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
The ALAC notes the importance of introducing a methodology through which the system can improve and more cases out of experience and learning can be automated. We do not see any existing procedures that can be used to meet this responsibility and suggest forming an SSAD implementation council consisting of members from all stakeholders. The responsibility of the SSAD implementation council would be looking into the types of disclosures that out of experience are deemed automatable and recommend moving its decision making to the central gateway manager who would provide an automated response to such requests.

To be clear, the “mechanism” that is established by the recommendation must have the authority (with the support of contracted party representatives) to have new classes of automation introduced into the SSAD without referring the matter to the GNSO Council which only has jurisdiction over policy matters (and this present policy recommendation will already allow the creation of new classes of automated responses).
Support implementation guidance as written
It would be useful to engage with parties that have been dealing with this for a long time:

ALAC asks the EPDP team to consider reaching out to key actors in the anti-abuse space, including but not limited to M3AAWG, FIRST and APWG. These groups have deep insights into dealing with investigations in the DNS space and have long used the WHOIS. Their practical insights into processes, issues, and key concerns could prove invaluable for developing an efficient and effective system.
Finally, the ALAC would like to note the importance of some priority 2 issues like the differentiation between legal vs natural persons and the accuracy of the data. Ending up with a disclosure system that returns inaccurate data and thus useless responses would be a waste to the effort put by all elements of the system and of no use to the requestor. Differentiation between natural and legal persons would offload the system from unnecessary queries that are permissible under GDPR.  
42
3/23/2020 12:39:13Susan PayneCom Laude GroupNo
No, I would like to continue to the next section
Support Recommendation intent with wording change
Whilst we do support the intent behind recommendation #2, much of the detail does seem to be left for future implementation work. Some of this seems quite fundamental to what the actual policy for operation of an SSAD will be and it would be preferable to have this detail worked out before adopting recommendations, for example:
• How the accreditation of a single user and a regular user might differ. The recommendation states that this MAY be the case, but it would be preferable to have clarity on whether this will be the case.
• The code of conduct
• Dispute resolution and complaints processes
• Graduated penalties for users
• What constitutes a “demonstrable threat to the SSAD”

The recommendation as currently drafted also somewhat lacks clarity for those not participating in the detailed work of the working group. For example:
• Does an individual accessing the SSAD on behalf of an accredited legal person also have to be separately accredited?
• Some of the signed assertions appear to go to the facts of a specific request rather than being for the accreditation of a user. Greater explanation/detail would help to clarify.
• Are the assertions regarding compliance with law, storage, protection, retention/disposal, use of the data for legitimate and lawful purposes, prevention of abuse, auditing, and so on intended to be a simple set of statements/declarations to that effect; will there be a set of minimum standards that they must acknowledge compliance with; or is the requesting user expected to identify the exact manner in which they will meet these various assertions?
Support Recommendation as written
Support Recommendation as written
Support Recommendation intent with wording change
The recommendation for the response time to acknowledge receipt of an SSAD request is “without undue delay”. This should be changed to “immediate”. The SSAD is intended to be an automated system.

A timeframe/SLA is also required for confirming all information has been received or for identifying and requesting missing information and for the timeline thereafter, including how quickly a SSAD request is to be transmitted to the contracted party.
Support Recommendation intent with wording change
Bullet Point #5: The sentence “The purpose of bullet point #5 is to determine whether bullet point #6 meaningful human review is required” needs to be revisited. Bullet point #6 does not refer to meaningful human review. Further, the type of review set out at bullet point #5 would appear likely to entail a meaningful human review.

The reference in the first sentence to “Contracted Party MAY evaluate the underlying data requested” seems to be inconsistent with the remainder of bullet point #5 and so is presently confusing and unclear. We understand that this has been subject to debate within the EPDP and that this is a compromise, however, the listed items that should be assessed would all appear to be ones required in order to determine, firstly, whether there is in fact personal data (and if there is not, then it is stated that disclosure MUST happen) and, secondly, where there is personal data, to carry out the kind of balancing exercise that the law expects. This would therefore seem to suggest that the “Contracted Party MUST evaluate”, rather than “MAY”.

In terms of the non-exhaustive list of factors to be considered in that balancing exercise, “Status of the data subject” would appear to be information which, in practice, will not be available since this does not form part of the Whois information and is unlikely to be information collected by a registrar as a matter of course. The unavailability of any data relating to this factor should not weigh the balance in favour of non-disclosure.

It is not clear what distinction is intended to be drawn by the used of “SHALL” as opposed to “MUST” in the sentence “If, based on consideration of the above factors, the Contracted Party determines that the requestor’s legitimate interest is not outweighed by the interests of fundamental freedoms of the data subject, the data SHALL be disclosed”. If there is a distinction, this should be clarified. Otherwise, this ought to be changed to “MUST”, for consistency.
Support Recommendation intent with wording change
Although we believe that we understand the intent here, there is potential ambiguity caused by the reference to “disclosure requests for which it has been determined that these can be responded to in an automatic fashion” when taken in conjunction with the fact that the two types of request so far identified are merely listed in the implementation guidance as “the EPDP Team expects”. There is also a reference to contracted parties having a discretion not to automate where not “required by these policy recommendation”. Does the implementation guidance “expectation” qualify as having been “determined” and “required by these policy recommendations” for the purposes of automated disclosure decision-making? Our understanding is that the two types of disclosure request so far identified are intended to be considered as “required”. The EPDP Team is asked to be explicit in the Final Report.
No, I wish to continue to the next section
Support intent of recommendation with edits
Under paragraph (c) the provision of a recommendation by the Central Gateway Manager should be obligatory. It is the intent that the Central Gateway Manager will learn and improve, which is best achieved with maximum data. Further, since there is an intent to evolve the SSAD with respect to automation, it will be necessary to compile data that demonstrates types of request where the decision of the Central Gateway Manager and the contracted party align.

It is not clear whether there is a requirement on the Contracted Party always to notify the Central Gateway Manager of its disclosure decision, as opposed to only where there is a recommendation from the Central Gateway Manager with which it disagrees. Again, for the purposes of evolving the SSAD, as well as to ensure centralized logging, all decisions (i.e. at a minimum whether or not the Contracted Party discloses) should be notified.
Support intent of recommendation with edits
Regarding Priority 3 requests, in Phase 1 there is a reference to “registrar response rates” whereas everywhere else refers to a Contracted Party. This would seem to be an error.
No, I wish to continue to the next section
Support recommendation as written
No, I wish to continue to the next section
Support intent of recommendation with edits
Support recommendation as written
Support recommendation as written
We would ask that there be a single set of complete definitions at the beginning. Having sub-sets of definitions introduced in individual recommendations is not user-friendly.
43
3/23/2020 12:27:03
Ephraim Percy Kenyanito
Non Commercial (Civil Society)
YesARTICLE 19
No, I would like to continue to the next section
Support Recommendation as written
Significant change required: changing intent and wording
The draft recommendations contain phrases such as“ public policy task”, “ “Consumer rights organizations” and "Cybersecurity authorities, including national Computer Emergency Response Teams (CERTs)," which are very vague.

More specifically, “public policy task” is too broad a threshold for allowing government authorities access to registrant data. On the other hand, while both “Consumer rights organizations” and "Cybersecurity authorities, including national Computer Emergency Response Teams (CERTs)," do not specify that the institutions should be only the government accredited ones.
Support Recommendation as written
Support Recommendation intent with wording change
We recommend that the title of this Recommendation should be "Third Party Justifications." This would make the recommendation more specific as compared to the broader use of “purpose”.
Support Recommendation as written
Support Recommendation intent with wording change
We propose a minor wording change at the end of the 4th paragraph by deleting the words, "nor can refusal to disclose be solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name." This is because the section makes IP interests over-ride all legitimate disclosure denials.
Recommendation should be deleted
The recommendation allows for automation of ALL requests by law enforcement agencies which does not meet the 3 part test i.e. a) Provided by law, b) In pursuit of a legitimate aim and c) Necessary and proportionate in pursuance of a legitimate aim. The recommendation as worded can be used to avoid scrutiny and oversight which is intended through this policy development process.
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
We request for clarification regarding the statement: "Support the ability of a requestor to submit multiple domain names in a single request."
Support recommendation as written
Support recommendation as written
Support recommendation as written
Intent and wording of this recommendation requires amendment
We request for rewording of the last paragraph as it does not have a clear legal basis as in other parts of the report. The paragraph is phrased that: "The SSAD MUST allow for automation of the processing of well-formed, valid, complete, properly-identified requests from accredited users with some limited and specific set of legal basis and data processing purposes which are currently described in Preliminary Recommendation #7 but still under discussion. These requests MAY be automatically processed and result in the disclosure of non-public RDS data without human intervention."
No, I wish to continue to the next section
Support intent of recommendation with edits
Support recommendation as written
Delete recommendation
This section creates an opaque process which can be used to revise policy without public participation.
A subcommittee of the GNSO Council can engage in long-term oversight of the SSAD's administration.
An existing process (GNSO council subcommittee) can be used
We object to the term "continuous evolution."
Any improvements must involve the GNSO Council through a public process.
Delete implementation guidance
The proposed automated disclosure does not meet the 3 part test i.e. a) Provided by law, b) In pursuit of a legitimate aim and c) Necessary and proportionate in pursuance of a legitimate aim. The recommendation as worded can be used to avoid scrutiny and oversight which is intended through this policy development process.
We recommend all data as outlined in the DNS Transparency Reporting Guide:- https://icannhumanrights.net/wp-content/uploads/2019/09/DNS-Transparency-Reporting-Guide.pdf
44
3/23/2020 12:31:51Brian KingMarkMonitorYesMarkMonitor
No, I would like to continue to the next section
Support Recommendation as written
MarkMonitor supports the concept of accreditation and encourages the SSAD to allow for the upfront establishment of as many accreditation attributes upfront as possible. These attributes should include identity characteristics, legal rights, law enforcement status, etc. as they may pertain to the accredited requestor. Enabling these attributes to be established upfront should ensure that subsequent data requests are automated as much as possible, and manually processed as quickly and uniformly as possible where necessary.
Support Recommendation as written
MarkMonitor supports accreditation for law enforcement agencies and other governmental agencies who need access to RDS data for their public policy objectives.
Support Recommendation intent with wording change
The criteria and content of requests as outlined in this recommendation are reasonable. To increase the potential for automation and standardization within SSAD, these rationale and justification options should be standardized, e.g. pre-populated options in a pick-from menu.
Support Recommendation as written
MarkMonitor supports the explicit recognition of the third-party purposes for which data may be disclosed.
Significant change required: changing intent and wording
In cases where disclosure cannot be automated, MarkMonitor submits that the SSAD must provide an immediate and synchronous confirmation that the request has been received.
Significant change required: changing intent and wording
MarkMonitor submits that the question of whether the RDS data contains personal data should be considered before the request is submitted to the contracted party, not after (Section 5). Referring requests to Contracted Parties for evaluation should be the exceptional case, not the rule. ICANN or its designee acting as the Central Gateway operator should determine whether the RDS data contains personal data. There is no question that the Central Gateway should be able to access the data in its capacity as a data controller in order to make this determination.

MarkMonitor notes that if Contracted Parties are permitted to deny requests based on the threshold questions in Section 4, then Contracted Parties’ responsibility for making a threshold determination must use MUST language in the first sentence of Section 4. Using MUST language here eliminates the confusing outcome where Contracted Parties can otherwise deny requests based on a determination they did not make.

MarkMonitor wonders whether all Contracted Parties possess sufficient resources and subject matter expertise to perform the analysis recommended in Section 6. Contracted Parties’ core competencies tend to be in the provision of technology services, and not necessarily in the relatively novel field of data protection law. It’s unclear how many Contracted Parties employ an in-house Data Protection Officer, privacy counsel, or other personnel with the expertise required to perform this analysis. The brand protection business formerly owned by MarkMonitor was disappointed in Contracted Parties’ significant lack of response to requests manually reviewed and submitted by our professional brand protection analysts, so we caution that this recommendation does not merely lead to more of the same. See https://www.markmonitor.com/mmblog/brand-protection/gdpr-whois-and-impacts-to-brand-protection-nine-months-later/.

Contracted Parties also have a strong preference for centralized decision making, so long as the associated liability can remain with the decision maker and not also expose the Contracted Party to liability for a decision which it did not make. MarkMonitor regrets that the EPDP remains in doubt about this possibility, and we note that it is understandable that Contracted Parties desire to retain control of decision making for which they carry legal liability. Encouragingly, ICANN has expressed willingness to undertake this central role, so long as the law supports this arrangement without ICANN being required to indemnify Contracted Parties. To resolve this stalemate, MarkMonitor encourages ICANN and the EPDP to obtain the legal confirmation necessary to support the centralized model as soon as possible.
Significant change required: changing intent and wording
MarkMonitor notes that many more types of requests need to be automated for the SSAD to be viable, especially including IP-related requests and requests related to cybersecurity. We note that IP is also a fundamental right under the EU Charter of Fundamental Rights, and that IP-based requests are grounded in the requestor’s legal right and/or obligation (in the case of trademark owners who have a legal obligation to police use of their mark). Data subject may not object to processing data “for the establishment, exercise or defence of legal claims,” under GDPR, so requests made for these purposes have a strong basis for automation. Another common-sense example includes data which has previously been disclosed and is known to the Central Gateway to be legal person data.
No, I wish to continue to the next section
Intent and wording of this recommendation requires amendment
Incorporating the comment above about the need for the Central Gateway to make most, if not all, disclosure decisions, MarkMonitor notes that Section b) should end, “criteria for centralized decision making or automatic disclosure.”

MarkMonitor appreciates that the concept of the Central Gateway assisting the Contracted Parties by making recommendations, but we reiterate that the best way to assist Contracted Parties is for the Central Gateway to make the decisions. It’s unclear which disclosure request types, if any, would best be handled in a decentralized manner by Contracted Parties.

MarkMonitor notes that some requests are urgent, and accordingly we appreciate that those requestors with urgent requests can characterize them as such. Again, we note that automating as many requests types as possible will reduce the need for urgent manual review.

Finally, MarkMonitor appreciates that complaints for erroneous denials may be made to ICANN Compliance. However, it is clear that further policy development work is needed to ensure that Compliance has the tools and authority needed to ensure that incorrect disclosure decisions are overturned, and data access is provided where it was erroneously denied.
Support intent of recommendation with edits
MarkMonitor notes that Service Level Agreements (SLAs) are important to ensuring consistent SSAD performance and user experience, and we think it is reasonable to expect that service levels will improve over time. The proposed average five-day SLA will be too long for many request types, including for example phishing remediation, which is measured in hours, not days. Again, we note that automating as many request types as possible will reduce the number of manual requests and enable faster service levels.
No, I wish to continue to the next section
Support intent of recommendation with edits
MarkMonitor finds the Acceptable Use Policy elements to be reasonable. We note that for ease of use, the SSAD should enable these representations to be made by checking a box or an equivalent automated means (if the SSAD is available via API, for example).
Support intent of recommendation with edits
MarkMonitor notes that this recommendation is missing a requirement for the RDS data to be disclosed, unless applicable law (e.g. data protection law) applies.

MarkMonitor supports the section h) requirement for registrars to provide explicit notice to registrants about the types of third parties that may process their data. This notification is important to setting registrant expectations (for all registrants, not just “data subjects” as included in section h), which should read “registrants”) and compliance with data protection law for natural person registrants.
Support intent of recommendation with edits
MarkMonitor cautions that many legitimate users of the SSAD will require high query volumes. These high volumes might need to be submitted all at one time, for example in the case of a cybersecurity researcher investigating an active botnet. Accordingly, the SSAD should be sufficiently provisioned to meet these legitimate high-volume needs, and legitimate requestors must not be throttled, denied, or de-accredited for legitimate use.
Support intent of recommendation with edits
MarkMonitor supports the need to have terms of use of the SSAD system. These terms should be developed and approved by the broader ICANN community, including representatives from organizations representative of SSAD end users. MarkMonitor suggests that the standard for indemnification should not be mere “misrepresentation” but would more appropriately be based on the “intentional, reckless or willful misrepresentation” standard.
Support recommendation as written
MarkMonitor supports the need for appropriate data retention polices.
Intent and wording of this recommendation requires amendment
MarkMonitor believes that reliable access to accurate and up-to-date RDS data is critical for ICANN’s mission: to ensure the stable and secure operation of the global DNS. ICANN cannot act as the “internet police” to carry out this mission completely by itself. Rather, ICANN’s stability and security mission passively benefits from parties like IP owners, law enforcement, cybersecurity professionals, and consumer protection agencies using RDS data in pursuit of their own objectives. This activity has benefited ICANN and the larger internet community for decades without appearing as a line item on ICANN’s balance sheet. The costs to deliver this benefit to the DNS have historically been borne by: a) RDS users’ operational efforts; and b) Contracted Parties providing a WHOIS service, which is paid for by fees from registrants, both of which benefit from a stable, secure DNS.

The mere addition of a centralized ICANN component should not turn the current cost distribution scheme on its head. MarkMonitor submits that costs to run the SSAD should continue to be distributed across the beneficiaries of a stable, secure DNS, including registries and registrars, and registrants who fund their domain name businesses. ICANN should take on a budget line item in recognition of the importance of this work to furthering its mission. That said, MarkMonitor and many of our clients have expressed a desire to pay their fair share of the new cost required to enable this centralized response to data protection law, primarily in the form of accreditation fees.

MarkMonitor notes that several anticipated types of SSAD users may be unable to pay accreditation and/or per-query fees, including small businesses, governmental agencies, and non-profit and academic cybersecurity researchers. They must be able to use the SSAD without prohibitive costs.
Support recommendation as written
MarkMonitor supports automation wherever possible, and supports this recommendation, noting that Recommendation 7 requires significant development of automated use cases.
No, I wish to continue to the next section
Support recommendation as written
Intent and wording of this recommendation requires amendment
MarkMonitor supports robust audit requirements, especially for transparency and accountability. Accordingly, MarkMonitor notes that Contracted Party auditing is an important oversight needed in this recommendation.
Intent and wording of this recommendation requires amendment
With the added input from the Belgian DPA that a centralized model is a “better, ‘common sense’ option in terms of security and for data subjects”, the EPDP should complete its work based on such a centralized model. This could eliminate the need for such a mechanism to gradually shift the SSAD toward greater centralization.
This Mechanism, if it exists, must represent the entire ICANN community, and not only the GNSO. It should consider perspectives of SSAD users including law enforcement, cybersecurity, intellectual property owners and agents, and other types of end users.

The Mechanism’s remit should be to act unidirectionally toward centralization and automation of all cases possible under the law, and the Mechanism must not be able to unwind centralization established by the EPDP without objective evidence of legal risk. It must have sufficient resources to obtain the legal clarity required to justify the centralization of more use cases over time.
The challenge in developing such a Mechanism is that it must be able to require automation for new request types without that power crossing “the picket fence” or constituting “policy making” under the GNSO’s remit. The challenge associated with creating such a unicorn further evidences that a centralized SSAD is better.
Support implementation guidance as written
In its work toward developing a hybrid model, the EPDP team appears to have created a false binary of “automated disclosure” vs. “Contracted Party decision making” where a third option is needed. The Central Gateway should be able to make most, if not all, decisions by itself. The Central Gateway, if required to make all disclosure decisions, will be incentivized to automate as many decisions as possible, which is advantageous for all the reasons listed above. If the Central Gateway is not comfortable automating certain decisions, the Central Gateway must be able to make a manual disclosure decision which will be binding on the Contracted Party. The Central Gateway must be able to compel the Contracted Party to provide the underlying RDS data to the Central Gateway if the Central Gateway requires the data to make a disclosure decision. In addition to relief from the operational burden, the benefit to Contracted Parties in this scenario is stronger evidence of data controllership by the Central Gateway, which further diminishes Contracted Parties’ liability for disclosure decisions made by the Central Gateway.
Thank you for your consideration of these comments on behalf of MarkMonitor and our clients.

Sincerely,



Brian J. King
Director of Internet Policy and Industry Affairs
45
3/23/2020 13:13:47Nat Kopcyk
M3AAWG- Messaging Malware and Mobile Anti-Abuse Working Group
No
No, I would like to continue to the next section
No opinionNo opinionNo OpinionNo OpinionNo opinionNo opinion
Significant change required: changing intent and wording
Preliminary Recommendation #7. Authorization for automated disclosure requests

In order to be effective, the SSAD system (as defined in the initial report) must support additional use cases that can be fully automated above and beyond the two currently specified (in Jurisdiction LEA and URS/UDRP due process). These must include use cases related to the needs of properly Accredited cybersecurity and anti-abuse investigators.

We note that additional use case review will be the subject of further discussion by the EPDP Phase 2 working group. In our review of the “Working Draft Use Case Candidates for Possible Automation”, we are encouraged that Use Case #7 “Identify infrastructure involved in botnets, malware, phishing, and consumer fraud” will be considered and believe strongly that an SSAD system that did not include this (or a similar) use cases would not address the needs of accredited cybersecurity and anti-abuse investigators.
No, I wish to continue to the next section
No opinion
Intent and wording of this recommendation requires amendment
Preliminary Recommendation #9. Determining Variable SLAs for response times for SSAD

The definition and enforcement of SLA associated with response times is of high importance to ensuring a workable and effective SSAD system. We note that the ability of accredited cyber-security investigators to tag their requests as “Urgent Requests” is currently not possible given the current definition. At best it is unclear:

“The criteria to determine whether it concerns an urgent request are limited to circumstances that pose an imminent threat to life, serious bodily injury, critical infrastructure (online and offline) or child exploitation.”

Given most campaigns to attack internet users [consumers] are short lived by design, a maximum response time of 5 business days is neither acceptable nor sufficient. By then the damage will have been done. As such the definition of “Urgent Requests” must be updated to include the important work of cybersecurity investigators.

We suggest adding the following language to make it clear that accredited cybersecurity researchers can submit requests that have been tagged as Urgent.

“For the avoidance of doubt, this includes issues related to malware, Botnets [and their command and control systems], phishing, pharming and abuse related to consumer fraud.”

Finally, we note that the SLAs defined in Recommendation #9 focus on response times only. In order to ensure transparency of the system in addition to allowing accountability to the community there must exist a mechanism to measure the rate of disclosure of RDS data across all disclosers. As such an SLA that measures and tracks disclosure rates must be added to this recommendation. The data associated with this SLA must be routinely audited and reported publicly.

No, I wish to continue to the next section
No opinionNo opinion
Intent and wording of this recommendation requires amendment
Preliminary Recommendation #12. Query Policy

In the course of investigations, especially those of a global nature, it is often necessary to request many thousands of requests for Registration data from the SSAD system. While we appreciate the need for any system to protect itself from abuse of all kinds, we are concerned that the definition of “abusive use” of the SSAD, specifically point #4, may inadvertently interfere with some investigations. E.g.

Storing/delaying and sending high-volume requests causing the SSAD or other parties to fail SLA performance. When investigating abuse based on this specific behavior, the concept of proportionality should be considered.

Query policy limits enforced by the SSAD must not impede the access required by accredited investigators to detect, attribute and mitigate abuse on a global scale. The receipt of requests at this scale must not result in throttling or result in a situation where legitimate requests are rejected.
No opinionNo opinion
Intent and wording of this recommendation requires amendment
Preliminary Recommendation #15. Financial Sustainability

M3AAWG is very concerned that the use of the SSAD may involve per transaction/requests charges. While we do not object to reasonable fees to ensure proper accreditation of members of the cybersecurity community, we would object to any financial sustainability model that may impose any per-transaction fees related to requests required during the course of a legitimate investigations.
No opinion
No, I wish to continue to the next section
No opinionNo opinion
Support intent of recommendation with edits
Preliminary Recommendation #19. Mechanism for the continuous evolution of the SSAD

The need for a mechanism that ensures the SSAD system can evolve at Internet speed is a very important concept and policy must exist to support it. It is equally important that transparency, accountability and full participation by all stakeholders be assured and as such we insist that any mechanism involved in defining how the SSAD will evolve include stakeholders outside of the GNSO, including the SSAC, GAC and ALAC.
In addition, decisions that result from this mechanism must not be subject to a vote from the GNSO Council that does not include the Advisory Committees.
No opinion


M3AAWG, the Messaging, Malware and Mobile Anti-Abuse Working Group, appreciates this opportunity to comment on the Initial Report of the Temporary Specification for gTLD Registration Data Phase 2 Expedited Policy Development Process (https://gnso.icann.org/en/issues/epdp-phase-2-initial-07feb20-en.pdf). We make these comments in our capacities as cybersecurity professionals and researchers committed to ensuring the security and stability of the internet, including the domain name ecosystem.

This issue is very important to M3AAWG members. Our 2018 Joint Survey published jointly with the Anti-Phishing Working Group found that changes to WHOIS access following ICANN’s implementation of the Temporary Specification is significantly impeding cyber applications and forensic investigations and allowing more harm to victims. M3AAWG appreciates the hard work of the EPDP Phase 2 team and the progress they have made to date. The successful completion of this policy and the ultimate implementation of a workable System for Standardized Access/Disclosure (SSAD) of Registration Data is key to organizations and individuals, including many of our members, that require access to registration data in order to detect threats, investigate new attack vectors and to understand trends aimed at protecting users and the Internet as a whole. This includes law enforcement authorities, both civil and criminal, who rely on the analysis and coloration of Registration Data obtained by private sector researchers and security. Failure to allow these professionals to access this data will threaten the security, stability and resiliency of the Internet as a whole and result in higher abuse rates, more harm inflicted on users and result in more criminal impunity on a global scale.


Given that context, M3AAWG has identified the following preliminary recommendations that represent the greatest concern to our members.
46
3/23/2020 13:41:32Danielle Rutherford
ICANN Policy Support for the SSAC
Yes
I am providing input on behalf of the Security and Stability Advisory Committee (SSAC)
No, I would like to continue to the next section
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Support Recommendation as written
Automation of as much of the request and disclosure process as is allowable under GDPR or similarly applicable regulations is in the best interest of both the requestor and the data controller.

The SSAC supports this recommendation and stresses the importance of the implementation guidance. As with any software, the ability to iterate and improve is vital. We view the proposed hybrid model as a marked improvement over the current disjointed and unpredictable situation, and one that will need to evolve as all parties learn and get experience over time to determine improvements needed.
No, I wish to continue to the next section
Support recommendation as written
Intent and wording of this recommendation requires amendment
The SSAC advises that the proposed definitions and timelines for the handling of the “Priority 3” requests need to be adjusted.

The Initial Report proposes that:
In Phase 1: cybersecurity requests are SSAD Priority 3 requests that must be fulfilled by registrars within five (5) business days, while URS requests are Priority 2 and must be fulfilled by registrars within two (2) business days .
In Phase 2: the SLAs are relaxed, and cybersecurity (Priority 3) requests must be fulfilled within (10) business days. (Pages 32-33)

These targets are misaligned with the reasons that the SSAD is being created. Cybersecurity requests are usually a high priority. They will usually be operational in nature and are about preventing active and ongoing harm to multiple victims of the public during malware and phishing attacks, etc. Nor are operational cybersecurity requests less urgent than URS requests. Further, the overall model for the SSAD assumes that cybersecurity requests will be made by accredited parties, within an accountable system, thus making the need for an extended review period moot. SSAC recommends that operational security requests (by accredited parties) be moved to Priority 2. If the volume of cybersecurity requests is of concern to the Contracted Parties, then a compromise for response within three (3) business days would be reasonable.

Requestors and contracted parties will gain confidence and improved efficiency over time, and so there is no reason for the response times to get longer and more relaxed over time. Thus it does not make sense to increase the SLA from Phase 1 to Phase 2 for any priority level of requests - they should stay the same or decrease between phases for the same priority. It may prove useful to have these SLAs reviewed by the standing mechanism (Rec #19) over time to ensure that the recommended SLAs are reasonable, and if they can be improved over time with automation and operational experience.

Cybersecurity use cases include both operational requests as mentioned above and those intended for longer-term research. In the latter case, where there is not an ongoing threat or attack, the need for data is less timely and could be considered a Priority 3 request. The SSAC notes that these separate use cases may need further delineation in order to put them in their appropriate priority classes, but that in general, they are both covered under Rec #4 ((iii) consumer protection, abuse prevention, digital service provider (DSP) and network security). The ePDP may want to delineate these in its preliminary work on automation, where various use cases that fall under Rec #4 are being more fully explored.
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support recommendation as written
Support recommendation as written
Intent and wording of this recommendation requires amendment
The EPDP engaged in discussions about providing guidance on “financial sustainability.” This topic is out-of-scope, is not contained within the ePDP Charter. This sideline effort and the time dedicated to it at the expense of critical issues raised in the charter represents a fundamental failure in the work of this ePDP. The SSAC is concerned that critical questions will remain unanswered.

These types of issues are typically driven by a directive of a charter for a policy group or by an implementation review team.

The SSAC thus first makes the following recommendations:
Recommendation 1: All work on “financial sustainability” should be suspended, text regarding it should be removed from the Phase 2 Final Report, and any work developed so far be passed along to either the subsequent implementation review team or added to a follow-on policy working group’s charter.
Recommendation 2: Future cross-community PDP’s should be required to stay entirely within the remit of their charters, regardless of the desire of a majority of participants to explore other areas. If such areas are identified by an ePDP (or PDP), then the charter must be revisited, modified and agreed by participating groups prior to significant effort, time, and expense being applied to a non-charter area.

Should the working group insist on continuing working on this non-charter item, the SSAC points to prior advice it has provided in this area for guiding this work. In SAC101v2: SSAC Advisory Regarding Access to Domain Name Registration Data, section 5.4, the SSAC provided extensive guidance for this type of work that would include efforts far more substantial than those undertaken by the ePDP to date, including a formal assessment process as part of a full PDP that would explore all relevant issues. In particular:

SSAC recommends that the initiation of charges for RDDS access, or any significant future changes in fees for RDDS access, must include a formal assessment of user impacts and the security and stability impacts, and must be conducted as part of a formal Policy Development Process (PDP).

While it is important that incremental costs to registrants not be tied directly to disclosure costs in order to be compliant with GDPR and other privacy laws, it is also important that the costs of the overall system for domain registration and management be ultimately borne by domain registrants taken as a whole, as a part of the assumed costs of said services. Such costs should include disclosures to third parties with rights to obtain redacted data in order to fulfill legitimate SSR activities and potentially other legal activities (e.g. rights protections) that fall outside SSAC’s scope of activities. The overall SSR of the DNS system requires the ability to access such data to enable communications with the owners of compromised resources as well as the determination of fraudulent and malicious activities that enable the suspension of registration services obtained by criminal actors.
Support recommendation as written
As stated in our comments on Recommendation #7, automation to the extent possible and permissible is essential and should be pursued. The SSAC has previously commented on the importance of automation in accessing RDDS data. In SAC101v2: SSAC Advisory Regarding Access to Domain Name Registration Data, section 3, we explain that numerous critical cybersecurity purposes...

...often require fast, automated access to domain registration data. The data is used by systems that must react quickly to security incidents (such as the maintenance of reputation lists used in firewalls), or because large numbers of records are needed due to the sheer volume of security incidents that occur each day

It is therefore critical that the SSAD system be engineered with the data processing activities and mechanisms as outlined in this recommendation. It will be much easier to add, remove, modify, or improve aspects of the SSAD system and the data request, review, and disclosure process if this is done. The SSAC stress this as a critical piece of implementation guidance to the implementation review team (IRT).
No, I wish to continue to the next section
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
The SSAC strongly supports the concept and rationale behind recommendation 19, the creation of a mechanism for the evolution of SSAD. ICANN has two primary methodologies for creating processes, requirements, and accountability for contracted parties to achieve operational and policy goals: contracts and consensus policy. Neither of these tools is particularly well-suited to being able to adjust the requirements of an evolving SSAD ecosystem where both data requestors and data controllers will be developing capabilities, learning and maturing effective processes, and continuously seeing changes in data request types and volumes. Those are the natural elements of a brand-new system in any environment. Further, as different types of abuse or operational needs manifest over time where new legitimate uses of data may come to light, it will be important to incorporate those into the standard operations of the SSAD. This recommendation provides a realistic foundation to create a process for making such updates without having to resort to the slow and protracted processes of contract negotiations or a PDP, and asks for inputs on how this may be feasible using existing processes within ICANN as a model.

The SSAC notes that there does not seem to be a current ICANN process that closely matches the one contemplated by this recommendation. There are some small, standing committees set up for various technical issues that may provide some guidance (e.g. IDN-related implementations, RSEP reviews) and the IRT process itself could be looked at as a basis for creating a “standing” IRT of some sort. Regardless of the chosen mechanism, the scope of the work it can do and recommendations it provides must both be narrow in their application yet enforceable under existing policy and contractual terms. Thinking about an appeals process or other accountability measures may assuage some groups’ concerns about such a mechanism being either under or over-powered depending on one’s particular issues. Finally, it should be noted that this is not a new concept, as such a mechanism was envisioned by the Expert Working Group on gTLD Directory Services in its final report. Recommendation set 4 stated that “The RDS must be designed with the ability to accommodate new users and permissible purposes that are likely to emerge over time,” and proposed a multi-stakeholder review board for this purpose. The ePDP members may wish to review this work to assist their own effort.
Support implementation guidance as written
Additional comments posted by SSAC on SAC-111 https://www.icann.org/en/system/files/files/sac-111-en.pdf
47
3/23/2020 13:43:38Zoe BonythonRrSG No
No, I would like to continue to the next section
Support Recommendation intent with wording change
The definition for “Accreditation” refers to a user being approved to gain access to the SSAD; this should be reworded as there is no non-public registration data contained in SSAD to access, and “accreditation” should instead refer to the user eligibility for making disclosure requests.

The recommendation includes credentials for an entity (organization) used by several individuals employed there, that is bad security practice. Individual users should be accredited.

Who is going to build an accreditation service that complies with these byzantine requirements? The implementation will be a significant amount of work and likely expensive

Recommendation 2 is better formatted to explain the accreditation process and reasoning behind it, so maybe Rec 1 can be adjusted to align with Rec 2 (same section categories, etc)
Support Recommendation as written
Support Recommendation as written
Support Recommendation intent with wording change
Assertion of one of these specified purposes does not guarantee disclosure in all cases or disclosure of all requested data elements, which will depend on evaluation of the merits of the specific request, compliance with all applicable policy requirements, and the legal basis for the request.
Support Recommendation as written
Support Recommendation intent with wording change
The first sub-point under Item 4 should be adjusted; “provided” should be changed to “demonstrated”:

Has the requestor demonstrated a legitimate interest or other lawful basis in processing the data?

Written as 'provided' it could be a claim with no evidence to back it up. Demonstration requires evidence.

The final point of Item 4 should be modified; it says “nor can refusal to disclose be solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name.” This should be removed entirely, as issues related to content on a website should not be addressed with the Registrar or Registry.

Point 6 should be reworded to align with point 5 intro section:

6. The applicable lawful basis and whether the requested data contains personal data for the Contracted Party to determine if the meaningful human review , similar to the requirements under GDPR’s 6.1.f, as described in paragraph 6 below is applicable and proceed accordingly.

Change to:

6. The application of meaningful human review and factors considered in bullet point #5 SHOULD be revised as appropriate to address applicable case law interpreting GDPR and other relevant data protection regulations, guidelines issued by the EDPB, or revisions to GDPR or other relevant laws that may occur in the future.
Support Recommendation intent with wording change
Proposed change of “can” to “MUST” in the opening line of this Rec:

For disclosure requests for which it has been determined that these MUST be responded to in an automatic fashion

These 3 things are only being done for the ones that ARE handled automatically, not for all possible requests which CAN be.

The concluding paragraph should be adjusted for clarity:

With respect to disclosure requests that would be sent to a Contracted Party for meaningful human review
No, I wish to continue to the next section
Support intent of recommendation with edits
Any recommendation regarding disclosure must remain non-binding.

The language around CP response timing is vague (“without undue delay”) but will be addressed within our comments on the SLA recommendation. Same with which types of requests are to be handled automatically.

Urgent SSAD Requests should be limited to LEA or their equivalent only. If a non-LEA user has knowledge of circumstances that pose an imminent threat to life, serious bodily injury, critical infrastructure (online and offline), or child exploitation, they should engage the appropriate LEA.

Maintaining a “dedicated contact” is vague, needs clarity. Email? Phone?

ICANN Compliance review must be limited to confirming that the request review process created via this EPDP is adhered to by all participants; Compliance must not become the arbiter of disputed disclosure responses, and so the mention of their involvement in Rec 8 should be revised. ICANN Compliance must not be permitted to question or overrule the Contracted Party’s review of the disclosure request.

If the Recommendation intent is that ICANN Compliance will judge Contracted Parties’ responses and possibly overrule a decision, then the RrSG level of support on this Recommendation will instead be “Intent and wording of this recommendation requires amendment”.
Support intent of recommendation with edits
See Below
SLA for Priorities 1 and 2 make sense. The proposed SLA matrix for Priority 3 is confusing and we don't understand the difference between response targets and compliance targets.

We note that SSAD users, including requestors and Contracted Parties, do business in a variety of languages (not only English). These SLAs may adversely impact requestors and data controllers working in different languages, causing an inappropriate barrier to achieving SLA compliance; the SLA should have flexibility to accommodate requests that cross language barriers.

We further note that the ‘business day’ should be calculated based on the responding Contracted Party, rather than the requestor or the Central Gateway’s location.
No, I wish to continue to the next section
Support recommendation as written
Support intent of recommendation with edits
The opening section is unclear. It should instead be “The EPDP Team recommends that the following requirements are applicable to any automated responses provided by SSAD, and to Contracted Parties when disclosing personal data.”

We note that all policy recommendations in the report (once adopted and implemented) are subject to ICANN Compliance enforcement, and this need not be called out specifically in this recommendation.
Support intent of recommendation with edits
Regarding the recommendation that “the requestor MAY seek redress via ICANN org if it believes the determination is unjustified” the RrSG is interested to understand what area within ICANN org would do this work (Compliance, GDD, etc)
Support recommendation as written
Support recommendation as written
Intent and wording of this recommendation requires amendment
If costs are borne by ICANN Org it means that Contracted Parties are paying for it. If Contracted Parties are paying, then ultimately registrants are paying for it. It is admirable that we recommend that the Registrant MUST NOT bear the costs for disclosure of their data, and the SSAD works on a cost-recovery basis, but in reality the operational costs will be significant and the funds will come from the Community (which is really the registrants).

The expectation that use of the SSAD results in lower costs than each Contracted Party handling their requests in-house is entirely erroneous. All the SSAD does is add a layer of work (and thus cost) on to the process which each CP will need to follow anyways in order to respond to disclosure requests as we are required to do

The RrSG eagerly awaits the requested input from ICANN Org regarding expected costs of developing, operationalizing and maintaining the SSAD.

Contracted Parties have maintained that costs be allocated to ICANN for development, individual Contracted Parties for their own integration to the system, and to the users/requestors for costs associated with accreditation (one time fee) and ongoing maintenance (recurring/subscription fee, with a per-transaction fee to prevent abuse).
Support intent of recommendation with edits
This section is unnecessarily complex and in some cases redundant. For example, the second-last paragraph (“The SSAD MUST allow for the automation of an immediate and synchronous response…”) could be shortened to simply indicate that the requestor automatically gets a ticket number.

Regarding “ standardization of disclosure decisions is the baseline objective.” - perhaps we should instead aim to follow the law.

It is crucial that each Contracted Party MUST make their own determination as to which disclosures are handled in an automated manner (if any). As such, the concluding paragraph of this section is paramount and should be moved to the top of the section.
No, I wish to continue to the next section
Support intent of recommendation with edits
Intent and wording of this recommendation requires amendment
The EPDP Phase 2 Team should consider the expense of the auditing requirements and include information on this topic in the Financial Sustainability review.

The auditing section attempts to replace or replicate regulatory requirements to demonstrate compliance with data protection regulation.

There are already relevant and simply-worded sections in the RA (Article 2, Section 2.11) and RAA (Section 3.15), and auditing obligations under relevant data protection law; we should only include in this Recommendation any auditing requirements which are both necessary and not already existent. Auditing of CP activity in the SSAD should instead occur within the context of the existing RA/RAA audit structure.
Intent and wording of this recommendation requires amendment
Recommendations stemming from this Mechanism MUST be focused on implementation only.

This Mechanism cannot create new policies or contractual obligations on Contracted Parties, and MUST instead be referred to the legitimate and relevant Policy Development Process or direct contract negotiation with ICANN Org.

To say “The EPDP Team has indicated a preference to use existing processes and procedures to establish this Mechanism, if possible” is simply unacceptable; regardless of any group’s preference, the existing GNSO Policy Development Process must be utilized.

We do recognize that the SSAD needs the ability to adapt, and we’ll learn more as we go. Data protection regulation is going to expand and our SSAD needs to accommodate that. Regarding the three specific areas of purview for this Mechanism, we agree that the SLA will need review and modification as further experience is gathered. However, we see no need to establish ongoing review of the categories of disclosure requests which may be automated, nor will we need modifications to user categories and disclosure rationales. The work of EPDP Phase 2 Team should be respected and accepted as exhaustive on these subjects.
The existing GNSO Policy Development Process and contract negotiation process should be used.

The only relevant work for the Mechanism is to review and possibly modify SLA obligations, although this may also require contractual negotiation with the Contracted Parties.
Any Policy or contractual changes should be referred to the GNSO for review.
Support implementation guidance as written
What is the purpose of this reporting, and who receives the reports? We cannot address what should be included in the mandatory reporting without understanding the purpose and use of the information.

SSAD reporting may potentially include overall request volume and response times.
● ICANN Org's lack of decisiveness and leadership in acknowledging its roles and responsibilities as a data controller, and instead waiting for "the community" to choose for it, has caused significant uncertainty in this process. Additionally, resources which could have been dedicated to the EPDP team’s work have instead been spent on work bypassing the EPDP team entirely. For future policy work we encourage ICANN Org to ensure that there are not separate parallel work tracks complicating and delaying the policy development process.

● The proposed SSAD model has significant benefits compared to the status quo. The CPH believes that this model gives both requestors and contracted parties improved reliability and uniformity of process while also allowing appropriate protection for non-public gTLD registration data by providing for meaningful human review prior to disclosure.

● Building an audit program will be a lengthy process; we should give priority to getting the SSAD up and running. Additionally, we note that, audits are basic requirements of many data protection laws/regulations, it is not necessary to duplicate those requirements here. These requirements are quite specific and some sections are in conflict with each other or redundant. This is highly complex and needs careful consideration. The report should highlight and leverage the existing audit language in ICANN agreements (Section 3.15 of the RAA and Article 2, Section 2.11 of the RA), rather than creating new auditing language.

● The SSAD is presumably provided in English only. ICANN should consider expanding all aspects of the SSAD to include other languages, thus providing an equitable compliance burden for registrars worldwide. This also relates to potential recommendations from the SSAD to the CP regarding disclosure, which may be misunderstood if provided in a language with which that CP is not familiar, resulting in inappropriate disclosure or non-disclosure of data.

● This is a significant amount of work given to Implementation, and there will be significant costs and work efforts by all teams to complete. This work is important and we should ensure that the IRT is given the resources that they need.

● One difficulty in responding to these recommendations is that concepts are often repeated in multiple places, frequently slightly different. Following public comments the EPDP Phase 2 Team should endeavor to modify the Report so that it is not repetitive or confusing.



48
3/23/2020 14:09:16Lori S. Schulman
International Trademark Association (INTA)
Yes
I am INTA's representative to ICANN.
No, I would like to continue to the next section
Support Recommendation intent with wording change
The INTA recommends the following revisions to the working definitions in Recommendation #1:

Authentication - The process or action of Validating the Identity Credential and Signed Assertions of a Requestor. [ INTA notes that the term “Requestor” is not defined anywhere and appears inconsistently in initial cap or all lower case. Should be defined in this section. We suggest a specific definition for this term below.]

● Authorization - A process for approving or denying disclosure of non-public registration data.
● De-accreditation of Accreditation Authority – An administrative action by which ICANN org revokes the agreement with the accreditation authority, if this function is outsourced to a third party, following which it is no longer approved to operate as the accreditation authority. [Moved this definition to appear in alphabetical order.]

● “Identifier Credential: A data object that is a portable representation of the association between an identifier and a unit of authentication information, and that can be presented for use in Validating an identity claimed by an entity that attempts to access a system. Example: Username/Password, OpenID credential, X.509 public-key certificate.
[We suggest reordering these definitions so they appear in alphabetical order.]
● Identity Provider - Responsible for 1) Verifying the identity of a requestor and managing an Identifier Credential associated with the requestor and 2) Verifying and managing Signed Assertions associated with the Identifier Credential. For the purpose of the SSAD, the Identity Provider may be the Accreditation Authority itself or it may rely on zero or more third parties.
● Requestor – An individual or organization seeking access to non-public domain name registration data through the SSAD.
● Revocation of User Credentials- The event that occurs when an Identity Provider declares that a previously valid credential has become invalid.
● Signed Assertion - A data object that is a portable representation of the association between an Identifier Credential and one or more access assertions, and that can be presented for use in Validating those assertions for an entity that attempts such access. Example: [OAuth credential], X.509 attribute certificate. [Moved to appear in alphabetical order.]


INTA COMMENTS:
The definitions have been only revised slightly and placed in alphabetical order but in general should be expanded significantly to include many additional terms used in the policy text below, as found in the EPDP Phase 2 Team working definitions available in the ICANN documents linked to the Initial Report. The EPDP Phase 2 team’s working definitions, which include draft definitions for terms such as “Legitimate Interest”, “Right of Access”, “Disclosure” would be helpful here. The above definitions appear to come from different sources and take different approaches to defining the components of the SSAD. Some have a legal context or approach (e.g., third parties, signed assertions), while others employ terms typically identified with automation, computing systems or even mathematics (e.g., data object, construct, a value, truth). Many employ terms treated as defined terms (e.g., “Requestor”, “Discloser”) that are not defined here but should be. A proposed definition for Requestor has been inserted based on its use in other definitions above and incorporating the related terms from those definitions in which Requestor was used. It would also be useful to see how SSAD and these terms relate to the existing WhoIs system, perhaps making reference to data objects currently used (e.g., registrant, registrant organization) and how they would be accessed and disclosed under SSAD.
The EPDP Team recommends that a policy for accreditation of SSAD users is established. The following principles underpin the accreditation policy:
a) SSAD MUST only accept requests for access/disclosure from accredited organizations or individuals. However, accreditation requirements MUST accommodate any intended user of the system, including an individual or organization who makes a single request. The accreditation requirements for regular users of the system and a one-time user of the system MAY differ. [Comment: Any differences in such requirements should be provided by the EPDP along with rationale.]
b) Both legal entities and/or individuals are eligible for accreditation. An individual accessing SSAD using the credentials of an accredited entity (e.g. legal persons) warrants that the individual is acting on the authority of the accredited entity.11 [Comment: Are the individuals identified in the signed assertions or are the warranties separate documents or assertions?]
c) The Accreditation policy defines a single Accreditation Authority, managed by ICANN org. This Accreditation Authority MAY work with external or third-party Identity Providers that could serve as clearinghouses to Verify identity and authorization information associated with those requesting accreditation.
d) The decision to authorize disclosure of non-public registration data, based on Validation of the Identity Credential, Signed Assertions, and data as required in preliminary recommendations concerning criteria and content of requests, will reside with the Registrar, Registry or the Central Gateway Manager, as applicable. [Comment: Are these delineated sufficiently in the referenced recommendations; is the decision resident with each of the contract parties listed separate or co-dependent. Need to clarify or link to the recommendations that show which aspects of the authorization decision reside with the Rr, which with the Ry and which with the CGM/ICANN. It should be clarified whether requests will initially be routed to the Rr or Ry or both, or responded to automatically by the CGM where possible.]

Requirements of the Accreditation Authority
e) Verifying the Identity of the Requestor: The Accreditation Authority MUST verify the identity of the Requestor, resulting in an Identity Credential.
f) Management of Signed Assertions: The Accreditation Authority MUST verify and manage a set of dynamic assertions/claims associated with and bound to the Identity Credential of the Requestor. This Verification, performed by an Identity Provider, results in a Signed Assertion.
g) Signed Assertions convey information such as:
o Assertion as to the purpose(s) of the request
o Assertion as to the legal basis of the Requestor
o Assertion that the user identified by the Identity Credential is affiliated with the relevant organization [Comment: Is this one Requestor in which an individual is part of the Requestor due to the affiliation, e.g. an Authorized Representative, or are each of the individual and the entity authorized as separate Requestors? This should be clarified.]

o Assertion regarding compliance with laws (e.g., storage, protection and retention/disposal of data) [Comment: Will these be provided as standards agreed upon under GDPR or identified based on ICANN policy? Will it be a general assertion to comply with applicable laws or will there be more specific compliance requirements provided?]
o Assertion regarding agreement to use the disclosed data for the legitimate and lawful purposes stated [Comment: Will there be a standard set of warranties developed that apply to all users equally, or will there be distinctions based on entity versus individual, or some other status, such as private sector, government, law enforcement, etc.?]
o Assertion regarding adherence to safeguards and/or terms of service and to be subject to revocation if they are found to be in violation
o Assertions regarding prevention of abuse, auditing requirements, dispute resolution and complaints process, etc.
o Assertions specific to the status of the specific Requestor – trademark ownership/registration for example [Comment: Will documents or written evidence have to be submitted or are signed assertions sufficient?]
o Power of Attorney statements, when/if applicable. [Comment: when will such PoA statements be required/applicable? For any user acting on behalf of another party? Only for qualified legal counsel?]
h) Validation of Identity Credentials and Signed Assertion, in addition to the information contained in the request, to facilitate the decision of the authorization provider to accept or reject the Authorization of an SSAD request. For the avoidance of doubt, the presence of these credentials alone DOES NOT result in or mandate an automatic access / disclosure authorization. However, the ability to automate access/disclosure authorization decision making is possible under certain circumstances where lawful. [Comment: What does this mean, under which circumstances and compliance with which law according to which decision maker? In which circumstances? For purposes of disclosure, INTA would strongly support automated or quasi-automated (i.e. human review by the central managing authority for provision of required info) access/disclosure decisions in cases of well-founded allegations of cybersquatting, trademark or copyright infringement, as evidenced in the assertions and supporting materials produced in connection with same/with the disclosure request itself. Other comments regarding automation are provided below.]
i) Defines a baseline “code of conduct”12 that establishes a set of rules that contribute to the proper application of data protection laws - including the GDPR, including:
o A clear and concise explanatory statement.
o A defined scope that determines the processing operations covered (the focus for SSAD would be on the Disclosure operation.)
o The mechanism that allows for the monitoring of compliance with the provisions.
o Identification of an Accreditation Body Auditor (a.k.a. monitoring body) and definition of mechanism(s) which enable that body to carry out its functions.
o Description as to the extent a “consultation” with stakeholders has been carried out.

The Accreditation Authority:
j) MUST have a uniform baseline application procedure and accompanying requirements for all applicants requesting Accreditation, including:
o Definition of eligibility requirements for accredited users
o Identity Validation Procedures
o Identity Credential Management Policies: lifetime/expiration, renewal frequency, security properties (password or key policies/strength), etc. [Comment: INTA would prefer longer lifetime/periods for accreditation (subject to audit) and no/low cost accreditation / cost recovery model.]
o Identity Credential Revocation Procedures: circumstances for revocation, revocation mechanism(s), etc. [see also “Accredited User Revocation & abuse section below]
o Signed Assertions Management: lifetime/expiration, renewal frequency, etc.
o NOTE: requirements beyond the baseline listed above may be necessary for certain classes of requestors.
k) MUST define a dispute resolution and complaints process to challenge actions taken by the Accreditation Authority.
l) MUST be audited by an auditor on a regular basis. [Comment: How often? This should be defined more specifically.] Should the Accreditation Authority be found in breach of the accreditation policy and requirements, it will be given an opportunity to address the breach, but in cases of repeated failure, a new Accreditation Authority must be identified or created. Additionally, accredited entities MUST be audited for compliance with the accreditation policy and requirements on a regular basis; (Note: detailed information regarding auditing requirements can be found in the Auditing preliminary recommendation).
m) MAY develop user groups / categories to facilitate the accreditation process as all Requestors will need to be accredited, and accreditation will include identity verification.
n) MUST report publicly and on a regular basis on the number of accreditation requests received, accreditation requests approved/renewed, accreditations denied, accreditations revoked, complaints received and information about the identity providers it is working with.
[Comment: As this section appears to be similar in summarizing the process and features addressed above the same comments apply regarding the need for clarification of standards and consistent use of terms to follow the process.]

Accredited User Revocation & Abuse:
o) Revocation, within the context of the SSAD, means the Accreditation Authority can revoke the accredited user’s status as an accredited user of the SSAD. A non-exhaustive list of examples where revocation may apply include 1) the accredited user’s violation of the code of conduct, 2) the accredited user’s abuse of the system, 3) a change in affiliation of the accredited user, or 4) where prerequisites for accreditation no longer exist. [Comment: Per the comments above regarding the legal entity Requestor that has an affiliated individual, does a dissociation of one authorized representative automatically result in the revocation of an entity’s Accreditation? Presumably this would not be the case for the legal entity, but may be the case for the individual – but this should be clarified. In addition, we reiterate that what constitutes an abuse of the system and/or a code of conduct violation must be made explicit. How is abuse of the system defined? How does it differ from violating code of conduct? We would also suggest that the EPDP team provide further details regarding the development of a code of conduct, when and how that would take place, and whether it would be necessary to have a separate code of conduct or whether a code of conduct could be built in to the terms of use for the SSAD along with an acceptable use policy and privacy policy. Regardless, development of the code of conduct / terms should involve all SSAD stakeholders.]
p) A mechanism to report abuse committed by an accredited user MUST be provided by SSAD. Reports MUST be relayed to the Accreditation Authority for handling. [Comment: How will abuse be defined and what verification/validation process will be used to assure that a claim of abuse is valid, legitimate, etc.?]
q) The revocation policy for individuals/entities SHOULD include graduated penalties. In other words, not every violation of the system will result in Revocation; however, Revocation MAY occur if the Accreditation Authority determines that the accredited individual or entity has materially breached the conditions of its accreditation and failed to cure based on: a) a third-party verified complaint received; b) results of an audit or investigation by the Accreditation Authority or Accreditation Authority Auditor; c) any misuse or abuse of privileges afforded; d) repeated violations of the accreditation policy; e) results of audit or investigation by a DPA.
r) In the event there is a pattern or practice of abusive behavior within an entity, the credential for the entity could be suspended or revoked as part of a graduated sanction.
s) Revocation will prevent re-accreditation in the future absent special circumstances presented to the satisfaction of the Accreditation Authority. [Comment: There should be a defined appeals process for any revocation decisions.]

De-authorization of Identity Providers
t) The authorization policy for Identity providers SHOULD include graduated penalties. In other words, not every violation of the policy will result in De- authorization; however, De-authorization may occur if it has been determined that the Identity Provider has materially breached the conditions of its contract and failed to cure based on: a) a third-party complaint received; b) results of an audit or investigation by the Accreditation Auditor or auditor; c) any misuse or abuse of privileges afforded; d) repeated violations of the accreditation policy. Depending upon the nature and circumstances leading to the de-authorization of an Identity Provider, some or all of its outstanding credentials may be revoked or transitioned to a different Identity Provider.
[Comment: As there does not appear to be a process for “authorization” of an Identity Provider (which can be an Accreditation Authority), it may be helpful to clarify how that process would work to enable further comment on de-authorization of Identity Providers.
Accredited entities or individuals:
u) MUST agree to:


o only use the data for the legitimate and lawful purpose stated;
o the terms of service, in which the lawful uses of data are described;
o prevent abuse of data received;
o [cooperate with any audit or information requests as a component of an audit;] [Comment: What is the purpose of bracketed materials, are these subject to change or interim provisions? The brackets should be removed – INTA would support the inclusion of this item.]
o be subject to de-accreditation if they are found to abuse use of data or accreditation policy / requirements;
o store, protect and dispose of the gTLD registration data in accordance with applicable law;
o only retain the gTLD registration data for as long as necessary to achieve the purpose stated in the disclosure request.
v) Will not be restricted in the number of SSAD requests that can be submitted during a specific period of time, except where the accredited entity or individual poses a demonstrable threat to the SSAD. It is understood that possible limitations in SSAD’s response capacity and speed may apply. For further details see the response requirements preliminary recommendation. [Comment: Additional clarification for what would constitute a “demonstrable threat” to the SSAD should be provided.]

Fees:
The accreditation service will be a service that is financially sustainable. For further details, see the financial sustainability preliminary recommendation.

Implementation Guidance

In relation to accreditation, the EPDP Team provides the following implementation guidance:

a) Recognized, applicable, and well-established organizations could support the Accreditation Authority as an Identity Provider and/or Verify information. Proper vetting, as described in j) above, MUST take place if any such reputable and well- established organizations are to collaborate with the Accreditation Authority.
b) Examples of additional information the Accreditation Authority or Identity Provider MAY require an applicant for accreditation to provide could include:
o a business registration number and the name of the authority that issued this number (if the entity applying for accreditation is a legal person);
o information asserting trademark ownership. [Comment: This could be clarified – does this refer to information demonstrating ownership of a trademark by the accredited party or that the accredited party is acting on behalf of a trademark owner (or both)? What kinds of information would this entail? Copy of TM registration / certificate? Power of Attorney or other form demonstrating agency?]

INTA COMMENTS:
In general, INTA supports the concept of requiring additional information regarding standard and readily available electronic data regarding the active status of a trademark registration, but rights holders with valid claims to ownership or the establishment of rights based on pending applications, judicial recognition, or other evidence of common law trademark rights should not be summarily prohibited from qualifying for Accreditation through verifiable accepted means relied upon in their home jurisdiction as a basis for sustaining such rights. INTA looks forward to specific provisions that embody the concepts for additional information requirements noted in Implementation Guidance subsection b) above.
Auditing / logging by Accreditation Authority and Identity Providers

c) The accreditation/verification activity (such as accreditation request, information on the basis of which the decision to accredit or verify identity was made) will be logged by the Accreditation Authority and Identity Providers.
d) Logged data SHALL only be disclosed, or otherwise made available for review, by the Accreditation Authority or Identity Provider, where disclosure is considered necessary to a) fulfill or meet an applicable legal obligation of the Accreditation Authority or Identity Provider; b) carry out an audit under this policy or; c) to support the reasonable functioning of SSAD and the accreditation policy.

See also auditing and logging preliminary recommendations for further details.
Support Recommendation intent with wording change
• Objective of accreditation
SSAD SHOULD [Comment: MUST] ensure reasonable access to RDDS for entities that require access to this data for the exercise of their public policy task. In view of their obligations under applicable data protection rules, the final responsibility for granting access to RDDS data will remain with the party that is considered as the controller for the processing of that RDDS data that constitutes personal data.

Notwithstanding these obligations, the decisions that these data controllers will need to make before granting access to RDDS data to a particular entity, can be greatly facilitated by means of the development and implementation of an accreditation procedure. The accreditation procedure can provide data controllers with information necessary to allow them to assess and decide about the disclosure of data. [Comment: Is this any different than the accreditation procedure outlined above? Or would this section envision a separate channel for access for government entities (including LEA)?]

• Eligibility
Accreditation by a countries’/territories’ government body or its authorized body [Comment: What does this refer to?]would be available to various eligible government entities that require access to non- public registration data for the exercise of their public policy task, including, but not limited to:
• Civil and criminal law enforcement authorities,
• Judicial authorities,
• Consumer rights organizations,
• Cybersecurity authorities, including national Computer Emergency Response Teams (CERTs),
• Data protection authorities

(f) Accreditation procedure
Accreditation would be provided by an approved accreditation authority. This authority
may be either a countries’/territories’ governmental agency (e.g. a Ministry) or delegated to an intergovernmental agency. This authority SHOULD [Comment: MUST] publish the requirements for accreditation and carry out the accreditation procedure for eligible government entities.

• The accreditation authority reserves the right to update what credentials or other material are required for accreditation. [Comment: Which shall not go into effect until the current accreditation period is up for renewal.]

a. Renewal
Accredited/authenticated parties MUST renew their accreditation/authentication periodically. Each accreditation authority SHOULD determine an appropriate time limit. [Comment: Should this not be uniform for all accredited entities? If not, why not?]

B. Data access
• Accreditation is required for a party to participate in the access system (SSAD). Unaccredited parties can make data requests outside the system, and contracted parties should have procedures in place to provide reasonable access. [Comment: These should be required to be at least equivalent to Temp Spec reasonable access requirements and SLAs.]
• Accreditation does not guarantee disclosure of the data. The final responsibility for the decision to disclose data lies with the data controller.
• Any accredited user will be expected to only process the personal data that it needs to process in order to achieve its processing purposes. They will be obligated to minimize the number of queries they make to those that are reasonably necessary to achieve the purpose.
• Accredited entities will be required to follow the safeguards as set by the disclosing system.
• Disclosure of RDDS data to the type of third parties MUST be made clear to the data subject. Upon a request from a data subject inquiring about the exact processing activities of their data within the SSAD, relevant information SHOULD be disclosed as soon as reasonably feasible. However, the nature of legal investigations or procedures MAY require SSAD and/or the disclosing entity keep the nature or existence of these requests confidential from the data subject. Confidential requests can be disclosed to data subjects in cooperation with the requesting authority, and in accordance with the data subject's rights under applicable law. [Comment: There must be defined mechanisms to rectify improper disclosure by accrediting entity or controller of the existence or nature of a confidential disclosure request.]


Please delete this: [In view of their obligations under applicable data protection rules, the final responsibility for granting access to RDDS data will remain with the party that is considered as the controller for the processing of that RDDS data that constitutes personal data.]

Rationale: It implies that the decision to disclose is solely at the controller’s discretion, even if disclosure would otherwise be required under the policy. It is also inconsistent with other sections of the policy (such as the automation recommendations) that require automated disclosure in certain circumstances.

Also – please add the following for clarity:
[This recommendation is intended to apply to governmental bodies at all levels, such as local municipalities, cities, states, and provinces, in addition to countries and territories.]
Support Recommendation intent with wording change
On sub-section (b) – It is assumed that, for the sake of efficiency, such identification and information will be automated once the requestor has input its accreditation credentials and that the requestor will not be asked to manually input such identification and information for each request.

On sub-section (c) – information about the legal rights of the requestor and rationale for request – a threshold should be set, probably a relatively low one, in order to avoid lengthy requests and the need to present the full legal case solely for the purpose of obtaining the data and on the other hand to have a minimal standard that must be met. Much of this can likely be accomplished by the use of check-box selections covering the most common types of legal rights, request rationale, etc.

On sub-section (f) – self designation of the request type should not be the absolute criteria since this is likely to be misused. While the categorization by the requestor can be taken into account, it cannot be the decisive factor. Possibly the centralized system can designate certain priority levels depending on the nature of the request, e.g. criminal issues will be top priority while civil claims that do not involve imminent public harm would not be classified as urgent by default.

It is noted that supporting documentation may be submitted. To the extent that the documentation is not in English, it should be provided which languages are acceptable and which ones require attaching an English translation. In addition, it should be determined what type of translation would be acceptable – any translation, certified translation etc.

Support Recommendation as written
Support Recommendation intent with wording change
A more specific timeframe for acknowledgment of receipt should be set, if such is to be manual, for instance 24 hours. Alternatively, it can be automated and in such case almost immediate, similar to other technological ticketing systems.

Likewise, a timeframe should be set for provision of additional information by the requestor if the Central Gateway Manager determines that a request submitted is incomplete. Three business days could be a feasible timeframe for rectification of such incomplete request.

“The Central Gateway Manager MUST confirm that all required information as per preliminary recommendation #3, criteria and content of request, is provided.” [Comment: Change to active voice: The Central Gateway Manager MUST confirm that the requestor has provided all required information, criteria, and content of the request, as per preliminary recommendation #3.]

Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request.” [Comment: “with a response indicating that the request is incomplete….” Current wording makes it sounds like the CGM is sending an incomplete response. This should be revised to make the intended meaning more obvious.

Significant change required: changing intent and wording
On sub-section (1) we recommend that further information be provided on instances where automated review would be used and in what cases automated disclosure may apply. The current wording is very vague on this point and requires further clarification along with examples of applicable scenarios. Also, this should more appropriately state “legally permissible and technically feasible” rather than “legally and technically permissible”.

On sub-section (2), we recommend further defining which third-party providers may be used by the Contracted Party and what criteria they should meet.

On sub-section (4), we strongly support that disclosure cannot be refused on the basis that there is no legal proceeding at the time since in many cases the information would be required in order to prepare the legal proceeding or determine the relevant party in such proceeding as part of the investigation preceding the actual legal proceedings. Pre-proceeding disclosures will also promote negotiated resolutions of disputes thus avoiding unnecessary filing of formal complaints. It is important to keep in mind always that in this context, we are talking about disclosing information relevant to an investigation or preparation of a legal claim – not prejudging (or asking a contracted party/data controller to prejudge) the merit of such investigation or claim.

In sub-section (5) it states that the “Contracted Party MAY evaluate the underlying data requested once the validity of the request is determined under bullet point #4 above”. This should be changed to a “MUST” and it could be clarified what “bullet point #4 refers to. In addition, use of the term “authorization provider” is unclear and we suggest for the sake of consistency referring to “Contracted Party” unless there is broader set of “authorization providers” evaluating the requests and if so, this should be clearly stated and defined.

In sub-section (5) “assessment of impact” should, in our opinion, encompass impact on all relevant parties and not solely on the data subjects, e.g. the requesting party, average consumers if applicable, etc.

In sub-section (5) “status of the data subject” it is unclear whether minors can register domain names. Even if so, further examples of “other protected classes” should be presented. In our opinion, this information would not necessarily be available to the Contracted Party and this criterion should be further considered.

In sub-section (5) it is not clear how “combined with other data” makes the scope of processing more high risk. Please elaborate on how combining data with other data increases the risk of data not being securely held; if you cannot provide a rationale for this assertion, this element of the recommendation should be deleted.

In sub-section (5) it states “Status of the controller and data subject. Consider negotiating power and any imbalances in authority between the controller and the data subject.” It is not clear how this is relevant when we know the disclosing party, under the proposed system, will be a registry operator or registrar. Please elaborate on why this was included and how it is relevant here.

In sub-section (5), it states “Legal frameworks involved. Consider the jurisdictional legal frameworks of the requestor, Contracted Party/Parties, and the data subject, and how this may affect potential disclosures.” We would suggest that, based on this assessment, if no applicable law would prohibit disclosure, then disclosure should be mandatory.

Significant change required: changing intent and wording
INTA feels strongly that day 1 automation should not be limited to law enforcement in EEA and dispute resolution provider requests. Instead, Disclosure should be fully automated from Day 1 for as many categories of request as is legally permissible. These categories should include as a minimum:
a. Requests from Law Enforcement in a jurisdiction local or applicable to the data subject;
b. Responses to UDRP and URS Providers for registrant information verification;
c. Requests where:
i. the data subject is a legal person [to the extent that such information is not publicly available in whois]; and/or
ii. neither the data subject nor the Contracted Party are subject to EU law [to the extent that such information is not publicly available in whois]; and/or
iii. the data subject has consented to make their registration data public;
d. Requests that are made by officers of the court, made under penalty of perjury, and include a good faith assertion that a clearly identified and protectable intellectual property right is being infringed through use of an identified domain name, should also receive day 1 automation;
e. Requests relating to domains registered in new gTLDs that only permit legal entities to register domain names (e.g. .BANK).
“Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply to the requestor with an incomplete request response, detailing which required data is missing, and provide an opportunity for the requestor to amend its request” should be amended to read “Should the Central Gateway Manager determine that the request is incomplete, the Central Gateway Manager MUST reply with a response indicating that the request is incomplete, detailing which required data is missing, and providing an opportunity for the Requestor to amend its request “

“A Contracted Party MAY retract or revise a request for automation that is not required by these policy recommendations at any time.” Comment: There be some kind of notice period before this would go into effect, otherwise this could unduly prejudice requestors who are anticipating an automated process. The only exception should be if the Contracted Party must change its automation approach immediately by court order or in response to clear legal requirement that automation is not permitted in connection with the particular request or type of request.

Support intent of recommendation with edits

The timescale for sending out the confirmation should be expressed here. Only fully complete requests should be allowed to be submitted to allow for automation. Clarify whether the Requestor will have more than one opportunity to amend its request.

The requirement for the “Central Gateway Manager MUST immediately and synchronously respond with an acknowledgement response and relay the disclosure request to the responsible Contracted Party” conflicts with the “without undue delay” obligation in Recommendation 5. INTA prefers the obligation for an immediate acknowledgement response and relay (within 24 hours).

“and relay the disclosure request to the responsible Contracted Party”… How is this determined? Is it sent to the registrar or registry? Both? At the option of the requestor?

“As part of its relay to the responsible Contracted Party, the Central Gateway Manager MAY provide a recommendation to the Contracted Party whether to disclose or not. The Contracted Party MAY follow this recommendation.” How and when would this be determined? On what basis? Inconsistent Central Gateway Manager guidance could be viewed as prejudicing/advantaging certain parties which could be problematic for the system as a whole.

The disclosure response time should be more specific. In the absence of exceptional circumstances, the timeframe should be a maximum of 72 hours.

Responses should also identify how to appeal a determination or re-submit a request to address or overcome the reasons for denial. The EPDP should also consider the possibility of a lightweight, rapid, third-party dispute resolution system for challenging disclosure denials.

The phrase “imminent threat to life, serious bodily injury, critical infrastructure …” is explicitly intended to extend beyond EEA, but is so broad that it will likely result in disputes between requestors and contracted parties over what should qualify. INTA recommends the EPDP should develop an illustrative list, including for example, child exploitation, human trafficking, terrorism, etc. Apart from a penalty for requestors deemed to have abused Urgent SSAD Requests, there does not appear to be any mechanism to either help clarify this language or address inevitable disputes. Despite the ability to file complaints with ICANN, ICANN contractual compliance department will not insert itself as the arbiter to decide such disputes absent clear guidance on what qualifies and what does not qualify.

Rephrase to "Should the Central Gateway Manager establish that the request is incomplete, Central Gateway Manager MUST reply to the Requestor with a response indicating that the request is incomplete and detailing which data required by policy is missing, providing an opportunity for the Requestor to amend its request".

The timescale for sending out the confirmation should be expressed here. Clarify whether the Requestor will have more than one opportunity to amend its request.

The acknowledgement response MUST include a "ticket number" or unique identifier to allow for future interactions with the SSAD.

“The EPDP Team recommends that if the Contracted Party determines that disclosure would be in violation of applicable laws or result in inconsistency with these policy recommendations, the Contracted Party MUST document the rationale and communicate this information to the requestor and ICANN Compliance (if requested).” If requested by whom? The requestor? Compliance? Anyone?

“ICANN Compliance should be prepared to investigate complaints regarding disclosure requests under its enforcement processes.” What criteria will be used to evaluate these?
Intent and wording of this recommendation requires amendment
All Priority 2 cases should be capable of automation from Day 1.
The Contracted Party should receive the disclosure request from the Central Gateway Manager on the same day that it was filed (as per Recommendation 8.b)
If the Mechanism for the evolution of SSAD identifies additional categories of requests that could be fully automated, the SSAD MUST allow for automation of their processing and the requests MUST be automatically processed and result in the disclosure of non-public RDS data without human intervention if legally permissible.
“It is possible that the initially-set priority may need to be reassigned during the review of the request. For example, as a request is manually reviewed, the Contracted Party MAY note that although the priority is set as 2 (UDRP/URS), the request shows no evidence documenting a filed UDRP case, and accordingly, the request should be recategorized as Priority 3.” Where a UDRP or URS filing is contemplated/imminent this should be sufficient to retain priority 2 status even if the complaint has not yet been filed.
INTA understands it will take some time for contracted parties to come into compliance with any SLA’s that are selected. However, INTA favors a uniform SLA for all priority 3 requests plus a simple contractual compliance grace period over the proposed bifurcated phases, mean response time measurements, and compliance percentage proposals. INTA also strongly supports a maximum 3 business day SLA for Priority 3 requests. Specifically, INTA further recommends that: a) the suggested 3 business day SLA apply to all priority 3 requests, with a six-month contractual compliance grace period for contracted parties to meet this SLA. To the extent that there are different SLAs for priority 3 requests based on phases, it does not make sense that the SLAs would be shorter during the first phase while the contracted party is trying to implement the SLAs and then longer after the contracted party has had more time to implement the system; b)The use of a mean response time and compliance percentage proposals make it impossible for ICANN or the community to hold any individual contracted party accountable for noncompliance. c)Likewise, they make it difficult for any individual contracted party to know whether it has complied with the SLA’s in real-time. Under the proposed process, the contracted party is only able to determine whether it has complied with the SLAs after the fact. ICANN should provide economic incentives for contracted parties with faster mean response times.

“These requests MAY be automatically processed and result in the disclosure of non-public RDS data without human intervention if legally permissible.” How will legal permissibility be determined? Any requests that can be legally automatically processed and result in disclosure of non-public RDS data MUST be. It should not be discretionary or allow for variance between different Contracted Parties. If certain Contracted Parties are automatically granting disclosure for certain types of requests, all other Contracted Parties should be granting disclosure for similarly situated requests either in an automated manner or, if due to resources automation is not possible for a particular Contracted Party, they must still be manually disclosed but with the same disclosure outcome unless there is a legal reason for not doing so (e.g. under local law of the CP).
Intent and wording of this recommendation requires amendment
(a) “For the avoidance of doubt, every request does not have to go through an enforcement procedure; the enforcement mechanism MAY, however, be triggered in the event of apparent misuse.” According to whom? The CGM? A third-party? This could be clarified regarding who can trigger enforcement mechanism regarding “apparent misuse.”
(b) Limiting requested data to only the current RDS will impose a challenge on brand owners and other third-party requestors. In addition to learning the identity of a current domain name registrant, it is very important for a brand owner to learn the approximate date on which that registrant acquired the disputed domain (sometimes through purchase from a prior registrant and thus, different from the domain’s creation date). This is because both the UDRP and URS require a showing of bad faith registration and use, i.e., bad faith at the time the disputed domain name was acquired by the registrant. By limiting requested and disclosed data only to the current information, brand owners may not be able to ascertain whether the registrant’s acquisition of the disputed domain name predates the brand owner’s trademark rights. This could result in the unintended filing of UDRP or URS complaints that have no chance of success. In such instances brand owners, through no fault of their own, could be found guilty of reverse domain name hijacking. In order to avoid this risk, requested data should not be limited to current RDS but should, upon request, be expanded to include archived/historical data as well to the extent such data is available.
(c) The “representations” required by this Recommendation must not be unduly burdensome and should, ideally, be satisfied by a check-the-box list of common reasons for such requests (with a catch-all “Other” checkbox and free text field for stating uncommon reasons). As for the “corresponding purpose and lawful basis for the processing”, the comments set forth pertaining to Preliminary Recommendation #3 “Criteria and Content of Requests” are incorporated here as well.
(e) It is unclear what is meant by the “representation regarding the intended use of the requested data”. If this simply means that the requestor represents that the intended use is valid, then this should be satisfied by a simple checkbox. However, if it’s meaning is intended to be broader and mean that the intended use must be specifically stated, this seems to be redundant to other parts of the process set out in the recommendations. If the latter is the case, then the representation should be satisfied by a standardized check-the-box list of common intended uses (with a catch-all “Other” checkbox and free text field for stating uncommon uses). Further, the “representation that the requestor will only process the data for the stated purpose(s)” should be satisfied with a simple checkbox.
Intent and wording of this recommendation requires amendment
As an initial matter, same comment as above regarding who/how mechanism is triggered regarding “apparent misuse.”

(a) No comment.

(b) Prohibiting historic data and limiting requested data to only the “current data or a subset thereof” will impose a challenge on brand owners See comments pertaining to Recommendation 10 a), which are applicable here as well.

(c) The term “applicable law” should be defined as it is confusing and unduly broad in relation to a contractually-based, multi-national system such as the DNS. Does “applicable law” mean that which is applicable in the jurisdiction of the requestor, the Identity Provider, the registrant, the registrar, the registry, or of ICANN? Or does it mean all of the various laws of all of these jurisdictions?

(d) While there is no objection to logging requests, further details should be specified such as where such logs are to be maintained, by whom, and for how long.

(e) With respect to the “balancing test”, the comments pertaining to the balancing test set out in Recommendation #6, par. 5 are incorporated here as well.

(f) The term “reasonable request” should be defined so as to avoid any improper denials of requested data and any unnecessary delays in processing the same. Should also clarify that the request is by the data subject.

(g) The term “applicable law” should be defined. The comments pertaining to Recommendation 11 par. (c) above are incorporated here as well. Further, while providing a “mechanism under which the data subject may exercise its right to erasure and any other applicable rights” is quite reasonable in principle, care must be taken that this is presented in a neutral manner such that the data subject is neither encouraged to, nor discouraged from exercising any such rights. Nevertheless, any such erasure should be done only after the requested information is provided to the requestor. The right to erasure cannot serve as a mechanism for a cybersquatter or criminal to evade the consequences of its actions.

(h) The “privacy policy for the SSAD and standard language (relating to the SSAD) to inform data subjects” should be developed by the SSAD stakeholders and put out for public comment to ensure the clarity, accuracy, and neutrality of the same. Further, the comments pertaining to Preliminary Recommendation #4 Third Party Purposes / Justifications are incorporated here as well.

(i) It is important that “the nature of legal investigations or procedures” not be limited to criminal investigations by law enforcement or other governmental entities. There are situations where civil investigations may require that requests be kept confidential from the data subject (e.g., where counterfeit goods may be quickly sold or destroyed by a data subject in an attempt at frustrating the enforcement of intellectual property rights). Further, the term “applicable law” should be defined and the comments to Recommendation 11 par. c) above are incorporated here as well.
Intent and wording of this recommendation requires amendment
(a) In defining “abuse or misuse of the system” the comments pertaining to Preliminary Recommendation #1: Accreditation, pars. o) – s) (Accredited User Revocation & Abuse), par. t) (De-authorization of Identity Providers), and to Preliminary Recommendation #8. Response Requirements, par. d) (Abuse of urgent requests) are incorporated here as well.

(b) 1. and 2. The term “High volume” should be defined. Further, although “redress via ICANN” is provided for, it is likely to be slow even in the face of an urgent need for the disclosure of information. Something faster is needed. Reasonable exceptions should be allowed for innocent errors that are neither intentionally malformed/incomplete or frivolous/vexatious. For example, there may be instances where a legitimate requestor submits a single, batched series of requests (e.g., where the same registrant owns a large number of disputed domain names) that are malformed or incomplete due to a minor and unintentional human error. In such situations, the requestor should be given notice of the deficiency(ies) by the entity receiving requests and then permitted an expedited (i.e., 24-hours or less) opportunity to cure them and resubmit the requests. Further, ICANN org” as used in this section should be more specific – should it refer to ICANN Compliance or some other structure within ICANN org?


(c) In addition to “specific domain name[s]”, provision should be made for disclosure, upon request, of all domain names owned by the same registrant who is the owner of the specific domain name that is the subject of the initial request. In UDRP and URS cases one of the stated methods of proving bad faith is to submit evidence of a registrant’s “pattern of conduct” involving the registration of other domain names that are confusingly similar to either the complainant’s or to a third-party brand owner’s trademarks. As such, this can be a critical piece of evidence in a UDRP or URS case. However, in light of widespread masking of registrant information, even with respect to registrants for whom GDPR does not apply, finding evidence of a pattern of conduct through common domain name ownership has become almost impossible. This information is only within the possession of the registrar and registry (or it might be spread across different registrars and registries used by the registrant) and so should be available to accredited Requestors for legitimate and lawful purposes such as protecting the public from harm and protecting the integrity of intellectual property rights. In addition, EPDP should consider introducing some kind of “trusted requestor” program to expedite responses to similarly-situated requests from a trusted requestor based on pre-defined criteria and use cases.

With respect to the statement, in Recommendation 12, that “historical registration data will not be made available via this mechanism”, prohibiting historic data will impose a challenge on brand owners. As such, the comments pertaining to Recommendation 10 a) are incorporated here as well.
Support intent of recommendation with edits
INTA supports the concept of using appropriate agreements, such as terms of use, a privacy policy and a disclosure agreement to provide rights, duties and obligations concerning access and disclosure of data through SSAD. However, such agreements must be carefully drafted and vetted by the community so that they accurately reflect EPDP policy recommendations and not impose additional obligations or duties or provide imprecise access or disclosure rights. All SSAD stakeholders should be involved in developing these agreements. The EPDP should also clarify how a code of conduct would relate to terms of use and the other agreements discussed in this recommendation, and consider whether all of these agreements could be covered under a single terms of use document. INTA recommends the following revisions to Recommendation #13:

The EPDP Team recommends that appropriate agreements, such as terms of use for the SSAD, a privacy policy and a disclosure agreement are put in place that take into account the recommendations from the other preliminary recommendations accurately reflect the recommendations of the final reports of the EPDP Team. These agreements are expected to be developed and negotiated by all SSAD stakeholders, taking the below implementation guidance into account and any such draft agreements will be published for public comment prior to implementation.

With respect to recommendations concerning proposed Terms of Use, INTA believes that a standard of mere misrepresentation to trigger requestor indemnification should be revised to an “intentional, reckless or willful” behavior standard. Misrepresentation is ultimately a vague legal principal without further qualification, such as fraudulent, negligent or innocent, to provided context. Moreover, misrepresentation can include merely misleading statements, including unintentional ones.

“The EPDP recommends, at a minimum, the privacy policy SHALL include:
● Relevant data protection principles, for example,”. Were there supposed to be particular examples listed here?

“Applicable prohibitions Disclosure” Should this say “Applicable prohibitions on Disclosure”? Please clarify

Support intent of recommendation with edits
With respect to Recommendation #14, INTA supports the recommendation “that requestors MUST confirm that they will store, protect and dispose of the gTLD registration data in accordance with applicable law.”

However, the second sentence of Recommendation #14 will create a contradiction if the registration data itself must be retained by applicable law:

“Requestors MUST retain only the gTLD registration data for as long as necessary to achieve the purpose stated in the disclosure request.”

This second sentence appears to be inspired by the GDPR. However, GDPR does not specify retention periods for personal data, which will often be supplied by “applicable law”. Instead, it states that personal data may only be kept in a form that permits identification of the individual for no longer than is necessary for the purposes for which it was processed. This provision of the GDPR is subject to debate and various interpretations when there is a legal right or obligation to keep the personal data. This balancing concept of reasonableness is not (and cannot realistically) be part of Recommendation #14. As such, the last sentence of Recommendation #14 is not needed and could create two conflicting obligations for Requestors. For instance, an investigator may need to keep evidence until a statute of limitations has run, but the purpose of the investigation may end after an arrest is made. The second sentence of Recommendation #14 should be struck.
Support intent of recommendation with edits
INTA agrees that there needs to be a delineation in costs between the development of the SSAD system and its operational costs. INTA further agrees that development costs should be initially borne by ICANN org, and Contracted Parties.

INTA further agrees that the subsequent running of the system should be on a cost recovery basis and that historic costs may be considered. In developing fees for access and accreditation for cost recovery, INTA asserts that fees for one class of user or accreditation applicant cannot be charged that are so high as to circumvent the policies developed by the EPDP Team. For instance, a corporate entity should not be charged a fee that makes access or accreditation an impracticable or expensive undertaking simply because they have large number of trademarks or a greater need for using the SSAD for enforcement purposes. INTA asserts that financial burden on all parties to the system should be equal or at least proportionate.

We would also support allocation of ICANN budget toward offsetting the costs for maintaining the Central Gateway and in general for setting up and maintaining this system.

We would like further specifics regarding the suggested legal risk fund and why such a fund is necessary as part of the costs of this system. All businesses and systems operate subject to some legal risk, so it is not clear why this system necessitates a special fund for its risks.

Finally, this section refers to “input from ICANN Org concerning the expected costs of developing, operationalizing and maintaining the three different models.” Can EPDP clarify what it means by “three different models” as used here?

Intent and wording of this recommendation requires amendment
• Automation of the receipt, authentication, and transmission of System for Standardized Access/Disclosure (“SSAD”) requests as well as automated disclosure of non-public registration data is an important and positive mechanism that will allow more efficient response to DNS abuse. However, the proposed recommendations severely limit the types of disclosure requests to be fully automated on Day 1, such that the potential benefit of automation is denied to many accredited users with legitimate types of disclosure requests.
o See Preliminary Recommendation #7. Authorization for automated disclosure requests, “The EPDP Team expects that the following types of disclosure requests can be fully automated (in-take as well as response) from the start:
 Requests from Law Enforcement in local or otherwise applicable jurisdictions;
 Responses to UDRP and URS Providers for registrant information verification.
o As stated above in the response to Recommendation #7, INTA feels strongly that Day 1 automation should not be limited to law enforcement in EEA and dispute resolution provider requests. Instead, disclosure should be fully automated Day 1 for as many categories of request as is legally permissible.
o Importantly, brand owners’ requests are absent from the EPDP Team’s limited types of automated disclosure requests. INTA feels strongly that this must be revised to include requests by brand owners that go through the accreditation process, outlined in Preliminary Recommendation #1. In the case of an accredited brand owner that requests disclosure of non-public registration data behind a domain where the Requestor has presented a well-founded allegation of infringement of the brand owner’s established intellectual property rights as the purpose for the disclosure request, there is no reason that automation would not be feasible or legally permissible. Accordingly, it is important that the EPDP Team include, at a minimum, requests by accredited brand owners in their list of disclosure requests that can be fully automated Day 1.
No, I wish to continue to the next section
Support recommendation as written
Support intent of recommendation with edits
INTA supports the SSAD having robust audit mechanisms to enable monitoring and compliance with law and with ICANN policy. While INTA notes that Recommendation 18 “expects” that auditing is done to ensure compliance, we note that this expectation in its current form does not use the term “recommend,” nor does it explicitly recommend auditing contracted parties. INTA assumes this to be a drafting oversight, but in the interest of clarity, INTA submits that Recommendation 18 should contain an explicit policy recommendation to audit contracted parties’ compliance with this policy.

We also note that the recommendation states “ICANN org as the Accreditation Authority is not required to audit governmental entities, whose accreditation and audit requirements are defined in Preliminary Recommendation #2.” If ICANN org is not the Accreditation Authority, would a third-party Accreditation Authority be required to audit governmental entities, or would any Accreditation Authority be exempt from auditing governmental entities? What is the rationale for this and for any distinction in auditing requirements as between ICANN org versus a third-party Accreditation Authority when it comes to auditing governmental entities?

This section also states “As ICANN serves as the accreditation authority, existing accountability mechanisms are expected to address any breaches of the accreditation policy, noting that in such an extreme case, the credentials issued during the time of the breach will be reviewed.” We assume this should say “IF ICANN serves as….”
Intent and wording of this recommendation requires amendment
As a threshold matter, INTA questions the necessity of such a Mechanism. INTA notes that the EPDP team decided to deviate from its longstanding preference for a centralized model only as a result of a misinterpretation of a letter received from the Belgian DPA (https://www.icann.org/en/system/files/correspondence/stevens-to-marby-04dec19-en.pdf). With the record corrected that the Belgian DPA actually thinks that a centralized model is a “better, ‘common sense’ option in terms of security and for data subjects”, INTA submits that the EPDP should complete its work based on such a centralized model. (https://www.icann.org/news/blog/icann-meets-with-belgian-data-protection-authority)

Should the EPDP team decide that such a Mechanism remains necessary, the composition of the Mechanism must represent the entire ICANN community, and not merely those interests represented in the GNSO. It is critical that such a Mechanism reflects the needs and interests of SSAD users including governments, cybersecurity investigators, and internet users at large.

If such a Mechanism is developed, it should be chartered with the power and scope to operate in one clear direction: to move as swiftly as possible toward the greatest amount of standardization (by centralization) and automation as legally possible. The Mechanism must not be allowed to undo any requirements for standardization, centralization, or automation developed by the EPDP team without citing clear, unambiguous legal risk associated with the status quo. With this sole exception, its only goal should be to add use cases which can be standardized, centralized, and automated based on new legal clarity. If this Mechanism is intended to act as a future corrective measure addressing the current lack of legal clarity, it must simultaneously have the power to require new request types to be automated without that power being deemed policymaking such that it fall under the exclusive control of the GNSO. INTA urges that great caution must be taken to achieve this end, and INTA reiterates that the difficulty presented here further supports that developing a centralized model at the outset remains preferable.

If it is ultimately determined that the Mechanism is needed, we might look to other forms of standing committees employed by ICANN to continuously examine and recommend improvements to other matters, e.g the IANA Customer Standing Committee, the Empowered Community structure, the GNSO Council Standing Selection Committee, etc. Representation within this Mechanism should reflect the representative makeup of the EPDP itself (including GNSO stakeholders as well as ALAC, SSAC, and GAC) and its guidance could be channeled to the GNSO Council, ICANN Org, and Board, with implementation of any accepted evolutionary guidance handled by a “standing” ICANN Org IRT in coordination with the standing committee Mechanism.
Support implementation guidance as written
INTA strongly supports robust reporting on all measurable aspects of SSAD, with requirements that all registries and registrars, Accreditation Authorities and Identity Providers, and ICANN (and any other parties that may facilitate any aspect of SSAD) maintain metrics data concerning the aspects of the system for which they are responsible, and that ICANN should be required to regularly publish compilations of such data. The types of metrics that should be reported might include total numbers of accredited parties, number of accreditation requests that were denied, total number of disclosure requests made through SSAD, total number of disclosure requests acknowledged within SLA timeframe and total number not timely acknowledged, total number of disclosure requests granted and denied and how many were substantively responded to within SLA timeframe versus beyond this timeframe, and the breakdown of legal bases and purposes for all disclosure requests (both granted and denied). It would also be helpful to make such data available on a per-registry and per-registrar basis. We would be happy to provide further input on a specific reporting program proposal, which should be developed as part of SSAD implementation.

At a high level, the EPDP should revisit the possibility of a centralized SSAD model, in light of apparently inconsistent comments on this subject, calling into question whether such an approach would actually be impermissible under GDPR. INTA would strongly prefer a more centralized/automated approach to SSAD that is more reflective of the historical WHOIS system in terms of querying and disclosure of data.

In any event, the EPDP must present a recommendation for a mechanism for obtaining historical data, to the extent such data is retained by Contracted Parties/ICANN. The EPDP must also present a recommendation for a mechanism for conducting “reverse RDDS” searches to identify all domain names associated with a particular RDS data element (e.g. name or email address). These functions are critical components for many third-party end-users of SSAD, including law enforcement, cybersecurity, consumer protection and intellectual property owners/agents. The EPDP should also specifically recommend automatic disclosure of any data that is not subject to GDPR, including data of legal persons and where the data is otherwise not subject to GDPR on jurisdictional grounds (i.e. no party in the data flow is subject to EU law, including registrant and registrar/registry)
INTA is pleased to submit its responses to the recommendations issued by the EPDP in regard
to the development and implementation of a legally compliant System for Standardized
Access/Disclosure to non-public gTLD registration data ("SSAD"). We are encouraged to see
that the working group has acknowledged intellectual property claims as a legitimate purpose for
requesting registrant data and that an automated intake system is recommended.
We appreciate the hard work and intensive effort that led to these comprehensive
recommendations. However, we feel that there is much work to be done. This is in light of the
concerns expressed by governments and the private sector with regard to expeditious access to
information that is critical to fighting domain abuse and cybercrime. Our specific
recommendations include:
1. The EPDP should revisit the possibility of a completely centralized SSAD model in light
of apparently inconsistent comments on this subject from data protection authorities and
the legal guidance that ICANN has received;
2. Disclosure of registration data should be guaranteed where request criteria have been
met;
3. Automated response to requests is only applicable from Day 1 to requests from law
enforcement and in response to UDRP/URS providers for registrant verification in an
active UDRP/URS proceeding; such automation should be expanded to cover additional
Day 1 use cases including for well-founded allegations of IP infringement, phishing,
fraud and other similar matters of consumer protection;
4. ICANN must fully address how it will ensure consistency in the application of disclosure
request processing by individual Contracted Parties, if the proposed hybrid model is
ultimately retained. Otherwise, the community will be left with a fragmented system with
inconsistent disclosure decisions by individual registries and registrars with no
mechanism for ensuring consistency and sufficiency of responses; and
5. GDPR specifically incorporates balance in terms of protecting privacy versus ensuring
access to data for legitimate third-party purposes; any acceptable SSAD must go further
in recognizing this, including in terms of (a) ensuring underlying data is accurate and up2
to-date (art. 5 of GDPR), (b) ensuring processors/controllers are applying any art. 6(1)(f) balancing test in good faith in recognition of the balance required under GDPR and in support of the legitimate third-party purposes identified in the SSAD proposal and EPDP Phase 1 report to which INTA commented; (c) enabling access to a certain degree of historical data and facilitating reverse correlation capability (i.e. reverse WHOIS/reverse Registrant Data Directory Service [RDDS]) to properly support third-party purposes; (d) recommending either general publication or automatic disclosure through SSAD of data not subject to the privacy protections of GDPR, including data of legal persons and where the data is otherwise not subject to GDPR on jurisdictional grounds (i.e. no party in the data flow is subject to EU law, including registrant and registrar/registry).
Thank you for your consideration of INTA’s comments. If you have any further questions or comments regarding this submission, please feel free to contact Lori Schulman, Senior Director, Internet Policy at lschulman@inta.org or +1(202)704-0408.
Sincerely,
Etienne Sanz de Acedo Chief Executive Officer
About INTA
INTA is a global not-for-profit association with more than 7,200 member organizations from over 187 countries. One of INTA’s goals is the promotion and protection of trademarks as a primary means for consumers to make informed choices regarding the products and services they purchase. During the last two decades, INTA has also been the leading voice of trademark owners within the Internet community, serving as a founding member of the Intellectual Property Constituency of the Internet Corporation for Assigned Names and Numbers (ICANN). INTA’s Internet Committee is a group of over 175 trademark owners and professionals from around the world charged with evaluating treaties, laws, regulations and procedures relating to domain name assignment, use of trademarks on the Internet, and unfair competition on the Internet, whose mission is to advance the balanced protection of trademarks on the Internet.
49
3/23/2020 14:40:29
Council of Europe Data Protection Unit
IGONo
No, I would like to continue to the next section
Significant change required: changing intent and wording
As the Accreditation Authority itself will process personal data, it is recommended that it defines a privacy policy (in which it defines the purpose of the processing of personal data and the application of privacy and data protection principles and applicable laws to its operations) and when it uses outsourced services in ensuring its task the responsibility remains with the Accreditation Authority with regard to the personal data processed. Therefore it is suggested to amend point c) as follows:

c) The accreditation policy defines a single Accreditation Authority, managed by ICANN org which should include a specific privacy policy for the processing of personal data it undertakes. This Accreditation Authority MAY work with external or third-party Identity Providers that could serve as clearinghouses to Verify identity and authorization information associated with those requesting accreditation. The responsibility for the processing of personal data in this latter case shall remain with the Accreditation Authority.

As there is a growing convergence towards a set of high level principles on the protection of privacy and personal data with existing legally binding multilateral treaty, namely the sole global data protection treaty (Convention 108+), it is advisable to change point i) as follows:

i) Defines a base line “code of conduct”[2] that establishes a set of rules that contribute to the proper application of data protection laws - including the GDPR and as enshrined in international public law established by legally binding multilateral instruments - including

It is of high importance that requirements established by the accreditation policy towards accredited users are clear. For that matter it would be beneficial to refer to existing provisions and definitions of legally binding instruments

For the reason of unclarity it is suggested that point a) of the Implementation Guidance is changed as follows:

a) Recognized, applicable, and well-established organizations under the law of the Accreditation Authority could support the Accreditation Authority as an Identity Provider and/or Verify information. Proper vetting, as described in j) above, MUST take place if any such reputable and well-established organizations are to collaborate with the Accreditation Authority.

As logging data are extremely sensitive and confidential in nature, it is recommended that point d) of the Implementation Guidance is amended as follows:

d) Logged data SHALL only be disclosed, or otherwise made available for review on a case-by-case basis, by the Accreditation Authority or Identity Provider with the approval of the Accreditation Authority Auditor, where disclosure is considered necessary to a) fulfil or meet an applicable legal obligation of the Accreditation Authority or Identity Provider; b) carry out an audit under this policy or; c) to support the reasonable functioning of SSAD and the accreditation policy.





Significant change required: changing intent and wording
Support Recommendation intent with wording change
As in different jurisdictions the depth of the disclosure decision would considerably vary according to the type(s) of data requested: i.e. for subscriber information (as per article 18 of the Budapest Convention and subsequent Interpretative Note) requested by a law enforcement authority less criteria would be assessed whereas for traffic or content data higher safeguards would be required (such as an official subpoena, court order, etc). As this may have non-negligible effects on the time during which a request is served, it is recommended to change the wording as follows:

d. affirmation of the purpose of the request and that the request is being made in good faith and that data received (if any) will be processed lawfully and only in accordance with the justification and purpose specified in (c);
e. A list of data elements requested by the requestor and the necessary accompanying official documentation (such as court order, subpoena, etc.) for the disclosure of the data, and why the data elements requested are serving the purpose, are proportionate, adequate, relevant and limited to what is necessary.


Support Recommendation intent with wording change
For clarity it is advisable to add as follows:

• Assertion of one of these specified purposes does not guarantee access in all cases, but will depend on evaluation of the merits of the specific request, compliance with all applicable policy requirements, included but not limited to the one on SSAD, and the legal basis for the request.


No opinion
Support Recommendation intent with wording change
Significant change required: changing intent and wording
Considering the great variety of situations, the automation of the process risks undermining the necessary case by case examination of disclosure requests.

No, I wish to continue to the next section
Support intent of recommendation with edits
As global, regional public health, pandemic cases, may require, it is recommended to amend the text as follows:

Urgent SSAD Requests
f) A separate accelerated timeline has been recommended for the response to ‘Urgent’ SSAD Requests, those Requests for which evidence is supplied to show an immediate need for disclosure (see below). The criteria to determine whether it concerns an urgent request are limited to circumstances that pose an imminent threat to life, serious bodily injury or serious degradation of health conditions, critical infrastructure (online and offline) or child exploitation. Note that the use of ‘Urgent’ SSAD Requests is not limited to LEA.


As per national law definition of critical infrastructure we recommend to change the text as follows:

Implementation Guidance:
a) The Central Gateway Manager MUST confirm that the request is syntactically correct, including proper and valid Authentication and Signed Assertions. Should the Central Gateway Manager establish that the request is syntactically incorrect, the Central Gateway Manager MUST reply with an error response to the requestor detailing the errors that have been detected.
b) Should the Central Gateway Manager establish that the request is incomplete, Central Gateway Manager MUST reply with an incomplete request response to the requestor detailing which data required by policy is missing, providing an opportunity for the requestor to amend its request.
c) Typically the acknowledgement response will include a “ticket number” or unique identifier to allow for future interactions with the SSAD.
d) An example of online critical infrastructure[3] includes, amongst others, root servers; examples of offline critical infrastructure includes, amongst others, utilities, food supply chain, electoral data base, citizenship/identity registration data base, transportation and banking.



Support intent of recommendation with edits
In case of priority 1 requests it would be advisable to limit as much as technically possible the response time to allow immediate action to prevent harm or fraud by competent authorities.

Request Type
Priority Proposed SLA[1] (for discussion) / Compliance at 3 months / 6 months / 12 months
Urgent Requests

“The criteria to determine whether it concerns an urgent request are limited to circumstances that pose an imminent threat to life, serious bodily injury, or serious degradation of health conditions, critical infrastructure (online and offline) or child exploitation.” 1 1 business day, ASAP (within 12 hours)/ 85% / 90% / 95%
No, I wish to continue to the next section
Support intent of recommendation with edits
For consistency purposes it would be useful to change the text as follows:


The requestor:

a) MUST only request data from the current RDS data set (no historic data);
b) MUST, for each request for RDS data, provide representations of the corresponding purpose and lawful basis for the processing, which will be subject to auditing (see the auditing preliminary recommendation for further details);
c) MAY request data from the SSAD for multiple purposes per request, for the same set of data requested;
d) For each stated purpose must provide (i) representation regarding the intended use of the requested data and (ii) representation of procedural, rule of law and data protection safeguards in the accompanying documentation, if required by law (ii) representation that the requestor will only process the data for the stated purpose(s). These representations will be subject to auditing (see auditing preliminary recommendation further details);
e) MUST handle the data subject’s personal data in compliance with applicable law (see auditing preliminary recommendation for further details).

No opinion
Support recommendation as written
Support intent of recommendation with edits

To be more complete it is recommended to add to the list:

The EPDP recommends, at a minimum, the privacy policy SHALL include:


• Transparency requirements
• Data security requirements
• Accountability measures (privacy by design, by default, DPO above certain size, etc)

No opinion
Support intent of recommendation with edits
Since public security shall be treated as an absolute priority, it is recommended that the text is changed as follows:

The EPDP Team recognizes that the fees associated with using the SSAD may differ for users based on request volume or user type among other potential factors. The EPDP Team also recognizes that governments may be subject to certain payment restrictions with the possibility of waiving criminal justice authorities competent in the fight against cybercrime or national authorities responsible for the cyber-security of a country/territory from any charge or fee.


Intent and wording of this recommendation requires amendment

See comments under Recommendation 7 as to the risks of an automation in light of the check and balance that necessarily has to be carried out to disclose the requested data.

No, I wish to continue to the next section
Support intent of recommendation with edits
Support recommendation as written
For Recommendation 17:

For consistency it is advisable to change the text as follows:

e) Logged data will remain confidential and must be disclosed, with the approval of the Accreditation Authority Auditor in the following circumstances:

Support recommendation as written
-
All SSAD entities must receive detailed guidance in due time developed by ICANN consensus policy.
A periodic (2 years) evaluation needs to be put in place.
-
Support implementation guidance with edits
In order to take better care of valid actual need from law enforcement to access non-public data, it is recommended that the text is amended as follows:

The EPDP Team recommends that, consistent with the preliminary recommendation that an SSAD request must be received for each domain name registration for which non-public registration is requested to be disclosed in paying due attention to the urgency of future Priority 1 requests, it must be possible for requestors to submit multiple requests at the same time, for example, by entering multiple domain name registrations in the same request form if the same request information applies.



-
Further attention needs to be paid to the need for a clear legal basis for cross-border requests for and disclosure of data. Reflections in this direction are currently underway within the context of the negotiation of the Second Additional Protocol to the Budapest Convention on Cybercrime.

Additional efforts need to be deployed to determine a minimum level of “data quality” for the purpose of SSAD so as only accurate, up to date, adequate, relevant and not excessive data in relation to the purposes are processed and a full-fledged international transfer policy is developed guaranteeing an appropriate level of protection for the data crossing national borders.
-
50
3/23/2020 15:20:01Eric Rokobauer
Endurance International Group
Yes
Endurance International Group
No, I would like to continue to the next section
Support Recommendation intent with wording change
Please see rationale provided by the RrSG's public comment to this report.
Support Recommendation as written
Support Recommendation as written
Support Recommendation intent with wording change
Support Recommendation as written
Support Recommendation intent with wording change
Please see rationale provided by the RrSG's public comment to this report.
Support Recommendation intent with wording change
Please see rationale provided by the RrSG's public comment to this report.
No, I wish to continue to the next section
Support intent of recommendation with edits
Please see rationale provided by the RrSG's public comment to this report.
Support intent of recommendation with edits
Please see rationale provided by the RrSG's public comment to this report.
No, I wish to continue to the next section
Support recommendation as written
Support intent of recommendation with edits
Please see rationale provided by the RrSG's public comment to this report.
Support intent of recommendation with edits
Please see rationale provided by the RrSG's public comment to this report.
Support recommendation as written
Support recommendation as written
Intent and wording of this recommendation requires amendment
Please see rationale provided by the RrSG's public comment to this report.
Support intent of recommendation with edits
Please see rationale provided by the RrSG's public comment to this report.
No, I wish to continue to the next section
Support intent of recommendation with edits
Intent and wording of this recommendation requires amendment
Please see rationale provided by the RrSG's public comment to this report.
Intent and wording of this recommendation requires amendment
Please see rationale provided by the RrSG's public comment to this report.
Existing GNSO policy development processes
Support implementation guidance as written
Please see comments made by RrSG in their response to this public comment.
Endurance supports the comments provided by the Registrar Stakeholder Group (“RrSG”). Endurance believes the modifications and provided rationale presented by the RrSG will help towards ensuring protection of personal data of domain registrants while also seeking further understanding of what kind of resources would be necessary to develop a standardized system for access and disclosure model (“SSAD”) . Those comments provided by the RrSG that Endurance is most interested are as follows:

- Receiving the requested input from ICANN Organization regarding the expected costs of developing, operationalizing and maintaining the SSAD (Recommendation #15: Financial Sustainability).

- A need to ensure language emphasizing that each Contracted Party must make their own determination as to which disclosures are handled in an automated manner (Recommendation #16: Automation).

- Additional observations provided in order to understand expectations of how long it would take to implement SSAD (and if those discussions have or will take place) and if it will be built to handle multiple languages to accommodate registrars and potential users globally.
51
3/23/2020 15:31:02Brian WinterfeldtWinterfeldt IP GroupYes
This submission is made on behalf of the Global Brand Owner and Consumer Protection Coalition (GBOC), an unincorporated association of about a dozen industry-leading businesses in various market sectors including software, hospitality, food and beverage, and apparel and footwear.
No, I would like to continue to the next section
Support Recommendation intent with wording change
GBOC generally supports this recommendation and believes accreditation is necessary for an effective, efficient and legally sound SSAD.

That said, GBOC would support the addition of a “Trusted Notifier” concept as an additional layer of accreditation/verification/trust for certain Accredited Entities who are demonstrated subject matter experts who have undergone additional vetting. Upon attaining Trusted Notifier status, such requestors should be afforded special privileges in using SSAD, such as accelerated and automated disclosure responses, a presumption favoring disclosure, etc. We would be happy to work with the EPDP team to identify more specific criteria for a Trusted Notifier program as part of SSAD, and would also suggest reviewing existing registry trusted notifier systems as part of this endeavor.

In addition, any accreditation period should be as long as possible, to reduce the burden of having to frequently seek re-accreditation.

There should also be a specified and defined independent appeal mechanism for any decisions to de-accredit an accredited user on the basis of an alleged violation of the SSAD/accreditation rules.
Support Recommendation intent with wording change
Under “Objective of accreditation,” the statement “SSAD SHOULD ensure reasonable access….” ought to be changed to “SSAD MUST ensure reasonable access….”

Under “Accreditation procedure,” the statement “This authority SHOULD publish the requirements….” ought to be changed to “This authority MUST publish the requirements….”
Support Recommendation intent with wording change
The Central Gateway should present lists of pre-populated fields to the requestor (e.g. a list of third party purposes/justifications.) These lists may or may not be exhaustive, depending on the fields. This would streamline the request and decision-making process and thus help the SSAD reach its predictability objective. Second, the wording of Recommendation 2 needs to be aligned with that of Recommendation 6:
1. in c) replace “specific rationale” and “basis or reason for the request” with “legitimate interest or other lawful basis”; and
2. in e) replace “adequate, relevant and limited to what is necessary” with “necessary.”
Support Recommendation as written
Support Recommendation intent with wording change
The wording of the first paragraph should be aligned with the wording of Recommendations # 8 (Response Requirements) and 16 (Automation), to read: “The EPDP Team recommends that the Central Gateway provide an immediate and synchronous response that indicates the receipt of a valid request”, rather than “without undue delay”, which won’t be a problem for an automated system and will maximize its efficiency. There is no reason to impose on a computer system a promptness requirement that is more appropriate for a task requiring human intervention. For added clarity, we would also support an explicit requirement that in no event should acknowledgment of receipt take place in a time period of more than 24 hours.
Support Recommendation intent with wording change
Bullet point 1
The second sentence should be edited as follows:
● From "Legally and technically permissible" to "legally permissible and technically feasible."
● From “Not explicitly prohibited” to “allowed.”
Bullet point 4
The gateway must present to requestors an indicative list of necessary data elements, with corresponding explanations of their respective necessity. This list shall be developed on the basis of the use cases created by the EPDP (https://community.icann.org/display/EOTSFGRD/d.+Use+Cases). This list may be adapted, over time, by the Mechanism for the Evolution of SSAD. A Contracted Party shall accept the necessity of the data elements that are on the indicative list. In addition to or instead of the indicative list, the requestor may request data elements not on the list but whose necessity the requestor can explain. The Contracted Party shall determine whether these data elements are necessary.
We also propose the following revised language for the last paragraph on page 26 of the Initial Report: “If the requestor has not provided a legitimate interest or other lawful basis in processing the data, the Contracted Party MAY deny the request, or require further information from the requestor before proceeding to bullet #5 below. If a requested data element is not necessary to the requestor’s stated purpose, the Contracted Party may deny disclosure of this data element, or require further information from the requestor before proceeding to bullet #5 below.”
Bullet point 5
“May” should be changed to “must” in the first sentence.
The term “authorization provider” is also not defined and seems to refer to a Contracted Party who will be making a disclosure determination. This should be clarified.
As part of the balancing test, a CP must also evaluate the importance of the legitimate interests pursued by the requestor, including the defense of rights recognized by Article 17 (property rights) and Article 27 (moral and material interests resulting from scientific, literary or artistic production) of the Universal Declaration of Human Rights, and by applicable national laws.
In addition, the EPDP should clarify how it has reached the conclusion that combining data elements creates a higher risk profile for disclosure. We would advise against including this component as part of the evaluation unless the rationale can be articulated.
Significant change required: changing intent and wording
Automation of the receipt, authentication, and transmission of SSAD requests as well as automated disclosure of non-public registration data is an important and positive element that will allow more efficient response to DNS abuse and best serve the intended function of having an SSAD. However, as currently written, Recommendation #7 too narrowly limits the types of disclosure requests that are authorized for Day 1 automation, listing only: (1) Requests from Law Enforcement in local or otherwise applicable jurisdictions; and (2) Responses to UDRP and URS Providers for registrant information verification.
There should be full automation from Day 1 for as many types of disclosure requests as are practically and legally possible. At a minimum, we suggest that Recommendation #7 also include the following Day 1 automated processing cases:
1. Requests where:
a. the data subject is a legal person (to the extent that such information is not already publicly available in RDDS, which it should be); and/or
b. neither the data subject nor the Contracted Party are subject to EU law (to the extent that such information is not already publicly available in RDDS, which it should be); and/or
c. the data subject has consented to disclosure (to the extent that such information is not already publicly available in RDDS, which it should be if the registrant already gave general consent to publication of its data);
2. Requests that are made by officers of a court, made under penalty of perjury, and/or include a good faith assertion that a clearly identified and protectable IP right is being infringed through use of an identified domain name; and
3. Requests relating to domains registered in new gTLDs that only permit legal entities to register domain names (e.g., .BANK)

The recommendation should clearly identify all requirements for a request to qualify for automation.
It is important to keep in mind that SSAD is designed to facilitate investigations and development of possible legal claims, law enforcement response, and cybersecurity response – it is not designed to pre-judge or pre-determine the merits of possible claims, nor should ICANN or Contracted Parties be acting as arbiters of the legitimacy of such investigations. Assuming accreditation and well-formulated requests, disclosure should be the default, and balancing tests can be automated to adhere to appropriate use cases.
No, I wish to continue to the next section
Support intent of recommendation with edits
We generally support Recommendation #8, but believes certain revisions to the recommendation will make the SSAD more efficient.
The report should clarify that the gateway will provide automated recommendations (to disclose or deny disclosure), rather than have personnel review requests and generate these recommendations. The gateway will be uniquely positioned to provide automated recommendations because it will have access to considerable amounts of data about the SSAD: categories of requests, track record of requestors, ambiguity (or lack thereof) of certain types of requests, etc. Instead of allowing the Central Gateway Manager to provide a recommendation to the Contracted Party whether to disclose or not, the Central Gateway Manager should be required (“must” instead of “may”) to do so, because it is unclear when it may not be advisable or possible for the Central Gateway Manager to do so. For the same reason, we believe that specifying when the Central Gateway Manager may provide such recommendations (e.g. for certain types of requests or requestors) would not be sufficient either.
Contracted Parties must be equipped to process requests that meet SLAs, without exception.
Responses where disclosure of data has been denied should also identify how to appeal a determination or re-submit a request to address or overcome the reasons for denial.
Contracted Parties should be required to document the rationale for non-disclosure and communicate it to both the requestor and ICANN Compliance as a matter of course. The requestor should be afforded the right to appeal a denial, and be informed by the gateway of the procedure for such an appeal.
ICANN Compliance MUST investigate all complaints concerning disclosure decisions, and not just “be prepared to investigate” them. Greater detail should also be provided regarding what criteria ICANN Compliance will use to evaluate these complaints.
Support intent of recommendation with edits
1. Each standard (non-urgent, non-automated) disclosure request should receive a response in 5 business days or less. If a CP exceeds an average SLA for this timeframe, the Central Gateway shall send an automated alert to ICANN Compliance and ICANN Compliance shall review the situation with the CP as immediately as practicable.
2. ICANN Compliance shall be required to develop a Remedial Plan on the basis of the review. Each Remedial Plan shall be published by ICANN Compliance, and made available through the Central Gateway and via the Compliance website at a dedicated microsite.
3. Any CP who breaches the SLA shall be investigated by ICANN Compliance who shall issue an SLA Breach Report. The SLA Breach Report shall include: the findings of the investigation; any previous Remedial Plan developed by ICANN Compliance for the CP in question; and the penalties imposed by ICANN Compliance. The SLA Breach Report shall be made available through the Central Gateway and via the Compliance website at a dedicated microsite. The Central Gateway shall automatically send any such SLA Breach Report to each requestor whose request did not receive a response within the 10 business days.
4. The Mechanism for the Evolution of the SSAD should be the forum for reviewing and addressing possible changes to SSAD SLAs.
5. Priority 1 / Urgent Requests must be responded to within a 24 hour response time.
6. Priority 2 Requests must be responded to within 2 business days.
7. To avoid misuse of the priority 1 and 2 levels, the report should require evidence. An updated recommendation should provide examples of what evidence would be sufficient for each priority level. If confidential or legally privileged evidence cannot be provided, sworn affidavits could be provided to satisfy this requirement.
8. The procedure for setting the priority level should be clarified. The relevant sentence should read: “When a requestor sets the priority level of a request as Priority 1 or 2, the Central Gateway will clearly state the criteria applicable for these priority levels and the potential consequences of abusing these priority settings.”
9. Recommendation 9 should also include this sentence from Recommendation 8: “the use of ‘Urgent’ SSAD Requests is not limited to LEA.”
10. This recommendation should include an SLA for the Central Gateway’s general uptime, at an industry standard level of 99.9%.
See above.
No, I wish to continue to the next section
Intent and wording of this recommendation requires amendment
Preamble: “For the avoidance of doubt, every request does not have to go through an enforcement procedure; the enforcement mechanism MAY, however, be triggered in the event of apparent misuse.” Comment: It should be clarified regarding who can trigger the enforcement mechanism regarding “apparent misuse.” The Centralized Gateway Manager? A Contracted Party? A third-party?
(a) Limiting requested data to only the current RDS data will impose a challenge on brand owners and other third-party requestors. There are a number of reasons it is very important to have the ability to also obtain historical data, for instance to learn the approximate date on which that registrant acquired the domain name (which may differ from the domain’s original creation date by a prior registrant). Accordingly, there should be an option to also obtain historical data that is retained by the Contracted Party upon request.
(b) The “representations” required by this portion of the Recommendation must not be unduly burdensome and should, ideally, be satisfied by a check-the-box list of common reasons for such requests (with a catch-all “Other” checkbox and free text field for stating uncommon reasons). As for the “corresponding purpose and lawful basis for the processing”, the comments set forth pertaining to Preliminary Recommendation #3 “Criteria and Content of Requests” are incorporated here as well.
(c) No comment. We support this criterion.
(d) It is unclear what is meant by the “representation regarding the intended use of the requested data”. If this simply means that the requestor represents that the stated intended use is the actual intended use, then this should be satisfied by a simple checkbox. However, if its meaning is intended to be broader and mean that the intended use must be specifically stated, this seems to be redundant to other parts of the process set out in the recommendations. If the latter is the case, then the representation should be satisfied by a standardized check-the-box list of common intended uses (with a catch-all “Other” checkbox and free text field for stating uncommon uses). Further, the “representation that the requestor will only process the data for the stated purpose(s)” should be satisfied with a simple checkbox.
(e) No comment.
Intent and wording of this recommendation requires amendment
As an initial matter, same comments as above regarding who/how mechanism is triggered regarding “apparent misuse.”

(a) No comment.

(b) See comments pertaining to Recommendation 10 concerning disclosure of historical data.

(c) No comment.

(d) Comments on logging appear in the Logging section, Recommendation 17.

(e) With respect to the “balancing test”, the comments pertaining to the balancing test set out in Recommendation 6 are incorporated here as well.

(f) The term “reasonable request” as used in this context (as opposed to the disclosure request context) should be further defined so as to avoid any improper denials of requested data and any unnecessary delays in processing the same. This section should also clarify that the “request” in this context is by the data subject itself.

(g) While we do not object to this concept in principle, and agree that such rights are prescribed under certain laws like GDPR, the right to erasure cannot be presented or used as a means of preventing disclosure of data in connection with a reasonable request that has met the applicable balancing test or other criteria for disclosure.

(h) The “privacy policy for the SSAD and standard language (relating to the SSAD) to inform data subjects” should be developed by the SSAD stakeholders and put out for public comment to ensure clarity, accuracy, and neutrality.

(i) It is important that “the nature of legal investigations or procedures” not be limited to criminal investigations by law enforcement or other governmental entities. There are situations where civil investigations may require that requests be kept confidential from the data subject (e.g., where counterfeit goods may be quickly sold or destroyed by a data subject in an attempt at frustrating the enforcement of intellectual property rights). It may be helpful to explicitly confirm this in this section.

Any domain name that is the subject of a disclosure request must be locked (using the UDRP definition) during the pendency of a disclosure request; and that any notice to data subjects of disclosure requests not be permitted during the pendency of a disclosure request.
Intent and wording of this recommendation requires amendment
(a) No comment.

(b) The reference to “ICANN org” as used in this section should be made more specific [“In the event the entity receiving requests makes a determination based on abuse to limit the number of requests a requestor, further, to point b, the requestor MAY seek redress via ICANN org if it believes the determination is unjustified.”] Which part of ICANN Org specifically would have responsibility? ICANN Compliance?

(c) In addition to disclosure relating to “specific domain name[s]” identified in a request, provision should be made for disclosure, upon request, of all domain names owned by the same registrant who is the owner of a specific domain name that is the subject of the initial request about which the Contracted Party to whom the request is directed has such additional information. In addition, EPDP should consider introducing some kind of “trusted requestor” program to expedite responses to similarly-situated requests from a trusted requestor based on pre-defined criteria and use cases. This will help alleviate the cost of examining each request “on its own merits” where the same requestor who has previously demonstrated a pattern of good faith, reasonable, and well-founded requests, submits further requests of a substantially similar nature. Finally, we reiterate our other comments regarding disclosure of historical registration data.
Support intent of recommendation with edits
In general, we support the concept of using appropriate agreements, such as terms of use, a privacy policy and a disclosure agreement to provide rights, duties and obligations concerning access and disclosure of data through SSAD. However, such agreements must be carefully drafted and vetted by the community so that they accurately reflect EPDP policy recommendations and not impose additional obligations or duties or provide imprecise access or disclosure rights. All SSAD stakeholders should be involved in developing these agreements. The EPDP should also clarify how a code of conduct would relate to terms of use and the other agreements discussed in this recommendation, and consider whether all of these agreements could be covered under a single terms of use document.

We recommend the following revised wording of Recommendation 13:

“The EPDP Team recommends that appropriate agreements, such as terms of use for the SSAD, a privacy policy and a disclosure agreement are put in place that accurately reflect the recommendations of the final reports of the EPDP Team. These agreements are expected to be developed and negotiated by all SSAD stakeholders, taking the below implementation guidance into account and any such draft agreements will be published for public comment prior to implementation.”

With respect to recommendations concerning proposed Terms of Use, we would suggest that a standard of mere “misrepresentation” to trigger requestor indemnification should be revised to an “intentional, reckless or willful misrepresentations” standard.

Further we note the text stating “The EPDP recommends, at a minimum, the privacy policy SHALL include: Relevant data protection principles, for example,”. This sentence appears to abruptly cut off - were there supposed to be particular examples listed here?

Further, we note the text stating “Applicable prohibitions Disclosure” Should this say “Applicable prohibitions on Disclosure”? Please clarify.
Support intent of recommendation with edits
We support the intent of this recommendation but note that the second sentence of Recommendation 14 might create a contradiction with the requirement of the first sentence in cases where the registration data must be retained under law applicable to the requestor for other reasons or for a longer duration not specific to achieving the purpose of original disclosure. Accordingly, we would suggest the following revision to the wording of Recommendation 14:

“The EPDP Team recommends that requestors MUST confirm that they will store, protect and dispose of the gTLD registration data in accordance with applicable law. Requestors MUST retain only the gTLD registration data for as long as necessary to achieve the purpose stated in the disclosure request, unless otherwise required to retain such data for a longer period under applicable law.”
Support intent of recommendation with edits
There needs to be a delineation in costs between the development of the SSAD system and its operational costs. We agree that development costs should be initially borne by ICANN Org and Contracted Parties, but that subsequent operational costs should be covered on a cost recovery basis that may take into account historical costs within reasonable parameters.

EPDP should clarify in this recommendation what it means by “smaller operators” in the context of disproportionately high burdens - it seems to imply contracted parties, but it is unclear. No fees for accreditation or disclosure requests must be so high for any class of user or accreditation applicant so as to circumvent their ability to make meaningful use of the SSAD. Overall, the financial burden on all parties to the system should be equal or at least proportionate. System costs should be a component of audits.

We would also support allocation of ICANN Org budget toward offsetting the costs for maintaining the Central Gateway and in general for setting up and maintaining this system.

We would like further specifics regarding the suggested legal risk fund and why such a fund is necessary as part of the costs of this system. All businesses and systems operate subject to some legal risk, so it is not clear why this system necessitates a special fund for its risks.

Finally, this section refers to “input from ICANN Org concerning the expected costs of developing, operationalizing and maintaining the three different models.” This should be updated now that three models are not being considered. That said, we incorporate our other comments regarding revisiting a more centralized model.
Support intent of recommendation with edits
See comments regarding Recommendation #7.
No, I wish to continue to the next section
Support intent of recommendation with edits
Support intent of recommendation with edits
Comments re Rec #17, since the Form lacked a separate comment box: We support the proposed requirements for logging requests and responses. Logging is essential to ensure the SSAD is operating properly, including to ensure ICANN Compliance can properly audit the actions of disclosing entities, identify any instances of systemic non-compliance, and take appropriate enforcement action, and to identify areas of possible evolution of the SSAD.
In addition to other specific aspects of the logging process, logging must include: disclosure and non-disclosure decisions; rationale for non-disclosure; divergence between the disclosure and non-disclosure decisions of a CP and the recommendations of the gateway; non-compliance with system requirements. Logged data should ensure removal of any personal data. Such data must be published in one or more machine readable formats.
CANN Compliance must have access to all logged SSAD data and must periodically review and analyze it to inform its enforcement activities, audit contracted parties who are not meeting their obligations, and to help provide analysis for any possible evolution of SSAD discussions.
Logs should also be readily available in the SSAD to allow requestors and contracted parties to review their own statistics. We would advise the general periodic publication of logs (per above, stripped of any personal data) for purposes of transparency, accountability, and process review, etc.

Comments re Rec #18: We agree that the SSAD needs to have sufficient audit mechanisms to enable monitoring and compliance with law and with ICANN policy. This recommendation states that the EPDP “expects” that auditing is done to ensure compliance, but it does not explicitly recommend auditing contracted parties - Recommendation 18 must explicitly recommend to audit contracted parties’ compliance with this policy.
Support intent of recommendation with edits
We support a possible mechanism other than a GNSO PDP to assist in ongoing and continuous tracking and potential improvements of the SSAD over time. We provide some suggested parameters of such a mechanism below.
This Mechanism, if it exists, must represent the entire ICANN community, and not only the GNSO. It should take into account SSAD users including law enforcement, cybersecurity, intellectual property owners and agents, and other types of end users. It should not take the form of a GNSO PDP, as this structure is likely too rigid to meet the needs that the Mechanism would be serving. The mechanism must have balanced representation from the entire ICANN community.

The Mechanism’s remit should be primarily aimed at further centralization, automation, efficiency, and cost-effectiveness of the SSAD to adhere SSAD as closely as possible to what the law actually requires in terms of protecting personal data. The Mechanism must not be a channel for second-guessing the EPDP recommendations/Registration Data Policy, or SSAD policy without objective evidence of legal risk, financial unsustainability, or other existential matters. It should have sufficient resources to obtain the legal clarity required to address these concepts.
Some kind of cross-community standing committee could be suitable for the Mechanism, akin to the CSC for PTI but with representation reflecting that of the EPDP.
Support implementation guidance as written
We support periodic transparency reports published by ICANN reporting on SSAD, including logged data discussed under Rec. #17. Quarterly reports may be adequate, but this could be revisited based on adoption and use of the SSAD.
As noted above, the EPDP should revisit the possibility of a fully or more centralized SSAD model, in light of apparently inconsistent comments on this subject, calling into question whether such an approach would actually be impermissible under GDPR. We would strongly prefer a more centralized/automated approach to SSAD that is more reflective of the historical WHOIS system in terms of querying and disclosure of data. Having received further comments from the Belgian DPA that a centralized model is a “better, ‘common sense’ option in terms of security and for data subjects”, the EPDP should revisit the possibility of an SSAD based on a centralized model, rather than the current hybrid model.

The EPDP must also present a recommendation for a mechanism for obtaining historical data, to the extent such data is retained by Contracted Parties/ICANN. Historical data is often critical to many legitimate third-party purposes for which SSAD is being created, for instance in order to help trace the chain of title of particular domain names which may be relevant in the course of certain legal disputes (e.g. a UDRP or URS case), to cybersecurity measures, or to law enforcement, among other possible reasons.

The EPDP must also present a recommendation for a mechanism for conducting “reverse RDDS” searches to identify all domain names associated with a particular RDS data element (e.g. name or email address). This function is also a critical component for many third-party end-users of SSAD, including law enforcement, cybersecurity, consumer protection and intellectual property owners/agents, as it facilitates more coordinated and efficient investigation and legal action with respect to large networks of problematic domain names all associated with the same registrant. At a minimum, we would suggest that an independent legal analysis be undertaken by the EPDP and its outside legal counsel on the legality under GDPR reverse searching, at least in cases where registrant data has already been disclosed to the requestor, if such an analysis has not already been undertaken (we are not aware of one at this time).

Finally, ICANN, the GNSO and EPDP cannot enact policies for ccTLDs, but some of them have followed the example of ICANN and terminated or substantially reduced open access to WHOIS. Therefore, we expect that some may want to follow suit again and participate in the SSAD. The EPDP should consider presenting recommendations or suggestions concerning possible voluntary ccTLD participation in SSAD.
52
3/23/2020 15:54:50Brian Beckham
Head, Internet Dispute Resolution Section, WIPO
Yes
WIPO Arbitration and Mediation Center
No, I would like to continue to the next section
Support Recommendation intent with wording change
For Requirements of the Accreditation Authority (i)3rd bullet, and (k) - add/comment: For some sets of SSAD users, to avoid the possibility of a conflict of interest, compliance with the Code of Conduct should be monitored by (and if warranted, violations addressed by) a third party independent of the Accreditation Authority. (Given the standards applied by some user groups, e.g., security professionals within the APWG, this may not be applicable, and in fact, for such group the Accreditation Authority may be ideally suited to monitor such compliance.)

For (l), "regular basis should be defined, e.g., annually.

For Accredited User Revocation & Abuse: grounds 1 and 2 should be managed by a third party, grounds 3 and 4 could be managed by the Accreditation Authority.
No opinion
Support Recommendation intent with wording change
For (d): as in the Lenz v Universal case examining takedown notices under the DMCA in the United States (requiring that in submitting a claim, copyright holders must consider potential “fair use” defenses) adding an attestation as to potential fair use here would assist the disclosure determination.
No OpinionNo opinion
Significant change required: changing intent and wording
For #3: The Contracted Party should not be the final arbiter of the outcome of an alleged claim; if a valid claim is asserted, the requested information should be disclosed (the Contracted Party should e.g., not add to its liability by purporting to judge potential fair use). Drawing a parallel to UDRP para 4(c), a Provider conducts a compliance review, e.g., to ensure that trademark rights are adequately claimed so as to permit the case to proceed to a determination by an independent expert panel -- it is not the Provider's role at that compliance review phase to assess the case merits. It should furthermore be noted that in some cases, the decision whether to proceed with a UDRP or court case can only be fully made once the registrant identity is known.

For #5 Assessment of Impact, this should be limited to scenarios where there is a risk to the safety of the data subject, and should not be used to merely avoid appearing to defend a legal claim (such as trademark infringement) made against it. Furthermore under this section, if a request is denied, not only should the rationale be documented, but the requestor should have the opportunity to appeal such refusal.
Support Recommendation intent with wording change
In the examples listed in the document at footnote 13, No. 5, "clear cut" trademark claim, this should not be limited to the TMCH, but may draw on other public databases, such as national offices or the WIPO Global Brands Database (containing tens of millions of records for dozes of national and regional offices, see https://www.wipo.int/reference/en/branddb).
No, I wish to continue to the next section
No opinion
Support intent of recommendation with edits
Under: What happens if priority needs to be shifted? -- second sentence: "evidence documenting a UDRP case" should be clarified to permit a UDRP Provider to provide e.g., a case registration number (at WIPO, all pending cases are assigned a number, which is posted online), but not to require the attachment of a complaint -- this is not required by the UDRP Rules (parties are required to copy the Provider and other party on case communications) and would require manual intervention for what is currently an automated process. (It is moreover noted that in some cases, claims have involved registrars, e.g., (Microsoft v. Shah, Ford Motor v. Greatdomains.com, and Solid Host v. Namecheap.)

Regarding the two phases of SLAs, it is not clear why after having time to learn how the SSAD will work in practice, more time would be needed to assess a request in Phase 2.
Intent and wording of this recommendation requires amendment
Regarding the proposed limitation on historic data, if limited to current data, at minimum, the date the current registrant became the registrant should be made available.
Intent and wording of this recommendation requires amendment
For (e): if such test goes beyond being satisfied that a trademark holder/agent has advanced a valid claim of infringement, the Contracted Party risks displacing the role of a legal adjudicator to assess the case merits; instead, the test should assess prima facie whether a valid claim has been made.

Under (g): any right to erasure should take account of the rights of third parties.
No, I wish to continue to the next section
No opinionNo opinion
Support intent of recommendation with edits
Under: What existing processes / procedures, if any, can be used to meet the above responsibilities? -- in terms of validation: as noted above the WIPO Brands Database contains tens of millions of records across dozens of national and regional offices, see: www3.wipo.int/branddb/en/branddb-help.jsp#db
Support implementation guidance as written
53
3/23/2020 15:55:35Frank ConaInfoNetworksNo
No, I would like to continue to the next section
Support Recommendation intent with wording change
We recommend a definition to specify the types of SSAD Users, such as “accredited organizations, companies, associations and individuals.” It is unclear how individuals making a request on behalf of an accredited legal entity (organization, company, association) will be validated at the time of request and then audited at a later date. We believe that Recommendation #1 should be revised to clarify whether requests made on behalf of accredited organizations must be made by individuals specifically accredited to act on behalf of that organization. Further to a), we believe that the EPDP should clarify whether SSAD will merely rely on an attestation of the individual or, preferably, rely on a Signed Assertion that the individual has the right to act on the authority of an accredited organization. It is not practically feasible for ICANN to be the sole Accreditation Authority for the myriad different types of Signed Assertions that may need to be Verified (e.g., organizations like WIPO are already better equipped to verify intellectual property rights).
Support Recommendation intent with wording change
Recommendation #1 speaks to accreditation generally, and Recommendation #2 appears to distinguish certain government entities as accredited requestors. However, its broad scope of (“public policy task” encompasses most government-related tasks) and general accreditation requirements makes it unclear what is being distinguished. We recommend incorporating the portions of ‘5. Accreditation Requirement” and “6. Accreditation Procedure” applicable to all requestors into Recommendation #1, and revising Recommendation #2 to indicate how these requirements differ for specific types of government entities (e.g., for “Civil and criminal law enforcement authorities”).

Section 6.c appears rather prescriptive and there should be more deference to government entities as requestors, e.g. “Audits should be conducted by the auditor designated by the applicable national / regional law.” Also, please see our comments in regard to Recommendation #18 as to clarifying how this relates to auditing of third parties acting as accreditation authorities.

In Section 6.e, the timing for making the disclosure clear to the data subject or for any request from the data subject is unclear, or if a challenge by a data subject is allowed before disclosure (particularly for automated processing where all criteria for disclosure are met). This is also not indicated in the swimlane flowchart in the report. This timing should be specified, such as in relation to Recommendation #9, and how it relates to automated processing under Recommendation #16.
Support Recommendation intent with wording change
We recommend that Recommendation #3 be revised as follows: “The EPDP Team recommends that each SSAD request MUST include all information necessary for a disclosure decision, including the following information as applicable:” Further to our comments for Recommendation #19 regarding clarifying the scope of the EPDP recommendations, an overly prescriptive requirement on the content of requests may unduly impede an otherwise legitimate SSAD request. There are adequate safeguards in the SSAD framework to de-accredit a user that abuses the system.
Support Recommendation as written
Support Recommendation intent with wording change
We support this recommendation, but note that the role of any Central Gateway Manager should be limited to avoid unnecessary cost, complexity, and risk. While there may be potential benefits to providing a single URL for requesters to submit their request, there should be no operational review, just logging and routing the request to the appropriate party for processing. Alternatively, we recommend “Central Gateway Manager” be replaced with “appropriate Gateway Manager.” (And that the definition of Central Gateway Manager be similarly revised.)

As explained in our public comments to the TSG final report (and consistent with the subsequent Bird & Bird legal memoranda), the use of a Central Gateway Manager is, of itself, largely immaterial to reducing the liability of a Contracted Party as a joint controller, and, as we note in connection with Recommendation #15 on financial sustainability, the use of a Central Gateway Manager in the manner recommended creates added costs, unnecessary complexity, and inefficiency in the SSAD process. We believe that a better approach is to route the requests to an appropriate Gateway Manager operated by participating Contracted Parties, and their designees, who are nevertheless still responsible as the decision-makers for disclosure. CANN’s role would be as a coordinating body, as originally proposed by ICANN and as it is for other operational activities.
Support Recommendation intent with wording change
We note that in order to conduct the recommended evaluation under 5. (e.g., Does the data requested contain personal data?), it is necessary to know whether the requested registration data is for a natural person or legal person (or a person and/or organization that is designated a “protected” person) along with the jurisdiction in which the registrant / tech contact and requestor each reside. A significant portion of current non-public registration data is for legal persons, and not subject to the privacy protections afforded natural persons. This is particularly true given the prevalence of privacy / proxy services, in which the non-public registration data does not include a registrant’s personal data by intent. Subjecting registration data that is not personal data to the privacy protection afforded natural persons under SSAD would preclude a true balancing of interests in a manner not consistent with Section 6(1)(f) of the GDPR by unduly thwarting accredited requestors who are appropriately seeking the information to address infringement, illicit activity, and other domain abuses. We recommend clarifying that specified requirements for Contracted Parties under this recommendation do not apply where the non-public registration data being requested is known to not be personal data (such as through a designation in the data or otherwise), and that automated processing is possible for such data. Conversely, the disclosure requirements should be revised to extend to applicable beneficial registrant information held by a privacy / proxy service (as opposed to merely disclosing the proxy registration data). Failure to do so would also thwart the legitimate interests of requestors, and moot the SSAD process, for all such registrations. The designated point of contact for the privacy / proxy service should be capable and authorized to investigate and handle information requests.
Support Recommendation intent with wording change
Please see our comments to Recommendation #5 regarding the ineffectiveness of a Central Gateway Manager. We recommend “Central Gateway Manager” be replaced with “appropriate Gateway Manager.”
No, I wish to continue to the next section
Support intent of recommendation with edits
We recommend that “the Central Gateway Manager” be revised to “the designated Gateway Manager” consistent with our comments elsewhere regarding changing the requirement for a single, centralized gateway for all requests to a requirement for one or more Gateway Managers designated for each top-level domain.
Support intent of recommendation with edits
We believe that the application of Recommendation #9 to specific types of requests requires significant community discussion, as well as the proposed SLA times for response. This should also be ascertained in conjunction with which use cases are capable of automated processing.
No, I wish to continue to the next section
Support intent of recommendation with edits
We recommend that “the Central Gateway Manager” be revised to “the designated Gateway Manager” consistent with our comments elsewhere regarding changing the requirement for a single, centralized gateway for all requests to a requirement for one or more Gateway Managers designated for each top-level domain.
Support intent of recommendation with edits
Similar to the evaluation in Recommendation #6, for a Contracted Party to determine the need to conduct a balancing test and the applicability of other privacy protections, it is necessary to know whether the requested registration data is for a natural person or legal person (or a person and/or organization that is designated a “protected” person) along with the jurisdiction in which the registrant / tech contact and requestor reside. A significant portion of current non-public registration data is for legal persons, and not subject to the privacy protections afforded natural persons. This is particularly true given the prevalence of privacy / proxy services, in which the non-public registration data does not include a registrant’s personal data by intent. Subjecting registration data that is not personal data to the privacy protection afforded natural persons under SSAD would preclude a true balancing of interests in a manner not consistent with Section 6(1)(f) of the GDPR by unduly thwarting accredited requestors who are appropriately seeking the information to address infringement, illicit activity, and other domain abuses. We recommend clarifying that specified requirements for Contracted Parties under this recommendation do not apply where the non-public registration data being requested is known to not be personal data (such as through a designation in the data or otherwise), and that automated processing is possible for such data. Please also see our comments to Recommendation #16 Automation. Conversely, the disclosure requirements should be revised to extend to applicable beneficial registrant information held by a privacy / proxy service (as opposed to merely disclosing the proxy registration data). Failure to do so would also thwart the legitimate interests of requestors, and moot the SSAD process, for all such registrations. The designated point of contact for the privacy / proxy service should be capable and authorized to investigate and handle information requests.
Support intent of recommendation with edits
We recommend that “the Central Gateway Manager” be revised to “the designated Gateway Manager” consistent with our comments elsewhere regarding changing the requirement for a single, centralized gateway for all requests to a requirement for one or more Gateway Managers designated for each top-level domain. In addition, we recommend that the second to last sentence be revised along the lines of the following, “SSAD requests MUST only refer to current registration data. Historical registrant information and other registration data will not be made available via this mechanism. For clarity, Contracted Parties SHALL not be precluded from providing enhanced services regarding such data.” Further to our comments in regard to Recommendation #19, we believe that the EPDP should not unduly inhibit innovative uses of the DNS.
Support recommendation as written
Support recommendation as written
Support intent of recommendation with edits
We fully support the cost-recovery and self-sustainability recommendations put forth by the EPDP, but note that the EPDP’s recommendation for a Central Gateway Manager, appears to be inconsistent with this, as it will add unnecessary implementation, operation, and maintenance costs, as well as liability risk, for all parties. Notwithstanding the Central Gateway Manager’s validation of the contents of the request, Recommendation #6 requires that the Contracted Party “to which the disclosure request has been routed MUST review every request on its merits” and make the decision on disclosure. The use of a Central Gateway Manager will be additive in both cost and risk for processing SSAD requests, as each Contracted Party must still implement its own system for processing SSAD requests, and ICANN has not committed to indemnifying the Contracted Parties for its operation of the Gateway Manager (the only reliable way to allocate liability among joint controllers under the current framework of the GDPR -- as explained in our prior public comments on the TSG’s report, and consistent with the subsequent legal memoranda provided by Bird & Bird). And, as the EPDP itself notes in Recommendation #14 “ICANN MAY contribute to the (partial) covering of costs for maintaining the Central Gateway.” The prospective benefits outlined by the EPDP on page 10 of the draft initial report can easily be achieved by routing requests to an appropriate Gateway Manager using well-established Internet technology, as we demonstrated to the EPDP working group at ICANN65, and without the additional cost, complexity, and risk of a single central gateway.
Support recommendation as written
No, I wish to continue to the next section
Support recommendation as written
Support intent of recommendation with edits
Recommendation #18 states “ICANN org as the Accreditation Authority is not required to audit governmental entities, whose accreditation and audit requirements are defined in Preliminary Recommendation #2.” However, Recommendation #2 appears directed only to governmental entities as accredited requestors, and NOT governmental entities operating as a third party accreditation authority. We believe that Recommendation #18 (and/or Recommendation #2) should be revised to clarify application of the audit requirements to a situation where a third party serving as an accrediting authority is a government entity, intergovernmental entity, or the like.
Support intent of recommendation with edits
We recommend that the following be added to Recommendation #19:

“d) The ability for Contracted Parties to make additional non-public data and services available through the SSAD or otherwise in a manner consistent with applicable data protection law.

The EPDP Phase 2 recommendations should not be interpreted as precluding a Contracted Party from collecting additional registration data elements from a Registrant, and disclosing that information via SSAD, or otherwise, in a manner consistent with applicable data protection laws and other regulations.”

Various Registry Operators are permitted to collect and publish additional data elements in the RDDS, and this is likely to be the case in the future. It is important that the EPDP recommendations do not unnecessarily inhibit innovative uses of the DNS by Contracting Parties in specifically addressing access to traditional Whois data. The EPDP recommendations should not preclude a Contracted Party from implementing enhanced services, as long as those services are provided in a manner consistent with applicable data protection laws and other legal requirements.
Support implementation guidance as written
We believe that it is important that the extensive work that has been undertaken by the EPDP in its Phase 1 and Phase 2 recommendations be placed in appropriate context. The EPDP should clarify that it is making implementation and policy recommendations for the processing of specific registration data, and there is nothing implicit or explicit in the recommendations that prohibit a Contracted Party from processing other registration data in other circumstances. That is, a Contracted Party may still collect additional types of information in registration data (whether or not including personal data) that could be made available in a manner consistent with applicable law. The EPDP recommendations should not be construed as precluding Contracted Parties from offering enhanced services if consistent with applicable law.
54
3/23/2020 16:24:26Constantine RoussosDotMusic LimitedNo
No, I would like to continue to the next section
No, I wish to continue to the next section
No, I wish to continue to the next section
It is important that the EPDP recommendations do not unnecessarily inhibit innovative uses of the DNS in order to specifically address access to traditional Whois data or RDDS data. The EPDP recommendations should not preclude a Registry Operator from collecting additional registration data related to a Registrant, or from disclosing that information via SSAD, as long as it complies with applicable law. For example, DotMusic is focused on creating a trusted environment for musicians, and this may extend to the incorporating a Registrant's intellectual property registrations and other rights into our domain services that may involve PII.
55
3/23/2020 16:51:23Eleeza Agopian ICANN orgYesICANN org
No, I would like to continue to the next section
General Comment:
For ease of reading and clarity in implementation, ICANN org suggests moving these definitions and the definition for “Eligible government entities” in Recommendation #2 to a separate section of the report. The rationale for this is that the definitions apply across all recommendations and are not meant to be interpreted as policy recommendations or requirements on their own.

Principles:
General Comment:
ICANN org suggests that the principles listed under Recommendation #1 move to the implementation guidance for this recommendation, as they do not seem to be intended as policy recommendations.

Bullet point d:
ICANN org suggests further clarifying principle d to specify which party is responsible for the validation of the Identity Credential, Signed Assertions, and the requested data in order to authorize the disclosure of the registration data. This is further described in the comments on bullet points f and g below.

Requirements of the Accreditation Authority:
Bullet point e:
As there are no recommendations on how the Accreditation Authority must verify the identity of the requestor, ICANN org believes it is important to understand the scale of effort the EPDP expects for the verification process. For example, how and to what type of standards would an IP attorney’s identity be validated? A cyber security researcher? If any possible SSAD user may be accredited, how would the Accreditation Authority or Identity Provider be expected to verify that an individual with the email address NAME@SLD.TLD is who they say they are? Would it be up to the Accreditation Authority or the Identity Provider to set these parameters?

Bullet point f:
This recommendation requires that “the Accreditation Authority MUST verify and manage a set of dynamic assertions/claims associated with and bound to the Identity Credential of the requestor,” but then notes that “This verification is performed by an Identity Provider.” The Accreditation Authority may not be able to verify and manage these “assertions” if a third-party Identity Provider is responsible for verifying the identity of the requestor. The Accreditation Authority may not have the necessary relationship with a requestor to verify the attributes included in a signed assertion. Can the EPDP confirm whether it is only the Identity Provider that can provide this function? If that is the case, would it be sufficient for the Accreditation Authority’s verification process to ensure a secure confirmation with the Identity Provider that the relevant “signed assertions” were provided?

Bullet point g:
As a general comment, please consider moving the recommendations related to Signed Assertions into their own recommendation, because this seems to require a series of actions and procedures that are separate from the Accreditation process. As the org understands them, Signed Assertions are meant to be additional methods for validating the identity of the requestor and attributes associated with a requestor’s identity. Can the EPDP Team confirm this assumption? Furthermore, some of the elements that must be managed and verified by the Accreditation Authority as part of the Signed Assertions seem to be related to individual requests, for example, assertion as to the purpose(s) of the request, and assertion as to the legal basis of the requestor. As Signed Assertions may then relate to individual requests rather than requests for accreditation to use the SSAD, can the EPDP further clarify why the Accreditation Authority is responsible for managing the Signed Assertions? Lastly, it would be helpful to understand if the Identity Provider is meant to generate or validate the Signed Assertions. See the comments above on bullet point f.

Bullet point h:
It is unclear how the Accreditation Authority would facilitate the validation of the Identity Credentials and Signed Assertions to “facilitate the decision of the authorization provider.” What does “facilitate” mean in this instance? Does it mean that the Accreditation Authority would share the Identity Credentials and Signed Assertions with the authorization provider (presumably the relevant Contracted Party)?

Bullet point i:
Can the team clarify its intentions in referencing GDPR standards in the context of its recommended “code of conduct” in footnote 12? Does the EPDP Team recommend that the Accreditation Authority define a baseline “code of conduct” as contemplated in Article 40 of the GDPR (with all of the associated requirements)? Or was this phrase used in a more general sense, with a reference to the GDPR as a suggested resource?

The Accreditation Authority:
Bullet point j:
The recommendation does not indicate which entity is intended to develop and enforce a “uniform baseline application procedure and accompanying requirements.” Can the EPDP confirm that it expects the Accreditation Authority to to develop a uniform baseline application procedure? Or is the expectation that the Mechanism for Evolution of the SSAD would develop this procedure?

The last sub-bullet under j) indicates that “requirements beyond the baseline” may be necessary. Is it recommended that the Accreditation Authority will have the discretion to decide when requirements beyond the baseline are necessary? Or would some other entity make this determination (e.g. the Mechanism for Evolution of the SSAD)? It is also unclear what specific procedures for validation or accreditation are contemplated and how stringent the EPDP Team envisions these procedures to be. Would it be up to ICANN org to determine what the requirements would be for accreditation? As an example, the Statement of Registrar Accreditation Policy provides criteria for the types of specific capabilities that an application for registrar accreditation must demonstrate.

De-authorization of Identity Providers:
Bullet point t:
There is no defined “authorization policy for Identity providers” in the initial report. Can the EPDP confirm that the Accreditation Authority would be expected to define this as part of its procedure for selecting and approving Identity Providers? If so, what standards would the Identity Provider have to follow? The use of SHOULD here indicates this procedure may be optional, therefore is it correct to assume that Identity Providers would still be in compliance if they chose to not include graduated penalties? Additionally, would it be correct to assume that ICANN org may choose any process and procedure to approve or reject Identity Providers?

Accredited Entities or Individuals:
Bullet point v:
Can the EPDP team clarify which entity is responsible for determining “where the accredited entity poses a demonstrable threat to the SSAD,” and when/how? As well as which entity is responsible for determining “possible limitations in SSAD’s response capacity and speed”?

Implementation guidance:
Bullet Point d:
To avoid confusion in implementation, ICANN org suggests clarifying whether this is a requirement or implementation guidance. Additionally, ICANN org suggests changing “SHALL” to “should” or removing the requirement altogether, as the statement “Logged data SHALL only be disclosed, or otherwise made available for review, by the Accreditation Authority or Identity Provider, where disclosure is considered necessary to.. support the reasonable functioning of SSAD and the Accreditation policy” may be too broad under applicable data protection law.
General Comment:
ICANN org suggests the EPDP team revisit preliminary recommendation 2 as a whole and verify the aspects that are meant to be distinguished from Recommendation 1 in terms of Accreditation. As this recommendation describes the process of Accreditation, ICANN org suggests coupling Preliminary Recommendation 2 with Preliminary Recommendation 1 and identifying the specific points on which the requirements differ, to help reduce confusion and remove inconsistencies. Does the EPDP intend for this recommendation to limit government entities to be accredited only via the process in this recommendation or can they also use other accreditation avenues?

Further down in the recommendation on data access, the second bullet point indicates that “The final responsibility for the decision to disclose data lies with the data controller.” ICANN org suggests that the term “data controller” be changed to “Contracted Parties” as data controller does not align with Preliminary Recommendation 1 or the rest of the initial report.

Additionally, ICANN org understands that the GAC has been suggested as taking responsibility for validating, confirming, and identifying government entities to use SSAD, though not in this report. As the GAC does not consist of a representative from all government entities, will the GAC create a defined process that clarifies how Accreditation Authorities will be identified for each country and territory and a defined process on how government-appointed Accreditation Authorities would connect to SSAD?

Determining Eligibility:
The first sentence indicates “Eligible government entities are those that governments consider require access to non-public RDDS data for the exercise of their public policy task, in compliance with applicable data protection laws.” Does this mean that the request and associated public policy tasks must be compliant with that country’s data protection laws or any data protection law that may be applicable to data identified in a request?

Data Access:
The second to last bullet states, “Accredited entities SHOULD indicate the requirement for confidentiality for any requests where applicable.” Recognizing this is within preliminary Recommendation 2 on accreditation of governmental entities, is there a general assumption around transparency of all SSAD requests, such as default to public or default to confidential?

General Comment:

Will the EPDP team address data protection issues related to requestors’ data in Preliminary Recommendation 3 (particularly related to the content and criteria of requests)? This recommendation requires the processing of requestors’ personal data. The processing of this data must be implemented in compliance with applicable law, including the GDPR.
General Comment:

ICANN org suggests that the EPDP team further clarify the scope of this recommendation. For example, ICANN org understands the term “third parties” to mean “requestors” in Preliminary Recommendation 4: Is this assumption correct?

Additionally, the first bullet states that “third parties may submit requests for specific purposes, including ...Registered name holder consent, contract or responses to registered name holders’ requests exercising their right of access.” Is the EPDP team recommending that registrants are able to provide consent to third parties to access the registrant’s own data through the SSAD? Or that a registrant would use the SSAD to access its own data? Or that a request from a registrant to a contracted party, in exercise of a data subject’s rights under applicable law, could go through the SSAD? If the last scenario is being contemplated by the EPDP Team, ICANN org notes that data subjects’ rights go far beyond data that is contemplated to be disclosed via SSAD and, as a result, requests from data subjects to the SSAD would have different limitations and requirements that have not been explored and should be considered if data subjects are to be included as intended users of the SSAD.
General Comment:

Footnote 14 (in Recommendation 8) states that it is the expectation that the initial review of the completeness of a request is done automatically, with the system not accepting the request until all requested data has been provided. Therefore, can the EPDP team further clarify if the following sentence in the first paragraph of Recommendation 5, that “all required information as per preliminary recommendation #3, criteria and content of request, is provided,” means simply that no fields may be left blank? Or does this recommendation contemplate that this check must include a substantive evaluation? If an acknowledgement of a request will require a human review (for example, to confirm that fields for required information include “real” information and not “12345” or otherwise inaccurate information), it seems that the automated acknowledgement of receipt would not be possible.
General Comment:
As noted in ICANN org’s general comments on the initial report, there seems to be a disconnect in the use of conventions in this recommendation, where some of the listed requirements seem to be optional. For example, paragraph 1 indicates that Contracted Parties “MUST review every request on its merits.” However, paragraph 4 states that the contracted party “should [emphasis added] make a threshold determination” and paragraph 5 mentions “may [emphasis added] evaluate.” Thus, per the recommendation, these are both optional reviews. As such, if every request MUST be reviewed “on its merits,” it would seem to follow that paragraphs 4 and 5 might also include “MUST” requirements.

Paragraphs 5 and 6 determine whether “the balancing test” is applicable. ICANN org suggests that the policy be clearer on the specific criteria that must be applied when this test is conducted, so that any dispute regarding a contracted party’s application of this test can be objectively evaluated. More specific comments are included below.


Paragraph 4:
The second bullet in this paragraph would be difficult for ICANN Contractual Compliance to enforce. ICANN org requests that the EPDP team provide further clarity on the following language, “Necessary means more than desirable but less than indispensable or absolutely necessary.” ICANN org understands that this language was provided by a judicial decision cited in a Bird & Bird memo, but there is no clarity on how the EPDP team envisions this would be implemented in the SSAD as a standard.

ICANN org suggests editing the third sub-bullet to state (proposed edit in brackets), “in addition, [the necessity of] each data element in a request SHOULD be evaluated individually.

The text, “If the answer to any of the above questions is no, the Contracted Party may deny the request, or require further information from the requestor before proceeding to paragraph 6 below[,]” raises some technical and implementation-related questions. For example, must Contracted Parties go back to the Central Gateway to request more information or must the Contracted Parties directly interact with the requestor? Additionally, how would such an interaction take place if the Contracted Parties have not already established a relationship with the requestor? Does the EPDP team envision there would be an open ticket with the requestor at the gateway? For clarity, ICANN org suggests rephrasing the sentence “.... disclosure cannot be refused solely …..” to state that, “A Contracted Party MUST NOT refuse a request solely…..”.

Paragraph 5:
Can the EPDP clarify if the use of “MAY”in paragraph 5 is intended to capture situations in which a balancing test is not required as part of a contracted party’s evaluation of a request?

This paragraph refers to determining whether “the balancing test” is applicable. Could the EPDP team clarify what part of this recommendation encapsulates “the balancing test,” and which requests require the “balancing test?” ICANN org understands that it is not the balancing test referenced in GDPR. Is it the bullets listed in paragraph 5 (assessment of impact, etc)? Is it the question: “Do the legitimate interests of the requestor outweigh the interests/fundamental rights and freedoms of the data subject?” And since the factors are listed as SHOULD, may the contracted parties disregard any factor listed herein? Is there a burden of proof for this determination?

The second-to-last bullet in this recommendation, “Status of the controller and data subject,” discusses the Contracted Party’s consideration of negotiating power and any imbalances in authority. Could the EPDP team clarify if this is referring to the relationship between a contracted party and registrant, the data subject and requestor, or another relationship?

Additionally, this text notes that the rationale for disclosure decisions must be documented. The recommendations are clear that the Contracted Party must provide a rationale to the requestor when a request is denied. As a rationale is to be documented in every case, is there any expectation that the rationale also be provided when data is disclosed? Or that the Contracted Party can or must produce this rationale if asked?

Could the EPDP clarify the intent of this language on p. 28: “If, based on consideration of the above factors, the Contracted Party determines that the requestor’s legitimate interest is outweighed by the interests or fundamental rights and freedoms of the data subject, the request may be denied.” Is the intention here that if a requestor’s interest is outweighed by the data subject’s, data can still be disclosed (because the request MAY (not MUST) be denied)? This seems contrary in the context of the test.

Paragraph 6:
The recommendation notes that “The application of the balancing test and factors considered in bullet point #5 SHOULD be revised as appropriate…” It would be helpful to understand the expected process for such revisions to occur. Is this intended as a task for Contracted Parties, as this is the “Contracted Party Authorization” recommendation? Would such revisions be limited to how Contracted Parties apply the test, or would ICANN org or the GNSO be expected to change the policy to account for these? ICANN org understands the use of SHOULD to mean that no revisions would be required based on case law or guidelines issued by data protection authorities. If this is not the intention, this section could be clarified.
General Comment:
ICANN org suggests combining this recommendation with Preliminary Recommendation #16, Automation, so that all recommendations related to automation may be found together.

ICANN org is uncertain how steps 1 through 3 are substantially different from the steps applied for non-automated requests. For example, in order to implement preliminary recommendation 7, the Central Gateway Manager would need to evaluate each request to identify whether the request meets the criteria for automated disclosure, so the steps would be the same for automated and non-automated requests. In addition, what is the intended role for “Signed Assertions” for automated requests?

These sections contemplate that Contracted Parties may request that the Central Gateway automate approval of additional categories of requests (and retract or revise automation). ICANN org understands this recommendation to mean that the Central Gateway would consider such requests for automation and would decide whether to grant such request upon consideration of the rationale for automation and an assessment of the risks associated with such automation.

Implementation Guidance:
The implementation guidance on categories of requests that can be fully automated from the start suggests that the SSAD is expected to contain automation capabilities on Day 1. How is this intended to apply in light of the discretion afforded the Contracted Parties in the paragraph above?

ICANN org notes the complexity of determining which law enforcement agencies may be considered local or from an otherwise applicable jurisdiction. Is this based on where a Contracted Party is incorporated? What other considerations must be taken into account to automate these types of requests?
No, I wish to continue to the next section
For the Central Gateway Manager
Paragraph b) states that the “the Central Gateway Manager MUST...relay the disclosure request to the responsible Contracted Party, if it does not concern a request that meets the criteria for automatic disclosure.” ICANN org understands that all requests that meet the criteria for automatic disclosure must also be relayed to the responsible Contracted Party. Does the EPDP team foresee that automated requests would also be transmitted and relayed in a similar manner to non-automated requests? In addition, what, specifically, must be relayed to the Contracted Party? Is this all information included in a request, or some subset of that information? Is the same information required to be relayed for automated and non-automated requests?

Additionally, In the context of automation, do the Contracted Parties foresee having the ability to review and identify requests that may not be automated based on criteria not being met? Will the EPDP team contemplate how automation would work in practice in terms of liability and safeguards that need to be put in place to mitigate liability risks?

The last two paragraphs in this recommendation (preceding the Implementation Guidance) provide that ICANN Compliance should be prepared to investigate complaints regarding disclosure requests, specifically where the requestor is of the view that its request was erroneously denied. However, the recommendation does not address eligibility criteria for third-party access to Registration Data, whether such criteria includes specific types or groups of third-party requestors, or specifically how certain types of requests should be treated, e.g. intellectual property infringement or DNS abuse cases. Accordingly, it will be difficult for ICANN Compliance to determine whether such denials were “erroneous.”

In light of the recommendation, ICANN Compliance anticipates reviewing compliance with the following:
response adhered to established SLAs;
response included all required content (i.e. denial communicated without disclosure of personal data, rationale for the decision, and (if applicable) how the Contracted Party applied the balancing test);
request was reviewed based on its individual merits; and
disclosure was not refused solely for lack of any of the following: (i) a court order; (ii) a subpoena; (iii) a pending civil action; or (iv) a UDRP or URS proceeding; or solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name (absent any legal requirements to the contrary);

However, ICANN Compliance will not be in a position to address the merits of the request itself or the legal discretion of the Contracted Party making the determination.

General Comment
ICANN org notes that the comments raised with the EPDP team before the publication of the initial report on this recommendation are still applicable and thus shared again here. The comments below note the challenges in enforcing the requirements as written. Additionally, ICANN org may have further comments on this recommendation based on additional feedback on SLAs that has been provided by team members on the mailing list, and looks forward to discussing this recommendation further with the EPDP team on how SLAs could evolve and through what mechanism.

How Priority is Defined ?
The language in this section could result in disagreements in implementation over whether the response times are mandatory or “best effort targets?”

Priority Matrix for non-automated disclosure requests ?
The SLAs as outlined in the Priority Matrix seem contradictory and may be difficult to implement as written. For example, is the recommendation to measure response times based on mean response times, or compliance target percentages as indicated in the table ? Additionally, Phase 3 (18 months of compliance) for Priority 3 seems to be missing from the bullets at the top of page 33. Could the EPDP team further clarify who and how should SLAs be measured? Are these measurements self-reported or measured based on responses to requests via the Central Gateway Operator? Does the EPDP team envision leaving the details above up to implementation?
No, I wish to continue to the next section
General Comments:

As noted in ICANN org’s comments on Preliminary Recommendation #13, ICANN org recommends combining Preliminary Recommendation 10, Acceptable Use Policy with Preliminary Recommendations 13 and 14.

This recommendation is labeled as “Acceptable Use Policy” yet bullet points a) through d) do not seem to address use of the SSAD. Could the EPDP revisit the title of Preliminary Recommendation 10 to ensure it applies to the entire recommendation?

The use of “Central Gateway Manager” in Preliminary Recommendation 10 seems to contradict the role of the Central Gateway Manager in the rest of the policy recommendations. Elsewhere the Central Gateway is expected only to carry out automated checks of requests. This does not seem to align with the language in Preliminary Recommendation 7, which requires the Central Gateway Manager to confirm the elements of the Acceptable Use Policy. Does the EPDP team anticipate this to be more than an automatic check? ICANN org suggests that the EPDP team further clarify if the intention of this paragraph is to reflect that review of disclosure requests is intended to be automatic as noted in footnote 14.

It is ICANN org’s understanding that all recommendations are subject to ICANN Contractual Compliance enforcement. However, as enforcement is referenced only in Preliminary Recommendations 10 and 11, is the EPDP team recommending that other requirements in the policy are not subject to compliance enforcement?

Bullet point a
Is it correct to assume that bullet a) is intended to mean that registrations with expired data cannot be requested through the SSAD and that a registrar will not disclose historic registration data beyond the life of the expired domain?
General Comment

The introduction paragraph notes that the disclosure requirements “are applicable to Contracted Parties and subject to ICANN Compliance enforcement, as well as any automated responses provided by SSAD.” Does this mean that all parties to the SSAD must comply with disclosure requirements if approved for automated disclosure?

Contracted Parties and SSAD

For clarity, ICANN org suggests indicating which responsibilities apply to which parties as it is not clear which of these elements are features of the system, which are obligations for the parties, or both. For example, it seems that “SSAD” should be removed or changed to “all parties to the SSAD,” as it is our understanding that the Contracted Parties are responsible for disclosing data in response to requests, while other entities such as the Central Gateway Manager and the Accreditation Authority are also responsible for processing data in compliance with applicable law.

Has the EPDP team considered what should happen if registration data changes between the time a request for disclosure is received and when a request is evaluated? Would the changed data be considered as historic data if returned once the data changed? Could this be addressed if the Contracted Party were to notify the requestor that the data has changed since the request was filed? Has the EPDP team considered how to address domain names that have expired or transferred since submitting the request?

Has the EPDP considered who would be responsible for responding to requests from data subjects who are seeking to exercise their rights to access or rectification under applicable data protection law (and providing additional notices when the standard notice isn’t adequate under applicable law)? Additionally, could the EPDP team confirm that the Contracted Parties are responsible for responding to data subject requests, as the Central Gateway and other entities within the SSAD would not have access to this data?

In bullet b, the recommendation reads as if the data must be provided in response to any request; rather, we understand that Contracted Parties and SSAD are required to provide current data for an approved request.

Bullet h mentions a “privacy policy” for the SSAD, but there is no clarification on what the privacy policy is intended to cover as there will be other users of the SSAD besides ICANN and the Contracted Parties. Could the EPDP team clarify who the privacy policy is intended to cover (registrants, requestors, others)?
Paragraph Above Bullet c:

The paragraph above bullet c requires further clarification in order to be implemented. The paragraph states, “As with other access policy violations, abusive behavior can ultimately result in suspension or termination of access to the SSAD.” It is unclear whose responsibility it would be to assess policy violations and abusive behavior. ICANN org assumes that this process would begin with the Central Gateway Manager and would be handed off to the Accreditation Authority if it is determined to be an abuse of the accreditation. Yet it is still unclear which entity would receive requests in this context.

Additionally, it is unclear how and why ICANN org would be involved in mediating disputes between a requestor and the entity limiting the requestor’s access. What if ICANN org is the entity limiting the requestor’s access, how does the EPDP team envision such action would be mediated?

Bullet point c:

ICANN org understands that per Preliminary Recommendation 5, the Central Gateway Manager confirms “all required information” is provided. The Central Gateway Manager does not perform any further evaluation of the request; therefore can the EPDP team clarify what it means for the Central Gateway Manager to examine each request on its own merits?

Paragraph under Bullet point C:
This paragraph needs to further specify which parties to the SSAD are responsible for each of the bullets following this paragraph.
ICANN org recommends combining Preliminary Recommendation 10, Acceptable Use Policy with Preliminary Recommendations 13 and 14.

The first paragraph notes that agreements are expected to be developed and negotiated by the parties involved in the SSAD. Is this intended to include ICANN, the Accreditation Authority, Identity Providers, Contracted Parties, users and requestors?

The use of SHALL is used in the associated implementation guidance. ICANN org suggests rewording SHALL to SHOULD.

ICANN org suggests that the EPDP team clarify in the implementation guidance if the SSAD users are meant to be the Requestors, the Contracted Parties, or any party to the SSAD as a whole.

Privacy Policy for SSAD

The second-to-last bullet mentions information about rights of the data subject and the methods that can be used to exercise these rights. Yet it is unclear whether the EPDP Team intends for data subjects to be included among accredited users of the SSAD. Does the EPDP team envision that data subjects would be using the SSAD to request access to their own data or any other type of request?

The last paragraph under this section states, “Further consideration should be given during implementation to whether updates to the RAA are necessary to ensure compliance with these recommendations.” Can the EPDP team clarify which recommendations they are referring to here and if this is specific to the terms of use or a blanket recommendation? Additionally, is the registrar considered to be an “SSAD user” that will be subject to the privacy policy ?

Terms of Use for SSAD Users

The first bullet in this section states that the Terms of Use shall address indemnification of the controllers. ICANN org suggests that the EPDP team clarify which party is responsible to indemnify whom, as well as who is being referenced as the “controller.” ICANN org suggests this bullet be reworded as “address indemnification of the specific party (gateway operator, registry, or registrar).

Lastly, the bullets under the terms of use seem to be a mix of liability considerations and rules. Was this intended by the EPDP team?

Disclosure Agreements for SSAD Users

Can the EPDP team confirm and clarify if the last 4 bullets of this recommendation are requirements for Contracted Parities?
General Comments:
ICANN org recommends combining this recommendation with Preliminary Recommendation #13, Terms of Use, as these appear to be terms applicable to requestors who received non-public gTLD registration data.
General Comments:
From an implementation perspective, it’s unclear how the policy requirements in Preliminary Recommendation #15 may be implemented. We anticipate implementation disagreements about which of these are binding policy obligations vs. implementation guidance. Additionally, Policy recommendations are meant to be binding and specify the responsibility of different parties. If the requirements in Preliminary Recommendation #15 are not meant to be binding then ICANN org suggests rephrasing these as implementation guidance.

Lastly, in determining the fee structure during implementation, ICANN org suggests the EPDP take care to ensure that the fee system does not create additional legal risk (e.g. fees cannot be set up in a manner that could be interpreted as the “sale” of nonpublic registration data under the CCPA).
General Comments:
ICANN org recommends combining this recommendation with Preliminary Recommendation #7, Authorization for Automated Disclosure Requests.

This recommendation does not have clear requirements on what would be automated and who would be responsible for determining what can be automated. For example, who would determine the technical feasibility and legal permissibility of automation?

Lastly, the EPDP recommends that the SSAD contain automation capabilities that will be available on Day 1. This poses a possibility that the implementation of the SSAD will be delayed if the SSAD cannot be deployed until the automation capability is in place. Therefore, is the EPDP team recommending that ICANN org should not implement any aspects of the SSAD until automation is complete ?
No, I wish to continue to the next section
Audits of the Accrediting Authority:
Will the EPDP team revisit this recommendation, as this was written before a model was agreed on? For example, if ICANN org were to be the Accreditation Authority, does the EPDP team foresee auditing as a requirement if arrangements with third party vendors could be enforced through commercial agreement? Or does the EPDP team envision additional audits would be required?

Audits of Identity Providers:
Could the EPDP team revisit each use of “SHALL” requirements in this recommendation and consider whether some ought to be restated as “shall” and some as “MUST?” The team may also consider revisiting the use of “SHALL” elsewhere in the document.


Audits of Accredited Entities/ Individuals:
ICANN org suggests placing everything under this section after the first sentence as implementation guidance. Otherwise this section may lead to confusion during implementation as there are no mandatory requirements and are guidelines for ICANN org, should org decide to audit entities and individuals.
Implementation Guidance:
ICANN org suggests deleting implementation guidance #1, which seems to be misplaced and does not belong under Preliminary Recommendation #19 as it is captured under Preliminary Recommendation #12 Query Policy.
ICANN org would like to thank the EPDP team for its thoughtful and dedicated work in producing this report. ICANN org hopes the comments it is providing in this form are helpful to the team as it discusses community input and finalizes its recommendations.

General Comment:
It would be helpful for the EPDP team to ensure that the Final Report makes clear how the recommendations are intended to be implemented as requirements for Contracted Parties and the other entities in the SSAD. ICANN org envisions that the SSAD policy will identify requirements (using RFC 2119 conventions such as MUST, MUST NOT, SHOULD, etc) for Contracted Parties and the Contracted Parties’ roles in evaluating requests for access to data (for non-automated use cases) and in disclosing registration data in response to both automated and non-automated requests. In addition, clarifications on requirements for the other parties to the SSAD (Accreditation Authority, Identity Provider, etc.) will minimize confusion and help streamline implementation.

“High-level principles/concepts:” SSAD Underlying Assumptions:
ICANN org suggests adding a footnote to clarify that the use of words that also serve as RFC 2119 conventions in this section are meant in their conventional sense in order to state principles. This would avoid confusion for the reader as these may be interpreted as requirements due to the use of RFC 2119 language (e.g. “must not” in the 3rd bullet and MUST in the 4th bullet.)

Main SSAD Roles & Responsibilities:
ICANN org notes that the roles and responsibilities outlined in this section are also further defined in the relevant recommendations throughout the report. As such, can the EPDP confirm that the definitions here provide a high-level overview and that specific requirements as related to each of the roles and responsibilities outlined in this section are delineated in the appropriate recommendations?

Section 3.3:
The fourth bullet under 3.3 states that “the working assumption is that ICANN and Contracted Parties will be Joint Controllers.” ICANN org, in its role as a liaison to the EPDP Team for the purposes of providing implementation-related advice, acknowledges that this is the assumption of the EPDP Team at this stage. ICANN org notes that a determination of the relevant roles and responsibilities of each of the parties will be based on an assessment of the final recommendations during the implementation phase.
56
3/24/2020 5:54:52Graeme BuntonTucows | RrSGYes
Response on behalf of the Tucows family of registrars
No, I would like to continue to the next section
Significant change required: changing intent and wording
The creation of an Accreditation Authority brings significant complications to what should be a simple transaction. An accreditation process can be beneficial for improved user tracking and to reduce the work needed by the responding Contracted Party to validate the requestor’s identity, however there are several aspects of this recommendation which should be modified and the reliance on an Accreditation Authority is misplaced.

The identity of the requestor is insufficient to demonstrate legal right to personal data; authentication of the request in combination with the identity of the requestor is what must be evaluated. Tucows does not note any circumstance in which a third party validating a requestor would circumvent either our own validation process or our review process with respect to the specific request; rather, Tucows notes multiple occasions in our experience in which a known (equivalent to accredited) requestor submitted an inappropriate request. This underscores the fact that the mere identity of the requestor is not sufficient to demonstrate any right to the requested data.

Additionally, each request for data necessitates a review of the requestor’s information and a confirmation that it remains valid and up-to-date, which is simple to bypass if a credential remains valid for ongoing reuse.

An alternative process is currently in use within the industry. The RrSG Minimum Required Information for Whois Data Requests (https://rrsg.org/minimum-required-information-for-whois-data-requests/) expects that each request will include information both about the requestor and about the specific request relating to a specific domain name, and allows self-authentication. A requestor swears, under penalty of perjury, that they are who they say they are and that their use of the data will be lawful. There is no need to insert additional bureaucracy into this process.

There is a significant and concerning lack of clarity surrounding who makes the disclosure decision, which is mentioned in principle (d) underpinning the Accreditation Policy. The registrar of record should be the initial and primary recipient of disclosure requests.

Regarding the definition of “Accreditation Authority”: every party has potential "authority" to gain access to personal data through an SSAD. This is because anyone's rights may be compromised by a domain name and they must, therefore, have the ability to protect their own rights by requesting disclosure of nonpublic registration data. Accreditation must not be only for those affluent enough to buy an SSAD Accreditation. As noted above, there is no reason for accreditation and thus no need for an accreditation authority to manage the personal data of every requestor.

For the “Accreditation Authority Auditor'', adding non-Contracted Party entities and a non-Contractual Compliance auditor is wholly unnecessary, as ICANN Contractual Compliance has authority to audit Contracted Parties. There is similarly no need to introduce an Identity Provider.

The “Identifier Credential” and “Signed Assertions” definitions stand outside the others as being confusingly technical and bearing no apparent relationship to the remainder of this document.

Regarding the definition “De-accreditation of Accreditation Authority”: We note that there is no corresponding discussion or definition of the accreditation of the Accreditation Authority itself. If they can be de-accredited then presumably there will also be an accreditation process for the Accreditation Authority which should be included in this Report.

Regarding Verification: The Contracted Party should conduct a meaningful human review to verify every request. The provided dictionary definition, while generally unhelpful to this recitation of definitions, does, however, acknowledge that automation is not possible. The information must be examined to establish its truth; this is a process that may only be conducted by a human.

Finally, organizations (entities) MUST NOT be accredited; requests to disclose nonpublic personal data should be made by individual users, while their organizational affiliation should be noted. Mere employment by an organization is not sufficient to demonstrate appropriate need for disclosure of personal data, although it may be factored into the decision. Similarly, credential sharing should be considered abusive.
Significant change required: changing intent and wording
If the entity makes the disclosure request via the SSAD rather than directly to the relevant Contracted Party, our response from Preliminary Recommendation #1 still stands: standalone accreditation is not necessary because the requestor’s identity must be validated as part of the review of every disclosure request.

Accreditation of relevant governmental entities is not necessary, both because they have jurisdiction and authorization to request non-public personal data directly from the Contracted Parties under their jurisdiction and because Contracted Parties have legal obligations to respond to those relevant governmental entities. Instead, validation of the requestor’s identity is required, each time a request is processed.

Further, the existence of an accreditation for an extrajurisdictional governmental entity must not presume, under this or any other model, that the entity or government in question can extend its jurisdiction to a CP that would not otherwise be subject to it; ICANN PDPs cannot create new international law.
Support Recommendation intent with wording change
We note the omission of a requirement on the requestor to attest that the content of their request is true or accurate to the best of their knowledge; this must be included. The EPDP team may want to compare this Recommendation against the RrSG Minimum Required Information for Whois Data Requests (https://rrsg.org/minimum-required-information-for-whois-data-requests/).
Recommendation should be deleted
There are many and varied reasonable purposes to request—and to be granted—disclosure of nonpublic personal data. Each request must be evaluated on its own merits. Since an exhaustive list cannot be included, and indeed has not been attempted, we see no benefit in providing a partial list of potential purposes for disclosing nonpublic personal data.

Regarding specifically the purpose “(iv) Registered name holder consent, contract or responses to registered name holders’ requests exercising their right of access,” the SSAD is not being created so that a domain owner can use it to have their own data disclosed to themselves or to a third party. Further, it is not clear what "Registered name holder contract" might mean with regard to a third party’s purpose for disclosure of personal data.

To the point “Assertion of one of these specified purposes does not guarantee access in all cases, but will depend on evaluation of the merits of the specific request, compliance with all applicable policy requirements, and the legal basis for the request”: we agree. We note that this also presumes human review of every request, which is correct.
Support Recommendation as written
Significant change required: changing intent and wording
We strongly support points #1 and #3 of the Preliminary Recommendation. We note specifically that the relevant Contracted Party MUST make the disclosure decision, and this relevant Contracted Party should be the registrar of record.

We support #4 “The Contracted Party SHOULD make a threshold determination…” to the extent that Contracted Parties should be making the ultimate determination, but we do not accept that, in every case, each of these steps are either required or sufficient to make a determination regarding disclosure of personal data.

Regarding the point “Absent any legal requirements to the contrary, disclosure cannot be refused solely for lack of any of the following: (i) a court order; (ii) a subpoena; (iii) a pending civil action; or (iv) a UDRP or URS proceeding; nor can refusal to disclose be solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name.” Each jurisdiction has its own requirements for due process and the disclosure of personal data. We do not agree that the EPDP Phase 2 Team is the correct body to make this determination. Each Contracted Party is perfectly situated to balance both their own local laws and the laws which might otherwise apply to them in this regard. This sentence of Preliminary Recommendation #6 should be struck in its entirety. We additionally specifically note that this sentence of Preliminary Recommendation #6 demands that content be included under the purview of ICANN or the Contracted Parties; this is not the case and the EPDP Phase 2 Team has no authority to attempt this. This must be removed.

In point #5, “Does the data requested contain personal data? If no personal data, no further balancing is required, and the non-personal data MUST be disclosed.”: This is an attempt to circumvent Preliminary Recommendation #17 of the EPDP Phase 1 Team, which allowed Contracted Parties to treat all their customers alike, rather than attempting the unfeasible task of determining whether a data subject is a natural or a legal person. While we agree that legal persons are not protected under the GDPR, we do not agree that the existence of a legal person negates the privacy rights of a natural person affiliated with the legal person. The requirement to disclose the non-personal data should be removed entirely, or the MUST should be changed to a MAY.

“The Contracted Party SHOULD evaluate at least the following factors”: as this list is neither exhaustive nor sufficient, this should be "MAY".

“An interest is generally legitimate so long as it can be pursued consistent with data protection and other laws.”: this presumes legitimacy rather than allowing the determination to rest upon the merits. Where personal data are concerned, privacy should be the presumption and only if the legitimate legal purpose in violating that privacy is sufficient should disclosure be made. The Preliminary Recommendation has this backwards.
Significant change required: changing intent and wording
The Contracted Party MUST be able to decide for itself if any requests for data it holds are handled in an automated manner. If requests are categorized, then each and every category which can be automated MUST be on an opt-in basis. It is unclear if the intent of this section is to mandate automation of at least the categories listed in the Implementation Notes, and as such the level of support is “significant change required” due to that possibility.

In item 1, delete “to qualify as an automated disclosure request.” This implies that providing all this information is sufficient to qualify a request for automated response at some future date. It has not yet been determined whether any request can be automated, so this wording is a dangerous precedent that will be relied upon in the future to prove that automation is allowable where it is not.

Regarding “With respect to disclosure requests that would be sent to a Contracted Party for manual evaluation, a Contracted Party MAY request the Central Gateway to fully automate all, or certain types of, disclosure requests. A Contracted Party MAY retract or revise a request for automation that is not required by these policy recommendations at any time.”: The words “manual evaluation” should be replaced with “meaningful human review”. If automation is selected, the Contracted Party must also have a right to review all decisions made on its behalf by the Central Gateway Manager—which, as we note in our general comment on this Report, is superfluous—and have a meaningful means of recourse in the event that the Central Gateway Manager makes a mistake. This section also presumes that the final policy will require automation in certain instances and the Contracted Party must always have the ability to reject that assumption.

Regarding the Implementation Guidance:

We note that the expectation of automated in-take also requires some mechanism for the Contracted Party to indicate which jurisdictions are considered “relevant” or “local”.

UDRP providers and local LEA are the only entities whose identity must first be validated and whose requests can then potentially be automated in certain cases. This is due to the trust placed in both and the fact that all other requestors' identities are immaterial until the request itself is evaluated.

URS providers may be automated because there is a mechanism to validate their identity: ICANN's requirement that they communicate by means of PGP and ICANN's publication of the public keys for each URS provider.
No, I wish to continue to the next section
Intent and wording of this recommendation requires amendment
In section (c), the sentence “If the Contracted Party decides not to follow the recommendation of the Central Gateway Manager, the Contracted Party MUST communicate its reasons for not following the Central Gateway Manager recommendation so the Central Gateway Manager can learn and improve on future response recommendations.” should be removed entirely. It is an unnecessary added complexity for implementation and there are privacy and other legal concerns with sharing this information with the Central Gateway Manager. The reasoning for failure to abide by the Central Gateway Manager's opinion about disclosure could itself contain personal data or rest upon disclosure of personal data which ought not be disclosed. Additionally, the decision to disclose or not disclose could include proprietary business information which should not be conveyed to the Central Gateway Manager. This should be a MAY rather than a MUST, if it remains here at all.

Section (d) provides that “exceptional circumstances MAY include the overall number of requests received if the number far exceeds the established SLAs.” As we will discuss in the Preliminary Recommendation #9 response, these SLAs are being set by the EPDP Phase 2 Team in a vacuum; there is no understanding of the request volume or how this may affect the staffing needs of all Contracted Parties. There must be flexibility for each individual Contracted Party to identify exceptional circumstances.

Further in section (d), the statement “SSAD requests that meet the automatic response criteria must receive an automatic disclosure response” ought to be “MAY receive an automatic disclosure response”. Contracted Parties should always maintain the ability both to determine which categories of requests receive automated responses and to audit the disclosure of the personal data of which they are stewards, among other things, to protect themselves from liability. Deciding in advance that certain categories of requests must always be automated is not realistic; any automated disclosure must be reevaluated on an ongoing basis to prevent abuse and allow for improvements.

Section (e) should be revised to remove the phrase “including, for example, an analysis and explanation of how the balancing test was applied (if applicable)” as this is a non-exhaustive and not-always-applicable example.

Section (f) refers to “those Requests for which evidence is supplied”; this evidence must also be conveyed to the Contracted Party so they can audit potential abuse of this mechanism.

Section (f) says “Note that the use of ‘Urgent’ SSAD Requests is not limited to LEA.”: this sentence should be modified to limit Urgent requests to only LEA and governmental entities. In what circumstances will a non-LEA/governmental party demand "Urgent" access due to any of these categories? In all cases where such categories are implicated, the requestor should immediately notify their local LEA/relevant authority who can take the appropriate actions, which may include requesting disclosure of non-public personal data related to the domain registration.

For section (g), abuse of Urgent SSAD requests, the Contracted Parties must also have the ability to make the determination that a requestor is abusing the Urgent Request process (and the standard request process).

Regarding Urgent SSAD requests, the Contracted Party must have the ability to determine if a request qualifies as urgent and to recategorize requests accordingly. We discuss this further in our response to Preliminary Recommendation #9.

We note that the concluding phrase “The EPDP Team recommends that, if the Contracted Party determines that disclosure would be in violation of applicable laws or result in inconsistency with these policy recommendations, the Contracted Party MUST document the rationale and communicate this information to the requestor and ICANN Compliance (if requested).” is similar to but not exactly the same as the requirements in section (e), this causes confusion and the two sections should be modified so that they are in alignment and are not duplicative.

Regarding the preliminary recommendation that “If a requestor is of the view that its request was denied erroneously, a complaint MAY be filed with ICANN Compliance. ICANN Compliance should be prepared to investigate complaints regarding disclosure requests under its enforcement processes.” ICANN Contractual Compliance may well be the best place to file the first-line request to review denied requests and ensure the correct processes are followed, but must not be the sole body for such disputes. The appropriate body is the courts of the relevant jurisdictions. (This might include Europe for GDPR purposes, for example.)

The implementation guidance is also duplicative and should be revised in light of the preceding preliminary recommendations.
Intent and wording of this recommendation requires amendment
This Preliminary Recommendation is complex and difficult to follow; it should be clarified for the Final Report. The “response targets” and “compliance targets” are not clearly defined and their meaning cannot be inferred from the text. That said, we do see value in the effort to create a new type of response target which provides flexibility and which is based on the total average response time rather than the response time for each individual request.

Two pieces of this Preliminary Recommendation belong in different sections. (1) The text in the priority section “Following receipt of a non-automated disclosure request from the Central Gateway Manager, the Contracted Party is responsible for determining whether to disclose the nonpublic data.” fits better under Preliminary Recommendation #6 “Contracted Party Authorization”. (2) The statement “If the Contracted Party determines it is unable to disclose the nonpublic data, the Contracted Party SHALL provide a rationale to the requestor and the Central Gateway Manager.” is very similar to Preliminary Recommendation #8 (e) and should be removed from this section; all disclosure requirements belong in the relevant Preliminary Recommendation.


The proposed SLA of 1 business day for Urgent requests is untenable. Volume (which is as yet unknown) must be taken into account, and this must also factor in all the requests that are sent directly to the Contracted Party instead of coming through the SSAD. How has the EPDP Phase 2 Team determined that these SLA proposals are reasonable for small, medium, and large registrars? How has the EPDP Phase 2 Team determined that these are reasonable for small Registry Operators and large Back-end Registry Operators? What testing or investigation has been done to ensure that these numbers are reasonable, achievable, and useful? We propose that 24 business hours (not 8 business hours, which is what 1 business day is) is appropriate as a minimum.

Further, most LEA requests are reasonably urgent even if they are not marked as Priority 1 "Urgent". As we noted in our response to Preliminary Recommendation #8, the Contracted Party must be able to modify the Priority/Urgency status of all requests (either to upgrade or downgrade a request), and this will necessarily impact the response time for other, lower-prioritized requests.

UDRP and URS already have response times built into their respective policies and these need not be revisited here. That said, the proposed SLA of 2 business days for UDRP and URS requests does not take into account the fact that the volume of priority 1 requests will necessarily impact response times for all other requests. As we mentioned in our response to Preliminary Recommendation #7, URS providers MUST request information using their public PGP keys, which can facilitate speed of response. However, UDRP providers must still be evaluated on their merits as any other requestor is. Further, we note that there may be confusion on the part of URS/UDRP providers regarding how to request the disclosure of registration data related to domain disputes. Will all URS/UDRP requests go through the SSAD or will they sometimes be sent directly to the relevant Contracted Party? Requests going to different locations will cause delay and could result in nonadherence to SLAs.

The Phase 1 and 2 response targets are confusing; is the required response time five business days or ten? This should be made significantly more simple to understand before the Final Report is published.

There are open questions which will presumably be addressed in the implementation phase, including: (1) how would a Contracted Party communicate changes in status/removal of ‘urgent’ marker from an open request back to the Central Gateway? (2) Who actually does the SLA calculations, is it the Central Gateway Manager? They are not included in the response by the Contracted Party and so they do not have the necessary information to calculate response times. The EPDP team should provide Implementation Guidance to ensure that the policy recommendations are entirely clear.

The expectation that fully-automated responses will be under 60 seconds lacks consideration of technical requirements and indicates that all Contracted Parties must spend valuable development time creating an automated system that will fit this specific SLA, not grounded in any specific rationale (why is 60 seconds better than 45 or 75?).
See previous response
No, I wish to continue to the next section
Intent and wording of this recommendation requires amendment
A typical Acceptable Use Policy (AUP) discusses the choice of law and reasonable uses of a service; this Preliminary Recommendation does not do that. The AUP as it applies to requestors ought to address things like credential sharing; abuse, including excessively high volume of requests, abuse of automated requests (where automated requests are in appropriate), and abuse of Urgent request designation; and illegitimate requests. Similarly, the AUP should address the consequences of violations, typically including termination of service. Termination of service is discussed in the “Accredited User Revocation & Abuse” section of Preliminary Recommendation #1 and is mentioned in Preliminary Recommendation #12; these disconnected elements, as well as the mention of the “enforcement mechanism” in this Preliminary Recommendation, should be brought together and harmonized to ensure alignment and lack of internal conflict.

The requestor requirements (a) through (d) do not belong in an Acceptable Use Policy and are duplicative of other Preliminary Recommendations. (a) is already in the Disclosure requirement section. (b) is in Rec. 3 criteria of requests. (c) is encompassed in Rec 3 c. (d) belongs in Rec 3 (c) but is not clear enough there and should be expanded in that Preliminary Recommendation. The only point that properly belongs in the AUP is (e).
Intent and wording of this recommendation requires amendment
Again, it is unclear what "an enforcement procedure" even is or what may be reasonable to go through one; this should be further determined. Additionally, this section mentions that the requirements are subject to ICANN Compliance enforcement; this is the case for all Consensus Policy and so there is no need for a specific mention here.

a) MUST only disclose the data requested by the requestor;
Preliminary Recommendation #8 (Response Requirements) indicates that a Contracted Party may disclose less data than was requested (as long as a justification is provided). This directly contradicts that statement. Contracted Parties MUST have the opportunity to provide less data than are requested for a variety of reasons (including where the requestor requests more data that a Contracted Party holds, for example). We propose two alternate texts for this point: Option 1: MAY disclose the data requested by the requestor, adding data at the Contracted Party's discretion or omitting data. (as stated above, with a reason for the omission). Option 2: MAY return current data or a subset thereof; if data are omitted, a reason MUST be provided. Contracted Party need not provide a reason for returning additional data.

b) MUST return current data or a subset thereof in response to a request (no historic data);
This requirement duplicates existing law and should be struck. Additionally, in the event that a Contracted Party believes that a recent change is relevant, they should be free to provide that data to the requestor. "Current" is an unclear term to use. It may well be current at the time of request but historic by the time of response. As a Contracted Party, we assume that "at the time of response" is the "currency" that is intended but, as mentioned above, a very recent change may be relevant and appropriate to disclose to the requesting party. We propose instead this alternate text: “b) MAY return current data or a subset thereof and MAY also include historic data as appropriate.”

“g) Where required by applicable law, MUST provide mechanism under which the data subject may exercise its right to erasure and any other applicable rights;” Data subjects already have the right to contact their Registrar or Registry to correct and/or erase data as applicable. This Preliminary Recommendation should be applicable only to the SSAD or Central Gateway Operator’s obligation to delete or correct requestor data.

“h) MUST, in a concise, transparent, intelligible, and easily accessible form, using clear and plain language, provide notice to data subjects of the types of entities/third parties which may process their data.” This is already a legal requirement in some jurisdictions, and there is no need to expand the obligation to those jurisdictions where it does not apply. We do support the creation of a Privacy Policy for the SSAD, in alignment with the Acceptable Use Policy, Query Policy, and Terms of Use. We note that many Contracted Parties provide contracts in languages not necessarily spoken at or in ICANN communities and so it is not reasonable for the EPDP Phase 2 Team to require only language they have approved to be presented to a data subject. These concerns could all be addressed by changing the MUST to a MAY.

Section (i) “Confidentiality of requests” is in direct contravention to applicable law. For example, the GDPR requires disclosure without the data subject’s explicit request in the event that third parties have received a data subject's personal data. In addition, confidentiality of requests may be reasonable and may be granted but must be reviewed in each case, similar to the review of a disclosure request itself. Where the Contracted Party determines that the confidentiality request is not valid or is being abused (AUP might help here), the Contracted Party may be required by local law to disclose to the data subject as usual, regardless of whether or not the requestor agrees.
Intent and wording of this recommendation requires amendment
We propose the following changes to the practices included in the description of abusive behaviour: 1, Remove “of malformed or incomplete requests.” from item 1, leaving “High volume automated submissions”; 2, remove “high volume automated” from item 2, and break it into two points, those being “duplicate requests” and “requests that are frivolous or vexatious”.

We further note that requesting nonexistent domains could also be abusive and should be considered for inclusion in the abuse section.

The consequences of abusive behaviour are vague and require further definition, as well as alignment with the Accreditation Preliminary Recommendation and the Preliminary Recommendations on Acceptable Use, Terms of Service, etc. Specifically, “As with other access policy violations,” - what other ones? “Abusive behaviour can ultimately result” - What are the results before this ultimate result? How long is abusive behavior to be tolerated by Contracted Parties?

The definition of an abusive request should be expanded to include cases when a list of domains is provided with a list of potential reasons; the reasons provided must be specific and true for each and every domain within the request, otherwise the request is inappropriate. For example, an IP request cannot list 500 domains and a reason "copyright or trademark violation". It may, however, list 500 domains and a single trademark or copyright instance that is being violated by all of the domains.

The requirement for the SSAD to have the ability to split up requests into multiple transactions may not be technically feasible and therefore should not be included as a MUST. Additionally, it should be clarified if the request is to be routed to the Registrar or the Registry; the requestor should not be able to decide this on their own.

Intent and wording of this recommendation requires amendment
Generally, a Terms of Use is the same as the Acceptable Use Policy. Here we have several different policies that may or may not be relevant to any party and yet none of them are sufficient on their own.

The main paragraph of this Preliminary Recommendation can replace Preliminary Recommendations 10 and 12 in their entirety. Any notes to those sections may well belong in this one.

The Privacy Policy for SSAD users says “The types of third parties with whom personal data is shared”; this should include the fact that data subjects will be provided with contact information for the parties that requested and received their data, according to relevant law.

The suggestion that “Further consideration should be given during implementation whether updates to the RAA are necessary to ensure compliance with these recommendations.” must be removed entirely. If the SSAD is a third party, no update to the RAA (or RA, which is not noted) is ever going to be necessary and implying here that it might be well beyond the appropriate scope of the EPDP Phase 2 work.

In the Terms of Use for SSAD users “applicable prohibitions” is very vague. Are these new "applicable" prohibitions such as abuse of the service?

The Disclosure Agreement for SSAD users lacks any reference to the identity of the requestor, which must be disclosed to the data subject in many cases.
Support intent of recommendation with edits
Abuse of this MUST be grounds for termination. Audit of this MUST be available to the Contracted Parties. These two points should be reflected in the Preliminary Recommendation (or the Abuse and Audit Preliminary Recommendations should be updated to clearly include them).
Intent and wording of this recommendation requires amendment
It is shocking that the EPDP Phase 2 Team has determined that registrants should bear the full cost of the facilitation of the disclosure of their personal data to third parties. "ICANN Org" receives its funding from Contracted Parties, which receive their funding from registrants directly. If any party should be charged a fee for this service, it is the requesting parties. The only part of this Preliminary Recommendation that should be kept is “The objective is that the SSAD is financially self-sufficient without causing any additional fees for registrants. Data subjects MUST NOT bear the costs for having their data disclosed to third parties; requestors of the SSAD data should primarily bear the costs of maintaining this system.”

The statement “ICANN MAY contribute to the (partial) covering of costs for maintaining the Central Gateway.” directly contradicts the rest of the paragraph where it is found.

Accreditation for a fee is not necessary, as assertion under penalty of perjury should be sufficient to "accredit" most users. We should recall that not only large companies which represent monied interests ought to be allowed to make requests, but rather anyone with a dispute regarding a domain name that should reasonably have access to the domain owner's personal data should be allowed to make a request.

People tend to value more the things that they must pay for. Paying for disclosure of personal data, then, is not in itself a bad idea, as it forces requestors to make a determination about how necessary the personal data is to their purpose. However, it is never appropriate to disclose data only on the basis of payment being rendered. Therefore, payment should be necessary but not sufficient to process certain requests; the payment is not for the disclosure of data itself, but for the effort required to investigate and consider the request.

Duplicative requests MUST be considered abusive. If additional information is requested, a requestor SHOULD be given the opportunity to respond and this MAY be subject to an additional fee.

This section also mentioned three models, but in the Report we find only one model. We would be fascinated to know what the other three are and perhaps be able to compare their financial suitability. That said, the cheapest, easiest, and most efficient and legal "model" is one where requestors request directly from Contracted Parties, using the RrSG Minimum Required Information for Whois Data Requests.
Intent and wording of this recommendation requires amendment
Tucows supports automation of the request intake process, including gathering the request data and transmitting it to the relevant Contracted Party for review.

The Preliminary Recommendation of automation insofar as it is technically feasible should be expanded to include legal feasibility as well.

Tucows notes that none of the disclosure requests we have received from any party could have been completed in an automated manner. Meaningful human review is required to balance the rights of the parties in question: the privacy rights of the registrant against the usually intellectual property rights of the requestor. Often the balance is such that disclosure is appropriate but in no instance could that be determined without human review.

The statement “standardization of disclosure decisions is the baseline objective.” is concerning and should be removed. Legally-appropriate disclosure decisions should, rather, be the "baseline objective"; the intent should be to recall that there is a balancing of rights and both sides' rights; "standardization of disclosure decisions" speaks to the right to data being placed above the right to data privacy, which is unacceptable.

A "credential check" is only applicable in local-LEA matters; for all other matters, the credential is insufficient and immaterial to the balancing of the requestor’s rights against the rights of the data subject. IIf there ends up being a third party "Central Gateway Manager" or "SSAD" then it is the case that "credential check" may simply consist of a log in so that repeat submitters need not provide their personal details in each case but this is less a "credential check" and more a convenience to the user.

Regarding syntax checking, incoming requests for disclosure of private data ought to be in narrative form (Example: I, Jane Smith, represent Company X whose trademark is infringed in the domain name of xcompanyx.tld. Proof of trademark registration and of my representation of Company X are attached. I request access to the private data of the registrant of xcompanyx.tld for the purpose of pursuing Company X's trademark claims.”) Therefore "syntax" is not an appropriate "check" of requests. Simply reducing this to check boxes or yes/no questions ("are you lawyer y/n" "is there a trademark concern y/n") does not provide sufficient information for a reasonable balancing of the respective rights and tends to invite abuse by allowing users to attempt to click the boxes that they believe will get them an answer they may or may not be due.

“The SSAD MUST allow for the automation of an immediate and synchronous response” — This is a technical requirement that will require development work and a cost to maintain. If this is being outsourced, it should again be noted that the cost must not be borne by registrants (including Contracted Parties or ICANN Org)

"Predictability" of receiving a ticket number is a noble goal; "predictability" of receiving personal data is unacceptable. The latter form of "predictability" is not possible as each request must be reviewed and the rights of each party fairly balanced.

We support the statement that requests “MAY” be automatically processed, as Contracted Parties MUST always have the ability to opt out of automating their legal review of requests.

If any decisions are made by the Central Gateway Manager on the Contracted Party’s behalf, then the Contracted Party must have the right to review those decisions as well as meaningful means of recourse in the event that a mistake was made.

We finally note that the first bullet point of Section 3.1, which describes high-level principles for the SSAD, contains the statement “In areas where automation does not meet these criteria, standardization of disclosure decisions is the baseline objective.” Tucows considers that the baseline objective is, in fact, protection of the various rights at stake: both the registrant's rights and the requestor's rights. Standardization of disclosure format falls under Whois/RDAP PDPs; the decision whether or not to disclose is dependent on meaningful human review and balancing of these aforementioned rights, which is of paramount importance.
No, I wish to continue to the next section
Intent and wording of this recommendation requires amendment
Intent and wording of this recommendation requires amendment
Any audit activity involving a Contracted Party should be treated as ICANN’s allowed audit under the RAA. Further, auditing disclosure decisions is not a reasonable or appropriate goal; instead, ICANN Contractual Compliance should audit adherence to the SSAD model and SLA obligations. The decision(s) made by Contracted Parties to disclose or not to disclose is in every case a matter between the Contracted Party and their relevant legal requirements; disputes regarding disclosure decisions should be raised with a Data Protection Authority. A requestor may well desire that a decision be revisited, perhaps with the help of ICANN Contractual Compliance, but in no event should ICANN Contractual Compliance be making a determination regarding the merits of the Contracted Party's decision.

Each party’s audit section includes a statement regarding the purpose of the audit (“tailored for the purpose of assessing compliance”), this statement should be modified in all cases to be instead “tailored for the purpose of assessing their compliance with this Policy.”

Any information disclosed to an auditor must of course be minimized as required under the GDPR and other data protection law; this should be mentioned.

For audits of the Accreditation Authority, any breach found must be communicated to all data subjects whose data were implicated in these breaches. This is nowhere in the Preliminary Recommendations and is a significant omission.

Regarding the statement “As ICANN serves as the accreditation authority, existing accountability mechanisms are expected to address any breaches of the accreditation policy,” if ICANN serves as the Accreditation Authority, existing accountability mechanisms do not address breaches and ICANN must still be audited for this particular function. There is no reason to exempt ICANN from this audit. We note, however, that the Accreditation Authority itself is an unnecessary element as requestors may simply self-certify in the body of their request directly submitted to the CP for review, and so the audit requirements could be simplified by removing the Accreditation Authority entirely.
Audits of Accredited Entities/Individuals - “the matter should be referred back to the Accreditation Authority and/or Identity Provider, if applicable, for action.” - The action should be termination of account. Contracted Parties are best situated to determine whether some requestors are making abusive requests and MUST be allowed to use past abuse to deny future requests. While an audit right is reasonable to the extent that a contractual relationship exists between the Accreditation Authority and/or Identity Provider, the protection of the rights of the data subjects are what are being audited. That is, proof that data get deleted as required by law; proof that data are not shared beyond what is legally required; and proof that the data were used only for the stated purpose should be auditable events. Any violation should result in termination of access rights to personal data. This need not happen at the point of an audit, however, this ought to be allowable at any time that a Contracted Party has evidence of abuse.
Delete recommendation
The need for this Mechanism is unclear, as it seems to replicate several duties which are already present in the GNSO system. SLA modifications should be conducted via contractual negotiation; categories of requests to be automated and implementation of user categories should occur within the GNSO PDP, and disclosure rationales should be determined by the relevant Contracted Party on a case by case basis.

We were pleased to read that “The Mechanism focuses solely on the implementation of the SSAD and must not contravene the ICANN Bylaws, the GNSO PDP and/or existing contractual provisions for the development of new requirements for Contracted Parties.” It would be inappropriate for the EPDP Phase 2 Team to recommend any method to bypass the existing GNSO PDP or contract update processes. We do note the significant omission of relevant law in what this Mechanism must not contravene; relevant law should also be included here. It must also be the case that simple metrics such as "approved" or "denied" are guarded against; to have sufficient meaning in this context, approval or denial need to be matched to whether the request itself was appropriate or not, including whether it was properly-formatted and whether disclosure would actually achieve the results intended.
The RrSG has created a reasonable and convenient mechanism for requesting disclosure of personal data that allows the Contracted Parties to apply a balancing test to the rights of the requestor against the privacy rights of the data subject taking into account the specific domain name(s) and the disclosure rationale. As Contracted Parties bear the risk for both failing to appropriately disclose and disclosing inappropriately, both under their local laws, they are best situated to make these determinations which will necessarily differ by Contracted Party, by jurisdiction of Contracted Party, by jurisdiction of requestor, and by jurisdiction of data subject. All of these factors are available to be known by the Contracted Party, again placing them in the best position to receive, review, and respond to requests. The EPDP Phase 2 Team is thanked for their tireless difficult work on this matter but is strongly encouraged to simply adopt the RrSG Minimum Required Information for Whois Data Requests as the best means of submitting requests for data disclosure. It is expected that, upon the EPDP Phase 2 Team's decision to do so, ICANN Contractual Compliance will gain the right to audit responses to data disclosure requests to protect the rights of requestors—again, ensuring that Contracted Parties reasonably review and respond to the requests but not to substitute ICANN Contractual Compliance's opinion for the Contracted Party's expert review. This should be sufficient for any reasonable requestor—as indeed registrars that have been using the RrSG Minimum Required Information for Whois Data Requests can attest to. Again, it is expected that ICANN Contractual Compliance's rights to audit this would fall under a standard audit under the Contracted Parties’ respective contracts.
The RrSG Minimum Required Information for Whois Data Requests can be used; alternatively, new policies should go through the standard GNSO PDP, not a Mechanism for improvements.
n/a
Any changes or requirements should occur within the standard GNSO PDP or contractual negotiations as needed.
Support implementation guidance as written
It should be noted that the reason for the request must be identical for each domain in such a bulk request. For example the trademark being infringed in the same trademark for each domain; it is not acceptable to simply provide a list of trademarks that might be infringed in the domains.
It is difficult to suggest what reporting should be required without knowing who the reporting is for and what the goal of it would be. The EPDP Phase 2 Team should collaborate to determine the purpose and recipient of any reports, and their work should be published for comment prior to incorporation into any Policy.
1. The preliminary recommendations do not specify to which Contracted Party the disclosure request is routed. Footnote 8 of the “Main SSAD Roles & Responsibilities” section indicates that the default recipient is the registrar, but in some circumstances the registry may be the recipient; this should be clarified and included in a Recommendation.

2. None of these preliminary recommendations address to whom the Contracted Party provides data being disclosed. The high-level principles indicate that data “are returned from the relevant Contracted Party directly to the requestor,” this should be included in Preliminary Recommendation #8 (Response Requirements).

3. Nothing in this Report addresses exactly how data are to be provided to the requestor. This must necessarily be done in a secure manner. This is a significant piece to leave for the Implementation phase and should be further considered, also in Preliminary Recommendation #8 (Response Requirements).

Tucows notes that there are many aspects of these Preliminary Recommendations which will require significant implementation efforts by Contracted Parties, ICANN, or other members of the community in order to achieve compliance. For example, returning disclosed data directly from the Contracted Party to the requestor, while entirely appropriate from a data protection perspective, is complex to operationalize in a manner that offers more security than a simple plain-text email.
We have two overall comments:

1. The content of the Initial Report speaks to a general lack of concern for protecting the privacy of personal data and a slide towards prioritization of third-party interests over those of the data subject. We also note that much of the work done in Phase 2 of the EPDP appears to be proceeding towards an externally-determined desired outcome rather than examine the situation in good faith and finding consensus among the GNSO Stakeholders on the best outcome. Finally, there is a pattern of ICANN Org staff circumventing the EPDP Phase 2 Team, including having groups outside the EPDP develop data disclosure models or ex parte meetings with DPAs, both of which could have had beneficial outcomes when done within the EPDP structure.

2. The Initial Report is contradictory at times, duplicative at others, inconsistent, and often incoherent. The overall theme of the recommended model is one of adding complexity and ignoring standardized processes that already exist; all Preliminary Recommendations should be reconsidered with a view to simplification and clarity as well as prioritization of data privacy. The recommended SSAD places new contractual, legal, technical, and costly burdens on all parties and recommends the creation or involvement of three or four additional third parties which are not necessary for the release of personal data upon reasonable request and within appropriate timeframes.

We will also take this opportunity to reiterate some of the most important points from our review of the Preliminary Recommendations, specifically focusing on areas of significant disagreement or omissions from the Preliminary Recommendations which should be corrected.

1. The decision to disclose data must reside with the relevant Contracted Party, which is the registrar of record.
2. If any decisions are made by the Central Gateway Manager on the Contracted Party’s behalf, then the Contracted Party must have the right to review those decisions as well as a meaningful means of recourse in the event that a mistake was made.
3. Any automated disclosure decisions must be on an opt-in basis for each Contracted Party.
4. Regarding Urgent SSAD requests, the Contracted Party must have the ability to determine if a request qualifies as urgent, and to recategorize requests accordingly.
5. The Acceptable Use Policy, Query Policy, Terms of Use, and Privacy Policy should be harmonized and better coordinated with each other.
6. The consequences of abusive behaviour are vague and require further definition, as well as alignment with the Accreditation Preliminary Recommendation and the Preliminary Recommendations on Acceptable Use, Terms of Service, etc.
7. Registrants must not bear any cost of the facilitation of the disclosure of their personal data to third parties.
8. Any further obligations or improvements must be developed within the GNSO PDP and must not be imposed on Contracted Parties in circumvention of the community-driven multistakeholder model.
9. Any breach found must be communicated to all data subjects whose data were implicated in these breaches.

Regarding the legal input from Bird & Bird, Tucows is pleased that the EPDP sought legal advice but is frustrated that the legal advice received has often been ignored or called into question by non-experts in this specialized legal field. We encourage the EPDP Phase 2 Team to incorporate this valuable input into decisions being made.

Tucows would like to thank the ICANN Staff team for providing comprehensive worksheets to aid the Team’s work in reviewing various topics. The worksheets were well-formatted and were helpful in grounding the EPDP PHase 2 team’s collaborative work in common understanding of the issues at hand.

Related to the Note at the beginning of Section 3, which explains that the GDPR is the only law specifically referenced in this Report, Tucows notes that the GDPR compliance work we have done within the ICANN community puts our industry in a good position to be compliant with new privacy laws as they roll out. The global trend is toward the protection of privacy and Tucows wholly supports this note.

The Central Gateway

The benefits of a Central Gateway are not sufficient to outweigh the significant complexity this proposed SSAD brings to the disclosure request process.

The presumption that there must be a Central Gateway is itself flawed. A central point of access is simply a third party inserted into a process that does not need it, in direct contravention of the GDPR's requirements to minimize processing of personal data.

A Central Gateway, albeit improved by not holding the registration data itself, still provides a central point of compromise for requestor data; these requestors are also worthy of data protection.

The suggestion that the Central Gateway would allow for opportunities to socialize the location and method for requesting non-public data is of limited utility; this objective could just as easily be achieved by hosting a list of registrar contact points, and although other work efforts have included a “socialization” aspect (Universal Acceptance, NTAG) these efforts have achieved only limited success.

A Central Gateway is similarly not required in order to standardize request formats. The RrSG has helpfully provided a standardized request form which aligns clearly with Preliminary Recommendation #3 “Criteria and Content of Requests”. Tucows notes that some frequent requestors have already adopted this form, vastly reducing the time for review and thus, the time between request and lawful disclosure. This form is available at http://icannregistrars.org/wp-content/uploads/2019/02/RrSG-Minimum-Required-Information-for-a-Whois-Data-Requests.pdf.

Tucows feels that complicating the transaction of requesting and disclosing private registration data by inserting a Central Gateway is not necessary or desired and supports a model based on the RrSG standardized method, including self-reported SLA compliance supported by ICANN's Contractual Compliance team as is every other Contracted Party contractual requirement. Tucows notes that similar requirements are routinely successfully audited by ICANN's exemplary Contractual Compliance team.
57
3/24/2020 9:17:24GAC Small GroupGACNo
No, I would like to continue to the next section
Support Recommendation as written
Support Recommendation intent with wording change
This recommendation allows for accreditation of governmental authorities. The GAC notes, however, that countries’/territories’ chosen accreditation authorities would need to coordinate with ICANN org in order to facilitate appropriate delivery and interoperability of credentials into the SSAD. The level of safeguards are well balanced and recognize both the needs of confidentiality for certain requests, such as those made by law enforcement, and the need for appropriate levels of transparency for non-sensitive requests.

The actual implementation of preliminary recommendation #2, including the arrangement with ICANN, is done by each country/territory according to their governmental and regulatory system. This includes the decision of whether the Accreditation Authority of each country/territory is limited to just one organization or applicable to multiple organizations.

The GAC recognizes that there are non-governmental organizations/private companies commissioned by, or collaborating with governments for pursuing public policy tasks, which should have an appropriate ability to become accredited. The issue of whether, how and when they are permitted to be accredited via a government’s accreditation to the SSAD needs further consideration by the EPDP Team.
Support Recommendation as written
Support Recommendation as written
Support Recommendation intent with wording change
The GAC recommends IMMEDIATE acknowledgement of receipt of an SSAD request, which could include via an automated system due to the fact that such acknowledgement by the responding party is important, so that the requestor has confirmation that its request has been received.
Support Recommendation intent with wording change
The GAC recommends automation of requests to the fullest extent possible consistent with the GDPR. This may include processing activities delegated to third parties when necessary.

Part of Recommendation #6 currently reads: “2. If deemed desirable, the Contracted Party MAY outsource the authorization responsibility to a third-party provider, but the Contracted Party will remain ultimately responsible for ensuring that the applicable requirements are met.”

The GAC recommends changing this recommendation to the following wording: “If deemed desirable, the Contracted Party MAY outsource the authorization activity to a third-party provider, but the Contracted Party shall remain ultimately responsible for ensuring that the applicable legal requirements are met”

The GAC emphasizes that while contracted parties may work with third parties on authorization activities: in terms of controllership, the Contracted Parties remain responsible and accountable for authorising disclosure. Therefore, the degree to which they can outsource this responsibility, by an agreement, to a third-party provider needs to be further examined. According to the latest correspondence from the Belgian DPA (4 December 2019) a controller “…cannot abdicate its responsibilities by virtue of a joint agreement.”
Support Recommendation intent with wording change
The GAC supports the intent of this recommendation but would like the EPDP team to clearly define all cases for automation including identification of who is making the decision. Whilst the GAC believes that there are a number of other cases that could be included at the start, the GAC highlights that these cases will need to be specified to avoid any confusion as to what particular use case applies to a specific request.

The GAC observes that the current proposal regarding requests from law enforcement does not provide guidance on what is/are the relevant jurisdictions to take into account in determining whether a law enforcement request takes place in a “local or otherwise applicable jurisdiction” and hence qualifies for an automated disclosure response. The GAC recommends that the location of the law enforcement agency making the request and location of the registrar providing the data constitute an important, though not exclusive criteria to consider. For example, registrars may have offices in multiple jurisdictions and would automate response to requests from law enforcement agencies within those jurisdictions.

In addition, there needs to be more consideration of what happens in case of erroneous automated assessment and recommendations for release by the central gateway, and subsequent release of personal data by relevant contracted parties.

Regarding the following language: “A Contracted Party MAY request the Central Gateway to fully automate all, or certain types of, disclosure requests.” The GAC advises that further clarification is needed as to whether the automation refers to requests to a particular Contracted Party (CP) or is intended for all CPs. It is also unclear whether particular CPs may choose to automate similar requests from particular requesters.

The GAC recommends that the scope of this automation is widened once the appropriate safeguards and procedures are put in place. These procedures should ensure that the multi-jurisdictional needs of law enforcement to protect the public and combat crime are met, whilst maintaining appropriate levels of data protection for the data subject.

For the purposes of the SSAD, Law Enforcement should be defined as including any government authority vested with law enforcement or investigative authority in civil or criminal matters.
No, I wish to continue to the next section
Support recommendation as written
Support intent of recommendation with edits
The GAC’s representatives emphasized during EPDP Team deliberations that the currently proposed “1 business day” service level agreement (SLA) for “urgent requests” is too long. Urgent requests are “limited to circumstances that pose an imminent threat to life, serious bodily injury, critical infrastructure (online and offline) or child exploitation.” The current SLA could result in a compliant response time of 72 hours or more if the request falls over a holiday weekend. Moreover, the SLA’s are phased over 18 months and never achieve 100% compliance with this 1-business day response requirement.

The GAC strongly recommends no more than a 24-hour response time for this narrowly defined category of requests requiring expedited responses in order to protect the public from grave harm. The GAC also urges swift implementation of this requirement with as close to 100% compliance as possible.
The GAC observes that the proposed review times for response and compliance targets (every six months in the first year and annually (depending upon the outcome of the first review) may be insufficient to identify and address potential problems. If there is a significant failure to meet SLA targets, it is important that any review mechanism takes place often enough to identify problems early on, rather than waiting 12 months or more to even begin an assessment. Accordingly, the GAC recommends that the reviews take place quarterly during the first year, with an opportunity to move to every six months if the first assessment indicates widespread and successful compliance.
No, I wish to continue to the next section
Support intent of recommendation with edits
The GAC notes that the governmental users of the SSAD are necessarily resource constrained, and by and large have little flexibility in adjusting their budgets to accommodate new financial commitments. Therefore, the GAC welcomes the EPDP team’s recognition that “governments may be subject to certain payment restrictions,” and that the “fees associated with using the SSAD may differ based on … user type.” The GAC understands that the SSAD must be financially self-sufficient, and looks forward to working in the implementation phase to develop an equitable fee structure that does not make it cost-prohibitive for governments to use the SSAD.
Support recommendation as written
No, I wish to continue to the next section