September 2019 - Gnso-epdp-team

Updated building block E - retention and destruction of data
by Caitlin Tubergen Oct. 7, 2019

Oct. 7, 2019

Dear EPDP Team: Further to EPDP Support Staff’s action, please find the updated version of Building Block E (retention and destruction of data). The edits intend to capture the Team’s discussion from the last meeting. As the building block is in the form of a Google Doc, please provide suggested edits directly in the document by Monday, 7 October. Thank you. Best regards, Marika, Berry, and Caitlin

6 5

Proposed Agenda - EPDP Team Meeting #22 - Thursday 3 October at 14.00 UTC
by Marika Konings Sept. 30, 2019

Sept. 30, 2019

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday 3 October at 14.00 UTC. Please make sure to review the relevant google docs and provide your input ahead of the meeting. As a reminder: 1. EPDP Team members to review and provide edits to the registrar-proposed questions to ICANN org<https://docs.google.com/document/d/1N66JcJ_1C9agknQGfJ22BG2L564hBS-w3k8ItZI…> to by Tuesday, 1 October. Best regards, Caitlin, Berry and Marika =============== EPDP Phase 2 - Meeting #22 Proposed Agenda Thursday, 3 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) a) Update from legal committee b) Finalization of questions to ICANN Org<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> c) Lawful basis input document<https://docs.google.com/document/d/1U9jt9nOHs9QMjWTDl7UPaT--9aD2lHZI/edit> – status d) Status of building blocks<https://community.icann.org/x/k5ICBw> 4. Query Policy<https://docs.google.com/document/d/13boFDslLC00MpuIhQV7yhwq0LPjZ-gz79pTmL-j…> (building block i & l) – second/final reading (15 minutes) a) Overview of updates made in response to input received during F2F meeting (James Bladel, Mark Svancarek) b) Feedback from EPDP Team c) Confirm next steps 5. Acceptable use policy<https://docs.google.com/document/d/1irlBo_oE5WqxTir5URaxlpPWTn17cnjDz72L79g…> (building block d & h) – Second reading (15 minutes) a) Overview of updates made following first reading b) Feedback from EPDP Team c) Confirm next steps 6. Criteria & content of requests<https://docs.google.com/document/d/1EOZY0oNiBrtAOZeka3LCMwyMiaGjSJLVDTcyVl4…> (building block a) – Second reading (15 minutes) d) Overview of updates made following first reading e) Feedback from EPDP Team f) Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): a) Tuesday 8 October 2019 at 14.00 UTC 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

questions for Bird & Bird
by Greg Aaron Sept. 27, 2019

Sept. 27, 2019

