October 2020 - Gnso-newgtld-wg

Consolidated list of materials for WG Member review
by Steve Chan Nov. 6, 2020

Nov. 6, 2020

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 Nov. 2, 2020

Nov. 2, 2020

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 Oct. 30, 2020

Oct. 30, 2020

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 Oct. 30, 2020

Oct. 30, 2020

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 Oct. 29, 2020

Oct. 29, 2020

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 Oct. 29, 2020

Oct. 29, 2020

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 Oct. 28, 2020

Oct. 28, 2020

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 Oct. 28, 2020

Oct. 28, 2020

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 Oct. 28, 2020

Oct. 28, 2020

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 Oct. 27, 2020

Oct. 27, 2020

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

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 27 October 03:00 UTC
by Julie Hedlund Oct. 27, 2020

Oct. 27, 2020

Dear Working Group members, Please see below the notes from the working sessions on 27 October at 03: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-27+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Action Items: General Comments: RySG comment: ACTION ITEM re: Implementation Guidance 24.4: Add a recommendation that a question should be asked of what's within the scope of the intended use and what is specifically excluded if anything from the scope of the intended use. ACTION ITEM: Add RySG’s second and third comments to the Community Applications section (Topic 34). Nameshop Comment: ACTION ITEM: Add the Nameshop comment to the Applications Assessed in Rounds section (Topic 3). ICANN Org Comment: ACTION ITEM: Staff and Leadership to review the report to see where processes and procedures are mentioned in the Recommendations and Implementation Guidance and we'll see how big of a task it is to make the usage consistent. Predictability: NCSG and other comments re: Review: ACTION ITEM: Staff and Leadership to develop proposed language for the SPIRT that encompasses these points: 1) Need to have some kind of review of the Predictability Framework early on; 2) that review doesn’t stop the work of the SPIRT, and 3) that review is under the supervision of the GNSO Council, 4) it should be lean and focused (look at Customer Standing Committee reviews as example). NCSG comment and others re: GNSO Operating Procedures taking precedent over the SPIRT: ACTION ITEM: Move from Implementation Guidance to a Recommendation that the GNSO Operating Procedures take precedent over the SPIRT. France-GAC and GAC re: role in SPIRT/need for SPIRT: ACTION ITEM: Take this discussion to the list. ICANN Board and ICANN org comments: ACTION ITEM: Leadership will review and bring questions back to the WG on the list. Notes: 1. Updates to Statements of Interest: -- Jeff Neuman has been appointed by the GNSO Council as the GNSO Liaison to the GAC. -- Olga Cavalli and Javier Rua have been appointed to the Nominating Committee. -- Cheryl Langdon-Orr will continue as the Liaison from the At-Large Advisory Committee to the GNSO. -- Greg Shatan is now a member of the At-Large Advisory Committee. 2. Introduce the Working Method for Reviewing Public Comments/Work Plan:https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGT… Work Plan: -- Multiple subjects for each meeting. -- Not reading through every comment. -- Everyone should have read the comments in advance of the meetings. -- Leadership will provide their input prior to a meeting in the appropriate column of the Public Comment Review Tool concerning the comments and questions worthy of a conversation. -- Focus on those comments that present something new or a question the WG needs to address. -- Goal is to put these subjects to rest and finalize the Final Report; not to do major rewrites. -- May move meetings to 2 hours. 3. 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: a. General Comments: -- Staff will note the comments about the public comment survey tool. -- If there are a significant number of commenters who raise an issue, even it has already been addressed by the WG, the WG should still consider it. Row 12: Question: Are there any additional recommendations that you believe the Working Group should consider making? Row 17: RySG: 1. “Given the importance of the “intended use” of the string in the String Similarity Evaluations, and perhaps other aspects of the evaluation of applications, there should be a specific question for this in the Applicant Guidebook (AG). In the 2012 AG Question 18a was, “Describe the mission/purpose of your proposed gTLD and this should be extended to describe the mission/purpose/intended use. If it’s not in the question itself, it must be in the notes accompanying it and the primary purpose of this is to unambiguously understand the intended use and to prevent the need to ask a Clarifying Question. This relates to Implementation Guidance 24.4 on page 104 of the Final Draft.” Leadership Comments: Seems like a good clarification and in line with WG Recommendations. Discussion: -- Could ask the reverse question: “Are there any uses which are outside of your intended use?” If we adopt the suggested question, consider also adopting the reverse question. -- The WG could say that there should be a question about intended use but without providing the text of the question. -- The recommendation could be that there should be a question on intended use and then point to a couple of sections where intended use is important. -- Add a recommendation that a question should be asked of what's within the scope of the intended use and what is specifically excluded if anything from the scope of the intended use. Leave it to the IRT to draft the question. ACTION ITEM re: Implementation Guidance 24.4: Add a recommendation that a question should be asked of what's within the scope of the intended use and what is specifically excluded if anything from the scope of the intended use. Row 17: RySG: “2. Conversion of Application from Community to Standard. If an applicant applies as a community, and during CPE it is determined by ICANN’s evaluator, that a community does not exist to move forward with the community application, then the applicant should have the ability to amend its application to a standard application and proceed on equal footing with standard applicants in the normal process.” Leadership comments: Probably a question we should consider in CPE section (New Question). Row 17: RySG: “3. To prevent a type of gaming, applicants or their affiliates should not be permitted to file both a community and a standard application for the same string.” Leadership Comment: This is a new question we have not yet considered. Does WG want to address? ACTION ITEM: Add RySG’s second and third comments to the Community Applications section (Topic 34). Row 23: Nameshop comment: Leadership Comment: This is new information that relates to Applications assessed in Rounds But also may be relevant to when a round is deemed "closed". Discussion: -- WG could consider not allowing applications for strings that are marked “will not proceed, unless there is some clarity or a check with both the applicant and ICANN. -- This is not something the WG has considered. Assumed that “will not proceed” meant that it is deemed to be a final decision. -- ICANN org notes that they can be in “will not proceed” status from a program perspective and still be in the cooperative engagement process. -- Application status definitions used are here: https://newgtlds.icann.org/en/applicants/advisories/application-contention-…. -- Two points: 1) The WG could set the principle that so long as an application is still in or could possibly be like within the statute of limitations of appeals or accountability mechanisms that we should not allow a string to proceed. 2) where there is a difference of an opinion between what ICANN org believes is past that period and has been exhausted and the applicant disagrees/disputes. -- Think we have to rely on ICANN’s position and the result of the dispute resolution mechanism. -- If we make a statement or change the report relating to this comment we need to make sure we are using generalities, not specifics. ACTION ITEM: Add the Nameshop comment to the Applications Assessed in Rounds section (Topic 3). Row 27: ICANN Org: Leadership Comments: #2 - Consider More details around transparency when they are mentioned. #3 - Look at these specific recommendations / Implementation Guidance to ensure "hooks" are intentional or not. #4 - Move to Predictability #5 ICANN Org distinguishes between Processes and Procedures and believes that processes are for the AGB, whereas procedures are to be developed after the AGB. We need to either explicitly state that that was not our intent (where applicable) or change wording in line with ICANN Org interpretation. Discussion: -- We may want to add more details in specific sections that call for more transparency. -- Need to clarify in places whether we really meant Implementation Guidance as part of a recommendation (and so mandatory) or Implementation Guidance as just guidance. -- ICANN org has a very specific definition of “process” which is something that is higher level view than what is in the AGB. Also, their definition of “procedure” is operationally focused. -- We use the terms interchangeably. We can decide to apply ICANN’s definition or decide to reject it. -- ICANN org: It’s about expectations – what we think should happen when we get a Recommendation or Implementation Guidance. ACTION ITEM: Staff and Leadership to review the report to see where processes and procedures are mentioned in the Recommendations and Implementation Guidance and we'll see how big of a task it is to make the usage consistent. b. Predictability: Row 11: NCSG and other comments re: Review Leadership Comments: 1. Several Comments discuss having an annual review (NCSG, Article 19, GAC). Though annual reviews seem excessive and will put the SPIRT in constant state of review, this is a new question and we should discuss whether to have reviews and if so how often? 2. The idea that GNSO Procedures take precedence show up in several comments, so this is something we may want to clarify as it has always been the intent. Discussion: -- There are several comments that call for an annual or periodic review. -- We could just say that the GNSO can review it in accordance with the Consensus Policy Implementation Framework (CPIF). -- Should do a sanity check a year or two into the implementation of the SPIRT, or at least some level of review before the third round starts, or until sufficient time has passed to have data to review. -- Maybe we need to say that the GNSO Council has the responsibility to make sure the program is working. -- Three points: 1) Need to have some kind of review early on; 2) that review doesn’t stop the work of the SPIRT, and 3) that review is under the supervision of the GNSO Council, 4) it should be lean and focused. ACTION ITEM: Staff and Leadership to develop proposed language for the SPIRT that encompasses these points: 1) Need to have some kind of review of the Predictability Framework early on; 2) that review doesn’t stop the work of the SPIRT, and 3) that review is under the supervision of the GNSO Council, 4) it should be lean and focused (look at Customer Standing Committee reviews as example). Row 11: NCSG and Row 19: IPC comments re: GNSO Operating Procedures taking precedent over the SPIRT: ACTION ITEM: Move from Implementation Guidance to a Recommendation that the GNSO Operating Procedures take precedent over the SPIRT. Row 13: BC re: representation in the SPIRT Leadership Comments: The SPIRT rules are the same as normal IRT rules. Do we want to mandate representation? Should we specify that the IRT set forth the qualifications for serving on the SPIRT. Discussion: -- Could let the IRT decide what are the qualifications for being a member of the SPIRT. -- Or, does the WG want to spell out qualifications, in which case we’ll need to brainstorm on the list. Row 15: France-GAC and Row 23: GAC re: role in SPIRT/need for SPIRT: Leadership Comments: Several Governments and the GAC comments reflect a desire to be able to refer matters directly to the SPIRT? Do we want to reconsider this? Do we want to suggest a GAC liaison to the SPIRT? Discussion: -- We talked about this before. Not something we need to revisit. -- Might be worth rethinking this as another avenue for the GAC other than Consensus Advice to the Board. -- What’s the harm in allowing the GAC to bring something to the SPIRT? The SPIRT is not obliged to take action. ACTION ITEM: Take this discussion to the list. Row 22: ICANN Board and Row 24: ICANN org comments: ACTION ITEM: Leadership will review and bring questions back to the WG on the list.

