December 2019 - Gnso-newgtld-wg

Re: [Gnso-newgtld-wg] [Ext] RE: Process Flow for Vickrey Auction Model
by Julie Hedlund Dec. 6, 2019

Dec. 6, 2019

Hi Jeff, Jessica sent me the attached editable version in Visio. She’s asked me to post it too. Kind regards, Julie From: Jeff Neuman <jeff.neuman(a)comlaude.com> Date: Friday, December 6, 2019 at 11:15 AM To: Julie Hedlund <julie.hedlund(a)icann.org>, "Hooper, Jessica" <jhooper(a)verisign.com>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Ext] RE: [Gnso-newgtld-wg] Process Flow for Vickrey Auction Model Thanks Jessica for this. If we can get an editable version of this over to ICANN policy staff, there are a couple of things I think we need to add, and to change around. For example, to the extent we have Pre-Delegation Testing, that would actually occur as part of Transition to Delegation as opposed to before objections. Plus we would want to add in some of the other elements. This is a great chart and one we can easily build on, so thanks again! Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Julie Hedlund Sent: Thursday, December 5, 2019 5:21 PM To: Hooper, Jessica <jhooper(a)verisign.com>; gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] Process Flow for Vickrey Auction Model Hi Jessica, Thanks very much for providing the flowchart. That’s really helpful. I’ve attached the document. Let’s see if this works. Kind regards, Julie From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> on behalf of "Hooper, Jessica via Gnso-newgtld-wg" <gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>> Reply-To: "Hooper, Jessica" <jhooper(a)verisign.com<mailto:jhooper@verisign.com>> Date: Thursday, December 5, 2019 at 5:13 PM To: "gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>" <gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>> Subject: Re: [Gnso-newgtld-wg] Process Flow for Vickrey Auction Model Looks like the file didn’t come through. I’ll work with Julie to get it posted to the group. Thanks, Jessica From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Hooper, Jessica via Gnso-newgtld-wg Sent: Thursday, December 5, 2019 5:06 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [EXTERNAL] [Gnso-newgtld-wg] Process Flow for Vickrey Auction Model Team – During a recent plenary meeting pertaining to String Contention Resolution, there were calls from WG members to have ICANN Staff develop a workflow or diagram to show how Alternative 1 (Vickrey Auction Model) from the Summary Document [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> would work and what that process would look like. Attached is a framework I put together when this idea first arose last year that illustrates the Vickrey Model and may address some of the outstanding questions around timing for objections… and it might save ICANN Staff from starting from scratch. Again, just a framework, a visual to help launch discussion. Thanks! Jessica Jessica Hooper | Senior Manager, Naming Operations | jhooper(a)verisign.com<mailto:jhooper@verisign.com> | O: 703-948-4553 |C: 1-571-230-2801 | verisign.com ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com [comlaude.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&…>

1 0

Process Flow for Vickrey Auction Model
by Hooper, Jessica Dec. 5, 2019

Dec. 5, 2019

Team - During a recent plenary meeting pertaining to String Contention Resolution, there were calls from WG members to have ICANN Staff develop a workflow or diagram to show how Alternative 1 (Vickrey Auction Model) from the Summary Document<https://docs.google.com/document/d/16qDoiK6vydQp6a0v9tMvU2l5fcypJY24hCzTIVT…> would work and what that process would look like. Attached is a framework I put together when this idea first arose last year that illustrates the Vickrey Model and may address some of the outstanding questions around timing for objections... and it might save ICANN Staff from starting from scratch. Again, just a framework, a visual to help launch discussion. Thanks! Jessica Jessica Hooper | Senior Manager, Naming Operations | jhooper(a)verisign.com<mailto:jhooper@verisign.com> | O: 703-948-4553 |C: 1-571-230-2801 | verisign.com

1 1

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 10 December 2019 at 03:00 UTC
by Julie Hedlund Dec. 5, 2019

Dec. 5, 2019

Dear all, Please find below the proposed agenda for the call on Tuesday, 10 December 2019 at 03:00 UTC for 90 minutes: 1. Review Agenda/Statements of Interest 2. Limited Appeals Mechanism -- Objections (second tab in the spreadsheet): https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8f… 3. Predictability Framework (if time permits): https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecG… 4. 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>. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 05 December 2019
by Julie Hedlund Dec. 5, 2019

Dec. 5, 2019

Dear Working Group members, Please see below the notes from the meeting on 05 December 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-12-05+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: ACTION ITEM 1: Staff will update the Limited New Appeals Processes spreadsheet based on today’s WG discussion at: https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8f… Notes: 1. Review Agenda/Statements of Interest: No updates provided. 2. Limited Appeals Mechanism https://docs.google.com/document/d/1pw98QzloHsVaM22VjYy95G-QmHULKbB2gPTSdzQ… What is the Issue we are Trying To Address? -- Are dispute resolution and challenge processes provide adequate redress options or if additional redress options specific to the program are needed. -- The Working Group believes that the accountability mechanisms set forth in the ICANN Bylaws (“Accountability Mechanisms) were inadequate in resolving issues that applicants or the wider community experienced during the 2012 round of the New gTLD Program. -- Although there have been significant changes to the Accountability Mechanisms as a result of the work done in conjunction with the IANA Transition, the Working Group still views them as insufficient to serve as the sole mechanism for redress within the New gTLD Program. Policy Goals / What the WG is Seeking to Accomplish The following from the 2007 policy continue to be appropriate: -- Recommendation 12: “Dispute resolution and challenge processes must be established prior to the start of the process.” -- Implementation Guideline R: “Once formal objections or disputes are accepted for review there will be a cooling off period to allow parties to resolve the dispute or objection before review by the panel is initiated.” -- Dispute resolution and challenge processes should be transparent, fair and cost effective and panelists, evaluators, and the Independent Objector must be free from conflicts of interests. -- Applicants and other impacted parties should have a challenge process to seek redress to errors in processes and/or outcomes, specific to the New gTLD Program. -- Any challenge processes must not conflict with, or impinge access to, Accountability Mechanisms under the ICANN Bylaws. -- Any challenge process must have measures to prevent frivolous usage. What are we Proposing? -- The WG proposes a limited substantive appeals process for certain types of actions or inactions that are inconsistent with the Applicant Guidebook. In general, the appeals process could be used to challenge evaluation results and/or objection panel determinations where those results or determinations are inconsistent with the provisions in the Applicant Guidebook. -- The new substantive appeal mechanism must not be a substitute for, nor act as a replacement for, the Accountability Mechanisms in the ICANN Bylaws that may be invoked to determine whether ICANN (staff or Board) violated the Bylaws by making (or not making) a certain decision. -- The substantive appeals process could apply to the following: Evaluation Elements [challenges] 1. Background Screening 2. String Similarity 3. DNS Stability 4. Geographic Names 5. Technical / Operational Evaluation 6. Financial Evaluation 7. Registry Services 8. Applicant Support 9. Community Priority Evaluation Objections [appeals] 1. String Confusion 2. Legal Rights Objection 3. Limited Public Interest 4. Community Objection 5. Conflict of Interest of Panelists Comments from Kathy: Recommend changing names for clarity: Challenges to Evaluation Elements could be called “Challenges” Appeals of Objections should be called “Appeals” One is more an administrative process, one is an arbitration process, and changes to name will make the process differences clearer. -- Confused about the different types of proceedings. Evaluations are between the applicant and the evaluation panel. The appeal is a more traditional judicial type of appeal. Using the same terminology for everything seemed confusing. Outline of Additional Recommendations: Discussion: -- Not intending to replace or do anything inconsistent with any of the accountability mechanisms in the ICANN Bylaws. -- Comment added by Kathy Kleiman: Where the appeal will be heard would be the same institution that heard the underlying objection, except for conflicts of interest. Consider making it clear that the recourse against Evaluations is a challenge to evaluation elements while in respect of objections the recourse is an appeal. -- Have a final decision for everything except for a conflict of interest. -- By adding “Challenges” and “Appeals” to the descriptions above shouldn’t limit who can bring challenges (such as third parties for background screening) or appeals. An applicant who is successful in an appeal from an Evaluation Challenge should not have to bear the costs of that appeal. -- I'm confused by this line. We are using appeal and challenge in the same sentence. Now that we are bucketing things, is this still accurate? All challenges and appeals except for the Conflict of Interest appeals have a “Clearly Erroneous” standard. Conflict of Interests should be reviewed under a “De Novo” Standard. -- Clearly erroneous favors ICANN, not applicants. Everyone cool with that? Not sure I am. -- Might want to flesh out what we mean by “clearly erroneous” -- such as reasoning arbitrary or a finding was not supported by substantial evidence. Cornell Law says, “Clearly Erroneous means: A standard of review in civil appellate proceedings. Under this standard, an appeals court must accept the lower court's findings of fact unless the appellate court is definitely and firmly convinced that a mistake has been made. In other words, it is not enough that the appellate court may have weighed the evidence and reached a different conclusion; the lower court's decision will only be reversed if it is implausible in light of all the evidence." Seems very high standard indeed. https://www.law.cornell.edu/wex/clearly_erroneous -- Suggested further standard for "clearly erroneous" - (a) arbitrary reasoning and/or (b) any element of the evaluation or Objection finding is not supported by substantial evidence.  -- What are the chances of a panelist from the same provider calling his colleague's decision "implausible"? Thought: approaches nil. -- It is my understanding that in legitimate arbitration forums there is always a process for handling conflict of interest issues. -- Other options are "arbitrary and capricious" and "substantial evidence". -- I think we should chart out what the various standards of review actually are. This seems to me like we have just thrown a dart across the room and hit "clearly erroneous" Limited New gTLD Appeals Processes: https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8f… Background Screening: -- Need to add members of the contention set as potential affected parties. Make even more broad -- third parties that could show some potential direct impact on them if the background screening is botched. -- Justine Chew: On Background screening, please refer to my email to WG of 21 Sep 2019. DNS Stability: -- Question: Should a backend provider have a right to appeal? Answer: This refers to the string itself, not to the operation. Not an issue with the backend or frontend provider. Technical Operations: -- Question: Should you be able to amend your application if the backend provider has a problem? Answer: Yes it makes to provide a challenge mechanism for the registry backend provider that is applying for pre-approval and fails. It would make sense the applicant could challenge the results on behalf of the backend provider. Financial -- Existing Evaluator Entity - Different individual Evaluator? -- Who would be an arbiter of a failure? Don’t think it would be at the same financial house. -- Who would have the expertise for an appeals mechanism? -- Have to consider the potential costs of having another evaluator. -- Selection of provider should include a question on whether the provider has an appeals procedure in place. I am now wondering the need to reconsider implications of that. -- Don't think we should rush through Column E. An appeal to someone's buddy down the hall is not a meaningful appeal. -- CPE and evaluation challenges are likely to require an independent evaluator. So, then ICANN would need to hire two firms. Ramping up two different providers could be very resource intensive. Think about the impact on costs and complexity. Or maybe ICANN could be the arbiter. -- ICANN being the arbiter puts ICANN much closer to content regulation since content is at the heart of Community proposed purpose. -- Flag as a potential issue and for others where there might need to be multiple providers. -- Support - Evaluation Challenges should be considered by an Alternate Qualified Provider.

1 0

Support for CCTRT recommendation for incentives
by Levine, Gertrude Dec. 5, 2019

Dec. 5, 2019

Hi all, I tried to post the following comments last week, but apparently they did not appear on the list. After conferring with Julie, I am trying again: I was unable to join the 26 November meeting; however, I would like to express my support for three of the ideas raised in the November 21 meeting in regard to the CCTRT recommendation to provide incentives or remove disincentives for new gTLDs to operate as verified TLDs. * ICANN's fees should be lowered for verified TLDs * In the case of string contention, applications for verified TLDs should get priority. * In the event that an applied-for string is similar to an existing verified TLD, and the applied-for string does not have the same or similar safeguards as the verified TLD, this would confuse and could harm end users. As such, it should be adequate grounds to file a formal objection. To preventing gaming, "verified TLD" could be defined in a specification within the RA. Thoughts? Thanks! Gertrude "Gg" Levine Digital Health Manager National Association of Boards of Pharmacy 847/391-4497

1 0

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 05 December 2019 at 20:00 UTC
by Julie Hedlund Dec. 2, 2019

Dec. 2, 2019

Dear all, Please find below the proposed agenda for the call on Thursday, 05 December 2019 at 20:00 UTC for 90 minutes: 1. Review Agenda/Statements of Interest 2. Limited Appeals Mechanism https://docs.google.com/document/d/1pw98QzloHsVaM22VjYy95G-QmHULKbB2gPTSdzQ… 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>. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Re: [Gnso-newgtld-wg] [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019
by Julie Hedlund Dec. 2, 2019

Dec. 2, 2019

Dear Anne, The discussion was in the context of this topic: “Additional Considerations (Mostly For Alternative 1)” so the assumption was that the request related to Alternative 1, but we note your point that the action could also be attributed to Alternative 2. Kind regards, Julie From: "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Monday, December 2, 2019 at 1:27 PM To: Julie Hedlund <julie.hedlund(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Thank you. Regarding Action Item 3, I thought the flow chart would also be applicable to Alternative 2. Are we saying there will only be a flow chart for Alternative 1? Thank you, Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Julie Hedlund Sent: Monday, December 2, 2019 9:52 AM To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 02 December 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-12-02+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: ACTION ITEM 1: Add a third alternative. ACTION ITEM 2: Add another goal (#7): “Increase efficiencies in application evaluation by way of understanding the contention set?” ACTION ITEM 3: Create a flow chart with a fictional string to show how alternative 1 would work. ACTION ITEM 4: Update the list of goals. Notes: 1. Review Agenda/Statements of Interest: Susan Payne was reappointed IPC Secretary for another year. 2. String Contention Mechanisms of Last Resort: https://docs.google.com/document/d/16qDoiK6vydQp6a0v9tMvU2l5fcypJY24hCzTIVT… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> What is the issue we are trying to address: -- The Working Group has discussed a number of potential issues with the mechanisms of last resort used in the 2012 New gTLD Round. These issues are captured in the Supplemental Initial Report. -- Although the Working Group ultimately believes that when there is string contention, an auction process should be used to select the Registry Operator invited to enter into a Registry Agreement with ICANN, the Working Group is still discussing what forms of private resolution should be allowed (if any), the specific type of auction to be used, and the timing of such an auction. Policy Goals / What the WG is Seeking to Accomplish: -- The WG is largely supportive of existing Implementation Guideline F: Implementation Guideline F: If there is contention for strings, applicants may: i) resolve contention between them within a pre-established timeframe ii) if there is no mutual agreement, a claim to support a community by one party will be a reason to award priority to that application. If there is no such claim, and no mutual agreement a process will be put in place to enable efficient resolution of contention and; iii) the ICANN Board may be used to make a final decision, using advice from staff and expert panels. Other goals include: 1. Reduce the risk of “bidding wars” in which the winner ultimately overpays for the TLD. a. Tentative, related goal for discussion: encourage applicants to bid their true value for a TLD. 1. Reduce collusion, profiteering, and/or speculation, especially as it relates to financial transactions external to the program (Note, while this is not an explicit goal for the mechanisms of last resort, it has been discussed as a motivation for altering the auction mechanism). 2. Increase transparency. 3. Resolve contention more quickly. 4. Increase predictability. 5. Encourage new entrants into the field. a. Which could include, making it easier to implement “multipliers” for certain types of applicants, such as those eligible for Applicant Support. -- Note that some of the terminology may need to be further defined if the above goals are adopted. In order to ensure that recommendations align with goals, it is important for the Working Group to agree on specific objectives. Discussion: -- Do we still need iii)? An alternative may be, "The ICANN Board may use expert panels to make Community Priority Evaluation determinations." This may also be dependent on recommendations on the new appeals mechanism. -- ICANN Board says it does not make policy. Its decision would be subject to RFR and IRP - very messy so it may be better to stick with what we developed earlier. -- This isn’t about the Board making policy, but making it clear that it’s an auction process rather than the Board making a decision. -- There should be a reference instead to Auction of last resort. -- Agree they are good goals so suggest removing possible description What are we Proposing? -- The Working Group is leaning towards recommending a sealed-bid auction as the ultimate form of auction used as a mechanism to resolve string contention. When a sealed-bid auction is held where bids are submitted without knowing the bid of others in the auction (e.g., prior to evaluating any of the applications) it is also called a Vickrey Auction. A sealed-bid auction can also be used as a mechanism of last resort and at the end of the process. -- With a sealed-bid auction, each applicant submits a sealed bid, stating the amount that they are willing to pay for the TLD. The ultimate “winner” pays the amount submitted by the second-highest bidder.. -- Regardless of when the sealed bid auction is held, if there are one or more Community-based Applications, that/those application(s) would need to be processed first through Community Priority Evaluation before looking at the auction bids. Alternative 1 - Vickrey Auction (No Private Resolution) -- Addresses goals 1, 2, 4, and 6. -- The principle pro here is the seemingly near elimination of private resolution. However, the principle con is the substantial complications this approach introduces (see Additional Considerations, Mostly For Alternative 1 below). Other cons are that other forms of private resolution might be impacted (e.g., joint ventures, string change, etc.) in seeking to eliminate private resolution for financial benefit and that bids are submitted with no contextual information. Alternative 2 - Sealed-Bid Auction allowing Private Resolution -- It seems to be supportive of, or at least not impede, 1, 2, and 6, but in a less pronounced manner as it relates to Alternative 1; the maker of this Alternative has acknowledged that it does not fully address concerns around potential collusion and profiteering on application withdrawals. -- However, some benefits are likely derived by obtaining sealed bids (which can reduce the incentive for all parties to agree to private resolution, if an applicant already knows they have the highest bid). The other main pro here is simplicity - most other processes remain unaffected. Discussion: -- Re: Alternative 2: First bullet point and third bullet point seem incompatible. Third bullet point: “Applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or to choose another string as was suggested for ‘brands’ of the same name.” -- Assuming you stayed in only those applicants who stayed in would be revealed on reveal day. So you could still have private resolution. -- For clarity, the third bullet could be swapped with the fourth bullet and add “post reveal day”. In third bullet point, after "opportunity", you would need to insert "after reveal day" or something to clarify that parties become known. -- Question: Wasn’t one of the proposals to outlaw private auctions? So not sure why we are still allowing private resolution. Answer: If we went with alternative 1 we would eliminate private resolution, but not for alternative 2. So that is one of the drawbacks with alternative 2. -- Thought alternative 2 was to allow participants to know how many contention sets there are. Add as a third alternative: Alternative three could remove some of the elements about private resolution. -- They may not resolve privately and should only have a limited period to resolve. If not resolved in a limited period, it should proceed to the sealed bid winner. I am not seeing the time limit in alternative 2 though. Is it there? -- Question: How would the timing work with a string contention objection process? -- How could private auctions be prevented? -- Objections should not be triggered until a winner (or a private resolution winner) is identified. -- Re: Alternative 2 there should be a limited time for private resolution. -- Helpful to put these alternatives out for public comment and indicate whether the WG has a preference. -- Re: Alternative 2 -- Question: For string confusion objections those would have to be heard right away. Additional Considerations: Public Comment: Comments from the public are solicited on all applications regardless of where they are placed in the queue. To do it otherwise would mean opening up separate public comment periods depending on whether there is a need to go to the second bidder, and that would be impossible to monitor. Discussion: -- Strongly support 1 public comment period, for the exact same length of time for all. -- Impractical to have multiple public comments. String Similarity Evaluation: Discussion: -- Don’t see how this fits with the notion of closed bids and timing. You have a scenario where you have some who know who they are bidding against and everyone else doesn’t. -- In the scenario where the result of a string similarity evaluation is that some would have insight into who is in the set -- this is an unfair result. -- Which is why getting every applicant to submit a bid at the point of application is something to consider, even though it may be cumbersome for many. -- What if this fact situation should default to sealed bid only? -- Why would they not be all announced at the same time? -- So we are proposing to treat some applicants differently from others? That does not seem to be in line with the Bylaws. -- Wouldn’t alternative 1 solve this issue? -- What about plurals? -- There was only one case in 2012 that was found to be similar (unicorn/unicom). -- Why string similarity evaluation after reveal day? Why not make it before reveal day? That is a possibility. -- is string similarity not subject to accountability mechanisms and appeals? would that not “reveal” it in some manner? -- Agree with that suggestion re string similarity evaluation occurring first and before reveal day. bids would have to be in before appeal. Objections: Objections on the highest bidder’s application must be filed within the objection period. With respect to objections to the other applications, ICANN would create a system for the filing of “an intent to file an objection.” Discussion: -- Question: What happens when someone indicates that they are filing a community objection and they are filing it against all of the applicants for a string. Answer: All applicants should have a chance to respond. Add text to relay your comment on "can indicate that an objection will apply to all applications for same string"?  -- Objections should not come into full proceedings unless and until there is a winner - it's a huge waste of time and money if it does proceed but private parties need to know what the value of the string may be. -- Some concern about not having to submit the objections on a standard timeline, although support not engaging fees or panels until the objection is necessary, based on bidder ordering . -- “time” may benefit some as they build their case. Or could the “intent to file” require some key points that will be included in the objection filing? -- Question: We are agreeing on the principle that the intent to object is a good idea, but when would that happen? Would one party have to state the type of objection and the grounds? Could it just be a party filing very general intent to objection concerning a risk associated with that application. Would there be a panel for an intent to object process? Answer: Proposal was that the objection would be “bare bones”. There would be no panel if it was just an intent to object to one application, but if for all applications (to the string) then one could request a panel. You file your objection against the applicant first in the queue and an intent to file against the others in the queue. Or, you could say I have the same objection to all of the applicants/string. -- Important for private parties in resolution to know that there is an intent to object (but that doesn’t pertain to alternative 1 as there is no private resolution). -- The objection should be submitted within a certain time period. -- The nature of the applicant is important. It's not just the existence of the string. It depends on who is operating it and what the purpose of the tld as stated in the application in Question 18 answers and services to be provided in answer to Question 23. There should be an intent to object process prior to determining the order of the queue with no panel convened. Other complications: Objections if there is more than one Community Application String Confusion Objection Results in the Creation of a New Contention Set or Adds to an Existing Contention Set Appeals/Accountability Mechanisms Applicant Support Program Discussion: -- Seems that these are all related to the attempt to gain efficiencies to know the order of the contention sets. If you don’t need to know the order then you could leave the program untouched. If you go back to the goals knowing the order of the contention sets goes to goals 3, 4, and 5. -- Add a goal: “Increase efficiencies in application evaluation by way of understanding the contention set?” -- Note that alternative 1 would eliminate the goal to allow contention resolution. “If there is contention for strings, applicants may: i) resolve contention between them within a pre-established timeframe” ________________________________ 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

Post call / New gTLD Subsequent Procedures Working Group call on Monday, 02 December 2019 at 15:00 UTC
by Michelle DeSmyter Dec. 2, 2019

Dec. 2, 2019

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Monday, 02 December 2019 at 15:00 UTC can be found on the agenda wiki page (<https://community.icann.org/x/2pYzBw>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, Michelle

1 0