<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>
<body>
You're right Brian. <br><br>
The intent was that if (now) the registrant of record is the registrar's
P/P Affiliate, the full entry (or the Affiiliate) be in the public WHOIS
or (later) if the registrar sees that the registrant of record is on the
list of Accredited P/P services, the full entry similarly be presented in
the public WHOIS.<br><br>
Alan<br><br>
<br>
At 2020-07-28 11:03 AM, King, Brian wrote:<br>
<blockquote type="cite" class="cite" cite="">Hi guys, <br>
<br>
I think you might be off track. This recommendation covers the
registrar’s obligation to publish the full/unredacted data. <br>
<br>
(if the data is that of an accredited P/P provider)<br>
<br>
<b>Brian J. King</b>​<br>
Director of Internet Policy and Industry Affairs, IP Group<br><br>
T +1 443 761 3726​<br>
<u>clarivate.com</u>​<br>
<img src="cid:.0" width="341" height="31" alt="D39D107B"><br>
<br>
<b>From:</b> Gnso-epdp-team <gnso-epdp-team-bounces@icann.org>
<b>On Behalf Of </b>Volker Greimann<br>
<b>Sent:</b> Tuesday, July 28, 2020 10:56 AM<br>
<b>To:</b> Alan Greenberg <alan.greenberg@mcgill.ca><br>
<b>Cc:</b> gnso-epdp-team@icann.org<br>
<b>Subject:</b> Re: [Gnso-epdp-team] Rec. 19 (time sensitive)<br>
<br>
I agree with Alan here. Let's not turn third party obligations into
registrar obligations. If something is an obligation of a p/p service
provider, it does not need to also be a registrar obligation.<br>
Best,<br>
-- <br>
Volker A. Greimann<br>
General Counsel and Policy Manager<br>
<b>KEY-SYSTEMS GMBH</b><br><br>
T: +49 6894 9396901<br>
M: +49 6894 9396851<br>
F: +49 6894 9396851<br>
W:
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net_&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=wtvZmh2-7tcL4d0sGWsGFQjmsePUV-rdny80W6UL9i8&s=u9rWZbw_y0u0IzSYnZVTh1ujcqrkYYijyDjTKbfbft4&e=">
www.key-systems.net</a><br><br>
Key-Systems GmbH is a company registered at the local court of
Saarbruecken, Germany with the registration no. HR B 18835<br>
CEO: Oliver Fries and Robert Birkner<br><br>
Part of the CentralNic Group PLC (LON: CNIC) a company registered in
England and Wales with company number 8576358.<br>
<br>
<br>
On Tue, Jul 28, 2020 at 4:35 PM Alan Greenberg
<<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
> wrote:<br>
<dl>
<dd>My understanding is that under the new P/P policy, an accredited P/P
service has an agreement with ICANN and it is THEIR contractual
obligation, not the registrar. The meaningfulness of an affiliated P/P
service disappears once the new accreditation process is
operational.<br><br>
<dd>Alan<br>
<dd>On July 28, 2020 10:20:38 AM EDT, "James M. Bladel"
<<a href="mailto:jbladel@godaddy.com">jbladel@godaddy.com</a>>
wrote:<br>
<dl>
<dd>If they aren’t “affiliated†then we can’t accept any
contractual obligations on their behalf. And if they aren’t
“accredited†then they shouldn’t be offering privacy
services. So leaving the sentence with “and†ensures that we
are both authorized (accredited) and capable (accredited) of meeting the
requirement.<br>
<dd> <br>
<dd>Note: I can’t help feeling like we are polishing the chrome
on the Titanic here. Privacy services are becoming less relevant
(and less attractive to customers) as the year progresses.<br>
<dd> <br>
<dd>J.<br>
<dd> <br>
<dd> <br>
<dd>From: </b>Gnso-epdp-team
<<a href="mailto:gnso-epdp-team-bounces@icann.org">
gnso-epdp-team-bounces@icann.org</a>> on behalf of "Kapin,
Laureen via Gnso-epdp-team"
<<a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a>
><br>
<dd>Reply-To: </b>"Kapin, Laureen"
<<a href="mailto:LKAPIN@ftc.gov">LKAPIN@ftc.gov</a>><br>
<dd>Date: </b>Tuesday, July 28, 2020 at 5:53 AM<br>
<dd>To:
</b>"<a href="mailto:gnso-epdp-team@icann.org">
gnso-epdp-team@icann.org</a>"
<<a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a>
><br>
<dd>Subject: </b>Re: [Gnso-epdp-team] Rec. 19 (time sensitive)<br>
<dd> <br>
<dd>Notice: This email is from an external sender. <br><br>
<dd> <br>
<dd>I welcome input from my Registrar colleagues on this issue re: the
first sentence of Rec. 19.1 (“In the case of a domain name
registration where an affiliated and </i>accredited privacy/proxy service
is used. . .â€)<br>
<dd> <br>
<dd>GAC Note: Should this be “orâ€</i> or “and/orâ€</i>?<br>
</b>
<dd> <br>
<dd>“In the case of a domain name registration where an affiliated
‘or’ accredited privacy proxy service is used?â€<br>
</b>
<dd> <br>
<dd>My understanding is that no P/P providers will actually be
“accredited†until the implementation of the PPSAI Policy
Recommendations. Having suggested this revision, I want to make
sure we’ve gotten it right. <br>
</b>
<dd> <br>
<dd> <br>
<dd>Kind regards,<br>
<dd> <br>
<dd>Laureen Kapin<br>
<dd>Counsel for International Consumer Protection<br>
<dd>Federal Trade Commission<br>
<dd>(202) 326-3237 <br>
<dd> <br>
<dd>From:</b> Gnso-epdp-team
<<a href="mailto:gnso-epdp-team-bounces@icann.org">
gnso-epdp-team-bounces@icann.org</a>> On Behalf Of </b>Kapin, Laureen
via Gnso-epdp-team<br>
<dd>Sent:</b> Monday, July 27, 2020 3:47 PM<br>
<dd>To:</b>
<a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a><br>
<dd>Subject:</b> [Gnso-epdp-team] FW: Rec. 19 (time sensitive)<br>
<dd> <br>
<dd>Hi folks,<br>
<dd> <br>
<dd> I’m forwarding proposed changes to Rec. 19 (Privacy Proxy)
that the Rgr’s, Rgy’s (deferring to Rgr’s) and GAC have agreed
to. As you’ll see below, we think these edits will improve the
clarity of the Recommendation 19. For convenience, more context is
provided in this email chain and I’m also including the revised text
(changes highlighted) here below. I’m happy to answer any
questions.<br>
<dd> <br>
<dd> Proposed Revised text of Rec. 19:<br>
</b>
<dd> <br>
<dd>Recommendation #19 Display of information of affiliated and
accredited</i> privacy/proxy providers<br>
<dd> <br>
<dd>19.1 In the case of a domain name registration
where an affiliated and </i>accredited privacy/proxy service is used,
e.g., where data associated with a natural person is masked, Registrar
(and Registry, where applicable) MUST include the full RDDS data of the
accredited</s> applicable </i>privacy/proxy service in response to an
RDDS query. The full privacy/proxy RDDS data may also include a
pseudonymized email.<br>
<dd> <br>
<dd>Implementation notes: <br>
<dd>19.2 Once ICANN org has implemented a privacy/proxy service
accreditation program, this R</i>ecommendation 19 </i>once in effect will
</i>replaces</s> or otherwise supersedes</s> EPDP phase 1 recommendation
#14.<br>
<dd> <br>
<dd>19.3 The intent of this recommendation is to provide clear
instruction to registrars (and registries where applicable) that where a
domain registration is done via an affiliated or </i>accredited
privacy/proxy provider, that data MUST NOT also be redacted. The working
group is intending that domain registration data should MUST NOT be both
redacted and privacy/proxied.<br>
<dd> <br>
<dd> <br>
<dd>Kind regards,<br>
<dd> <br>
<dd>Laureen Kapin<br>
<dd>Counsel for International Consumer Protection<br>
<dd>Federal Trade Commission<br>
<dd>(202) 326-3237 <br>
<dd> <br>
<dd>From:</b> Kapin, Laureen <br>
<dd>Sent:</b> Monday, July 27, 2020 10:12 AM<br>
<dd>To:</b> James M. Bladel
<<a href="mailto:jbladel@godaddy.com">jbladel@godaddy.com</a>>;
<a href="mailto:swyld@tucows.com">swyld@tucows.com</a>;
'<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>'
<<a href="mailto:alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>
>; King, Brian
(<a href="mailto:Brian.King@markmonitor.com">
Brian.King@markmonitor.com</a>)
<<a href="mailto:Brian.King@markmonitor.com">
Brian.King@markmonitor.com</a>>;
<a href="mailto:Christopher.Lewis-Evans@nca.gov.uk">
Christopher.Lewis-Evans@nca.gov.uk</a>; Anderson, Marc
(<a href="mailto:mcanderson@verisign.com">mcanderson@verisign.com</a>)
<<a href="mailto:mcanderson@verisign.com">mcanderson@verisign.com</a>
><br>
<dd>Cc:</b> Marika Konings
<<a href="mailto:marika.konings@icann.org">marika.konings@icann.org</a>
>; Rafik Dammak
<<a href="mailto:rafik.dammak@gmail.com">rafik.dammak@gmail.com</a>
><br>
<dd>Subject:</b> Rec. 19 (time sensitive)<br>
<dd> <br>
<dd>Hi folks,<br>
<dd> <br>
<dd> Rec. 19 seems like something we may be able to clarify and
agree upon prior to submitting our consensus designations. I think
the current wording of Rec. 19 is not clear in these ways:<br>
<dd>
<dd>The inconsistency between the title of the Rec. and the content
(title references “affiliated†and content references
“accreditedâ€)
<dd>The open question of its applicability to both affiliated and
accredited Privacy Proxy Service Providers
<dd>The indefinite “this†reference
<dd> <br>
<dd>This seems like something we should sort out before going to final
publication. To that end, I’m proposing some clarifying revisions
below. For context, I also include
<dd>the Category 2 comment by the GAC, joined by ALAC and BC and objected
to by the Registrars and Registries;
<dd>the original Rec. 19 text
<dd> <br>
<dd>I welcome your input and hope we can resolve and improve this
recommendation. Doing so will affect the GAC’s Consensus
designations, so please let us know whether this is something we can
resolve sooner rather than later. Thanks!<br>
<dd> <br>
<dd> <br>
<dd> <br>
<dd>Category 2 proposed changes:<br>
</b>
<dd> <br><br>
<dd>131. GAC / BC /ALAC<br>
<dd>Rec. 19 Privacy/Proxy<br>
<dd> <br>
<dd>2041-42<br>
<dd> <br>
<dd>Display of information of affiliated privacy / proxy providers<br>
<dd> <br>
<dd>Clarify ambiguity -- the phrase “once in effect†seems unclear
and unnecessary. Also, does this language mean that Rec. 19 only
goes into effect once the PPSAI implementation is complete? <br>
<dd>Delete “once in effect†from the following: “Once ICANN org has
implemented a privacy/proxy service accreditation program, this
recommendation ‘once in effect’ replaces or otherwise supersedes EPDP
phase 1 recommendation #14.†Also clarify timing of when this
Rec. comes into play.<br>
<dd>RrSG: Disagree with change. Recommendation 19 cannot possibly come
into effect until after PPSAI is live, as Rec 19 relies on the existence
of accredited P/P providers (which will not exist until after PPSAI is
live). <br>
<dd> <br>
<dd>ALAC: Title of Rec #19 still refers to AFFILIATED P/P providers, but
the text of the first paragraph refers to accredited P/P services.
Surely the intent of this Rec if to cover Affiliated P/P services now and
Accredited ones once they exist.<br>
<dd> <br>
<dd>RySG: Do Not Support<br>
<dd> <br>
<dd> <br>
<dd>Current language Rec. 19:<br>
</b>
<dd> <br>
<dd> <br>
<dd>Proposed Revised text of Rec. 19:<br>
</b>
<dd> <br>
<dd> <br>
<dd>Recommendation #19 Display of information of affiliated and
accredited</i> privacy/proxy providers<br>
<dd> <br>
<dd>19.1 In the case of a domain name registration
where an affiliated and </i>accredited privacy/proxy service is used,
e.g., where data associated with a natural person is masked,Registrar
(and Registry, where applicable) MUST include the full RDDS data of the
accredited</s> applicable </i>privacy/proxy service in response to an
RDDS query. The full privacy/proxy RDDS data may also include a
pseudonymized email.<br>
<dd> <br>
<dd>Implementation notes: <br>
<dd>19.2 Once ICANN org has implemented a privacy/proxy service
accreditation program, this R</i>ecommendation 19 </i>once in effect will
</i>replaces</s> or otherwise supersedes</s> EPDP phase 1 recommendation
#14.<br>
<dd> <br>
<dd>19.3 The intent of this recommendation is to provide clear
instruction to registrars (and registries where applicable) that where a
domain registration is done via an affiliated or </i>accredited
privacy/proxy provider, that data MUST NOT also be redacted. The working
group is intending that domain registration data should MUST NOT be both
redacted and privacy/proxied.<br>
<dd> <br>
<dd> <br>
<dd>Kind regards,<br>
<dd> <br>
<dd>Laureen Kapin<br>
<dd>Counsel for International Consumer Protection<br>
<dd>Federal Trade Commission<br>
<dd>(202) 326-3237 <br>
<dd> <br><br>
</dl><br>
<dd>-- <br>
<dd>Sent from my Android device with K-9 Mail. Please excuse my
brevity.<br>
<dd>_______________________________________________<br>
<dd>Gnso-epdp-team mailing list<br>
<dd><a href="mailto:Gnso-epdp-team@icann.org">Gnso-epdp-team@icann.org</a>
<br>
<dd>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><br>
<dd>_______________________________________________<br>
<dd>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
(<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=wtvZmh2-7tcL4d0sGWsGFQjmsePUV-rdny80W6UL9i8&s=v2y8gnWMaWhUOGFEBoA8yL7Sx3-4WSOlUfxXwGLrMac&e=">
https://www.icann.org/privacy/policy</a>) and the website Terms of
Service
(<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=wtvZmh2-7tcL4d0sGWsGFQjmsePUV-rdny80W6UL9i8&s=uX0j1TiSE6yqNrxLpT1A0kAri-O5mGVstpllRA2vuxc&e=">
https://www.icann.org/privacy/tos</a>). 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.<br><br>
</dl>Confidentiality note: This e-mail may contain confidential
information from Clarivate. If you are not the intended recipient, be
aware that any disclosure, copying, distribution or use of the contents
of this e-mail is strictly prohibited. If you have received this e-mail
in error, please delete this e-mail and notify the sender immediately.
<br><br>
</blockquote></body>
</html>