Additional thoughts on Proposal 5
Apologies in advance. I will not be able to join the call later today as I am cohosting a workshop at RightsCon at the same time. I will review the notes and recording and respond on list as necessary. As Jeff noted during the last call, this is complicated because we are now allowing the resolution of contention sets in ways that were not allowed in the 2012 round. A very simple, clean way to settle contention sets without these measures is to have them all go to an ICANN auction of last resort or a random draw. But some people insist that losers should get paid so those are off the table. I also believe that we have to address BOTH Board concerns - Board Concern #1 - applications submitted for the sole purpose of receiving a payout for losing private auctions We have made good progress in addressing #1 and I think we can get there with some tweaks. Transparency requirements are good but they should not be rolled back for the creation of JVs. Not suggesting trade secrets be divulged but we should know who the operator of the JV is and we should also know the circumstances around what caused members of the contention set who are not part of the JV to drop out. I also believe that the Bona Fide proffers should be reviewed and enforced by ICANN, not just the outside evaluators. Rationale is that at some point, the evaluators will disappear. They are temporary help. ICANN has the ultimate responsibility to administer this program so they should be the ones reviewing theses Bona Fide requirements. And along these lines - ICANN should oversee all auctions, not just the Auction of Last resort. As currently constructed in Paul's edit - there are too many steps for revealing the results of private auctions. With ICANN overseeing this, it's a much cleaner process. ICANN involvement also adds a level of assurance that these auctions are being conducted in an aboveboard manner. As far as penalties for violations of the Bona Fide requirements - loss of registry has to be there. That is a major deterrent and should not be cast aside. Board Concern #2 - gaming for the purposes of financing other applications. The base Proposal 5 does nothing to address Concern #2. Donna stated that she's "not convinced that means we have to address it." I couldn't disagree more. If we fail to address this now, there is a strong likely hood that the Board will either 1) come back to us and ask us to develop a plan (slowing things down again) or 2) develop a solution themselves. Neither is an ideal outcome so we have to do something to stop the gaming for purposes of financing other applications. I and others believe that the Bona Fide requirements do not go far enough here. Others believe my sealed bid requirement goes too far. So what are alternative solutions that are enforceable and prevent this type of activity? Auction proceeds held in escrow? All auction conducted at once? Timing on when these auctions happen is the key to stop this gaming and that is why I proposed the submission of all bids upfront. With bids upfront, auctions could be conducted whenever but there is a constraint on the ability to roll funds over and over. ICANN's right to refer to competition authority. We never got around to discussing why Paul felt the need to delete this section completely and since the call there was a brief discussion on list about whether ICANN has this as an inherent right or whether it should be spelled out. My proposal was based upon the RSEP process which is already in force of all registry operators and will be required for all future operators. It specifically calls out competition authority referral if ICANN makes a determination such referral is necessary. I was surprised how representatives of contracted parties reacted so negatively to that since it is in existing registry agreements. My rationale for including this provision and calling it out specifically is simple - if a JV or other form of private resolution raises competition concerns for ICANN, they should have the right to refer it to relevant competition authorities to ensure they are ok with it. This protects ICANN the institution from charges that it is fostering anticompetitive behavior. Jim Prendergast The Galway Strategy Group +1 202-285-3699
Jim, I agree with you. And essentially "Board Concern #1" and "Board Concern #2" are identical: The board is concerned that applicants are trying to facilitate financial gain by strategically losing private auctions. For whatever reason: * either just to bath in cash * or to finance other applications and in the end it doesn't matter. It's one and the same concern. It is however still beneficial to factor them in separately as the countermeasure to Concern #2 can be easily mitigated by having all auctions for clear cut cases (no objections, etc) all at once. Don't forget: "sealed bid auctions" are now essentially just "reveals" - all of them can be facilitated in a millisecond; whereas in the past we had to create auction slots and auctions were time and resource consuming. The only real difference between Board Concerns #1 and #2 is (as you indicate) "timing". 1. Applicants apply for their strings. 2. After the application window closes those who face contention resolution are requested to submit a sealed bid (the only information they have at this point is that they face some kind of contention - which could be identical or similar strings. They don't know how many contention set members or their identity or string names). 3. That bid is valid for both auction types: the one where proceeds are shared among losers - and the one where losers won't benefit (formerly: "auction of last resort"). o The latter one is very important, as applicants may announce upfront that they will not allow losers to financially benefit (this deters fortune seekers). o Example: dotAIRPORT, LLC will make it crystal clear, that it won't participate in any scheme where auction proceeds are distributed to losers. o In fact we could have applicants OPT OUT of the private auction right in the application - then contention set members would be informed that one member opted out of auction fee distribution: the affected applicants could quickly withdraw their application to maximize their application fee refunds (overall loss); as they are now facing a mandatory ICANN auction of last resort. 4. Auction deposits are due a few days before auction reveal (regardless how auction proceeds are distributed). 5. Failure to pay the winning bid (2nd highest) results in losing the deposit and any potential application fee refund. Thanks, Alexander From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jim Prendergast Sent: Montag, 27. Juli 2020 14:28 To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Additional thoughts on Proposal 5 Apologies in advance. I will not be able to join the call later today as I am cohosting a workshop at RightsCon at the same time. I will review the notes and recording and respond on list as necessary. As Jeff noted during the last call, this is complicated because we are now allowing the resolution of contention sets in ways that were not allowed in the 2012 round. A very simple, clean way to settle contention sets without these measures is to have them all go to an ICANN auction of last resort or a random draw. But some people insist that losers should get paid so those are off the table. I also believe that we have to address BOTH Board concerns - Board Concern #1 - applications submitted for the sole purpose of receiving a payout for losing private auctions We have made good progress in addressing #1 and I think we can get there with some tweaks. Transparency requirements are good but they should not be rolled back for the creation of JVs. Not suggesting trade secrets be divulged but we should know who the operator of the JV is and we should also know the circumstances around what caused members of the contention set who are not part of the JV to drop out. I also believe that the Bona Fide proffers should be reviewed and enforced by ICANN, not just the outside evaluators. Rationale is that at some point, the evaluators will disappear. They are temporary help. ICANN has the ultimate responsibility to administer this program so they should be the ones reviewing theses Bona Fide requirements. And along these lines - ICANN should oversee all auctions, not just the Auction of Last resort. As currently constructed in Paul's edit - there are too many steps for revealing the results of private auctions. With ICANN overseeing this, it's a much cleaner process. ICANN involvement also adds a level of assurance that these auctions are being conducted in an aboveboard manner. As far as penalties for violations of the Bona Fide requirements - loss of registry has to be there. That is a major deterrent and should not be cast aside. Board Concern #2 - gaming for the purposes of financing other applications. The base Proposal 5 does nothing to address Concern #2. Donna stated that she's "not convinced that means we have to address it." I couldn't disagree more. If we fail to address this now, there is a strong likely hood that the Board will either 1) come back to us and ask us to develop a plan (slowing things down again) or 2) develop a solution themselves. Neither is an ideal outcome so we have to do something to stop the gaming for purposes of financing other applications. I and others believe that the Bona Fide requirements do not go far enough here. Others believe my sealed bid requirement goes too far. So what are alternative solutions that are enforceable and prevent this type of activity? Auction proceeds held in escrow? All auction conducted at once? Timing on when these auctions happen is the key to stop this gaming and that is why I proposed the submission of all bids upfront. With bids upfront, auctions could be conducted whenever but there is a constraint on the ability to roll funds over and over. ICANN's right to refer to competition authority. We never got around to discussing why Paul felt the need to delete this section completely and since the call there was a brief discussion on list about whether ICANN has this as an inherent right or whether it should be spelled out. My proposal was based upon the RSEP process which is already in force of all registry operators and will be required for all future operators. It specifically calls out competition authority referral if ICANN makes a determination such referral is necessary. I was surprised how representatives of contracted parties reacted so negatively to that since it is in existing registry agreements. My rationale for including this provision and calling it out specifically is simple - if a JV or other form of private resolution raises competition concerns for ICANN, they should have the right to refer it to relevant competition authorities to ensure they are ok with it. This protects ICANN the institution from charges that it is fostering anticompetitive behavior. Jim Prendergast The Galway Strategy Group +1 202-285-3699
Re Board concerns #1 and 2 I am ok with Alex's proposal. With respect to the Bona Fides, I don't think these will be effective as they rely on assumptions and judgment calls. I think that generally we should avoid solutions/mechanisms that require ICANN to make judgement calls as we have seen in the past that this has often not turned out well and will almost certainly result in disputes which junk up and delay the process. Jim mentions protection of ICANN the institution in his comments on the ability of ICANN to refer to competition authorities. First, I do not think that protecting ICANN org is within the remit of, or should be a concern for this group and that ICANN can clearly take care of itself, but if this was a concern then we are doing ICANN no favors by having them decide Bon Fides and are doing no one else any favors to create a whole new process or panels to decide this. This doesn't even get into the issue of what to do if you don't meet the Bona Fides test which is a whole separate can of worms. Re ICANN's ability to refer to competition authorities why are we still wasting time on this? Adding in a provision has no effect on ICANN's (or anyone else's) ability to refer applications to competition authorities which they can do at any time. Also, why would we even want ICANN to do this? What expertise does ICANN have to make this call and why would ICANN want to jump on the grenade and do this? Finally, as I mentioned above, protecting ICANN org is not a concern of this group, but if it was, I fail to see how including a right for ICANN to refer applications to relevant competition authorities provides any legal protection whatsoever to ICANN org from charges that it is fostering anticompetitive behavior. Marc H. Trachtenberg Shareholder Greenberg Traurig, LLP | 77 West Wacker Drive | Suite 3100 | Chicago, IL 60601 Tel 312.456.1020 Mobile 773.677.3305 trac@gtlaw.com<mailto:trac@gtlaw.com> | www.gtlaw.com<http://www.gtlaw.com/> [Greenberg Traurig] From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Alexander Schubert Sent: Monday, July 27, 2020 8:14 AM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Additional thoughts on Proposal 5 *EXTERNAL TO GT* Jim, I agree with you. And essentially "Board Concern #1" and "Board Concern #2" are identical: The board is concerned that applicants are trying to facilitate financial gain by strategically losing private auctions. For whatever reason: * either just to bath in cash * or to finance other applications and in the end it doesn't matter. It's one and the same concern. It is however still beneficial to factor them in separately as the countermeasure to Concern #2 can be easily mitigated by having all auctions for clear cut cases (no objections, etc) all at once. Don't forget: "sealed bid auctions" are now essentially just "reveals" - all of them can be facilitated in a millisecond; whereas in the past we had to create auction slots and auctions were time and resource consuming. The only real difference between Board Concerns #1 and #2 is (as you indicate) "timing". 1. Applicants apply for their strings. 2. After the application window closes those who face contention resolution are requested to submit a sealed bid (the only information they have at this point is that they face some kind of contention - which could be identical or similar strings. They don't know how many contention set members or their identity or string names). 3. That bid is valid for both auction types: the one where proceeds are shared among losers - and the one where losers won't benefit (formerly: "auction of last resort"). * The latter one is very important, as applicants may announce upfront that they will not allow losers to financially benefit (this deters fortune seekers). * Example: dotAIRPORT, LLC will make it crystal clear, that it won't participate in any scheme where auction proceeds are distributed to losers. * In fact we could have applicants OPT OUT of the private auction right in the application - then contention set members would be informed that one member opted out of auction fee distribution: the affected applicants could quickly withdraw their application to maximize their application fee refunds (overall loss); as they are now facing a mandatory ICANN auction of last resort. 4. Auction deposits are due a few days before auction reveal (regardless how auction proceeds are distributed). 5. Failure to pay the winning bid (2nd highest) results in losing the deposit and any potential application fee refund. Thanks, Alexander From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jim Prendergast Sent: Montag, 27. Juli 2020 14:28 To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Additional thoughts on Proposal 5 Apologies in advance. I will not be able to join the call later today as I am cohosting a workshop at RightsCon at the same time. I will review the notes and recording and respond on list as necessary. As Jeff noted during the last call, this is complicated because we are now allowing the resolution of contention sets in ways that were not allowed in the 2012 round. A very simple, clean way to settle contention sets without these measures is to have them all go to an ICANN auction of last resort or a random draw. But some people insist that losers should get paid so those are off the table. I also believe that we have to address BOTH Board concerns - Board Concern #1 - applications submitted for the sole purpose of receiving a payout for losing private auctions We have made good progress in addressing #1 and I think we can get there with some tweaks. Transparency requirements are good but they should not be rolled back for the creation of JVs. Not suggesting trade secrets be divulged but we should know who the operator of the JV is and we should also know the circumstances around what caused members of the contention set who are not part of the JV to drop out. I also believe that the Bona Fide proffers should be reviewed and enforced by ICANN, not just the outside evaluators. Rationale is that at some point, the evaluators will disappear. They are temporary help. ICANN has the ultimate responsibility to administer this program so they should be the ones reviewing theses Bona Fide requirements. And along these lines - ICANN should oversee all auctions, not just the Auction of Last resort. As currently constructed in Paul's edit - there are too many steps for revealing the results of private auctions. With ICANN overseeing this, it's a much cleaner process. ICANN involvement also adds a level of assurance that these auctions are being conducted in an aboveboard manner. As far as penalties for violations of the Bona Fide requirements - loss of registry has to be there. That is a major deterrent and should not be cast aside. Board Concern #2 - gaming for the purposes of financing other applications. The base Proposal 5 does nothing to address Concern #2. Donna stated that she's "not convinced that means we have to address it." I couldn't disagree more. If we fail to address this now, there is a strong likely hood that the Board will either 1) come back to us and ask us to develop a plan (slowing things down again) or 2) develop a solution themselves. Neither is an ideal outcome so we have to do something to stop the gaming for purposes of financing other applications. I and others believe that the Bona Fide requirements do not go far enough here. Others believe my sealed bid requirement goes too far. So what are alternative solutions that are enforceable and prevent this type of activity? Auction proceeds held in escrow? All auction conducted at once? Timing on when these auctions happen is the key to stop this gaming and that is why I proposed the submission of all bids upfront. With bids upfront, auctions could be conducted whenever but there is a constraint on the ability to roll funds over and over. ICANN's right to refer to competition authority. We never got around to discussing why Paul felt the need to delete this section completely and since the call there was a brief discussion on list about whether ICANN has this as an inherent right or whether it should be spelled out. My proposal was based upon the RSEP process which is already in force of all registry operators and will be required for all future operators. It specifically calls out competition authority referral if ICANN makes a determination such referral is necessary. I was surprised how representatives of contracted parties reacted so negatively to that since it is in existing registry agreements. My rationale for including this provision and calling it out specifically is simple - if a JV or other form of private resolution raises competition concerns for ICANN, they should have the right to refer it to relevant competition authorities to ensure they are ok with it. This protects ICANN the institution from charges that it is fostering anticompetitive behavior. Jim Prendergast The Galway Strategy Group +1 202-285-3699 ---------------------------------------------------------------------- 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.
Thanks Alexander, As I mentioned in my reply to Jim and as we have discussed many times already on many calls, the “all bids up front” model doesn’t work for private auctions. It doesn’t work, frankly, for ICANN Last Resort auctions. Applicants simply cannot know the bid amount it should make until all public comments, GAC Early warnings, objections, etc. are over. We can’t deconstruct the entire New gTLD program to solve a problem that only a fraction of the WG even think is a problem. Best, Paul To receive regular COVID-19 updates from Taft, subscribe here<https://www.taftlaw.com/general/subscribe>. For additional resources, visit Taft's COVID-19 Resource Toolkit<https://www.taftlaw.com/general/coronavirus-covid-19-resource-toolkit>. This message may contain information that is attorney-client privileged, attorney work product or otherwise confidential. If you are not an intended recipient, use and disclosure of this message are prohibited. If you received this transmission in error, please notify the sender by reply e-mail and delete the message and any attachments. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Alexander Schubert Sent: Monday, July 27, 2020 8:14 AM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Additional thoughts on Proposal 5 Jim, I agree with you. And essentially “Board Concern #1” and “Board Concern #2” are identical: The board is concerned that applicants are trying to facilitate financial gain by strategically losing private auctions. For whatever reason: · either just to bath in cash · or to finance other applications and in the end it doesn’t matter. It’s one and the same concern. It is however still beneficial to factor them in separately as the countermeasure to Concern #2 can be easily mitigated by having all auctions for clear cut cases (no objections, etc) all at once. Don’t forget: “sealed bid auctions” are now essentially just “reveals” – all of them can be facilitated in a millisecond; whereas in the past we had to create auction slots and auctions were time and resource consuming. The only real difference between Board Concerns #1 and #2 is (as you indicate) “timing”. 1. Applicants apply for their strings. 2. After the application window closes those who face contention resolution are requested to submit a sealed bid (the only information they have at this point is that they face some kind of contention – which could be identical or similar strings. They don’t know how many contention set members or their identity or string names). 3. That bid is valid for both auction types: the one where proceeds are shared among losers – and the one where losers won’t benefit (formerly: “auction of last resort”). o The latter one is very important, as applicants may announce upfront that they will not allow losers to financially benefit (this deters fortune seekers). o Example: dotAIRPORT, LLC will make it crystal clear, that it won’t participate in any scheme where auction proceeds are distributed to losers. o In fact we could have applicants OPT OUT of the private auction right in the application – then contention set members would be informed that one member opted out of auction fee distribution: the affected applicants could quickly withdraw their application to maximize their application fee refunds (overall loss); as they are now facing a mandatory ICANN auction of last resort. 4. Auction deposits are due a few days before auction reveal (regardless how auction proceeds are distributed). 5. Failure to pay the winning bid (2nd highest) results in losing the deposit and any potential application fee refund. Thanks, Alexander From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jim Prendergast Sent: Montag, 27. Juli 2020 14:28 To: gnso-newgtld-wg@icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Additional thoughts on Proposal 5 Apologies in advance. I will not be able to join the call later today as I am cohosting a workshop at RightsCon at the same time. I will review the notes and recording and respond on list as necessary. As Jeff noted during the last call, this is complicated because we are now allowing the resolution of contention sets in ways that were not allowed in the 2012 round. A very simple, clean way to settle contention sets without these measures is to have them all go to an ICANN auction of last resort or a random draw. But some people insist that losers should get paid so those are off the table. I also believe that we have to address BOTH Board concerns - Board Concern #1 - applications submitted for the sole purpose of receiving a payout for losing private auctions We have made good progress in addressing #1 and I think we can get there with some tweaks. Transparency requirements are good but they should not be rolled back for the creation of JVs. Not suggesting trade secrets be divulged but we should know who the operator of the JV is and we should also know the circumstances around what caused members of the contention set who are not part of the JV to drop out. I also believe that the Bona Fide proffers should be reviewed and enforced by ICANN, not just the outside evaluators. Rationale is that at some point, the evaluators will disappear. They are temporary help. ICANN has the ultimate responsibility to administer this program so they should be the ones reviewing theses Bona Fide requirements. And along these lines – ICANN should oversee all auctions, not just the Auction of Last resort. As currently constructed in Paul’s edit – there are too many steps for revealing the results of private auctions. With ICANN overseeing this, it’s a much cleaner process. ICANN involvement also adds a level of assurance that these auctions are being conducted in an aboveboard manner. As far as penalties for violations of the Bona Fide requirements – loss of registry has to be there. That is a major deterrent and should not be cast aside. Board Concern #2 - gaming for the purposes of financing other applications. The base Proposal 5 does nothing to address Concern #2. Donna stated that she’s “not convinced that means we have to address it.” I couldn’t disagree more. If we fail to address this now, there is a strong likely hood that the Board will either 1) come back to us and ask us to develop a plan (slowing things down again) or 2) develop a solution themselves. Neither is an ideal outcome so we have to do something to stop the gaming for purposes of financing other applications. I and others believe that the Bona Fide requirements do not go far enough here. Others believe my sealed bid requirement goes too far. So what are alternative solutions that are enforceable and prevent this type of activity? Auction proceeds held in escrow? All auction conducted at once? Timing on when these auctions happen is the key to stop this gaming and that is why I proposed the submission of all bids upfront. With bids upfront, auctions could be conducted whenever but there is a constraint on the ability to roll funds over and over. ICANN’s right to refer to competition authority. We never got around to discussing why Paul felt the need to delete this section completely and since the call there was a brief discussion on list about whether ICANN has this as an inherent right or whether it should be spelled out. My proposal was based upon the RSEP process which is already in force of all registry operators and will be required for all future operators. It specifically calls out competition authority referral if ICANN makes a determination such referral is necessary. I was surprised how representatives of contracted parties reacted so negatively to that since it is in existing registry agreements. My rationale for including this provision and calling it out specifically is simple – if a JV or other form of private resolution raises competition concerns for ICANN, they should have the right to refer it to relevant competition authorities to ensure they are ok with it. This protects ICANN the institution from charges that it is fostering anticompetitive behavior. Jim Prendergast The Galway Strategy Group +1 202-285-3699
Paul, While I do believe there is a problem we need to address, I agree with you that the clock on any contention set resolution can only start after evaluations and objections. Which was the way in 2012 and still makes sense. Rubens
On 27 Jul 2020, at 11:09, McGrady, Paul D. <PMcGrady@taftlaw.com> wrote:
Thanks Alexander,
As I mentioned in my reply to Jim and as we have discussed many times already on many calls, the “all bids up front” model doesn’t work for private auctions. It doesn’t work, frankly, for ICANN Last Resort auctions. Applicants simply cannot know the bid amount it should make until all public comments, GAC Early warnings, objections, etc. are over. We can’t deconstruct the entire New gTLD program to solve a problem that only a fraction of the WG even think is a problem.
Best, Paul
To receive regular COVID-19 updates from Taft, subscribe here <https://www.taftlaw.com/general/subscribe>. For additional resources, visit Taft's COVID-19 Resource Toolkit <https://www.taftlaw.com/general/coronavirus-covid-19-resource-toolkit>.
This message may contain information that is attorney-client privileged, attorney work product or otherwise confidential. If you are not an intended recipient, use and disclosure of this message are prohibited. If you received this transmission in error, please notify the sender by reply e-mail and delete the message and any attachments.
From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Alexander Schubert Sent: Monday, July 27, 2020 8:14 AM To: gnso-newgtld-wg@icann.org Subject: Re: [Gnso-newgtld-wg] Additional thoughts on Proposal 5
Jim,
I agree with you.
And essentially “Board Concern #1” and “Board Concern #2” are identical: The board is concerned that applicants are trying to facilitate financial gain by strategically losing private auctions. For whatever reason: · either just to bath in cash · or to finance other applications and in the end it doesn’t matter. It’s one and the same concern. It is however still beneficial to factor them in separately as the countermeasure to Concern #2 can be easily mitigated by having all auctions for clear cut cases (no objections, etc) all at once. Don’t forget: “sealed bid auctions” are now essentially just “reveals” – all of them can be facilitated in a millisecond; whereas in the past we had to create auction slots and auctions were time and resource consuming. The only real difference between Board Concerns #1 and #2 is (as you indicate) “timing”.
1. Applicants apply for their strings. 2. After the application window closes those who face contention resolution are requested to submit a sealed bid (the only information they have at this point is that they face some kind of contention – which could be identical or similar strings. They don’t know how many contention set members or their identity or string names). 3. That bid is valid for both auction types: the one where proceeds are shared among losers – and the one where losers won’t benefit (formerly: “auction of last resort”). o The latter one is very important, as applicants may announce upfront that they will not allow losers to financially benefit (this deters fortune seekers). o Example: dotAIRPORT, LLC will make it crystal clear, that it won’t participate in any scheme where auction proceeds are distributed to losers. o In fact we could have applicants OPT OUT of the private auction right in the application – then contention set members would be informed that one member opted out of auction fee distribution: the affected applicants could quickly withdraw their application to maximize their application fee refunds (overall loss); as they are now facing a mandatory ICANN auction of last resort. 4. Auction deposits are due a few days before auction reveal (regardless how auction proceeds are distributed). 5. Failure to pay the winning bid (2nd highest) results in losing the deposit and any potential application fee refund.
Thanks,
Alexander
From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>] On Behalf Of Jim Prendergast Sent: Montag, 27. Juli 2020 14:28 To: gnso-newgtld-wg@icann.org <mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Additional thoughts on Proposal 5
Apologies in advance. I will not be able to join the call later today as I am cohosting a workshop at RightsCon at the same time. I will review the notes and recording and respond on list as necessary.
As Jeff noted during the last call, this is complicated because we are now allowing the resolution of contention sets in ways that were not allowed in the 2012 round. A very simple, clean way to settle contention sets without these measures is to have them all go to an ICANN auction of last resort or a random draw. But some people insist that losers should get paid so those are off the table.
I also believe that we have to address BOTH Board concerns -
Board Concern #1 - applications submitted for the sole purpose of receiving a payout for losing private auctions
We have made good progress in addressing #1 and I think we can get there with some tweaks.
Transparency requirements are good but they should not be rolled back for the creation of JVs. Not suggesting trade secrets be divulged but we should know who the operator of the JV is and we should also know the circumstances around what caused members of the contention set who are not part of the JV to drop out.
I also believe that the Bona Fide proffers should be reviewed and enforced by ICANN, not just the outside evaluators. Rationale is that at some point, the evaluators will disappear. They are temporary help. ICANN has the ultimate responsibility to administer this program so they should be the ones reviewing theses Bona Fide requirements.
And along these lines – ICANN should oversee all auctions, not just the Auction of Last resort. As currently constructed in Paul’s edit – there are too many steps for revealing the results of private auctions. With ICANN overseeing this, it’s a much cleaner process. ICANN involvement also adds a level of assurance that these auctions are being conducted in an aboveboard manner.
As far as penalties for violations of the Bona Fide requirements – loss of registry has to be there. That is a major deterrent and should not be cast aside.
Board Concern #2 - gaming for the purposes of financing other applications.
The base Proposal 5 does nothing to address Concern #2. Donna stated that she’s “not convinced that means we have to address it.” I couldn’t disagree more.
If we fail to address this now, there is a strong likely hood that the Board will either 1) come back to us and ask us to develop a plan (slowing things down again) or 2) develop a solution themselves. Neither is an ideal outcome so we have to do something to stop the gaming for purposes of financing other applications.
I and others believe that the Bona Fide requirements do not go far enough here. Others believe my sealed bid requirement goes too far. So what are alternative solutions that are enforceable and prevent this type of activity?
Auction proceeds held in escrow? All auction conducted at once?
Timing on when these auctions happen is the key to stop this gaming and that is why I proposed the submission of all bids upfront. With bids upfront, auctions could be conducted whenever but there is a constraint on the ability to roll funds over and over.
ICANN’s right to refer to competition authority.
We never got around to discussing why Paul felt the need to delete this section completely and since the call there was a brief discussion on list about whether ICANN has this as an inherent right or whether it should be spelled out.
My proposal was based upon the RSEP process which is already in force of all registry operators and will be required for all future operators. It specifically calls out competition authority referral if ICANN makes a determination such referral is necessary. I was surprised how representatives of contracted parties reacted so negatively to that since it is in existing registry agreements.
My rationale for including this provision and calling it out specifically is simple – if a JV or other form of private resolution raises competition concerns for ICANN, they should have the right to refer it to relevant competition authorities to ensure they are ok with it. This protects ICANN the institution from charges that it is fostering anticompetitive behavior.
Jim Prendergast The Galway Strategy Group +1 202-285-3699
_______________________________________________ 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.
Thanks Jim. Comments in line with your notes below. Best, Paul To receive regular COVID-19 updates from Taft, subscribe here<https://www.taftlaw.com/general/subscribe>. For additional resources, visit Taft's COVID-19 Resource Toolkit<https://www.taftlaw.com/general/coronavirus-covid-19-resource-toolkit>. This message may contain information that is attorney-client privileged, attorney work product or otherwise confidential. If you are not an intended recipient, use and disclosure of this message are prohibited. If you received this transmission in error, please notify the sender by reply e-mail and delete the message and any attachments. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Jim Prendergast Sent: Monday, July 27, 2020 6:28 AM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Additional thoughts on Proposal 5 Apologies in advance. I will not be able to join the call later today as I am cohosting a workshop at RightsCon at the same time. I will review the notes and recording and respond on list as necessary. As Jeff noted during the last call, this is complicated because we are now allowing the resolution of contention sets in ways that were not allowed in the 2012 round. A very simple, clean way to settle contention sets without these measures is to have them all go to an ICANN auction of last resort or a random draw. But some people insist that losers should get paid so those are off the table. I also believe that we have to address BOTH Board concerns - Board Concern #1 - applications submitted for the sole purpose of receiving a payout for losing private auctions We have made good progress in addressing #1 and I think we can get there with some tweaks. Transparency requirements are good but they should not be rolled back for the creation of JVs. Not suggesting trade secrets be divulged but we should know who the operator of the JV is and we should also know the circumstances around what caused members of the contention set who are not part of the JV to drop out. The operator of the JV will be in the application update, so that is a red herring. As for parties that are not in a JV, there is no way for a JV to know why other applicants dropped out and no way for the JV or its constituent elemental parties to issue discover to determine why a third party dropped out. I also believe that the Bona Fide proffers should be reviewed and enforced by ICANN, not just the outside evaluators. Rationale is that at some point, the evaluators will disappear. They are temporary help. ICANN has the ultimate responsibility to administer this program so they should be the ones reviewing theses Bona Fide requirements. I don’t disagree, but unless we want to create the entire framework now instead of having the IRT do it (as Jeff suggested) we need to build out details around how ICANN would enforce these. And along these lines – ICANN should oversee all auctions, not just the Auction of Last resort. As currently constructed in Paul’s edit – there are too many steps for revealing the results of private auctions. With ICANN overseeing this, it’s a much cleaner process. ICANN involvement also adds a level of assurance that these auctions are being conducted in an aboveboard manner. This has been debated extensively. ICANN overseeing private auctions makes them ICANN auctions not private auctions. There is no stomach for the elimination of private auctions. As far as penalties for violations of the Bona Fide requirements – loss of registry has to be there. That is a major deterrent and should not be cast aside. This doesn’t make any sense. If the concern is that a party is losing to get money, how do you take away a registry from a party that didn’t win it in an auction? Even if you could, the disruption to any second level registrants would be intense. Board Concern #2 - gaming for the purposes of financing other applications. The base Proposal 5 does nothing to address Concern #2. Donna stated that she’s “not convinced that means we have to address it.” I couldn’t disagree more. Proposal 5 does address this by requiring a bona fide intention to run the registry. If we fail to address this now, there is a strong likely hood that the Board will either 1) come back to us and ask us to develop a plan (slowing things down again) or 2) develop a solution themselves. Neither is an ideal outcome so we have to do something to stop the gaming for purposes of financing other applications. Perhaps, but there are other items, such as Closed Generics, where the Board instructed us to find a solution and we aren’t going to do so. Also, sometimes the Board doesn’t get what it wants – that is what the bottom up process is all about. I and others believe that the Bona Fide requirements do not go far enough here. Others believe my sealed bid requirement goes too far. So what are alternative solutions that are enforceable and prevent this type of activity? Auction proceeds held in escrow? All auction conducted at once? All auctions conducted at once won’t work as all contention sets aren’t on the same timeframe (objections, etc.). Holding auction proceeds in escrow hurts smaller players who may not be able to borrow against the escrowed funds in time, sure, but would do nothing to hinder large corporations. These ideas sound good, but don’t actually accomplish anything other than ICANN interfering in private auctions. Timing on when these auctions happen is the key to stop this gaming and that is why I proposed the submission of all bids upfront. With bids upfront, auctions could be conducted whenever but there is a constraint on the ability to roll funds over and over. All bids up front has been discussed extensively and rejected repeatedly. It doesn’t work. Applicants cannot know the bid amounts until all public comments, GAC Early warnings, objections, etc. are over. We can’t deconstruct the entire New gTLD program to solve a problem that only a fraction of the WG even think is a problem. ICANN’s right to refer to competition authority. We never got around to discussing why Paul felt the need to delete this section completely and since the call there was a brief discussion on list about whether ICANN has this as an inherent right or whether it should be spelled out. My proposal was based upon the RSEP process which is already in force of all registry operators and will be required for all future operators. It specifically calls out competition authority referral if ICANN makes a determination such referral is necessary. I was surprised how representatives of contracted parties reacted so negatively to that since it is in existing registry agreements. My rationale for including this provision and calling it out specifically is simple – if a JV or other form of private resolution raises competition concerns for ICANN, they should have the right to refer it to relevant competition authorities to ensure they are ok with it. This protects ICANN the institution from charges that it is fostering anticompetitive behavior. We actually discussed this for a large portion of a call that you were on. I deleted it from the draft because we came to a conclusion on the call that there will be a general notice in the AGB that ICANN can refer whatever it wants whenever it wants to whatever competition authority it chooses – and not just for private auctions. So, this comment leaves me befuddled. Jim Prendergast The Galway Strategy Group +1 202-285-3699
participants (5)
-
Alexander Schubert -
Jim Prendergast -
McGrady, Paul D. -
Rubens Kuhl -
trachtenbergm＠gtlaw.com