Dear EPDP Team,

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

The next meeting will be Thursday, 19 August at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin

1. Further to today's conversation, if groups have follow-up questions based on the benefits or operational changes discussed, please populate them into the new column in the Google Doc.

2. EPDP Team to review Recommendation 3-5 in Section 3 of the Draft Final Report and provide proposed language in response to today's discussion by COB today, Tuesday, 17 August. Specifically,

With respect to Recommendation 3 (new data element), please review the RySG proposed language and the IPC proposed language and provide suggested edits with a view toward a compromise approach.
With respect to Recommendation 4 (code of conduct), please review IPC's concern and consider Art. 40 of the GDPR - how much flexibility has been applied by the EDPB to those that have developed codes of conduct to date? For example, are those that not controllers allowed to be part of the conversation?
With respect to Recommendation 5 (registrant and registration-based contacts), please review the RySG text. Are any edits required, or does the EPDP Team agree to the proposed update?

EPDP Phase 2A - Meeting #36

Proposed Agenda

Tuesday 17 August 2021 at 14.00 UTC

1. Roll Call & SOI Updates (5 minutes)

2. Welcome & Chair updates (Chair) (5 minutes)

3. Consider benefits and operational challenges identified – see https://docs.google.com/document/d/1L-SdgAb0tJlGJoBbuRWHuKSuZRIdXnia/edit (15 minutes)

a. Consider following questions:

· Are there any clarifying questions that anyone has about the input provided by others?

· If this input has not helped create a better understanding of each other’s position, what else can be done / should be considered?

· If/how should this input be captured in the Final Report or should groups be encouraged to highlight their views in their minority statements?

EPDP Feedback:

This group lives within a larger environment, which is the broader internet. The idea of deciding on a data element that specifies legal/natural is out of the scope for this process. This data element exists – whether or not it is used is within the scope; however, deciding if this data element should exist in the world is outside the scope of the GNSO. The Team should assume it exists for the purposes of this conversation.
In terms of its existence, is this a reference to the kind element in RDAP, or something else?
Yes, thinking of the kind element. What we do not have and would benefit from is an organized visible data dictionary preferably maintained at the IANA registry system. Should assume the data element exists – the question should be should it be used and how.
Disagree with this characterization – ICANN org has made this clear that if this is to become a requirement, the EPDP Team must be really clear that it has to exist. If this element could be potentially referenced, the Team has to make clear what the name is and what the structure is.
If any TLD operator or address registry operator would like to make use of the data element, they can and should. In terms of ICANN org response, they will not require that data element to be substantiated in contract unless this group makes a policy recommendation. This is an IETF level question, not under the control of this group.
If the Team does not specify this data element in the data specification those who choose to use it will not use it consistently.
The IETF already did this in the RDAP work that created the “kind” element. Can the group come up with the policy that will be used with respect to the “kind” element?
What the group is asking is do we need to have a common data element or not – this is the question being asked.
The discussions this team is having are taking place in a broader context, and even if we recommend the creation of something new, this would have implications elsewhere and could trigger work in other parts of the community, including the IETF. What the team needs to focus on: is there a recommendation for new consensus policy to the GNSO Council for registrars who choose to differentiate, and if so, how?
In terms of the benefits – the benefit of the flag – GAC colleagues noted the discussion of the overall benefit of differentiation. The Team may be too late to discuss this properly. Do not think the Team has properly discussed some of the aspects here.
Struggled with not all of the responses seem to be answering the same question – for example, some of the benefits seem to be defining benefits for why differentiation should exist for all registrations, while some of the responses seem to be answering the question for a standardized data element for registrars who choose to differentiate. Some argue this should be a public data element in the RDDS. It was not always clear what the responses were referring to. It’s important to be clear what we are talking about.
The Team is discussing the benefits of a common data element that would be able to flag whether this is a legal or a natural person. The question the team should focus on is should this data element exist for registrars who choose to differentiate.
There are a number of benefits listed here – perhaps start with the benefit of the public (RDDS query) to have a consistent indication of whether the data contains legal person or natural person data. To have this be available consistently would be helpful for a number of reasons including whether to submit a one-off request for the data and to understand the likelihood that the data will be provided. Having that element publicly available would convey helpful information to users of RDDS.
The Team has been discussing benefits and many groups believe they have put forward benefits and have been repeatedly told the input was unhelpful or anecdotal.
Real example – if there is a field defined, as a consumer, if one were to go – this is not filled in, then one could choose not to do business. Suppliers in Europe are required to post information on websites. The knowledge that someone has chosen not to fill in this field and not to convey it speaks volumes. The Team has talked a lot about anecdotal evidence, but the rationales on both parties’ sides are not supportable by hard evidence. We have asked CPs to show evidence of harm and fines – if you provide education and allow correction, there are essentially no risks.
The purpose of this exercise, coming out of the facilitated discussions, was to share additional information to create a better understanding of why having a common data element would be beneficial. If nothing has triggered new discussions or ideas, perhaps the team needs to move on.
Another benefit is that once a record has been returned as no personal data in this SSAD, this could be helpful in implementing the SSAD
In terms of the ALAC input, finding it difficult to understand – specifically, there are points on consistent labelling and display (input 2 and 3) – in the absence of a data element, how is the data still not consistently labelled and displayed? CL&D is a requirement one way or another – not sure how this adds. If a flag were to be added, it would have to be consistently labelled and displayed. Encouraged to hear a flag that specifically addresses personal and non-personal data – could be included in the guidance but not required. A flag of that nature rather than a flag on registrant type would have much more utility – specifically in references to Phase 2 Rec. 9.4.4. Not sure understand input #5 – GDPR does not require differentiation b/w legal and natural persons.
Need further clarification on the kind element feedback. In terms of v-card and j-card that is being used in the RDAP – if it is going to be replaced, this seems like the opportunity to do this. Concerned about how we use the IETF in relation to policy development. Homework to capture those technical questions.
In terms of a flag, this was in reference to a common data element, and would need to specify the values that this element would take. There are future laws and regulations underway that could make this mandatory.
The Team needs to focus on text for inclusion in the Final Report. It is necessary at this point to put forward specific text.

