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

FW: [Ext] Statement of RySG on Phase II Final Report
by Caitlin Tubergen 30 Jul '20

30 Jul '20

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 30 Jul '20

30 Jul '20

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 29 Jul '20

29 Jul '20

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 29 Jul '20

29 Jul '20

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 29 Jul '20

29 Jul '20

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 28 Jul '20

28 Jul '20

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 28 Jul '20

28 Jul '20

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 28 Jul '20

28 Jul '20

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

Final report and consensus designation
by Rafik Dammak 27 Jul '20

27 Jul '20

Hi all, We are reaching today an important milestone of our long journey. As promised, I am sharing with you the consensus designation I made for the policy recommendations. Following the GNSO Working Group Guidelines provision, I am sharing here the first iteration of the consensus designation. Similar to phase 1, I am using a table to identify the consensus designation for each policy recommendation I believe has been achieved. The table also indicates which groups do not appear to support a recommendation or a part of it. The designation is based on the outcome of our latest deliberations this week and I made the assessment with the “cannot live with” as an indicator or where groups have indicated directly that they do not support certain recommendations, to select what I think is the appropriate level of consensus. We managed to resolve the majority of “cannot live with” items identified, but unfortunately we were not able to do that for all. I have used those “cannot live with” items that we were not able to resolve as an indicator. I want also to highlight that in certain cases the “cannot live with” items went to a very specific part of the recommendation and I have taken a cautious approach and assumed that this meant a group is not able to live with the whole recommendation for the purpose of the consensus designation. Groups can of course correct that if it is not an accurate assumption. The document includes also the relevant provisions in the GNSO working group guidelines. As mentioned previously, this is an iterative process but also not an endless one. So I would like to ask each group to indicate if they believe the consensus designation is not the correct one or the group has been incorrectly identified or not identified as not supporting certain recommendations. Please do that asap to help me to review the received input and make the necessary updates in a timely manner. I am hoping that this process will be straightforward and we all come swiftly to a general understanding on the consensus designations. The period of 24 to 29 July is for the EPDP Team to respond to consensus designations and share its feedback. For ease of use, you can use the table to share your input. We tried our best to revolve concerns, reach agreements within the limits and constraints we are dealing with. The product is not perfect but it is the result of a consensus process and a lot of compromise. Although it would have been nice if the outcome of PDPs could make everybody happy and give everyone everything they want, unfortunately this is not possible, but it is important that we have a product you can accept and own. This is not the time for revisions or re-opening discussions but it is for finalizing our deliverable. So let’s stay focused. I do believe that we did what we could do and deliberated on those topics to the extent of possible. I acknowledge there are disagreements and concerns. As I stated during the calls, you have the opportunity to get them on the record through the minority statement where you can go into details and explain your rationale. Even if you support a consensus position, you can still provide a statement to make your views heard. I urge you to submit them by deadline in order to be included, you don’t need to wait for the 29th July to do so. I recognize there may be some general dissatisfaction with some wanting more, others wanting less but at the end the group has come and worked together on delivering this report. The GNSO council will consider the final report and recommendations upon reception and will have to act on. Rest ensured that the report will be reviewed diligently. I also acknowledge the frustration that some have about the remaining priority 2 issues not being addressed. I can reassure you that the GNSO Council is looking at how, not if, to address those topics in a timely manner and outlining the next steps and timing. It tasked a small team of councillors to come up with the proposal to be considered. You can find the final report here: https://community.icann.org/x/K4LsBw . Finally and on a less formal note, today was supposed to be the start of the Olympics game in Tokyo. Many described our EPDP as a marathon, definitely at an Olympic level of efforts and commitment. We are so close to the finishing line and we should celebrate soon the finalization of this phase. Best Regards, Rafik

2 2

Re: [Gnso-epdp-team] FW: Extension of time until August 24, 2020 for Minority Statements
by Alan Greenberg 27 Jul '20

27 Jul '20