Dear Leon et al: Following up on the first round of answers from Bird & Bird and the F2F, SSAC would like to following to be reviewed by the legal sub-team and sent to Bird & Bird. We've tried to make sure that these are new questions and are not duplicative of info we got from the first batch. The SSAC team feels these are important questions to ask per the current work and the charter. BALANCING, AND RIGHT TO OBJECT: The defense of networks, the prevention of fraud, resisting cybercrime, and indicating possible criminal acts or threats to public security to a competent authority are tasks performed by third parties who are not law enforcement or government agencies. Such parties have legitimate interests in making data requests under GDPR, notably under Article 6(1)f; see also Recitals 47, 49, and 50. We are considering balancing where the data subject may be infringing upon the rights of others, and the safety of third-party requestors who deal with cybercrime. The third-party purposes above also require timely responses to data requests. Assume that registrars notify their registrants up-front of the purposes of data collection, under what circumstances the data may be released, the right to object, etc. a. When a data controller receives a legitimate third-party data request, under what circumstances is the controller required under GDPR to explicitly notify the data subject that a request has occurred, and/or that it has provided data to a third party? b. Under what circumstances do data subjects have the right to object under GDPR to the release of their data to third parties? Per Bird & Bird's Question 3 memo, ICANN's use cases do not involve profiling or highly sensitive data categories (race, political affiliation, etc.), and "a decision to release information via the SSAD is would not in itself have legal effect on the data subject." c. Are data controllers ever required to notify the data subject of the identity of a third-party requestor? d. Please confirm: when a data subject objects to processing, the decision to release the data resides with the data controller? e. If a registrant must be notified of a request and then be given the opportunity to object, please explain how this process can be reconciled with or integrated into a SSAD that is designed to provide timely data exchange when possible and does not involve "a decision based solely on automated processing". (See Bird & Bird's Question 3 memo, paragraph 1.12.) LEGAL VERSUS NATURAL PERSONS: Registration data submitted by legal person registrants may contain the data of natural persons. For example the contact data they provide may include a natural person's name and email address. Legal person registrants also have the ability to publish non-personally identifiable contact data ("admin(a)companyname.com") should they desire. If registrants are required to self-identify as either a natural or legal person, then: a. Can registrars rely on that self-identification? b. Can registrars make the contact data submitted by legal person registrants publicly available in RDS (WHOIS), by stating that it is the responsibility of a legal person registrant to obtain consent from any natural person whose data it submits? Please state any considerations, such as the ability of the registrant to correct its data. As part of the analysis, please examine the policies of the Internet protocol (IP address) registries RIPE NCC (the registry in Europe, based in the Netherlands) and ARIN (the registry in North America, which has customer contacts in Europe). These registries publish the data of natural persons who are subject to the GDPR, publicly via their WHOIS services, by placing the choice and responsibility on their registrants, who are legal persons. IP addresses and domain names are two sides of the same coin, and these IP address registries state mission justifications and collection purposes similar to those in ICANN's Temporary Specification. See: 1) "How We're Implementing the GDPR: Legal Grounds for Lawful Personal Data Processing and the RIPE Database": https://labs.ripe.net/Members/Athina/gdpr-legal-grounds-for-lawful-personal- data-processing-and-the-ripe-database 2) "How We're Implementing the GDPR: The RIPE Database": https://labs.ripe.net/Members/Athina/how-we-re-implementing-the-gdpr-the-rip e-database 3) "Personal Data Privacy Considerations At ARIN": https://teamarin.net/2018/03/20/personal-data-privacy-considerations-at-arin / 4) ARIN "Data Accuracy": https://www.arin.net/reference/materials/accuracy/ 5) ARIN Registration Services Agreement, paragraph 3: https://www.arin.net/about/corporate/agreements/rsa.pdf 6) ARIN Privacy Policy: https://www.arin.net/about/privacy/

2 1

Accreditation Homework
by Alex Deacon Sept. 26, 2019

Sept. 26, 2019

All, You can view the current state of the Accreditation details Milton and I have been working on in the following Google Doc - https://docs.google.com/document/d/1hWT8narH9v3zaBkGllYq3t3zMDlwhQ9tp-RB9iU… A summary of where we ended up is listed below. We can discuss these (and other) details on our Thursday call. Regards, Alex 1) Single Accreditation Body or Multiple? - Alex believes that there will be multiple Accreditation Bodies and a framework to accredit the accreditors is required. - Milton is not convinced we will need such a complex policy and there should be a single uniform general accreditation process that ICANN is responsible for. 2) Code of Conduct - Alex believes that a properly crafted Accreditation Body Baseline Policy, Trusted Accreditation Body Program Policy and an Accreditation Body Practice Statement (as described in his framework) will result in a uniform code of conduct for all sector based Accreditation Bodies. (Note that sector specific accreditation requirements would be added on top of this uniform code of conduct.) - Milton agrees, but thinks the Code of Conduct should be uniform for all SSAD users and should not vary by sector or accreditation body. 3) Authentication vs. Authorization - I think there is agreement between Alex and Milton here. - The framework doc now defines a set of terms, including authentication, authorization and their related credentials. Accrediting Bodies assist in the creation of both authentication credentials and authorization credentials. - The ultimate decision to authorize disclosure of registration data, based on validation of the authentication credential, authorization credentials, and any other data contained in the request, will reside with the registrar, ICANN, or whatever party we ultimately agree on. 4) Individual Users - Both Alex and Milton agree that any accreditation framework must not rule out individual users from accessing non-public RDS data. - Three options have been proposed and how to best accomplish this is still TBD. 5) Accreditation and User Group - This is the largest ares of disagreement. - NCSG is opposed to relying on accreditation bodies that emerge from user groups that benefit from easy access to the data and that Accreditation Bodies should not be responsible for auditing and enforcing accreditation of their own users, as this creates a conflict of interest. - Alex does not agree. The proposed framework (with the safeguards, auditing, monitoring, complaints process, de-accreditation, etc.) is sufficient to address Milton's concerns. - Having said that both Milton and Alex agree that auditing entities must be independent. 6) Accreditation and Financial sustainability - Alex/IPC believes more detail is needed before we can have a constructive conversation on fees. - Milton states that his and NCSG's views were articulated in LA. ___________ *Alex Deacon* Cole Valley Consulting alex(a)colevalleyconsulting.com +1.415.488.6009

