October 2020 - Gnso-newgtld-wg

Consolidated list of materials for WG Member review
by Steve Chan 06 Nov '20

06 Nov '20

Dear WG Members, As discussed and agreed on the 6 August WG call, we have compiled a consolidated list of materials for you all to review in advance of seeking to finalize the draft Final Report for public comment, as early as 13 August 2020. For review and feedback no later than Thursday, 13 August (and for discussion on the WG call that same day) Draft Final Report Change Analysis (which will be leveraged for the public comment proceeding):https://docs.google.com/document/d/17oV-BTJGtm2Q6w15qxqtsvRZg6P… Draft Final Report (minus Predictability Framework and Auctions: Mechanisms of Last Resort & Private Resolution of Contention Sets (Including Private Auction)) attached and available here, on an ongoing basis as the document is updated: https://community.icann.org/display/NGSPP/g.+Draft+Final+Report Per Emily’s email, comments on the Predictability Framework and the one new additional paragraph in the Closed Generics are due 11 August at 23:59 UTC. Review here: https://docs.google.com/document/d/1S4aOGxln9b93E_j3eF-dm0E6M8-VYToD8U9AkPl…. Feedback form is attached. NEW! - The new draft report section on Auctions: Mechanisms of Last Resort & Private Resolution of Contention Sets (Including Private Auction), comments due 12 August at 23:59 UTC – https://docs.google.com/document/d/1ShY7lL07QrFKIDZybdGceXXvb_hmKGHI3qE9bxg…. Again, feedback form is attached. Please let us know if you have any questions or concerns. Best, Steve Steven Chan  Policy Director, GNSO Support Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  Email: steve.chan(a)icann.org Skype: steve.chan55 Mobile: +1.310.339.4410 Find out more about the GNSO by visiting: https://learn.icann.org/ Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar

17 50

ICANN's Ability to Act (Without Using Predictability Model)
by Jeff Neuman 02 Nov '20

02 Nov '20

All. On the last cast, towards the end of the call, when dealing with Systems (Topic 14)<https://docs.google.com/spreadsheets/d/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1Y…>, ICANN Org made the following Comment: 1. Our Recommendation from Draft Final Report: ""in service of transparency, once the systems are in use, ICANN should communicate any system changes that may impact applicants or the application process. Processes described under Topic 2: Predictability should be followed." 1. ICANN Org Comment: "ICANN org would like to note that for issues related to security and stability, as well as the proper functioning of systems, ICANN org cannot be constrained to the processes outlined under Topic 2. ICANN org will need to respond rapidly to any issue that may fall under these categories." Discussion - 1. Under Predictability (Topic 2)<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…>, another version of this came up and has been discussed in the last email exchange to which Donna, Anne and I responded. In that discussion, ICANN said that it needed "the right to act in emergency situations, including taking actions in line with the Board or officers' fiduciary responsibilities." 1. Donna, Anne and I agreed that in true emergencies, ICANN does need to be able to act in emergency situations. We also agreed that it was critical that ICANN be transparent when it acts, and that Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately. 2. I had suggested narrowing the scope of what constitutes emergencies, but Donna and Anne did not necessarily think that would be possible. 1. Here, under Systems<https://docs.google.com/spreadsheets/d/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1Y…>, ICANN Org has broadened this to not just include "emergency situations", but also any issues "related to security and stability as well as the proper functioning of systems." 1. This is a much more expansive list of situations where ICANN would not have to use the Predictability Model. 2. In line with the above, it certainly makes sense that any issues that created an emergency situation with respect to the systems, should allow ICANN to act quickly without the use of the Predictability Model. I could see this including things like responding to a data breach or other imminent security vulnerability. We could also see responding to other forms of Cyberattack, DDoS, etc. Question: However, is the Working Group concerned that the language "related to" and "Proper functioning of systems' is too wide an opening to allow ICANN to always make changes without using the Predictability Model / SPIRT? For example, one could argue that the creation of Digital Archery was an act related to security and stability. Changing the Pre Delegation Testing Requirements could easily be related to security and stability, etc. Jeff Neuman Recommendation: We should be consistent in setting out when ICANN Org / Board should be excused from using the Predictability Model to act. Certainly Emergency Situations should be covered with the Transparency requirements discussed in #1 above. Perhaps stating something like: "With respect to its operation and administration of the systems, ICANN must retain the ability to act in emergency situations, including those where immediate action is necessary to remedy any service interruption, interference, service obstruction or other imminent threat to the systems; provided that ICANN provides notice to all impacted users of the affected system(s) as soon as reasonably practicable after such action has been taken along, and if such action involves any downtime to the system(s), it shall provide updates to impacted users as to when normal service can be restored." Thoughts? [cid:image003.png@01D6AEF0.2589CBE0] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com

4 4

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 29 October 15:00 UTC
by Julie Hedlund 30 Oct '20

30 Oct '20

