[Gnso-epdp-team] Rec. 19 (time sensitive)

[Alan Greenberg]

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 at godaddy.com> wrote:
>If they aren’t “affiliated” then we can’t accept any contractual
>obligations on their behalf. And if they aren’t “accredited” then they
>shouldn’t be offering privacy services.  So leaving the sentence with
>“and” ensures that we are both authorized (accredited) and capable
>(accredited) of meeting the requirement.
>
>Note:  I can’t help feeling like we are polishing the chrome on the
>Titanic here.  Privacy services are becoming less relevant (and less
>attractive to customers) as the year progresses.
>
>J.
>
>
>From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> on behalf of
>"Kapin, Laureen via Gnso-epdp-team" <gnso-epdp-team at icann.org>
>Reply-To: "Kapin, Laureen" <LKAPIN at ftc.gov>
>Date: Tuesday, July 28, 2020 at 5:53 AM
>To: "gnso-epdp-team at icann.org" <gnso-epdp-team at icann.org>
>Subject: Re: [Gnso-epdp-team] Rec. 19 (time sensitive)
>
>Notice: This email is from an external sender.
>
>
>I welcome input from my Registrar colleagues on this issue re: the
>first sentence of Rec. 19.1 (“In   the case of a domain name
>registration where an affiliated and accredited privacy/proxy service
>is used. . .”)
>
>GAC Note:  Should this be “or” or “and/or”?
>
>“In the case of a domain name registration where an affiliated ‘or’
>accredited privacy proxy service is used?”
>
>My understanding is that no P/P providers will actually be “accredited”
>until the implementation of the PPSAI Policy Recommendations.  Having
>suggested this revision, I want to make sure we’ve gotten it right.
>
>
>Kind regards,
>
>Laureen Kapin
>Counsel for International Consumer Protection
>Federal Trade Commission
>(202) 326-3237
>
>From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> On Behalf Of
>Kapin, Laureen via Gnso-epdp-team
>Sent: Monday, July 27, 2020 3:47 PM
>To: gnso-epdp-team at icann.org
>Subject: [Gnso-epdp-team] FW: Rec. 19 (time sensitive)
>
>Hi folks,
>
>I’m forwarding proposed changes to Rec. 19 (Privacy Proxy) that the
>Rgr’s, Rgy’s (deferring to Rgr’s) and GAC have agreed to.  As you’ll
>see below, we think these edits will improve the clarity of the
>Recommendation 19.  For convenience, more context is provided in this
>email chain and I’m also including the revised text (changes
>highlighted) here below.  I’m happy to answer any questions.
>
>   Proposed Revised text of Rec. 19:
>
>Recommendation #19  Display of information of affiliated and accredited
>privacy/proxy providers
>
>19.1  In   the case of a domain name registration where an affiliated
>and accredited privacy/proxy service is used, e.g., where data
>associated with a natural person is masked, Registrar (and Registry,
>where applicable) MUST include the full RDDS data of the accredited
>applicable privacy/proxy service in response to an RDDS query. The full
>privacy/proxy RDDS data may also include a pseudonymized email.
>
>Implementation notes:
>19.2 Once ICANN org has implemented a privacy/proxy service
>accreditation program, this Recommendation 19 once in effect will
>replaces or otherwise supersedes EPDP phase 1 recommendation #14.
>
>19.3 The intent of this recommendation is to provide clear instruction
>to registrars (and registries where applicable) that where a domain
>registration is done via an affiliated or accredited privacy/proxy
>provider, that data MUST NOT also be redacted. The working group is
>intending that domain registration data should MUST NOT be both
>redacted and privacy/proxied.
>
>
>Kind regards,
>
>Laureen Kapin
>Counsel for International Consumer Protection
>Federal Trade Commission
>(202) 326-3237
>
>From: Kapin, Laureen
>Sent: Monday, July 27, 2020 10:12 AM
>To: James M. Bladel <jbladel at godaddy.com>; swyld at tucows.com;
>'alan.greenberg at mcgill.ca' <alan.greenberg at mcgill.ca>; King, Brian
>(Brian.King at markmonitor.com) <Brian.King at markmonitor.com>;
>Christopher.Lewis-Evans at nca.gov.uk; Anderson, Marc
>(mcanderson at verisign.com) <mcanderson at verisign.com>
>Cc: Marika Konings <marika.konings at icann.org>; Rafik Dammak
><rafik.dammak at gmail.com>
>Subject: Rec. 19 (time sensitive)
>
>Hi folks,
>
>Rec. 19 seems like something we may be able to clarify and agree upon
>prior to submitting our consensus designations.  I think the current
>wording of Rec. 19 is not clear in these ways:
>
>
>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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200728/ce32274f/attachment-0001.html>