FINAL VERSION SUBMITTED (IF RATIFIED)
The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.
DRAFT SUBMITTED FOR DISCUSSION
The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).
Updated version by Hadia Elminiawi, Bastiaan Goslings, Laurin Weissinger and Matthias Hudobnik on 21 March 2020:
The ALAC appreciates ICANN putting forward the EPDP on the temporary specification for gTLD registration data, phase 2 report for public comment and takes this opportunity to provide its comment herewith.
For all Recommendations not listed here, we are recommending that the ALAC “Support as written”.
Recommendation #1: Accreditation
Response: Support 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.
Recommendation #6: Contracted Party Authorization
Response: Support 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.
Recommendation #7: Authorization for automated disclosure requests
Response: Support 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 site 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.
Recommendation #9: Determining variable SLAs for response times for SSAD
Response: Support with wording change.
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 one day 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.
Recommendation #15: Financial Sustainability
Response: Support with wording change.
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.
Recommendation #19 Mechanism for the evolution of the SSAD
Response: Support with wording change.
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 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).
Reporting Requirements
- Are there any recommendations the EPDP Team has not considered? If yes, please provide details below.
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.
General Comment
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.
Original draft posted by Alan Greenberg on 19 March 2020 at 02:00 UTC:
The ALAC appreciates ICANN putting forward the EPDP on the temporary specification for gTLD registration data, phase 2 report for public comment and takes this opportunity to provide its comment herewith.
For all Recommendations not listed here, we are recommending that the ALAC “Support as written”.
Recommendation #1: Accreditation
Response: Support 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.
Recommendation #6: Contracted Party Authorization
Response: Support 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 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.
Recommendation #7: Authorization for automated disclosure requests
Response: Support 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 site 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.
Recommendation #9: Determining variable SLAs for response times for SSAD
Response: Support with wording change.
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 is one day 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.
Recommendation #15: Financial Sustainability
Response: Support with wording change.
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 soruce 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 CERTS, academic research and similar endeavours.
Recommendation #19 Mechanism for the evolution of the SSAD
Response: Support with wording change.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 from all stakeholders. The responsibility of the SSAD implementation council would be looking into the types of disclosures that out of experience are deemed to 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).
General Comment
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.
