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

Balancing Test Framework
by Crossman, Matthew Oct. 30, 2019

Oct. 30, 2019

All, Following the LA meeting, the RySG agreed to consolidate Alan Woods' 6.1(f) procedural document and the legal advice received on the balancing test. Attached is our simplified framework of non-binding guidance to assist controllers in performing the 6.1(f) balancing test. 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

Overview of ICANN66 meetings and input requested on plenary questions
by Marika Konings Oct. 30, 2019

Oct. 30, 2019

Dear EPDP Team, As discussed during today’s meeting, please find hereby the overview of EPDP Phase 2 related meetings: * Saturday, 02 November - 08:30-18:30 (https://66.schedule.icann.org/meetings/1116817) * Sunday, 03 November - 17:00-18:30 (https://66.schedule.icann.org/meetings/1116819) * Monday, 04 November - 15:15-18:30 (https://66.schedule.icann.org/meetings/1116825) * Thursday, 07 November - 13:30-15:00 – (https://66.schedule.icann.org/meetings/1116842) Other EPDP related meetings that may be of interest: * Monday, 04 November - 10:30-12:00 – Plenary Session EPDP Phase 2 * Wednesday, 05 November - 08:30-10:15 – EPDP IRT (1 of 2) * Thursday, 07 November - 08:30-10:15 – EPDP IRT (2 of 2) For the plenary session, please find attached the proposed outline that was shared during today’s meeting. If you have any suggestions for questions to be asked for the interactive part of the meeting, please share these with the list by Wednesday 30 October at the latest. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 1

Notes and action items - EPDP Team Meeting #28
by Marika Konings Oct. 29, 2019

Oct. 29, 2019

Dear EPDP Team, Please find below the action items and notes from today’s EPDP Team meeting. Best regards, Caitlin, Berry and Marika EPDP Team Meeting #28 Tuesday, 29 October 2019, 1400 UTC Action Items 1. Alex Deacon to reconcile the Accreditation BB and remove references to framework and make it clear this is the policy for the Accreditation Authority. 2. Registrar team to review brackets in sub-point f and confirm that it aligns with https://rrsg.org/minimum-required-information-for-whois-data-requests/. 3. Alex Deacon with the assistance of staff support to review EPDP Team input received re. Single identity / multiple authorizations and propose updates to section F. 4. Margie and Volker to propose revised language for sub-point n), consider splitting into two points, one for individuals and one for entities. 5. James to propose language for sub-point q). 6. James and Greg to work on proposed modifications to sub-point t). 7. Reminder: EPDP Team to review all building blocks and policy principles, and provide input on those building blocks and/or parts not finalized yet as well as policy principles by Wednesday 30 October at 21.00 UTC. After that, building blocks will be considered frozen and comments received by that date will form the basis for deliberations at ICANN66. 8. Support staff to send out calendar invites for the EPDP Team meetings at ICANN66. (COMPLETED) 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.<https://community.icann.org/x/ZwPVBQ> 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a. ICANN Org questions to the EDPB · Team to consider any clarifying questions for ICANN to send to the EDPB · Procedural question - what is the status of this letter? · During the Los Angeles F2F, the Strawberry Team noted it was hesitant to share questions before sending to the EDPB. · Thought the Strawberry Team would share the questions with the EPDP Team after they shared the questions with the European Commission · Suggest not attaching questions to this document - EPDP should distance itself from this document as much as possible. Many assumptions in the document do not represent consensus within the team. · May be helpful for the Team to consider this letter with time frames attached to it, including when the Strawberry Team is expecting to receive a response. · There was a need for prior consultation before getting the document to the Board. EC colleagues who were able to speak with the Belgian DPA. ICANN wanted to have answers from the Board before sending to the EPDB. The EPDB and the Belgian DPA are informed about this paper, but the response is unlikely to come in before ICANN66. · Unhappy with this situation. EPDP Team asked for the document to be shared prior to dispatching to EDPB. This causes frustration and burnout for volunteers to see their efforts bypassed. There is talk to defend the multi-stakeholder model at the global level, but this undermines the multi-stakeholder model. EPDP Team should put something on the record that this has not been reviewed nor endorsed by the EPDP Team. · The Team knew from the beginning that the Strawberry Team has been working on a set of questions to the EPDB. From the beginning, the EPDP Team was cognizant that it was developing a standard where a UAM may be one of several options. This paper is not completely contradictory to the Team’s work. The Team can factor in any response in its work. · Team to formulate questions for Strawberry Team and EDPB. · The Team should not devote time to this effort in Montreal. Every action the Strawberry Team has taken has been done without the consultation of the EPDP Team. Any time spent on this seems to legitimize an illegitimate, bootleg process. · Do not agree with how this process was conducted, but answers could help us. · Any response from the EDPB, if any, will not be helpful to the EPDP Team because it is based on assumptions the EPDP Team has no consensus on - for example, that the UAM is a benefit to registrants. b. Status of building blocks · A new google doc was added for the policy principles. 4. Accreditation - (building block f and j) – second reading continued (30 minutes) a) Review comments & input provided · Request for Team members to refrain from wordsmithing and focus on concepts. b) Feedback from EPDP Team Proposed Definitions · Question from ICANN org - what are the criteria for selecting an accreditation authority? · There is still work to be done in cleaning up the language from the original framework (which assumed multiple accreditation authorities). The accreditation authority is assumed to be ICANN org. If ICANN wants to outsource this responsibility, it can. The Team has agreed that a single accreditation authority will be run by ICANN org and it can outsource identity verification to zero or more third parties. · How ICANN ultimately runs this is up to it, but ICANN will be ultimately responsible for the accreditation authority role. · Definition of credential - the terms validation and verification are clarified here. This is based on an RFC for security credentials that is standard in the industry. · Where this is a defined term used in the text of a definition (like validate or verification), it is capitalized. · Definition of de-accreditation of accreditation authority- this needs to be discussed more. What is the process to revoke or reassign the credentials. · While this is an implementation issue, text should be added to protect accredited users. · If ICANN org is the accreditation authority perhaps de-accreditation will never happen. It may be that we need to flesh out de-accreditation of 3rd party identity providers ICANN may leverage. · Subpoint q, which deals with de-accreditation, fleshes out more details with respect to de-accreditation. · If ICANN org is going to be the accreditation authority, a framework is not needed, and this language can be removed. · What does this word framework mean in this context? · What is the difference b/w framework and policy recommendations? What is in this framework and what is the purpose of it? · Subpoint A · This is unclear - how can it accommodate single users if they have to be accredited? · If accreditation is added before requirements, would this address the above concern? · Subpoint C · The word preferably seems to imply this is not a requirement. · Action item: Alex Deacon to reconcile the document and remove references to framework. · Subpoint E · Can “must” be taken out of brackets? · Why does this say “benefits of accreditation”? · It could be that the benefits of accreditation section could be moved within this building block · Is accreditation just verification of identity? This section, particularly Subpoint F, tries to explain the benefits. · Some of these points seem to be policy recommendations, not describing the benefits of accreditation · Maybe the word benefits should be removed? · Subpoint F · Some of the bullet points will not be disclosed when accreditation is applied for. Some of these bullets will be disclosed at the time of the disclosure request - such as legal basis. · Agree that some assertions will be provided at the time of disclosure request. · If these assertions are associated with an identity, they would be passed on as defaults, so the purpose may be identified by the identity provider. · A credentialed user could select purposes not associated with that credential? If an enterprise has multiple functions and purposes - does it make sense for this type of enterprise to have multiple credentials that apply to each type of purpose it has? · Inextricably linking an identity credential with authorization details is a bad security process. Envisioning a single door with a combination of keys - who are you (identity credential) and what assertions are you making with regard to your request. Can limit the purposes a user can assert in a request, but it would be a mistake to require users to manage many identity credentials for different types of requests. · Shouldn’t technically cripple the system because we are afraid of policy decisions that could happen because the system is more capable. · Single identity per user, that single identity may have multiple authorizations but each authorization should be tied to one single purpose. Should not cross pollinate. · Registrars to confirm that requirements align with https://rrsg.org/minimum-required-information-for-whois-data-requests/. · Action item: Registrar team to review brackets in sub-point f and confirm that it aligns with https://rrsg.org/minimum-required-information-for-whois-data-requests/. · Action item: Alex with the assistance of staff support to review EPDP Team input received re. Single identity / multiple authorizations and propose updates to section F. · Sub-Point g) h) i) j) l) m) o) · No comments · Sub-Point n) · As RySG provided in its input, if someone has violated the rules, there should not be any graduated penalties for user. Access should be revoked. · If an individual working for an entity has credentials revoked, this should also be extended to any officers of that entity. If you have a company that has users that are accredited, is a bit much that the entire organization’s credentials are removed? Maybe consider different standard for revocation for individual vs. organization? Consider that organizational credentials should only be revoked based on a showing of systematic organizational abuse? Is trust has been breached by individual, it does apply to the whole organization - maybe there are ways to regain that trust? Organization will be responsible for legal consequences of misconduct, but punishing other parts of the organization for it is problematic, there needs to be a way to remediate. Graduated sanctions also exist under the RAA - consider applying that here? Reinstatement of individuals may not be an option / desirable. Need to ensure that repercussions are of such a nature that it deters bad behavior. · Action item: Margie and Volker to propose revised language for sub-point n), consider splitting into two points, one for individuals and one for entities. · Sub-Point p) · How would CPs know that someone has been de-accredited and would try to get access by going directly to a CP? This is providing a work around for a revoked entity. Either take p) out completely, or if you leave it in, there needs to be a feedback loop to CPs. Maybe publication of revocation lists similar to certs · Action item: delete sub-point p) · Sub-Point q) · Need to flesh out a little bit more what happens to outstanding credentials in the case of the de-accreditation of the accreditation authority. · May need to distinguish between policy actions vs. criminal actions. There are parallels in the Ry and Rr agreements - graduated sanctions for violation of the contract, but if you are found to be a criminal, that skips you to the end. · Also need to address what happens to users if/when accreditation authority is de-accredited. · Action item: James to propose language for sub-point q. · Sub-Point s) · Sub-point t) · See RrSG comment - must be limits on how many requests can be submitted. This language prevents technical operator to protect the system against abuse like a DDOS attack. Language needs to be loosened up a bit. May also be addressed in cost-recovery section? As written feels like a blanket prohibition on any access controls. The words “poses a demonstrable threat’ is intended to cover issues such as DDOS attacks. Maybe requests beyond a certain quota are not subject to SLA performance requirements? With a high volume, direct request to CP might make more sense? Not a solution as SSAD is supposed to facilitate these kinds of high volume requests.  Need to avoid having one party decide what is abusive or decide what volume they respond to. SSAC is of the view that if a request is legitimate, it needs to be responded to. Not necessarily a technical problem but an economical problem. · Action item: James and Greg to work on proposed modifications to sub-point t). · Continue from point n) in Montreal. c) Confirm next steps 5. Auditing Requirements (building block New) – first reading a. Review building block b. Feedback from EPDP Team c. Confirm next steps Deferred 6. Logging requirements (building block NEW) – first reading a. Review building block b. Feedback from EPDP Team c. Confirm next steps Deferred 7. EPDP Meetings and Proposed Agenda for ICANN66 a. Overview of meetings and proposed agenda (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-October/002711.html) b. Reminder: EPDP Team to review all building blocks and policy principles, and provide input on those building blocks and/or parts not finalized yet as well as policy principles by Wednesday 30 October at 21.00 UTC at the latest. After that, building blocks will be considered frozen and comments received by that date will form the basis for deliberations at ICANN66. * See agenda circulated * 4 EPDP Team meetings throughout the week, plus plenary session on Monday * Action item (reminder): EPDP Team to review all building blocks and policy principles, and provide input on those building blocks and/or parts not finalized yet as well as policy principles by Wednesday 30 October at 21.00 UTC. After that, building blocks will be considered frozen and comments received by that date will form the basis for deliberations at ICANN66. * Action item: Support staff to send out calendar invites for the EPDP Team meetings at ICANN66. 8. Wrap and confirm next EPDP Team meeting (5 minutes) a. Saturday 2 November from 8.30 – 18.30 local time b. Confirm action items c) Confirm questions for ICANN Org, if any Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

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

Oct. 29, 2019

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Tuesday, 29 October 2019 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/L5ACBw> (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, 14 November 2019
by Terri Agnew Oct. 29, 2019

Oct. 29, 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, 14 November 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/y3x7rdor Agenda Wiki: https://community.icann.org/x/DoEzBw 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 Enter passcode on telephone: 7349

1 0

Notes and action items - EPDP Meeting #25 - 17 Oct 2019
by Caitlin Tubergen Oct. 28, 2019

Oct. 28, 2019

Dear EPPD Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Tuesday, 22 October at 14:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #25 Proposed Agenda Thursday, 17 October 2019 at 14.00 UTC Action Items Support Staff to update the text of the Accreditation Building Block and Financial Sustainability Block based on today’s discussion. EPDP Team to provide additional edits in the Accreditation Building Block re: implementation guidance and definitions by COB tomorrow, Friday, 18 October. EPDP Team to provide additional edits from today’s conversation to the Financial Sustainability Block by Friday, 18 October. EPDP Volunteers needed to propose initial text for Building Block M – Terms of Use/Disclosure Agreements/Privacy Policies by Monday, 21 October. 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee b) Status of building blocks 4. Accreditation (building block f and j) – second reading continued (30 minutes) a) Overview of implementation guidance section b) Feedback from EPDP Team Principle b Requirements should be spelled out as part of the policy discussion There will be different types of entities and may have different documentation to provide These requirements should be as uniform as possible C may need to come before B There needs to be an underlying baseline of requirements that are uniform. Accreditation is all about identification; thought the group agreed that accreditation is at a minimum about identity, but it could also establish other things as well – such as law enforcement, cyber security, etc. It would be helpful to draw a line b/w the accreditation process and what needs to be included in the disclosure request – parties seeking accreditation should probably not have to include every scenario where a law enforcement would have to interface with the SSAD – hoping the Team can be more specific with baseline requirements for accreditation Law enforcement will likely have a different accreditation system than other entities, so that conversation should be separate What does accreditation mean? The group discussed the potential for allowing for the automatic disclosure where allowed under the law suggest “and automation of responses where possible under applicable law” Accreditation does not equate to automated response by default – each query will be decided upon on its own merits Certain types of people (user groups) may allow for streamlining – some categories may involve more scrutiny – to that extent, accreditation is more than authentication of identity By adding too much into one subject, the discussion is encumbered. The discussion of accreditation and authentication should be decoupled. The small team for accreditation agreed that accreditation is not authorization. It might be desirable and helpful to have attributes associated with accreditation. The only attribute that will consistently make a difference is whether it is law enforcement or not. With respect to cyber security researchers, any IT person could legitimately claim to be doing cyber security research. There shouldn’t be entry barriers that say you are or are not cyber security researchers. The building block includes a list of definitions, which the Team has not yet discussed. If accreditation only proves identity, the Team is limiting what it can discuss with regard to the release of data. Support Staff to try to analyze what was said during the conversation with respect to Subpoint B and Subpoint C for online consideration Principle d What is the expectation for what de-accreditation means? Accreditation would be that the accreditation is who they say they are; as a result, there is access to the system without further verification of identity. If an entity is de-accredited, it would need to be re-accredited. This would mean that the authority could revoke access to the system, not “de-accredit”. Principle g What is the accreditation policy and requirements – where is this? The accreditation policy and associated requirements have not been drafted/implemented yet Principle i Issue with replaced “must be paid for service” with “cost-recovery system” – this could suggest that the costs need to be covered by another form. The whole system is for the benefit of third-party users who would request disclosure of registration data – concerned with costs being shifted to registrants Two types of costs involved – development and deployment of the system and then the cost of day-to-day running of the system The costs need to be considered in a cost-recovery system. The purpose of accreditation is to lower these costs. Whatever cost-recovery system takes place – these costs need to be recovered from the users of the system, not from registrants or contracted parties. Have issues with the terms “significantly reduce”. This is a separate system. The Team really needs to consider a cost-benefit analysis of figuring out someone’s ID – how much will this actually cost? Is it achievable? Perhaps the second sentence could be moved to Block N. There are two sets of development costs – accreditation system and SSAD. This paragraph should be limited to the development of the accreditation system. Re: development of SSAD – that should be moved to Building Block N. Agree with moving the second sentence to Building Block N. If the benefit exceeds the cost, there needs to be an escape valve in the policy. As a policy principle, it should be the benefits of the SSAD system must outweigh the costs. If there are too many requirements, the system will be too expensive. Avoid saying the costs outweigh the benefits. This language needs more work to make it clear what the team is after. Maintain first sentence and delete second sentence This conversation can be moved to the financial building block. Registrants do get something from the SSAD – a reliable and secure DNS. The SSAD is not a clean slate – the current system is the registrars having to do the work themselves, and someone is paying for this. There is a clean and reliable DNS system today – to say “cleaner” and “more reliable” would be preferable. Costs may be occurring in other areas that are offset for a system that doesn’t currently exist is problematic and disproportionate. Principle k The use of the word “tagging” is confusing Marc to submit proposed updated online What is the meaning b/w the first and second sentence? The SSAD takes requests from accredited and unaccredited users, so unaccredited users will be treated a different way. RDAP is a query response protocol, where you query the system and get a response back. There will now be instances where some queries will be responded to right away and others will be queued (for balancing tests have to be conducted) and the response will be returned later – RDAP was not designed to be used in this way. The second sentence in k does not make sense. Implementation Guidance Feedback Drafting note c – legitimate and lawful purpose described above (stated) Some implementation belongs in the policy – a and b could be left in implementation guidance. C and D could be left in the policy language as opposed to implementation guidance. De-accreditation – this will depend on what the specifics of accreditation are and what it would mean for someone to be de-accredited At the F2F, the Team talked about de-accreditation for the users of the system and the accrediting entities. E and G are potentially in conflict with each other. What does access to the system mean? Even bad actors should have access to the public data. This hinges on unaccredited users having access to the system – is the SSAD being used by everyone, or just accredited users? Can the Team agree that the SSAD could be used by both accredited and non-accredited users? The difference is that accredited entities will query the system w/o verification of the entity. SSAD should be usable by everyone and not exclude anyone How one does identity verification is a decision ICANN should be making in the public interest. Concern that individuals should not be prevented from getting access to data they may need to protect their domain name c) Confirm next steps Support Staff to update the text of the Accreditation Building Block based on today’s discussion. EPDP Team to provide additional edits in the Google Doc for implementation guidance and definitions by COB tomorrow, Friday, 18 October. 5. Financial Sustainability (building block n) – second reading a) Overview of updates made following first reading b) Feedback from EPDP Team Third paragraph: cost-recovery basis is used in multiple places. The Team needs to define this term. Cost-recovery is a term of art in accounting, and that definition is probably not what the Team meant here. Cost recovery may mean different things to different people. Also, what does “historic costs” mean in this context? The users of the system should be sustaining the capability of the system on an ongoing basis. Second paragraph – object to contracted parties bearing the costs. Different parties will bear different costs – this language does not explain that division of responsibilities. For example, accredited entities will bear the costs of getting accredited. The parties who are receiving the queries that contracted parties would be responsible for setting up their systems to receive queries and respond to them. Registrants being beneficiaries of the system may be a tenuous argument Fourth paragraph – in favor or usage-based fees that sustain the operation of this system. A system cannot be costed out unless we know what the system is designed to do. c) Confirm next steps 6. Terms of use / disclosure agreements / privacy policies (building block m) – first reading a) Review building block b) Feedback from EPDP Team c) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 22 October 2019 at 14.00 UTC b) Confirm action items c) Confirm questions for ICANN Org, if any

13 33

For your review - accreditation building block by Friday 25 Oct COB
by Marika Konings Oct. 28, 2019

Oct. 28, 2019

Dear EPDP Team, Please note that staff has gone ahead and cleaned up the accreditation building block per today’s discussion for your review and input: https://docs.google.com/document/d/1-90NgBnkZt8mRL2acJUPOwoIkx5clvXlCaCC3RA…. As per the action items from today’s meeting, please provide any further edits or comments by Friday 25 October COB in the google doc. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

3 2

ICANN Org questions to the EDPB
by Janis Karklins Oct. 28, 2019

Oct. 28, 2019

Dear Team members, This morning Goran shared with me the Strawberry paper, which has been sent to the European Data Protection Board. This paper outlines a Unified Access Model (UAM) based on the Technical Study Group’s technical model <https://www.icann.org/en/system/files/files/technical-model-access-non-publ…>, which the Strawberry team described to the Team in Marrakech and at our meeting in Los Angeles. The questions to the EDPB are outlined in Section 8 of this paper. ICANN Org is asking the European data protection authorities to provide substantive input on these issues. Any answers that will be provided ICANN Org will forward to the EPDP to inform our policy discussions. At the same time Goran suggested that if the EPDP would have any further questions to ask of the DPAs, we should send them to Goran for subsequent communication to the EDPB. Of course, the Team can also ask questions to Georgios who is working at the European Commission. I hope you will find the document informative. We have planned to discuss ICANN Org input in one of the Montreal Team meetings. I do not intend to open discussion about this document during our upcoming Tuesday's call. Thank you for your consideration JK

2 1

**Reminder** Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Tuesday, 29 October 2019
by Julie Bisland Oct. 28, 2019

Oct. 28, 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, 29 October 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/y6qusxhq [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_y6qusxhq&d…> Agenda Wiki: https://community.icann.org/x/L5ACBw 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 [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<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

Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #26 - 22 Oct 2019
by LEWIS-EVANS, Christopher Oct. 27, 2019

Oct. 27, 2019

OFFICIAL Marc Sorry for the delay in response, We have tried to cover release off with the last sentence “Confidential requests can be disclosed to data subjects in cooperation with the requesting authority, [and] [or] in accordance with the data subject's rights under applicable law.” There are two points here to consider the first is that the volume of confidential requests will be low but also the request from Data subject for how their data has been used will also be a small percentage of these confidential requests. So working in cooperation would not be too onerous on the CP’s and is what happens now in many case’s outside of this environment. Thanks Chris Lewis-Evans From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Anderson, Marc via Gnso-epdp-team Sent: 25 October 2019 18:04 To: jbladel(a)godaddy.com; caitlin.tubergen(a)icann.org; gnso-epdp-team(a)icann.org Subject: Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #26 - 22 Oct 2019 Thank you James and Chris. One follow up question for you. When we met as a small team on this topic, one of the concepts discussed was that confidential requests shouldn’t automatically remain so indefinitely. I’m curious if you considered this at all and if so, why it wasn’t included in the proposed draft text. 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: Friday, October 25, 2019 12:43 PM To: Caitlin Tubergen <caitlin.tubergen(a)icann.org<mailto:caitlin.tubergen@icann.org>>; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: [EXTERNAL] Re: [Gnso-epdp-team] Notes and action items - EPDP Meeting #26 - 22 Oct 2019 NOTE – This was sent to the “bounces” address in error. Sorry for the delay! - JB ------------------------------- Caitlin, Janis & ePDP Team – Chris and I have been hammering out some draft text for Building Block H, sub-bullet (h) (Caitlin’s Action Item #3, below). Chris is offline at the moment, but here’s where we have landed for discussion during tomorrow’s call: Disclosure of RDS data to the type of third parties must be made clear to the data subject. Upon a request from a data subject the exact processing activities of their data within the SSAD, should be disclosed as soon as reasonably feasible. However the nature of legal investigations or procedures may require SSAD and/or the disclosing entity keep the nature or existence of these requests confidential from the data subject. Confidential requests can be disclosed to data subjects in cooperation with the requesting authority, [and] [or] in accordance with the data subject's rights under applicable law. 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>> Date: Tuesday, October 22, 2019 at 4:26 PM To: "gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Subject: [Gnso-epdp-team] Notes and action items - EPDP Meeting #26 - 22 Oct 2019 Notice: This email is from an external sender. Dear EPDP Team: Please find below the notes and action items from today’s EPDP Team meeting. As a reminder, the next EPDP meeting will be Thursday, 24 October at 1400 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. Amr to propose new text re: Building Block d, subpoint c<https://docs.google.com/document/d/1irlBo_oE5WqxTir5URaxlpPWTn17cnjDz72L79g…> on compatible purposes – for Building Block d based on today’s discussion by Thursday, 24 October. 2. Support Staff to review subpoint d and ensure relevant points are captured in the Auditing building block by Wednesday, 23 October. 3. Chris Lewis-Evans to work with colleagues to update Building Block h, subpoint h<https://docs.google.com/document/d/1irlBo_oE5WqxTir5URaxlpPWTn17cnjDz72L79g…> by Thursday, 24 October. 4. Support staff to review and revise Building Block h, subpoint i<https://docs.google.com/document/d/1irlBo_oE5WqxTir5URaxlpPWTn17cnjDz72L79g…> based on today’s discussion by Wednesday, 23 October. 5. EPDP Team to provide concerns and objections (if any) to the Priority 2 next steps proposal by Friday, 25 October. 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. EPDP Phase 2 - Meeting #26 Tuesday, 22 October 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) 1. Proposed outline for EPDP Plenary Session at ICANN66 · This plenary session, previously known as the Cross-Community session, was requested by the GAC and GNSO. · EPDP Support Staff drafted questions to discuss in the plenary session. The EPDP Team is welcome to suggest targeted questions that could generate discussion during the plenary session. 1. Questions to ICANN Org (request to provide input by ICANN66) · Questions originally raised by James and edited by the EPDP Team were shared informally with ICANN org · Would the Team object to Janis asking ICANN org to respond to the questions that were already shared informally? · Should these questions be asked to the Board in addition to Org? · Janis will send these questions to Goran under his capacity as chair. 1. Status of building blocks<https://community.icann.org/x/k5ICBw> · The Team has not completed any additional building blocks since the last meeting. · Encourage Team members to make an extra effort to provide input and follow through on action items. · In the event any member is unable to complete homework by the deadline, please provide an update with an updated deadline. · In the next agenda item, Janis has requested agreed items to be highlighted in green. Text highlighted in green should not be questioned unless there was a misunderstanding. · Additionally, there are now two new building blocks for auditing and logging requests. · Input is sometimes provided very close to the call, which does not give other team members time to provide feedback. Perhaps prior to the Montreal meeting, there will be a date where all documents are frozen so that everyone can work towards a specific deadline. · IPC will provide input on the accreditation building block by EOD today. · Marc A. and Hadia to include updated text for accreditation shortly. 4. Acceptable use policy [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (building block D and H) – second reading continued 1. Overview of updates made 2. Feedback from EPDP Team Subpoint c · Still awaiting updated language from Margie and Amr for subpoint c · Margie and Amr have not yet reached agreement on language; they did agree that a requestor could make a request for disclosure under more than one purpose · Have difficulty in accepting that the disclosee could change the purpose. If the disclosee is going to state specific purposes, that needs to be the purpose under which they process the data. The requestor cannot make subtle changes to the purposes after receiving the data. · If this language is in the law, please specify the problem. · The data subject is going to be told that data will be given to people who have a specific standard and/or purpose(s) as stated. The controller/processor cannot say, “or other purposes as updated”. This dilutes the initial notice to the data subject. Also, the data subject will not know who the disclosee is until there is an access request. · Article 5 of GDPR – data is not further processed in a matter that incompatible with the purposes for which the data was collected. · Agree with the above suggestion, but for one issue. Prevent a situation where someone requests data under false pretenses. There needs to be a safeguard that prevents this. · The purposes for which a requestor may request data is not the same as the original purposes for which the data is collected. The requestor has to seek permission from the primary controller on any further processing, and the determination as to whether further processing is incompatible needs to be made by the primary controller. · The recipient of the data is now the controller; however, that recipient has no nexus with the registrant. Absent independent oversight, there is now a new controller with data. There are recent examples (like Equifax) to ensure there is a necessity test before release of data and that the recipient of the data will responsibly use the data. · The theoretical nature of this discussion is blocking resolution. When we have defined the language which will be presented to the registrant, and when we have discussed some examples of compatible/incompatible, this will be more clear.  · Action: Amr to revise the language of subpoint c and provide to the list for discussion by Thursday, 24 October. · Margie and Amr do agree that multiple purposes can be submitted for each request. Trying to solve: if after the disclosure has taken place and the requestor comes up with a new purpose that was not disclosed, can the requestor process data for the purpose that was not disclosed? Subpoint d · This should be further explained in the auditing section · What is the purpose for the requestor to submit the lawful basis for the processing to take place? The controller has to have a lawful basis. The requestor can provide a lawful basis they think the controller may use, but not sure why this is included. Building Block H Subpoint h · This has not yet been agreed, so James and Chris L-E are working to update this in advance of Thursday’s call Subpoint i · The use of double negatives in not ideal · There is one issue of releasing a name and another about releasing identity of a person that may be harmed. It is difficult for a registrar to respond to requests by local law enforcement authorities. This point should be split. How to handle human rights defenders is a difficult problem. · Local laws justify sanctions that may be disproportionate to an offense that has taken place. Disclosure requests must not go further than where MLATs are in place. Subpoint a · No disagreements from the Team to remove the word “necessary” 1. Confirm next steps 5. Query Policy [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (building block i and l) – second reading continued 1. Overview of updates made 2. Feedback from EPDP Team Subpoint a and accompanying list · This is too subjective – what is high-volume to one registrar may be low-volume to another. How can this be implemented to get something that is less subjective. · Bullet point six is troublesome – there are undefined terms “mine” and “harvest” are very subjective. · Third bullet point notes quotas – this inclusion is problematic. Additionally, rate limiting is also problematic. If someone is submitting a legitimate request, this needs to be accepted and considered. The third bullet should be deleted. · Receivers of queries now decide what frequency or number of requests they want to receive unilaterally, but that may not work in the new system. Accordingly, bullet 3 and 6 are problematic. · This list includes terms that are present in the 2013 RAA. There are two ways to resolve this: be specific as possible or secondly, roll them all up to commercially reasonable efforts to prevent abuse. Team members need to appreciate that there are bad actors, and the SSAD will be a big target. There needs to be mechanisms to safeguard this system – specific safeguards will allow for bad actors to abuse the system. The system should not handcuff providers to burdensome obligations – a small registrar may not be able to handle this, for example. · GDPR requires adequate and technical measures in place to protect data. In the legal world, the measures would not be published. There needs to be volume control. It may be helpful to look how registries did this. · One key issue here – there needs to be some reference to proportionality. Registrars range in size radically - what is high-volume to one registrar may be low-volume to another. · Just as the Team considers bad acting requestors, the Team also needs to consider bad acting registrars. · Users of data and suppliers of data need to have a common understanding. · Enumerating abuse may be problematic – perhaps the commercially reasonable approach should be used to give flexibility to the providers. · The Team needs to find middle ground so that compliance can take action against bad actors. · The commercially reasonable approach is a nonstarter. · Support Staff to determine where the “proportionate” idea can be placed. 1. Confirm next steps 6. Priority 2 items – proposed next steps (see attached) 1. Overview of leadership team proposed next steps · This document was shared with the agenda. · Recommendations factored in the small team’s proposals Privacy/Proxy · Questions around how this issue may already be addressed by the PPSAI policy · This implementation is currently on hold, but perhaps the implementation review team has taken into account this issue – proposal for support staff to reach out to colleagues on PPSAI for further information Legal vs. Natural · Confirm with colleagues re: status of the study and associated timeline. · In parallel to study being undertaken, Legal Committee could review what questions (if any) should be submitted prior to the completion of the study. City Field · Legal advice came in at the end of Phase 1 · Legal committee to review and analyze the legal advice and review additional legal questions that have been proposed Data Retention · Staff to confirm what the status of ICANN org’s work to review data retention procedures and see if the retention period recommended in Phase 1 needs to be updated. OCTO · Follow up with OCTO colleagues – and see if the position during Phase 1 has changed. Based on feedback received, Team would consider what the appropriate next steps are Uniform Anonymization · Legal Committee to review the questions received thus far for the Team to have an informed discussion on this WHOIS Accuracy and ARS · This is a topic b/w ICANN org and the GNSO Council – trying to review scope of this work – await further guidance on this before proceeding further. 1. Feedback from EPDP Team · Staff should proceed with the next steps · The legal vs. natural study is not dependent on the implementation of Phase 1 recommendations. · Would Team agree to a lunchtime presentation of the terms of reference to the legal vs. natural study. · EPDP Team to provide objections to the Priority 2 proposal by Friday, 25 October. 1. Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Thursday 24 October 2019 at 14.00 UTC 2. Confirm action items 3. Confirm questions for ICANN Org, if any ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ This information is supplied in confidence by NCA, and is exempt from disclosure under the Freedom of Information Act 2000. It may also be subject to exemption under other UK legislation. Onward disclosure may be unlawful, for example, under data protection legislation. Requests for disclosure to the public must be referred to the NCA FOI single point of contact, by email on PICUEnquiries(a)nca.gov.uk. All E-Mail sent and received by NCA is scanned and subject to assessment. Messages sent or received by NCA staff are not private and may be the subject of lawful business monitoring. E-Mail may be passed at any time and without notice to an appropriate branch within NCA, on authority from the Director General or their Deputy for analysis. This E-Mail and any files transmitted with it are intended solely for the individual or entity to whom they are addressed. If you have received this message in error, please contact the sender as soon as possible.

1 0