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@01D664BC.13FD6090] 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
