<html>
<body>
Hi Greg,<br><br>
What I meant by &quot;sourced&quot; is where the data is collected. I
think you're identifying the entity which interfaces directly with the
RDS as data flows through each model.<br><br>
Pages 111 and 112 illustrate the SRDS and FRDS models, which show the
data is sourced from Validators and Registrars, with Registrar data
flowing through Registries. For example, see the text under the figure on
page 112, &quot;In this model, data is pushed to the SRDS by Validators
and Registries/Registrars via EPP.&quot; For a summary of models
considered and where data is collected for each model, see the table on
page 110.<br><br>
Page 163 then indicates the Registry is the entity through which
collected data is either pushed at time of collection (SRDS), or pulled
in near real-time when responding to queries (FRDS).<br><br>
Page 142 actually depicts another model (regional) that wasn't
recommended. For completeness, I should noted that page 144 depicts a
bypass model (also not recommended) where data wouldn't flow through
registries at all.<br><br>
Apologies for any confusion my description of &quot;sourcing&quot; may
have caused.<br><br>
Best, Lisa<br><br>
<br>
At 01:47 PM 4/5/2017, Greg Aaron wrote:<br>
<blockquote type=cite class=cite cite=""><a name="_MailEndCompose"></a>
Dear Lisa:<br>
&nbsp;<br>
No, in the EWG’s final report, it says that the RDS would obtain data
from the _<i>registries</i>_, not from registrars.&nbsp; See the
illustration on page 11; pages 142 and 163 say “registry” as well.<br>
&nbsp;<br>
All best,<br>
--Greg<br>
&nbsp;<br>
&nbsp;<br>
<b>From:</b> Lisa Phifer
[<a href="mailto:lisa@corecom.com" eudora="autourl">
mailto:lisa@corecom.com</a>] <br>
<b>Sent:</b> Wednesday, April 5, 2017 3:04 PM<br>
<b>To:</b> Greg Aaron &lt;gca@icginc.com&gt;; Hollenbeck, Scott
&lt;shollenbeck@verisign.com&gt;; 'stephanie.perrin@mail.utoronto.ca'
&lt;stephanie.perrin@mail.utoronto.ca&gt;; 'gnso-rds-pdp-wg@icann.org'
&lt;gnso-rds-pdp-wg@icann.org&gt;<br>
<b>Subject:</b> Re: [gnso-rds-pdp-wg] Proposed Definition/Background for
Authoritative<br>
&nbsp;<br>
The EWG's thinking on models evolved quite a bit after its first initial
report.<br><br>
In the EWG's final report, thin data elements were sourced from
registrars and contact data was sourced from validators.<br><br>
Refer to pages 110-116 for the set of models considered, and page 163 for
data flow diagrams for two of those models (called synchronized and
federated RDS). <br><br>
On pages 112-114 and in Annex F, you will find discussion of
jurisdictional and privacy concerns (as well as other concerns) that were
evaluated as the basis for the EWG's final decision to recommend the SRDS
model.<br><br>
Lisa<br><br>
At 12:26 PM 4/5/2017, Greg Aaron wrote:<br><br>

<dl>
<dd>Dear Scott:<br>

<dd>&nbsp;<br>

<dd>My point was: where was the EWG’s RDDS going to get data?&nbsp; From
the registries, not directly from registrars.<br>

<dd>&nbsp;<br>

<dd>The “Registrar Registration Expiration Date” field is mention is
relevant to just the three thin gTLD registries (.COM, .NET, .JOBS) --
the thin model that’s going away (and has been for years).&nbsp; In the
other 1,200+ gTLD registries, the expiration date is not provisioned by
registrars, it’s generated by the registries (as you know).<br>

<dd>&nbsp;<br>

<dd>So anyway, you’re advocating that in the future, contact data should
remain at registrars and never go to registries, and that ICANN should
send all gTLDs to the thin model?&nbsp;&nbsp; After the community decided
to go to an all-thick model in 2013, and Verisign just recently agreed to
the thick implementation plan for .COM and
.NET?&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>

<dd>&nbsp;<br>

<dd>To better understand, I would like your views on these questions: 
<dd>How the thin registry model is required under privacy law.&nbsp; 
<dd>An issue is personal data crossing from (being collected from) one
jurisdiction to another.&nbsp; Under the evolving privacy laws you are
concerned about, won’t a registrar sometimes be barred from accepting
domain registrations from registrants outside its
jurisdiction?&nbsp;&nbsp; For example, how could GoDaddy, a U.S.
registrar, accept registrations (and the accompanying contact data) from
registrants in Europe?&nbsp; Could GoDaddy serve that contact data via an
RDS under any circumstances?&nbsp; 
<dd>What has changed in privacy law recently that overrides the
considerations of privacy law that the EWG and the Thick PDP WG
made?&nbsp; 
<dd>&nbsp;<br>

