Dear Working Group members, Please see below the notes from the meeting today, 21 May 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-05-21+New+gTLD+Subsequent+Pro.... Please also see the referenced documents at: https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXK.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Action Items: 2.2.4 TLD Types: ACTION ITEM 1: Staff will add footnote about “categories” versus “types” and application types versus TLD types - review transcript. ACTION ITEM 2: Re: “INTA: New Idea - Suggests that if the WG allows string contention to be resolved in some bases by selecting an alternative string, should allow a “mark +” to meet requirements for Spec 13, even if string is not identical to mark.” Check to see if this should be referred to RPMs PDP WG. Notes: 1. 2.2.4 TLD Types Policy Goals: -- It's really a subset of applications that received some differential treatment, whether that's eligibility requirements, whether that's processing order or sorry order processing and that's why there’s a question mark. -- It ends in a question mark because we don't normally think of that as a category. But if we do decide to take the subset of ID and applications and in some way treat them differently than other applications. For example, evaluating them first. Then for the purpose of this discussion, it would be a quote to the type or category. -- The working group recognizes that there may be circumstances where it makes sense to have differential treatment for an application based on either the type of string, the type of applicants, or the registry focus. -- There could be differential treatment in terms of eligibility, there could be differential treatment in terms of how that application gets evaluated, there could be differential treatment as we just discussed in order processing those applications. -- There could be differential treatment in terms of string contention. So for example, in the last round community if you qualified for community, you would prevail in the string contention over any non-community application or and or there could be differential treatment in terms of contractual provisions. So again, one or more of those could apply to a particular particular to the type. Can anyone think of any other areas where there may be some sort of differential treatment? -- Suggestion for community-based objection. -- Applications would be eligible for applicant support, while others may not. Could be another type. -- A particular application may fall into several possible types. -- Need to make a clear distinction between an application and a TLC type. -- There were questions in the last round that divided up the applications between standard and community based -- noted. -- May need to move away from how applications were referred to in the last round. -- The policy goals say that the working group believes this differential treatment should be the exception and this is more from the perspective of creating categories itself. The idea that there are these exceptions to the standard. -- Creating additional TLD types should be done under exceptional circumstances or something to that effect. -- May need to revisit based on the work of WT5. -- Put in a comment re: applicant support to come back to this. Public Comment Summary -- High-Level Agreements: -- Support for most of the commenters to maintain existing categories that were in the applicant guidebook and the ones that were subsequently created. -- Not seeing additional types suggested by the WG, but could be added later. -- Do we need a placeholder for future innovation types? This about this as we move ahead. Requirements/Treatment: -- Need to narrow down the types of differential treatment. -- Context: First step in deciding create a category is because there is a need to treat it differently. It's not to validate that as a type so that was essentially the the test. I think the working group talked about way back when, when they first talked about to the types. -- Re: “INTA: New Idea - Suggests that if the WG allows string contention to be resolved in some bases by selecting an alternative string, should allow a “mark +” to meet requirements for Spec 13, even if string is not identical to mark.” Check to see if this should be referred to RPMs PDP WG. -- Some comments (Public Interest Community and Christopher Wilkinson) objecting to unlimited applications, but the majority did not support limits.