Dear Working Group members, Please see below the notes from the working sessions on 29 October at 15:00 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-10-29+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 17 Applicant Support: Row 19 – RySG: ACTION ITEM: Re: 17.5 Bid Credits, also 17.9, 17.13, and 17.17 ACTION ITEM: Staff to review the RySG comments (17.9, 17.13, 17.17) to determine how they can be incorporated into the Final Report. Re: 17.5: Leadership to send a question to the list re: bid credits. Row 23 – ALAC re: Metrics ACTION ITEM: Add the metrics suggestions to the metrics section of the Final Report. Row 25 – GAC re: “Middle Applicant” ACTION ITEM: Ask on the list whether WG members want to develop a definition of “middle applicant” or re-write the recommendation to avoid use of the term. Topic 32: Limited Challenge/Appeal Mechanism: Row 15 – ICANN Org re: Appeals Mechanisms and Bylaws ACTION ITEM: Flag the issue of the interrelationship between ICANN as an evaluator and the accountability mechanisms; add to the chart in Annex F where ICANN is the evaluator the parties that can challenge and the mechanism to address that challenge. Topic 12: Applicant Guidebook Multiple Comments re: AGB publication in other languages. ACTION ITEM: Take the discussion to the list as to whether the timeframe for the publication in UN languages could be shorter. Row 13: ICANN org re: 12.4 clarity of language ACTION ITEM: re: 12.4 and clarity of language: Move the Implementation Guidance 12.8 into the recommendation 12.4; staff to reach out to ICANN org to see if that language addresses the issue. Topic 13: Communications Row 17 -- ICANN org re: Goals and Affirmation 6.1.1 Re: “It would be helpful to understand the PDP WG’s definition of the goals of the Program and whether this Recommendation is in reference to Affirmation 6.1.1.” ACTION ITEM: Re: ICANN org comments on goals and Affirmation 6.1.1: Ensure that the Recommendation on the goals of the Program is linked to Affirmation 6.1.1. Topic 14: Systems Row 13: Dotzon re: certain character combinations not allowed ACTION ITEM: Check on what are the problematic character combinations. Row 15: ICANN org ACTION ITEM: Bring to the list the ICANN org comment on Topic 14 Systems: “ICANN org would like to note that for issues related to security and stability, as well as the proper functioning of systems, ICANN org cannot be constrained to the processes outlined under Topic 2. ICANN org will need to respond rapidly to any issue that may fall under these categories.” Notes: 1. Updates to Statements of Interest: -- Maxim Alzoba has stepped down from the RySG position on the Standing Selection Committee (SSC). 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics: -- Discussion on the list: Predictability and GAC/Board Questions: Comments due by Monday, 02 November. Application Submission comment review document<https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmC…>: Topic 17 Applicant Support -- A lot of the comments have been considered. -- We did say that there should be a work stream specifically set up for Applicant Support for implementation. -- Lots of comments that have specifics. Most would be referred to an IRT. -- Provide more guidance on bid credits/multiplier. -- Meta question: based on the comments do we think we are in good shape? Answer: There are a few actions, but otherwise we are in good shape. Row 19 – RySG: Leadership Comments: A lot of these are for clarity; could be adopted if the WG agrees. -- RySG and ALAC comments mention metrics. These also could be referred to an IRT. -- 17.17: Use the colloquial term “going out of business” – we should define it better. Take the RySG definition. -- 17.13: Also worth adopting. -- 17.5 Significant concerns on how bid credits, multipliers, and other features may be used in other unintended ways beyond benefiting AS applicants, and how the risk of gaming can be mitigated. Leadership to send a question to the list. ACTION ITEM: Staff to review the RySG comments (17.9, 17.13, 17.17) to determine how they can be incorporated into the Final Report. Re: 17.5: Leadership to send a question to the list re: bid credits. Row 22 – InfoNetworks LLC re: reduced fees. Also Row 24: ICANN Board concerns Leadership Comments: Consider Implementation Guidance for IRT? Further WG discussion. Discussion: -- Reducing fees is a Pandora's Box. If ICANN can lower them for certain registries what is keeping them from raising them for others? .museum is an outlier and should stay that way. -- Could consider a degree of payment is linked with a degree of activity in the TLD. -- There were a number of comments on the theme of no matter what happens an applicant has to meet all of the other qualifications, such as the technical requirements. -- If the ICANN Board wants to favor one type of speech over another type of speech by reducing or raising its prices, I'm not sure that is something this WG wants to be involved in at all. -- Wouldn't that be the type of content based decisions the Board has expressed concern about? -- There were comments on both sides – reduced fees or not. Seems that we are not going to get consensus on ongoing support once an applicant becomes a registry. -- I don't think Applicant Support assessment is content based. Isn't is more about underserved regions and slower economies in the Global South etc. Row 23 – ALAC re: Community Leadership Comments: Look to see if there is overlap with the request for metrics from the RySG. Isn’t supposed to have the same definition of “community” as CPE. ACTION ITEM: Add the metrics suggestions to the metrics section of the Final Report. Row 25 – GAC re: “Middle Applicant” Leadership Comments: We do address "middle applicant" but don't define it. Either develop a definition (maybe through a small team), or restate the recommendation without using the term. Discussion: -- Generally speaking - its best if we, the Sub Pro WG, define any terms so they are not misconstrued during implementation. ACTION ITEM: Ask on the list whether WG members want to develop a definition of “middle applicant” or re-write the recommendation to avoid use of the term. Dispute Proceedings comment review document<https://docs.google.com/spreadsheets/d/1Pk3SadfiropKdD387FrgELdulfZuTbUCivf…>: Topic 32: Limited Challenge/Appeal Mechanism Row 11: INTA and GBOC re: 32.5 Appeal Leadership Comments: This was addressed by the WG, but flag for discussion. Discussion: -- Any way to strengthen the recommendation that the appeal should not be heard by the same people? -- 32.5 does say “must” in the Implementation Guidance. Row 15 – ICANN Org re: Appeals Mechanisms and Bylaws Leadership Comments: WG to consider if ICANN is a party to the appeal/challenge how does the process work. Seek clarification on Org's comments on interplay of limited challenge/appeals mechanism on the Bylaws accountability mechanisms. Discussion: -- Where ICANN is the evaluator, the Accountability Mechanisms should apply rather than instituting new appeals mechanisms. It's duplicative. But what does ICANN org say about this? -- The accountability mechanisms are meant to address Bylaws related issues. -- Not always a Bylaws issue. It also says "failure to take into account relevant information when making the determination". Accountability Mechanisms are not limited to ByLaws as far as I know. -- Question: Could we just say that if there is an appeal it would stay any accountability mechanism deadlines? Answer: Don’t think the WG has the authority to recommend this. -- Should flag to the Board that it wouldn’t be efficient to have two appeals mechanisms running at the same time. -- There is a group working on the timing rules for IRTs. Susan Payne is on this group and will ask that it bear it in mind. The WG also could send a note to the group. The rules also will go out for public comment. -- Can’t see making recommendations to change the accountability mechanisms. -- Add to the chart in Annex F where ICANN is the evaluator the parties that can challenge and the mechanism to address that challenge. ACTION ITEM: Flag the issue of the interrelationship between ICANN as an evaluator and the accountability mechanisms; add to the chart in Annex F where ICANN is the evaluator the parties that can challenge and the mechanism to address that challenge. Pre-Launch Activities comment review document<https://docs.google.com/spreadsheets/d/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1Y…>: Topic 12: Applicant Guidebook Multiple Comments re: AGB publication in other languages. Leadership Comments: The WG has considered it and addressed this concern. Discussion: -- The English version will always be out earlier in draft versions. -- Could change to 1 month instead of 2 – making it 3 months instead of 4, but check with language services. -- We do say it should be as soon possible but application window can’t open until 2 months after publication. -- Perhaps strengthen the intent to have them out *together* or as close as possible. -- As a policy statement we could say “take measures to translate as quickly as possible” rather than debate 2 mos vs 3 mos. -- But there were concerns about that language. -- You could always say as soon as possible, but not later than 2-3 months. ACTION ITEM: Take the discussion to the list as to whether the timeframe for the publication in UN languages could be shorter. Row 13: ICANN org re: 12.4 clarity of language Leadership Comments: Discussed the issue of min/max timeframe: tried to develop a range but WG was unsuccessful. On the second issue, this is something the IRT can focus on when writing the AGB, but note that we should focus on language that is measurable. Discussion: -- We can address this by giving examples, or we could leave this as a high-level principle. -- If it comes to the IRT we will have the same problem. -- There is a term of art: “plain English” with standards for it available. -- If we cannot come up with examples or more guidance, we can't expect the IRT members to. -- ICANN has a style guide. -- Examples: Make sure to reduce the ICANN acronyms, legal jargon, use plain English, remove historical background. -- Need to tie this to the Implementation Guidance 12.8 where the WG gives examples. Could put this into the recommendation. ACTION ITEM: re: 12.4 and clarity of language: Move the Implementation Guidance 12.8 into the recommendation 12.4; staff to reach out to ICANN org to see if that language addresses the issue. Topic 13: Communications Multiple comments re: longer communications period: -- Diverse support for what the WG recommended concerning the communications period; don’t need to revise the recommendation. Row 17 -- ICANN org re: Goals and Affirmation 6.1.1 Re: “It would be helpful to understand the PDP WG’s definition of the goals of the Program and whether this Recommendation is in reference to Affirmation 6.1.1.” ACTION ITEM: Re: ICANN org comments on goals and Affirmation 6.1.1: Ensure that the Recommendation on the goals of the Program is linked to Affirmation 6.1.1. Topic 14: Systems Row 13: Dotzon re: certain character combinations not allowed Leadership Comments: This is new information not considered. Find out what were the problematic characters. ACTION ITEM: Check on what are the problematic character combinations. Row 15: ICANN org re: “ICANN org would like to note that for issues related to security and stability, as well as the proper functioning of systems, ICANN org cannot be constrained to the processes outlined under Topic 2. ICANN org will need to respond rapidly to any issue that may fall under these categories.” Leadership Comments: Addressed, primarily in Predictability Framework. ACTION ITEM: Bring to the list the ICANN org comment on Topic 14 Systems: “ICANN org would like to note that for issues related to security and stability, as well as the proper functioning of systems, ICANN org cannot be constrained to the processes outlined under Topic 2. ICANN org will need to respond rapidly to any issue that may fall under these categories.”

