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<http://www.comlaude.com/> [cid:image003.jpg@01D58519.1C04C950] ________________________________ 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://comlaude.com>
Jeff, Is your point that you don’t want to have fruitless Objections filed against non-winning bidders? So are you saying that the highest bidder is revealed and that triggers the Objection clock? Anne From: Gnso-newgtld-wg <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 [EXTERNAL] ________________________________ 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<http://www.comlaude.com/> [cid:image001.jpg@01D58501.533A7860] ________________________________ 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://comlaude.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.
Hi Jeff, Looks all good – BUT: you seemingly left out the possibility to elect private contention set resolution. * As far as I understood we leave it to the applicants to choose whether or not they try “private contention set resolution” (which in the 2012 round amounted to private auctions). * As you stated: if there is contention then we ask the members to submit Vickery bids (without giving them ANY other information). * Then the reveal day comes. We inform the highest Vickery bidder THAT he is the highest bidder (NOT how much the 2nd highest bid is) and thus we enable him to inform the contention set: “Sorry, I am not interested in a private contention resolution; because I can get the TLD in the Vickery auction: and I am fine with that”. We then evaluate that applicant. * This way we would INCENTIVIZE applicants to NOT go into private auctions (I tried to explain that during the call today) * However: If the high-bidder of the Vickery auction should elect to try private contention resolution (private auction) and all other contention set members as well: what then? Regardless HOW their contention set resolution would look like – they would likely want to be 100% sure that all contention set members pass the evaluation, right? So in THAT case the entire contention set would inform ICANN that they wish that ALL applications are being evaluated because they want to enter PRIVATE contention set resolution only once it’s clear all members pass the evaluation! Imagine one applicant wins the private contention resolution, all others “withdraw” their applications – but then the guy who survived DOESN’T pass evaluation? So really we have 2 scenarios (if there is no community applicant involved): 1. If the ICANN Vickery auction winner elects the ICANN contention resolution: we only evaluate him – and he then pays the 2nd bidders bid price and its over (and the other’s get a full refund?). The high bidder would ONLY get the information THAT he is the high bidder – NOT the amount of the 2nd bid yet! So that applicant knows the potential MAXIMUM they have to pay (a tad below their own bid) – but have no other. So nobody gets “tipped off”. Only if the ICANN last resort resolution is being triggered that applicant would be informed about the exact sum they have to pay. 2. If all contention set members demand an evaluation – we have to do so, so they can enter into private contention set resolution! Which further delays everything for them and makes it even MORE attractive for the Vickery Auction high-Bidder to enter into the ICANN contention set resolution of “last resort” (which suddenly is not anymore “last resort” but actually “speedy resolution”). 3. If neither 1 or 2 is the case (meaning: the winner doesn’t say “OK, I pay and am done” – but also not all contention set members demand an evaluation) then the fallback is “scenario 1” - after a certain time frame during which the contention set COULD in theory come up with some contention resolution (even if not all applications are evaluated). E.g. if there are only 2 applicants the high bidder could offer a buyout – regardless the evaluation status of the 2nd bidder. Thanks, Alexander From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Friday, October 18, 2019 1:32 AM 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? a. For exact matches and plural/singular (if that rule is adopted), it will be clear who is in a contention set. b. But, what if String Similarity Evaluation determines that others should be in the Contention Set? c. 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. 6. Would objections need to be filed during the objection period? a. 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. b. 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. 7. Is #5 above the same if there are one or more Community Applications? a. 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. b. 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. c. Then, the objections (if any) on the non-Community Applications would only be heard if the Community Applications do not pass CPE. 8. What if a String Confusion Objection results in the creation of a new contention set or adds to an existing contention set? a. I think this would be treated similarly to the String Similarity Evaluation results. b. 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). 9. How do Appeals/Accountability Mechanisms work with this? a. 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. 10. How does the Applicant Support Program figure into this? a. 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. b. 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: <mailto:jeff.neuman@comlaude.com> jeff.neuman@comlaude.com <http://www.comlaude.com/> www.comlaude.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 <https://comlaude.com>
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...>
All Just to come back to my suggestion from Thursday. 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. That part of Jeff’s restatement of what I proposed is largely correct—the finer details to be worked out. This goes some way to overcoming Neustar’s concerns with the Vickery model that recommends submitting a sealed bid with the application. There is no way of knowing how many applications will be submitted next time around, which makes it difficult for potential applicants to assign a value to the string beyond what they’re paying to submit the application. If the applicant is made aware that they in a contention set for a string, then they have a little more information to work with in deciding a value and submitting a bid; however, the bid is only intended to be relevant in the event of an auction of last resort. ICANN would then process only the application that submitted the highest bid. This assumption is incorrect. Our recommendation is that the applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or chose another string as was suggested for ‘brands’ of the same name. Applicants would not know before reveal day who they are in contention with and would submit a bid absent that information, but they would become aware after the fact and should still have an opportunity to resolve the contention privately. It’s important to remember that a private auction only happens if all bidders agree to do s. I understand concerns about collusion and profiteering. I understand that what I’m suggesting may not overcome those concerns, but perhaps what we need in order to address those concerns is to have a policy statement that expressly prohibits collusion and profiting from the new gTLD. I don’t know how you enforce such a policy statement, but perhaps it would be enough to serve as a deterrent to this type of behavior. Donna Donna Austin Neustar, Inc. / Senior Policy Manager, Registry Solutions Mobile: +1 310 890 9655 donna.austin@team.neustar<mailto:donna.austin@team.neustar> / Website: home.neustar<http://www.home.neustar/> Follow Neustar: LinkedIn<http://www.linkedin.com/company/5349> / Twitter<http://www.twitter.com/neustar> Reduce your environmental footprint. Print only if necessary. ________________________________ The information contained in this email message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this email message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message. From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Thursday, October 17, 2019 6:59 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction 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<mailto: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:image002.jpg@01D58814.50B4D750] ________________________________ 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...>
From: Aikman-Scalese, Anne Sent: Monday, October 21, 2019 3:20 PM To: 'Austin, Donna' <Donna.Austin@team.neustar> Subject: RE: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction Thanks Donna. So I guess that means Objection time limit would not be triggered until the winner of the contention set is determined (either through private auction or through highest sealed bid) and then losing bidders may opt to stay in contention until the outcome of any Objection process against the winner. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Monday, October 21, 2019 3:07 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction [EXTERNAL] ________________________________ All Just to come back to my suggestion from Thursday. 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. That part of Jeff’s restatement of what I proposed is largely correct—the finer details to be worked out. This goes some way to overcoming Neustar’s concerns with the Vickery model that recommends submitting a sealed bid with the application. There is no way of knowing how many applications will be submitted next time around, which makes it difficult for potential applicants to assign a value to the string beyond what they’re paying to submit the application. If the applicant is made aware that they in a contention set for a string, then they have a little more information to work with in deciding a value and submitting a bid; however, the bid is only intended to be relevant in the event of an auction of last resort. ICANN would then process only the application that submitted the highest bid. This assumption is incorrect. Our recommendation is that the applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or chose another string as was suggested for ‘brands’ of the same name. Applicants would not know before reveal day who they are in contention with and would submit a bid absent that information, but they would become aware after the fact and should still have an opportunity to resolve the contention privately. It’s important to remember that a private auction only happens if all bidders agree to do s. I understand concerns about collusion and profiteering. I understand that what I’m suggesting may not overcome those concerns, but perhaps what we need in order to address those concerns is to have a policy statement that expressly prohibits collusion and profiting from the new gTLD. I don’t know how you enforce such a policy statement, but perhaps it would be enough to serve as a deterrent to this type of behavior. Donna Donna Austin Neustar, Inc. / Senior Policy Manager, Registry Solutions Mobile: +1 310 890 9655 donna.austin@team.neustar<mailto:donna.austin@team.neustar> / Website: home.neustar<http://www.home.neustar/> Follow Neustar: LinkedIn<http://www.linkedin.com/company/5349> / Twitter<http://www.twitter.com/neustar> Reduce your environmental footprint. Print only if necessary. ________________________________ The information contained in this email message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this email message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message. From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Thursday, October 17, 2019 6:59 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction 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<mailto: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@01D58823.0FBE4BA0] ________________________________ 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...> ________________________________ 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.
I would like to explore Donna’s suggestion a bit more. I think we could get comfortable with a concession for sealed bids for an ICANN auction of last resort that still allowed for good faith private resolution of contention sets. I want to re-iterate for the benefit of folks on the thread that (i) Private Resolutions need not always be a private auction (other forms of resolution like joint ventures are possible) and (ii) the only way a contention set gets to Private Resolution is if all members of the contention set agree. So, to Alexander’s earlier point, that points to a greater likelihood that contention sets will end up at the ICANN auction, particularly if parties know there won’t be a bidding war. I can’t speak definitively for Amazon on this point, but I believe we can and should discuss this concession a bit more to see if we can find some common ground. Thanks, Kristine From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Aikman-Scalese, Anne Sent: Monday, October 21, 2019 3:21 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction From: Aikman-Scalese, Anne Sent: Monday, October 21, 2019 3:20 PM To: 'Austin, Donna' <Donna.Austin@team.neustar<mailto:Donna.Austin@team.neustar>> Subject: RE: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction Thanks Donna. So I guess that means Objection time limit would not be triggered until the winner of the contention set is determined (either through private auction or through highest sealed bid) and then losing bidders may opt to stay in contention until the outcome of any Objection process against the winner. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Monday, October 21, 2019 3:07 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction [EXTERNAL] ________________________________ All Just to come back to my suggestion from Thursday. 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. That part of Jeff’s restatement of what I proposed is largely correct—the finer details to be worked out. This goes some way to overcoming Neustar’s concerns with the Vickery model that recommends submitting a sealed bid with the application. There is no way of knowing how many applications will be submitted next time around, which makes it difficult for potential applicants to assign a value to the string beyond what they’re paying to submit the application. If the applicant is made aware that they in a contention set for a string, then they have a little more information to work with in deciding a value and submitting a bid; however, the bid is only intended to be relevant in the event of an auction of last resort. ICANN would then process only the application that submitted the highest bid. This assumption is incorrect. Our recommendation is that the applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or chose another string as was suggested for ‘brands’ of the same name. Applicants would not know before reveal day who they are in contention with and would submit a bid absent that information, but they would become aware after the fact and should still have an opportunity to resolve the contention privately. It’s important to remember that a private auction only happens if all bidders agree to do s. I understand concerns about collusion and profiteering. I understand that what I’m suggesting may not overcome those concerns, but perhaps what we need in order to address those concerns is to have a policy statement that expressly prohibits collusion and profiting from the new gTLD. I don’t know how you enforce such a policy statement, but perhaps it would be enough to serve as a deterrent to this type of behavior. Donna Donna Austin Neustar, Inc. / Senior Policy Manager, Registry Solutions Mobile: +1 310 890 9655 donna.austin@team.neustar<mailto:donna.austin@team.neustar> / Website: home.neustar<http://www.home.neustar/> Follow Neustar: LinkedIn<http://www.linkedin.com/company/5349> / Twitter<http://www.twitter.com/neustar> Reduce your environmental footprint. Print only if necessary. ________________________________ The information contained in this email message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this email message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message. From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Thursday, October 17, 2019 6:59 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction 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<mailto: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@01D58827.091A0560] ________________________________ 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...> ________________________________ 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.
What is the problem we are trying to solve by the instantiation of a sealed-bid auction process? 1) Is it that we believed the prices paid in the ICANN (English-style) auctions were too high? 2) Is it to prevent the development of a secondary market where applicants join the process to gain in the spoils of private settlements? 3) Do we suspect there was collusion in the previous round and seek to avoid that in the next round? 4) Something else? We discussed, but I don’t think settled our policy goals in this area. My brief reading of economics papers (that I could fathom) is: 1) That sealed bid auctions and English (bidding) auctions have similar revenue results. 2) That whether a traditional sealed bid auction (where the winner pays the highest priced bid) and a Vickrey auction (where the winner pays the second highest price bid) is conducted depends on a variety of factors where the advice of a fairly sophisticated economist should be sought. 3) That collusion has occurred in all auction and contention-settlement formats. 4) That no where could I find a sealed bid auction was not close in time to the award. Cf., our situation, where the bids are to be submitted months or years prior to the award or where a set of evaluations and objections can change the status of the players and the value of the object. E.g., the reveal will markedly change the market value of the asset up for bid. It seems that having a sealed bid far in advance of the award and the uncertainties that will introduce will discourage new entrants into the field. I think one of our objectives is to encourage competition. There are other unforeseen consequences to a “far-in-advance” auction as indicated by the log list of issues created by Jeff. Our approach to contention resolution depends on our policy goals and sealed-bid auctions of some type might be part of that solution. However, I don’t think we should specify auction timing of the types that have been discussed without appropriate analysis - and maybe there is a more straightforward way to accomplish our policy goals. Last week, we discussed solutions, how they would be implemented, and their likely effects. Instead, we might first write down the desired effects (our policy goals) and then generate solutions, both simple and elaborate. I hope this is helpful. Kurt
On Oct 21, 2019, at 3:48 PM, Dorrain, Kristine via Gnso-newgtld-wg <gnso-newgtld-wg@icann.org> wrote:
I would like to explore Donna’s suggestion a bit more. I think we could get comfortable with a concession for sealed bids for an ICANN auction of last resort that still allowed for good faith private resolution of contention sets. I want to re-iterate for the benefit of folks on the thread that (i) Private Resolutions need not always be a private auction (other forms of resolution like joint ventures are possible) and (ii) the only way a contention set gets to Private Resolution is if all members of the contention set agree. So, to Alexander’s earlier point, that points to a greater likelihood that contention sets will end up at the ICANN auction, particularly if parties know there won’t be a bidding war.
I can’t speak definitively for Amazon on this point, but I believe we can and should discuss this concession a bit more to see if we can find some common ground.
Thanks,
Kristine
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Aikman-Scalese, Anne Sent: Monday, October 21, 2019 3:21 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
From: Aikman-Scalese, Anne Sent: Monday, October 21, 2019 3:20 PM To: 'Austin, Donna' <Donna.Austin@team.neustar <mailto:Donna.Austin@team.neustar>> Subject: RE: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
Thanks Donna. So I guess that means Objection time limit would not be triggered until the winner of the contention set is determined (either through private auction or through highest sealed bid) and then losing bidders may opt to stay in contention until the outcome of any Objection process against the winner.
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Monday, October 21, 2019 3:07 PM To: gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
[EXTERNAL] All
Just to come back to my suggestion from Thursday.
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.
That part of Jeff’s restatement of what I proposed is largely correct—the finer details to be worked out. This goes some way to overcoming Neustar’s concerns with the Vickery model that recommends submitting a sealed bid with the application. There is no way of knowing how many applications will be submitted next time around, which makes it difficult for potential applicants to assign a value to the string beyond what they’re paying to submit the application. If the applicant is made aware that they in a contention set for a string, then they have a little more information to work with in deciding a value and submitting a bid; however, the bid is only intended to be relevant in the event of an auction of last resort.
ICANN would then process only the application that submitted the highest bid.
This assumption is incorrect.
Our recommendation is that the applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or chose another string as was suggested for ‘brands’ of the same name. Applicants would not know before reveal day who they are in contention with and would submit a bid absent that information, but they would become aware after the fact and should still have an opportunity to resolve the contention privately. It’s important to remember that a private auction only happens if all bidders agree to do s.
I understand concerns about collusion and profiteering. I understand that what I’m suggesting may not overcome those concerns, but perhaps what we need in order to address those concerns is to have a policy statement that expressly prohibits collusion and profiting from the new gTLD. I don’t know how you enforce such a policy statement, but perhaps it would be enough to serve as a deterrent to this type of behavior.
Donna
Donna Austin Neustar, Inc. / Senior Policy Manager, Registry Solutions Mobile: +1 310 890 9655 donna.austin@team.neustar <mailto:donna.austin@team.neustar> / Website: home.neustar <http://www.home.neustar/>
Follow Neustar: LinkedIn <http://www.linkedin.com/company/5349> / Twitter <http://www.twitter.com/neustar> Reduce your environmental footprint. Print only if necessary. The information contained in this email message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this email message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>] On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Thursday, October 17, 2019 6:59 PM To: gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
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 <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 <mailto: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]:
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. 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]. 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. 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. 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. 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. 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. 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). 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. 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...>
<image001.jpg>
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...>
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. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I'm with Kurt at this point. I have not seen any real evidentiary impetus to change the status quo procedures from the last round. What is the problem we are trying to solve, and what evidence suggests it is a problem? Thanks, Mike Mike Rodenbaugh RODENBAUGH LAW tel/fax: +1.415.738.8087 http://rodenbaugh.law On Mon, Oct 21, 2019 at 7:10 PM Kurt Pritz <kurt@kjpritz.com> wrote:
What is the problem we are trying to solve by the instantiation of a sealed-bid auction process?
1) Is it that we believed the prices paid in the ICANN (English-style) auctions were too high?
2) Is it to prevent the development of a secondary market where applicants join the process to gain in the spoils of private settlements?
3) Do we suspect there was collusion in the previous round and seek to avoid that in the next round?
4) Something else?
We discussed, but I don’t think settled our policy goals in this area.
My brief reading of economics papers (that I could fathom) is:
1) That sealed bid auctions and English (bidding) auctions have similar revenue results.
2) That whether a traditional sealed bid auction (where the winner pays the highest priced bid) and a Vickrey auction (where the winner pays the second highest price bid) is conducted depends on a variety of factors where the advice of a fairly sophisticated economist should be sought.
3) That collusion has occurred in all auction and contention-settlement formats.
4) That no where could I find a sealed bid auction was not close in time to the award. Cf., our situation, where the bids are to be submitted months or years prior to the award or where a set of evaluations and objections can change the status of the players and the value of the object. E.g., the reveal will markedly change the market value of the asset up for bid.
It seems that having a sealed bid far in advance of the award and the uncertainties that will introduce will discourage new entrants into the field. I think one of our objectives is to encourage competition. There are other unforeseen consequences to a “far-in-advance” auction as indicated by the log list of issues created by Jeff.
Our approach to contention resolution depends on our policy goals and sealed-bid auctions of some type might be part of that solution. However, I don’t think we should specify auction timing of the types that have been discussed without appropriate analysis - and maybe there is a more straightforward way to accomplish our policy goals.
Last week, we discussed solutions, how they would be implemented, and their likely effects. Instead, we might first write down the desired effects (our policy goals) and then generate solutions, both simple and elaborate.
I hope this is helpful.
Kurt
On Oct 21, 2019, at 3:48 PM, Dorrain, Kristine via Gnso-newgtld-wg < gnso-newgtld-wg@icann.org> wrote:
I would like to explore Donna’s suggestion a bit more. I think we could get comfortable with a concession for sealed bids for an ICANN auction of last resort that still allowed for good faith private resolution of contention sets. I want to re-iterate for the benefit of folks on the thread that (i) Private Resolutions need not always be a private auction (other forms of resolution like joint ventures are possible) and (ii) the only way a contention set gets to Private Resolution is if all members of the contention set agree. So, to Alexander’s earlier point, that points to a greater likelihood that contention sets will end up at the ICANN auction, particularly if parties know there won’t be a bidding war.
I can’t speak definitively for Amazon on this point, but I believe we can and should discuss this concession a bit more to see if we can find some common ground.
Thanks,
Kristine
*From:* Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> *On Behalf Of *Aikman-Scalese, Anne *Sent:* Monday, October 21, 2019 3:21 PM *To:* gnso-newgtld-wg@icann.org *Subject:* [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
*From:* Aikman-Scalese, Anne *Sent:* Monday, October 21, 2019 3:20 PM *To:* 'Austin, Donna' <Donna.Austin@team.neustar> *Subject:* RE: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
Thanks Donna. So I guess that means Objection time limit would not be triggered until the winner of the contention set is determined (either through private auction or through highest sealed bid) and then losing bidders may opt to stay in contention until the outcome of any Objection process against the winner.
*From:* Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> *On Behalf Of *Austin, Donna via Gnso-newgtld-wg *Sent:* Monday, October 21, 2019 3:07 PM *To:* gnso-newgtld-wg@icann.org *Subject:* Re: [Gnso-newgtld-wg] Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
*[EXTERNAL]* ------------------------------ All
Just to come back to my suggestion from Thursday.
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.
That part of Jeff’s restatement of what I proposed is largely correct—the finer details to be worked out. This goes some way to overcoming Neustar’s concerns with the Vickery model that recommends submitting a sealed bid with the application. There is no way of knowing how many applications will be submitted next time around, which makes it difficult for potential applicants to assign a value to the string beyond what they’re paying to submit the application. If the applicant is made aware that they in a contention set for a string, then they have a little more information to work with in deciding a value and submitting a bid; however, the bid is only intended to be relevant in the event of an auction of last resort.
ICANN would then process only the application that submitted the highest bid.
This assumption is incorrect.
Our recommendation is that the applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or chose another string as was suggested for ‘brands’ of the same name. Applicants would not know before reveal day who they are in contention with and would submit a bid absent that information, but they would become aware after the fact and should still have an opportunity to resolve the contention privately. It’s important to remember that a private auction only happens if all bidders agree to do s.
I understand concerns about collusion and profiteering. I understand that what I’m suggesting may not overcome those concerns, but perhaps what we need in order to address those concerns is to have a policy statement that expressly prohibits collusion and profiting from the new gTLD. I don’t know how you enforce such a policy statement, but perhaps it would be enough to serve as a deterrent to this type of behavior.
Donna
*Donna Austin* *Neustar, Inc.* / Senior Policy Manager, Registry Solutions *Mobile:* +1 310 890 9655 *donna.austin@team.neustar <donna.austin@team.neustar>* / *Website:* home.neustar <http://www.home.neustar/>
*Follow Neustar:* LinkedIn <http://www.linkedin.com/company/5349> */* Twitter <http://www.twitter.com/neustar> Reduce your environmental footprint. Print only if necessary. ------------------------------ The information contained in this email message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this email message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.
*From:* Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org <gnso-newgtld-wg-bounces@icann.org>] *On Behalf Of *Austin, Donna via Gnso-newgtld-wg *Sent:* Thursday, October 17, 2019 6:59 PM *To:* gnso-newgtld-wg@icann.org *Subject:* [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
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 <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? 1. For exact matches and plural/singular (if that rule is adopted), it will be clear who is in a contention set. 2. But, what if String Similarity Evaluation determines that others should be in the Contention Set? 3. 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? 1. 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. 2. 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? 1. 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. 2. 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. 3. 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? 1. I think this would be treated similarly to the String Similarity Evaluation results. 2. 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? 1. 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? 1. 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. 2. 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 <jeff.neuman@comlaude.com>* www.comlaude.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.comlaude.com_&d=DwMG...>
<image001.jpg>
------------------------------ 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...>
------------------------------
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. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
+1 on that. Sent from my iPhone
On Oct 22, 2019, at 6:31 PM, Mike Rodenbaugh <mike@rodenbaugh.com> wrote:
I'm with Kurt at this point. I have not seen any real evidentiary impetus to change the status quo procedures from the last round. What is the problem we are trying to solve, and what evidence suggests it is a problem?
Thanks, Mike
Mike Rodenbaugh RODENBAUGH LAW tel/fax: +1.415.738.8087 http://rodenbaugh.law
On Mon, Oct 21, 2019 at 7:10 PM Kurt Pritz <kurt@kjpritz.com> wrote: What is the problem we are trying to solve by the instantiation of a sealed-bid auction process?
1) Is it that we believed the prices paid in the ICANN (English-style) auctions were too high?
2) Is it to prevent the development of a secondary market where applicants join the process to gain in the spoils of private settlements?
3) Do we suspect there was collusion in the previous round and seek to avoid that in the next round?
4) Something else?
We discussed, but I don’t think settled our policy goals in this area.
My brief reading of economics papers (that I could fathom) is:
1) That sealed bid auctions and English (bidding) auctions have similar revenue results.
2) That whether a traditional sealed bid auction (where the winner pays the highest priced bid) and a Vickrey auction (where the winner pays the second highest price bid) is conducted depends on a variety of factors where the advice of a fairly sophisticated economist should be sought.
3) That collusion has occurred in all auction and contention-settlement formats.
4) That no where could I find a sealed bid auction was not close in time to the award. Cf., our situation, where the bids are to be submitted months or years prior to the award or where a set of evaluations and objections can change the status of the players and the value of the object. E.g., the reveal will markedly change the market value of the asset up for bid.
It seems that having a sealed bid far in advance of the award and the uncertainties that will introduce will discourage new entrants into the field. I think one of our objectives is to encourage competition. There are other unforeseen consequences to a “far-in-advance” auction as indicated by the log list of issues created by Jeff.
Our approach to contention resolution depends on our policy goals and sealed-bid auctions of some type might be part of that solution. However, I don’t think we should specify auction timing of the types that have been discussed without appropriate analysis - and maybe there is a more straightforward way to accomplish our policy goals.
Last week, we discussed solutions, how they would be implemented, and their likely effects. Instead, we might first write down the desired effects (our policy goals) and then generate solutions, both simple and elaborate.
I hope this is helpful.
Kurt
On Oct 21, 2019, at 3:48 PM, Dorrain, Kristine via Gnso-newgtld-wg <gnso-newgtld-wg@icann.org> wrote:
I would like to explore Donna’s suggestion a bit more. I think we could get comfortable with a concession for sealed bids for an ICANN auction of last resort that still allowed for good faith private resolution of contention sets. I want to re-iterate for the benefit of folks on the thread that (i) Private Resolutions need not always be a private auction (other forms of resolution like joint ventures are possible) and (ii) the only way a contention set gets to Private Resolution is if all members of the contention set agree. So, to Alexander’s earlier point, that points to a greater likelihood that contention sets will end up at the ICANN auction, particularly if parties know there won’t be a bidding war.
I can’t speak definitively for Amazon on this point, but I believe we can and should discuss this concession a bit more to see if we can find some common ground.
Thanks,
Kristine
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Aikman-Scalese, Anne Sent: Monday, October 21, 2019 3:21 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
From: Aikman-Scalese, Anne Sent: Monday, October 21, 2019 3:20 PM To: 'Austin, Donna' <Donna.Austin@team.neustar> Subject: RE: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
Thanks Donna. So I guess that means Objection time limit would not be triggered until the winner of the contention set is determined (either through private auction or through highest sealed bid) and then losing bidders may opt to stay in contention until the outcome of any Objection process against the winner.
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Monday, October 21, 2019 3:07 PM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
[EXTERNAL] All
Just to come back to my suggestion from Thursday.
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.
That part of Jeff’s restatement of what I proposed is largely correct—the finer details to be worked out. This goes some way to overcoming Neustar’s concerns with the Vickery model that recommends submitting a sealed bid with the application. There is no way of knowing how many applications will be submitted next time around, which makes it difficult for potential applicants to assign a value to the string beyond what they’re paying to submit the application. If the applicant is made aware that they in a contention set for a string, then they have a little more information to work with in deciding a value and submitting a bid; however, the bid is only intended to be relevant in the event of an auction of last resort.
ICANN would then process only the application that submitted the highest bid.
This assumption is incorrect.
Our recommendation is that the applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or chose another string as was suggested for ‘brands’ of the same name. Applicants would not know before reveal day who they are in contention with and would submit a bid absent that information, but they would become aware after the fact and should still have an opportunity to resolve the contention privately. It’s important to remember that a private auction only happens if all bidders agree to do s.
I understand concerns about collusion and profiteering. I understand that what I’m suggesting may not overcome those concerns, but perhaps what we need in order to address those concerns is to have a policy statement that expressly prohibits collusion and profiting from the new gTLD. I don’t know how you enforce such a policy statement, but perhaps it would be enough to serve as a deterrent to this type of behavior.
Donna
Donna Austin Neustar, Inc. / Senior Policy Manager, Registry Solutions Mobile: +1 310 890 9655 donna.austin@team.neustar / Website: home.neustar
Follow Neustar: LinkedIn / Twitter Reduce your environmental footprint. Print only if necessary. The information contained in this email message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this email message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Thursday, October 17, 2019 6:59 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
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]:
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. 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]. 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. 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. 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. 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. 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. 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). 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. 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 www.comlaude.com
<image001.jpg>
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
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. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
+2 Marc H. Trachtenberg Shareholder Greenberg Traurig, LLP 77 West Wacker Drive | Suite 3100 | Chicago, IL 60601 T +1 312.456.1020 trac@gtlaw.com<mailto:trachtenbergm@gtlaw.com> | www.gtlaw.com<http://www.gtlaw.com/> | View GT Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h> [Greenberg Traurig] From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Peter LaMantia Sent: Tuesday, October 22, 2019 5:48 PM To: Mike Rodenbaugh <mike@rodenbaugh.com> Cc: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction *EXTERNAL TO GT* +1 on that. Sent from my iPhone On Oct 22, 2019, at 6:31 PM, Mike Rodenbaugh <mike@rodenbaugh.com<mailto:mike@rodenbaugh.com>> wrote: I'm with Kurt at this point. I have not seen any real evidentiary impetus to change the status quo procedures from the last round. What is the problem we are trying to solve, and what evidence suggests it is a problem? Thanks, Mike Mike Rodenbaugh RODENBAUGH LAW tel/fax: +1.415.738.8087 https://urldefense.proofpoint.com/v2/url?u=http-3A__rodenbaugh.law&d=DwIGaQ&... <https://urldefense.proofpoint.com/v2/url?u=http-3A__rodenbaugh.law&d=DwMFaQ&...> On Mon, Oct 21, 2019 at 7:10 PM Kurt Pritz <kurt@kjpritz.com<mailto:kurt@kjpritz.com>> wrote: What is the problem we are trying to solve by the instantiation of a sealed-bid auction process? 1) Is it that we believed the prices paid in the ICANN (English-style) auctions were too high? 2) Is it to prevent the development of a secondary market where applicants join the process to gain in the spoils of private settlements? 3) Do we suspect there was collusion in the previous round and seek to avoid that in the next round? 4) Something else? We discussed, but I don’t think settled our policy goals in this area. My brief reading of economics papers (that I could fathom) is: 1) That sealed bid auctions and English (bidding) auctions have similar revenue results. 2) That whether a traditional sealed bid auction (where the winner pays the highest priced bid) and a Vickrey auction (where the winner pays the second highest price bid) is conducted depends on a variety of factors where the advice of a fairly sophisticated economist should be sought. 3) That collusion has occurred in all auction and contention-settlement formats. 4) That no where could I find a sealed bid auction was not close in time to the award. Cf., our situation, where the bids are to be submitted months or years prior to the award or where a set of evaluations and objections can change the status of the players and the value of the object. E.g., the reveal will markedly change the market value of the asset up for bid. It seems that having a sealed bid far in advance of the award and the uncertainties that will introduce will discourage new entrants into the field. I think one of our objectives is to encourage competition. There are other unforeseen consequences to a “far-in-advance” auction as indicated by the log list of issues created by Jeff. Our approach to contention resolution depends on our policy goals and sealed-bid auctions of some type might be part of that solution. However, I don’t think we should specify auction timing of the types that have been discussed without appropriate analysis - and maybe there is a more straightforward way to accomplish our policy goals. Last week, we discussed solutions, how they would be implemented, and their likely effects. Instead, we might first write down the desired effects (our policy goals) and then generate solutions, both simple and elaborate. I hope this is helpful. Kurt On Oct 21, 2019, at 3:48 PM, Dorrain, Kristine via Gnso-newgtld-wg <gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org>> wrote: I would like to explore Donna’s suggestion a bit more. I think we could get comfortable with a concession for sealed bids for an ICANN auction of last resort that still allowed for good faith private resolution of contention sets. I want to re-iterate for the benefit of folks on the thread that (i) Private Resolutions need not always be a private auction (other forms of resolution like joint ventures are possible) and (ii) the only way a contention set gets to Private Resolution is if all members of the contention set agree. So, to Alexander’s earlier point, that points to a greater likelihood that contention sets will end up at the ICANN auction, particularly if parties know there won’t be a bidding war. I can’t speak definitively for Amazon on this point, but I believe we can and should discuss this concession a bit more to see if we can find some common ground. Thanks, Kristine From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Aikman-Scalese, Anne Sent: Monday, October 21, 2019 3:21 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction From: Aikman-Scalese, Anne Sent: Monday, October 21, 2019 3:20 PM To: 'Austin, Donna' <Donna.Austin@team.neustar<mailto:Donna.Austin@team.neustar>> Subject: RE: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction Thanks Donna. So I guess that means Objection time limit would not be triggered until the winner of the contention set is determined (either through private auction or through highest sealed bid) and then losing bidders may opt to stay in contention until the outcome of any Objection process against the winner. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Monday, October 21, 2019 3:07 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction [EXTERNAL] ________________________________ All Just to come back to my suggestion from Thursday. 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. That part of Jeff’s restatement of what I proposed is largely correct—the finer details to be worked out. This goes some way to overcoming Neustar’s concerns with the Vickery model that recommends submitting a sealed bid with the application. There is no way of knowing how many applications will be submitted next time around, which makes it difficult for potential applicants to assign a value to the string beyond what they’re paying to submit the application. If the applicant is made aware that they in a contention set for a string, then they have a little more information to work with in deciding a value and submitting a bid; however, the bid is only intended to be relevant in the event of an auction of last resort. ICANN would then process only the application that submitted the highest bid. This assumption is incorrect. Our recommendation is that the applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or chose another string as was suggested for ‘brands’ of the same name. Applicants would not know before reveal day who they are in contention with and would submit a bid absent that information, but they would become aware after the fact and should still have an opportunity to resolve the contention privately. It’s important to remember that a private auction only happens if all bidders agree to do s. I understand concerns about collusion and profiteering. I understand that what I’m suggesting may not overcome those concerns, but perhaps what we need in order to address those concerns is to have a policy statement that expressly prohibits collusion and profiting from the new gTLD. I don’t know how you enforce such a policy statement, but perhaps it would be enough to serve as a deterrent to this type of behavior. Donna Donna Austin Neustar, Inc. / Senior Policy Manager, Registry Solutions Mobile: +1 310 890 9655 donna.austin@team.neustar<mailto:donna.austin@team.neustar> / Website: home.neustar<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.home.neustar_&d=DwMF...> Follow Neustar: LinkedIn<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_company...> / Twitter<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_neustar&...> Reduce your environmental footprint. Print only if necessary. ________________________________ The information contained in this email message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this email message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message. From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Austin, Donna via Gnso-newgtld-wg Sent: Thursday, October 17, 2019 6:59 PM To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction 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<mailto: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. 1. 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. 1. 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). 1. 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. 1. 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...> <image001.jpg> ________________________________ 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...> ________________________________ 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. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org<mailto:Gnso-newgtld-wg@icann.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li... <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p... <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org<mailto:Gnso-newgtld-wg@icann.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li... <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p... <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org<mailto:Gnso-newgtld-wg@icann.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li... <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p... <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. ---------------------------------------------------------------------- If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@gtlaw.com, and do not use or disseminate the information.
In answer to Jeff's original email - I agree largely with Donna's and Kristine's comments, and look forward to some fine-tuning in respect of objections and appeals after a bit more thought. In answer to Kurt's comments, policy goals to aim for in my book: 1. Allowing private contention set resolution but strongly discouraging, if not prohibiting or preventing, collusion and profiting through withdrawing from a contention set - ban on private auctions 2. Moving to Vickrey auction, instead of regular bidding auction, to make applicants put a (fixed) value on the string being applied for 3. Leveling the playing field somewhat with a multiplier on bids for applicants which qualify for Applicant Support in the event of an ICANN-endorsed auction as the mechanism of last resort to resolve contention set Justine ----- On Wed, 23 Oct 2019 at 15:20, Marc Trachtenberg via Gnso-newgtld-wg < gnso-newgtld-wg@icann.org> wrote:
+2
*Marc H. Trachtenberg * Shareholder Greenberg Traurig, LLP 77 West Wacker Drive | Suite 3100 | Chicago, IL 60601 T +1 312.456.1020 trac@gtlaw.com <trachtenbergm@gtlaw.com> | www.gtlaw.com | View GT Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h>
[image: Greenberg Traurig]
*From:* Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] *On Behalf Of *Peter LaMantia *Sent:* Tuesday, October 22, 2019 5:48 PM *To:* Mike Rodenbaugh <mike@rodenbaugh.com> *Cc:* gnso-newgtld-wg@icann.org *Subject:* Re: [Gnso-newgtld-wg] Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
**EXTERNAL TO GT**
+1 on that.
Sent from my iPhone
On Oct 22, 2019, at 6:31 PM, Mike Rodenbaugh <mike@rodenbaugh.com> wrote:
I'm with Kurt at this point. I have not seen any real evidentiary impetus to change the status quo procedures from the last round. What is the problem we are trying to solve, and what evidence suggests it is a problem?
Thanks,
Mike
Mike Rodenbaugh
RODENBAUGH LAW
tel/fax: +1.415.738.8087
http://rodenbaugh.law <https://urldefense.proofpoint.com/v2/url?u=http-3A__rodenbaugh.law&d=DwMFaQ&...>
On Mon, Oct 21, 2019 at 7:10 PM Kurt Pritz <kurt@kjpritz.com> wrote:
What is the problem we are trying to solve by the instantiation of a sealed-bid auction process?
1) Is it that we believed the prices paid in the ICANN (English-style) auctions were too high?
2) Is it to prevent the development of a secondary market where applicants join the process to gain in the spoils of private settlements?
3) Do we suspect there was collusion in the previous round and seek to avoid that in the next round?
4) Something else?
We discussed, but I don’t think settled our policy goals in this area.
My brief reading of economics papers (that I could fathom) is:
1) That sealed bid auctions and English (bidding) auctions have similar revenue results.
2) That whether a traditional sealed bid auction (where the winner pays the highest priced bid) and a Vickrey auction (where the winner pays the second highest price bid) is conducted depends on a variety of factors where the advice of a fairly sophisticated economist should be sought.
3) That collusion has occurred in all auction and contention-settlement formats.
4) That no where could I find a sealed bid auction was not close in time to the award. Cf., our situation, where the bids are to be submitted months or years prior to the award or where a set of evaluations and objections can change the status of the players and the value of the object. E.g., the reveal will markedly change the market value of the asset up for bid.
It seems that having a sealed bid far in advance of the award and the uncertainties that will introduce will discourage new entrants into the field. I think one of our objectives is to encourage competition. There are other unforeseen consequences to a “far-in-advance” auction as indicated by the log list of issues created by Jeff.
Our approach to contention resolution depends on our policy goals and sealed-bid auctions of some type might be part of that solution. However, I don’t think we should specify auction timing of the types that have been discussed without appropriate analysis - and maybe there is a more straightforward way to accomplish our policy goals.
Last week, we discussed solutions, how they would be implemented, and their likely effects. Instead, we might first write down the desired effects (our policy goals) and then generate solutions, both simple and elaborate.
I hope this is helpful.
Kurt
On Oct 21, 2019, at 3:48 PM, Dorrain, Kristine via Gnso-newgtld-wg < gnso-newgtld-wg@icann.org> wrote:
I would like to explore Donna’s suggestion a bit more. I think we could get comfortable with a concession for sealed bids for an ICANN auction of last resort that still allowed for good faith private resolution of contention sets. I want to re-iterate for the benefit of folks on the thread that (i) Private Resolutions need not always be a private auction (other forms of resolution like joint ventures are possible) and (ii) the only way a contention set gets to Private Resolution is if all members of the contention set agree. So, to Alexander’s earlier point, that points to a greater likelihood that contention sets will end up at the ICANN auction, particularly if parties know there won’t be a bidding war.
I can’t speak definitively for Amazon on this point, but I believe we can and should discuss this concession a bit more to see if we can find some common ground.
Thanks,
Kristine
*From:* Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> *On Behalf Of *Aikman-Scalese, Anne *Sent:* Monday, October 21, 2019 3:21 PM *To:* gnso-newgtld-wg@icann.org *Subject:* [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
*From:* Aikman-Scalese, Anne *Sent:* Monday, October 21, 2019 3:20 PM *To:* 'Austin, Donna' <Donna.Austin@team.neustar> *Subject:* RE: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
Thanks Donna. So I guess that means Objection time limit would not be triggered until the winner of the contention set is determined (either through private auction or through highest sealed bid) and then losing bidders may opt to stay in contention until the outcome of any Objection process against the winner.
*From:* Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> *On Behalf Of *Austin, Donna via Gnso-newgtld-wg *Sent:* Monday, October 21, 2019 3:07 PM *To:* gnso-newgtld-wg@icann.org *Subject:* Re: [Gnso-newgtld-wg] Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
*[EXTERNAL]* ------------------------------
All
Just to come back to my suggestion from Thursday.
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.
That part of Jeff’s restatement of what I proposed is largely correct—the finer details to be worked out. This goes some way to overcoming Neustar’s concerns with the Vickery model that recommends submitting a sealed bid with the application. There is no way of knowing how many applications will be submitted next time around, which makes it difficult for potential applicants to assign a value to the string beyond what they’re paying to submit the application. If the applicant is made aware that they in a contention set for a string, then they have a little more information to work with in deciding a value and submitting a bid; however, the bid is only intended to be relevant in the event of an auction of last resort.
ICANN would then process only the application that submitted the highest bid.
This assumption is incorrect.
Our recommendation is that the applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or chose another string as was suggested for ‘brands’ of the same name. Applicants would not know before reveal day who they are in contention with and would submit a bid absent that information, but they would become aware after the fact and should still have an opportunity to resolve the contention privately. It’s important to remember that a private auction only happens if all bidders agree to do s.
I understand concerns about collusion and profiteering. I understand that what I’m suggesting may not overcome those concerns, but perhaps what we need in order to address those concerns is to have a policy statement that expressly prohibits collusion and profiting from the new gTLD. I don’t know how you enforce such a policy statement, but perhaps it would be enough to serve as a deterrent to this type of behavior.
Donna
*Donna Austin* *Neustar, Inc.* / Senior Policy Manager, Registry Solutions *Mobile:* +1 310 890 9655 *donna.austin@team.neustar <donna.austin@team.neustar>* / *Website:* home.neustar <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.home.neustar_&d=DwMF...>
*Follow Neustar:* LinkedIn <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_company...> */* Twitter <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.twitter.com_neustar&...> Reduce your environmental footprint. Print only if necessary. ------------------------------
The information contained in this email message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this email message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.
*From:* Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org <gnso-newgtld-wg-bounces@icann.org>] *On Behalf Of *Austin, Donna via Gnso-newgtld-wg *Sent:* Thursday, October 17, 2019 6:59 PM *To:* gnso-newgtld-wg@icann.org *Subject:* [Gnso-newgtld-wg] FW: Donna Austin Proposal and Paul McGrady Question re: Sealed Bid Auction
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 <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?
1. For exact matches and plural/singular (if that rule is adopted), it will be clear who is in a contention set. 2. But, what if String Similarity Evaluation determines that others should be in the Contention Set? 3. 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?
1. 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. 2. 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.
1. Is #5 above the same if there are one or more Community Applications?
1. 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. 2. 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. 3. Then, the objections (if any) on the non-Community Applications would only be heard *if* the Community Applications do not pass CPE.
1. What if a String Confusion Objection results in the creation of a new contention set or adds to an existing contention set?
1. I think this would be treated similarly to the String Similarity Evaluation results. 2. 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).
1. How do Appeals/Accountability Mechanisms work with this?
1. 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.
1. How does the Applicant Support Program figure into this?
1. 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. 2. 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 <jeff.neuman@comlaude.com>* www.comlaude.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.comlaude.com_&d=DwMG...>
<image001.jpg>
------------------------------
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...>
------------------------------
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.
_______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
------------------------------ If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@gtlaw.com, and do not use or disseminate the information. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (10)
-
Aikman-Scalese, Anne -
Alexander Schubert -
Austin, Donna -
Dorrain, Kristine -
Jeff Neuman -
Justine Chew -
Kurt Pritz -
Mike Rodenbaugh -
Peter LaMantia -
trachtenbergm＠gtlaw.com