[Gnso-epdp-team] Notes and action items - EPDP Phase 2A Meeting #37 - 19 August 2021

[Caitlin Tubergen]

Dear EPDP Team,

Please find below the notes and action items from today’s meeting.

The EPDP Phase 2A Meeting will be Tuesday, 24 August at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin
--

Action Items

1. Data element small team representatives to respond to Doodle Poll ASAP, noting that the small team's update to the plenary is scheduled for Tuesday, 24 August.
2. Leadership and Support Staff to update the language of Recommendation 4 and New Recommendation by COB Friday, 20 August based on today's discussion.
3. As no disagreement was received during today's call, Support Staff to add RySG proposed language into Draft Recommendation 5<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#heading=h.17dp8vu> (email contacts) and EPDP Team members to provide proposed edits (if any) by COB, Monday, 23 August.
4. Amr to propose updates to Recommendation 1<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#heading=h.17dp8vu> by COB Monday, August 23.

EPDP Phase 2A - Meeting #37
Proposed Agenda
Thursday 19 August 2021 at 14.00 UTC

1.                     Roll Call & SOI Updates (5 minutes)

2.                     Welcome & Chair updates (Chair) (5 minutes)
a.       Small team to develop proposal for values of the data element (if agreed to)
 - Please see email sent yesterday.
Believe there is value for a small group to review the values for a standardized data element.
- CPH has signaled a willingness to support a standardized data element so long as it is optional, and the display of the data element would be within a closed system such as the SSAD. The question is – regarding the establishment of a new data element – is this worth doing, and for the members who preferred a mandatory use of a field, whether a standardized data element that is optional and used in an SSAD-like system would get consensus support.
- The list of assigned volunteers are members who previously opined on this issue and could return to the full group in very short order.
EPDP Team response:
- Regarding the usage of the data element – if this is restricted to SSAD or similar tools, what does this mean? If a registrar is using this data element, but receives a request outside SSAD, would it not be used?
- The registrar is question could still use it, but the question is how the flag is used and how data will be provided in response to a request. The thinking is that the standardized data element could be useful for everyone as we look to develop more automated tools, such as the SSAD. The flagging capability could be used down the road.
- The IPC would want the possibility for the data element to be mandatory, so the question about gating it is an odd question. At a minimum, the contracted party should have the capacity to publish it, even if it is voluntary.
- The Team seems to be in broad agreement that this should exist. The data element should exist – the wording used suggested that it would only be visible in SSAD. The main point – by having this piece of data, it is available in a restricted context – this would not preclude the registrar from displaying it publicly (if they so choose) or using it for their own purposes.
- Important to identity SSAD or comparable tools as a possible or likely use of the element. The SSAD is many years away – do not want to delay the use of the element until SSAD. Do not confuse the discussion with the uses, and the impact/use may change over time.
- What does the use of the standardized data element trigger in terms of output of registrant data. Team should be careful not to conflate this. When we discuss the use of a flag or the display, is it the flag we are discussing or the output that comes in response to the flag?
- Recommend a permissive policy recommendation – no need to restrict, since this is optional. A Rr may use the data element (or not); the policy should not restrict how the element is used.
- The interventions heard seem to argue for a broader scope than what was laid out in Keith’s email. CPs do not all agree that this data element should exist – there is not broad agreement. CPs are trying to come up with something that we can get our stakeholder group to get behind and support. Working toward the minimum that CPs could support.
- Our policy recommendation should not restrict anything.
3.                     Continue review and updates to section 3 of Final Report - Responses to Council Questions & Recommendations (75 minutes) – see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit>
As a reminder: proposed timeline to get to Final Report
19 August – consider suggestions for further consideration & agree on updates to report
24 & 26 August – consider suggestions for further consideration & agree on updates to report
27 August – publish draft Final Report for EPDP Team review, consensus call.
30 August – deadline for minority statements
31 August – finalize report and address any outstanding items, if any.
a.       Review of Recommendation #4
·      Consider input provided

        *   There are two updates made based on the prior discussion. Some noted that it should specify that legal person data is not protected. The suggested language over the list was added to the table in the document.
        *   Which of the three versions provided should be included in the report?
        *   The second part of the conversation – a new recommendation based on the outcome of the mediated conversations deals with a code of conduct as a way to get further certainty around GDPR standard. Tried to reflect IPC’s comment regarding additional participants in this recommendation.
