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

Proposed agenda - EPDP Team Meeting #37 - Thursday, 19 December
by Caitlin Tubergen Dec. 16, 2019

Dec. 16, 2019

Dear EPDP Team: Please find below the agenda for the next EPDP Team meeting on Thursday, 19 December at 14:00 UTC. As a reminder, please find the upcoming deadlines below: Tuesday, 17 December: Deadline for review of Purposes Building Block Tuesday, 17 December: Deadline for review of Acceptable Use Policy Building Block Thank you. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #37 Proposed Agenda Thursday, 19 December 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Legal committee update b) Status of building blocks 4. Preliminary Rec - User Groups a) Review updated language and comments / suggestions provided by deadline b) Feedback from EPDP Team c) Confirm next steps 5. Preliminary Rec – Acceptable Use Policy a) Review comments / suggestions provided by the deadline in relation to edits discussed previously b) Feedback from EPDP Team c) Confirm next steps 6. Preliminary Rec - Purposes a) Review comments / suggestions provided by deadline b) Feedback from EPDP Team c) Confirm next steps 7. Homework over the holiday period a) Staff to publish updated version of draft Initial Report by 24 December at the latest with updates to the building blocks as discussed to date b) EPDP Team to flag any issues / concerns by 7 January at the latest: o please do not reopen previously closed discussions unless there is new information to consider. o If you have concerns about certain sections, please provide alternative language to address your concern but also factoring in other perspectives expressed to date. o Please do not redline but provide language suggestions in the form of comments so that these can be reviewed by all before being applied. o Minor edits (grammar, style) can be sent to the staff support team directly. 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 9 January 2020 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any

1 0

FW: Clarification on display of information of affiliated vs. accredited P/P providers
by Caitlin Tubergen Dec. 13, 2019

Dec. 13, 2019

