Sebastien,

Thank you for your detailed reply to my note.  I'll try to expand a bit.

My note was triggered by a possible misunderstanding that once the RDRS experiment is complete, the full SSAD will be rolled out without further consideration of the architecture.  I think this would be a very large mistake.  But in order to keep this discussion to a manageable scope, I'll focus on the RDRS.  We can come back to post-RDRS issues later.


On Tue, Sep 5, 2023 at 10:07 AM Sebastien@registry.godaddy <Sebastien@registry.godaddy> wrote:

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:

 
1. 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.

The creation of the form is indeed a step forward.  It could have and should have been done quite a while ago.  Everyone could have been using it to submit requests directly to registrars.  But since the form is supposed to be available this month and the system available in November, we can proceed from here.

While an orderly form is necessary, it's not sufficient.  The point I've been making about Requesters knowing whether their requests will be honored requires more discussion.  One way or another, both requesters and registrars are going to develop a sense of what requests will be honored.  After a requester has made one or more requests, he will know which ones succeeded and which ones failed.  Based on that, his subsequent requests will likely be patterned after the ones that succeeded previously.  Similarly, registrars will gain similar experience and use that experience to streamline their internal processes.

Tucows has been running their own system, Tucows Tiered Access Compliance and Operations (TACO) System 
https://tieredaccess.com .  Perhaps they can comment on how they have evolved their system and internal processes based on their experience.

The reaction whenever I've raised this point is that it's up to each registrar to evaluate each request.  Well, yes, but that's just a starting point, not the end of the discussion.  A couple of thoughts arise immediately:
We have not had any of these discussions.  ICANN Org has taken the narrow position that its role is to avoid getting involved in any of the substantive issues, it has not encouraged the requesters and registrars to do so, and it has not included support for these discussions in its design of the RDRS.

2. 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.

I'm not suggesting ICANN offer blanket protection.  I'm not even suggesting ICANN offer *any* protection.  What I am suggesting is that casting the discussion in terms of blanket protection closes off the potential for meaningful discussion.  The path that's been chosen for the RDRS is strongly oriented against making useful, practical distinctions.  This casts a lot of doubt on whether the data gathered by the RDRS will provide a meaningful sense of what the demand, cost, etc. would be in a well designed system.

3. 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.

See the above discussion.  Automation is essential for reducing cost and delay.  That said, I agree that it will take some experience and some work to determine which requests can be handled automatically.  As you say, the decision cannot be taken blindly.  But with experience, at least some of the requests can be handled automatically.  The process will necessarily be incremental, i.e. "salami slicing."


 4. 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 Respondent.

There are legitimate uses for searches across the registration data.  We can defer discussion of this for another time, but we can't make it go away.

5. 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.

This is another issue that has been kicked down the road.  It won't go away.

6. Privacy laws and general privacy principles have to be observed.

It’s a given.

7. 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 agree that focusing on just the contracted parties won't change the risks involved with PII.  That wasn't the point of this bullet.  Rather, I was referring to the idea that this system has been designed with only the contracted parties involved.  The ccTLDs and RIRs have similar needs. 

 

I remain available to discuss this further.


Thanks.  I too remain available for further discussion.

Steve Crocker

 

Kindly,

 

 

 

Sebastien Ducos

GoDaddy Registry | Senior Client Services Manager

signature_2363518853

+33612284445

France & Australia

sebastien@registry.godaddy

 

 

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

  1. 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.
  2. 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.
  3. 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.
  4. There needs to be a way to perform searches and correlations.  These may need to be done via trusted intermediary processes.
  5. The quality/accuracy of the data has to be addressed.  Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data.
  6. Privacy laws and general privacy principles have to be observed.
  7. 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

signature_3256585056

+33612284445

France & Australia

sebastien@registry.godaddy

 

 

From: GNSO-EPDPP2-SmallTeam <gnso-epdpp2-smallteam-bounces@icann.org> on behalf of Yuko Yokoyama <yuko.yokoyama@icann.org>
Date: Thursday, 27 July 2023 at 11:43 pm
To: gnso-epdpp2-smallteam@icann.org <gnso-epdpp2-smallteam@icann.org>
Subject: [GNSO-EPDPP2-SmallTeam] RDRS Talking Points - 3 clean documents

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@.

 

Dear GNSO Small Team,

 

Thank you again for all your valuable input on the RDRS Talking Points document. Due to the nature of the cleaning up process, I have opted to preserve all redline/comments in the original document, but created 3 clean documents based on that. These 3 documents incorporated all of you feedback and comments as appropriate.

 

 

If you see something glaring, please do let me know. Otherwise, please consider these final in principle, and are ready for your use.  

 

Please also be reminded that ICANN now has a one-page flyer, that will complement the talking point documents. They are translated into 6 UN languages + Portuguese:

 

 

Thank you,

 

Yuko Yokoyama

Program Director

Strategic Initiatives, Global Domains & Strategy

Internet Corporation for Assigned Names and Numbers (ICANN)

 

Direct Line:  +1 310 578 8693

Mobile: +1 310 745 1517

E-mail:  yuko.yokoyama@icann.org

www.icann.org

_______________________________________________
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.