December 2018 - Gnso-epdp-team

Re: [Gnso-epdp-team] language re: affiliated privacy/proxy companies
by Mark Svancarek (CELA) 19 Dec '18

19 Dec '18

Forwarding to list From: Mark Svancarek (CELA) Sent: Wednesday, December 19, 2018 12:37 PM To: Anderson, Marc <mcanderson(a)verisign.com>; jbladel(a)godaddy.com; caitlin.tubergen(a)icann.org Subject: RE: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Alternately: "or offered by an accredited P/P provider" Although this assumes that PPSAI proceeds. From: Mark Svancarek (CELA) Sent: Wednesday, December 19, 2018 11:41 To: 'Anderson, Marc' <mcanderson(a)verisign.com<mailto:mcanderson@verisign.com>>; jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>; caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org> Subject: RE: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Marc, I would prefer: "known Privacy or Proxy service" Which is a superset of "offered or made available by Registrar or its Affiliates" /msv From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Anderson, Marc via Gnso-epdp-team Sent: Wednesday, December 19, 2018 09:09 To: jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>; caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org>; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Hi all, James makes a good point, I support his edit. Caitlin's proposed text has a typo showing "proxy/proxy" where I assume "privacy/proxy" is intended. I have concerns with the text "...Registrar MUST return in response to any query full WHOIS data..." More specifically, I don't think "any" actually means "any" in this context, "full" is undefined and should more appropriately be "unredacted" and WHOIS should be replaced with RDS or RDDS. I suggest: "...Registrar MUST return unredacted data in response to RDDS queries... " I understand the reason for this recommendation is so that Registrars do not redact registration data that is already protected by a known Privacy or Proxy service. If the Privacy/Proxy service is operating as intended than personally identifiable information of the registrant has already been removed from the RDDS record and so further redacting it is redundant and creates an unnecessary hurdle for a requestor with a legitimate need to access the actual registration data behind the service. While Caitlin's proposed language is generally clear, sometimes an explanation of the intent can be helpful in particular when it comes time to implement the policy. I suggest adding text along these lines: The intent of the working group in making this recommendation is that Registrars should not redact registration data that is already protected by a known Privacy/Proxy service. Redacting the RDS data of a Privacy/Proxy service provider shouldn't be necessary for GDPR compliance and creates an unnecessary hurdle for a requestor with a legitimate need to access the actual registration data behind the service. On our Tuesday call we discussed the fact that it is not always know to the registrar that the registration is from a privacy/proxy service. I used the words "known Privacy or Proxy service" while Caitlin uses "offered or made available by Registrar or its Affiliates". I'm not sure which is better and perhaps this is a question for registrars. I'm sensitive to registrars potentially getting sideways with compliance over this. On last Thursday's (meting #34) call, Marika talked to us about the "policy change impact" section of the report which could include information on how to measure compliance. While we agreed on Thursday's call to table that until we are a little further along in our policy recommendations, that does have me wondering if there is language we could add so that Registrars and compliance are on the same page as to how this should be implemented and enforced? We also spoke about the currently on hold Privacy/Proxy implementation effort. I understand them to be on hold waiting our final policy recommendations as that may inform or otherwise impact their work. I am maybe being overly cautious here, but I want to make sure nothing in our recommendations conflicts with or constrains the Privacy/Proxy group. Our group is responsible for GDPR compliance, their group for implementing a Privacy/Proxy policy. Some overlap may be unavoidable but we should leave Privacy/Proxy policy to them. I'm thinking adding language that this recommendation is subject to that policy might be prudent. If there is no conflict then this recommendation stands, but if it conflicts with their policy, then their policy takes precedent. Thanks, Marc From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Wednesday, December 19, 2018 8:15 AM To: Caitlin Tubergen <caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org>>; GNSO EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Subject: [EXTERNAL] Re: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Hi All- This language is mostly ok (thanks Caitlin!), but the parenthetical example sideswipes the natural vs. legal debate. Recommend we change this: (e.g. where data associated with a natural person is masked) To this: (e.g. where data associated with the Privacy/Proxy customer is masked) Thanks- J. ------------- James Bladel GoDaddy ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org>> Sent: Tuesday, December 18, 2018 18:48 To: GNSO EPDP Subject: [Gnso-epdp-team] language re: affiliated privacy/proxy companies Dear All, Following up on an action item from today's EPDP call, please find draft language regardingregistrar disclosure of privacy/proxy data to a requestor (section 2.6 of Appendix A of the Temp Spec).For ease of reference, the updated language is italicized. The EPDP Team recommends that in the case of a domain name registration where a Privacy/Proxy service,offered or made available by Registrar or its Affiliates in connection with a registration isused, (e.g. where data associated with a natural person is masked), Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email. (emphasis added) Please respond to the list if you have any issues with the above draft language. Best regards, Marika, Berry, and Caitlin