Dear EPDP Team: Further to EPDP Support Staff’s action item to follow up with ICANN org re: the Clarification on display of information of affiliated vs. accredited P/P providers, please see the below response from ICANN org. Thank you. Best regards, Marika, Berry, and Caitlin From: Cyrus Jamnejad <cyrus.jamnejad(a)icann.org> Date: Tuesday, December 3, 2019 at 12:49 PM To: Caitlin Tubergen <caitlin.tubergen(a)icann.org> Cc: Marika Konings <marika.konings(a)icann.org>, "policy(a)bacinblack.com" <policy(a)bacinblack.com>, Karen Lentz <karen.lentz(a)icann.org>, Amanda Fessenden <amanda.fessenden(a)icann.org> Subject: Re: Clarification on display of information of affiliated vs. accredited P/P providers Hi Team, Thanks for reaching out, and my apologies on the delayed response. I hope I haven’t set you back, and I am happy to discuss further if you’d like to. I want to also thank Amy Bivins for her amazing help on this. So your request references two recommendations, EPDP Phase 1 Recommendation 14 (and its accompanying note), and PPSAI Recommendation 4. In asking, “Can you please provide clarifying information on how this recommendation is being implemented?” I understand you to be asking about PPSAI Recommendation 4. The EPDP Phase 1 IRT is in the process of implementing EPDP Phase 1, Recommendation 14. As you are aware, the PPSAI implementation (and IRT) is on hold pending the resolution of the EPDP Phase 2 work. There is no current activity underway. In term of the implementation of PPSAI Recommendation 4, the PP IRT was considering a proposed requirement that all privacy and proxy service providers include a label, which would flag each registration as a privacy/proxy registration and identify which provider is associated with that registration, in the existing WHOIS output “registrant organization” field. (See Draft PPAA, distributed to PP IRT 12 Sept 2018, at https://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20180913/426…, Section 3.15). This requirement would apply to all privacy and proxy service providers, regardless of whether the provider is affiliated with a registrar or registry operator or operating independently of any other contracted party. The draft privacy and proxy service provider accreditation agreement does not distinguish between requirements for registrar-affiliated and non-affiliated privacy and proxy service providers, at the direction of the PPSAI IRT. The draft requirements would require all privacy and proxy service providers to become accredited to continue offering those services. This requirement for accreditation would be enforced through the registrar, on the grounds that accredited registrars could not knowingly accept registrations involving a privacy or proxy service from an unaccredited provider (See PPSAI recommendation 1, note, p. 7, https://gnso.icann.org/sites/default/files/filefield_48305/ppsai-final-07de…) Following the completion of the EPDP Phase 2 work and the Rec 27 analysis, the existing draft PPSAI materials will need to be revisited to ensure consistency with the EPDP-recommended requirements, and to ensure the requirements and processes fit together in a manner that will create a transparent, predictable, and reasonable process for all parties involved. I hope this helps, and again, please reach out if more is needed. Best, Cyrus Jamnejad gTLD Accounts & Services Manager Internet Corporation for Assigned Names and Numbers (ICANN) Skype: cyrus.jamnejad.icann Telephone: +1 310 578 8635 www.icann.org From: Caitlin Tubergen <caitlin.tubergen(a)icann.org> Date: Wednesday, October 30, 2019 at 8:50 AM To: Cyrus Jamnejad <cyrus.jamnejad(a)icann.org> Cc: Marika Konings <marika.konings(a)icann.org>, "policy(a)bacinblack.com" <policy(a)bacinblack.com>, Karen Lentz <karen.lentz(a)icann.org> Subject: Clarification on display of information of affiliated vs. accredited P/P providers Dear Cyrus: On behalf of the EPDP on the Temporary Specification for gTLD Registration Phase 2 Team, we are writing to request clarification on the display of information of affiliated vs. accredited privacy/proxy providers within the context of the implementation of the Privacy and Proxy Services Accreditation Issues Working Group’s recommendations. As part its work in Phase 1, the EPDP Team made the following recommendation in its Final Report: “In the case of a domain name registration where an ‘affiliated’ privacy/proxy service used (e.g., where data associated with a natural person is masked), Registrar (and Registry where applicable) MUST include in the public RDDS and return in response to any query full non-personal RDDS data of the privacy/proxy service, which MAY also include the existing privacy/proxy pseudonymized email.” The EPDP Team went on to note, “PPSAI is an approved policy that is currently going through implementation. It will be important to understand the interplay between the display of information of affiliated vs. accredited privacy / proxy providers. Based on feedback received on this topic from the PPSAI IRT, the EPDP Team may consider this further in phase 2”. As you are aware, the Privacy and Proxy Services Accreditation Issues Working Group recommended the following, “[t]o the extent that this is feasible, domain name registrations involving P/P service providers should be clearly labelled as such in WHOIS.” Can you please provide clarifying information on how this recommendation is being implemented? Thank you. Best regards, Marika, Berry, and Caitlin EPDP Policy Development Support Staff

1 0

Notes and action items - EPDP Team Meeting #35 - 12 December 2019
by Caitlin Tubergen Dec. 13, 2019

Dec. 13, 2019

Dear EPDP Team: Please find below notes and action items from EPDP Meeting #35 on Thursday, 12 December 2019. The next EPDP Team meeting will be Thursday, 19 December at 14:00 UTC. The Legal Committee will meet on Tuesday, 17 December at 15:00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin -- Action Items EPDP Support Staff to update the Terms of Use Building Block to change “data processing agreement” to “disclosure agremeent” by Friday, 13 December. EPDP Support Staff to include a footnote in the Authorization Provider Building Block, noting the Team will return to the discussion once a decision on who will be the authorization provider by Friday, 13 December. EPDP Team to revisit the “should vs. must” discussion following additional guidance from ICANN org. EPDP Support Staff to include implementation guidance on examples of online and offline infrastructure. EPDP Team to provide examples within the updated text by Wednesday, 18 December. Upcoming Review Deadlines DateWhatTopic 17 December 2019Deadline for comments and suggestionsInitial Report language on: Purposes Acceptable Use Policy 19 December 2019 EPDP- Phase 2 call #36Address comments / suggestions received by deadline on: Purposes Acceptable Use Policy EPDP Phase 2 - Meeting #35 Proposed Agenda Thursday, 12 December 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Status of building blocks 4. Preliminary Rec #11 – Terms of Use (20 minutes) a) Review updates made as a result of previous meeting Support Staff added explanatory text to explain the different types of documents. The changes during the last call are an improvement. The note at the top of the building block is a good start to help explain. Data processing agreement seems incorrect – this should be the disclosure agreement b/w the disclosing entity and the entity requesting data. Action: Support Staff to update data processing agreement to disclosure agreement in the explanatory text. No additional comments, this building block can be closed for now. b) Review any remaining comments/suggestions c) Feedback from EPDP Team d) Confirm next steps 5. Preliminary Rec #14 - Automation a) Review comments / suggestions provided by deadline Comment from NCSG: At worst, you want to say "may" be automated, it is not a consensus policy ever, that it "must" be automated. Suggest rewording to:  "The EPDP Team recommends that those aspects of the SSAD identified below may be automated where both technically feasible and legally permissible." If automation is legally and technically feasible, that is what the system should do. The use of the word “must” is too absolute. Must should be replaced by “may”, as this provides flexibility and would not prohibit automation. Automation will be very helpful in a lot of ways, and if it can be done, it will be beneficial. However, the decision of what is automated should have flexibility – “must” should be changed to “may” or “should” At this point, it’s not clear where these decisions will be made. If automation is taken away, that will take a lot of the usefulness of the SSAD. The current wording of the language builds in discretion. Strongly believe this language has to be a “must”. There needs to be an indication of the Team’s intention here – for that reason, prefer “must”. This language was originally proposed to show that automation is allowed when technically and legally permissible. It does not matter what the ultimate model is Concern with “must” causing issues with compliance in the future If ICANN is the centralized discloser, the language may not be as objectionable Proposal to add footnote, noting that this language will be revisited once the Team decides who will make the disclosure decision. Action: Support Staff to add footnote: that makes clear that this language will be revisited once a determination has been made who is the authorization provider and note that some think it should be may instead of must. Comment on: The SSAD must allow for automation of the processing of well-formed, valid, complete, properly-identified requests from accredited users with some limited and specific set of legal basis and data processing purposes which are yet to be determined. These requests MAY be automatically processed and result in the disclosure of non-public RDS data without human intervention.  Objection with the “must” – cannot have a permissive statement and add a “must” Change the “must” to a “should” would be acceptable. However, this seems duplicative to the first paragraph. Strong “must” language is better for enforcement and explains what the policy is. There needs to be “must” language in the policy. “may” language could disappear in implementation “Disclosing entity” should be changed to “authorization provider” In Consensus policies at ICANN, the IETF definitions are used (RFC 2911) Cannot have rigidity here, as this relates to a principle-based law There is a safety valve already included It may be helpful to identify specific portions that must be automated Await guidance from ICANN org on “should” vs. “must” and revisit once guidance is received ICANN org liaisons comment: For implementation purposes, who would determine that automation is "both technically feasible and legally permissible," and when would that occur?  This is an excellent question the Team has been dancing around – the controller has to have an override on an automated system. A DPIA would have helped with this issue. Action: ICANN org question can be deferred for later once more details are worked out b) Feedback from EPDP Team c) Confirm next steps 6. Preliminary Rec – Response Requirements a) Review comments / suggestions provided by the deadline in relation to edits discussed previously - [online and offline] - Concerned that others who are reading this would not know what “online and offline” means - may be helpful to include examples - If a requestor is of the view that its request was denied erroneously, a complaint could be filed with ICANN Compliance. - Object to second sentence - If ICANN compliance is not the arbiter, then who is? - The first sentence of the paragraph deals with the requestor. Could change: ICANN Compliance should be prepared to investigate complaints about disclosure requests handled erroneously. - Question from ICANN org – this statement assumes that the CP is disclosing the data - If there is a complaint for every refusal, this would be a problem. - Action: put a pin in this when it is determined who will be making the disclosure decision b) Feedback from EPDP Team c) Confirm next steps 7. Preliminary Rec # – User Groups d) Review comments / suggestions provided by deadline Important to have user groups Language is too vague – there is no detail in the accreditation policy e) Feedback from EPDP Team f) Confirm next steps 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 19 December at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Thursday, 12 December 2019 at 14:00 UTC
by Terri Agnew Dec. 12, 2019

Dec. 12, 2019

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Thursday, 12 December 2019 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/V4EzBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call, observers can join via audio cast, listen to the recordings and read the transcript afterwards. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Terri

1 0

Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Thursday, 19 December 2019
by Terri Agnew Dec. 12, 2019

Dec. 12, 2019

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Thursday, 19 December 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) For other times: https://tinyurl.com/yyl7w7o9 Agenda Wiki: https://community.icann.org/x/WYEzBw The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Kind Regards, Terri If needed, an option to join via telephone has been added for this meeting. **New join information - Conference Bridge: Toll-free access number (US and Canada): 800 550 6865 and Toll 213 233 3193 Other telephone numbers found here: http://www.adigo.com/icann [adigo.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adigo.com_icann&d=D…> Enter passcode on telephone: 7349

