Page History

Audio Recording

Zoom Recording

Chat Transcript 

GNSO transcripts are located on the GNSO Calendar

Attendance

Apologies: Matthew Shears (ICANN Board), Marc Anderson (RySG), Melina Stroungi (GAC), James Bladel (RrSG), Mark Svancarek (BC)

Alternates:  Leon Sanchez (ICANN Board), Beth Bacon (RySG), Owen Smigelski (RrSG), Steve DelBianco (BC)

Notes/ Action Items

EPDP_P2A_Project-Change-Request_20210803 (1).docx

1.                     Roll Call & SOI Updates (5 minutes)

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

a.     Status of continuation of mediated conversations

·      Share proposed action items coming out of mediated conversations to date

• If we have a path to consensus and need more time to finalize, that would be sufficient justification for submitting a project change request. Otherwise, a project change request is unlikely to help.
• The Team will need a rationale by tomorrow if we need extra time.
• Update from Melissa Allgood –
• There is one more session today regarding dealing with uncertainty. Following the last call, leadership will propose a plan for how to handle the mediated discussions.
• Leadership would like to expand the conversation regarding the data element. There was a lack of understanding regarding the benefits of a standardized data element and the operational challenges of having a standardized data element. Support Staff has created a document where benefits and burdens can be placed – the deadline to contribute to the document is Tuesday, 10 August.
• Hearing that Team members have to go on the record again with the operational burdens is frustrating – how many times do we have to repeat the same things? Still believe there is a fundamental scope issue that has not been addressed with respect to the additional data element.
• This is the last time groups will need to do this. If the issues have been stated before, it should not be a large lift to copy and paste again.
• It is the chair’s view that the issues the Team is tackling are in scope. If the GNSO Council feels that the questions are out of scope, the Council can communicate this to the Team. Philippe has been monitoring the conversations closely. Believe what the Team has in the Initial Report is within the scope of the guidance given by the GNSO Council.
• It’s important to document the different approaches on the new data element.

3.                     Initial Report Public Comment Review (50 minutes)

a.     EPDP Team Question for Community Input #3 – see PCRT and Discussion Table

-    The discussion tables were developed by the staff support team in an attempt to group similar comments to facilitate the review. Groups were asked to flag comments that require further discussion.

b.     Review items flagged for further discussion

·      #1 (IPC) –

• This should be available for registrars to do – for the benefit of registries, it should be consistent across registrars.
• There is already an element in RDAP that talks about “kind” and different elements that can be populated – individual, organization. Since it is already in existence, there should be a policy recommendation to standardize this.
• This data element should not be conflated with the recommendation regarding differentiation. Part of the fear of having the standardized item is that differentiation should be required, but that is incorrect.
• The RrSG is not opposed to this flag; however, not willing to accept a mandatory data element.
• What some groups want is not what we will end up with; the initial report made it very clear to ask – should this element exist not should it be mandated.
• There is an opportunity to agree on having a standardized data element available – the capability for CPs to differentiate in a standardized way. How it is done is important but not the critical question at this juncture.
• If there is an optional choice on whether or not to differentiate, then creating a standardized data element is contradictory. Some organizations are already using the “kind” element – if it is called standardized, it implies mandatory.

·      #2 (RrSG, IPC)

• Ruling from chair that this is in scope.

·      #3 (ALAC, BC)

• The Team needs to make a clear recommendation to ICANN org that it is defined. If we are not mandating its use, it’s not consensus policy – but there are many recommendations coming out of PDPs that are not consensus policy.
• Many examples of consensus policies where requirements are optional – setting aside the mandatory discussion, if it is used, it should be used consistently
• There is considerable uncertainty about the nature of domain name registrations – the threshold of work for determining legally if this is a natural or legal person will either fall on the individual or registrar or both. Do not believe in creating meaningless data elements.
• Thought the point of reviewing public comments was to flag new concerns or ideas. That is not what is happening right now – the conversation is moving back to policy disagreements.

·      #5 (BC)

• There are a lot of benefits to the standardized data element that the group has not discussed before – for example, the users of the RDS could assess the veracity of the registrant’s designation. Plan to add these to the homework document.