1 0

Question to ICANN re: Dispute Resolution Providers Data Processing Agreements
by Kurt Pritz 19 Dec '18

19 Dec '18

Dear Dan and Trang: I am writing to you in your capacity as the ICANN organisation liaisons to the EPDP Team. As you may recall, the EPDP Team discussed issues related to the EPDP Team’s assessment of responsible parties, specifically in relation to dispute resolution providers. For more information regarding the Team’s assessment of responsible parties vis-à-vis ICANN and dispute resolution providers, please refer to p. 20 of the Initial Report <https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld…>. As you recall, Recommendation #18 provides: “The EPDP Team recommends that ICANN Org must enter into data processing agreements with dispute resolution providers in which, amongst other items, the data retention period is specifically addressed, as this will affect the ability to have publicly-available decisions.” In an email on the topic, the ICANN organization stated, “[a]dditional discussions and analyses may be needed on this topic.” This comment specifically went to the EPDP indication that, in dispute resolution processes, ICANN is the sole data controller. Following the discussion during the EPDP Team’s meeting <https://community.icann.org/display/EOTSFGRD/2018-12-04+EPDP+Team+call+%2331> on 4 December 2018, the Team agreed that no changes to Recommendation #18 were required. If ICANN org disagrees with or wishes to discuss the Recommendation #10 or EPDP Team’s assessment regarding the responsibility of the parties, please engage with the EPDP Team at your earliest convenience and in time to inform its deliberations as it prepares its Final Report. This, we think, will require a response prior to the end of year ICANN shutdown. Thanks very much for taking time to consider this. Sincerely, Kurt

2 1

Question to ICANN re: Data Escrow Data Processing Agreements
by Kurt Pritz 19 Dec '18

19 Dec '18

Dear Dan and Trang: I am writing to you in your capacity as the ICANN organisation liaisons to the EPDP Team. As you may recall, the EPDP Team discussed Recommendation #6 from its Initial Report <https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld…> during its meeting <https://community.icann.org/display/EOTSFGRD/2018-12-04+EPDP+Team+call+%2331> on 4 December 2018. The EPDP Team agreed to update the language of Recommendation #6 to the following: “[t]he EPDP Team recommends that ICANN Org develop legally-compliant data processing agreements with the data escrow providers.” While you are likely aware of this recommendation, the EPDP Team thought it important to request in writing that ICANN commence development of legally-compliant data processing agreements with its approved data escrow providers. The EPDP Team discussed and documented <https://community.icann.org/display/EOTSFGRD/e.+Data+Elements+Workbooks> the associated processing activities and responsible parties for registrar data escrow and registry data escrow. Please refer to Purpose E data processing workbooks <https://community.icann.org/display/EOTSFGRD/e.+Data+Elements+Workbooks> for additional information. In its analysis, the EPDP Team has identified ICANN as the controller and the contracted parties and data escrow providers as processors. Accordingly, the EPDP Team encourages you to proceed with developing legally-compliant data processing agreements with those roles as described here and in the Initial Report. If ICANN org disagrees with or wishes to discuss the EPDP Team’s request, analyis or assessment, please engage with the EPDP Team at your earliest convenience and in time to inform its deliberations as it prepares its Final Report. This, we think, will require a response prior to the end of year ICANN shutdown. Thanks very much for taking time to consider this. Sincerely, Kurt

2 1

Proposed Agenda - EPDP Meeting #36
by Caitlin Tubergen 19 Dec '18

19 Dec '18

