Dear Working Group members, Please see below the notes from the meeting on 06 August 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-08-06+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Draft Final Report: ACTION ITEM: Send email listing all documents for the WG to consider to finalize the Report. Public Comment Survey Tool: ACTION ITEM: Change the radio button to: “[Do not support certain aspects, or all, of the Output(s)” Private Resolutions Discussion – Model 6: ACTION ITEM: Re: Other Forms of Private Resolution -- Add a couple sentences to deliberation section to say that some working group members proposed adding this disclosure requirement (“All material terms of any arrangement between applicants to privately resolve a contention set (financial or otherwise) must be disclosed to ICANN [and the community]”) and include the rationale, while others opposed it. ACTION ITEM: Re: “The information obtained from the contention resolution process may not be used by ICANN for any purpose other than as necessary to evaluate the application in accordance with the requirements set forth in the Applicant Guidebook.” Amend the text to include “for any purpose other than is necessary to evaluate the application, the new gTLD or to otherwise comply with the law.” ACTION ITEM: Leadership and staff to revise Model 6 based on the WG discussion during the meeting on 06 August and send the text for review on 07 August. Notes: 1. Updates to Statements of Interest: -- Donna Austin is now with GoDaddy. 2. Final Report Structure and Public Comment Survey (Demo) Schedule: -- If we finish Private Resolution today, then we will cancel Monday’s meeting to allow time to review documents. -- Finalize everything by 14 August. Draft Final Report Change Analysis: https://docs.google.com/document/d/17oV-BTJGtm2Q6w15qxqtsvRZg6PuW9WHGPOG1Kgs... 
 -- Show substantive differences, but also where there are minor changes. -- Also note where there are no changes. -- Send an omnibus email indicating all of the documents that the WG should review. Public Comment Survey Tool: Demonstration: -- Requirement to enter email and name/affiliation is standard procedure for the public comment forum. -- Encourage using the Word form document to enter changes and then cut and paste into the Google form (but can save progress also in the Google form). -- Staff will assist if access/use of Google is not possible. -- The instructions describe the 5 outputs in the draft Final Report: (a) Affirmation, (b) Affirmation with Modification, (c) Recommendation, (d) Implementation Guidance, and/or (e) No Agreement. -- The survey is asking for input on those outputs. -- Each topic has its own section with the option to save at the end of each section. -- The topics follow the order in the draft Final Report. -- There is a reference to the page number for that topic in the Final Report and we’ll explore whether we can include a link to the document. (Subsequent testing shows that links do work.) -- The demo focused on the first five topics as an example. -- The Description of Difference text is the same as that in the “Draft Final Report Change Analysis” document that is out for review by the WG. The introduction to each topic includes the following text: “The below description of difference is intended to serve as a resource for readers to better understand which report topics have evolved significantly from the Initial Report to the draft Final Report. The differences are listed in a descriptive fashion and readers should review the full set of Outputs for the relevant topic as a package, to better understand the full context of the Outputs and changes made.” -- The demo highlighted the various types of differences: 1) minor (including brief description); 2) substantive (including brief description); 3) no substantive differences (so no description of changes). -- The survey questions are the same for each topic. Responses that support, can live with, or have no opinion are not followed by a comment box (although text can be provided as comments); responses that can’t live with (or do not support, see discussion below), or where there is information or interests that the WG has not considered should include comments in the boxes provided. -- There are open text boxes at the end of the survey that may be used to provide input on recommendations that the WG didn’t consider, or any other comments. Discussion: -- There will be a webinar to demonstrate the survey tool after the public comment period begins. -- Any request for an extension beyond the 40-day public comment period will be considered by the leadership team in coordination with support staff. -- Question: Can we comment when we support or can live with the outputs? Answer: You can but there won’t be a text box associated with that response. The survey is designed to focus on whether there are recommendations that people can’t live with or can support, with the focus on getting comments where there is no support or people can’t live with something. -- More than one person can access the Google survey form at the same time, but we recommend using the Word form to capture the input and then cutting and pasting it into the Google form. -- The numbering of the topics matches that used in the Final Report, which is simplified from the numbering we have been using in the production document. -- Question: Why use “Can’t live with” instead of “Do not support”? Answer: That follows the format we’ve been using, but it doesn’t have to. We can use “Do not support” and also include “or all” of the Outputs. ACTION ITEM: Change the radio button to: “[Do not support certain aspects, or all, of the Output(s)” -- What sort of comment would be applied to a “Yes, we support this” that that would add further benefit to the evaluation of any of the or assessment of any of the comments coming in? There will be lots of comments coming in and how do we avoid subjective analysis? Can we put them into clear categories? -- Some groups might want to explain why they can live with a recommendation – why they are willing to compromise. Also, if there isn’t that option the comments will all be negative. Not necessarily reflective of the support. -- The radio buttons for support and can live with will show the support – they don’t need to have comments associated with them to be counted. And we won’t use the donut charts which can sometime mischaracterize the level of support. -- Could consider whether to include a text box after the support and can live with option to say why they were willing to compromise, but have to think about how to avoid that becoming a subjective analysis. But we are trying to have a simple approach and keep people tight with their responses. We also don’t have much time for analysis and deciphering comments where people indicated support but then commented. -- Helpful to know why someone supported something or conditionally supported something. -- Nothing is preventing someone from entering text in the text boxes. We are just trying to organize this in a way that is easy to analyze. This is supposed to be a Final Report and we organized the survey to get comments on the aspects that people do not support. -- Question: Can we get access to the Google spreadsheet that this the output from the Google form and then provide our response in the form of a spreadsheet for staff to input? Answer: Staff would not be able to easily integrate that type of input into the Google spreadsheet without a great deal of manipulation. It wouldn’t be technically feasible. 3. Continued Private Resolutions Discussion – Model 6 (https://docs.google.com/document/d/15qdNbLO1-EfXdQosA7fK1ugQtaaMzwof2-viKCQl...) Contention Resolution Transparency Requirements -- What we added in here was a recommendation from arm Paul to put in a time frame of when the stock would be disclosed. New text: “In the case of a private auction or an ICANN auction of last resort, all parties in interest to any agreements relating to participation of the applicant in the private auction or ICANN Auction of Last Resort must be disclosed to ICANN within 72 hours of resolution and ICANN must, in turn, publish the same within 72 hours of receipt.” -- Also added a footnote on the contact information: “Contact Information will be subject to the same publication rules as contact information was treated in the application process.” -- Added from the previous list: “The value of the Applicant Support bidding credits or multiplier used, if applicable.” Other Forms of Private Resolution Deleted: “All material terms of any arrangement between applicants to privately resolve a contention set (financial or otherwise) must be disclosed to ICANN [and the community]” -- Comment from Elaine Pruis: “all material terms of any arrangement” has been replaced with “material information regarding changes to the ...applications” – these are not the same thing. Have we discussed and agreed to this substitution? -- This was hotly contested on the call where we last discussed this. Some were very much opposed to disclosing anything. -- This sentence required disclosure of all kinds of sensitive information. -- There are all kinds of deals that could be made that could impact the overall outcome of the program and we’re remiss to not ask people to tell us, or tell the community or the public what arrangements have been made in order to resolve a contention. ACTION ITEM: Re: Other Forms of Private Resolution – Add a couple sentences to deliberation section to say that some working group members proposed adding this disclosure requirement (“All material terms of any arrangement between applicants to privately resolve a contention set (financial or otherwise) must be disclosed to ICANN [and the community]”) and include the rationale, while others opposed it. Re: “The information obtained from the contention resolution process may not be used by ICANN for any purpose other than as necessary to evaluate the application in accordance with the requirements set forth in the Applicant Guidebook.” -- There was a debate on competition authority review and that ICANN Org had the right to do that, so we didn’t need language stating that. -- Comments from Justine Chew: I generally disagree with the sub-bullets here. Disclosure is not only required for proper evaluation but also the source of data to support better policy making. If protection is to be afforded to disclosing applicants, then limit to just non-disclosure by ICANN/evaluator of information exactly of the kind not made public in the application form. -- We can put some other something else in there to allow for the use of the information for the evaluation of the program, not just the application. -- Comments from Paul McGrady: So maybe, just maybe, we could say for any purpose other than is necessary to evaluate the application, the new gTLD or to otherwise comply with the law. ACTION ITEM: Re: “The information obtained from the contention resolution process may not be used by ICANN for any purpose other than as necessary to evaluate the application in accordance with the requirements set forth in the Applicant Guidebook.” Amend the text to include “for any purpose other than is necessary to evaluate the application, the new gTLD or to otherwise comply with the law.” Factors to Consider in Determining of Non-good faith Intent. -- Comment from Paul McGrady: “Consider deleting the highlighted text as it is redundant with the intro paragraph for this section. If you decide to keep this redundant language, propose change from "non-good faith Intent" to "whether or not an applicant breached the Terms and Conditions in the Applicant Guidebook"” -- Not having the requisite bona fide good faith intent is a breach of the terms and conditions. -- Don't think that these are really good proxies or factors for determining no bad faith or not good faith. We should not seek complicated subjective solutions, we should see simpler, objective solutions. -- That was why we had this compromise to determine non-good faith intent. If we can’t agree on these factors then we don’t have a compromise. If you can’t have controls on private resolution then you are arguing for not allowing it. -- Let’s get public comment on the proposal and see if there are other factors we can include. -- Maybe we need to work backwards from the reasons that some want to ban private auctions. -- Don’t think we should use “non-good faith” as a term. -- Make the factors examples rather than exclusive factors and tie them to the T&C rather than "non-good faith" (whatever that is). -- How about "noncompliance with the bona fide intention" requirement instead of "non-good faith intent"? -- “For which there is no reasonable good faith explanation”. -- Question: At what point would ICANN be making this determination? Answer: After the fact. Very late in the process. -- So why not just say that if there is reasonable evidence that the applicant does not have the good faith intent to operate the TLD the ___consequences occur. ACTION ITEM: Leadership and staff to revise Model 6 based on the WG discussion during the meeting on 06 August and send the text for review on 07 August.