- Gnso-epdp-team - lists.icann.org

Re: [Gnso-epdp-team] Revised Consensus Designation
by Alan Greenberg July 30, 2020

July 30, 2020

For the purposes of determining consensus within the report, please indicate that the ALAC does NOT support recommendations (as stated in my original response on 24 July timestamped 15:46 UTC): 6.2 Priority Levels 9 Automation of the SSAD 14 Financial Sustainability 18 Evolution mechanism You may indicate support for the other recommendations. The reference to not supporting the entire report is based on the correct statement within the report that all of the SSAD recommendations are linked and inter-dependant. As noted in the submission of the ALAC statement, the ALAC will continue to consider our position and potentially resubmit a revised statement prior to the deadline of 24 August. We understand that any differences would not be reflected in the Chair's designation of consensus within the report. PLEASE RE-ISSUE THIS CHART SO WE CAN SEE YOUR PROPOSED DESIGNATIONS PRIOR TO THE REPLY DEADLINE. Alan At 2020-07-30 06:07 AM, Rafik Dammak wrote: >Hi all, > >Thanks for reviewing the consensus designation >and sending by the deadline your input to >indicate support or objection to >recommendations. I revised the consensus >designation based on what was received by the deadline. > >I will give 24 hours for final review to check >the revised consensus designation, 31st July >12:00PM UTC. The staff still needs to finish >attaching the different pieces for the final >report by the deadline. I would like to >emphasize one thing in particular. Regarding >ALAC conditional support for SSAD related >recommendations, unfortunately I have cautiously >interpreted them as opposition for several >reasons. Of course, if the ALAC disagrees with >this designation, they can share their input by the deadline. > >I cannot find any mention in the GNSO working >group guidelines covering such cases. I also >cannot recall similar precedents in previous >GNSO PDP WGs. The consensus designation is >supposed to be final at the time of publication >and report submission and shouldnâ?Tt be amended >when moving to GNSO council review since they >are to some extent the basis for council >decision on approving or not. The GNSO council >will review the report and policy >recommendations in order to make a decision. I >will highlight in my communication by the time >of submission and during the presentation of the >report the positions indicated by the groups >regarding consensus and their minority >statements. I understand the intent and request >for consideration made to GNSO council but >procedures didnâ?Tt envision such a situation of >having consensus designation in undecided or >pending state and in my role as chair or council >liaison I am bound to follow the procedures. I >cannot guarantee GNSO council decisions or actions. > >On a separate note, in order to close out final >issues, can RrSG can respond to Laureen's last >message on PPSAI (recommendation #19)? On >recommendation #7, I took the note of the latest >language agreed by RySG and BC, removing the >RySG no-support of the recommendation. I have >concluded that BC doesnâ?Tt agree to drop the >footnote and as result I have taken note of the >NCSG opposition in the consensus designation. > >Best Regards, > >Rafik > >Content-Type: >application/vnd.openxmlformats-officedocument.wordprocessingml.document; > name="Consensus designation table - 30 July 2020 .docx" >Content-Disposition: attachment; > filename="Consensus designation table - 30 July 2020 .docx" >Content-ID: <f_kd8ik4um0> >X-Attachment-Id: f_kd8ik4um0 > >_______________________________________________ >Gnso-epdp-team mailing list >Gnso-epdp-team(a)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.

4 5

FW: [Ext] IPC/BC minority statement
by Caitlin Tubergen July 30, 2020

July 30, 2020

Dear EPDP Team, Please find attached the joint minority statement of the IPC and BC. Best regards, Marika, Berry, and Caitlin From: "Journoud, Franck" <Franck_Journoud(a)motionpictures.org> Date: Wednesday, July 29, 2020 at 5:03 PM To: Marika Konings <marika.konings(a)icann.org>, Caitlin Tubergen <caitlin.tubergen(a)icann.org>, Berry Cobb Mail <mail(a)berrycobb.com>, Rafik Dammak <rafik.dammak(a)gmail.com> Cc: "King, Brian" <Brian.King(a)markmonitor.com>, "Mark Svancarek (CELA)" <marksv(a)microsoft.com>, Margie Milam <margiemilam(a)fb.com>, Steve DelBianco <sdelbianco(a)netchoice.org>, "Deacon, Alex" <alex(a)colevalleyconsulting.com> Subject: [Ext] IPC/BC minority statement Dear colleagues, Please find attached the joint minority statement of the IPC and BC on the Phase 2 final report. This statement includes a list of the recommendations we support or oppose, to assist the consensus designation process. Best, -Franck Franck Journoud Vice President, Technology Policy E franck_journoud(a)motionpictures.org<mailto:franck_journoud@motionpictures.org> O (202) 378-9127 | M (202) 285-7322 MOTION PICTURE ASSOCIATION 1600 Eye Street NW, Washington, DC 20006 CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is strictly prohibited. If you have received this communication in error, please notify the sender by return e-mail and delete and/or destroy all copies of this communication and any attachments.

2 1

FW: [Ext] Statement of RySG on Phase II Final Report
by Caitlin Tubergen July 30, 2020

July 30, 2020

Dear EPDP Team, Please find attached the RySG statement for inclusion in the EPDP Phase 2 Final Report. Best regards, Marika, Berry, and Caitlin From: "Crossman, Matthew" <mmcross(a)amazon.com> Date: Wednesday, July 29, 2020 at 5:55 PM To: Rafik Dammak <rafik.dammak(a)gmail.com>, Marika Konings <marika.konings(a)icann.org>, Caitlin Tubergen <caitlin.tubergen(a)icann.org> Cc: "Anderson, Marc (mcanderson(a)verisign.com)" <mcanderson(a)verisign.com>, "alan(a)donuts.email" <alan(a)donuts.email> Subject: [Ext] Statement of RySG on Phase II Final Report All, Attached is the RySG statement for inclusion in the Final Report. We have no objections to the consensus designations. Would you mind confirming receipt? Thanks! Matt Matthew Crossman | Amazon Corporate Counsel gTLD Registry, IP P: 206-266-1103 | C: 530-574-2956 Email: mmcross(a)amazon.com<mailto:mmcross@amazon.com>

1 0

FW: [Ext] RrSG Minority Statement for EPDP Phase 2 Final Report
by Caitlin Tubergen July 30, 2020

July 30, 2020

Dear EPDP Team, Please find attached the RrSG Minority Statement for the EPDP Phase 2 Final Report. Best regards, Marika, Berry, and Caitlin From: Owen Smigelski <owen.smigelski(a)namecheap.com> Date: Wednesday, July 29, 2020 at 5:48 PM To: Rafik Dammak <rafik.dammak(a)gmail.com>, Marika Konings <marika.konings(a)icann.org>, "<policy(a)bacinblack.com>" <policy(a)bacinblack.com>, Caitlin Tubergen <caitlin.tubergen(a)icann.org> Cc: "James M. Bladel" <jbladel(a)godaddy.com>, Volker Greimann <vgreimann(a)key-systems.net>, Matt Serlin <matt(a)brandsight.com>, Theo Geurts CIPP/E <gtheo(a)xs4all.nl>, Sarah Wyld <swyld(a)tucows.com> Subject: [Ext] RrSG Minority Statement for EPDP Phase 2 Final Report Hello EPDP Phase 2 leadership team- Attached is the RrSG Minority Statement for the EPDP Phase 2 Final Report. Additionally, the RrSG does not object to any consensus designations. On behalf of the RrSG, thank you very much for your tireless efforts and amazing work to push Phase 2 to completion- which at times seemed like an impossible task! Hopefully one day in the not too distant future we can all have an EPDP team reception to properly celebrate. Regards, Owen Smigelski on behalf of RrSG EPDP Team

1 0

Minority statement of NCSG
by Mueller, Milton L July 29, 2020

July 29, 2020

Attached is the (on time) minority statement of NCSG Dr. Milton L Mueller Georgia Institute of Technology School of Public Policy [IGP_logo_gold block].

1 0

Re: [Gnso-epdp-team] Rec. 19 (time sensitive)
by James M. Bladel July 29, 2020

July 29, 2020

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(a)icann.org> on behalf of "Kapin, Laureen via Gnso-epdp-team" <gnso-epdp-team(a)icann.org> Reply-To: "Kapin, Laureen" <LKAPIN(a)ftc.gov> Date: Tuesday, July 28, 2020 at 5:53 AM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)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(a)icann.org> On Behalf Of Kapin, Laureen via Gnso-epdp-team Sent: Monday, July 27, 2020 3:47 PM To: gnso-epdp-team(a)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(a)godaddy.com>; swyld(a)tucows.com; 'alan.greenberg(a)mcgill.ca' <alan.greenberg(a)mcgill.ca>; King, Brian (Brian.King(a)markmonitor.com) <Brian.King(a)markmonitor.com>; Christopher.Lewis-Evans(a)nca.gov.uk; Anderson, Marc (mcanderson(a)verisign.com) <mcanderson(a)verisign.com> Cc: Marika Konings <marika.konings(a)icann.org>; Rafik Dammak <rafik.dammak(a)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