Dear All, Please find the proposed agenda for our next EPDP Team meeting below. Thank you. Best regards, Marika, Berry, and Caitlin -- EPDP Meeting #36 Agenda Thursday, 20 December 2018 Roll Call & SOI Updates (5 minutes) Welcome and Updates from EPDP Team Chair (5 minutes) Review of outstanding action items Other updates, if applicable Continue review of list of topics for further discussion: in today’s meeting we will review potential wording developed from previous discussions for certain Temp Spec / Policy Recommendations to assess where there are areas of agreement. Privacy/Proxy Services - how the P/P records appear in the public WHOIS (review of language developed in previous meeting) The EPDP recommends that in the case of a domain name registration where a Privacy/Proxy service, offered or made available by Registrar or its Affiliates in connection with a registration is used, (e.g. where data associated with a [Privacy/Proxy customer] is masked), Registrar MUST return [unredacted data] in response to [RDDS] quer[ies], including the existing privacy/proxy pseudonymized email. Note: bracketed wording references suggestions from James and Marc A. Consent by the Registrant to Publish and/or Disclose for technical contact Current language in Temp Spec, Section 7.2.1/ Appendix C – Section 2.3 contains this requirement: Registrar MAY provide the opportunity for the Admin/Tech and/or other contacts to provide Consent to publish additional contact information outlined in Section 2.4 of Appendix A. Margie to introduce issue: Whether registrars should seek consent from those listed as additional contacts (admin/tech) to having their information as reflected in the Contact data be published rather than be redacted. This is an issue that would be available to both natural persons and legal persons. Proposed outcome: confirm this requirement [IPC/BC/SSAC support confirmation.] Geographic Differentiation Discuss proposed draft recommendation (see attached document) Discussion, next steps Definition of Optional Discuss proposed draft language (see attached document) Discussion, next steps Wrap and confirm next meeting to be scheduled for Thursday, 3 January 2019 at 14.00 UTC Confirm action items Confirm questions for ICANN Org, if any

1 0

language re: affiliated privacy/proxy companies
by Caitlin Tubergen 19 Dec '18

19 Dec '18

Dear All, Following up on an action item from today’s EPDP call, please find draft language regarding registrar disclosure of privacy/proxy data to a requestor (section 2.6 of Appendix A of the Temp Spec). For ease of reference, the updated language is italicized. The EPDP Team recommends that in the case of a domain name registration where a Privacy/Proxy service, offered or made available by Registrar or its Affiliates in connection with a registration is used, (e.g. where data associated with a natural person is masked), Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email. (emphasis added) Please respond to the list if you have any issues with the above draft language. Best regards, Marika, Berry, and Caitlin

3 2

**Reminder** Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 20 December 2018
by Julie Bisland 19 Dec '18

19 Dec '18

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/FAvVBQ Thank you. Kind Regards, Andrea

1 0

Notes, action items from EPDP Team Meeting #35
by Caitlin Tubergen 19 Dec '18

19 Dec '18

