Dear EPDP Team, Please find below the notes and action items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV...> from today’s meeting. Best regards, Berry, Marika, and Caitlin -- 🚨 Action Items 🚨 Please refer to the project spreadsheet<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV...> for action items. EPDP Phase 2A - Meeting #21 Proposed Agenda Tuesday 11 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Legal vs. natural (30 minutes) 1. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); 2. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. Question i – Whether any updates are required to the EPDP Phase 1 recommendation on this topic * Walk through of staff proposed write up of Initial Report text * Want to make sure there is clarity about internal registrar flagging function OR whether the expectation is the flag should be displayed in the output * Maybe the hang up is whether it is a global flag. For every query, the registrar could say “the flag is not set”. With respect to the wording about where SSAD appears, would like to lay a path where we separate the concepts we are talking about from the SSAD implementation. SSAD is just one way to implement differentiated access. The recommendation would be stronger if SSAD is not referenced. * EPDP Phase 2A is a follow on from Phase 1 and 2, so there is an expectation that the group is basing its work on the SSAD, so do not think the reference to SSAD as an element that retrigger the group’s work should be removed. Perhaps consider adding text like “or alternative differentiated access model”. * Registrars implement all sorts of flags – autorenewal, privacy/proxy service – ICANN has nothing to do with what registrars do internally. The language on the screen implies we are talking about new fields in the RDDS, which is what is needed for differentiation of legal/natural. We should use the same language for Phase 1 – Phase 1 had five recommendations (5-10) that detail specific things about registration data. If we are specifying a new RDDS field here, we need to specify all of the details that were specified for Phase 1. * As many members know, the NIS2 proposals seem to be getting stricter and require more of the CPs if the proposals are adopted. The community should think hard about what will happen when the NIS2 is adopted – another EPDP or pause of Phase 2? Team may need to update these requirements. * The language references some EPDP members are of the view that EPDP Phase 1 should be maintained for controller flexibility – in the face of privacy legislation that is changing and evolving across many jurisdictions, it is difficult to write future-proof policy that can take all situations into account. The current language (allowed but not required) provides necessary flexibility. * With respect to the flag language, this is confusing. In Phase 1, there is a recommendation regarding registrars providing registrants the ability to provide consent to publish – this may be a flag of some sort, but there is not detailed language around a flag. It is up to the registrar how this is captured, but per the requirements, they would need to offer and capture that choice. In terms of publishing this, it doesn’t make sense that the flag would be indicated in the RDDS output. How would this flag apply on the legal natural differentiation, and how would this be published? This may not be a best practice. * The recommendation doesn’t appear different than what the GNSO Council should be doing anyway. It may be worth considering previous points of what would happen – Phase 2B? New EPDP? There is additional work that is required for this recommendation. * The EPDP came about because the policy was at odds with the law. NIS2 is its current state does not require a policy change. Strongly disagree with phrasing in recommendation 1 – it can be answered without the additional language. * There is more convergence at an international level – the GDPR and developments in Europe are being looked at by everyone and are guiding other jurisdictions. Important to note that the place where the privacy laws were developed make a clear distinction between legal and natural data. It is important for this group to not lose sight of where we are coming from – maintaining Whois to the greatest extent possible while complying with the GDPR. * The scope of the GDPR is clear – it applies to natural persons, but what is unclear is a definition of legal persons. Recommendation 2 is confusing – CPs have a duty to ensure their documentation of the consent of a natural person is clearly recorded. Telling people that they have to have a flag solely for the benefit of third parties is ridiculous. Suggest removing the language regarding a flag. * Somewhere in this document it explains the contents of this flag could be “unknown” – don’t agree with this; it should be empty instead of unknown. Flexibility is good, and while the wording needs to be updated, nothing changes since this is an optional field. NIS2, even in the current versions, will not likely require policy, but that is why this field in the RDDS is necessary. * The guidance should be as flexible as possible. * Remind the group that as we started this process the goal was to stay as close to the old Whois system as much as possible so long as it’s compliant with GDPR. There is a recognized benefit in having the information publicly accessible and widely shared so long as it’s compliant with law. * The group seems to repeat the same arguments over and over again. There has not been a single valid reason why redacted information that is not protected under any law is redacted. From a technical feasibility perspective, having the capacity for flags involves no risk and is line with the guidance from contracted parties that wish to differentiate. With respect to Point 2, suggest deleting “unknown” because it may create more problems than it solves. This could lead to bad faith registrants abusing the system. * There are two different interpretations over what the GDPR protects – this discussion has been had many times. Distinctions can be made without flags – why should a flag be chosen over all others? * Contracted parties do not need a policy to tell them to follow the law. When a new law comes out, do not need to wait for a policy to explain or require CPs to follow the law. * Having no policy at all – what is the purpose of having a multi-stakeholder policy development process – why can’t we be forward looking, anticipate new laws, etc. * The text will be circulated via a link and get feedback by Friday, 14 May. Please provide suggested edits (in comment form) with an eye toward reaching consensus. The capability to differentiate is a worthwhile goal; the flag may be a bit of a distraction, and the group may not be able to agree to the specifics. Focus on the high-level policy goal rather than focusing on being overly prescriptive. * Confirm next steps – proposed deadline for comments / suggestions / proposed edits Friday 14 May 2021 Guidance write up * Brief overview of main changes applied. * The Staff Support Team reviewed all input received on the LvN guidance. In addition to identifying cannot live with items, there were many additional comments and suggestions made by EPDP Team members. In the second version that you can find in the google doc<https://docs.google.com/document/d/103kazmQlFxRmecNosslsZhg6u0MwxoZ5DiZj86j0...>, you can see all the updates that we made and responses to the comments. * A number of comments were received in relation to the concept of the flag or a defined data element – these have not been applied here as this approach is expected to be further considered in the context of the write up in response to the consensus policy question. * The Registrar Team provided feedback that a number of GDPR principles from the table were not sufficiently highlighted in the write up. The Staff Support Team called these out in the background information section to make clear that in addition to the guidance there may be other principles that Registrars need to factor in when dealing with personal information. * A number of comments / questions were made in relation to instances where differentiation may not be possible at the time of registration. This has been discussed previously, but we have called it out as a separate question for discussion so that we can attempt to resolve this topic to everyone’s satisfaction. * We’ve moved the disclaimer language to the beginning of the guidance section instead of the end as there were suggestions to add new disclaimer language. In order to avoid duplication, we’ve suggested moving the language that was already in the document up to the top of the guidance section. * There were a number of clarifying edits that have been suggested. The staff support team has applied those that did not seem to change the intent of the language and where no objections were noted. In some cases where there were opposing views, we may have suggested an alternative approach. * A number of respondents pointed out that the registrant may not be the data subject in all circumstances – reminder that a footnote had already been added to the previous version to make this clear. * We also applied the updates that were agreed to during the last meeting (i.e. adding a reference to a possible timeframe for scenario 2 and removing the reference to third party verification). * There were a number of comments that did not come with any suggested changes or proposed language – for future input, please make sure that you are specific about the changes you are proposing. There were also some comments that did not seem to belong in the guidance write up or were not in line with what has been discussed to date – in our responses we have noted as such. * The idea would be to leave the write up as is for now to allow the group to focus on the consensus policy write up. The hope is that in the next review cycle, the team can consider clarifications, consistency, and “cannot live with” items, and that all other comments have been exhausted by now. * There also seemed to be a suggestion that the guidance write up was trying to restrict differentiation to SSAD but that is not our understanding – it is indeed a suggestion that some have made, but the guidance write up indicates various avenues through which this may happen, including SSAD. * Please go to the google doc<https://docs.google.com/document/d/103kazmQlFxRmecNosslsZhg6u0MwxoZ5DiZj86j0...> where you can first find a clean version with all changes applied and secondly a staff support team edited version with the redline changes and our response to the different comments that explain which changes have been applied and why some suggestions were not applied. * Remaining outstanding questions: * Should this be labelled guidance, best practices or something else? Note that the GNSO Operating Procedures refer to “Best Practices” as an illustrative type of outcome but do not specifically mention guidance. At the same time, maybe the EPDP Team should focus on what its expectations are once the GNSO Council / ICANN Board adopt this guidance or best practice? What is expected from ICANN org? Is anything expected from other parties such as the GNSO Council and/or RrSG in relation to promotion and communication of this guidance? * In terms of expectations – the expectation would be that ICANN org communicates this and makes sure this is publicized in a way that affected contracted parties know that this guidance/best practices exist, otherwise – what is the purpose? This should be communicated and enshrined it in a place that is easily accessible. “Best practices” is a term that carries more heft and weight, and the fact that it is consistent with the term the Council uses is another mark in its favor. * The term best practices carries more weight so that should be used, and is far more likely to have something to come out of this. * On both of these topics, CPs have been discussing this and have not come to agreement yet on the preference. The guidance we developed is possible guidance, but are they are the best? Who decides this? * If not us to determine best practices, then who? * This should be useful – should be something that CPs can use if they want to differentiate that gives them some instruction of how to achieve this. This should be a living document – it is not policy but could be provided in the broader term of guidance for contracted parties. * Best practices is the right term to use in terms of the by-laws – stay away from term guidance, which has a different meaning under the bylaws. * In response to who determines best practices – it is the EPDB under Article 36. * Perhaps should be thinking of this in terms of what we would like to achieve in terms of communication, dissemination, uptake, etc. rather than terminology. Guidance seems more like a policy threshold; best practices sounds more like an implementation. * DNS abuse institute mission is to develop best practices – the term is not as radioactive as the group seems to feel. * Are there any scenarios in which there is zero contact between the registrar and the registrant which would mean it would not be possible to differentiate if any of the scenarios are followed (as differentiation would happen either at the moment of registration or at the first contact opportunity between registrar and registrant)? * Proposed next steps – consider latest version of write up (apart from updates in response to previous two questions) as near final state and focus attention now on write up in response to question i. Once that review has been completed, EPDP Team to undertake final review and identification of “cannot live with” items. 4. Feasibility of unique contacts (30 minutes) 1. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. 2. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses. * Review and consideration of input provided on write up – outstanding questions: · A number of comments / questions were raised in relation to the legal committee team developed definitions which were reviewed and considered by the EPDP Team. Are updates necessary in the context of the Initial Report write up? · A placeholder was added to consider possible guidance in relation to EPDP Phase 1 recommendation concerning expectations for web-forms. RrSG has indicated that this is not within scope for the EPDP Team while others have suggested that the recommendation #13 cannot be implemented as intended (note, Staff Support team is not aware of this being brought as an issue to the GNSO Council by the IRT). EPDP Team to consider further what, if anything, should be added to the Initial Report on this topic. * Confirm next steps – EPDP Team to review updated version of write up and flag any comments or suggested edits in the form of comments to the document by Friday 14 May. 5. Homework assignments reminder (5 minutes) · By Friday 14 May, EPDP Team to review proposed LvN question i write up for the Initial Report (https://docs.google.com/document/d/1CBKYrgEOwxpLtZJbck4XMAnJcqEdOS6ObiSHio6y...) Please provide comments, suggestions and proposed edits in the form of comments. · By Friday 14 May, EPDP Team to review updated version of feasibility of unique contacts write up for the Initial Report (https://docs.google.com/document/d/1Dl-71SsX_OqDNpvN-rQ9K_wJnevEVW0V0oH32xYl...). Please provide comments, suggestions and proposed edits in the form of comments. 6. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #22 Thursday 13 May at 14.00 UTC 2. Confirm action items 1. Confirm questions for ICANN Org, if any