<dd>All best,<br>

<dd>--Greg<br>

<dd>&nbsp;<br>

<dd>&nbsp;<br>

<dd>From:</b> Hollenbeck, Scott
[<a href="mailto:shollenbeck@verisign.com" eudora="autourl">
</a><a href="mailto:shollenbeck@verisign.com" eudora="autourl">
mailto:shollenbeck@verisign.com</a>] <br>

<dd>Sent:</b> Wednesday, April 5, 2017 12:37 PM<br>

<dd>To:</b> Greg Aaron
&lt;<a href="mailto:gca@icginc.com">gca@icginc.com</a>&gt;;
'stephanie.perrin@mail.utoronto.ca'
&lt;<a href="mailto:stephanie.perrin@mail.utoronto.ca">
stephanie.perrin@mail.utoronto.ca</a>&gt;; 'gnso-rds-pdp-wg@icann.org'
&lt;<a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a>&gt;<br>

<dd>Subject:</b> RE: [gnso-rds-pdp-wg] Proposed Definition/Background for
Authoritative<br>

<dd>&nbsp;<br>

<dd>Greg,<br>

<dd>&nbsp;<br>

<dd>I was a member of the EWG. It’s important to recall the context of
the recommendations that you refer to below. The EWG recommended
development of a single, centralized RDDS, *not</b>* multiple thick
registries. In that environment, there is only one source for public
access, and it is, by definition, the only possible source. It’s
described as authoritative because there are no other options. Note that
this recommendation was largely rejected by the community.<br>

<dd>&nbsp;<br>

<dd>The one example I provided was just that – one example, and it’s not
the one you expanded on in your “PS” below. I wasn’t referring to the
expiration date derived from the specified registration period. As the
author of EPP, I know how that works very well. I was referring to the
“Registrar Registration Expiration Date” as described in the CL&amp;D
policy:<br>

<dd>&nbsp;<br>

<dd>
<a href="https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en">
https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en</a>
 <br>

<dd>&nbsp;<br>

<dd>This is a data element produced by the registrar and pushed to the
registry solely for inclusion in a registry’s RDDS. There are multiple
mainstream examples where the registrar is the original creator or
collector and the registry is just the last link in the chain of
custody:<br>

<dd>&nbsp;<br>

<dd>Registrant contact information<br>

<dd>Admin contact information<br>

<dd>Billing contact information<br>

<dd>Technical contact information<br>

<dd>Registrar reseller information<br>

<dd>&nbsp;<br>

<dd>Is my view of “authoritative” counter to the direction of the thick
WHOIS policy? Yes, it is. It recognizes that the data privacy landscape
is changing and thick registries might not be viable in the future due to
evolving data protection laws.<br>

<dd>&nbsp;<br>

<dd>Scott<br>

<dd>&nbsp;<br>

<dd>From:</b>
<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
gnso-rds-pdp-wg-bounces@icann.org</a>
[<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">
</a><a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">
mailto:gnso-rds-pdp-wg-bounces@icann.org</a>] On Behalf Of </b>Greg
Aaron<br>

<dd>Sent:</b> Wednesday, April 05, 2017 11:41 AM<br>

<dd>To:</b> Stephanie Perrin
&lt;<a href="mailto:stephanie.perrin@mail.utoronto.ca">
stephanie.perrin@mail.utoronto.ca</a>&gt;;
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<br>

<dd>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg] Proposed
Definition/Background for Authoritative<br>

<dd>&nbsp;<br>

<dd>There are two different definitions&nbsp; of “authoritative” being
used here.&nbsp; One is “where does the data come from,” i.e.&nbsp; what
is the original source.&nbsp; Stephanie and Scott are using this first
definition.&nbsp;&nbsp; The second definition is “what is the data of
record, which should be relied upon.”&nbsp; I am using that second
definition.&nbsp; I think the first concept is important to understand,
but it cannot be used as the standard for a variety of legal, technical,
and practical reasons.&nbsp;&nbsp;&nbsp; The history at ICANN, and recent
policy-making, has been toward relying on thick registry data as the data
of record, to be relied upon.&nbsp; My view was used by both the EWG and
the Thick WHOIS PDP.<br>

<dd>&nbsp;<br>

<dd>Stephanie, I think you’re wrong about what the EWG said.&nbsp; It did
not use your definition, it used mine.&nbsp; The EWG said: “Requestors
must be able to obtain authoritative data from the RDS in real-time when
needed.” And the EWG said: “the RDS is the authoritative data source and
provides authoritative access.”&nbsp; The EWG did not recommend that
people be able to obtain certain kinds of data directly from registrars
via RDS.&nbsp; Instead, the EWG said that RDS was to provide data from
(thick) registries.&nbsp; The data in the registries is authoritative,
and the RDS is the authoritative way to get that data held in the
registries.<br>