Dear All, Below, please find notes and action items from today’s call, EPDP Team Meeting #35. The next EPDP Team meeting will be Thursday, 20 December at 1400 UTC. Thank you. Best regards, Marika, Berry, and Caitlin __ EPDP Team Call #35 Tuesday, 18 December 2018 14:00 UTC High-Level Notes/Actions EPDP Support Staff to circulate draft recommendation regarding registrar disclosure of privacy/proxy data to requestor, as developed by the team discussion during the meeting. This draft recommendation will replace the language in Section 2.6 of Appendix A. EPDP Leadership to summarize the EPDP Team’s discussion of registrant consent to publication of private data and send to the mailing list for further discussion. The EPDP Legal Committee will hold its first meeting tomorrow, Wednesday, 19 December at 1400 and will discuss and refine potential questions to submit for further legal guidance. Question to ICANN What is the rationale for the bolded wording in this Temporary Specification section: As soon as commercially reasonable, Registrar MUST provide the opportunity for the Registered Name Holder to provide its Consent to publish the additional contact information outlined in Section 2.3 of Appendix A for the Registered Name Holder. What was the community input into this Temporary Specification section that, in each of the two cases, led to the wording, “as soon as commercially reasonable,” and “MUST“? Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ 1. Roll Call & SOI Updates Attendance will be taken from Adobe Connect Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes. Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair (5 minutes) a. Review of outstanding action items Support Staff will be circulating language regarding geographic differentiation and policy impact analysis this week for the EPDP Team's review. b. Other updates, if applicable c. Announce LC Members and introduce agenda for first meeting (EDPB questions) First meeting will be held tomorrow (18 Dec, 1400 UTC) during the normal EPDP call time Members of the LC include: Board - Leon BC - Margie IPC - Diane ISPCP - Thomas RySG - Kristina RrSG - Emily GAC - Laureen ALAC - Hadia EPDP Leadership - Kurt, Rafik The first meeting's agenda will be to review the SOW and EDPB questions to refine for ultimate review by legal counsel. Who decided the criteria for the legal committee? In following the CCWG Work Stream 2 model, the idea was only to have attorneys on the Legal Committee; however, since not all groups have attorneys, the rule is not absolute. EPDP Members should refrain from using colored language in their emails to the team. d. Review of commonly-asked Google Form questions Document will be sent to the Team with the notes for today. Please email additional questions regarding the Google Form to: gnso-epdp-lead(a)icann.org. 3. Continue review of list of topics for further discussion Privacy/Proxy Services - how the P/P records appear in the public WHOIS If there is a privacy/proxy service, the Registrar must return the full WHOIS data. BC wanted to confirm Section 2.6 of Appendix A. It may make sense to add language similar to Section 2.6 of Appendix A as a policy recommendation. This is a good idea because if a requester jumps through hoops to ultimately receive P/P data, it will be wasted time for both the requestor and the registrar. PPSAI work is currently on pause. This makes sense if the service is offered by the registrar or a service offered by an affiliate of the registrar. In the event the service is independent of the registrar, the registrar could not return the underlying data. The language may need to be tightened up for situations in which a registrar is unaware that a P/P service is being used. The registrar can only deliver underlying information if it is aware there is underlying information. P/P services would be legal persons and not natural persons. The Team could work on the current wording, but it makes sense to solve for the majority case and not the edge case. The RAA includes rules for registrar’s P/P services and it applies to registrar affiliates as well. Not advocating for removal of this requirement, but more specific language is needed to capture non-affiliated cases. For reference, the RAA rules relating to privacy/proxy apply to services "offered or made available by Registrar or its Affiliates in connection with each registration" (3.4.1.5) Possible draft language: The EPDP recommends that in the case of a domain name registration where a Privacy/Proxy service, offered or made available by Registrar or its Affiliates in connection with a registration is used, (e.g. where data associated with a natural person is masked), Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email. Action support staff to capture the above language and email to the EPDP Team. Email from ICANN org to IPC - delay of PPSAI IRT - ICANN org believes the EPDP will address some of the issues. If the PPSAI work requires something from this team, OK, but this team's job should not be doing the PPSAI IRT's work. PPSAI situations there may be privacy customers Privacy Customer 125 could still be personal data since it is capable of identifying a person. Anonymized emails can still be personal data. To the extent that the EPDP team (within its charter scope) has specific guidance on the issues as they relate to PP services, that may be helpful to the PPSAI IRT when they finalize their proposed model and draft agreements. If the PPSAI IRT needs something specific from the EPDP Team, the burden is on them to come forward with what they need. The Team should not make assumptions - we may not be automatically providing the needed guidance the PPSAI IRT needs to complete its work. If the Team can provide guidance, or if the PPSAI IRT can provided questions to us, there should be a communication path b/w the two groups. We need to discuss and agree what will be on the agenda. Only a minority of members wanted to discuss P/P. Registrant Consent to Publication – option for registrants to request to have all of their RDS data published It is important to allow registrants to make this decision. Registrars may not offer this if not required to, so it would be better to make this a requirement and honor the registrant's choice. The EPDP Team's job is to say - does the Temp Spec allow ICANN and contracted parties compliant with the GDPR? Creating a consensus policy requiring this is creating an implementation impossibility that cannot be implemented prior to 25 May. As an alternative, if there is a process by which a registered name holder could actively request their information be published could be OK. The default would be redaction. We should be able to do this, but we may not be able to do this by May 2019. Asking the GNSO to start a new PDP is pushing this too far down the road as to make it not viable at all. There may be mechanisms allowing for consent, but this should be MAY for both registrars and registrants. This should not be mandatory, could be voluntary, but getting consent to publish data on the basis of consent is not easy. While companies may already do this, they may not be doing it well or in a GDPR-compliant way. IPC believes this should be a must - registrars must make the option available to registrants. How will registries know if there is consent to publish the data, so it makes more sense to make this a "must" rather than a "may". If a registrant knows enough about publication of data, they can make an informed decision as to which registrar to use. Regarding Art. 6(1)(b) - notes taking steps prior to entering into a contract - this may be more straightforward rather than meddling with consent in Art. 8. If you are doing consent-based processing, you need to evidence the consent and the content of that consent comprehensively. For everyone on these calls, shopping around for registrars may be simple, but for the typical registrant - it is not simple. You need equivalent of an apple agreement to cover consent, but then you would have to deal with withdrawal of consent. We should park this issue for now. It is not for the group to figure this out as we do not have time. Art. 6(1)(b) - if in order to enter into a contract, the controller must process data subject's data prior to entering into the contract, that's what the language in Art. 6(1)(b) is meant to represent. Registrars should not be forced to take risks for the sake of certain people. Certain businesses may not be in a position to assume the risk. What if we took out the words when commercially feasible and replace it with "may". We are not talking about a concept involving implementation costs - providing the data that is optional to publish was the law of the land. Registrars should be required to explain to registrants what data they have the option to publish. There seems to be an assumption that everyone is working from the same basis of knowledge, which may not be the case with some registrars and registrants. If it not going to be a "must", we could have a "may" in the recommendations. The reference to "gun shy" was not meant to be inflammatory. Registrants asking for their information to be published are making this request for their own benefit - they are not doing it for the benefit of third parties. (they may be using it for marketing, advertising) Ultimately, this should be optional since this is an add-on or value-added service. This could also be captured in the Team's report. One of the complaint of registrars is that ICANN heaps regulations on the "good guys". While "may" could be OK, in a situation with the "bad guys", this may allow bad registrars to give another layer of obfuscation with their bad customers. If consent is not transferred to the registry, are we defeating the purpose? Does this issue become moot when RDAP is deployed? It is not clear why offering the option of publishing details and getting consent - why is that so difficult? It sounds straightforward. The risk here is getting it wrong - if there is no legal basis for publishing data, this is a risk. How can you withdraw consent and remove the data from the escrow provider, the registries and other relevant parties? The technical implementation issue is a red herring. The technical issues are not insurmountable here. "soon as commercially reasonable" is important for small registrars. It should still be a "may". Leadership to summarize this conversation via email. Support Staff to send draft language re: P/P services to the list. Consent by the Registrant to Publish and/or Disclose for technical contact 4. Wrap and confirm next meeting to be scheduled for Thursday, 20 December 2018 at 14.00 UTC a. Confirm action items b. Confirm questions for ICANN Org, if any

