Dear EPDP Team, Below, please find the notes and action items from today’s call. As a reminder, the next EPDP Team call will be Tuesday, 8 October at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #22 Thursday, 3 October 2019 at 14.00 UTC Action Items ICANN org liaisons to informally share draft questions with ICANN org. Following review of CPH letter, the EPDP Team will determine if CPH draft questions should be included in a formal letter to ICANN org, ICANN Board, or both. EPDP Team to continue providing feedback (by group) into the lawful basis comparison table by Wednesday, 9 October at 16:00 UTC. EPDP Support Staff to review the feedback provided and provide a summary to the EPDP Team by Thursday, 10 October. James Bladel to provide an illustrative but non-exhaustive list of examples of illegitimate requests or requests of an abusive nature by Tuesday, 8 October. James to also consider how the list could be included in the building block I/L (query policy). (Note: Mark Sv. has offered to assist.) EPDP Support Staff to provide suggested updates to building block L (query policy) based on today’s discussion following receipt of James and Mark Sv’s updates. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. 1. Roll Call & SOI Updates (5 minutes) · Attendance will be taken from Zoom · Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Confirmation of agenda (Chair) · Following Chris D’s suggestion from the F2F meeting, the CPH will be circulating a draft letter to the EPDP list shortly. The draft letter includes questions to the ICANN Board. 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from legal committee · LC met on Tuesday and continued discussing draft questions, some of which came out of the F2F meeting. · At this time, no additional questions have been agreed to. · Volunteers from the LC will be drafting high-level summaries of the legal memos from Batch 1. · The next LC meeting will be Tuesday, 15 October b) Finalization of questions to ICANN Org · Suggestion to ask these questions to the Board · Recommend referring the questions to Org, or sending to both Org and Board · Do these draft questions differ greatly from the CPH letter? · Recommend tabling this draft letter until the EPDP Team has reviewed the draft CPH letter · ICANN org needs to determine if this is a board or an org question. ICANN legal may need to be consulted on this. The EPDP Team needs an authoritative answer from ICANN on these answers. · Action: ICANN org liaisons to informally share draft questions with the org, as appropriate. Following review of CPH letter, the EPDP Team will determine if CPH draft questions should be included in a formal letter to ICANN org or the ICANN Board. c) Lawful basis input document [docs.google.com] – status · During F2F meeting, it was agreed to look at building blocks in conjunction with the lawful bases. For example, with respect to content and criteria of a request, is there a different set of information that is required for a 6(1)(d) vs. a 6(1)(e) request? · There may not be a difference in requirements b/w the lawful bases · Question: are groups still planning to provide feedback or if, alternatively, this is no longer a helpful exercise? · Tying the request to lawful basis in not a good match - it’s unnecessarily constraining the exercise. · Groups to continue providing input to the lawful basis table by 8 October, and Support Staff to summarize input for the EPDP Team. d) Status of building blocks · The building blocks are all housed on a separate wiki page · When work has been completed, the building block will be marked in green · The other objective of the status page is to show when building blocks will be discussed, and when input following a discussion is due · Because the building blocks are in Google Doc format, the EPDP Team may provide feedback in advance 4. Query Policy [docs.google.com] (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 · “not legitimate or of an abusive nature” - will that be defined in this policy development phase, or is that developed in the implementation phase? · This is a question that EPDP Support Staff flagged in the Zero Draft - noting that examples would be helpful. · This question will likely be kicked down to the implementation review team; however, there is needs to be some leeway for the disclosing entity. An illustrative, but non-exhaustive list would be helpful · Consider using SSAC advice here, which was included in the BC accreditation example · One challenge is making sure everyone can understand the policy language - specificity is helpful here. Refer to SSAC advice. · This language was provided in a use case. · Just as the system can recognize abusive behavior, there needs to be flexibility for the requestor to make high-volume requests. ICANN itself may need to make high-volume requests as well. · Abusive and vexatious can be content specific. It may also be helpful to provide guidelines on what is NOT considered abusive. · If the recipient of a request, and a requestor has sent 10,000 queries and another requestor who has sent three requests, could the requestor who sent three be potentially blocked from a response while the 10,000 queries are being handled. · If there are a provider who has to answer 10,000 from one and three from another, the provider must serve all 10,003 · This building block is closely related to the financial building block, b/c this is not a free service. That may be one of the natural rate-limiting factors - payment for requests. · The language here was from the use case discussed in Marrakech. Brian and Mark had agreed to review subpoint b, but that homework may no longer be necessary. · Perhaps subpoint a and b can be combined · Keeping the two separate makes sense, but place a full stop after misuse of the system. · The language should ensure that if there is redacted data, the public data should be provided along with it. · There was a suggestion that the response should not include public data elements - it would be helpful if the inclusion of public data elements are a must, should, should not, etc. · If this system displays public and non-public data elements, it will be used for both. The concern would be that the system will be used when public data fields are sufficient. · Assuming there is a centralized system, there may well be a decision made to integrate WHOIS with the SSAD - it may be an effective way to unify those two systems - that’s an implementation decision, and it shouldn’t be forbidden · It does not make sense that anyone would build a separate system for SSAD and would not leverage the existing system. If authentication to the SSAD fails, it would simply return the public data. · Assuming that people are using the SSAD are requesting nonpublic data - it is fairly trivial to return the nonpublic information with the private information. There is framing of the topic that is invalid, specifically in reference to fee structure. One of the responsibilities of Rys and Rrs is to provide core services of WHOIS. Refer to SSAC101. Because of rate limits in the current environment, it is very hard to get public information. Tucows the second largest registrar in the world, but they limit users to one query per minute. · In principle, no objection to returning full WHOIS record along with undisclosed information. However, the people that want this are planning to set up some sort of automated query system that would use the data for anything. · Challenge is this is not a technical issue; if it is coming through SSAD, a human being has to review the request - if a public WHOIS channel, it’s automated. One query per minute, is 86,000 queries per day. If a user of the system is warranted in making 86,000 queries per day, curious as to what the entity may be using the data for. Potential solution - this is conditional - if you submit a request through SSAD and it is successful, you get the full data in return. · Proposal: The response must include the public data elements related to the domain name registration associated with the requested non-public data. · If the Team could somehow assume that there is a system in which one entity will be responsible for taking on the responses and the disclosure responsibility, the conversation could be easier. · Why does the language, “each request needs to be evaluated on its own merits” need to be here - seems like a truism · Statement should remain · What is the purpose of the footnote added by James and Mark? · The purpose is if these go forward, these are applicable to the system in the Rr’s governance with ICANN and would not eliminate their use in other products and services by companies that are contracted parties with ICANN. Other products such as SSL and hosting may have valid & legitimate reasons to share data outside of SSAD. c) Confirm next steps · Team to revisit this building block when James has provided the non-exhaustive list · Staff to reword the language re: return of public data for valid requests 5. Acceptable use policy [docs.google.com] (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 [docs.google.com] (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