3 2

Notes and action items - EPDP Phase 2 Meeting #21 - 26 September 2019
by Caitlin Tubergen Sept. 26, 2019

Sept. 26, 2019

Action Items 1. EPDP Team members to review and provide edits to the registrar-proposed questions to ICANN org to by Tuesday, 1 October. 2. Support Staff to edit the accreditation building block in accordance with materials received and the discussion during today’s meeting by Monday, 7 October. 3. Support Staff to edit the retention building block in light of today’s discussion by Tuesday, 1 October. EPDP Team members to review edited language and provide suggested updates (if any) by Monday, 7 October. 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. EPDP Phase 2 - Meeting #21 Proposed Agenda Thursday, 26 September 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. RrSG proposed questions for ICANN Org (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-September/002504.html) Does ICANN have a clear preference on whether or not it will: · Field these requests for non-public data · Maintain its own RDS replica database · Make a/the determination of the validity of the request · Assume responsibility for this decision, in any scenario where ICANN doesn’t hold the data directly and must require a Contracted Party to respond to the Requestor (even if the Contracted Party disputes ICANN’s determination). EPDP Team Feedback: On 20 September, Registrars sent a message to the list re: questions for ICANN org liaisons. With respect to James’ message, should this question be funneled through ICANN org liaisons, or should it go directly to the Board? The preferred timing would be to receive input from the Board or ICANN liaisons before ICANN66 In terms of the recipient, if the questions are directed to the ICANN Board, the Board liaisons can relay the questions to the Board. Are EPDP Team Members allowed to provide feedback on this? Re: point 2, the way it is currently written may imply that ICANN maintaining a replica database is the only option The intent was to see if ICANN would be open to a replica database, not to presuppose that would be the ultimate route, but this can be reworded to be more clear. Uncomfortable that ICANN’s responses may be dispositive of the policy. If ICANN says it will not be responsible, does that mean the EPDP Team cannot make recommendations where ICANN has the responsibility? It is useful to raise these questions to ICANN org and ICANN Board, but irrespective of the answers the EPDP Team receives, the EPDP Team needs to review the questions with caution. The ultimate application of the law will be up to the DPAs, not ICANN. Even if ICANN has a preference for one of the options, the assumptions in this message have not been agreed upon by the EPDP Team. For example, the EPDP Team has not agreed that a replica database is preferred. The goal of this message should be to understand ICANN’s position in the event the EPDP Team proceeds with any of the approaches in the message. Action: Support Staff to distribute a Google Doc with James’ proposed text so the Team can finalize the questions during the next call on Thursday, 3 October. 4. Accreditation (building block f & j – see attached) (45 minutes) Overview of updates made in response to input received during F2F meeting (Alex Deacon, Milton Mueller) The EPDP Team should have received a link to a google doc yesterday. The document Milton and Alex have been working on is roughly based on the accreditation model Alex presented in LA. Is there a single body or multiple accreditation bodies? Answer: no agreement – IPC notes there should be multiple accreditation bodies, while NCSG notes there should be one accreditation body (ICANN) Code of conduct – difference of option whether this should be a uniform policy or differentiate by sector Included a set of definitions that defines authentication and authorization Accreditation framework must not rule out individual users The idea of user groups is an area of divergence for IPC and NCSG. IPC believes de-accreditation and auditing can allow for user groups; NCSG does agree with the concept of user groups. The linkage b/w accreditation and user groups is the primary area of disagreement b/w NCSG and IPC. Re: financial consideration – thought the group agreed that groups wanting accreditation would pay for accreditation Review of “ideal accreditation model” proposals submitted by IPC, BC, SSAC, and GAC to cover their respective communities, outlining what the baseline accreditation requirements could be as well as the attendant benefits of accreditation within the architecture of an SSAD BC ICANN can accredit the accreditors, rather than be the sole accrediting body, particularly in light of the presentations the Team heard in Marrakech. As part of accreditation, there needs to be authentication – that a purpose is identified, processing will be compatible with the purpose stated. Graduated penalties and de-accreditation would apply if there is abuse Re: fees – all applicants should pay a non-refundable application fee. Three levels of accreditation – one-time access, intermittent users, regular access – graduated accreditation fees based on type of user Logging responsibility – activity would be logged by the entity providing access and The logs would include the and the accredited entity, the purpose, the query and the day Logs would be retained for two years in a machine-readable format and logged information would remain confidential but could be revealed with legal justification. A third-party firm should be chosen to randomly audit logs Accredited entities would agree to safeguards De-accreditation does not prevent the requestor from submitting manual requests for access SSAC Accreditation is required for a party to participate in the access system (SSAD). Unaccredited parties can make data requests outside the system. Accreditation provides safeguards, with the goal of making the exchange of data as routine and as swift as possible within the law. Accreditation emphasizes the responsibilities of the data requestor (recipient), who is responsible for complying with the law. Accreditation will focus on the requirements of the law, such as requirements regarding data retention length, secure storage, organizational data controls, and breach notifications. Therefore the accreditation guidelines should be the same across all accrediting bodies (if there is more than one). A common and standardized set of practices and language is highly desirable to manage the accreditation and operational processes, extending to common legal documents. There is not yet a demonstrated need for accreditation requirements to vary from one industry sector to another. Some data requestors may participate in more than one industry sector and may make queries with different purposes (for example, cybercrime versus intellectual property disputes). What matters more is the legitimate bases for the queries they make rather than what kind of organization they are. Accreditation is granted to an organization (not specific individuals within an organization). Accredited parties are authorized to participate in the SSAD system and receive the necessary access/authentication credentials from a central authority. Accreditation does not guarantee disclosure of the data. Accreditation is for a period and must be renewed occasionally. Any auditing of the activities of accredited parties must be performed by a neutral third party auditor. Log data is confidential. Accreditation may be revoked by the accrediting body. Parties that violate the law are responsible to the state authorities responsible for enforcing the law. The cost of becoming accredited must not be onerous on parties that have a demonstrated need for the data but have limited means. Feedback from EPDP Team GAC circulated a response re: the GAC’s view on accreditation. It recognizes that this is more complicated when it comes to the accreditation of public authorities. Concerns with a single entity identifying law enforcement – perhaps identification could be done by a national entity, but the credentialing aspect could be handled by a global entity. Accreditation can be thought of as an authentication function, but not a dispositive function. ICANN could be the accreditor of accreditors at the very least. Many potential users of the SSAD will be in multiple groups – does this mean these users would have be accredited by multiple bodies? One condition of the system is the user needs to make legitimate queries, or it will be kicked out Accrediting entities should not propose themselves as accrediting bodies – at the very least, ICANN should accredit the accreditors There may be different groups that have different roles, but everyone within the group has their own API or credential, so that this is trackable at the individual level, not the group level. For multiple accreditations – if all accreditors impose the same rules, there shouldn’t be a need for multiple accreditations. Re: user groups – if the first clause is removed, perhaps that language is OK. In short, it is not about law enforcement. As far as credentials, the organization would be accredited, and the organization receives credentials. Discarded the notion of self-accrediting bodies The Team has not agreed on user groups and accreditation bodies Agreed to standardized method for accrediting accreditors – by ICANN The Team has not covered law enforcement enough at this time Confirm next steps Support Staff to edit the accreditation building block in accordance with materials received and the discussion during today’s meeting by Monday, 7 October. 5. Query Policy (building block i & l – see attached) – second/final reading (15 minutes) a. Overview of updates made in response to input received during F2F meeting (James Bladel, Mark Svancarek) b. Feedback from EPDP Team c. Confirm next steps 6. Retention and destruction of data (BB e) – Second reading (15 minutes) a. Overview of updates made following first reading (see attached) b. Feedback from EPDP Team The portion about the relevant data processing arrangements is unclear It may mean the arrangement b/w requestors and their accrediting body, but it could also apply if the requestor and data protection body entered into a data processing arrangement The language could mean that the agreement referenced here is part of the accreditation process The purpose of the broad language at this time could allow for different scenarios, as the Team has not agreed on the structure of the system. No objection to the fact that retention is on a case-by-case basis. Perhaps the second sentence could be reworded – it needs to be clear in what is meant. The retention is limited by the purpose that the data is being requested. The purpose limitation, and if the request is a 6(1)(f), part of the balancing test may be how long the data will be retained for. c. Confirm next steps Support Staff to edit retention building block in light of today’s discussion by Tuesday, 1 October. 7. Lawful basis table – see https://docs.google.com/document/d/1U9jt9nOHs9QMjWTDl7UPaT--9aD2lHZI/edit [docs.google.com] (10 minutes) a. Initial review of input provided RrSG is the only group to provide timely input. RrSG notes that while this table addresses GDPR lawful bases, the Team needs to be forward-thinking that requirements need to not just account for GDPR but also future data protection legislation Support staff to provide further guidance on the goal of this exercise b. Confirm next steps 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 3 October 2019 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, 26 September 2019 at 14:00 UTC
by Terri Agnew Sept. 26, 2019