1 0

Notes from EPDP Meeting #34 - Tuesday, 11 Dec 2019
by Caitlin Tubergen Dec. 11, 2019

Dec. 11, 2019

Dear EPDP Team, Please find below the notes from EPDP Meeting #34 on Tuesday, 10 December. As a reminder, the next EPDP Team meeting will be Thursday, 12 December at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #34 Tuesday, 10 December 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Status of building blocks 4. Preliminary Rec #7 – Authorization Provider >From the last meeting, there are three outstanding issues. Team members were asked to provide input, and we will go over comments received by last Sunday today. The Leadership Team proposed paths forward based on the comments proposed by the Team. Comments proposed after the deadline were not taken into account. Going forward, the Team needs to follow the suggested timelines. Please refrain from making editorial proposals to already-agreed to text. a) Consider outstanding items: · “less invasive” retain reference or not (paragraph 5). Proposal from leadership – leave the “less invasive” reference and include the ICO reference for clarity EPDP feedback: Fine with this suggestion. If people have another place to go to for data, they should go there and not use the SSAD. The word invasive is not on the ICO website; they use intrusive. A footnote will not give the appropriate guidance to the IRT. ‘Necessary’ means that the processing must be a targeted and proportionate way of achieving your purpose. You cannot rely on legitimate interests if there is another reasonable and less intrusive way to achieve the same result.  Who makes the decision about there being another means – if the authorizing entity is going to rely on this, it would be helpful for the authorizing entity to refer to what that source is Fine with invasive or intrusive. This could be addressed in some respects with development of an appropriate fee structure. If there is something that is less intrusive, the fees of becoming accredited and using SSAD will act as a disincentive for using the SSAD Agree to change to intrusive, add reasonable, and include Margie’s language Proposed implementation advice: If the basis to deny the disclosure is based on a less intrusive means, the authorizer shall identify the less intrusive means This proposal is troublesome to have a system we build point to a source that may be problematic. The discloser could not understand all reasons where data is disclosed – that is up to the requestor. If the discloser does know a different source, it could point to it, but that should not be required. This bullet is redundant – if there is a less intrusive means, that would have to be called out in the reason for denial. Agreement to remove second bullet (less intrusive means) · Geographic application (paragraph 6, sub-bullet 2 and 3) Leadership proposal to delete the bullets re: EEA and non-EEA and replace with notion to consider if balancing test is required and proceed accordingly EPDP Feedback: Important not to recommend policies that create different classes of registrants. Recommending a feasibility study is difficult to implement and also very expensive Re: geographic issue – it is not appropriate to rehash the issues that were already resolved. The Team had already talked about in the past that CPs could make geographic distinctions. The distinction in paragraph 6 artificially creates 2 classes of registrants. Suggest abandoning this distinction and apply the legal bases for all disclosure requests. Differentiating on a geographic basis could result in competitive advantages that the Team should consider This seems to be doing two steps in 1. First, is there a legal basis? If the legal basis under 6(1)(f), then the balancing test is necessary. The requestor has to state its legal basis. It is likely all laws will consider the same considerations. The concept of legitimate interest predates GDPR. Focus on legal basis and stay away from the geographic basis If I am a registrant and I live in Ireland and have an Irish registrar, the balancing test should apply. If I live in Ghana, and I have Ghanaian registrar – in that instance, should I also have the balancing test? That is what the language is trying to get it here. The Phase 2 recs could overrule the Phase 1 recommendations. This could be a 6(1)(f)-like balancing test. It may not be easy to determine if something is personal data at first glance. Replace the two points with one bullet point (noted on presentation screen) How can you determine if there is personal data? · Must/should/may (paragraph 7) [Assuming that ‘should’ cannot be enforced]: Update language to read: “If, based on consideration of the above factors, the authorization provider determines that the requestor’s legitimate interest is not outweighed by the interests or fundamental rights and freedoms of the data subject, the data is expected to be disclosed. The rationale for the approval should be documented. If all other requirements for disclosure have also been met, the data MUST be disclosed. Cleaner from a compliance perspective that MUST is preferred It needs to be must or shall. “is expected to be” should be shall Have an objection to this proposal – partly b/c we don’t know who is making the decision yet – this could mean that CPs have no wiggle room to not disclose data. Maybe need to come back to this once we have a response from DPAs. If this policy conflicts with other laws, this will move to external venue. The entire policy would be at risk if there is a box that is too narrow and remove the ability for data controllers to have any discretion at all. Cannot agree to language that has no certainty The Temp Spec uses the word “must” – this would be a step back The release valve is the qualifiers in the previous points, so the must is OK here. The other “shoulds” should be changed to “musts” This building block is now stabilized. b) Feedback from EPDP Team c) Confirm next steps 5. Preliminary Rec #11 – Terms of Use (20 minutes) a) Review comments / suggestions provided by deadline Confused as what the privacy policy is intended to address here – isn’t this covered by the disclosure agreement? Action: EPDP Support Staff to include additional language, clarifying the difference b/w the terms of use, privacy policy, and data protection agreement for EPDP Team review. b) Feedback from EPDP Team c) Confirm next steps 6. Preliminary Rec #14 - Automation a) Review comments / suggestions provided by deadline b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 12 December at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any