6 8

Requestor Purpose - Rec 7
by Crossman, Matthew July 29, 2020

July 29, 2020

Hi team, As an update, Margie, Brian, and I worked on a compromise for the Rec 7 language on Requestor Purposes. We agreed on the following edit to 7.1(a): 7.1(a) Requestors MUST submit data disclosure requests for specific purposes such as but not limited to: but not limited to: (i) criminal law enforcement, national or public security, (ii) non law enforcement investigations and civil claims, including, intellectual property infringement and UDRP and URS claims, (iii) consumer protection, abuse prevention, and network security, and (iv) obligations applicable to regulated entities.[1] Requestors MAY also submit data verification requests on the basis of Registered Name Holder (RNH) consent that has been obtained by the Requestor (and is at the sole responsibility of that Requestor), for example to validate the RNH's claim of ownership of a domain name registration, or contract with the Requestor. (Footnote below) 1 For example, the EU Directive on security of network and information systems (known as the NIS Directive) imposes specific obligations on Digital Service Providers and Operators of Essential Services. With these changes this is no longer a CLW item for the RySG. Let us know if this new language causes any concern for other groups. Thanks, Matt Matthew Crossman | Amazon Corporate Counsel gTLD Registry, IP P: 206-266-1103 | C: 530-574-2956 Email: mmcross(a)amazon.com<mailto:mmcross@amazon.com> ________________________________ [1] This approach is very similar to the business model ARSI had previously discussed with the Author Central Pro teams for the .AUTHOR TLD.

