Dear Working Group members, Please see below the notes from the meeting today, 22 April 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-04-22+New+gTLD+Subsequent+Pro.... Please also see the referenced document at: https://docs.google.com/document/d/1VSrLyWvfAiwDP-pe-QhAokRVoY1rpnDhfTqViwo4-zc/edit#<https://docs.google.com/document/d/1VSrLyWvfAiwDP-pe-QhAokRVoY1rpnDhfTqViwo4-zc/edit> Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: 1. Updates to Statements of Interest: No updates provided. 2. Zoom Introduction -- Staff/hosts cannot see private chat unless it is directed at staff/hosts. That is not included in the transcript reports. Staff/hosts will not see private chat between members. 3. Update on Work Track 5 -- Review of Questions for Community Input. -- Next will begin review of the proposals. 4. Review of Summary Documents – Continuation of Discussion from ICANN64 to Reach Closure on Select Topics -- Section 2.4.3 Systems: https://docs.google.com/document/d/1VSrLyWvfAiwDP-pe-QhAokRVoY1rpnDhfTqViwo4...
 2.4.3.c.1: The ICANN organization should ensure that enough time is provided for development and testing before any system is deployed. -- Support from all commenters. 2.4.3.c.2: Systems should undergo extensive, robust Quality Assurance (QA), User Interface (UI), and Penetration testing to ensure that they are stable and secure, and that data is properly protected and kept confidential where appropriate. -- Support from all commenters. 2.4.3.c.3: Applicant-facing systems should be usable and integrated, ideally with a single login. -- Support from all commenters. 2.4.3.c.4: Once a system is in use, the ICANN organization should be transparent about any system changes that impact applicants or the application process. In the event of any security breach, ICANN should immediately notify all impacted parties. -- Support from most commenters. -- New Ideas from RySG and ICANN Org. Discussion: -- Include language of what ICANN should do when there is a security breach (from Terms of Use already vetted by ICANN Legal). See here for possible language to address Security Incidents: https://www.icann.org/en/system/files/files/nsp-terms-of-use-11may18-en.pdf 2.4.3.c.5: The ICANN organization should offer prospective system end-users with the opportunity to beta-test systems while ensuring no unfair advantages are created for individuals who test the tools. It may accomplish this by setting up an Operational Test and Evaluation environment. -- Support from all commenters. 2.4.3.c.6: As stated in section 2.4.1 above, “Any Agreements/Terms of Use for systems access (including those required to be “clicked-through”) should be finalized in advance and included in the Applicant Guidebook with the goal of minimizing obstacles and/or legal burdens on applicants. -- Support from all commenters. Discussion: -- Delete “and included in the Applicant Guidebook”. 2.4.3.c.7: Implementation Guidance regarding technical systems: Applicants should be able to enter non-ASCII characters in certain fields. -- Support from all commenters. Discussion: -- What other fields must allow IDN scripts? At least TLD. 2.4.3.c.8: Implementation Guidance regarding technical systems: Applicants should be able to access live (real time) support using tools such as a phone helpline or online chat to address technical system issues. -- Support from all commenters. 2.4.3.c.9: Implementation Guidance regarding technical systems: A single applicant should be able to submit and access multiple applications without duplicative data entry and multiple logins. -- Support from most commenters. -- New Idea from ICANN Org. Discussion: -- Request from Kobe for ICANN Org to provide specifics on what improvements would add complexity, cost, and time. -- BRG suggested that this should be a low priority. -- Neustar concerns about possible delay, but generally supportive. -- Perhaps use the term “user” as opposed to “applicant” to avoid confusion. “User” meaning an already contracted party versus “applicant” being an applicant for a new string”. Include a definition. 2.4.3.c.10: Implementation Guidance regarding technical systems: Applicants should be able to receive automated confirmation emails from the systems. -- Support from all commenters. 2.4.3.c.11: Implementation Guidance regarding technical systems: Applicants should be able to receive automated application fee related invoices. -- Support from all commenters. 2.4.3.c.12: Implementation Guidance regarding technical systems: Applicants should be able to view changes that have been made to an application in the application system. -- Support from most commenters. -- ICANN Org Concerns. 2.4.3.c.13: Implementation Guidance regarding technical systems: Applicants should be able to upload application documents in the application system. -- Support from all commenters. 2.4.3.c.14: Implementation Guidance regarding technical systems: Applicants should be able to update information/documentation in multiple fields without having to copy and paste information into the relevant fields. -- Support from most commenters. -- ICANN Org Concerns. -- Some ICANN64 Concerns re: Mission and Purpose not be appropriate for “autofill”, and issue about “autofill” in relation to Question 23 as related to “services to be rendered” in the new TLD. Discussion: -- If we recommend a policy that limits where “autofill” can be used then the systems should be consistent with that policy. This discussion is limited to a system that allows autofill (where the policy allows it). -- The systems section will not override concerns about allowing autofill for answers to certain questions. -- Could the WG agree that autofill could be allowed for fields if technically feasible except for mission, purpose, and services to be rendered -- which will be parked and returned to later. Parking lost should include Question 18 and 23, but not exclude any other question referencing mission, purpose, or proposed services. 2.4.3.c.15: Implementation Guidance regarding technical systems: Applicants should be able to specify additional contacts to receive communication about the application and/or access the application and be able to specify different levels of access for these additional points of contact. The systems should provide means for portfolio applicants to provide answers to questions and then have them disseminated across all applications being supported. -- Support from most commenters. -- ICANN Org Concerns. -- BC Divergence. -- ICANN64 Concerns. Discussion: -- Tied to c.14 so it should be consistent. 2.4.3.c.16: Implementation Guidance regarding technical systems: The systems should provide clearly defined contacts within the ICANN organization for particular types of questions. -- Support from most commenters. -- BC New Idea. -- ICANN Org Divergence. Discussion: -- BC New Idea is consistent with how ICANN Org says it is actually done. -- Need to determine if ICANN Org is in agreement with the recommendation, or to rely on the existing system. Next Steps: Leadership to rank the recommendations in the systems section -- what would be high priority, not high priority, etc. Next call: Tuesday, 30 April 2019 at 03:00 UTC for 90 minutes.