fr

Public Comment

Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.

Ce contenu est uniquement disponible en

  • English

Name: Registries Stakeholder Group (RySG)
Date: 13 Jan 2022
1. EPDP Phase 2A Rec. #1 provides, in part, “The EPDP Team recommends that a field or fields MUST be created to facilitate differentiation between legal and natural person registration data and/or if that registration data contains personal or non-personal data. ICANN org MUST coordinate with the technical community, for example the RDAP WG, to develop any necessary standards associated with using this field or fields within EPP and the RDDS.” Please refer to p. 6 of the Final Report for the full text of the recommendation. Is there any new, specific, and concise information the ICANN Board should consider with respect to Recommendation 1?

The RySG continues to believe that recommendation 1, remains merely an implementation matter, and does not materially benefit the question as to how the differentiation implied by such a data element, may actually be achieved in a consistent manner that pays due heed to compliance with relevant laws relating to the handling of data, personal or otherwise. 

The RySG continues to state that the underlying utility, use and indeed justification/necessity for the creation of the  data element, remains hugely unclear. The RySG, in the spirit of the multistakeholder model, and noting the insistence of our colleagues, vis á vis inclusion (prior to the GNSO Council vote), saw no reason to seek to block the recommendation; however, we will urge the Board, in their consideration, to consider the lack of clarity as to what benefit such a data element achieves in the absence of stated outcomes which remain unforthcoming by those initial proponents. 

Finally, we further believe that the recommendation is not without significant implementation issues, many of which remain wholly conditional on third party processes, for example, the actual definition of the data element will lie within the IETF and not ICANN’s remit.

2. EPDP Phase 2A Rec. #2 provides, in part, “The EPDP Team recommends that Contracted Parties who choose to differentiate based on person type SHOULD follow the guidance1 below and clearly document all data processing steps.” Please refer to p. 7 of the Final Report for the full text of the recommendation. Is there any new, specific, and concise information the ICANN Board should consider with respect to Recommendation 2?

The RySG encourages the Board to consider our minority statement in this matter. The RySG are exceptionally supportive of any and all attempts to help clarify the means by which, we , as contracted parties may, with some uniformity, apply the expectations of data privacy legislation, ensuring that data that should be protected, is protected, and to the greatest extent achievable, that non-personal data is made appropriately available. For this reason we supported voluntary guidance. This being noted, and as we have explained,  we do not believe that the guidance that was ultimately created, is of any great practical application and use. The guidance is merely a restatement of legal principles, and provides little or no ‘guidance’ as to how practically such principles are to be applied. The RySG does not believe the guidance to be wrong, just that it offers little or no substance to properly inform the contracted parties, as was hoped. 

3. EPDP Phase 2A Rec. #3 provides, in part, “The EPDP Team recommends, in line with GDPR Article 40 requirements for Codes of Conduct, that the above developed guidance concerning legal/natural differentiation should be considered by any possible future work within ICANN by the relevant controllers and processors in relation to the development of a GDPR Code of Conduct.” Is there any new, specific, and concise information the ICANN Board should consider with respect to Recommendation 3?

The RySG refers to our comments made at 2 above, and add that, although such guidance is certainly a starting point for any Art 40 type Code of Conduct, the RySG would expect that a far more detailed approach, than what is currently contained in recommendation 3, would be required. The RySG would refer the Board to the statement of the Irish Data Protection Commission, insofar as they have noted “A GDPR ‘Code of Conduct’ is more than just a guidance or best practice document, and it must materially specify or enhance the application of data protection law to a certain sector or processing activity – not merely be a restatement of the GDPR”. (see: https://www.dataprotection.ie/en/organisations/codes-conduct) . It is in this vein that we would again remind the Board that in its current form, the proposed code of conduct remains quite removed from that which would be considered ‘guidance’ sufficient to meet the requirements of Article 40.

4. EPDP Phase 2A Rec. #4 provides, in part, “The EPDP Team recommends that Contracted Parties who choose to publish an intended to be pseudonymized registrant-based or registration-based email address in the publicly accessible RDDS should evaluate the legal guidance obtained by the EPDP Team on this topic (see Annex F), as well as any other relevant guidance provided by applicable data protection authorities. Is there any new, specific, and concise information the ICANN Board should consider with respect to Recommendation 4?

-

5. Other Comments

The RySG would like to thank the Board for this opportunity and again would like to affirm our belief that the multi-stakeholder model is at its best when it seeks to enable the contracted parties to comply with laws as it may apply to them individually, across the global legislative landscape. We submit that we continue to earnestly support ICANN and its mission, and we do urge the Board, especially in light of recent legislative lobbying and activism, that the  ICANN community is at its most effective, when we create policy that does not seek to enforce individual laws, by individual nations or collectives, but policy that supports and guides the ability of the contracted parties to ensure their own individual compliance, within a global, predictable, and homogeneous policy framework protecting the core stability and security of the DNS. 

Summary of Submission

The Registries Stakeholder Group (RySG) would like to thank the Board for this opportunity and again would like to affirm our belief that the multi-stakeholder model is at its best when it seeks to enable the contracted parties to comply with laws as it may apply to them individually, across the global legislative landscape. We submit that we continue to earnestly support ICANN and its mission, and we do urge the Board, especially in light of recent legislative lobbying and activism, that the ICANN community is at its most effective, when we create policy that does not seek to enforce individual laws, by individual nations or collectives, but policy that supports and guides the ability of the contracted parties to ensure their own individual compliance, within a global, predictable, and homogeneous policy framework protecting the core stability and security of the DNS. 


The RySG provided feedback on the Board’s questions.