Dear Working Group members, Please see below the notes from the meeting today, 09 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-09+New+gTLD+Subsequent+Pro.... Please also see the referenced document at: https://docs.google.com/document/d/1VSrLyWvfAiwDP-pe-QhAokRVoY1rpnDhfTqViwo4... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: 1. Updates to Statements of Interest (SOIs): No updates provided. 2. Review of Summary Documents – Continuation of Discussion from ICANN64 to Reach Closure on Select Topics (see: https://docs.google.com/document/d/1VSrLyWvfAiwDP-pe-QhAokRVoY1rpnDhfTqViwo4...) Overview: -- Goal is to get to generally agreed principles. -- May be some things labeled as a new idea, but we will discuss all new ideas. -- Jeff Neuman added some notes to the document to stimulate discussion. -- First cite background information, then policy goals, summary of the public comments, then themes and new concepts. 2.4.1 Applicant Guidebook: Policy Goals -- Suggested edits: * An Some form of the Applicant Guidebook should be utilized for future new gTLD procedures. * However, Usability, clarity, and practicality should must be priorities when drafting future versions. 2.4.1.c.1: Work Track 1 generally agreed that an Applicant Guidebook (AGB) of some form should continue to be utilized in future waves of applications. The Work Track generally agreed, however, that the Applicant Guidebook should be made more user friendly. Themes/trends: * Support from all commenters New Ideas/Concepts for Deliberations * BC: New Idea - make the document less English-dependent, since language plus the complexity of the subject matter can make understanding challenging. * What about recommending that legalese should be avoided? * How about recommending a Companion Guide (eg., Applications for Dummies) that would not be controlling, but provide for assistance? * To the extent possible, use Plain Language Text: https://www.plainlanguage.gov/about/definitions/ * But legal and accounting terms may be important for clarity and accuracy. Discussion: -- Avoid being too prescriptive with respect to language since some legal terms may be necessary. -- We are leaning towards implementation guidance (“should” versus “must”). -- Trying to boil the BC comment down to actual language/practical implementation. -- What does BC mean by “less English-dependent”? That is a BC comment. -- Example: https://www.plainlanguage.gov/about/definitions/ 2.4.1.c.2: In order to enhance accessibility for ease of understanding, especially for non-native English speakers and those that are less familiar with the ICANN environment, the Work Track believes that the AGB should: * Translations of AGB should be released soon after English version. Themes/trends: * Support from all commenters New Ideas/Concepts for Deliberations * See aboveNone Discussion: -- Don’t think the ALAC comment disagrees – AGB can be free from historical context, but it could be included in a companion guide. -- Question: Will the AGB be available in other languages? We will get to that concept a little later. 2012 was published in the UN languages, so unless we recommend something different that would be the status quo. -- Justine Chew (in the Google Doc): Sure. I can't see why something like a Companion Guide won't work. Subject to my first comment on the need to notify that terms and conditions in AGB are not displaced. 2.4.1.c.2.1: Be less focused on historical context and to the extent it is included, concentrate this content in appendices if possible. Themes/trends: * Support from all commenters New Ideas/Concepts for Deliberations * ALAC: Concerns - The historical context is important and needs to be readily available. * Note from Jeff: I think both can be achieved (namely, having an Applicant Guidebook that is free of historical context, but having in the Companion Guide (or elsewhere) the historical context. 2.4.1.c.2.2: Be less about policy, with a stronger focus on the application process. Themes/trends: * Support from all commenters New Ideas/Concepts for Deliberations * ALAC: Concerns - The link between application process and policy is important to maintain. * Note from Jeff: Historical Context/Policy Dependency could all go in a separate companion guide. Discussion: -- Could have the AGB and a companion guide that has the historical context/policy. -- Translations should be released at the same time as the English version. 2.4.1.c.2.3: Be focused on serving as a practical user guide that applicants can utilize in applying for a TLD. For instance, step-by-step instructions, possibly by type of application with a ‘choose your own adventure’ methodology. Themes/trends: * Support from all commenters New Ideas/Concepts for Deliberations * BC/INTA: New Idea - Suggestion to create an interactive process to help potential applicants understand which typepath of application to choose before applying, especially .Brands and Communities. * Note from Jeff: Not sure we will have different “paths” for applications, but we may have different categories (eg., geographic, brand, community, etc.). Is this implementation guidance (eg., nice to have)? Does next recommendation address this? 2.4.1.c.2.4: Have an improved Table of Contents, include an index and the online version should contain links to appropriate sections, definitions, etc. Themes/trends: * Support from all commenters New Ideas/Concepts for Deliberations * None 2.4.1.c.2.5: The online version could have sections that apply specifically to the type of application being applied for with the ability to only print those related sections. Themes/trends: * Support from all commenters New Ideas/Concepts for Deliberations * None * Note from Jeff: See above 2.4.1.c.2.6: In conjunction with the above, the online version should allow for advanced indexing of an omnibus text. A core set of standard provisions may be applicable to everyone, but additional provisions may only be applicable to some. If the text is tagged and searchable, users could more easily locate the parts of the text that are relevant to them. Themes/trends: * Support from all commenters New Ideas/Concepts for Deliberations * None * Note from Jeff: How is this different from the recommendations above? Is this essential? Discussion: -- Haven’t captured the INTA new idea – type of application and include .Brands and Communities. Closely related to the BC comment. -- This question about different application paths could be about priorities and cost. -- This could be something for the companion guide. -- Maybe the next recommendation on an improved table of contents goes part of the way to addressing the BC/INTA comments. -- May make sense to have a checklist for each category. -- Whether to create different guides for each application may not be necessary. -- Might be easier to go with the recommendations at 2.4.1.c.2.4 and 2.4.1.c.2.5. -- BC and INTA comments reference “type of application” not “path”. Staff notes that these are summarize and WG members should reference the complete comment. The WG does not have to use this a policy language. -- Not sure the BC/INTA comment is a new idea and not sure what is an “interactive process”. 2.4.1.c.2.7: 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 (see section 2.4.3 on Systems). Themes/trends: * Support from all commenters New Ideas/Concepts for Deliberations * INTA: Concerns/New Idea - Concern that click-through agreements are non-negotiable and suggestion that applicants should be able to indicate if they wish to negotiate. * Note from Jeff: We should be specific on which Agreements we are talking about? Registry Agreement? Applicant Terms of Use? Portal/Application System Terms of Use? * RA - yes * Applicants TOU - * Systems TOU - no * Note: How do we really feel about negotiating? Should the Terms of Use and Portal/Application System really be treated like the Registry Agreement? * “...Finalized and published WITH the AGB, though the AGB should reference the existence of agreements/TOU” Discussion: -- Re: the question about INTA comment about applicants being able to negotiate – not everything has to be negotiable. -- What agreements do we mean? RA, Applicant TOU, Systems TOU? -- The WG needs to take the INTA comments and discuss what we think as a WG as to what agreements this applies – subject to negotiation or not. -- In 2012 you could ask to negotiate the RA, but no others. This comment is referencing the RA and which others? Or if not the RA, which agreements? Or, how do we feel about the systems TOU being non-negotiable? Or should these agreements be open to negotiation after the community has had a chance to vet them? -- Jeff will try to write out the questions more clearly. Suggested next steps * Potentially useful to prioritize the implementation elements. * Ensure implementation improvements are properly differentiated from actual 2012 practice. When seeking improvements from 2012, be specific about what should be different. Discussion: -- Need to talk about how to prioritize these recommendations. ICANN Org has asked the WG to be very clear in our recommendations. -- In the goals for this section, we haven’t mentioned increasing access for those who don’t understand the system (new applicants). Seems like a policy goal for the AGB should be to increase accessibility for new applicants and underserved regions. -- Consider adding goal about targeting new applicants Suggested edits: Policy Goals / What the WG is Seeking to Accomplish * An Some form of the Applicant Guidebook should be utilized for future new gTLD procedures. * However, Usability, clarity, and practicality should must be priorities when drafting future versions. * Consider adding goal about targeting new applicants