All The suggestion that I made toward the end of the call was on the fly and I have not had an opportunity to fully think it through. So while I appreciate Jeff’s effort to capture what I suggested below, I wanted to flag that Jeff’s description is not completely aligned with my overall thinking. I’ll come back to the list about this tomorrow. Donna From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Thursday, October 17, 2019 3:32 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction At the end of the call that just wrapped up we had a good discussion on a potential compromise regarding auctions that I want to continue the conversation in this thread before we lost momentum. WARNING: THIS E-MAIL MAY RESULT IN YOUR HEAD SPINNING FROM THE POTENTIAL PERMUTATIONS. If I understood correctly, the proposal was that we consider the following: What if at some point prior to reveal day, ICANN were to notify all of the parties that are in a contention set that they were in a contention set. Perhaps even telling them how many other applicants they were in a contention set with. But there would be no disclosure of WHO was in the contention set. Then each applicant would be given a period of time (Which would end PRIOR to reveal day), to either withdraw their application or submit a sealed bid. ICANN would then process only the application that submitted the highest bid. If the application with the highest bid gets through the entire evaluation/objection processes and to the contracting stage, it would then be responsible for the payment of an amount equal to the second highest bid. If that applicant did not make it through the evaluation/objection processes for whatever reason, ICANN would then start processing the application of the second highest bidder and if that bidder were successful, it would at contract stage pay ICANN the price of the third highest bidder, etc. Here are the potential issues/questions [and some of my initial thoughts]: 1. If there are one or more Community Applications, that/those application(s) would need to be processed first through CPE before looking at the auction bids. 2. What happens on Reveal Day? Are all of the applications (that have not been withdrawn) posted regardless of whether they are first in the queue or not? [I would say yes so that they next steps can be completed]. 3. If they are all revealed, would the order of where the bids came in (but not the amounts) be posted? I would say again yes. 4. Would comments from the public be solicited on all applications regardless of where they placed in the queue? I would say yes because 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. 5. How does String Similarity Evaluation fit in here? * For exact matches and plural/singular (if that rule is adopted), it will be clear who is in a contention set. * But, what if String Similarity Evaluation determines that others should be in the Contention Set? * Although String Similarity Evaluation is after reveal day, if the panel decides that another string should be added to an existing contention set, or it results in the creation of a new contention set, the following should happen: i. If it creates a new contention set, the all of the applicants in the new contention set would be asked to submit bids. Yes, they would know who they were in a contention set with, but that is just something I think we need to live with. ii. If new applications were added to an existing contention set, then the new applicants would be asked to submit a sealed bid. Yes, they would know who was in their contention set and if the applications are poste in the order in which they bid, they would know who they would have to outbid, BUT, they would not know how much the others bid. This too in unavoidable. 1. Would objections need to be filed during the objection period? * This is a much more difficult question. My proposal would be that objections on the highest bidder’s application would certainly need to be filed within the objection period. * With respect to objections on the other applications, I believe there should be something akin to the filing of “an intent to file an objection” with respect to other applications. But the actual Objection filing would not need to be made unless the first application did not succeed. If ICANN needs to go to the second bidder, the party(ies) that indicated an intent to file an objection would be given 30 days to file that objection at that time. If the first applicant proceeds to contracting, then there would be no need to hear any objections on the second, third, etc. applications. 2. Is #5 above the same if there are one or more Community Applications? * I would say that all Community Applications for a string would be treated as if they were first in the queue for the purposes of #5. So, objections on the community applications would need to be filed during the original objection period, but “intent to file objections” would need to be filed (if any) on the others. * If more than one Community Application passes CPE for a string, then the highest Community bidder would be processed through the rest of the process first. If for whatever reason they do not succeed, then it would go to the 2nd Community Applicant that passed CPE, etc. * Then, the objections (if any) on the non-Community Applications would only be heard if the Community Applications do not pass CPE. 3. What if a String Confusion Objection results in the creation of a new contention set or adds to an existing contention set? * I think this would be treated similarly to the String Similarity Evaluation results. * What this means is that after all String Confusion Objections are filed within the Objection Period, ICANN would need to determine whether there would be a possibility if the outcome could result in the creation of a new contention set or add to an existing contention set. If that possibility exists, then ICANN would need to hold off on proceeding with the potentially impacted strings until after the results of the String Confusion Objection are in (as well as any appeals of those decisions). 4. How do Appeals/Accountability Mechanisms work with this? * All appeals/Accountability Mechanisms of the first application in the queue must be exhausted. If the first application in the queue for whatever reason loses an appeal and that results in the failure of the application (for whatever reason), then and only then would the second in line be processed. 5. How does the Applicant Support Program figure into this? * If we decide that Applicants who are given support get a multiplier on their auction bid (But not Priority), that would get figured in at the appropriate time in determining their order in the queue. * If we decide that Applicants who are given support do not get a multiplier on their auction bid, then this would have no impact on the proposal. If you made it this far, I am not only amazed, but also proud 😊 Great job! Best regards, Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.comlaude.com_&d=DwMG...> [cid:image001.jpg@01D58518.AA1A5760] ________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&c...>