·      #6 (RrSG, ALAC, IPC)

• This is not new information, but ICANN org made important points regarding creation of clear policy language.
• Important to address 17.3 as part the Team’s final report.
• Hope ICANN org liaisons participate in flagging if the final report language is unclear.

·      #7 (GAC, ALAC, IPC)

·      #11 (BC)

• Have heard CPs mention cost or resource issues is a barrier to the data element. The group should consider how to reduce these barriers.

·      #12 (IPC)

• When the team discussed mandatory differentiation, we thought differently about what that would mean. Do not have concerns as a registrar if I am required to give the customer the option to self-designate. All that means is that a consistent data element is published in the RDS – that doesn’t mean their data is automatically published in the RDDS. The “kind” concept already exists in RDAP.

·      #13 (IPC)

• Not a good idea to discuss the probability of consensus before we consider each other’s positions.

·      #14 (ALAC)

• The comments are not from the public; they are from groups who are participating in this group.
•  

c.       EPDP Team Question for Community Input #4 – see PCRT and Discussion Table

·      #2 (GAC, BC, ALAC)

• Think about whether guidance is sufficient and consider expressly adding that GDPR does not apply to legal persons.
• Also think that guidance should be updated to best practices – should discuss both of these items at the next call.

·      #3 (ALAC, BC)

·      #5 (BC, ALAC)

·      #7 (IPC, BC, ALAC)

·      #9 (BC, RySG)

·      #12 (BC)

·      #14 (BC)

·      #16 (BC)

·      #17 (BC)

·      #18 (BC)

·      #20 (BC)

·      #21 (BC)

d.      Looking ahead at next assignments:

·      EPDP Team Question for Community Input #5

·      Additional Comments

4.                     Proposed timeline to get to Final Report (15 minutes):

- 10 August – complete review of public comments

- 12 August – delivery of action items mediated conversations, confirm possible suggestions for further consideration.

- 17 & 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.

- 31 August – finalize report and address any outstanding items.

·         EPDP Team input

·         Confirm next steps

• In the meetings from 12 August onward, the Team would work on updated language for inclusion in the Final Report.
• There probably won’t be anything so dramatically different from the Initial Report that it would need another round of public comments.
• Think the timelines are too aggressive and would request more time.
• Do not think we need to extend the timeline – there is nothing new in the public comments.
• If done, the Team would need to file a project change request by next Monday. The ultimate decision about granting more time belongs to the Council. If groups believe more time is needed – it would be helpful to provide the rationale for requesting more time to the leadership team. The rationale for requesting more time should be to the level that will convince the entire council that the additional time is warranted. If the PCR is submitted by the motion and documents deadline, this will allow councilors to have time to consult with their constituencies. Generally speaking, the Council will accept a PCR absent objection, but there is no guarantee in this instance. As a reminder, the conclusion of this effort will allow work to begin on accuracy.  
• The Council is not meeting until 19 August, so the Team will still need to work under its existing timeline as an extension is not guaranteed. Staff will attach the PCR to the notes, and groups asking for more time will be asked to fill in the highlighted areas. Staff will need this by Monday, 9 August by 16:00 UTC.

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

a.     EPDP Team Meeting #34 Tuesday 10 August at 14.00 UTC (tentative)

b.     Confirm action items

• EPDP Team to review the public comments received for Preliminary Recommendations 5 and Additional Comments. Groups to use the Discussion Table Google Docs to indicate if new ideas are presented that warrant further discussion by the full team by COB Monday, 9 August. If EPDP Members believe a recommendation should be amended based on a public comment, EPDP Team members are strongly encouraged to provide proposed updates in the Google docs by COB Monday, 9 August.
• EPDP Team members to indicate benefits and operational challenges of a (i) legal v. natural differentiation and (ii) standardized data element within the dedicated Google Doc by COB Wednesday, 11 August.
• Groups who believe the EPDP Team needs more time to deliver its Final Report to indicate rationale in the highlighted portion of the attached project change request by COB, Friday, 6 August.

c.     Confirm questions for ICANN Org, if any