1 0

Post Call | New gTLD Subsequent Procedures Working Group | Tuesday, 27 October 2020 at 03:00 UTC
by Terri Agnew Oct. 27, 2020

Oct. 27, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Tuesday, 27 October 2020 at 03:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/OQjQC> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . 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 Terri

1 0

Note on Work Commencing on our Next Call: Tuesday, October 27th at 03:00 UTC
by Jeff Neuman Oct. 26, 2020

Oct. 26, 2020

All, We wanted to provide you with some more information on the working methods going forward starting on the call in about 7 or 8 hours. You will have seen the agenda has a link to the Working Group Wiki<https://community.icann.org/display/NGSPP/h.+Published+Draft+reports> page. That page breaks down the comments we received into sections: 1. Overarching Issues (Topics 1-8) 2. Foundational Issues (Topics 9-11) 3. Pre-Launch Activities (Topics 12-14) 4. Application Submission (Topics 15-18) 5. Application Processing (Topics 19-20) 6. Application Evaluation / Criteria (Topics 21-29) 7. Dispute Proceedings (Topics 30-33) 8. String Contention Resolution (Topics 34-35) 9. Contracting (Topics 36-38) 10. Pre-Delegation comment (Topic 39) 11. Post Delegation (Topics 40-41) We will not be necessarily going in order. Therefore it is important that you review the WorkPlan at https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. Bookmark it! For each call, you will have been expected to read all of the comments prior to the call. We WILL NOT be reading each comment like we did with the previous comment reviews. You will see a column has been inserted into the spreadsheets called "Leadership Recommendations". In that column, the leadership team will have made notes on either recommended actions or on recommended questions we address from the comments. NOT ALL OF THE COMMENTS WILL HAVE A NOTATION IN THE LEADERSHIP RECOMMENDATION COLUMN. This may be because (a) there is no new information being provided by the comment, (b) we have already gone over similar comments in previous comment periods and do not need to revisit, or (c) the comment is not related to the topic we are discussing. In some cases, those comments falling into (c) will be recommended to move to their appropriate areas. The Leadership recommendations are only guidance for the group. They are in no way binding. They are meant to help steer the discussion in an efficient manner. They are the areas that we the leadership team believed presented areas that may need some more conversation. However, if you believe there are additional comments we must pay attention to, please indicate that in the "NOTES" column to the left of the Leadership Column indicating (a) why you believe we need to address the comment and (b) your name. Please be prepared to discuss those items during the applicable call. {For the call later, we will not require this] Finally, if there are outstanding items from the call, be prepared to continue the discussion online (through e-mail) and potentially through small groups to finish the details. We have a lot of material to re-go over and not much time to do it. Also remember, that we have been through all of these topics before. So, unless the information is new to us, or we have directly solicited the information, we may not need to address the comment. This was after all a Draft Final Report. At the end of the day, we know our report will not be perfect. There may be some areas we may need to punt to the IRT set up on SubPro. We are in the home stretch everyone! Sincerely, Jeff (on behalf of Jeff, Cheryl, and the rest of the Leadership Team). [cid:image001.png@01D6ABAD.4BBB5B30] 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