1 0

Recordings, Attendance & AC Chat / GNSO Temp Spec gTLD RD EPDP / Tuesday, 18 December 2018
by Andrea Glandon 18 Dec '18

18 Dec '18

Dear all, Please find the attendance and AC chat attached to this email, and the MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Tuesday, 18 December 2018 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/BQvVBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-18dec18… AC Recording: https://participate.icann.org/p39bwklo2lc/<https://participate.icann.org/p39bwklo2lc/?OWASP_CSRFTOKEN=42cbcfdcadb04b8a…> ** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ Thank you. Kind Regards, Andrea Glandon

1 0

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 20 December 2018
by Andrea Glandon 18 Dec '18

18 Dec '18

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/FAvVBQ Thank you. Kind Regards, Andrea

1 0

Reminder CSP deadline
by Nathalie Peregrine 18 Dec '18

18 Dec '18

Dear all, We would like to remind you about the upcoming Chairing Skills Program (CSP). If you would like to take part in the training and benefit from individual feedback on your chairing skills, or if you are willing to share your experience and act as a coach we kindly ask that you register here [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_forms_…> by next Friday, 21 December, 2018. You will find some general information about the program in the flyer enclosed and in more detail here: https://community.icann.org/x/8xK4Aw. The CSP will be held during ICANN64 in Kobe, Japan with a preparatory call beforehand. Participation includes a reasonable time commitment between 3-7 hours, but offers great opportunities for effective participation at ICANN meetings. If you have any questions, please feel free to contact Sandra Hoferichter, Chair of the ICANN Academy Working Group at info(a)hoferichter.eu<mailto:info@hoferichter.eu> or the PRS Team at prs(a)icann.org<mailto:prs@icann.org>. Thank you, PRS Team Carlos Reyes Strategic Policy Planning Director Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 202 802 8019 Skype: carlos.reyes.icann www.icann.org

1 0