6 6

Are we all spammers?
by Mueller, Milton L July 28, 2020

July 28, 2020

This is a bit Off Topic, but I've just noticed that in the past day or two, my email has been classifying more than half of the EPDP listserv and several other ICANN-related listservs as junk mail. I am wondering whether this has happened to anyone else or whether it unique to Georgia Tech's MS Outlook. Dr Milton L Mueller, Professor School of Public Policy Georgia Institute of Technology Internet Governance Project<https://internetgovernance.org>

2 2

FW: Rec. 19 (time sensitive)
by Kapin, Laureen July 28, 2020

July 28, 2020

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(a)godaddy.com>; swyld(a)tucows.com; 'alan.greenberg(a)mcgill.ca' <alan.greenberg(a)mcgill.ca>; King, Brian (Brian.King(a)markmonitor.com) <Brian.King(a)markmonitor.com>; Christopher.Lewis-Evans(a)nca.gov.uk; Anderson, Marc (mcanderson(a)verisign.com) <mcanderson(a)verisign.com> Cc: Marika Konings <marika.konings(a)icann.org>; Rafik Dammak <rafik.dammak(a)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@01D663FA.D7BD75A0] 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

1 1

Review of agreements reached on cat 2 items by Tuesday 28 July COB
by Marika Konings July 28, 2020

July 28, 2020

Dear EPDP Team, To facilitate your review of category 2 agreements that have been reached, please review the compilation here: https://docs.google.com/document/d/1sfUJf8RqSaTEskxlqAflh8OR4QDXGURa/edit. If there are any that we missed (we recorded 4 items), please flag this as soon as possible. By COB today, Tuesday 28 July, please indicate if any of these agreements have resulted in cannot live with items for your group. For input already provided on the mailing list, this has been reflected in the google doc. As a reminder, the remaining deadlines are: 1. By COB Tuesday, 28 July: EPDP Team to review Support Staff’s noted list of agreements and flag if any agreed changes result in “cannot live with” items. (Cannot live items will not be applied to the Final Report.) 2. By Wednesday, 29 July at the latest: EPDP Team Members to respond to Chair’s consensus designation if members believe designation is inaccurate. 3. By Wednesday, 29 July at the latest: EPDP Team Members to provide minority statements. Note that an extension has been provided for those not able to meet this deadline to submit by 24 August at the latest. 4. By Friday, 31 July: Deadline to submit Final Report to GNSO Council. Best regards, Caitlin, Berry and Marika

1 0