Dear All,
As a reminder, please see Sebastien’s message below. The proposed agenda for tomorrow’s meeting is as follows:
Best regards,
Marika
From:
GNSO-EPDPP2-SmallTeam <gnso-epdpp2-smallteam-bounces@icann.org> on behalf of "Sebastien@registry.godaddy" <Sebastien@registry.godaddy>
Date: Wednesday, 9 March 2022 at 14:28
To: "gnso-epdpp2-smallteam@icann.org" <gnso-epdpp2-smallteam@icann.org>
Subject: [GNSO-EPDPP2-SmallTeam] EPDP Phase 2 Small Team update
Dear Small Team members,
I hope you are having an informative and productive ICANN73. In preparation for our meeting next week, I wanted to share a couple of things with you and ask you to start thinking about our next conversation.
o
Wednesday 16 March Small team meeting (already scheduled)
o
Monday 21 March joint meeting with GDPR Board Caucus / interested Board members
o
Wednesday 23 March Small team meeting
o
Monday 28 March joint meeting with GDPR Board Caucus / interested Board members
o
Wednesday 30 March small team meeting to finalize response to Council
Of course, if in the end additional time and/or additional meetings are needed, we can adjust accordingly but for now I hope we are all willing to work towards the timeline we shared with the
GNSO Council prior to ICANN73.
To prepare for our conversation next week, I would like to encourage you all to review the input that has been received in the
google
doc [docs.google.com]. As I shared in my high-level summary last week, most small team members seem to be of the view that the ODA does not provide enough information to confidently determine the cost / benefit. Some point
to the inability to predict costs based on usage, the high variability and range of costs and lack of information on the specific costs of the different components of the system. This in my mind raises the question of what further information is needed and
how can it be obtained, to allow the GNSO Council as well as the ICANN Board to confidently determine the cost / benefit and/or determine if modifications need to be made.
Some have suggested that a pilot / ticketing system could assist in that regard. However, before we dive into what such a pilot / ticketing system could/should look like, I think we need to take a step back and ask ourselves some of the following questions.
Assuming for a moment that there is support at Council level as well as the ICANN Board level for conducting a pilot of some kind to gather further information:
I know that these are not easy questions to answer that is why I would like you to start thinking about these, and ideally, share any thoughts you may have with the list so we can start this conversation prior to our
next meeting. We obviously need to be conscious of the fact that a pilot is a pilot - it cannot prove everything to everyone, because by the time to have everything in place to test, you will have the final product. The pilot needs to be the result of what
we want to test, and the pilot in turn will be the tool to provide the answers to that test.
I think this will also be an important part of our informal conversation with the ICANN Board, because if this turns out to be the direction the small team wants to take, we do want to make sure that any pilot has the
ability to either confirm or disprove the concerns that the Board expressed in its letter so that it helps inform a decision on how to proceed.
I hope this is helpful. Of course, if there is any other information and/or ideas that have emerged from discussions during ICANN73 that may be helpful, please feel free to share these with the group.
Kindly,
Sebastien Ducos
GoDaddy Registry | Senior Client Services Manager
![]()
+33612284445
France & Australia