<dd>&nbsp;<br>

<dd>The Thick WHOIS PDP WG recently looked at the issue of
authoritativeness, and our WG should consider it carefully.&nbsp; That
PDP WG used my definition, not Scott’s.&nbsp; That PDP WG said that a
thick registry is the authoritative repository of all data currently
displayed in WHOIS.&nbsp; Quote below, with my notes in square
brackets:<br>

<dd>&nbsp;<br>

<dd>“Here is the working definition used by the WG while analysing this
issue: ‘Authoritative, with respect to provision of Whois services, shall
be interpreted as to signify the single database within a hierarchical
database structure holding the data that is assumed to be the final
authority regarding the question of which record shall be considered
accurate and reliable in case of conflicting records; administered by a
single administrative (agent) and consisting of data provided by the
registrants of record through their registrars.’ A proposed shorter
version is ‘the data set to be relied upon in case of doubt’.&nbsp; [In
other words, the REGISTRY is the ultimate authority, not
registrars.]<br>

<dd>Authoritativeness in a Thin Whois Environment<br>

<dd>Since the registrar alone holds most Whois data, its data is
necessarily authoritative as to those data elements (e.g., name of
registrant). For that data held by both registrar and registry (e.g.,
name of<br>

<dd>registrar), it appears that registry data is generally treated as
authoritative, but the WG is not aware of any official ICANN policy
statement on this. The WG observes that in the case of the Uniform
Dispute Resolution Policy (UDRP), UDRP Providers treat the registrar
Whois information as authoritative, which may be the result of the UDRP
having been adopted prior to the emergence of thick gTLD registries.<br>

<dd>Authoritativeness in a Thick Whois Environment<br>

<dd>Most comments that addressed this question stated that registry data
is considered authoritative in the thick environment. Only one stated
that the registrar data was authoritative. Again, the WG is<br>

<dd>not aware of any official ICANN policy statement on this question.
The WG notes that the registrar remains responsible for the accuracy of
the data under either the thick or thin model, as the relationship with
the registrant remains with the registrar. ..the WG assumes that any data
collected by the registrar becomes authoritative only after it is
incorporated in the registry database</i>.” [emphasis added]<br>

<dd>&nbsp;<br>

<dd>If anyone wants the registrars to remain the source of record
for&nbsp; any data available throrugh an RDS, then: 
<dd>That will sink the entire purpose of the thick registry effort, 
<dd>It will make solving domain disputes harder than they are now, and 
<dd>Registrars should be contractually required to serve RDS
indefinitely.&nbsp; That’s contrary to the thick policy, a goal of which
was to get registrars out of the business of serving their own WHOIS (or
RDAP, or whatever).&nbsp; 
<dd>All of which would be completely unnecessary and wasteful.<br>

<dd>&nbsp;<br>

<dd>All best,<br>

<dd>--Greg<br>

<dd>&nbsp;<br>

<dd>P.S.: Scott is using a corner case to support his argument.&nbsp; In
99.999% of cases, registrars do not ”push expiration dates to
registries”.&nbsp;&nbsp; Registrars send in EPP Create commands and
indicate a registration term in years.&nbsp; The registry time-stamps the
create and expiration date based on the time the Create command is
received.&nbsp; The registrar does not hold those dates authoritatively –
the registry does.&nbsp; The only exception I know of is Verisign’s
obscure “ConsoliDate” product, which is available in .COM and .NET and is
used infrequently&nbsp; by a small number of corporata cleints to add
days to expiration dates.&nbsp; In any case, the Create date in a
registry may not correspond to the date/time the registrant entered into
the contract with the registrar.&nbsp; What really matters is the date
recorded in the registry.<br>

<dd>&nbsp;<br>

<dd>&nbsp;<br>

<dd>&nbsp;<br>

<dd>From:</b>
<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
gnso-rds-pdp-wg-bounces@icann.org</a>
[<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">
</a><a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">
mailto:gnso-rds-pdp-wg-bounces@icann.org</a>] On Behalf Of </b>Stephanie
Perrin<br>

<dd>Sent:</b> Wednesday, April 5, 2017 10:05 AM<br>

<dd>To:</b>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<br>

<dd>Subject:</b> Re: [gnso-rds-pdp-wg] Proposed Definition/Background for
Authoritative<br>

<dd>&nbsp;<br><br>

<dd>+1<br><br>

<dd>It is not every day that I quote the EWG conclusions, as there are
quite a few with which I disagree.&nbsp; In this case though, it does
seem to me we discussed this exhaustively, and reached the conclusion
that the registrars were the authoritative source.&nbsp; From a data
protection perspective, this is consistent.&nbsp; I believe it would be
the common view that the entity closest to the individual on the data map
would be the authority on the data, not the entity further down the chain
of control, and not the data controller (in this case ICANN).&nbsp; I
realize I am mixing technical perspectives with legal perspectives here
but I believe it is useful to flesh out how the matter is analyzed from
each point of view.<br><br>