1 0

REMINDER: Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 27 October 03:00 UTC
by Julie Hedlund Oct. 26, 2020

Oct. 26, 2020

Dear WG Members, As a reminder, please find below the proposed agenda for the regular WG meeting on Tuesday, 27 October 2020 at 03:00 UTC. Kind regards, Julie From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Wednesday, October 21, 2020 at 6:56 AM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 27 October 03:00 UTC Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Tuesday, 27 October 2020 at 03:00 UTC. Proposed Agenda (also posted on the wiki<https://community.icann.org/display/NGSPP/2020-10-27+New+gTLD+Subsequent+Pr…>): 1. Review Agenda/Updates to Statements of Interest 2. Introduce the Working Method for Reviewing Public Comments/Work Plan: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn… 3. 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: * General Comments; and * Predictability 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

2 1

CCT Review Team Recommendations Adopted Yesterday by the ICANN Board
by Jeff Neuman Oct. 23, 2020

Oct. 23, 2020

All, Yesterday the ICANN Board approved more of the CCT-RT Recommendations<https://www.icann.org/en/system/files/files/cct-pending-recs-board-action-2…> (11 of the remaining 17). More specifically, the approved recommendations can be found here: https://www.icann.org/en/system/files/files/cct-pending-recs-board-action-2…. I do not believe any of these recommendations or approved actions will have any material impact on our work or on us completing our work by the end of this year. Here is my (very unofficial summary). To get the full text, see the Scorecard<https://www.icann.org/en/system/files/files/cct-pending-recs-board-action-2….>. In general: 1. ICANN shall try to collect TLD registration number data per TLD and registrar at a country-by-country level. 2. ICANN shall investigate existing definitions of parking......in order to provide a definition of parking for community review, and a transparent methodology and process for data collection. 3. For Recommendations 8 and 11 calling for registrant and end user surveys, ICANN shall conduct periodic surveys of registrants (every 3 years) to ensure baseline data for future analysis s well as to reduce response burden, given the survey length and the pace of behavioral change associated with the domain name marketplace. 4. For Recommendation 13: * CCT-RT Recommendation: ICANN should collect data in conjunction with its related data collection activities on the impact of restrictions on who can buy domains within certain new gTLDs (registration restrictions) to help regularly determine and report: 1. Whether consumers and registrants are aware that certain new gTLDs have registration restrictions; 2. Compare consumer trust levels between new gTLDs with varying degrees of registration restrictions; 3. Determine whether the lower abuse rates associated with gTLDs that impose stricter registration policies identified in the Statistical Analysis of DNS Abuse in gTLDs Study continue to be present within new gTLDs that impose registration restrictions as compared with new gTLDs that do not 4. Assess the costs and benefits of registration restrictions to contracted parties and the public (to include impacts on competition and consumer choice) and; 5. Determine whether and how such registration restrictions are enforced or challenged. * What Board Approved: i. The Board notes that data collection concerning consumer awareness of registration restrictions (part 1) and consumer trust levels in TLDs with restrictions versus those without (part 2) can be incorporated into future surveys of consumer-end users and registrants (see recommendations 8 and 11). ii. Determining a correlation between lower abuse rates and stricter registration policies (part 3) entails extending parts of the "Statistical Analysis of DNS Abuse in gTLDs" study. iii. Regarding part 4 on assessing "costs and benefits of registration restrictions to contracted parties and the public", with clarification received from CCT-RT Implementation Shepherds, the Board calls for questions around costs and benefits to be integrated into the voluntary data gathering collection efforts, along with parts 1 and 2. The Board also expects that these data sets will be provided to the future review team to conduct a cost/benefit analysis based on the data. iv. On part 5, determining "whether and how such registration restrictions are enforced or challenged", the Board directs ICANN org to conduct a voluntary pilot survey to gather the requested data, and to review results and participation rates to determine whether the survey should be continued at regular intervals. Data collection efforts must be preceded by consultation with contracted parties on the approach and methods for a voluntary survey (or other means of contacting contracted parties), to ensure the most meaningful and useful data can be collected. 1. The Board notes that ICANN org will continue to collect data and generate monthly reports on an ongoing basis. DAAR itself is not and cannot be a compliance/enforcement tool. Rather, it is a tool that monitors third party reputation lists to indicate possible concentration of DNS security threats. 2. With respect to WHIOS Accuracy to help the WHOIS Review Team, the Board notes that no further action is required at this time, and that if future RDS reviews request that data, ICANN org will provide the information in #18 to help inform their work. 3. With respect to Recommendation 20 on DNS Abuse Complaints: * CCT-RT Recommendation: Assess whether mechanisms to report and handle complaints have led to more focused efforts to combat abuse by determining: (1) the volume of reports of illegal conduct in connection with the use of the TLD that registries receive from governmental and quasi-governmental agencies; (2) the volume of inquires that registries receive from the public related to malicious conduct in the TLD; (3) whether more efforts are needed to publicize contact points to report complaints that involve abuse or illegal behavior within a TLD; and (4) what actions registries have taken to respond to complaints of illegal or malicious conduct in connection with the use of the TLD. Such efforts could include surveys, focus groups, or community discussions. If these methods proved ineffective, consideration could be given to amending future standard Registry Agreements to require registries to more prominently disclose their abuse points of contact and provide more granular information to ICANN. * What Board Approved: The Board directs ICANN org to conduct a voluntary pilot survey to obtain the requested data. Data collection efforts must be preceded by consultation with contracted parties on the approach and methods for a voluntary survey (or other means of contacting contracted parties), to ensure the most meaningful and useful data can be collected. The Board directs ICANN org to review results and participation rates, after completion of the survey, to determine whether the survey should be continued at regular intervals. 4. For Recommendation 23 on new TLDs operating in highly-regulated sectors, ICANN Agreed to the following: * The Board notes that ICANN org, through its Contractual Compliance team, currently reports on volume and nature of complaints received regarding gTLDs operating in highly-regulated sectors. * The Board directs ICANN org to conduct a voluntary pilot survey to capture the recommended data, as well as a review of a sample of domain websites within the highly regulated sector. With respect to collecting data from resellers, the Board notes that ICANN does not have the means to communicate with resellers. For the corresponding datapoint, this will need to be obtained through registrars, on a voluntary basis. Data collection efforts must be preceded by consultation with contracted parties on the approach and methods for a voluntary survey (or other means of contacting contracted parties), to ensure the most meaningful and useful data can be collected. Following completion of the survey, the Board directs ICANN org to review the results before determining whether to proceed with the survey on an ongoing basis. * Regarding the portion of the recommendation calling for an audit on registration practices, the Board notes existing Registry Agreement limitations to two audits per year and that ICANN Compliance data shows insignificant volumes of complaints, indicating that this is a low risk area. The Board believes it is important to ensure limited resources are used to focus on obligations that have the largest potential impact to the Safety, Security and Resiliency of the DNS. As a result, the Board directs ICANN org to continue to monitor complaint trends in this area, and to plan for an audit if any risk is identified. 5. For Recommendation 24, which asks for a quarterly report on complaints received for a registry's failure to comply with either the safeguard related to gTLDs with inherent governmental functions r the safeguard related to Cyberbullying. ICANN Agreed to: The Board directs ICANN org to conduct a voluntary pilot survey to gather the data requested under 24b, and to review results and participation rates to determine whether the survey should be continued at regular intervals. Data collection efforts must be preceded by consultation with contracted parties on the approach and methods for a voluntary survey (or other means of contacting contracted parties), to ensure the most meaningful and useful data can be collected. 6. For Recommendation 26: * CCT-RT Recommendation: A study to ascertain the impact of the New gTLD Program on the costs required to protect trademarks in the expanded DNS space should be repeated at regular intervals to see the evolution over time of those costs. The CCT Review Team recommends that the next study be completed within 18 months after issuance of the CCT Final Report, and that subsequent studies be repeated every 18 to 24 months. The CCT Review Team acknowledges that the Nielsen survey of INTA members in 2017 intended to provide such guidance yielded a lower response rate than anticipated. We recommend a more user friendly and perhaps shorter survey to help ensure a higher and more statistically significant response rate. * What Board Approved: The Board encourages collaboration with relevant partners, as appropriate, to gain a deeper insight into the effects of the New gTLD Program on trademark enforcement, using a combination of qualitative and quantitative research. [cid:image001.png@01D6A938.FE23F380] 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

1 0

Re: [Gnso-newgtld-wg] [Ext] RE: Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 27 October 03:00 UTC
by Julie Hedlund Oct. 21, 2020

Oct. 21, 2020

Hi Jim, The calendar invites should go out today, or tomorrow at the latest. Kind regards, Julie From: Jim Prendergast <jim(a)GALWAYSG.COM> Date: Wednesday, October 21, 2020 at 7:09 AM To: Julie Hedlund <julie.hedlund(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Ext] RE: Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 27 October 03:00 UTC Thanks Julie – do you know when we will get calendar items or even just times for the November and December meetings? We’re running into other events like the IGF which starts Nov 2. Thanks Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Julie Hedlund Sent: Wednesday, October 21, 2020 6:56 AM To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 27 October 03:00 UTC Dear WG Members, Please find below the updated proposed agenda for the regular WG meeting on Tuesday, 27 October 2020 at 03:00 UTC. Proposed Agenda (also posted on the wiki<https://community.icann.org/display/NGSPP/2020-10-27+New+gTLD+Subsequent+Pr…>): 1. Review Agenda/Updates to Statements of Interest 2. Introduce the Working Method for Reviewing Public Comments/Work Plan: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1ftMpOLke…> 3. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1x9vbkFUN…>https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics: * General Comments; and * Predictability 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

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 27 October 03:00 UTC
by Julie Hedlund Oct. 21, 2020

Oct. 21, 2020

Dear WG Members, Please find below the updated proposed agenda for the regular WG meeting on Tuesday, 27 October 2020 at 03:00 UTC. Proposed Agenda (also posted on the wiki<https://community.icann.org/display/NGSPP/2020-10-27+New+gTLD+Subsequent+Pr…>): 1. Review Agenda/Updates to Statements of Interest 2. Introduce the Working Method for Reviewing Public Comments/Work Plan: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn… 3. 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: * General Comments; and * Predictability 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

2 1

FW: Questions on ICANN Board Comments to SubPro Draft Final Report
by Jeff Neuman Oct. 20, 2020

Oct. 20, 2020

All, Jim asked in the chat on the call last night about the note that we sent to Avri and Becky regarding the Board Comments to SubPro. I apologize that I had not sent this to the full list earlier. For some reason I thought I did send it, but it turns out that I had not. Apologies for that. Below you will find the note that we sent out. Please let me know if you have any questions about the note. Sincerely, Jeff [cid:image001.png@01D6A693.B8EA1440] 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: Jeff Neuman Sent: Wednesday, October 14, 2020 9:46 AM To: avri.doria(a)board.icann.org; Becky Burr <becky.burr(a)board.icann.org> Cc: Cheryl Langdon-Orr <langdonorr(a)gmail.com>; steve.chan(a)icann.org; Emily Barabas <emily.barabas(a)icann.org>; Julie Hedlund <julie.hedlund(a)icann.org> Subject: Questions on ICANN Board Comments to SubPro Draft Final Report Dear Avri and Becky, Cheryl and I are reaching out to you both as the ICANN Board Liaisons to the SubPro PDP. First, we want to thank you for the comprehensive comments from the ICANN Board on the Draft Final Report. It is clear from the letter that the Board spent great deal of time and resources in discussing and preparing the response. Last week, the SubPro Working Group had an initial discussion on some of the comments raised by the Board. Through that discussion, it became clear that the Working Group would like some additional information from the Board on either underlying assumptions or context for the recommendations. Registry Voluntary Commitments / PICs (also applies to String Similarity) On Topic 9, Registry Voluntary Commitments / PICs, the Board states: "The language of the Bylaws, however, could preclude ICANN from entering into future registry agreements (that materially differ in form from the 2012 round version currently in force) that include PICs that reach outside of ICANN's technical mission as stated in the Bylaws. The language of the Bylaws specifically limits ICANN's negotiating and contracting power to PICs that are "in service of its Mission." The Board is concerned, therefore, that the current Bylaws language would create issues for ICANN to enter and enforce any content-related issue regarding PICs or Registry Voluntary Commitments (RVCs). Has the PDP WG considered this specific language in ICANN Bylaws are part of its recommendations or implementation guidance on the continued use of PICs or the future use of RVCs." The Working Group has not considered the ICANN Bylaws specifically with respect to whether PICs or RVCs would run afoul of the ICANN Bylaws. In our discussions last week, we were a little puzzled by this question which we believe is more of a legal question as opposed to a policy-development one. Therefore, this question would not be one properly in front of the Working Group. However, from this comment, the Working Group is now keenly interested to discover from the Board: * Does the ICANN Board believe that any future PICs or RVCs would in fact be outside the scope what the Bylaws Permit? * The Working Group would like to understand why the Board may believe that the current Bylaws would create issues for ICANN to enter and enforce any content-related issue regarding RVCs in particular if the Registry voluntarily adopted the commitment on its own. Therefore, ICANN would not be regulating any form of content, but rather would just be ensuring that the Registry is doing the job it signed up to do. * In other words, does the Board believe that ICANN enforcing voluntary commitments made by registries if those commitments relate to the content on their TLDs, to be impermissible content regulation? * And if it does, but a consensus of the community desires ICANN to be in this role, could the Bylaws be changed to allow ICANN to perform this job. Applicant Support Can you clarify the comment made on topic 17, with respect to Applicant Support, where the Board states that it is not a grant-seeking organization....but that is could, through the Pro Bono Assistance Program, act as a facilitator in the introduction of industry players or potential funding partners to the prospective entrants. Does this mean ICANN would be comfortable in granting application discounts (or even application fee forgiveness), but it would not be comfortable in seeking funds from others to fund such services provided by other third parties? Community Applications On Community Applications (Topic 34), many groups have expressed support for prioritizing community based applications where there is string contention. However, the similar to Topic 9, the ICANN Board is asking whether evaluating community-based applications and enforcing those commitments could run afoul of ICANN's mission. * Is the ICANN Board taking a position that we should not be having any community-based applications? Or Is the Board stating that we can have Community-based applications, but it would have to rely solely on self enforcement even if these applications were given priority in contention sets? * If there is a consensus within the ICANN-community to continue allowing Community-Based applications and giving them priority, could we not amend or clarify the bylaws to make sure that ICANN were not running afoul of the mission? We may likely have additional questions on some of the other comments, but I wanted to pass these through as soon as we could. We would like to discuss these questions with you both on a future call as opposed to an exchange of e-mails if possible as there could likely be follow up questions. Thanks again for the Board's extensive comments and we look forward to discussing these issues with you. Sincerely, Cheryl and Jeff SubPro Chairs

1 0

Post Call | New gTLD Subsequent Procedures Working Group | Monday, 19 October 2020 at 20:00 UTC
by Andrea Glandon Oct. 19, 2020

Oct. 19, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Monday, 19 October 2020 at 20:00 UTC can be found on the agenda wiki page<https://community.icann.org/x/NwjQC> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . 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

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 19 October 20:00 UTC
by Julie Hedlund Oct. 19, 2020

Oct. 19, 2020

Dear Working Group members, Please see below the notes from the working sessions on 19 October at 20: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-19+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: 1. Updates to Statements of Interest: No updates provided. 2. Meeting with the SSAC re: draft Final Report – highlighted issues: SSAC’s Work Party looking at two areas: 1) SSR issues in the draft Final Report; 2) Gap analysis – issues not in the draft Final Report. a. Root Zone Delegation Rates SSAC/Rod Rasmussen, Chair: -- This gets into one of the biggest issues. Lots of issues were well addressed in SSAC advice. -- There are some issues that are outstanding around measuring and monitoring: how do you make decisions on when things are not going well? When and how the metrics are dealt with. -- Related to that is the concept of the SPIRT. -- WG/Jeff Neuman, Co-Chair: OCTO recent paper on early warning system. Technical community couldn’t agree on a solution, objective tests or metrics, so ICANN should just ask. See Public Comment Forum announcement -- Recommendations for Early Warning for Root Zone Scaling at https://www.icann.org/public-comments/recommendations-early-warning-root-sc… -- SSAC/Rod Rasmussen, Chair: Does the SPIRT provide the overarching framework? It is more focused on specific issues, not an overarching process. Could there be an oversight group that could say when things need to slow down? --WG/Jeff Neuman, Co-Chair: How to incorporate SSR expertise and decision making into the SPIRT. WG didn’t discuss that as part of the SPIRT role, but it can call experts on issues. Meant to deal with process issues; and serve as a shepherd on possible policy issues. -- SSAC/Geoff Houston: OCTO document is just an opinion. There are contrary views. -- SSAC/Rod Rasmussen, Chair: SSAC concern is that there might be overarching systemic SSR issues and it’s not clear that the SPIRT is set up to review those types of issues, or is empowered to do something about it. -- SSAC/Rod Rasmussen, Chair: SSAC concern when it comes to contentious issues, such as root zone delegation, where you could have experts who don’t agree; if these got referred to the SPIRT it’s not clear how the SPIRT would make decisions and what criteria it would use. SPIRT should not make SSR conclusions/recommendations without the appropriate technical expertise. -- WG/Jeff Neuman, Co-Chair: The SPIRT is not a decision maker; but to help ICANN understand the potential impacts and make sure that when it comes to making a decision the right parties are involved. SPIRT could make sure that the experts are involved. -- SSAC/Rod Rasmussen, Chair: Who would have the authority to slow down delegations? WG: Ultimately the ICANN Board. The way we instructed the SPIRT is to make sure we can alert the stakeholders to the possible impacts. Board wanted that clarified in the comments. Transparency would be very important. -- WG/Jeff Neuman, Co-Chair: Could consider having an SSAC liaison. b. How names are constructed: IDNs / Variants / Restricted character combos SSAC/Rod Rasmussen, Chair: -- Interesting things around determining contention sets that from a technical aspect doesn’t make a lot of sense to look at intended use to decide if a string is confusingly similar. -- You can look at strings as they are and have some rules around that. -- Inconsistencies on how plurals were addressed in the prior round. -- Concerns about SWORD tool. -- WG/Jeff Neuman, Co-Chair: SWORD tool -- Recommendation was to eliminate it. -- WG/Jeff Neuman, Co-Chair: Not using intended use for putting things in contention sets and treatment of plurals and singulars; WG was considering doing a study on plurals and singulars – but the plurals were acquired so they went away by consolidation. -- SSAC/Ram Mohan: On intended use – this should not be considered a defining characteristic on whether a string should be placed in a contention set or not because intended use changes over time. Also, and expected use may not be how it is used in real life. Thought it was not a good idea to apply intended use as a defining characteristic, although it could be something to note. -- SSAC/Rod Rasmussen, Chair: You have the issue where the intended use changes over time and what are the rules for that? -- WG/Paul McGrady: Example of .apples – applied for by the Apple Growers Association and say they won’t sell computers, etc. Could have a side agreement with Apple computers. -- SSAC/Ram Mohan: What happens if someone registers bad.apples and uses it to talk about bad experiences with Apple computers? The fundamental thing we are saying it’s a bad idea to have intended use being a defining factor, but could be an identifying factor. Need to think about how to mitigate the risks, but it not always black and white. -- WG/Jeff Neuman, Co-Chair: Whether it is the definitive factor or a factor someone won’t be happy if someone registers bad.apples. c. DNS Abuse itself and a proxy for other meta issues -- SSAC/Rod Rasmussen, Chair: These are issues that were noted as part of the last expansion as being potential issues with the original delegations. But the majority of TLDs were okay. But where there are problems, are those lessons learned? Does there need to be a PDP? How does that interact with subsequent rounds? Is it a gating factor? There is an engineering concept of being able to do something in a new space. Are there best practices that would be rolled out for the new gLTDs? Want to see any issues mitigated up front. Where is that properly handled? -- WG/Jeff Neuman, Co-Chair: The abuse that occurs in TLDs now is not because something is new versus old. It happens because it is a registry or ccTLD that doesn’t take down sites. Shouldn’t put restrictions on newer TLDs without dealing with older/legacy TLDs. Needs to be handled on a global level, although GAC didn’t like that the SubPro didn’t make a recommendation on this. There are a lot of people in the ICANN community that think if we can’t get the legacy players to do something we should put it on the new gTLDs and then make the legacy TLDs adopt the rules in their renewed contracts. We think the appropriate place is for the GNSO Council to set the policy on DNS abuse. -- SSAC/Rod Rasmussen, Chair: What were the primary drivers of concentrated abuse? Pricing? - undoubtedly at 1 cent, poor filtering of bad actors registering names? likely. Would be really good to have a solid understanding to make good decisions. Lack of experience for new operators? Maybe, maybe not. Lots to know. Don’t think anyone wants to punish new operators, but we want to make sure things are successful. -- WG/Donna Austin: The data is important. ICANN has been talking about bad actors for some time, but are yet to provide evidence of what they are talking about. Also important to keep the conversation in perspective: are we talking about DNS abuse or abuse conducted on the Internet? d. Registry Testing / Pre-evaluation process for Back End Operators SSAC/Rod Rasmussen, Chair: -- Idea of having back-end operators prove that they can do it over and over again doesn’t make tons of sense; it becomes interesting when you think about the scaling. How do you test when you have a lot of concentration with back-end operators handling thousands of TLDs? What about the next .com? -- Might want to say that there is a base set of testing and then also testing for special circumstances. -- WG/Jeff Neuman, Co-Chair: We aren’t trying to say that ICANN is certifying back-end registries. The way you need to think about the pre-evaluation program is doing the evaluation earlier in time than you would have done it during the application process. It isn’t a certification or pre-approval. We do state that if you say you are using a pre-evaluated back-end operator but using new/additional services that the back-end operator wasn’t evaluated for then the back-end operator has to be re-evaluated for those services. -- SSAC/Rod Rasmussen, Chair: Suggesting that ICANN org could produce an “RSP 101” type of document. There is the applicant side and the backend side. Lessons learned. e. TLD Types -- SSAC/Rod Rasmussen, Chair: SAC103: One of the things was that it was easy to become a publicly traded company. There is a concern about bad actors being able to game this. -- WG/Jeff Neuman, Co-Chair: In general most publicly traded companies have strict requirements/obligations for avoidance of crime; we didn’t ignore it but we didn’t think ICANN could have different regulations for different jurisdictions. f. Name Collision / Interaction with Private TLD proposal -- SSAC/Rod Rasmussen, Chair: We continue the work on name collisions. We are moving forward to try to answer the Board questions. There is enough time to get that work done before new gTLDs are launched. -- WG/Jeff Neuman, Co-Chair: There are members of the WG have been debating whether the work of the NCAP should be a dependency for certain elements of the next round. The NCAP is not making any recommendations as to whether their work should be a dependency for the next round; that would be a decision by the Board. -- SSAC/Rod Rasmussen, Chair: It is not up to the SSAC or NCAP to make any recommendations concerning whether name collisions should be a dependency for new gTLDs. We are trying to develop a framework to mitigate risks so that people can make better informed decisions. -- WG/Jeff Neuman, Co-Chair: .corp, .home, and .mail are not in scope for this WG. It is a matter of opinion as to what should be the dependencies for the next round. If something is a dependency we need to decide at what point we need to make a decision? -- SSAC/Rod Rasmussen, Chair: Outside of our remit too, although the question needs answering. -- SSAC/Rod Rasmussen, Chair: SAC113 on Private Namespace – that is an ICANN/IETF interaction for creating a name/s that would be reserved from ever being published. It would have that space for private use. That is to try to address the issue that people keep picking up names and trying to do that; it would mitigate but not stop that practice. -- WG/Jeff Neuman, Co-Chair: We know this was talked about as an issue between ICANN/IETF, but it has wider ramifications. .onion and the satirical paper The Onion.

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Monday, 19 October 20:00 UTC
by Julie Hedlund Oct. 19, 2020

Oct. 19, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Monday, 19 October 2020 at 20:00 UTC. Proposed Agenda (also posted on the wiki<https://community.icann.org/display/NGSPP/2020-10-19+New+gTLD+Subsequent+Pr…>): 1. Review Agenda/Updates to Statements of Interest 2. Meeting with the SSAC re: draft Final Report; selected topics TBD 3. Review draft Final Report Public Comments – to prepare see the Public Comment Review Tool at: https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU… and review the following topics; we will cover as many as time permits: a. #32 Limited Challenge/Appeal Mechanism b. #9 Registry Voluntary Commitments/Public Interest Commitments c. #20 Application Change Requests d. #35 Auctions/Private Resolutions e. #2 Predictability f. #23 Closed Generics 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

2 2

Do we have an agenda for Monday's meeting?
by Jim Prendergast Oct. 19, 2020

Oct. 19, 2020

Jeff and Cheryl Will we have the SSAC or should we prep for more comment review? Nothing on the Wiki yet. https://community.icann.org/display/NGSPP/2020-10-19+New+gTLD+Subsequent+Pr… Thanks Jim Prendergast The Galway Strategy Group +1 202-285-3699

6 7

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 14 October at ICANN69
by Julie Hedlund Oct. 14, 2020

Oct. 14, 2020

Dear Working Group members, Please see below the notes from the working sessions on 14 October at ICANN69 at 12:00 and 14: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-14+ICANN69+Hamburg-+New+g…. Kind regards, Julie Notes and Action Items: Actions: #17 Applicant Support: ACTION ITEM: Staff to copy the ALAC and RySG comments on metrics into the Metrics topic. Notes: 1. Updates to Statements of Interest: No updates provided. Review draft Final Report Public Comments – to prepare see the Public Comment Review Tool at:https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIU…: Overview: -- Reviewing the comments to decide how the WG will deal with them, if not already addressed in the Final Report. -- Not working on final text/language for the Final Report. -- Staff will complete the Public Comment Review Tool and the overall statistical report by 21 October. -- Not trying to count or weight the comments – some represent groups, some individuals. #17 Applicant Support: -- ICANN Org notes that ICANN is not a grant-seeking organization. Role could be more as a facilitator with those organizations and applicants. Referred to the Pro Bono Assistance Program. -- Think through how we can have ICANN serve in a facilitation role while also ensuring that organizations can help applicants by providing pro bono services. -- ICANN Board comment: “Alternatively, ICANN org – through the Pro Bono Assistance Program – could act as a facilitator in the introduction of industry players or potential funding partners to the prospective entrants.” Seems that this doesn’t suggest that ICANN org is seeking funding. Not sure why that is “pro bono” as that relates to services that are provided but not charged. ICANN org could be the facilitator, but the applicant gets the money. -- Via constant funding there might be an affiliation with ICANN and it might attract attention of the anti-monopoly agencies around the world (not sure it goes well with fiduciary duties of directors) for such constantly funded registries. -- Might be helpful to have some context: in discussions over the years we’ve talked about the uniting of resources, such as how to reach all of the different parties. -- GAC comments: Some are definitional, which we can consider whether we need to provide more definitions – some are very difficult to define. -- One point the GAC raised is about ongoing ICANN fees. Some commenters supported that concept and some didn’t. Don’t see a clear answer coming from the community on yes or no. It will be difficult for the WG to make a concrete recommendation for ongoing fees. Consider whether there is some middle ground. -- Financial stability is important for second level registrants. If you can't pay the ICANN taxes, you probably aren't a safe bet for second level registrants. -- The WG didn’t come to agreement on differentiating applicant support for geos and non-geos. There are some comments on who ICANN org should work with to get funding, and those are implementation details we could pass on. -- On gaming: ask WG members from groups who submitted comments on gaming – be more specific as to why there would be more gaming and provide examples we can work with. -- Low numbers of applicants last round probably due to a combination of poor communications/marketing and disqualification of application if they do not qualify for Applicant Support. The other factor was poor marketing and communications. -- In part of the WG recommendations we say that unless the panel finds willful gaming they can convert to a regular application, but if there is willful gaming it can’t convert. -- INTA comment: That they did consider the possibility of gaming in order to prevail in the context of auctions and put in some guardrails there. INTA were flagging that the issue is a potential risk for all applicant support, not just with auctions. But we’ve already built in some guardrails: “INTA suggests that Implementation Guidance 17.7 be clarified such that the restrictions against gaming not apply solely to Applicants getting Applicant Support who prevail in an auction...” -- In terms of the RySG comments: “17.2 financial support should be clarified and/or expanded upon to include a variety of professional fees (beyond application writing and attorney fees) such as financial viability, securing funding, etc.” Also discussion of gaming – would like more specificity. WG will need to revise its recommendations also based on ICANN org comments. Need more information on this: “(see 35.2) Applicant Support applicants who have access to bid credits, multipliers, other should be protected from more sophisticated applicants who benefit financially from entering into a business combination or joint venture.” Move comments on metrics to the Metrics section. More clearly define “Going out of business”. -- NCSG comments: Look at outreach and communication section and see if we need to add. Facilitation for the Pro Bono Assistance Program should be made as early as possible. -- Line 22 ALAC comments: “We not only support a recommendation that “Community” should be broadly interpreted, but would go further to advocate that the way “community” is interpreted should be applied consistently throughout each aspect of the application process.” Need to make sure this is consistent with the Community Applications. -- Not sure why we can’t have two different definitions of community for Applicant Support and for evaluation of CPE. As well as for Community Objections. ACTION ITEM: Staff to copy the ALAC and RySG comments on metrics into the Metrics topic. #34 Community Applications: General Review of Comments: -- Re: ALAC’s comments don’t think the WG will be able to develop a concrete definition of what is community. -- Lots of groups that support the output completely. -- Needs to be two different standards – one for economic and non-economic-based communities – see ALAC comments – as a WG there is a general feeling that the way the CPE Guidelines were written in 2012 they were biased towards economic communities. The WG is working on revising the Guidelines to eliminate that bias. -- Swiss Govt. comments, line 11: “We note that consideration should be given to providing support for non-profit community-based applications, which is not included in final recommendations. In addition, we recall that one of the key criticisms of the Community Priority Evaluation (CPE) was that qualification as a Community application was far too difficult to achieve given the level of requirements or rather the severity of the material requirements or criteria set for this purpose. We are of the opinion that this point is not being sufficiently and effectively addressed by the SubPro PDP WG in its recommendations.” We did consider this although we talk about economic and non-economic – WG should make this clearer. -- Couple of comments on the scoring. We discussed this in the WG, but haven’t come to a conclusion. Even if we lowered the scoring to 12 from 14 that would have only resulted in one additional applicant being granted community status, so we have been concentrating on making the criteria more clear and attainable. -- ALAC comments: Going through comments (two documents) provided on the CPE Guidelines in the last few weeks. -- fTLD comments – they have Spec 12, community based, but didn’t have to go through CPE. Wanted to make sure in their comments that CPE Guidelines are more clear. -- Think more about the timing of when changes are made. Will consider more when we get to that topic. -- ICANN org has comments – a lot are which are in line with what we are already discussing – going through the Guidelines. -- Don’t see anything here that we aren’t already considering. -- <question>PICs are very problematic they allow contracted parties to bypass mandatory RPMs. It’s very curious why ICANN would want standardised contracts but allows private RPMs which have no oversight – Surely if a RPM is good enough for 1 gTLD it should apply to all gTLDs? Or if not none?</question> Board Comments on PICs/RVCs and Bylaws restriction on content regulation (falls in this topic as well as others): -- Question: Re: “In this context the Board also encourages the PDP WG to consider the mission-limitation that derives from the Bylaws, which state that ICANN will not restrict “services that use the Internet's unique identifiers or the content that such services carry or provide” (Section 1.1 (c)). The PDP WG may want to review the impact this provision might have on ICANN’s ability to enforce the content of community TLDs post delegation.” Board and ICANN Org comments casting doubt on whether community applications should proceed in the next round. Concerns about whether PICs/RVCs could conflict with the Bylaws. Can the Board provide any context? Why would a registry voluntarily agreeing to regulate itself be considered as content regulation? -- Avri Doria, Board: There will be differences between what the Board provided and what ICANN org provided. One set of issues relates to whether the commitments ICANN is responsible for enforcing can be enforced, or will they conflict with the Bylaws. If it requires looking at a complaint about content, is that an activity ICANN can engage in – enforcing a contract against a complaint about content. The Board is not making a comment about whether there should be priority or not, but we did look at what happened in the last round. The Board is asking whether there is a problem that could force the Board into the adjudication process. Is this a working method? How do we deal with the mission statement of no content regulation? -- The way the WG framed it is that there are ways to do this by treating it as a breach of contract that ICANN could have an outside panel make a determination (say a violation of a PIC) – that ICANN would only make a determination on what the registry agreed to do, on a breach of contract, not on content. -- If there is an issue with the Bylaws, the Bylaws can be amended. -- If it can only be solved with a Bylaws change then the Board would look at it. -- Avri Doria, Board: What we are saying now is please look at this and tell us if we are wrong. -- Seems like this is more of a legal determination. All the WG could say to the Board is that if they think there could be a violation of the Bylaws, if the community wants this then the Board needs to figure out it could be allowed in the Bylaws. -- The process for amending Fundamental ByLaws via the EC procedures would be pretty complicated. Moving PIC and RVC Dispute Resolution to an outside panel/provider would be more efficient. -- Will we find out way done the line that ICANN legal determines that the new PICs are not enforceable? We need input as to whether the wording allows us to have a new applicant have new PICs related to content. -- The Board is raising some important issues and not sure the WG has considered these issues. -- Section 1 of the ICANN Bylaws from the point of view that the restriction of content is not the be-all and end-all. The mission also involved in upholding security and stability. With respect to string similarity evaluation using PICs concerning different uses of singular and plurals of words seems to relate to security and stability. -- WG is not rejecting the Board’s comments, but trying to understand them better. -- Question: Is the issue PICs and RVCs as tools, or just as the intersect with content? Answer: Could be anything in the contract that could cover the content associated with the TLD. -- Jorge Cancio, Swiss, Govt.: In the 2016 Bylaws this was considered to be a good compromise that allows for different readings. There might be different interpretations of what the Board is posing in its question. The reading from the Board goes to trying to limit any legal dangers, but this is only one view of the mission. What does the restriction on content regulation mean in relation to the WG’s recommendation. The grandfathering in the Bylaws extends to any new PICs that are similar or analogous to the PICs previous to the 2016 PICs. There was an intention behind that to allow for similar PICs in the future. It is very important for this WG to look at the overall interpretation and the history of the creation of this piece of the Bylaws, and not just from a risk-mitigation approach. -- Avri Doria, Board: Risk aversion is part of its fiduciary role. The Board is asking for discussion, an understanding of the policy basis, finding a set of answers to the questions. Board always has to go back to the bottom-up, multi-stakeholder process. -- Don’t think the WG could agree on one interpretation of what the Bylaws mean, but even if we did it is irrelevant since only the Board can determine whether something violates the Bylaws. As a WG we have to decide what we think the policy should be and what we want to happen. The community needs to affirm that through its processes. If the Board approves the recommendation then the Board has to consider how and whether to approve and what that would entail. -- But if it's clear to us that something violates the bylaws, we shouldn't recommend that. If it's something grey instead of black and white then we could send the recommendation upstream. -- The WG shouldn’t just punt it to the Board. The Board is not going to amend the Bylaws to allow ICANN to regulate content. We should get a determination now and decide how to amend the recommendation. If it is already a process in the PICDRP that if ICANN determines something is related to content it can shift the evaluation to a third party, we should call that out in the recommendation. This should be a dialog with the Board now, to avoid a delay later. Don’t think we can afford punting this to the Board to determine later. -- The larger issue is that ICANN is an infrastructure group so they have stayed away from regulating content and maintaining content neutrality. -- The Board raised this issue concerning closed generics too. -- We need to get to the substance to ensure this is what we want to recommend and we all figure out how we want to make it happen. -- All ICANN is able to enforce is that stuff their bylaws define they can. That's expanded or shrunken elsewhere. Aligning / allowing agreements within that scope seems patently reasonable. -- Amending the Bylaws might actually increase risk.

1 0

Auction theory
by Rubens Kuhl Oct. 14, 2020

Oct. 14, 2020

This year Nobel prize on economics was awarded to the developers of the FCC spectrum auction system, making for some interesting reading: https://www.nobelprize.org/prizes/economic-sciences/2020/popular-informatio… <https://www.nobelprize.org/prizes/economic-sciences/2020/popular-informatio…> The book that was the basis for the prize is available at: http://www.econ.ucla.edu/riley/271/Milgrom-Putting%20Auction%20Theory%20to%… <http://www.econ.ucla.edu/riley/271/Milgrom-Putting%20Auction%20Theory%20to%…> At a first glance I don't see anything that wasn't already considered by the WG, but more in-depth reading might reveal otherwise. Rubens

1 1

Reminder/Work Plan Re: Proposed Agenda - New gTLD Subsequent Procedures PDP WG - ICANN69 Sessions Wednesday, 14 October
by Julie Hedlund Oct. 14, 2020

Oct. 14, 2020

Dear WG Members, As a reminder, please find below the proposed agenda and the attached agenda slides for the WG Working Sessions at ICANN69 on Wednesday, 14 October 2020. Please also see the draft Work Plan as discussed at the last WG meeting at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. Kind regards, Julie From: Julie Hedlund <julie.hedlund(a)icann.org> Date: Friday, October 9, 2020 at 10:35 AM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: Proposed Agenda - New gTLD Subsequent Procedures PDP WG - ICANN69 Sessions Wednesday, 14 October Dear WG Members, Please find below the proposed agenda for the WG Working Sessions at ICANN69 on Wednesday, 14 October 2020 at: Working Session 1 of 2 at 14:00 CEST/12:00 UTC for 90 minutes -- See: https://69.schedule.icann.org/meetings/oATf8ZTYxS9pC734Q Working Session 2 of 2 at 16:00 CEST/14:00 UTC for 60 minutes -- See: https://69.schedule.icann.org/meetings/g696FRw6tdbCetCDX Note that participation links will be published 24 hours prior to the session start. Proposed Agenda (also posted on the wiki<https://community.icann.org/x/GgebC>): 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the Public Comment Review Tool at: https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU… and review the following topics; we will cover as many as time permits over the two Working Sessions: a. #17 Applicant Support b. #34 Community Applications c. #32 Limited Challenge/Appeal Mechanism d. #9 Registry Voluntary Commitments/Public Interest Commitments e. #20 Application Change Requests f. #35 Auctions/Private Resolutions g. #2 Predictability h. #23 Closed Generics 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

3 4