Dear EPDP Team, Please find below the notes and action items from today’s meeting. Following today’s discussion, the Support Staff Team incorporated the agreements we captured into an updated version of the Final Report for your review (https://drive.google.com/drive/folders/1TW3Z-s6DzS2QsV_VwJ6iUQTvKVIXQrmG). EPDP Team members are now requested to review the pdf version of the complete Final Report<https://drive.google.com/drive/folders/1TW3Z-s6DzS2QsV_VwJ6iUQTvKVIXQrmG> and indicate what changes/updates are essential, within this Google Doc<https://docs.google.com/document/d/1Il7T4x1nOXA5i8ru58zCwB3KlTg9aZ5h/edit>, before the Final Report can be published. Please provide your input as soon as possible, but no later than Wednesday, 1 September 14.00 UTC. Please note there is currently a placeholder meeting scheduled for Thursday, 2 September at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV...> 1. Keith to circulate Chair's statement to the EPDP Team for their review prior to closing out Ask #1 (stating groups' discomfort with Recommendation #1). 2. EPDP Team to review Keith's statement by 14:00 on Wednesday, 1 September and flag if further discussion is needed on Ask #1. 3. EPDP Support Staff to incorporate changes agreed to during today's meeting into Section 3 of the Final Report and circulate to the EPDP Team. (see attached) 4. EPDP Team members are now expected to review the pdf version of the complete Final Report and indicate, within this Google Doc<https://docs.google.com/document/d/1Il7T4x1nOXA5i8ru58zCwB3KlTg9aZ5h/edit>, what changes/updates are essential before the Final Report can be published. Please provide your input as soon as possible, but no later than Wednesday 1 September 14.00 UTC. EPDP Phase 2A - Meeting #40 Proposed Agenda Tuesday 31 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Consider and resolve remaining four “cannot live with” items for section 3 of Final Report - Responses to Council Questions & Recommendations (75 minutes) – see https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit As a reminder: timeline to get to Final Report 30 August – deadline for minority statements 31 August – finalize report and address any outstanding items, if any. Chair to circulate proposed consensus designations and Chair statement. 2 September – placeholder meeting, submission of Final Report to GNSO Council 10 September – final deadline for minority statements (any minority statements submitted after 30 August will be added to the Final Report, with the updated version to be submitted to the Council in time for the September meeting document deadline) * Review ask #1: Ask #1: EPDP Team to consider if this section (lines 100-104), as well as footnote 5, 20 and 21, can be removed if the Chair statement on consensus designations makes clear that there was significant disagreement within the group on a number of these issues and that readers are encouraged to review the minority statements to better understand the different views and perspectives. Leadership Assessment: There appears to be general support for removing the current statement and related footnotes expressing opinions but only if the Chair statement accurately reflects the EPDP Team’s conversations and differences of opinions to make clear that readers understand that where the recommendations have ended up, is not necessarily what some would have liked to see. Keith to circulate consensus designations and proposed Chair’s statement following the call to allow the EPDP Team to confirm that this has been done in an acceptable manner. * Consider EPDP Team input provided * It is hard to make a final call on this issue in the absence of seeing and reviewing the Chair’s statement. It’s unlikely that readers will read minority statements, so the four corners of the report should clearly indicate the disagreements. * Cautious against making the arguments made in the minority statements. It is theoretically possible to write a dry and analytical note regarding the significant dissension among the groups, some advocating for x and some advocating for y. This is a pivotal statement and the one that everyone reads, so it is important. * Confirm next steps * Keith to circulate statement after this call for group to review. * Review ask #2: Do the updates and the reorganization of recommendation #1 address the cannot live with items flagged? If not, how can these be addressed, factoring in the discussions to date. Leadership Assessment: There is still a level of discomfort with the recommendation, although based on the discussions to date the group does seem to agree on the underlying principle (a field(s) must be created (technically), but this field(s) is optional for use by CPs. If this is indeed the common understanding, and factoring in the other suggestions, would the following updates be helpful: The EPDP Team recommends that a field or fields MUST be created[1] to allow for facilitate differentiation between legal and natural person registration data and/or if that registration data contains personal or non-personal data. The EPDP expects that the technical community, for example the RDAP WG, will develop any necessary standards associated with such fields. This field or fields MAY[2] be used by those Contracted Parties that differentiate between legal and natural person registration data and/or if that registration data contains personal or non-personal information. For clarity, Contracted Parties MAY make use of the field(s), which means that if a Contracted Party decides not to make use of the field(s), it may be left blank or may not be present. Additionally, Contracted Parties MAY include the field(s) is not required to be included in a RDDS response. * Consider EPDP Team input provided * Question regarding the word created – can you provide examples of how the field or fields could be used and where the fields would be used? * In terms of allow for vs. facilitate, believe that language should be facilitate optional differentiation b/w legal and natural. With respect to the second footnote, this is causing discomfort with the RySG. Did not discuss this specific language or how this would be implemented. RySG sees value in having a standardized field for CPs who choose to differentiate. In the small group, the group was not supportive of including this field in the public RDDS response. In the small group, however, there was an ask that even though some does not support it, could the recommendation at least not prevent it. With that background, in reading the footnote, this goes further than Rys are willing to compromise on. * This language was Support Staff’s attempt to try to find middle ground. The precision that is required b/w the must for data elements to be created and the mays regarding how CPs may use it is not a coercive attempt to make this a bigger requirement. With respect to Footnote 1, none of the policy staff are experts in IETF land; however, if this were an adopted recommendation, the technical services team or another group within ICANN org would be tasked with submitting an internet draft to the IETF – how that happens in detail, we do not know. If a CP were to choose to use these fields, it is a pretty safe bet that they would need to do so through their EPP systems and processed the data via RDAP or an SSAD, all of those technical requirements need to be laid out outside of ICANN before CPs can use these fields. In reference to footnote 2, what is important is the last sentence – CPs may include this in the RDDS response. The Small Team’s original instruction – at that time, it seemed clear that there was no broad support for the fields to be published in the public RDDS, but there may be support for it to be disclosed through a restrictive system. In the discussions, however, there was the aspect of certain parties not wanting to restrict if they chose to publish or make available these fields in the RDDS. In Phase 1 implementation, it outlines what the future requirement is going to be for an RDDS query format. It is not complete, but the reason Support Staff tried to include Footnote 2 is that if a registrar did choose to publish both of the fields in the public query, the intent of CL&D and advisory is that these fields would be appended to or appear at the end of the query format. * These fields should be co-equal and distinct from each other. There is a policy at the level that we are talking about and then there will be a policy of each of the parties, principally the registrars. The consensus is permissive with respect to whether the fields are collected, how the field is used, and whether the field is published or not published. Individual registrars will have their own policies which may differ from each other. * The footnote regarding EPP and RDAP comes closer to a previous concern. The previous language about created without reference to where and how they are created was unhelpful. Would like to see a reference to specifications to the RAA and specifications. In Phase 1, there was detail with respect to how fields can be used. Because we are omitting that, the concept of where they are used needs to be more specific. * From a CPH perspective, do not want this language in the footnote. It is not necessary in order to display these optional fields. Clarify that we did not add an additional field – we allowed for additional fields – this is to account for the fact that Registries can include additional elements. In terms of implementation, the EPDP team expects the technical community to develop standards for such a field. * GAC views this as necessary infrastructure to provide information to differentiate between legal and natural. This is no misunderstanding that this is mandatory to publish or use; however, if these fields are created, if it’s infrastructure and needs to work within the entire system. If there is no specificity, it will be of no utility. The fields need to have the capacity to work in the system, including disclosure and publication. The present configuration prior to the updated footnote lacked that specificity that this would work within the system of disclosure and publication. * Would think that footnote 2 is unnecessary, but after listening to what other team members have said, believe that it is necessary. * Would the group agree to change the footnote from will be appended to may be appended? * Once this goes to the IETF, do not want to ensure that human rights groups are represented – these will be forgotten. The policy recommends that this be optional; footnotes should not coerce this. * Should not make reference to any existing contracts here – it a dangerous step to imply that the community has the right to amend the contracts. * The PDP modifies contracted parties’ obligations, but it does not amend the contracts b/c the contract says that CPs are obligated to comply with consensus policies. It is not a process of amending the contract itself, but it has the effect of modifying a CP’s obligations under the agreement. References to amending the contract should be removed. * The additional field of identifying personal v. non-personal preserves the distinction focused on by some. * The PDP manual allows for agreement on terms and conditions – WHOIS language amendments from PDP has gone directly into the contracts. * Proposed language: ICANN MUST coordinate the technical community, for example the RDAP WG, to develop any necessary standards associated with such fields. * Is this proposed language OK for ICANN org? * Do not need to amend the contract at all. There can be supplements. If there are recommendations in the policy that ultimately lead to a requirement to have the fields or make them optional, that is sufficient. * Generally the IRT does not amend the contract, but sometimes the language will supersede the contract. * The contract can be modified via an RSEP, but do not want registries to have to file an RSEP to use these fields. If these fields are not to be included, why are other fields included there? * The redlines are acceptable. The language here accomplishes what others would like to accomplish. * Confirm next steps * Review ask #3: Considering the org input (“because this recommendation is for guidance only (and thus not subject to compliance enforcement), the use of should vs may wouldn’t be expected to have a significant impact from the org perspective"), can the group live with leaving this as “SHOULD” (lines 261-265). If not, please provide alternative suggestions that take into account the EPDP Team’s discussion. Leadership assessment: All groups, apart from the RySG, seems to be able to live with the word “SHOULD”. Is the RySG willing to accept that outcome, or would it like to stick with its “cannot live with” position which will be factored into the consensus designation process. * Consider EPDP Team input provided * Will voice concern over should v. may in the minority statement and that will be enough to get non-objection from the RySG * Confirm next steps * Review ask #4: please consider the updates proposed by the RrSG (lines 322-329 - “any future work within ICANN by the ….”) & RySG team (“any future work by ICANN by the relevant controllers and processors in relation…”. Also, please provide further input on what these changes would mean or imply as work on a Code of Conduct was not part of phase 1 or phase 2 recommendations. Also consider additional language suggested by IPC (late submission): “For the avoidance of doubt, RDS data requestors are relevant controllers and processors and must be included in any such future work.” Leadership assessment: based on the input provided, and additional review of the GDPR requirements in relation to the development of a Code of Conduct, would the following updates address the different positions: The EPDP Team recommends, in line with GDPR Article 40 requirements for Codes of Conduct,[3] 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. Consistent with GDPR recital 99, “When drawing up a code of conduct, or when amending or extending such a code, associations and other bodies representing categories of controllers or processors should consult relevant stakeholders, including data subjects where feasible, and have regard to submissions received and views expressed in response to such consultations”. This future work is expected to be carried out in an open and transparent manner, allowing for observers to follow the discussions and with the opportunity for the community to provide input before the Code of Conduct is finalized. * Consider EPDP Team input provided * Concerned with use of Code of Conduct as this is a term in the RAA * Proposed edit: for the avoidance of doubt, this Code of Conduct is separate and distinct from the code of conduct referenced in the RAA and/or registry agreements. * Not all readers will see the footnote – important to incorporate the text into the recommendation. * Is it possible to ask ICANN to commence a code of conduct in line with Article 40 of GDPR * Confirm the GAC proposed addition of pseudonymized is a minor edit * Team intentionally used the term masked instead of pseudonymized – the proposed clarification is useful but should be consistent. The Team used masked intentionally because it is less of a loaded term legally speaking. * Not willing accept the term masked unless defined. * Perhaps “intended to be pseudonymous” * Pseudonyms are intended to be reversible * Do not agree to this change * Confirm next steps * Agree on next steps 4. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #41 Thursday 2 September at 14.00 UTC (placeholder, if necessary) b. Confirm action items c. Confirm questions for ICANN Org, if any ________________________________ [1] “Created” in this context means that ICANN org, with the assistance of the the technical community will develop a standard that defines how and where this field or fields can be used within EPP and the RDAP protocol. [2] If a Contracted Party chooses to differentiate between legal and natural registration data or personal and non-personal data AND chooses to publish this field or fields in RDDS, those field(s) will be appended to the requirements of an RDDS response format as currently defined in the RDDS Specifications for Ry & Rr (see https://www.icann.org/resources/pages/registry-agreement-raa-rdds-2015-04-27...) and WHOIS Advisory (https://www.icann.org/resources/pages/registry-agreement-raa-rdds-2015-04-27...). the existing Registry Registration Data Directory Services Consistent Labelling and Display Policy<https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en> is expected to apply. [3] Not to be confused with the Code of Conduct that is referenced in the RAA and/or Registry Agreements.