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

Compare with Current View Page History

« Previous Version 6 Next »

Public Comment CloseStatement
Name 

Status

Assignee(s)

Call for
Comments Open
Call for
Comments
Close 
Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number

17 April 2019

COMMENT

To be ALAC advice to the ICANN Board.

Hide the information below, please click here 

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).

ALAC Advice to the ICANN Board related to the Phase 1 Final Report on the Temporary Specification for gTLD Registration Data EPDP

The ALAC has significant concern related to three aspects of the EPDP Report. Specifically, the ALAC is concerned not only with the outcomes, but with the process that was followed to address the issues.

All three impact the ability to access registration data and the completeness of that data. As such the issues call into question whether the EPDP Recommendations address a key requirement in the Temporary Specification (and since confirmed as an important criterion by the Board. Specifically: “to identify the appropriate balance for a path forward to ensure compliance with the GDPR while maintaining the existing WHOIS system1 to the greatest extent possible”.

Moreover, the EPDP was to address compliance with the GDPR and not to re-legislate and revise existing ICANN policy unless it impacted GDPR compliance.

The issues raised here are in alignment with previous ALAC statements and moreover are all strongly supported by the SSAC as well as others in the ICANN ecosystem.

Effective Disappearance of Thick WHOIS

With one exception, all new gTLDs authorized under the auspices of ICANN have operated under Thick WHOIS rules whereby all registration data is transferred to the registry. The only exception is .JOBS along with two legacy TLDS .COM and .NET. The Thick WHOIS PDP recommended (with unanimous consensus) that the three Thin WHOIS TLDs convert to THICK and the recommendation was ratified by the GNSO Council and by the Board.

The EPDP does not require that all TLD operate under Thin rules, but makes it extremely unlikely (i.e. is virtually impossible) that there be any other result. Specifically, the EPDP allows all data to be transferred to registries only if all parties agree that there is a strong legal basis for doing so, and it is clear that some contracted parties do not agree that there could be such legal basis, and the issue was not really discussed for this reason.

The EPDP did ask its independent legal counsel whether thick WHOIS was “legal”, but the reply had not been received at the time the report was issued. It has since been received[1] and says, in short, that the arguments presented in the Thick WHOIS PDP report are sufficient justification for allowing Thick WHOIS throughout the gTLD space.

The issue is particularly relevant because the way the Temporary Specification has been implemented has shown that the registrar and registry for a given registration may apply radically different redaction rules on the same registration.

The ALAC advises  the Board to request [require]  that the issue of Thick WHOIS issue be re-opened during the EPDP Phase 2 in light of the new legal opinion.

Geographic Differentiation

GDPR, in rough terms, only applies to entities within the European Economic Area (EEA) and to entities outside of the targeting individuals resident within the EU. It specifically does not apply to entities outside of the EEA that do not process data within the EEA or target customers within the EU.

The Temporary Specification allowed contracted parties to apply the GDPR globally without consideration of geography, and the EPDP is recommending the same rule.

The issue was never substantially discussed within the EPDP, with arguments for preserving the Temporary Specification rule being:

  • It is too difficult to determine the location of a registrant
  • Other jurisdictions might also have privacy regulations
  • Privacy is a good thing and we should preserve the privacy of all registrants

The first point was never discussed in any detail, nor was it explained why one could not rely on Country field in the registration data (a field that the registrant is required to provide and certify that it is accurate).

The second point is certainly true, although some jurisdictions might have less stringent rules, and the EPDP was charted SOLELY to address GDPR compliance.

The third point is certainly accepted by many (including those within At-Large) but the EPDP was not chartered to be an all-encompassing privacy PDP, but to address compliance (and not over-compliance) with the GDPR.

Moreover, there was virtually no discussion about the impact of security and stability of redacting vast amounts of data not required under GDPR. GDPR is explicitly requires balancing various needs and this was not considered during the EPDP.

At the time the report was issues, there was also an outstanding question to the EPDP legal counsel whether ICANN’s presence in the EU imply that the GDPR apply ALL personal data regardless of location, and this possibility was a consideration in the recommendation. The EPDP has since received a legal opinion[2] that the ICANN European offices do not made ICANN sufficiently European as to have GPDR apply in all cases.

A number of members within the EPDP (including those from the ALAC and SSAC) understood that there would be further study and discussion of the issue during Phase 2, but apparently that was not the understanding of the all.

The ALAC advises the Board to request [require] that the issue of geographic differentiation be re-opened during the EPDP Phase 2 in light of the new legal opinion and the lack of considering the competing needs of privacy vs the benefits of non-redaction on cyber-security activities and that the ensuing discussion factor in the needs of those using the data for cyber-security and other legitimate purposes.

Legal/Natural Person Differentiation

The Temporary Specification allows contracted parties to treat legal persons as natural persons and redact data, and the EPD does the same.

The issue was discussed during Phase 1. The rational for allowing contracted parties flexibility was that there is currently no indication within the registration data that explicitly indicates that the registrant is a legal or natural person. Some registrars have used the Organization field for this purpose but others have not done so.  Again, the balancing of the needs of contracted parties for simple solutions was not balanced against the competing needs for data access.

The Legal/Natural Person is on the agenda for discussion within Phase 2, but there is no indication that the outcome will be any different than during Phase 1, and the EPDP practice has been to favor contracted party needs when the group is divided[3].

It is understood that if a legal/natural distinction is to be required, registrars will need to be given significant time to phase this.

The ALAC advises the Board to request [require] that the issue of legal/natural  differentiation be discussed  during the EPDP Phase 2 explicitly considering the competing  needs of those using the data for cyber-security and other legitimate purposes.

 

 



[1] https://community.icann.org/download/attachments/102138857/ICANN%20-%20Memo%20on%20thick%20Whois%5B1%5D.docx

 

[2] https://community.icann.org/download/attachments/102138857/ICANN%20-%20Memo%20on%20Territorial%20Scope%20.docx

 

[3] This was clearly indicated by how the Technical Contact field was handled. These fields will be optional for registrants to complete, but some registrars preferred to not collect the fields at all (a change from the Temporary Specification) and that is how it ended.

  • No labels