b. Confirm next steps

4. Continue review and updates to section 3 of Final Report - Responses to Council Questions & Recommendations (60 minutes) – see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#

As a reminder: proposed timeline to get to Final Report

17 & 19 August – delivery of action items mediated conversations, 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. Continue review of Recommendation #3 (if proposed language has been put forward by RySG)

· Consider input provided

- First issue – should this be used for SSAD, separate issue – MUST or SHOULD

· EPDP Team discussion

Groups have been told what is in and out of scope – bring the SSAD into the discussion now is a red herring. This hasn’t yet been approved by the Board and may never be. The Team should not spend time discussing this any further. It does not serve the Team to discuss multiple questions simultaneously – they should be addressed orthogonally in a single context.
If you are rejecting the SSAD discussion, where would or should this discussion take place?
It should not be a huge surprise what the CPH is suggesting as it is consistent with statements made previously. The language used here is based on the proposed Rec #4.3. Registries have said previously that they are opposed to having a standardized data element in the public RDDS, but do see utility and usefulness in having that data element be available in SSAD integration. CPs will have an obligation to integrate with the SSAD system. Registries have also said that legal v. natural designation alone is insufficient, so that is why the personal or non-personal data is included in the draft language.
If we took out implementation and put “as part of the SSAD” if this would still be objectionable to ALAC colleagues in terms of scope. Could make a recommendation for a standardized data element. Observe that having a standardized data element that identifies the type of person and the type of data would be a useful infrastructure to have in place and would be a positive step.
Flagging that it would be useful to the SSAD is fine, but mandating that it is part of SSAD implementation is not fine. If we do not specify that this will be done, it may never – as SSAD is no guarantee.
In support of SSAD instead of as part of SSAD implementation
BC colleagues support the IPC recommendation and believe in the conditional must.
In terms of may or must, there is not support for MUST. The last sentence in the IPC proposal is a deal breaker – first, the obligation that registries must store the contents of this field is problematic for registries and second, do not support including this in the public RDDS response.
CPH seems happy with the data element as part of the SSAD, but where it goes to public RDDS system – even with checks and balances – where does that risk push the opponents over? Do not understand if all points are included, why can’t this data be in the public RDDS?
Having the data available when you know who the requestor is more palatable than of having it in a public database where you do not know who the requestor is. Where CPs can get on board is the SSAD where you know who the requestor is and have some assurances of how that data would be used.
In terms of having the flag for legal persons – not talking about having a flag just for legal persons – we are talking about flagging the data for all responses. From Ry perspective, not just talking about data of legal persons – this is additional information about all types of registrants.
Have talked about having the field be empty, but the lack of information is useful in its own right.
Not talking about the data of natural persons, just legal persons.
In practice, this might create a bit of confusion. For example, the registrant might have a hard time distinguishing whether to answer “natural” vs “legal with personal” – think about this like you are filling out a multiple choice form – decline to declare vs. just leaving it blank – these are not the same, and the inferences drawn from the two answers are not the same.
If this is blank outside of the SSAD, what does this tell others about the nature of the data? Not having data in that flag or field could tell you something.
There are six distinct possibilities – no answer given, unspecified as to legal vs. natural, unspecified where legal person has not indicated personal or not personal – the responses have started to proliferate
As a registrar, it’s more important to know whether there is personal information rather than knowing what kind of registrant the person is.
Agree that in an ideal world the two meanings proposed – “not provided” or “not asked” have very different meanings and while it would be preferable to have both options – at this point, it’s unlikely to get agreement in this EPDP – would prefer to have an element that is not filled in.
If there are implications, need to be aware of them – for example, the kind element.
“In support of the SSAD, a standardized data element should be identified that would indicate the type of person it concerns (natural or legal) and if legal, also the type of data it concerns (personal or non-personal data). Such a data element could be used by registrars who choose to differentiate between legal and natural persons. Such flagging could facilitate review of disclosure requests via SSAD.”
Support of this language

· Confirm next steps

Review of Recommendation #4

· Consider input provided

· EPDP Team discussion

· Confirm next steps

Review of recommendation #5 (if proposed language has been put forward)

· Consider input provided

· EPDP Team discussion

· Confirm next steps

Confirm next steps

5. Wrap and confirm next EPDP Team meeting (5 minutes):

a. EPDP Team Meeting #37 Thursday 19 August at 14.00 UTC

b. Confirm action items

c. Confirm questions for ICANN Org, if any