Sept. 26, 2019

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Thursday, 26 September 2019 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/_YUCBw> (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

purpose of lawful basis table exercise
by Caitlin Tubergen Sept. 26, 2019

Sept. 26, 2019

Dear EPDP Team: During today’s meeting, some EPDP Team members expressed confusion with the purpose of the Lawful Basis Table. The underlying idea of the table is to determine whether a specific lawful basis may necessitate different requirements with respect to the building blocks of the SSAD, and if so, what the different requirements may be. By way of example, should the response time requirement differ if there is a vital interest vs. a legitimate interest? As a reminder, the action item captured during the F2F meeting was: Support Staff to create a table (in the form of a Google Doc) which includes a column for each lawful basis and a column for what a requesting party would be required to provide in its request, what is the expected response time, is automation likely, what are the standardized categories that may fall within that lawful basis, etc. Following receipt of the table, the EPDP Team members to populate the contents of the table. If there are commonalities, policy recommendations can be drafted accordingly. We hope that helps clarify the purpose of the table. Best regards, Marika, Berry, and Caitlin

1 0

Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Thursday, 03 October 2019
by Terri Agnew Sept. 26, 2019

Sept. 26, 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, 03 October 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) 07:00 PDT, 10:00 EDT, 16:00 Paris CEST, 19:00 Karachi PKT, 23:00 Tokyo JST, (Friday) 00:00 Melbourne AEST For other times: https://tinyurl.com/y2f23xpm Agenda Wiki: https://community.icann.org/x/-4UCBw 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

