October 2019 - Gnso-epdp-team

Questions for ICANN Org from EPDP Team Chair
by Marika Konings Nov. 19, 2019

Nov. 19, 2019

Dear ICANN org liaisons, On behalf of Janis Karklins, in his capacity as EPDP Team Chair, please find hereby a number of questions for ICANN org he would appreciate a response to as soon as possible: Does ICANN have a clear preference on whether or not it will: 1. Field these requests for non-public data 2. Maintain its own RDS replica database 3. Make a/the determination of the validity of the request 4. 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) 5. Consider an approach whereby ICANN acts as a more or less “gateway” for authorized data to pass through, data provided by the Contracted Party at the request of ICANN (per contractual requirement), with the responsibility for such disclosure to be assumed by ICANN. 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…>.

2 1

EPDP Phase 1 Consultation from GNSO Council regarding recommendation #12
by Rafik Dammak Nov. 1, 2019

Nov. 1, 2019

Dear EPDP Team, As the GNSO Council liaison to the EPDP Team, I wanted to provide you with an update on the status of consultations with the ICANN Board in relation to parts of the EPDP Phase 1 recommendations that were not adopted by the ICANN Board (recommendation #1, purpose 2 and recommendation #12 – deletion of org field data). Most recently: ● The GNSO Council wrote to the ICANN Board to share its take-aways from the engagement with the ICANN Board on this topic during ICANN65, to which a number of EPDP Team members contributed (see https://gnso.icann.org/en/correspondence/gnso-council-to-icann-board-09sep1… ). ● The ICANN Board provided a response (seehttps:// gnso.icann.org/en/correspondence/chalaby-to-drazek-14oct19-en.pdf) which the Council discussed during its most recent meeting on Thursday 24 October 2019. As part of its consideration of the Board’s response, focusing on recommendation #12 –deletion of data, Council members tend to agree with the ICANN Board that everyone has the same goal in mind here “which is ensuring there are no inadvertent consequences of the deletion of data while ensuring compliance with applicable laws”. The Council, based on the input that has been provided by EPDP Team members, assumed that this notion was already implied in recommendation #12. However, noting the Board’s concern, the Council discussed during the 24 October meeting whether this could be made more explicit, for example in the form of implementation guidance, similar to how a safeguard was included in relation to the deletion of administrative data (“prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains Registered Name Holder contact information”). Before further pursuing this approach (by way of an implementation guidance, instead of modifying recommendation #12), the Council would like to hear from the EPDP Team if there are any concerns about doing so or any other input the Council should consider as it aims to conclude the consultations with the ICANN Board. I realize that it is short notice, but if there are any initial reactions that I can take back to the GNSO Council before Sunday 3 November, this may already be informative as the Council will meet with the ICANN Board during ICANN66 and is expected to discuss this topic further during the Council meeting which is scheduled for 6 November 2019. I will also check with Janis to see if there are a couple of minutes we can carve out from the Saturday session to get some initial reactions. Looking forward to hearing from you. Best Regards, Rafik Dammak GNSO Council liaison to the EPDP Team

6 6

EPDP-P2 - Project Package - Close of October 2019
by policy＠bacinblack.com Oct. 31, 2019

Oct. 31, 2019

Dear All, Please find attached the EPDP-P2's close of October 2019 Project Package. I've attached the PDF here, but you can find individual work products and the raw MPP file on the wiki (https://community.icann.org/x/6BdIBg) All in all, the project health is still On-Track and On-Schedule. We are slightly behind schedule at the task level related to our building blocks. EPDP leadership is aware of this and in response made the decision to increase the group's call volume through the time to Initial Report delivery. Project Package Contents: * Page 1 - Summary Gantt chart timeline * Page 2 - Fact Sheet - summary schedule of financial condition as managed by the PCST sub-team * Page 3 - Situation Report - details about project health and current state activities * Page 4 - Project Plan; partially collapsed. If a detailed task view is required, please advise and I can print a fully expanded version. * Page 5,6 - Work Plan / Action Items - Active * Pages 7+ - Work Plan / Action Items - Closed Thank you. B Berry Cobb @berrycobb GNSO Policy Consultant

1 0

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