Hi Anne, I did not capture that, but please note that as stated these are high-level notes, not verbatim. The definitive source is the recording and transcript. Also, if you would like this to be considered by the WG putting it on the list as you have done below is helpful. Kind regards, Julie From: "Aikman-Scalese, Anne" <AAikman@lrrc.com> Date: Thursday, February 6, 2020 at 5:42 PM To: Julie Hedlund <julie.hedlund@icann.org>, "gnso-newgtld-wg@icann.org" <gnso-newgtld-wg@icann.org> Subject: [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 UTC. 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/2020-02-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...>. Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date. -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.) -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.