[Gnso-epdp-team] Questions regarding disclosure risks

Mark Svancarek (CELA) marksv at microsoft.com
Fri Sep 20 18:02:39 UTC 2019


Attached is the final version of a PowerPoint that I shared exactly one year ago at the first LA meeting.  There wasn't much interest back then, but it should be helpful when considering these topics.

The notes attached to each slide explain the details, but this matrix is a summary.  (I have also attached the matrix as an attachment.)


CP delivers data to requestor
Data passes through ICANN from CP to requestor
ICANN always holds the data

  *   Request goes to CP
  *   CP is the decider
2



  *   Request goes to ICANN
  *   CP is the decider




  *   Request goes to CP
  *   ICANN is the decider
3



  *   Request goes to ICANN
  *   ICANN is the decider
4
5
6, 7

Feel free to propose additional variations if applicable.

(Note that the reference to "UAM" was based on my interpretation of the ICANN-proposed model from mid-2018; that term no longer has any practical meaning and should not be construed as applicable to anything Goran or Strawberry team have discussed recently.)

/marksv


From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> On Behalf Of James M. Bladel
Sent: Friday, September 20, 2019 8:35 AM
To: Greg Aaron <greg at illumintel.com>; 'Sarah Wyld' <swyld at tucows.com>; gnso-epdp-team at icann.org
Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks

Greg et al -

Sarahs' Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin.  So I'll respond to Greg and pose a few questions to ICANN Staff.

Greg - In this case, Yes. "Addressed" = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data.  For clarity, "provided" can mean that ICANN sends the data directly to the Requestor, or somehow causes another (contracted) party to transmit the data to the Requestor.

Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to  individual Contracted Parties.  They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to the affected Contracted Party (please jump in if I'm misunderstanding/mischaracterizing this point).

Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are:

Does ICANN have a clear preference on whether or not it will:
1. Field these requests for non-public data
2. Maintain its own RDS replica database
3. Make a/the determination of the validity of the request
4. Assume responsibility for this decision, in any scenario where ICANN doesn't hold the data directly and must require a Contracted Party to respond to the Requestor (even if the Contracted Party disputes ICANN's determination).

We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work.  Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for making this decision), or we abandon the "centralized" version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some "requestor" stakeholders).

Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons.

Thanks-

J.
_______________
James Bladel
GoDaddy
________________________________
From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org<mailto:gnso-epdp-team-bounces at icann.org>> on behalf of Greg Aaron <greg at illumintel.com<mailto:greg at illumintel.com>>
Sent: Thursday, September 19, 2019 14:25
To: 'Sarah Wyld'; gnso-epdp-team at icann.org<mailto:gnso-epdp-team at icann.org>
Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks

Notice:This email is from an external sender.


When you say "addressed" what do you mean -- that ICANN decides whether the data should be disclosed in response to a query?


From: Sarah Wyld <swyld at tucows.com<mailto:swyld at tucows.com>>
Sent: Thursday, September 19, 2019 11:16 AM
To: Greg Aaron <greg at illumintel.com<mailto:greg at illumintel.com>>; gnso-epdp-team at icann.org<mailto:gnso-epdp-team at icann.org>
Subject: Re: [Gnso-epdp-team] Questions regarding disclosure risks


Hi Greg,

"Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here.

Thanks.

--

Sarah Wyld

Domains Product Team

Tucows

+1.416 535 0123 Ext. 1392




On 9/19/2019 10:12 AM, Greg Aaron wrote:
Sarah, what do you mean by "responding party"?  For example so your scenarios assume that ICANN is acting in a specific legal capacity?

I ask because depending on what you mean, there may be other scenarios.

All best,
--Greg


From: Gnso-epdp-team<gnso-epdp-team-bounces at icann.org><mailto:gnso-epdp-team-bounces at icann.org>On Behalf Of Sarah Wyld
Sent: Wednesday, September 18, 2019 3:18 PM
To: gnso-epdp-team at icann.org<mailto:gnso-epdp-team at icann.org>
Subject: [Gnso-epdp-team] Questions regarding disclosure risks


Hello all,

During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data.

In order to fulfill this request, one of two things must be true. Either:

  1.  ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or
  2.  ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor

These potential scenarios raise the following questions:

  1.  In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed?
  2.  In the second scenario, will ICANN "relay" disclosed data between the requestor and the Registry/Registrar?
  3.  What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance?

Thank you,

--

Sarah Wyld

Domains Product Team

Tucows

+1.416 535 0123 Ext. 1392




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190920/3532013d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: contracts and whois data flow 2018 final.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 135329 bytes
Desc: contracts and whois data flow 2018 final.pptx
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190920/3532013d/contractsandwhoisdataflow2018final-0001.pptx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: whois decider + holder matrix.png
Type: image/png
Size: 12917 bytes
Desc: whois decider + holder matrix.png
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190920/3532013d/whoisdeciderholdermatrix-0001.png>


More information about the Gnso-epdp-team mailing list