·      EPDP Team discussion

        *   From a CPH perspective – do not agree to include other parties in the development of a Code of Conduct. From a CPH perspective, this would be akin to including other parties in a contract discussion.
        *   Code of conduct has a specific terminology, which makes it akin to a contractual negotiation. Could agree to a code of conduct, but only b/w the RrSG and the code of conduct as per the RAA.
        *   If only CPs can participate in discussions, which would ultimately find its way into a contract, is tantamount to saying – there can never be consensus policy.
        *   Did not envision a Code of Conduct getting down to escrow agents and EBERO providers. Contracts state that CPs have to participate in consensus policy process and abide by those consensus policies.
        *   No matter what this group recommends, the EPDB will want to know that processors are consulted. With that in mind, would like to include that language here.
        *   There is a specific reference to codes of conducts in the RA and there is some confusion whether the group is talking about a code of conduct in the RA vs. the Code of Conduct under the GDPR and previous directive. There is confusion and conflation of these terms, and it is important to be clear about this.
        *   The code of conduct discussion should not be another phase of EPDP. This group has discussed a code of conduct numerous times over the last few years. The EPDP Team is charged with coming up with policy recommendations, and from there – the EPDP’s mandate is completed. The Code of Conduct negotiations should occur elsewhere. The discussion should take place with groups who are affected by it. Since we are still waiting for the DPAs from Phase 1, it is difficult to say who needs to be at the table. Controllers definitely need to be at the table; processors may also need to be at the table. If entities would be sanctioned by the code of conduct, they definitely need to be at the table. Article 14, Section 4 requires the Code of Conduct must have a mechanism to control whether the Code of Conduct is being abided by.
        *   Have discussed Codes of Conduct for third parties in Phase 2, and CPs were part of that discussion – do not see how this is different from asking to be included in the CPs’ code of conduct.
        *   This recommendation was not proposed just for the legal v. natural distinction. Once the PDP ends and the DPAs are complete regarding who controllers and processors are, a code of conduct could be developed and submitted to the EDPB under Art. 40 of the GDPR as confirmation that what is being done is in fact in line with the GDPR so there would be legal assurances that this is compliant. It would be helpful to capture in writing how we the data is being processed.
        *   One of the key players here is the registrant – how do we propose to involve representatives of the registrant
        *   Staff Support will work with leadership will rework the language based on this discussion.
·      Confirm next steps
b.      Review of recommendation #5
·      Consider input provided

        *   There is proposed language from the RySG – ALAC provided one comment in response to this and asked for the B&B summary table to add.
·      EPDP Team discussion

        *   The chart does not help – it is already covered in a descriptive way in bullet 3
        *   Intentionally omitted the discussion about automated disclosure assumes a number of things such as built in verification and validation – and seems more relevant to SSAD disclosure rather than RDDS disclosure
        *   Seems everyone agrees to include the registry language in the table for the second reading
·      Confirm next steps
c.       Review of recommendation #1 (second reading)
·      Consider additional input provided

        *   During the last discussion, there was concern over the last sentence. The proposal is to remove the sentence and retain the first sentence, not as a recommendation but as an answer to the Council’s question.
        *   Should say recommendation part 1. The GNSO statement of the team’s task should have been worded that way.
        *   Need to address 17.3 – advocating for the language suggested in the BC comment – group could not resolve the legal v. natural distinction.
        *   Do not think this should be limited to 17.1. Agree with leadership’s proposal.
        *   Support leadership language. Struck by opacity – if we cannot agree on language that everyone likes, we reduce it to a simple statement – where do we address the discussion in the report?
        *   Could include a reference – for those who are interested in more context, please review the Initial Report as well as minority statements where groups elaborated on their views on this topic.
        *   The reason why leaving language as it is currently is problematic is because it implies that there was consensus on 17.1, and that is not correct.
        *   The proposed revision seems to indicate that additional work is needed – how do we go about getting a resolution to this? If 17.1 is not agreed to, should we say we failed to reach consensus for changes, therefore – 17.1 should be repealed? How can this be resolved?
        *   Not advocating for more EPDP, but would end up with the same scenario (optional differentiation) – could clarify that no additional work is suggested at this point.
        *   Ultimately, agree that the substance of the change is indeed in 17.1 – if we want to refer specifically to what we have been doing, we could lay this out clearly. 17.1 is the substance that the EPDP Team failed to reach consensus on; 17.2 is part of the input that was considered; 17.3 is the process used, though this was deferred to Phase 2A (instead of Phase 2).
        *   All that is being discussed is to ensure the language reflects the process that has gone on and the level of dissatisfaction with how the process has worked. Would like to make sure that someone who cares enough to read this afterward does not come away with an incorrect understanding.
        *   Action: Amr to include draft text in the table.
·      Consider leadership path forward
·      Confirm next steps

d.      Review of recommendation #2 (second reading)
·      Consider additional input provided

        *   There is a slight tweak to the second paragraph in an effort to recognize the members would like to use existing processes and also scoping possible work due to legislative developments.
·      Consider leadership path forward

        *   NIS2 is still a draft directive, and this is outside the scope of this EPDP. This is bad form to suggest this to the GNSO Council. The GNSO does not need to do this – councilors representing certain groups can go ahead and request a preliminary issues report so a PDP could progress without this recommendation. Do not see why this is necessary and it is not a good precedent.
        *   From a Staff perspective, welcome the scoping teams to determine if policy work is needed rather than going to the preliminary issues report.
        *   This recommendation was part of the mediated conversations.
·      Confirm next steps
e.       Confirm next steps

4.                     Wrap and confirm next EPDP Team meeting (5 minutes):
a.     EPDP Team Meeting #38 Tuesday 24 August at 14.00 UTC
b.     Confirm action items
- Small Team volunteers please respond to the Doodle Poll ASAP.
c.     Confirm questions for ICANN Org, if any


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-team/attachments/20210819/fc994517/attachment-0001.html>