<dd>cheers Stephanie P<br>

<dd>&nbsp;<br>

<dd>On 2017-04-05 07:10, Hollenbeck, Scott via gnso-rds-pdp-wg
wrote:<br>

<dd>From:
<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
gnso-rds-pdp-wg-bounces@icann.org</a>
[<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">
</a><a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">
mailto:gnso-rds-pdp-wg-bounces@icann.org</a>] On Behalf Of Greg
Aaron<br>

<dd>Sent: Tuesday, April 04, 2017 5:18 PM<br>

<dd>To: Michael D. Palage
<a href="mailto:michael@palage.com">&lt;michael@palage.com&gt;</a>; 'RDS
PDP WG'
<a href="mailto:gnso-rds-pdp-wg@icann.org">
&lt;gnso-rds-pdp-wg@icann.org&gt;</a><br>

<dd>Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] Proposed
Definition/Background for Authoritative<br>

<dd>&nbsp;<br>

<dd>Thanks, Mike.&nbsp; A few notes to contribute as people consider
“authoritative”:<br>

<dd>&nbsp;<br>

<dd>Registries exist to be authoritative repositories of data; that’s
what they are designed to do.&nbsp; (So, for example, two different
people can’t register the same domain name, or so a domain won’t resolve
to the wrong nameservers.)&nbsp; Domain registries are generally
considered authoritative for at least the thin data.&nbsp; (Domain,
sponsoring registrar, dates, statuses, nameservers.)&nbsp; The registry
creates or is the original recorder of record for most of those fields
(domain, sponsoring registrar, dates).&nbsp; And the registry is
authoritative for status and nameserver data, using them to enable and
control resolution, or to prevent certain actions from taking place in
the registry (such as deletions, and registrar-to-registrar
transfers).<br>

<dd>&nbsp;<br>

<dd>The Thick WHOIS PDP decided that all gTLD registries should be
thick.&nbsp; One reason was to ensure that there won’t be any more
disagreements (discrepancies)&nbsp; between what the registrar says the
data is and what the registry says it is (and as seen via WHOIS or a
successor system).&nbsp; Another reason was to hold contact data in one
place reliably, so it could be served from one (authoritative) place; as
a consequence registrar port 43 service will eventually go
away.&nbsp;&nbsp; In other words, all registries should become
authoritative for all the data we see in WHOIS, if they are not
already.&nbsp; That was the desired policy and operational outcome.<br>

<dd>&nbsp;<br>

<dd>So the current situation seems to be pretty simple, and is on the
path to getting even simpler: <br>

<dd>If the registry is thick, the registry is authoritative for all data
we see in WHOIS today. <br>

<dd>&nbsp;<br>

<dd>I can’t agree with the conclusion that thick registries are
authoritative for all the data they possess. Being the last holder in a
chain of custody makes them a *convenient* source of access to certain
data elements, but they are not the original, authoritative* (able to be
trusted as being accurate or true; reliable) source. An example:<br>

<dd>&nbsp;<br>

<dd>A registrar creates an agreement with a registrant. That agreement
has an expiration date. The registrar pushes this expiration date to the
registry for publication in an RDDS. The registry has no direct contact
or relationship with the registrant or the agreement between the
registrant and the registrar.<br>

<dd>&nbsp;<br>

<dd>In this and similar indirect data collection situations, the registry
is just the last holder in the chain of custody. The registrar is the
original source of the data, and is thus a more accurate and reliable
source of information.<br>

<dd>&nbsp;<br>

<dd>Scott<br>

<dd>&nbsp;<br>

<dd>* I think it’s very important for us to agree on a definition of
“authoritative”, and that doesn’t mean that we get to make one up. I’ve
included mine (taken from the Oxford English dictionary) here.<br>

<dd>&nbsp;<br><br>

<dd><pre>_______________________________________________</pre><br>

<dd>&nbsp;<br><br>

<dd><pre>gnso-rds-pdp-wg mailing list</pre><br>

<dd>&nbsp;<br><br>
<br><br>

<dd><pre><a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a></pre><br>

<dd>&nbsp;<br><br>

<dd><pre>&nbsp;</pre><br><br>
<br><br>

<dd><pre>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre><br>

<dd>&nbsp;<br>

<dd>&nbsp;<br>

<dd>_______________________________________________<br>

<dd>gnso-rds-pdp-wg mailing list
<dd><a href="mailto:gnso-rds-pdp-wg@icann.org">
gnso-rds-pdp-wg@icann.org</a><br>

<dd>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><br>

</dl></blockquote></body>
</html>