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

Tue Jul 28 14:55:37 UTC 2020

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 at mcgill.ca>
wrote:

> My understanding is that under the new P/P policy, an accredited P/P
> service has an agreement with ICANN and it is THEIR contractual obligation,
> not the registrar. The meaningfulness of an affiliated P/P service
> disappears once the new accreditation process is operational.
>
> Alan
>
> On July 28, 2020 10:20:38 AM EDT, "James M. Bladel" <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 *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 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:*
>>
>>
>>
>>
>>
>> *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 at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200728/f6d58ba7/attachment-0001.html>