2 1

Response to Anne and Donna on Predictability (Renamed Thread)
by Jeff Neuman 30 Oct '20

30 Oct '20

In an attempt to shorten the thread and not force everyone to read the entire chain, I am starting a new one: 1, Question from Donna: Is the Board required to refer an issue to the SPIRT as a consequence of receiving GAC advice on an issue that impacts the new gTLD program? I note that we say it can bring it to the attention of the SPIRT, but what's the expectation? That the Board would wait for a response from the SPIRT and that would form the basis of the Board's response to the GAC? I'm trying to understand the compatibility of the two processes and whether it's a reasonable expectation that the Board would in fact forward GAC advice to the SPIRT for consideration. * Jeff Response: As a Working Group I don't think we can force the Board to refer relevant GAC Advice to the SPIRT even if we wanted to. I would hope that if the SPIRT is working as intended that the Board would do so not because it is required to, but because there is a benefit from doing so. This is sort of akin to the Board waiting for GNSO input on GAC Consensus Advice on GNSO issues prior to it making a decision on GAC Advice. I don't believe anything requires the Board to wait for GNSO input, but by practice, it generally does. 2. Regarding the Ability of GAC to Refer items directly to the SPIRT * Donna: As I said on the call I think we do need to reconsider this issue because it may be preferable to have the GAC bring an issue to the SPIRT for consideration rather than issue advice to the Board. We should also keep in mind, that regardless of who brings the issue to the SPIRT, the SPIRT has a limited role is required to work through the framework in order to assess whether the change to the program is operational or policy and recommend appropriate action. I appreciate we had concerns about lobbying, but perhaps it may be prudent to allow SO/ACs to bring issues to SPIRT as well. * Jeff: I find this argument persuasive, but would like to hear from others especially those that we afraid of lobbying. 3. Regarding a GAC (or other SO/AC Liaison to the SPIRT * Donna: I have no objection to a Liaison, but the role would need to be defined. * Anne - I believe the IPC would support a GAC Liaison. GAC participation could affect timelines for getting final recommendations to the GNSO Council so that would have to be addressed. * Jeff: Just to double check, would these also support Liaisons from the other SOs and ACs? 4. Regarding a Time Frame by which the SPIRT must finalize its Recommendations / Advice * Donna: It would be helpful to have a process flow to help us respond to this question. I think some work had been done on this previously and perhaps it can be resurrected. We'd also need to account for the possibility that the SPIRT could be dealing with more than one issue at any point in time. * Anne: I don't think you can put a time limit on SPIRT recommendations. You don't know the issues in advance and whether an expert opinion will be needed. If SPIRT is taking too long, GNSO Counsel can intervene as long as we know GNSO Council procedures re Input, Guidance, and EPDP take precedence. (Consensus on the call was to move this to Recommendation status and this was always the intent anyway. GNSO Council is the "guardrail" on the SPIRT.) * Jeff: We have a very high level flow chart which I will ask ICANN policy staff to provide the link again. I agree that it is hard in advance to set a mandatory time limit for a response. But what if we say that all referrals to the SPIRT must indicate the expected turn around time as to when a response is needed. And upon acceptance of the referral the SPIRT should either agree with that timeline or provide an agreed upon counter to the referral on the time it likely would take? This would also help the GNSO Council in its supervision over the SPIRT.? 5. On the ability for the Board to Respond to Emergency Situations * Donna: I agree that the ICANN Board should be able to act in emergency situations and I actually think this should be at the Board's discretion and not something that we narrowly tailor as this would be difficult to do. However, for transparency reasons the Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately. * Anne: If such an emergency power to halt processing of applications is necessary, would the scope and duration modeled on the Temp Spec in the RA? In addition, if an emergency power is "scoped" in this manner, does it prohibit the Board from acting outside that emergency power and does the Board really want that constraint or is this just building in a new option the Board can invoke? * Jeff: I think the board is not asking us, but rather telling us that they will always need to reserve for itself the ability to take action in an emergency and I do not believe they will want us / or let us define what constitutes that emergency. Certainly Transparency as Donna points out will be critical and I think required disclosure is a great idea. If the Board's action impacts contracted parties that have already executed an RA, then yes, it will need to be in the form of a Temp Spec (if done unilaterally). But if it just impacts applicants, then a Temp Spec if not required. ALL - Is transparency the only check and balance? 6. On the Role of Precedent within the SPIRT * Donna: I agree that the SPIRT be able to rely on precedent and should be encouraged to do so. * Anne: GNSO Council should determine, when it accepts a SPIRT recommendation, whether or not the acceptance of that recommendation establishes a precedent. The Motion to approve at the Council level should include the question as to whether it sets precedent or not. * Jeff: Anne, I think it is fair to give the GNSO the final say on whether something should be precedent or not, but not everything will need a GNSO Council resolution. Remember that the GNSO can always choose not to comment on, or approve, a SPIRT Recommendation. So, in cases where they do not, then are we saying that shouldn't act as precedent? 7. On Level of Detail in Change Log * Donna: From memory the change process from 2012 was opaque at best, so I agree with the proposed recommendation that the level of detail be sufficient for the community to understand the scope and nature of the change. 8. On ICANN's Ability to Act Quickly * Donna The substance of the actual example is not the issue here. It's about ICANN's ability to act quickly and develop solutions vs the time that it may take the SPIRT to make a decision and implement, which is a valid concern. I think we need to discuss further. * Anne: Just pointing out that SPIRT cannot make a decision, it can only make a recommendation. The issue of speed was debated at length in the Policy & Implementation Working Group as well as in this Sub Pro Working Group. The public comment on the "Initial Report" was overwhelmingly in favor of a "Standing IRT". You can say that SPIRT should provide GNSO Council with a recommendation on an issue within 30 days of it being raised by the proper party (Board, Council, ICANN staff) and if they do not, then Council must take it up directly. But that may be the only way to force the SPIRT to work quickly. * Jeff: It is hard to see how any issue that materially impacts applicants will need to be resolved so quickly as to not allow the SPIRT to be brought into the loop to make a recommendation. Excluding true "emergencies" [See Above], the goal is to involve the SPIRT early to ensure that all possible consequences are considered. And if something must have a fast turnaround, well then the SPIRT will have to accommodate. Its easy in the abstract to say that things will come up that will require quick action, but the reality is that had things (like Digital Archery) been considered by those outside of ICANN staff, in theory also it is possible some of those issues would never have arisen. 9. Re Membership of the SPIRT being limited * Donna: There should be an upper limit on membership that recognizes that the SPIRT is intended to be a nimble and efficient team. * Anne Throughout the deliberations, it was determined that the constitution of the SPIRT should be the same as the IRT since public comment was in favor of a Standing IRT. Unfortunately, recommendations to make this group small may result in resort to a "representative" model which tilts the votes (as we have seen in connection with the recent EPDP on privacy.) I'm not certain that limiting the number of members actually makes the team more efficient. In Sub Pro, very few members are actually active in discussions. Things move slowly due to differing points of view, not due to the number of members. Maybe the timeline for SPIRT to make a recommendation to GNSO Council should depend on the category assigned to the issue? 30 days for X, 60 days for Y, 90 days for Z?SPIRT be nimble, SPIRT be quick, SPIRT jump over the policy schtick!" * Jeff: I believe both can be true. We can have a limited membership that represents the various ICANN stakeholders. Remember we are also looking for qualified members that know and understand the issues. Would love some more comments on this one. [cid:image003.png@01D6ADE0.26DA5250] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Jeff Neuman Sent: Tuesday, October 27, 2020 9:58 AM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Items on Predictability we did not get to on last WG Call Notice: This email is from an external sender. All, Notes from the meeting that occurred at 03:00 UTC on Tuesday will be out shortly. With this e-mail, however, I want to raise some issues that we did not necessarily have time to discuss on the call, but which I think we may need to address. Remember, that discussions on this e-mail list are going to be critical to getting our work done. Quick note on caution: As described on the call, we are not relitigating any of these issues. The purpose here is to evaluate the questions raised and determime whether we should respond by updating the recommendations. Also, please make sure that you refer to the Predictability Section of the Draft Final Report when responding. On the Topic of Predictability - For some of these I have proposed a path forward in line with other recommendations. Please feel free to disagree. Ultimately it is not my view that matters, but rather the will of the group. 1. The GAC has asked the following: * Should they be able to refer things directly to the SPIRT? We started this discussion on the call. The recommendation in the draft final report states that only the GNSO Council, ICANN Board, and ICANN staff should be able to refer things to the SPIRT. This was to avoid lobbying and to keep the work of the SPIRT focused and as free as possible from interference. Remember, not even the SPIRT can take up issues on its own. It must come from one of the 3 sources. Our choices are: i. To stick with our original position, pointing out that if the GAC issues Consensus Advice to the Board, the Board can bring it to the attention of the SPIRT. Alternatively, if the GAC can convince ICANN staff about the importance of an issue, then ICANN staff can bring it to the attention of the SPIRT. OR[Aikman-Scalese, Anne] I believe the IPC would support the original position. DA: I have a question-is the Board required to refer an issue to the SPIRT as a consequence of receiving GAC advice on an issue that impacts the new gTLD program? I note that we say it can bring it to the attention of the SPIRT, but what's the expectation? That the Board would wait for a response from the SPIRT and that would form the basis of the Board's response to the GAC? I'm trying to understand the compatibility of the two processes and whether it's a reasonable expectation that the Board would in fact forward GAC advice to the SPIRT for consideration. ii. Allow the GAC to refer items to the SPIRT. This could lessen delay if the GAC issues consensus advice. Rather than having to wait for the ICANN Board to address the issue only to refer it to the SPIRT could waste precious time. If we go down this path, then the following questions could arise: * Must the referral only be accepted if there is a GAC Consensus? * If we allow the GAC to refer items to the SPIRT, do we allow each of the other ACs (particularly the ALAC and SSAC)? If not, why are we making treating the GAC any differently. DA: As I said on the call I think we do need to reconsider this issue because it may be preferable to have the GAC bring an issue to the SPIRT for consideration rather than issue advice to the Board. We should also keep in mind, that regardless of who brings the issue to the SPIRT, the SPIRT has a limited role is required to work through the framework in order to assess whether the change to the program is operational or policy and recommend appropriate action. I appreciate we had concerns about lobbying, but perhaps it may be prudent to allow SO/ACs to bring issues to SPIRT as well. * Perhaps an easier question, should we recommend that the GAC have a Liaison on the SPIRT? We state that the composition of the SPIRT should be open so long as they possess the requisite skills (I am paraphrasing). So, I would think that offering the ACs, including the GAC, liaison positions on the SPIRT, does not seem like a huge issue. We should again, however, stress that they must have the qualifications that we require of all others. DA: I have no objection to a Liaison, but the role would need to be defined. [Aikman-Scalese, Anne] I believe the IPC would support a GAC Liaison. GAC participation could affect timelines for getting final recommendations to the GNSO Council so that would have to be addressed. 1. The ICANN Board has raised the following questions that I believe are important to thing about: * Do we want to recommend a timeframe by which the SPIRT must make a recommendation? We have discussed this briefly before and did not decide to include one because each issue is different and it may not be possible to dictate a timeframe. DA: It would be helpful to have a process flow to help us respond to this question. I think some work had been done on this previously and perhaps it can be resurrected. We'd also need to account for the possibility that the SPIRT could be dealing with more than one issue at any point in time. [Aikman-Scalese, Anne] I don't think you can put a time limit on SPIRT recommendations. You don't know the issues in advance and whether an expert opinion will be needed. If SPIRT is taking too long, GNSO Counsel can intervene as long as we know GNSO Council procedures re Input, Guidance, and EPDP take precedence. (Consensus on the call was to move this to Recommendation status and this was always the intent anyway. GNSO Council is the "guardrail" on the SPIRT.) * What role does precedent play? For this one, I would think that because predictability is one of our main goals, that there really needs to be a good reason to not follow precedent. We don't want issues to keep being re-litigated at the SPIRT level just because there may be different members on the SPIRT or they may involve different applications. So, I would state that once a recommendation has been issued (and accepted), then absent a substantial change in facts or circumstances, that issue should not be taken up again by the SPIRT. DA: I agree that the SPIRT be able to rely on precedent and should be encouraged to do so. [Aikman-Scalese, Anne] GNSO Council should determine, when it accepts a SPIRT recommendation, whether or not the acceptance of that recommendation establishes a precedent. The Motion to approve at the Council level should include the question as to whether it sets precedent or not. * The ICANN Board wants to make sure that it has the right to act in emergency situations, including taking actions in line with the Board or officers' fiduciary responsibilities. This is repeated in the ICANN Org comments. Recommendation: So long as there is truly an emergency situation, I can see no reason why we would not make it clear that ICANN Has a right to act. We could state, however, that such action must be narrowly tailored to address the emergency situation and use the least restrictive means to achieve their purpose. To allow otherwise, could circumvent the Predictability Framework. DA: I agree that the ICANN Board should be able to act in emergency situations and I actually think this should be at the Board's discretion and not something that we narrowly tailor as this would be difficult to do. However, for transparency reasons the Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately. [Aikman-Scalese, Anne] If such an emergency power to halt processing of applications is necessary, would the scope and duration modeled on the Temp Spec in the RA? In addition, if an emergency power is "scoped" in this manner, does it prohibit the Board from acting outside that emergency power and does the Board really want that constraint or is this just building in a new option the Board can invoke? 1. ICANN Org has raised the following: * They have asked how the Predictability Framework fits in with Recommendations 3.6 and 3.7. Those Recs address future reviews and state that any material changes stemming from future reviews should not be implemented until the round following the round in which the results of the review were adopted. Recommendation: We should state that it is the specific intent of the Working Group that the Predictability Model should address issues as they arise and not stop future rounds. When addressing issues, the SPIRT, ICANN, and the community must decide whether any resulting changes apply to the current round or only to the next subsequent round. However, any formal reviews (like the CCT-RT or any other one the community decides to do) follow the Recommendations in 3.6 and 3.7.[Aikman-Scalese, Anne] It seems this question would have to turn on whether or not GNSO Council rules that a PDP or EPDP is necessary. If so, you don't want folks rushing to file applications before the policy is adequately developed. If the issue raised necessitates a PDP or EPDP, the GNSO Council would need to scope which applications are prohibited until the policy matter is settled via PDP or EPDP. The SPIRT can't decide policy matters and cannot make this determination. Only GNSO Council can do that unless the ICANN Board intervenes for some Security, Stability, Resiliency reason or else the ICANN Board might have to act on GAC Advice not to allow another round to proceed until the issue is settled. * ICANN states that the level of detail in change logs may not to be determined by other considerations such as security, confidentiality, privacy, or other considerations. Recommendation. Perhaps we state that the level of detail must be sufficient for the community to understand the scope and nature of the change without compromising security, the privacy of individuals, or confidentiality obligations owed to applicants or other third parties. DA: From memory the change process from 2012 was opaque at best, so I agree with the proposed recommendation that the level of detail be sufficient for the community to understand the scope and nature of the change. * We state that where a significant issue arises and it requires resolution via the Predictability Framework, applicants should be afforded the opportunity to withdraw their application and receive an appropriate refund. The question is whether all such refunds should follow the standard refund schedule or whether they should be refunded a different amount? Recommendation: If the issue would still allow the application to proceed, then it should be the standard refund schedule. If, however, the issue makes it impossible for the applications to proceed, then consideration should be given for a full refund. DA: In the event that a change in the program after applications have been submitted makes it difficult for the applicant to remain true to their business plan or makes their application largely ineligible without change, then a full refund should be available. [Aikman-Scalese, Anne] Personal Opinion: I think this depends on what stage the application is at. For example, if applicant proceeded with full knowledge that there was no Closed Generic policy that was final and proceeded to file Closed Generic applications, I think the Board would have to determine the level of refund. If this WG doesn't come up with Closed Generic policy, I think we face the risk that the Board will send that result back to GNSO Council and say "try again" and "we won't allow ICANN org to process those applications until you get the policy work done". And of course based on the policy we have now, no new applications for that string for an open TLD would be permitted either. * ICANN has made the assumption that the SPIRT will not allow ICANN to act quickly and points the Draw as an example where they created "Proxy Lawyers" to take their place. My take: However, what ICANN did not mention in their comments is that it took several months to come up with the proposal for the draw and therefore perhaps a SPIRT would have brought this issue to ICANN sooner, thereby REDUCING the time it took to figure this issue out. Recommendation: No change to existing language. DA: The substance of the actual example is not the issue here. It's about ICANN's ability to act quickly and develop solutions vs the time that it may take the SPIRT to make a decision and implement, which is a valid concern. I think we need to discuss further. [Aikman-Scalese, Anne] Just pointing out that SPIRT cannot make a decision, it can only make a recommendation. The issue of speed was debated at length in the Policy & Implementation Working Group as well as in this Sub Pro Working Group. The public comment on the "Initial Report" was overwhelmingly in favor of a "Standing IRT". You can say that SPIRT should provide GNSO Council with a recommendation on an issue within 30 days of it being raised by the proper party (Board, Council, ICANN staff) and if they do not, then Council must take it up directly. But that may be the only way to force the SPIRT to work quickly. * ICANN would like for us to develop more guidance as to when someone should recuse themselves from the recommendation. There is a Conflict section in Appendix E. Recommendation: This is a level of detail perhaps that an IRT may want to weigh in on. I don't believe we need to address. DA: Given we discussed this at length, perhaps the IRT can develop more specificity on this based on other examples available. However, we should specify this in the Final Report.[Aikman-Scalese, Anne] IRT needs to develop a more detailed SOI questionnaire for the purposes of the SPIRT. The tough issue will be when recusal is "required" versus voluntary - can't remember how this works. * Use of the word "Subcontractors" should be changed to vendors / contractors. - Recommendation. This is a very minor point and we should just accept this change. DA: Agree we should change. * Do we want to limit the size of the SPIRT (Which does not include experts)? Recommendation. Will leave this to the group, but note that it can be addressed by the IRT and/or even the GNSO Council when the SPIRT is initially set up. DA: There should be an upper limit on membership that recognizes that the SPIRT is intended to be a nimble and efficient team. [Aikman-Scalese, Anne] Throughout the deliberations, it was determined that the constitution of the SPIRT should be the same as the IRT since public comment was in favor of a Standing IRT. Unfortunately, recommendations to make this group small may result in resort to a "representative" model which tilts the votes (as we have seen in connection with the recent EPDP on privacy.) I'm not certain that limiting the number of members actually makes the team more efficient. In Sub Pro, very few members are actually active in discussions. Things move slowly due to differing points of view, not due to the number of members. Maybe the timeline for SPIRT to make a recommendation to GNSO Council should depend on the category assigned to the issue? 30 days for X, 60 days for Y, 90 days for Z? "SPIRT be nimble, SPIRT be quick, SPIRT jump over the policy schtick!" [cid:image004.png@01D6ADDD.52670830] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com ________________________________ 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.

2 2

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Monday, 02 November 20:00 UTC
by Julie Hedlund 29 Oct '20

29 Oct '20

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Monday, 02 November 2020 at 20:00 UTC for 90 minutes. Note: For the schedule of the upcoming meeting topics, please see the Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. WG members are requested to review scheduled topics and comments prior to the meetings. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: <https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU…> https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: 1. Topic 20: Application Change Requests<https://docs.google.com/spreadsheets/d/1jS1m66MxbJRWhhQQTZBpyZnIuWm4ncpJFki…> 2. Topic 24: String Similarity Evaluations<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> 3. Topic 35: Auctions<https://docs.google.com/spreadsheets/d/1kmZRLAsW6wlTyQ8LA3KhOQzU1UABL9zCPWw…> 1. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Best, Julie Julie Hedlund, Policy Director

1 0

Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 29 October 2020 at 15:00 UTC
by Andrea Glandon 29 Oct '20

29 Oct '20

Dear all, * All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 29 October 2020 at 15:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/OwjQC> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . Please note, there is a part 1 and part 2 for all recordings. 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 can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards Andrea

1 0

Items on Predictability we did not get to on last WG Call
by Jeff Neuman 28 Oct '20

28 Oct '20

All, Notes from the meeting that occurred at 03:00 UTC on Tuesday will be out shortly. With this e-mail, however, I want to raise some issues that we did not necessarily have time to discuss on the call, but which I think we may need to address. Remember, that discussions on this e-mail list are going to be critical to getting our work done. Quick note on caution: As described on the call, we are not relitigating any of these issues. The purpose here is to evaluate the questions raised and determime whether we should respond by updating the recommendations. Also, please make sure that you refer to the Predictability Section of the Draft Final Report when responding. On the Topic of Predictability - For some of these I have proposed a path forward in line with other recommendations. Please feel free to disagree. Ultimately it is not my view that matters, but rather the will of the group. 1. The GAC has asked the following: * Should they be able to refer things directly to the SPIRT? We started this discussion on the call. The recommendation in the draft final report states that only the GNSO Council, ICANN Board, and ICANN staff should be able to refer things to the SPIRT. This was to avoid lobbying and to keep the work of the SPIRT focused and as free as possible from interference. Remember, not even the SPIRT can take up issues on its own. It must come from one of the 3 sources. Our choices are: i. To stick with our original position, pointing out that if the GAC issues Consensus Advice to the Board, the Board can bring it to the attention of the SPIRT. Alternatively, if the GAC can convince ICANN staff about the importance of an issue, then ICANN staff can bring it to the attention of the SPIRT. OR ii. Allow the GAC to refer items to the SPIRT. This could lessen delay if the GAC issues consensus advice. Rather than having to wait for the ICANN Board to address the issue only to refer it to the SPIRT could waste precious time. If we go down this path, then the following questions could arise: * Must the referral only be accepted if there is a GAC Consensus? * If we allow the GAC to refer items to the SPIRT, do we allow each of the other ACs (particularly the ALAC and SSAC)? If not, why are we making treating the GAC any differently. * Perhaps an easier question, should we recommend that the GAC have a Liaison on the SPIRT? We state that the composition of the SPIRT should be open so long as they possess the requisite skills (I am paraphrasing). So, I would think that offering the ACs, including the GAC, liaison positions on the SPIRT, does not seem like a huge issue. We should again, however, stress that they must have the qualifications that we require of all others. 1. The ICANN Board has raised the following questions that I believe are important to thing about: * Do we want to recommend a timeframe by which the SPIRT must make a recommendation? We have discussed this briefly before and did not decide to include one because each issue is different and it may not be possible to dictate a timeframe. * What role does precedent play? For this one, I would think that because predictability is one of our main goals, that there really needs to be a good reason to not follow precedent. We don't want issues to keep being re-litigated at the SPIRT level just because there may be different members on the SPIRT or they may involve different applications. So, I would state that once a recommendation has been issued (and accepted), then absent a substantial change in facts or circumstances, that issue should not be taken up again by the SPIRT. * The ICANN Board wants to make sure that it has the right to act in emergency situations, including taking actions in line with the Board or officers' fiduciary responsibilities. This is repeated in the ICANN Org comments. Recommendation: So long as there is truly an emergency situation, I can see no reason why we would not make it clear that ICANN Has a right to act. We could state, however, that such action must be narrowly tailored to address the emergency situation and use the least restrictive means to achieve their purpose. To allow otherwise, could circumvent the Predictability Framework. 1. ICANN Org has raised the following: * They have asked how the Predictability Framework fits in with Recommendations 3.6 and 3.7. Those Recs address future reviews and state that any material changes stemming from future reviews should not be implemented until the round following the round in which the results of the review were adopted. Recommendation: We should state that it is the specific intent of the Working Group that the Predictability Model should address issues as they arise and not stop future rounds. When addressing issues, the SPIRT, ICANN, and the community must decide whether any resulting changes apply to the current round or only to the next subsequent round. However, any formal reviews (like the CCT-RT or any other one the community decides to do) follow the Recommendations in 3.6 and 3.7. * ICANN states that the level of detail in change logs may not to be determined by other considerations such as security, confidentiality, privacy, or other considerations. Recommendation. Perhaps we state that the level of detail must be sufficient for the community to understand the scope and nature of the change without compromising security, the privacy of individuals, or confidentiality obligations owed to applicants or other third parties. * We state that where a significant issue arises and it requires resolution via the Predictability Framework, applicants should be afforded the opportunity to withdraw their application and receive an appropriate refund. The question is whether all such refunds should follow the standard refund schedule or whether they should be refunded a different amount? Recommendation: If the issue would still allow the application to proceed, then it should be the standard refund schedule. If, however, the issue makes it impossible for the applications to proceed, then consideration should be given for a full refund. * ICANN has made the assumption that the SPIRT will not allow ICANN to act quickly and points the Draw as an example where they created "Proxy Lawyers" to take their place. My take: However, what ICANN did not mention in their comments is that it took several months to come up with the proposal for the draw and therefore perhaps a SPIRT would have brought this issue to ICANN sooner, thereby REDUCING the time it took to figure this issue out. Recommendation: No change to existing language. * ICANN would like for us to develop more guidance as to when someone should recuse themselves from the recommendation. There is a Conflict section in Appendix E. Recommendation: This is a level of detail perhaps that an IRT may want to weigh in on. I don't believe we need to address. * Use of the word "Subcontractors" should be changed to vendors / contractors. - Recommendation. This is a very minor point and we should just accept this change. * Do we want to limit the size of the SPIRT (Which does not include experts)? Recommendation. Will leave this to the group, but note that it can be addressed by the IRT and/or even the GNSO Council when the SPIRT is initially set up. [cid:image002.png@01D6AC60.D41D3490] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com

3 2

FW: ICANN Application Status
by Aikman-Scalese, Anne 28 Oct '20

28 Oct '20

Hi all, I listened to the Zoom from the call. Regarding General Comments Topics 1-8 and the comment from Nameshop – Item 23 in relation to preventing new applications for the same string about “checking with the applicant” - I am attaching the ICANN definitions of “Will Not Proceed” and “Not Approved” as well as the current lists of 2012 applications which fall in those categories. These may be illustrative even though 2012 applications are outside the scope of this PDP. Please remind me, did the WG say we are not prohibiting applications in these categories? Or are they prohibited? (I think Justine did a lot of drafting on this issue.) I understand we should be discussing this on the list and also later in connection with “Applications Assessed in Rounds.” I don’t know if the ICANN definitions would have to change for future rounds where new appeal processes are put in place. This will have to be super clear in the Applicant Guidebook for the next round. I have always been concerned that no “back-up” applications for certain strings creates a situation where an applicant can prevent third parties from applying and essentially effect a “freeze” on a TLD string while negotiating with ICANN from strength. For example, an applicant could apply in the next round for numerous Closed Generic strings and take the position that no other applicant in subsequent rounds could apply for that string while it is negotiating and contesting ICANN decisions not to delegate Closed Generics. Not sure where we came out on this, but I tend to agree with Alan Greenberg’s comment on the call that the determination as to whether subsequent applications for the same string are “blocked” has to be made by ICANN. Of course that determination itself could be subject to Request for Reconsideration and Independent Review Panel so this is very tricky. Regarding Greg Shatan’s comment, I think Nameshop had an application for .idn that was changed to .internet. I am not sure of the status at this point. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman(a)lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image005.png@01D6AC87.08050F00] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> [cid:image006.jpg@01D6AC87.08050F00] Because what matters to you, matters to us.™ ________________________________ 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.

