Dear EPDP Team, Please find below the notes and action items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV...> from today’s EPDP Phase 2A meeting. The next EPDP Phase 2A meeting will be Thursday, 20 May at 14:00 UTC. 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 #23 Proposed Agenda Tuesday 18 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) * Leadership and Support Staff have been working on a timeline to get the group to the end of May. We will share this at the end of the call. 3. Legal vs. natural (45 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. Consensus policy question write up * Questions to be considered by the EPDP Team: 1. Some have suggested that recommendation #1 (“GNSO Council to monitor developments…”) does not seem to rise to the level of a recommendation as it is already something that the Council is expected to do. If the intent is to signal that there should be a formal process to trigger reopening deliberation on this topic, the recommendation should state so explicitly. o Should the EPDP Team consider adding a more explicit trigger that would require the Council to reopen consideration of this topic? If yes, what should this trigger be and who/how would it be determined that this trigger is met? * There is an interplay between legal v. natural and the question hanging in the background as to whether SSAD will come along in a timely and effective fashion. If everyone would agree, would like to see wording in here related to the idea of trigger. Having a high level and attention and concern about forward progress here; if there is no progress, it changes how one views the output of this working group. * If in six months, there is not clear forward progress and confidence-building events, that would be bad news. 1-2 years would be too far off. In terms of timing, would want to see something to confirm confidence and forward progress by six months as the outer limit. * Adoption of the NIS2 should be a triggering event. * If we do a timeframe, it should be every six months – not just in six months. Would not agree to a single time. Another trigger to look at is if NIS2 passes – it’s not clear that we need a PDP to address NIS2 because there is nothing in the current policy that will prevent CPs from complying with NIS2, but it would result in a very uneven playing field. * It should be a combination of both – event triggered and an associated timeframe, whichever happens first. For example, the timeframe is set to a year, but if a specifically identified event happens before that, the topic could be reopened. * GNSO should already be looking out for these things – the question the group needs to think about is how we are going to cleanly scope a PDP. We can recommend to the Council to continually monitor but keeping an EPDP open is something the group should be very wary of. * Remind the group that if a separate policy is needed – have to start from scratch. Because of this, it makes sense to specifically call out the NIS2 as a triggering event. * A reference to NIS2 is appropriate and is an important consideration but limiting the trigger to NIS2 is probably too stringent. The question is how do we reengage? That question is ultimately up to the GNSO Council. If the EPDP is paused until a triggering event, it will still be a GNSO question. There is a good argument for bringing this group to a close and giving the community a fresh start on this. * Team should focus on decisions proposed in NIS2 that if they come to pass would trigger a renewed look at the questions. NIS2, as it currently stands, is too vague to be a trigger. * Why do we need this instead of WHOIS review team procedure continuing along? Could this not be picked up in a WHOIS review 3? If there is a specific reference to NIS2, then you have to put a reference to data protection law changes. * The Board has chosen to ignore the 6-month review for RDS 2. * Homework assignment to come up with a language for specific triggers. 2. Some have indicated disagreement with the inclusion of recommendation #2 (“ICANN org must implement the capability for Contracted Parties to use a standardized data element in the registration data……”) as it is not ‘in any way necessary for the delivery of the service” nor does it “seem to serve any useful purpose to the data subject and may be doing harm by exposing additional information about the data subject”. However, as other comments noted, the EPDP Team has not considered yet if/how this additional data element would be treated (redacted / non-redacted) nor is it clear who/how such a data element could be standardized. o If the EPDP Team would agree that a standardized data element must be added, how would this work in practice? Is this an ICANN org responsibility, would it require changes to existing policy recommendations (e.g. CL&D), would this require work by other bodies, e.g. IETF? * ICANN must implement the capability for CPs – it’s not an implementation, exactly. It’s an addition to the data dictionary. Whether or not there is an implementation issue is whether or not a registrar chooses to designate – there is split here between defining the concept and implementing it. Would suggest changing the wording to “define the capability” but not necessarily impose the implementation. Whether or not this needs to be passed through the IETF – probably, but ICANN should take the lead on this. * If a registrar wants to make a distinction and has a flag, there is not a requirement for a registry to do anything about it. This doesn’t make sense in an optional sense. Having a standardized field is important, but it should be mandatory. * We have a situation today where contents of RDS fields for thick registries may vary considerably between what the registry shows vs. what the registrar shows. Do not know why we are agonizing over this. The data dictionary is currently sitting in contracts. Do not understand why we don’t go back and revise the Phase 1 recommendations re: the fields. * Confused around the language “ICANN org must implement” * Re: the data dictionary – the data dictionary for WHOIS is in the contracts. For RDAP, the replacement, that is defined in a profile. That profile was developed jointly by ICANN and Contracted Parties and clearly defines all of the fields. There are too many questions about how this would be implemented. RySG is not supportive of adding this field to the RDDS output. This could add confusion and open up data subjects to having additional data disclosed about them which doesn’t make sense. * One distinction is the difference between a standardized data element that is data collected and a standardized data element that CPs would have or use. The next step would be to have this as a data element itself rather than a data element used internally by a registrar. * Whether a field in the RDDS is displayed publicly would need to be specified here, but this is a binary decision that we have to make. There is value in having this field available to the SSAD. That allows the SSAD to make a determination that something should be disclosed rather than have a registrar manually determine. * The Team hasn’t said how this field will be generated. CPs might be more comfortable with the concept if we call this field an output of whether a registrant has self-designated (could be yes/no). That type of data would be useful for analysis, research, transparency. Do not understand the point of what harm would be done with this field. * If we want a field only displayable to the SSAD, that’s better than not having it at all. * Suggest the whole group, as part of homework, go back and look in detail at the Phase 1 report. Purpose 3 – contact with RNH – go to appendix D and review the data element workbook which defined what the Phase 1 team referred to as the minimum public data set. What data elements would be displayed in this minimum public data set? Recommendation 10 is outlining the “minimum public data set” and goes on further to define an additional processing activity that is considered personal data that would ultimately be redacted. Also, go back to Phase 2 – the group needs to make a distinction here if the field is required minimum data set but still optional – is it public or only processed via the SSAD as defined in Phase 2? That is kind of clarity that we are looking for. That is the policy change that may be required that would amend the recommendation from Phase 1. o If the EPDP Team would agree that a standardized data element must be added, what would the data element table look like for this data element (required to be transferred from Rr to Ry, redacted / non-redacted) – see phase 1 recommendations #7, 8, 9 and 10? 3. Some have expressed concern about the use of “unknown” (“that indicates whether the registration contains 1) a legal person, 2) a natural person, 3) unknown…”). Some have suggested it should be replaced by “empty” or “not-specified”, others have suggested there should only be two options, namely legal or natural person. The Staff support team had understood from previous discussions that the use of “unknown” is fairly standard and in this particular case would be helpful, for example, in the case of existing registrations for which no determination may have been made yet. o What would be the appropriate term to use for those registrations for which differentiation has not been done or for which the status is not known (e.g. in cases where differentiation is requested but has not been completed yet)? Or should the field remain blank if unfilled rather than specified as “unknown”? * Unknown is not the proper thing to display. We can simply leave this blank. * The Phase 1 report does not specifically state the aspect where a value of a data element should be left blank. The intent of the data element workbooks was that we are not going to change existing requirements. This is a complex thing we are tackling – the existing requirements are based on the Whois protocol, and we’re in the midst of dealing with RDAP protocol. RDAP does not pass blank values. Review the RDDS specs of the RAA and RA and you will get into the fine details of a footnote that will allow for the understanding that if a data element contains no value, it must still be displayed. However, a Whois advisory notes that CPs cannot pass an empty value at all. Phase 1 group did not specifically state that blank values must be displayed. The intent was not to change the existing requirement, and we have to work through the technical challenges of changing protocols. * Main concern is that if we keep “unknown” this would give the possibility for registrants to identify as unknown. New registrants should identify as natural/legal. For existing registrants could have “not yet identified” 4. Some have suggested that the use of “standardized data element” is vague and have suggested using “standardized mechanism” instead. However, from the discussions to date it seems that a standardized data element has been clearly understood as meaning adding a data element to RDDS (or the Registrar’s internal system) that would allow a registrar to indicate whether the registration concerns a legal / natural person and/or personal / non personal data. o Should the EPDP Team refer to “mechanism” instead? If so, how can mechanism be further described to make clear what is intended to mean and who would be responsible for developing / implementing it. * Do not need to focus on the term mechanism – what we are looking for is a standardized data element – a field in the RDDS. * Would like to hear from whoever recommended the term mechanism. * 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 21 May. 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. * Questions to be considered by the EPDP Team Note, in a number of instances suggestions were made by some members of the team, which others objected to. Those items have been flagged as changes not applied in the redline version – EPDP Team members are encouraged to reach out to each other to see if a compromise can be reached and communicate these back to the full team for consideration. 1. At the moment, the write up refers Contracted Parties who would like to provide a registrant-based or registration-based email address to the Bird & Bird memo. Some have suggested that more specific guidance should be included or called out. o Should more specific guidance be included, or is it sufficient to refer to the B & B memo (which will be included in full in the annex to the Initial Report)? If more specific guidance is to be included, what should this include? * EPDP Team to refer to specific guidance to be included. 1. No specific proposals have been put forward in relation to the topic of web-forms. Various approaches have been suggested during previous calls such as providing guidance to phase 1 IRT, referring this issue back to the GNSO Council for further consideration, not making any reference here but direct those that have expressed concern about web-forms to the phase 1 IRT and/or ICANN compliance from which the issue can be escalated, if necessary. o Which approach should the EPDP Team follow for the purpose of the Initial Report? o Are there any volunteers that would be willing to write up a proposal on the agreed approach on this topic for the EPDP Team to consider? * 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 21 May. * Based on projected timeline, not sure three meetings will be enough. Will minority statements be allowed? * Minority statements are typically reserved for final reports – the initial report will document where differences exist. * BC intends to submit a minority statement 5. Homework assignments reminder · By Friday 21 May, EPDP Team to review the updated LvN consensus question i write up for the Initial Report (https://docs.google.com/document/d/1_k0hVA6c2SvQPLiaZAlUllTKdplssofYlRHDkeR4...) Please provide comments, suggestions and proposed edits in the form of comments. · By Friday 21 May, EPDP Team to review updated version of feasibility of unique contacts write up for the Initial Report (https://docs.google.com/document/d/1wpZWZzCNcDsAYuy3FqxV67POgDV2hrOvrwGa3kjd...). Please provide comments, suggestions and proposed edits in the form of comments. · EPDP Team to review Rec. 1 and come forward with specific timelines or triggering mechanisms by Friday, 21 May. https://docs.google.com/document/d/1_k0hVA6c2SvQPLiaZAlUllTKdplssofYlRHDkeR4... · EPDP Team to review the Feasibility Write-up and come forward with draft text from the legal memo to include in the write-up by Friday, 21 May. If no proposals are introduced, Support Staff will leave text as is, i.e. include link to the memo. ( https://docs.google.com/document/d/1wpZWZzCNcDsAYuy3FqxV67POgDV2hrOvrwGa3kjd... ) 6. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #24 Thursday 20 May at 14.00 UTC 2. Confirm action items 3. Confirm questions for ICANN Org, if any