Re: [Gnso-epdp-team] Rec. 19 (time sensitive)
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 <gnso-epdp-team-bounces@icann.org> on behalf of "Kapin, Laureen via Gnso-epdp-team" <gnso-epdp-team@icann.org> Reply-To: "Kapin, Laureen" <LKAPIN@ftc.gov> Date: Tuesday, July 28, 2020 at 5:53 AM To: "gnso-epdp-team@icann.org" <gnso-epdp-team@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 <gnso-epdp-team-bounces@icann.org> On Behalf Of Kapin, Laureen via Gnso-epdp-team Sent: Monday, July 27, 2020 3:47 PM To: gnso-epdp-team@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 <jbladel@godaddy.com>; swyld@tucows.com; 'alan.greenberg@mcgill.ca' <alan.greenberg@mcgill.ca>; King, Brian (Brian.King@markmonitor.com) <Brian.King@markmonitor.com>; Christopher.Lewis-Evans@nca.gov.uk; Anderson, Marc (mcanderson@verisign.com) <mcanderson@verisign.com> Cc: Marika Konings <marika.konings@icann.org>; Rafik Dammak <rafik.dammak@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: 1. The inconsistency between the title of the Rec. and the content (title references “affiliated” and content references “accredited”) 2. The open question of its applicability to both affiliated and accredited Privacy Proxy Service Providers 3. 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 1. the Category 2 comment by the GAC, joined by ALAC and BC and objected to by the Registrars and Registries; 2. 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: [cid:image001.png@01D664AF.95CCA700] 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
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" <jbladel@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 <gnso-epdp-team-bounces@icann.org> on behalf of "Kapin, Laureen via Gnso-epdp-team" <gnso-epdp-team@icann.org> Reply-To: "Kapin, Laureen" <LKAPIN@ftc.gov> Date: Tuesday, July 28, 2020 at 5:53 AM To: "gnso-epdp-team@icann.org" <gnso-epdp-team@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 <gnso-epdp-team-bounces@icann.org> On Behalf Of Kapin, Laureen via Gnso-epdp-team Sent: Monday, July 27, 2020 3:47 PM To: gnso-epdp-team@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 <jbladel@godaddy.com>; swyld@tucows.com; 'alan.greenberg@mcgill.ca' <alan.greenberg@mcgill.ca>; King, Brian (Brian.King@markmonitor.com) <Brian.King@markmonitor.com>; Christopher.Lewis-Evans@nca.gov.uk; Anderson, Marc (mcanderson@verisign.com) <mcanderson@verisign.com> Cc: Marika Konings <marika.konings@icann.org>; Rafik Dammak <rafik.dammak@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:
1. The inconsistency between the title of the Rec. and the content (title references “affiliated” and content references “accredited”) 2. The open question of its applicability to both affiliated and accredited Privacy Proxy Service Providers 3. 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
1. the Category 2 comment by the GAC, joined by ALAC and BC and objected to by the Registrars and Registries; 2. 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:
[cid:image001.png@01D664AF.95CCA700]
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.
Hey James, The “and” construction effectively kills this until PPSAI is finished, since it would require the P/P provider to be both affiliated and also accredited (which won’t be possible until PPSAI is finished and P/P providers are actually accredited, so effectively close to never). Two ways to solve this are: 1. Change “and” to “or”, which makes this provision effective now for affiliated P/P providers (what we said in Phase 1), and also effective when P/P providers can actually get accredited. 2. Strike “affiliated and”, which makes this provision effective when P/P providers can actually get accredited. This in conjunction with the Phase 1 rec would cover both current and future state. Either one would be acceptable. Plain “and” doesn’t work. Thanks. 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@icann.org> On Behalf Of Alan Greenberg Sent: Tuesday, July 28, 2020 10:35 AM To: gnso-epdp-team@icann.org; James M. Bladel <jbladel@godaddy.com>; Kapin, Laureen <LKAPIN@ftc.gov>; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Rec. 19 (time sensitive) 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" <jbladel@godaddy.com<mailto:jbladel@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 <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Kapin, Laureen via Gnso-epdp-team" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Reply-To: "Kapin, Laureen" <LKAPIN@ftc.gov<mailto:LKAPIN@ftc.gov>> Date: Tuesday, July 28, 2020 at 5:53 AM To: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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 <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Kapin, Laureen via Gnso-epdp-team Sent: Monday, July 27, 2020 3:47 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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 <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; swyld@tucows.com<mailto:swyld@tucows.com>; 'alan.greenberg@mcgill.ca' <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>>; King, Brian (Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>) <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>>; Christopher.Lewis-Evans@nca.gov.uk<mailto:Christopher.Lewis-Evans@nca.gov.uk>; Anderson, Marc (mcanderson@verisign.com<mailto:mcanderson@verisign.com>) <mcanderson@verisign.com<mailto:mcanderson@verisign.com>> Cc: Marika Konings <marika.konings@icann.org<mailto:marika.konings@icann.org>>; Rafik Dammak <rafik.dammak@gmail.com<mailto:rafik.dammak@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: 1. The inconsistency between the title of the Rec. and the content (title references “affiliated” and content references “accredited”) 2. The open question of its applicability to both affiliated and accredited Privacy Proxy Service Providers 3. 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 1. the Category 2 comment by the GAC, joined by ALAC and BC and objected to by the Registrars and Registries; 2. 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: [cid:image001.png@01D664AF.95CCA700] 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. 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.
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: 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 <alan.greenberg@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" <jbladel@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 <gnso-epdp-team-bounces@icann.org> on behalf of "Kapin, Laureen via Gnso-epdp-team" <gnso-epdp-team@icann.org> *Reply-To: *"Kapin, Laureen" <LKAPIN@ftc.gov> *Date: *Tuesday, July 28, 2020 at 5:53 AM *To: *"gnso-epdp-team@icann.org" <gnso-epdp-team@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 <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Kapin, Laureen via Gnso-epdp-team *Sent:* Monday, July 27, 2020 3:47 PM *To:* gnso-epdp-team@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 *R*ecommendation *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 <jbladel@godaddy.com>; swyld@tucows.com; ' alan.greenberg@mcgill.ca' <alan.greenberg@mcgill.ca>; King, Brian ( Brian.King@markmonitor.com) <Brian.King@markmonitor.com>; Christopher.Lewis-Evans@nca.gov.uk; Anderson, Marc ( mcanderson@verisign.com) <mcanderson@verisign.com> *Cc:* Marika Konings <marika.konings@icann.org>; Rafik Dammak < rafik.dammak@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:
1. The inconsistency between the title of the Rec. and the content (title references “affiliated” and content references “accredited”) 2. The open question of its applicability to both affiliated and accredited Privacy Proxy Service Providers 3. 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
1. the Category 2 comment by the GAC, joined by ALAC and BC and objected to by the Registrars and Registries; 2. 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 *R*ecommendation *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 Gnso-epdp-team@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://www.icann.org/privacy/policy) and the website Terms of Service (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.
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@icann.org> On Behalf Of Volker Greimann Sent: Tuesday, July 28, 2020 10:56 AM To: Alan Greenberg <alan.greenberg@mcgill.ca> Cc: gnso-epdp-team@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: www.key-systems.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net_&d...> 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 <alan.greenberg@mcgill.ca<mailto:alan.greenberg@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" <jbladel@godaddy.com<mailto:jbladel@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 <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Kapin, Laureen via Gnso-epdp-team" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Reply-To: "Kapin, Laureen" <LKAPIN@ftc.gov<mailto:LKAPIN@ftc.gov>> Date: Tuesday, July 28, 2020 at 5:53 AM To: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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 <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Kapin, Laureen via Gnso-epdp-team Sent: Monday, July 27, 2020 3:47 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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 <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; swyld@tucows.com<mailto:swyld@tucows.com>; 'alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>' <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>>; King, Brian (Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>) <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>>; Christopher.Lewis-Evans@nca.gov.uk<mailto:Christopher.Lewis-Evans@nca.gov.uk>; Anderson, Marc (mcanderson@verisign.com<mailto:mcanderson@verisign.com>) <mcanderson@verisign.com<mailto:mcanderson@verisign.com>> Cc: Marika Konings <marika.konings@icann.org<mailto:marika.konings@icann.org>>; Rafik Dammak <rafik.dammak@gmail.com<mailto:rafik.dammak@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: 1. The inconsistency between the title of the Rec. and the content (title references “affiliated” and content references “accredited”) 2. The open question of its applicability to both affiliated and accredited Privacy Proxy Service Providers 3. 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 1. the Category 2 comment by the GAC, joined by ALAC and BC and objected to by the Registrars and Registries; 2. 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 Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=wtvZmh2-7tcL4d0sGWsGFQjmsePUV-rdny80W6UL9i8&s=Lkfc1tQHhXbvOotDwpTUK8OBgdkCtkRAiVC9BiM7iRA&e=> _______________________________________________ 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://www.icann.org/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=>) and the website Terms of Service (https://www.icann.org/privacy/tos<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=>). 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.
D/n intend to raise a ruckus here – just to make sure we’ve got this right for as long as PP services are around. Rec. 19 says: “Registrar (and Registry, where applicable) MUST include the full RDDS data of the accredited privacy/proxy service in response to an RDDS query.” So this is an obligation of the Registrar (and if applicable, the Registry) no? Or am I missing something? Kind regards, Laureen Kapin Counsel for International Consumer Protection Federal Trade Commission (202) 326-3237 From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of King, Brian via Gnso-epdp-team Sent: Tuesday, July 28, 2020 11:03 AM To: Volker Greimann <vgreimann@key-systems.net>; Alan Greenberg <alan.greenberg@mcgill.ca> Cc: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Rec. 19 (time sensitive) 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@icann.org> On Behalf Of Volker Greimann Sent: Tuesday, July 28, 2020 10:56 AM To: Alan Greenberg <alan.greenberg@mcgill.ca> Cc: gnso-epdp-team@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: www.key-systems.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net_&d...> 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 <alan.greenberg@mcgill.ca<mailto:alan.greenberg@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" <jbladel@godaddy.com<mailto:jbladel@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 <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Kapin, Laureen via Gnso-epdp-team" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Reply-To: "Kapin, Laureen" <LKAPIN@ftc.gov<mailto:LKAPIN@ftc.gov>> Date: Tuesday, July 28, 2020 at 5:53 AM To: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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 <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Kapin, Laureen via Gnso-epdp-team Sent: Monday, July 27, 2020 3:47 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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 <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; swyld@tucows.com<mailto:swyld@tucows.com>; 'alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>' <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>>; King, Brian (Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>) <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>>; Christopher.Lewis-Evans@nca.gov.uk<mailto:Christopher.Lewis-Evans@nca.gov.uk>; Anderson, Marc (mcanderson@verisign.com<mailto:mcanderson@verisign.com>) <mcanderson@verisign.com<mailto:mcanderson@verisign.com>> Cc: Marika Konings <marika.konings@icann.org<mailto:marika.konings@icann.org>>; Rafik Dammak <rafik.dammak@gmail.com<mailto:rafik.dammak@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: 1. The inconsistency between the title of the Rec. and the content (title references “affiliated” and content references “accredited”) 2. The open question of its applicability to both affiliated and accredited Privacy Proxy Service Providers 3. 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 1. the Category 2 comment by the GAC, joined by ALAC and BC and objected to by the Registrars and Registries; 2. 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 Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=wtvZmh2-7tcL4d0sGWsGFQjmsePUV-rdny80W6UL9i8&s=Lkfc1tQHhXbvOotDwpTUK8OBgdkCtkRAiVC9BiM7iRA&e=> _______________________________________________ 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://www.icann.org/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=>) and the website Terms of Service (https://www.icann.org/privacy/tos<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=>). 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.
hi all, thanks for this discussion, we are already reaching the deadline to send input for consensus designation and we need to make clear what the last version of the language to be added in the report for: - recommendation #7 - recommendation #19 so I would like to confirm the positions of RrSG and RySG representatives in particular regarding those 2 recommendations . That will help groups for their consensus designation input and for editing the language in the final report. Best, Rafik Le mer. 29 juil. 2020 à 00:35, Kapin, Laureen via Gnso-epdp-team < gnso-epdp-team@icann.org> a écrit :
D/n intend to raise a ruckus here – just to make sure we’ve got this right for as long as PP services are around. Rec. 19 says:
“Registrar (and Registry, where applicable) MUST include the full RDDS data of the accredited privacy/proxy service in response to an RDDS query.”
So this is an obligation of the Registrar (and if applicable, the Registry) no? Or am I missing something?
Kind regards,
Laureen Kapin
Counsel for International Consumer Protection
Federal Trade Commission
(202) 326-3237
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *King, Brian via Gnso-epdp-team *Sent:* Tuesday, July 28, 2020 11:03 AM *To:* Volker Greimann <vgreimann@key-systems.net>; Alan Greenberg < alan.greenberg@mcgill.ca> *Cc:* gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Rec. 19 (time sensitive)
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 <http://clarivate.com>*
[image: D39D107B]
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Volker Greimann *Sent:* Tuesday, July 28, 2020 10:56 AM *To:* Alan Greenberg <alan.greenberg@mcgill.ca> *Cc:* gnso-epdp-team@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: www.key-systems.net <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net_&d...>
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 <alan.greenberg@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" <jbladel@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 <gnso-epdp-team-bounces@icann.org> on behalf of "Kapin, Laureen via Gnso-epdp-team" <gnso-epdp-team@icann.org> *Reply-To: *"Kapin, Laureen" <LKAPIN@ftc.gov> *Date: *Tuesday, July 28, 2020 at 5:53 AM *To: *"gnso-epdp-team@icann.org" <gnso-epdp-team@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 <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Kapin, Laureen via Gnso-epdp-team *Sent:* Monday, July 27, 2020 3:47 PM *To:* gnso-epdp-team@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 *R*ecommendation *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 <jbladel@godaddy.com>; swyld@tucows.com; ' alan.greenberg@mcgill.ca' <alan.greenberg@mcgill.ca>; King, Brian ( Brian.King@markmonitor.com) <Brian.King@markmonitor.com>; Christopher.Lewis-Evans@nca.gov.uk; Anderson, Marc ( mcanderson@verisign.com) <mcanderson@verisign.com> *Cc:* Marika Konings <marika.konings@icann.org>; Rafik Dammak < rafik.dammak@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:
1. The inconsistency between the title of the Rec. and the content (title references “affiliated” and content references “accredited”)
2. The open question of its applicability to both affiliated and accredited Privacy Proxy Service Providers
3. 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
1. the Category 2 comment by the GAC, joined by ALAC and BC and objected to by the Registrars and Registries;
2. 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 *R*ecommendation *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 Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...> _______________________________________________ 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://www.icann.org/privacy/policy <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). 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. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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://www.icann.org/privacy/policy) and the website Terms of Service (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.
Might we come to agreement on this issue so that we can achieve consensus? How about if we use “and/or”? Consensus designations are due today. 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 <gnso-epdp-team-bounces@icann.org> On Behalf Of Rafik Dammak Sent: Wednesday, July 29, 2020 2:37 AM To: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Rec. 19 (time sensitive) hi all, thanks for this discussion, we are already reaching the deadline to send input for consensus designation and we need to make clear what the last version of the language to be added in the report for: - recommendation #7 - recommendation #19 so I would like to confirm the positions of RrSG and RySG representatives in particular regarding those 2 recommendations . That will help groups for their consensus designation input and for editing the language in the final report. Best, Rafik Le mer. 29 juil. 2020 à 00:35, Kapin, Laureen via Gnso-epdp-team <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> a écrit : D/n intend to raise a ruckus here – just to make sure we’ve got this right for as long as PP services are around. Rec. 19 says: “Registrar (and Registry, where applicable) MUST include the full RDDS data of the accredited privacy/proxy service in response to an RDDS query.” So this is an obligation of the Registrar (and if applicable, the Registry) no? Or am I missing something? Kind regards, Laureen Kapin Counsel for International Consumer Protection Federal Trade Commission (202) 326-3237 From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of King, Brian via Gnso-epdp-team Sent: Tuesday, July 28, 2020 11:03 AM To: Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>>; Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Rec. 19 (time sensitive) 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<http://clarivate.com> [D39D107B] From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Volker Greimann Sent: Tuesday, July 28, 2020 10:56 AM To: Alan Greenberg <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>> Cc: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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: www.key-systems.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net_&d...> 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 <alan.greenberg@mcgill.ca<mailto:alan.greenberg@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" <jbladel@godaddy.com<mailto:jbladel@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 <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Kapin, Laureen via Gnso-epdp-team" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>> Reply-To: "Kapin, Laureen" <LKAPIN@ftc.gov<mailto:LKAPIN@ftc.gov>> Date: Tuesday, July 28, 2020 at 5:53 AM To: "gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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 <gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Kapin, Laureen via Gnso-epdp-team Sent: Monday, July 27, 2020 3:47 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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 <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>; swyld@tucows.com<mailto:swyld@tucows.com>; 'alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>' <alan.greenberg@mcgill.ca<mailto:alan.greenberg@mcgill.ca>>; King, Brian (Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>) <Brian.King@markmonitor.com<mailto:Brian.King@markmonitor.com>>; Christopher.Lewis-Evans@nca.gov.uk<mailto:Christopher.Lewis-Evans@nca.gov.uk>; Anderson, Marc (mcanderson@verisign.com<mailto:mcanderson@verisign.com>) <mcanderson@verisign.com<mailto:mcanderson@verisign.com>> Cc: Marika Konings <marika.konings@icann.org<mailto:marika.konings@icann.org>>; Rafik Dammak <rafik.dammak@gmail.com<mailto:rafik.dammak@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: 1. The inconsistency between the title of the Rec. and the content (title references “affiliated” and content references “accredited”) 2. The open question of its applicability to both affiliated and accredited Privacy Proxy Service Providers 3. 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 1. the Category 2 comment by the GAC, joined by ALAC and BC and objected to by the Registrars and Registries; 2. 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 Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMFaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=wtvZmh2-7tcL4d0sGWsGFQjmsePUV-rdny80W6UL9i8&s=Lkfc1tQHhXbvOotDwpTUK8OBgdkCtkRAiVC9BiM7iRA&e=> _______________________________________________ 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://www.icann.org/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=>) and the website Terms of Service (https://www.icann.org/privacy/tos<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=>). 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. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@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://www.icann.org/privacy/policy) and the website Terms of Service (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.
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@icann.org> On Behalf Of Volker Greimann Sent: Tuesday, July 28, 2020 10:56 AM To: Alan Greenberg <alan.greenberg@mcgill.ca> Cc: gnso-epdp-team@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@mcgill.ca>alan.greenberg@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@godaddy.com>jbladel@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@icann.org>gnso-epdp-team-bounces@icann.org> on behalf of "Kapin, Laureen via Gnso-epdp-team" <<mailto:gnso-epdp-team@icann.org>gnso-epdp-team@icann.org> Reply-To: "Kapin, Laureen" <<mailto:LKAPIN@ftc.gov>LKAPIN@ftc.gov> Date: Tuesday, July 28, 2020 at 5:53 AM To: "<mailto:gnso-epdp-team@icann.org>gnso-epdp-team@icann.org" <<mailto:gnso-epdp-team@icann.org>gnso-epdp-team@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@icann.org>gnso-epdp-team-bounces@icann.org> On Behalf Of Kapin, Laureen via Gnso-epdp-team Sent: Monday, July 27, 2020 3:47 PM To: <mailto:gnso-epdp-team@icann.org>gnso-epdp-team@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@godaddy.com>jbladel@godaddy.com>; <mailto:swyld@tucows.com>swyld@tucows.com; '<mailto:alan.greenberg@mcgill.ca>alan.greenberg@mcgill.ca' <<mailto:alan.greenberg@mcgill.ca>alan.greenberg@mcgill.ca>; King, Brian (<mailto:Brian.King@markmonitor.com>Brian.King@markmonitor.com) <<mailto:Brian.King@markmonitor.com>Brian.King@markmonitor.com>; <mailto:Christopher.Lewis-Evans@nca.gov.uk>Christopher.Lewis-Evans@nca.gov.uk; Anderson, Marc (<mailto:mcanderson@verisign.com>mcanderson@verisign.com) <<mailto:mcanderson@verisign.com>mcanderson@verisign.com> Cc: Marika Konings <<mailto:marika.konings@icann.org>marika.konings@icann.org>; Rafik Dammak <<mailto:rafik.dammak@gmail.com>rafik.dammak@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@icann.org>Gnso-epdp-team@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.
participants (6)
-
Alan Greenberg -
James M. Bladel -
Kapin, Laureen -
King, Brian -
Rafik Dammak -
Volker Greimann