2 1

Re: [Gnso-newgtld-wg] FW: ICANN Application Status
by Emily Barabas 28 Oct '20

28 Oct '20

Hi Anne, In response to your request, here is the text of the relevant implementation guidance: Implementation Guidance 3.4: Where a TLD has already been delegated, no application for that string will be allowed for a string in a subsequent round. It should in general not be possible to apply for a string that is still being processed from a previous application round, i.e. * If there is an application that has a status of “Active”, “Applicant Support”, “In Contracting”, “On-hold” or “In PDT”, a new application for that string will not be allowed in a subsequent round. However, * If all applications for a particular string have been Withdrawn, meaning the string has not been delegated, new applications for the string will be allowed in a subsequent round. * If all applications for a given string have a status of “Will Not Proceed”, an application for the TLD will only be allowed if: * All appeals and/or accountability mechanisms have proceeded through final disposition and no applications for the string have succeeded in such appeals and/or accountability mechanisms; or * All applicable time limitations (statute of limitations) have expired such that all applicants for a particular string would not be in a position to file an appeal or accountability mechanism with respect to the string. * If all applications for a given string have a status of “Not Approved”, an application for the TLD string will only be allowed if: * All appeals and/or accountability mechanisms have proceeded through final disposition and no applications for the string have succeeded in such appeals and/or accountability mechanisms; or ○ All applicable time limitations (statute of limitations) have expired such that all applicants for a particular string would not be in a position to file an appeal or accountability mechanism with respect to the string; and * The ICANN Board has not approved new policies or procedures that would allow one or more of the applicants from the prior round to cure the reasons for which it was placed in the “Not Approved” category, but has approved new policies or procedures that would allow an applicant to apply for the string in any subsequent round. In the event that there are new policies or procedures put into place which would allow applications for strings which were “Not Approved” in a prior round, the ICANN Board must make a determination as to whether the applicants in the prior round have any preferential rights for those strings if such prior applicants commit to adopt such new policies or procedures at the time such policies or procedures are put into place. In addition, * If a registry operator has terminated its Registry Agreement and (i) the TLD has not been reassigned to a different registry operator, and (ii) in the case of a Specification 13 Brand TLD, it is more than 2 years following the Expiration Date (See RA Section 4.5(a)), then applications will be allowed to be submitted during a subsequent round. Kind regards, Emily From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Wednesday, 28 October 2020 at 01:32 To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] FW: ICANN Application Status Hi all, I listened to the Zoom from the call. Regarding General Comments Topics 1-8 and the comment from Nameshop – Item 23 in relation to preventing new applications for the same string about “checking with the applicant” - I am attaching the ICANN definitions of “Will Not Proceed” and “Not Approved” as well as the current lists of 2012 applications which fall in those categories. These may be illustrative even though 2012 applications are outside the scope of this PDP. Please remind me, did the WG say we are not prohibiting applications in these categories? Or are they prohibited? (I think Justine did a lot of drafting on this issue.) I understand we should be discussing this on the list and also later in connection with “Applications Assessed in Rounds.” I don’t know if the ICANN definitions would have to change for future rounds where new appeal processes are put in place. This will have to be super clear in the Applicant Guidebook for the next round. I have always been concerned that no “back-up” applications for certain strings creates a situation where an applicant can prevent third parties from applying and essentially effect a “freeze” on a TLD string while negotiating with ICANN from strength. For example, an applicant could apply in the next round for numerous Closed Generic strings and take the position that no other applicant in subsequent rounds could apply for that string while it is negotiating and contesting ICANN decisions not to delegate Closed Generics. Not sure where we came out on this, but I tend to agree with Alan Greenberg’s comment on the call that the determination as to whether subsequent applications for the same string are “blocked” has to be made by ICANN. Of course that determination itself could be subject to Request for Reconsideration and Independent Review Panel so this is very tricky. Regarding Greg Shatan’s comment, I think Nameshop had an application for .idn that was changed to .internet. I am not sure of the status at this point. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman(a)lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image001.png@01D6AD0B.8BB32FB0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com [lrrc.com]<https://urldefense.com/v3/__http:/lrrc.com/__;!!PtGJab4!qdVEW4uySPkfubrSwmo…> [cid:image002.jpg@01D6AD0B.8BB32FB0] Because what matters to you, matters to us.™ ________________________________ 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.

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 29 October 15:00 UTC
by Julie Hedlund 27 Oct '20

27 Oct '20

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Thursday, 29 October 2020 at 15:00 UTC for 90 minutes. Note: For the schedule of the upcoming meeting topics, please see the Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. WG members are requested to review scheduled topics and comments prior to the meetings. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: <https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU…> https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: * Application Submission comment review document<https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmC…>: Topic 17 Applicant Support * Dispute Proceedings comment review document<https://docs.google.com/spreadsheets/d/1Pk3SadfiropKdD387FrgELdulfZuTbUCivf…>: Topic 32: Limited Challenge/Appeal Mechanism * Pre-Launch Activities comment review document<https://docs.google.com/spreadsheets/d/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1Y…>: Topic 12: Applicant Guidebook, Topic 13: Communications, and Topic 14: Systems 3. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Best, Julie Julie Hedlund, Policy Director

1 0