[Gnso-epdp-team] Proposed agenda - EPDP Phase 2A Meeting #23 - 18 May 2021

[Caitlin Tubergen]

Dear EPDP Team,

Please find below the proposed agenda for tomorrow’s meeting.

Best regards,

Berry, Marika, and Caitlin

--
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)



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?

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?

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”?

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.



     *   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?

  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.


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_k0hVA6c2SvQPLiaZAlUllTKdplssofYlRHDkeR4mJ8/edit?usp=sharing) 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/1wpZWZzCNcDsAYuy3FqxV67POgDV2hrOvrwGa3kjddOc/edit?usp=sharing). 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 #24 Thursday 20 May at 14.00 UTC
  2.  Confirm action items
  3.  Confirm questions for ICANN Org, if any




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