Rafik, You may not have the authority to change it but you in your role of GNSO Council Liaison, you do have the authority to being the request to the Council Chair and the Council. This report not being considered by the Council until September is fine. Perhaps there can be a smaller extension and then use the mechanisms you suggest. On those, a Wiki link is NOT acceptable. The statements need to be integrated into the report. I STRONGLY suggest that past whatever the initial publication deadline is, you publish a REVISED report incorporating new statements no less than once a week. That way whenever someone pulls the report, they get the most recent version. The effort to insert a statement and recreate the PDF is minimal and this gives the minority statement the respect that they are due. Alan At 2020-07-25 04:52 AM, Rafik Dammak wrote: >hi, > >As you know, we were asked by the GNSO council >to submit a final report by 31st July at the >latest. I don't have the mandate or the ability to change that. > >However to respond to this request to the extent >of possible and permissible, we will have a wiki >page where minority statements will get posted >and include that link in an annex to the Final >Report. The other option in the same fashion >would be to get the annex attached to the final >report when ready and still submitting the final >report by the deadline. Whatever is received by >the deadline will go in immediately into the >report and anything after that will just get >added later. This would allow for a timely >submission of the Final Report, while groups can >still take time to finalize their minority >statements. I will communicate clearly to the >GNSO Council when the final report is submitted >that other minority statements are still forthcoming. > >The deadline for submissions is 24th August but >I strongly urge groups to submit theirs when >ready and not waiting till the last minute. That >will help for GNSO council consideration in a >timely manner. I will also note that Council >would only be able to start considering at the >earliest in September instead of August. > >Best Regards, > >Rafik > > > >Le sam. 25 juil. 2020 Ã 01:40, Kapin, Laureen >via Gnso-epdp-team ><<mailto:gnso-epdp-team@icann.org>gnso-epdp-team(a)icann.org> a Ã©crit : > >Dear colleagues, > > > > Please note our request for more time to complete Minority Statements. > > > >Kind regards, > > > >Laureen Kapin > >Counsel for International Consumer Protection > >Federal Trade Commission > >(202) 326-3237 > > > >From: Kapin, Laureen >Sent: Friday, July 24, 2020 12:36 PM >To: Rafik Dammak <<mailto:rafik.dammak@gmail.com>rafik.dammak(a)gmail.com> >Cc: Marika Konings ><<mailto:marika.konings@icann.org>marika.konings(a)icann.org>; >'<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca' ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca>; >Margie Milam ><<mailto:margiemilam@fb.com>margiemilam(a)fb.com>; >King, Brian >(<mailto:Brian.King@markmonitor.com>Brian.King(a)markmonitor.com) ><<mailto:Brian.King@markmonitor.com>Brian.King(a)markmonitor.com>; >LEWIS-EVANS, Christopher ><<mailto:Christopher.Lewis-Evans@nca.gov.uk>Christopher.Lewis-Evans(a)nca.gov.uk>; ><mailto:Georgios.TSELENTIS@ec.europa.eu>Georgios.TSELENTIS(a)ec.europa.eu; >Manal Ismail >(<mailto:manal@tra.gov.eg>manal(a)tra.gov.eg) ><<mailto:manal@tra.gov.eg>manal(a)tra.gov.eg> >Subject: Extension of time until August 24, 2020 for Minority Statements > > > >Dear Rafik, > > > > On behalf of the GAC, ALAC, BC, and IPC, we > are requesting until August 24th to submit our > Minority Statements. Regrettably, the final > stages of this process were quite rushed as > stakeholder groups were asked to review, > digest, and confer over large amounts of > material that raised complex issues. Over the > last week, we attempted to identify and > prioritize our concerns and resolve the scores > of remaining issues. Despite three > lengthy meetings, there was not sufficient > time to discuss, much less resolve many crucial > matters. Notably, we barely discussed the > important category of issues that stakeholder > groups would like to see changed. There was > also considerable confusion over the final resolution of certain issues. > > > > As a result, we will need time to carefully > review the now final version of the EPDP Report > to pinpoint and finalize what will comprise the > issues included in our minority > statements. Like other stakeholder > groups, the GAC has formal procedures for > conferring with our members. This is an > iterative process that requires time for > membership to review proposed text, ask > questions, and consider revisions until a final > agreement is reached. This task is made more > difficult due to the complexity of the subject > matter and intervening religious and summer > holidays. The Minority Statements are a > crucial part of the multistakeholder model and > for many groups will be the only opportunity to > express and explain their concerns as part of > the Final Report. Accordingly, we will need > until August 24th to complete this important > responsibility. We will try to submit our > Minority Statements earlier than that if > possible. We appreciate your understanding. > > > >Kind regards, > > > >Laureen Kapin > >Counsel for International Consumer Protection > >Federal Trade Commission > >(202) 326-3237 > > >_______________________________________________ >Gnso-epdp-team mailing list ><mailto:Gnso-epdp-team@icann.org>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>https://www.icann.org/privacy/policy) >and the website Terms of Service >(<https://www.icann.org/privacy/tos>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. > >_______________________________________________ >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.

6 5