[Gnso-epdp-team] Rec. 19 (time sensitive)
Alan Greenberg
alan.greenberg at mcgill.ca
Tue Jul 28 15:34:01 UTC 2020
You're right Brian.
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.
Alan
At 2020-07-28 11:03 AM, King, Brian wrote:
>Hi guys,
>
>I think you might be off track. This
>recommendation covers the registrar’s
>obligation to publish the full/unredacted data.
>
>(if the data is that of an accredited P/P provider)
>
>Brian J. King​
>Director of Internet Policy and Industry Affairs, IP Group
>
>T +1 443 761 3726​
>clarivate.com​
>D39D107B
>
>
>From: Gnso-epdp-team
><gnso-epdp-team-bounces at icann.org> On Behalf Of Volker Greimann
>Sent: Tuesday, July 28, 2020 10:56 AM
>To: Alan Greenberg <alan.greenberg at mcgill.ca>
>Cc: gnso-epdp-team at icann.org
>Subject: Re: [Gnso-epdp-team] Rec. 19 (time sensitive)
>
>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.
>Best,
>--
>Volker A. Greimann
>General Counsel and Policy Manager
>KEY-SYSTEMS GMBH
>
>T: +49 6894 9396901
>M: +49 6894 9396851
>F: +49 6894 9396851
>W:
><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
>
>Key-Systems GmbH is a company registered at the
>local court of Saarbruecken, Germany with the registration no. HR B 18835
>CEO: Oliver Fries and Robert Birkner
>
>Part of the CentralNic Group PLC (LON: CNIC) a
>company registered in England and Wales with company number 8576358.
>
>
>On Tue, Jul 28, 2020 at 4:35 PM Alan Greenberg
><<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca> wrote:
>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.
>
>Alan
>On July 28, 2020 10:20:38 AM EDT, "James M.
>Bladel" <<mailto:jbladel at godaddy.com>jbladel at godaddy.com> wrote:
>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.
>
>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.
>
>J.
>
>
>From: Gnso-epdp-team
><<mailto:gnso-epdp-team-bounces at icann.org>gnso-epdp-team-bounces at icann.org>
>on behalf of "Kapin, Laureen via Gnso-epdp-team"
><<mailto:gnso-epdp-team at icann.org>gnso-epdp-team at icann.org>
>Reply-To: "Kapin, Laureen" <<mailto:LKAPIN at ftc.gov>LKAPIN at ftc.gov>
>Date: Tuesday, July 28, 2020 at 5:53 AM
>To:
>"<mailto:gnso-epdp-team at icann.org>gnso-epdp-team at icann.org"
><<mailto:gnso-epdp-team at icann.org>gnso-epdp-team at icann.org>
>Subject: Re: [Gnso-epdp-team] Rec. 19 (time sensitive)
>
>Notice: This email is from an external sender.
>
>
>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 accredited privacy/proxy service is used. . .â€)
>
>GAC Note: Should this be “or†or “and/or�
>
>“In the case of a domain name registration
>where an affiliated ‘or’ accredited privacy proxy service is used?â€
>
>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.
>
>
>Kind regards,
>
>Laureen Kapin
>Counsel for International Consumer Protection
>Federal Trade Commission
>(202) 326-3237
>
>From: Gnso-epdp-team
><<mailto:gnso-epdp-team-bounces at icann.org>gnso-epdp-team-bounces at icann.org>
>On Behalf Of Kapin, Laureen via Gnso-epdp-team
>Sent: Monday, July 27, 2020 3:47 PM
>To: <mailto:gnso-epdp-team at icann.org>gnso-epdp-team at icann.org
>Subject: [Gnso-epdp-team] FW: Rec. 19 (time sensitive)
>
>Hi folks,
>
> 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.
>
> Proposed Revised text of Rec. 19:
>
>Recommendation #19 Display of information of
>affiliated and accredited privacy/proxy providers
>
>19.1 In the case of a domain name
>registration where an affiliated and 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
>applicable privacy/proxy service in response to
>an RDDS query. The full privacy/proxy RDDS data
>may also include a pseudonymized email.
>
>Implementation notes:
>19.2 Once ICANN org has implemented a
>privacy/proxy service accreditation program,
>this Recommendation 19 once in effect will
>replaces or otherwise supersedes EPDP phase 1 recommendation #14.
>
>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
>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.
>
>
>Kind regards,
>
>Laureen Kapin
>Counsel for International Consumer Protection
>Federal Trade Commission
>(202) 326-3237
>
>From: Kapin, Laureen
>Sent: Monday, July 27, 2020 10:12 AM
>To: James M. Bladel
><<mailto:jbladel at godaddy.com>jbladel at godaddy.com>;
><mailto:swyld at tucows.com>swyld at tucows.com;
>'<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca'
><<mailto:alan.greenberg at mcgill.ca>alan.greenberg at mcgill.ca>;
>King, Brian
>(<mailto:Brian.King at markmonitor.com>Brian.King at markmonitor.com)
><<mailto:Brian.King at markmonitor.com>Brian.King at markmonitor.com>;
><mailto:Christopher.Lewis-Evans at nca.gov.uk>Christopher.Lewis-Evans at nca.gov.uk;
>Anderson, Marc
>(<mailto:mcanderson at verisign.com>mcanderson at verisign.com)
><<mailto:mcanderson at verisign.com>mcanderson at verisign.com>
>Cc: Marika Konings
><<mailto:marika.konings at icann.org>marika.konings at icann.org>;
>Rafik Dammak <<mailto:rafik.dammak at gmail.com>rafik.dammak at gmail.com>
>Subject: Rec. 19 (time sensitive)
>
>Hi folks,
>
> 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:
>
>The inconsistency between the title of the Rec.
>and the content (title references
>“affiliated†and content references “accreditedâ€)
>The open question of its applicability to both
>affiliated and accredited Privacy Proxy Service Providers
>The indefinite “this†reference
>
>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
>the Category 2 comment by the GAC, joined by
>ALAC and BC and objected to by the Registrars and Registries;
>the original Rec. 19 text
>
>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!
>
>
>
>Category 2 proposed changes:
>
>
>131. GAC / BC /ALAC
>Rec. 19 Privacy/Proxy
>
>2041-42
>
>Display of information of affiliated privacy / proxy providers
>
>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?
>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.
>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).
>
>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.
>
>RySG: Do Not Support
>
>
>Current language Rec. 19:
>
>
>Proposed Revised text of Rec. 19:
>
>
>Recommendation #19 Display of information of
>affiliated and accredited privacy/proxy providers
>
>19.1 In the case of a domain name
>registration where an affiliated and 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 applicable privacy/proxy service
>in response to an RDDS query. The full
>privacy/proxy RDDS data may also include a pseudonymized email.
>
>Implementation notes:
>19.2 Once ICANN org has implemented a
>privacy/proxy service accreditation program,
>this Recommendation 19 once in effect will
>replaces or otherwise supersedes EPDP phase 1 recommendation #14.
>
>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
>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.
>
>
>Kind regards,
>
>Laureen Kapin
>Counsel for International Consumer Protection
>Federal Trade Commission
>(202) 326-3237
>
>
>
>--
>Sent from my Android device with K-9 Mail. Please excuse my brevity.
>_______________________________________________
>Gnso-epdp-team mailing list
><mailto:Gnso-epdp-team at icann.org>Gnso-epdp-team at icann.org
>https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>_______________________________________________
>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://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)
>and the website Terms of Service
>(<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).
>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.
>
>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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200728/d20ead58/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 23bc71f.jpg
Type: image/jpeg
Size: 9073 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200728/d20ead58/23bc71f-0001.jpg>
More information about the Gnso-epdp-team
mailing list