FW: Proposed Agenda - EPDP Team meeting #21 on Thursday 26 September at 14.00 UTC
by Heineman, Ashley Sept. 26, 2019

Sept. 26, 2019

From: Heineman, Ashley Sent: Thursday, September 26, 2019 9:59 AM To: Marika Konings <marika.konings(a)icann.org>; Alex Deacon <alex(a)colevalleyconsulting.com>; King, Brian <Brian.King(a)markmonitor.com>; Margie Milam <margiemilam(a)fb.com>; Mark Svancarek (CELA) <marksv(a)microsoft.com>; Georgios.TSELENTIS(a)ec.europa.eu; LEWIS-EVANS, Christopher <Christopher.Lewis-Evans(a)nca.gov.uk>; Ben Butler <bbutler(a)godaddy.com>; Greg Aaron <greg(a)illumintel.com> Cc: gnso-epdp-lead(a)icann.org Subject: RE: [Gnso-epdp-team] Proposed Agenda - EPDP Team meeting #21 on Thursday 26 September at 14.00 UTC Hi Marika and apologies for the delayed response. This issue has proven to be a complicated matter for the GAC as it pertains to “accreditation” for Public Authorities and is something still under consideration for us. For what it is worth, we as the GAC and GAC small group are reflecting on the attached slide we’ve developed. We are considering, but have not reached a formal view, on what different options we have. This includes potentially having the identification function being performed at the national level and credentialing could happen at a more or less global level (for lack of a better characterization). In light of this, we are not in a position at this stage to provide a best case model for accreditation from the GAC perspective. Thanks for following up, Ashley (on behalf of the GAC small group) From: Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> Sent: Wednesday, September 25, 2019 10:48 AM To: Alex Deacon <alex(a)colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com>>; King, Brian <Brian.King(a)markmonitor.com<mailto:Brian.King@markmonitor.com>>; Margie Milam <margiemilam(a)fb.com<mailto:margiemilam@fb.com>>; Mark Svancarek (CELA) <marksv(a)microsoft.com<mailto:marksv@microsoft.com>>; Georgios.TSELENTIS(a)ec.europa.eu<mailto:Georgios.TSELENTIS@ec.europa.eu>; LEWIS-EVANS, Christopher <Christopher.Lewis-Evans(a)nca.gov.uk<mailto:Christopher.Lewis-Evans@nca.gov.uk>>; Ben Butler <bbutler(a)godaddy.com<mailto:bbutler@godaddy.com>>; Greg Aaron <greg(a)illumintel.com<mailto:greg@illumintel.com>>; Heineman, Ashley <AHeineman(a)ntia.gov<mailto:AHeineman@ntia.gov>> Cc: gnso-epdp-lead(a)icann.org<mailto:gnso-epdp-lead@icann.org> Subject: FW: [Gnso-epdp-team] Proposed Agenda - EPDP Team meeting #21 on Thursday 26 September at 14.00 UTC Hi IPC, BC, GAC, and SSAC reps, Can you please confirm whether you will be sharing any documents in relation to agenda item #4b? Thanks, Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> Date: Tuesday, September 24, 2019 at 13:16 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: Re: [Gnso-epdp-team] Proposed Agenda - EPDP Team meeting #21 on Thursday 26 September at 14.00 UTC Please note that an additional item has been added under item 3 (see below). Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> Date: Tuesday, September 24, 2019 at 12:20 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] Proposed Agenda - EPDP Team meeting #21 on Thursday 26 September at 14.00 UTC Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday 26 September at 14.00 UTC. Best regards, Caitlin, Berry and Marika =============== EPDP Phase 2 - Meeting #21 Proposed Agenda Thursday, 26 September 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. RrSG proposed questions for ICANN Org (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-September/002504.html<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.…>): Does ICANN have a clear preference on whether or not it will: · Field these requests for non-public data · Maintain its own RDS replica database · Make a/the determination of the validity of the request · Assume responsibility for this decision, in any scenario where ICANN doesn’t hold the data directly and must require a Contracted Party to respond to the Requestor (even if the Contracted Party disputes ICANN’s determination). 4. Accreditation (building block f & j – see attached) (45 minutes) a) Overview of updates made in response to input received during F2F meeting (Alex Deacon, Milton Mueller) b) Review of “ideal accreditation model” proposals submitted by IPC, BC, SSAC, and GAC to cover their respective communities, outlining what the baseline accreditation requirements could be as well as the attendant benefits of accreditation within the architecture of an SSAD c) Feedback from EPDP Team d) Confirm next steps 5. Query Policy (building block i & l – see attached) – second/final reading (15 minutes) a) Overview of updates made in response to input received during F2F meeting (James Bladel, Mark Svancarek) b) Feedback from EPDP Team c) Confirm next steps 6. Retention and destruction of data (BB e) – Second reading (15 minutes) a) Overview of updates made following first reading (see attached) b) Feedback from EPDP Team c) Confirm next steps 7. Lawful basis table – see https://docs.google.com/document/d/1U9jt9nOHs9QMjWTDl7UPaT--9aD2lHZI/edit<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goog…> (10 minutes) a) Initial review of input provided b) Confirm next steps 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 3 October 2019 at 14.00 UTC 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://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> and visiting the GNSO Newcomer pages<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…>.

