Hi Steve,
I fully understand the approach the group has agreed upon for the RDRS is not your preferred path. I believe the point has been clearly made on a number of occasion and yet the group has agreed
to proceed with it. We collectively note your assessment that it is a mistake.
To be clear, in my view there is no foregone conclusion and no one benefits from temporising for 2-3 years. If either were the case we’d be wasting our time and ICANN’s investment. I hope we
collectively remain responsible enough to avoid both.
To your key points:
-
Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to make those requests, and they
need to know what their obligations are after they receive the requested data.
The template originally provided by the Registrars, which we are using on the Request side is both meant as a tool to gather the required elements, and a checklist to ensure the Requestor does not miss any key information.
This in itself doesn’t guarantee “qualifying” for the data as it will depend on the assessment of the Sponsoring Registrar not only based on the data provided, but also on the jurisdiction they operate from and the local DPA’s own thresholds for what does or not qualify. There are efforts to harmonize these things within the EU and we are already experiencing wide differences; in our case we are building an international tool that will need to cater for entirely different legislations.
I assume we will cover the Requestor’s obligations when we review the T&C’s, but here too, responding Registrars may need to cover additional requirements to ensure adherence to their local law.
-
Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules.
The difficulty here is that it is neither for us nor for ICANN to guarantee that. Registrars will not incur risks if they adhere to their local legislation. I’ll let ICANN Org speak for itself, but I don’t see it offering a blanket protection to respondents in its T&C’s, if fact it has made clear from Day1 that it leaves the responsibility squarely in the Registrar’s camp.
-
The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases.
We have had this conversation before: it is unfeasible, someone needs will own the responsibility for every answer and we cannot demand that this decision be taken blindly.
-
There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes.
I am not sure what is involved here. Can you please elaborate as long as we are not discussing doing research on specific requests and their responses, this has already been assessed and refused both by ICANN Org and the Respondents.
-
The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data.
The issue of Privacy/Proxy has been addressed: it will not be tackled here, but we have engaged the Board to ask that the work on PPSAI be restarted. RDRS may need to be adapted in consequence, but we are not pre-empting the outcomes of that work which may be months/years away.
-
Privacy laws and general privacy principles have to be observed.
It’s a given.
- The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties.
We are in full agreement.
To be clear if it wasn’t for the benefit of the Community, I believe ICANN (and I assume you mean Org) would probably want to stay away from any involvement at all.
I don’t believe we can reduce taking in account the risk incurred by the contracted parties for potentially inappropriately handling the PII entrusted in them, as working “just” for the contracted parties.
I remain available to discuss this further.
Kindly,
Sebastien Ducos
GoDaddy Registry | Senior Client Services Manager
+33612284445
France & Australia
From:
Steve Crocker <steve@shinkuro.com>
Date: Thursday, 24 August 2023 at 3:03 pm
To: Sebastien Ducos <Sebastien@registry.godaddy>
Cc: gnso-epdpp2-smallteam@icann.org <gnso-epdpp2-smallteam@icann.org>, Steve Crocker <steve@shinkuro.com>
Subject: Re: [GNSO-EPDPP2-SmallTeam] EPDPP2-SmallTeam - Next steps
Caution:
This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails
to isitbad@.
Sebastian, et al,
Thanks. As best I can tell, the proposed revised charter is to proceed with the old SSAD. To say this another way, the implementation and deployment of RDRS is
a two to three year temporizing step, and then the plan is to return to the previously proposed SSAD concept. I think this is a major mistake. At the very least, it deserves a careful assessment of the purpose and whether the design will accomplish the purpose.
Here are the key points. (This is not necessarily complete; there may be other key points.)
-
Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to
make those requests, and they need to know what their obligations are after they receive the requested data.
-
Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules.
-
The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases.
-
There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes.
-
The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data.
-
Privacy laws and general privacy principles have to be observed.
-
The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties.
I'll try to say more going forward. For the present, this note signals an objection to the proposed charter as it is currently written.
Thanks,
Steve
On Thu, Aug 24, 2023 at 8:46 AM Sebastien@registry.godaddy <Sebastien@registry.godaddy> wrote:
Dear Small Team,
As we will all be back at our desks in the next week or two I wanted to get us back into thinking about what is ahead of us with the RDRS.
1/ Thank you to those who contributed to the documents shared by Yuko last month. I am including her 27 July email below if anyone needs a refresher.
We agreed that there was no immediate need to pivot this into presentations, brochures or any other support you might need to promote the service, but as we are now able to look at our calendars for the next few months, it would be good to raise possible requests and deadlines if you are attending relevant events and would want Staff support in producing material.
2/ Marika sent 2 days ago a reminder to review and confirm the proposed charter for the Standing Committee to continue our good work after launch (see https://docs.google.com/document/d/1IFmCY1xEtWy7IoyM-uSYiRkzFkc0jLdM/edit). Thank you to those who confirmed it works. Thumbs up also from the Requestor side would be great.
3/ We will need to get into reviewing T&Cs before launch. I understand these have been in the working and we can look forward to drafts soon.
4/ We have not scheduled our next meeting yet. A number of us haven’t yet returned from their break.
Next week (28 July) looks early and the following Monday is Labor Day in the US. Unless anyone is itching to get back to it earlier, can I suggest for prepare our next call for Monday 11 September at our regular schedule, for a call every second week thereafter? I will ask Staff to send us invite to block the time slot. We can always agree to augment the cadence in the lead to launch if we find we need more time to get ready for it.
Kindly,
Sebastien Ducos
GoDaddy Registry | Senior Client Services Manager
+33612284445
France & Australia
_______________________________________________
GNSO-EPDPP2-SmallTeam mailing list
GNSO-EPDPP2-SmallTeam@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.