[Gnso-epdp-team] Questions regarding disclosure risks

Fri Sep 20 17:33:58 UTC 2019

Thanks much, James.  My observation is about the models we discussed in L.A.
(What kinds of hamburgers are on the menu?)  We should be precise about what
we mean by "distributed".  I see three models:

*	Model #1: Queries come from requestors into a central point (run
somehow by ICANN), that central point distributes the queries to the
relevant registrars/registries, then the central point routes the replies
back to the requestors.  The central point also passes out authentication
credentials to the parties making queries. This is the technical model the
TSG wrote about.  This has a DISTRIBUTED data model - the data resides at
the registries/registrars.  It has CENTRALIZED query input/output and
access/authentication functions.
*	Model #2: A central point passes out authentication credentials, and
requestors and registries/registrars then use those to trade queries with
each other directly. This is a DISTRIBUTED model in two ways:  the data is
distributed because it resides at the registries/registrars, and
query-making and response takes place among distributed parties.  It is
CENTRALIZED in one way: access/authentication functions.
*	Model #3: ICANN holds a registry containing all RDS data, obtained
from the registries/registrars, and all queries go to and immediately served
back from there.  The central point also controls access (authentication
creds).  This is all CENTRALIZED.  I will call this the Lord of the Rings
Model: "One registry to rule them all / One registry to find them / One
registry to bring them all / And at ICANN bind them."

In Model #1, ICANN can be the party making the disclosure decisions.  In
that case, the registry/registrar would be acting pretty much as a data
processor - if ICANN sends it a query, the registry/registrar simply
supplies the data.   Or, the registrar/registry can be the decision-maker in
model #1.

Model #2 only allows the registry/registrar to be the decision-maker.

Model #3 exists only for ICANN to be the decision-maker.

So, ICANN can be "the decider" without a centralized registry.  The most
crucial question is whether ICANN can or will act as the decider.  If
ICANN's the decider, then we have a choice between Model #1 or Model #3.  If
ICANN will not be the decider, then we have a choice of Model #1 or Model
#2.

Sarah posited ICANN as the decider, and then said the registry/registrar
would be making 6(1)f decisions.  I didn't understand that, because there
can only be one decider.  

So, we need to know who the decider will be.  And the WG should enumerate
the plusses and minuses of each of the models.

All best,

--Greg

From: James M. Bladel <jbladel at godaddy.com> 
Sent: Friday, September 20, 2019 11: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 <mailto:gnso-epdp-team-bounces at icann.org>
<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/dc17e0c9/attachment-0001.html>