1 0

FW: Query policy homework
by Mark Svancarek (CELA) Sept. 26, 2019

Sept. 26, 2019

Apologies for the late submission - I initially failed to include the list when sharing with staff. James and I were tasked to review two things: (1) whether the verbiage required changing and (2) whether it was in the scope of the Charter to include it at all. Verbiage Since the Charter does not directly prohibit such a thing, we proceeded to review the existing language. We suggest only a minor grammatic change to the bullet. "The EPDP Team recommends the SSAD, in whatever form it eventually takes: (a) Unless otherwise required or permitted, must not allow bulk access, wildcard requests, reverse lookups, nor Boolean search capabilities. (b) Must only return current data (no data about the domain name registration's history); (c) Must receive a specific request for every individual domain name (no bulk access); (d) Must direct requests at the entity that is determined through this policy process to be responsible for the disclosure of the requested data." Our comments are: * Bullet A * During the F2F in Los Angeles, some members proposed removing this restriction entirely. This was opposed by others, including RrSG, RySG, and some ISPCP and NCSG. * During the F2F in Los Angeles, some members proposed removing the first qualifying clause, beginning with "...not allow bulk access". This was opposed by some members, and the preferred option for some RrSG, RySG and NCSG members. * During the F2F in Los Angeles, some members have proposed leaving this item as-is. This was less desirable for some RrSG, RySG, ISPCP and NCSG who were concerned that these facilities would be required elsewhere in the system. * Bullet C * No objections, but redundant with the equivalent (first) prohibition listed in (a) We also considered whether a further definition of "SSAD" might be helpful, resulting in the following text: "SSAD" is here defined as a system of data disclosure developed under consensus policy and contractually enforced by ICANN. Development of SSAD does not prevent entities from developing additional data processing agreements outside of the consensus policy process to serve their business or customer interests. Charter As mentioned about, the Charter does not directly prohibit us from discussing such topics. However, Thomas' reasoning is compelling and I attach it for completeness. Mark and James

1 0