1 0

Data enrichment companies
by Mueller, Milton L Dec. 11, 2019

Dec. 11, 2019

I am wondering how many of the people involved in EPDP are familiar with data enrichment companies such as People Data Labs. If you're not you may be amazed at how vast is the number of people encompassed in their records, and how many data points are aggregated in them. As we battle mightily over how much disclosure of measly Whois records we will allow and under what circumstances, it might be useful to take a look at this article, https://www.dataviper.io/blog/2019/pdl-data-exposure-billion-people/ There you will see a storehouse of names, email addresses, phone numbers, social media profile information and physical addresses for 1.2 billion people, all available for subscribers to this service and - in this bizarre case - all of it exposed to anyone with the right IP address due to a configuration error of an Elasticsearch server. Based on my exposure to these data enrichment services, I think we may have found a quick solution to the SSAD problem. One could conclude that we don't need one at all, because any serious requestor can get a ton of data about virtually anyone on the internet - automatically, instantly - by using one of these services. [https://www.dataviper.io/wp-content/uploads/2019/11/data_viper_blog_v3.jpg]<https://www.dataviper.io/blog/2019/pdl-data-exposure-billion-people/> 1.2 billion people exposed in data leak includes personal info, LinkedIN, Facebook<https://www.dataviper.io/blog/2019/pdl-data-exposure-billion-people/> On October 16, 2019 Bob Diachenko and Vinny Troia discovered a wide-open Elasticsearch server containing an unprecedented 4 billion user accounts spanning more than 4 terabytes of data.. A total count of unique people across all data sets reached more than 1.2 billion people, making this one of the largest data leaks from a single source organization in history. www.dataviper.io I'll leave you all with that thought. See you Tuesday. Dr Milton L Mueller, Professor School of Public Policy Georgia Institute of Technology Internet Governance Project<https://internetgovernance.org>

4 3

**Reminder** Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Thursday, 12 December 2019
by Julie Bisland Dec. 11, 2019

Dec. 11, 2019

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Tuesday, 12 December 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) For other times: https://tinyurl.com/y5vtrdo4 [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_y5vtrdo4&d…> Agenda Wiki: https://community.icann.org/x/V4EzBw The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream02 [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/stream02.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Kind Regards, Terri If needed, an option to join via telephone has been added for this meeting. **New join information - Conference Bridge: Toll-free access number (US and Canada): 800 550 6865 and Toll 213 233 3193 Other telephone numbers found here: http://www.adigo.com/icann [adigo.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adigo.com_icann&d=D…> Enter passcode on telephone: 7349

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Tuesday, 10 December 2019 at 14:00 UTC
by Terri Agnew Dec. 10, 2019

Dec. 10, 2019

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Tuesday, 10 December 2019 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/VYEzBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call, observers can join via audio cast, listen to the recordings and read the transcript afterwards. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Terri

1 0

Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Thursday, 12 December 2019
by Terri Agnew Dec. 10, 2019

Dec. 10, 2019

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Tuesday, 12 December 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) For other times: https://tinyurl.com/y5vtrdo4 Agenda Wiki: https://community.icann.org/x/V4EzBw The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream02 Listen in application such as iTunes: http://stream.icann.org:8000/stream02.m3u Kind Regards, Terri If needed, an option to join via telephone has been added for this meeting. **New join information - Conference Bridge: Toll-free access number (US and Canada): 800 550 6865 and Toll 213 233 3193 Other telephone numbers found here: http://www.adigo.com/icann [adigo.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.adigo.com_icann&d=D…> Enter passcode on telephone: 7349

1 0