December 2019 - Gnso-newgtld-wg

Re: [Gnso-newgtld-wg] EBERO / SLAM Data Status and next steps
by Steve Chan 31 Jan '20

31 Jan '20

Dear All, There did not appear to be any comments, questions, or objections to how the EBERO/SLAM data topic was characterized by Jeff, including what will be sought from ICANN Org’s GDD team. The information below will be sent to GDD for their review and resolution. Best, Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Jeff Neuman <jeff.neuman(a)comlaude.com> Date: Wednesday, October 2, 2019 at 8:14 AM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] EBERO / SLAM Data Status and next steps All, On 23 August 2019, high-level statistics were shared from ICANN org’s SLA Monitoring program (attached). These statistics provided the monthly number of 1) DNS failures 2) RDDS failures and 3) DNS and RDDS failures that reached the EBERO threshold. On 26 August 2019, Donna Austin shared a RySG document which included data previously shared by ICANN org at the Madrid DNS Symposium / GDD Summit (attached). This data provided more detail on group 3 above in particular, including elements like: The cause for why the EBERO threshold was reached (i.e., DNS/DNSSEC or RDDS) A further, more specific breakdown within each of the two categories that indicate why the EBERO threshold was reached (e.g., IPv6 transport error, broken chain of trust in DNSSEC, etc.) Within our Working Group there has been some discussion about what impact this data may have. For example, we discussed whether past failures should have any impact on future application evaluations or RSP pre-approval for future rounds? The Working Group, however, is trending towards agreeing that evaluation and thus RSP pre-approval (which is likely to leverage the same or substantially the same evaluation criteria) should be forward looking and not be impacted by past performance. The Working Group is also trending towards requiring the pre-approval prior to each evaluation round and that the approval will be good for the duration of the then-current round. A second area in which this data could have an impact is whether or not existing Registry Service Providers should be grandfathered into any future pre-approval processes? Based on the Working Group’s deliberations and public comment received, the answer appears to be no. Most of the comments seem to point to requiring all RSPs (whether new or existing) to go through the same processes in future rounds. Therefore, based on where the Working Group is heading, the Co-Chairs do no believe that we are in need of additional historical data for purposes of finalizing its work on the RSP Pre-approval program. We recognize that registry service provider performance has been a topic of discussion for matters other than the pre-approval program. We understand that there has been discussion about whether the relatively high number of registry services failures indicates that RSP might need to improve how they operate to ensure the security and stability of the DNS. While this WG is forward looking and not intending to impose new commitments for existing RSPs, lessons may be learned to improve the evaluation process for future applicants/RSPs. Based on the above, the WG believes it does need more context from GDD to understand the data it has been provided, since not all SLA failures are equally harmful. Therefore in looking at the failures, for example, the WG needs clarity on whether they refer to service availability or Round Trip Time (RTT). The WG also wants to try and examine if there was any harm caused by the downtime, which is benefitted in part by understanding the timing of the failure (e.g., prior to Sunrise, during Sunrise, before General Availability, after GA). For the failures that did NOT reach the EBERO threshold, the WG would like summary data of which of the SLRs was missed. For the failures that DID reach the EBERO threshold, a detailed breakdown (e.g., similar specificity that was shared at the Madrid DNS Symposium / GDD Summit), which includes the timing of the failure. This information may help identify weaknesses in the evaluation criteria, registry system testing, and/or contractual requirements captured in the Registry Agreement. The leadership intends to send the request for additional context next week, but we would like to know if there are any comments from the Working Group. Thanks for your attention to this matter. Best regards, Jeff Neuman and Cheryl Langdon-Orr SubPro PDP Co-Chairs 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

3 4

Happy Holidays !
by Vanda Scartezini 22 Dec '19

22 Dec '19

My best wishes for 2020 full of Health, Joy and Success! kisses Vanda Scartezini Polo Consultores Associados Av. Paulista 1159, cj 1004 01311-200- Sao Paulo, SP, Brazil Land Line: +55 11 3266.6253 Mobile: + 55 11 98181.1464 Sorry for any typos.

1 0

Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019
by Pruis, Elaine 21 Dec '19

21 Dec '19

Happy Holidays! I was hoping we’d have this conversation on the last call. Now we’re heading into a long break, so I’ll put some thoughts out to the list for further discussion on these two points: 1. Kristine wrote: “I even included a “pro” in the ICANN Auction of Last Resort category because I know some folks on here believe there is a hypothetical problem with “applicants being paid to lose”. And Paul McGrady suggesting in his comments, “There have been rumors of gaming in the last round.” A quick google of “Minds + Machines auction” very clearly exemplifies “being paid to lose” as a winning strategy in the 2012 round. It isn’t a “hypothetical”. Here is one of many examples; “….MMX, which applied for .inc and .llc, said this morning that it has benefited from a $2.4 million windfall by losing both auctions.” The ICANN Board has expressed their concern around the “practice of participating in private auctions for the sole purpose of being paid to drop out” via their Subsequent Procedures Supplemental Report public comments for this PDP WG to address. This practice is not hypothetical, nor a rumor, but is this a “problem”? I think we can best answer that question by considering another of Paul’s statements, 1. “Weaknesses…Enriches ICANN (which has never justified why it thinks it “owns” the undelegated TLD resource).” Are TLDs public assets? If not, what are they? How do you justify your answer to that question? We’ve created a MSM that defines ICANN as a steward of this resource. If we don’t treat TLDs as public assets, we decrease ICANN’s legitimacy. Imagine if new TLD application fees were $50k, and private auctions are a part of the contention resolution formula. There will be thousands of speculative “pay me to go away” applications, instead of just hundreds like in 2012. People noticed the windfalls in the last round and are hoping that it is a business strategy they can deploy in the next round, with no intention of actually operating the TLD. Donna suggested some rules or policy that might prevent speculative participation. But a recent article<https://www.aei.org/technology-and-innovation/experiments-in-market-solutio…> on the “Experiments in market solutions: The FCC’s toll-free number auction” states “This creates incentives for strategic behavior by RespOrgs such as warehousing or hoarding available numbers, which ties up these resources unproductively and leads to quicker exhaustion of the limited supply of numbers in each area code. Historically the Commission has tried to control this strategic behavior via regulation, which can be costly and is not guaranteed to be effective. Moreover, assignment via a first-in-time rule can lead to inefficient allocation of toll-free numbers, as they flow to customers with the fastest trigger fingers, rather than those who value the number the most. Woke: Toll-free assignment auction To address this inefficiency, the FCC voted last year to allocate the most popular numbers in the new area code via auction. The structure is a single-round Vickrey auction. Qualified bidders submit a sealed bid for each available toll-free number they are interested in. The highest bid wins the number, but the bidder is only required to pay the value of the second-highest bid. The single-round structure reduces the agency’s administrative costs compared to the multi-round structure used for more valuable spectrum auctions. And as the Commission notes, the Vickrey design discourages strategic bidding by encouraging a participant to bid its true estimate of a number’s value, knowing it will only have to pay the value placed on it by the runner-up.” I think it is impossible to prevent private resolution. Those that want to make deals will do it before or after the delegation. But I don’t think we should set up the program to encourage private auctions. We need to treat TLDs as a public asset. Perhaps we can recommend that auction funds to ICANN be used strictly for security and stability purposes (for example, fund the RIRs). I’d like us to look at this piece through the lens of “public benefit” and not “private gain”. Elaine From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of "Dorrain, Kristine via Gnso-newgtld-wg" <gnso-newgtld-wg(a)icann.org> Reply-To: "Dorrain, Kristine" <dorraink(a)amazon.com> Date: Thursday, December 12, 2019 at 3:43 PM To: Kurt Pritz <kurt(a)kjpritz.com> Cc: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [EXTERNAL] Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Fair points. I also prefer a model where ICANN is not enriched and the process *is* cost neutral. Therefore, I support having this conversation at a policy level. Regarding the preferability of Vickrey, I think there will be a range of outcomes regardless of what scheme is used, which is why I like the idea of choice. Applicants can select for themselves what model fits their situation. To answer your question below, even with Vickrey, the most well-off applicants can simply bid an outrageous amount, so Vickrey does favor deep pockets, as Paul pointed out in the table. The only option currently on the list that provides ANY hope for a resolution that doesn’t necessarily cost a pile of money is private resolution. Kristine From: Kurt Pritz <kurt(a)kjpritz.com> Sent: Thursday, December 12, 2019 12:11 PM To: Dorrain, Kristine <dorraink(a)amazon.com> Cc: McGrady, Paul D. <PMcGrady(a)taftlaw.com>; gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Thanks for your comments Kristine. I did purposefully leave off the “paid to ICANN” part as that is a separate policy question I think. I don’t think we need to assume that the money would go to ICANN: * as that did not go so well the first time, and * we should consider what a “cost neutral” application process really means. If we think the process should be cost neutral to ICANN, then I think / suppose that placing the auction funds aside in a foundation of sorts would satisfy the neutrality requirement. (Although, the lie might have been put to that when ICANN replenished its reserve out of the auction funds.) If we think the process should be cost neutral to ICANN AND the applicants, then should not the money go back to the applicants in some way? Isn’t that truly cost neutral? Additionally, as a question of policy, maybe the money can be placed in some more effective foundation than one that is taking years to establish. I think these are policy choices for us. Finally, to me it seems that Vickrey is probably preferable to a highest price auction but, as I said in an earlier email, it is a complex economics issue. For example, can the Vickrey scheme be gamed in someway where there are well-off and not-well-off applicants? Or does the Vickrey scheme tend to defeat that gaming? We should tell ICANN what our policy goals are for this and ask them to figure it out in implementation, which will be reviewed by the community. Whew, sorry, Kurt On Dec 12, 2019, at 11:56 AM, Dorrain, Kristine <dorraink(a)amazon.com<mailto:dorraink@amazon.com>> wrote: I fully support Paul’s choice model and have added a few more pros and cons to the table. In the interest of equity, I even included a “pro” in the ICANN Auction of Last Resort category because I know some folks on here believe there is a hypothetical problem with “applicants being paid to lose.” The Auction of Last Resort can be effective against any perception that this might be a problem because applicants must ALL agree to any other mechanism. I generally support Kurt’s additions, with a few questions/suggestions in red. I’m going to be late for the call that starts shortly… Kristine From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Kurt Pritz Sent: Thursday, December 12, 2019 11:35 AM To: McGrady, Paul D. <PMcGrady(a)taftlaw.com<mailto:PMcGrady@taftlaw.com>> Cc: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 I think the table is a great idea. If it helps clarify the discussion, under ‘Auction Type,’ I think the options could be: Sealed Bid - winner pays highest price bid to ICANN (why would the winner not pay the second highest price…did I miss something? I think this option is more about timing, not any other change to the Vickrey model) Sealed Bid - Vickrey (winner pays second highest price bid to ICANN) Ascending auctions (paid to ICANN) - similar to the previous round Private resolution (fully private...notably, participants could self-select a sealed bid auction as their private auction mechanism of choice) Additionally, under ‘Auction Type’ or ‘Auction Timing' as a separate table the options would be: (I do like the idea of making this clear in the chart) Timing - bids submitted at time of TLD application Timing - bids submitted at near time of TLD award (after evaluation, clearing of objectionsetc) I think breaking it out this way would make the identification of strengths and weaknesses easier and clearer. Best regards, Kurt On Dec 10, 2019, at 2:25 PM, McGrady, Paul D. <PMcGrady(a)taftlaw.com<mailto:PMcGrady@taftlaw.com>> wrote: Hi All! I have really enjoyed the conversation on the calls and on this list regarding auctions. It is a great reminder of how rich in talent our community is. Below I have summarized some of the pros and cons of each process discussed (these are not meant to be exhaustive or dismissive, just my own thoughts which I encourage others to supplement). I’ve also proposed a possible way forward that could disrupt the current default status quo (ICANN Last Resort auction found in 2012 AGB, but which in my opinion is based on the false premise that ICANN “owns” all the undelegated gTLD space) but not force everyone into a one-sized-fits-all solution. I hope that the below encourages communication and helps us reach a consensus position that everyone in the WG can stand behind. Auction Type Strengths Weaknesses Vickrey (place maximum bid amount at the time application is filed) • Straightforward. • Eliminates significant delays caused by contention sets. • Favors single TLD applicants. • Favors deep pockets. • Bad for .brand applicants who could end up paying significantly more • Enriches ICANN (which has never justified why it thinks it “owns” the undelegated TLD resource). • Assumes no changes in the round/procedures/ other circumstances between filing of the application and the auction. • Assumes money is the only way to solve a contention. Modified Vickrey (place maximum bid amount at the time contention sets are formed) • Straightforward. • Eliminates much of the delay caused by contention sets • Eliminates ICANN Last Resort auctions. • Allows multiple TLD applicants to use resources more efficiently. • Favors deep pockets. • Enriches ICANN (which has never justified why it thinks it “owns” the undelegated TLD resource). • Assumes money is the only way to solve a contention. Private Resolution (could be dollar amounts, acquisitions, other consideration, etc.) • Allows for full creativity to resolve contention sets. • Doesn’t enrich ICANN (which has never justified why it thinks it “owns” the undelegated TLD resource). • The parties may agree on an auction process to resolve the contention set or they may agree instead to negotiate toward a mutually rewarding outcome. • There have been rumors of gaming in the last round. • Favors deep pockets.Amend to say: may favor deep pockets…private resolutions do not require the expenditure of ANY cash. ICANN Last Resort (status quo from 2012 AGB) None. • No applicant “gets paid to lose.” • Favors deep pockets. • Enriches ICANN (which has never justified why it thinks it “owns” the undelegated TLD resource). A possible way forward: Choice. Let each applicant choose how they would like to proceed. If all of the other members in the contention set make the same choice, that is the method that will be used. If, however, the members of the contention set do not agree, then ICANN Last Resort (status quo) will be default. There is no harm to the pro-Vickrey applicants in this option since whatever dollar amount they designated in their applications can, if they so choose, become their maximum dollar amount in an ICANN Last Resort if need be. Since an applicant submitting a Vickrey auction preference might be compromised in an ICANN Last Resort, the maximum dollar amount they are prepared to spend should be lodged with a third party under strict confidentiality obligations, e.g. with one of the large accounting firms. The same is true for the pro-Modified Vickrey applicants. Whatever maximum dollar amount that they would have bid once contention sets were finalized can become their maximum bid in an ICANN Last Resort if need be. Likewise, if an applicants selected Private Resolution and the other member(s) of the contention set did not, they would simply bid in the ICANN Last Resort whatever they were prepared to pay in a private auction. Because Private Resolution opens up the door to creative problem solving between members of a contention set, the applicants in that contention set should be allowed to select – after contention sets are formed – to try Private Resolution. Such a selection should be unanimous and if it doesn’t lead to resolution (e.g. negotiations are attempted and fail instead of the parties using a private auction), then the ICANN Last Resort option would kick in. I hope the above is helpful and moves us a bit closer to a consensus position. Thanks. Best, Paul 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(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Justine Chew Sent: Monday, December 9, 2019 6:49 PM To: Austin, Donna <Donna.Austin(a)team.neustar<mailto:Donna.Austin@team.neustar>> Cc: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Thank you, Donna, for picking this up. Just in relation to Goal No. 1, on reflection, I think the text "...in which the winner ultimately overpays for the TLD" should be omitted or reworded, firstly as Donna has explained, we don't know what "overpays" actually means. Secondly, even if that is the case, why should we be concerned if an applicant chooses to "overpay". Thirdly, At-Large's concerns had to do with the situation of wealthier applicants outbidding less-wealthy applicants, thereby potentially stifling competition. So, perhaps the goal should be re-stated as "Reduce the risk of unintended outcomes from “bidding wars". As for the remaining texts, I would like to be able to review the flowcharts for the 3 Alternatives before making further comments. Thanks, Justine Chew ----- On Sat, 7 Dec 2019 at 04:57, Austin, Donna via Gnso-newgtld-wg <gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>> wrote: Thanks for the notes Julie, these are particularly helpful as I wasn’t able to attend the call. I have listened to the recording and I wanted to address a couple of issues that were discussed and are captured in your notes. I don’t agree that Alternative 1 addresses the following goal: 1. Reduce the risk of “bidding wars” in which the winner ultimately overpays for the TLD. a. Tentative, related goal for discussion: encourage applicants to bid their true value for a TLD. I personally struggle with this as a goal because it’s a subjective assessment that applicants from 2012 overpaid for a TLD. Only the successful applicant can make that judgement and if the applicant willingly entered into a private or ICANN auction of last resort they didn’t do so blindly: they had an opportunity to assess the market and combined with their own personal objectives for wanting a string made a judgement about how much they were willing to pay for the string. As I noted previously, my main issue with Alternative 1 is that the sealed bid has to be provided at the time of application, which is unfair to any applicant that ultimately finds themselves in a contention set. No-one can predict how many applications will be received and how many strings will end up in a contention set so the applicant has no information available at the time of submitting their application on which to assess the value of the TLD to them. It would be eminently fairer to all applicants to submit sealed bids at a time when more information is available that would allow them to make a more informed decision about the value of the TLD to them, which is ultimately why I proposed Alternative 2 originally. Donna Donna Austin Neustar, Inc. / Senior Policy Manager, Registry Solutions Mobile: +1 310 890 9655 donna.austin(a)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 Julie Hedlund Sent: Monday, December 02, 2019 8:52 AM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Dear Working Group members, Please see below the notes from the meeting on 02 December 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-12-02+New+gTLD+Subsequent+Pr…<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…>. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: ACTION ITEM 1: Add a third alternative. ACTION ITEM 2: Add another goal (#7): “Increase efficiencies in application evaluation by way of understanding the contention set?” ACTION ITEM 3: Create a flow chart with a fictional string to show how alternative 1 would work. ACTION ITEM 4: Update the list of goals. Notes: 1. Review Agenda/Statements of Interest: Susan Payne was reappointed IPC Secretary for another year. 2. String Contention Mechanisms of Last Resort:https://docs.google.com/document/d/16qDoiK6vydQp6a0v9tMvU2l5fcypJY24… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> What is the issue we are trying to address: -- The Working Group has discussed a number of potential issues with the mechanisms of last resort used in the 2012 New gTLD Round. These issues are captured in the Supplemental Initial Report. -- Although the Working Group ultimately believes that when there is string contention, an auction process should be used to select the Registry Operator invited to enter into a Registry Agreement with ICANN, the Working Group is still discussing what forms of private resolution should be allowed (if any), the specific type of auction to be used, and the timing of such an auction. Policy Goals / What the WG is Seeking to Accomplish: -- The WG is largely supportive of existing Implementation Guideline F: Implementation Guideline F: If there is contention for strings, applicants may: i) resolve contention between them within a pre-established timeframe ii) if there is no mutual agreement, a claim to support a community by one party will be a reason to award priority to that application. If there is no such claim, and no mutual agreement a process will be put in place to enable efficient resolution of contention and; iii) the ICANN Board may be used to make a final decision, using advice from staff and expert panels. Other goals include: 1. Reduce the risk of “bidding wars” in which the winner ultimately overpays for the TLD. * Tentative, related goal for discussion: encourage applicants to bid their true value for a TLD. 1. Reduce collusion, profiteering, and/or speculation, especially as it relates to financial transactions external to the program (Note, while this is not an explicit goal for the mechanisms of last resort, it has been discussed as a motivation for altering the auction mechanism). 2. Increase transparency. 3. Resolve contention more quickly. 4. Increase predictability. 5. Encourage new entrants into the field. b. Which could include, making it easier to implement “multipliers” for certain types of applicants, such as those eligible for Applicant Support. -- Note that some of the terminology may need to be further defined if the above goals are adopted. In order to ensure that recommendations align with goals, it is important for the Working Group to agree on specific objectives. Discussion: -- Do we still need iii)? An alternative may be, "The ICANN Board may use expert panels to make Community Priority Evaluation determinations." This may also be dependent on recommendations on the new appeals mechanism. -- ICANN Board says it does not make policy. Its decision would be subject to RFR and IRP - very messy so it may be better to stick with what we developed earlier. -- This isn’t about the Board making policy, but making it clear that it’s an auction process rather than the Board making a decision. -- There should be a reference instead to Auction of last resort. -- Agree they are good goals so suggest removing possible description What are we Proposing? -- The Working Group is leaning towards recommending a sealed-bid auction as the ultimate form of auction used as a mechanism to resolve string contention. When a sealed-bid auction is held where bids are submitted without knowing the bid of others in the auction (e.g., prior to evaluating any of the applications) it is also called a Vickrey Auction. A sealed-bid auction can also be used as a mechanism of last resort and at the end of the process. -- With a sealed-bid auction, each applicant submits a sealed bid, stating the amount that they are willing to pay for the TLD. The ultimate “winner” pays the amount submitted by the second-highest bidder.. -- Regardless of when the sealed bid auction is held, if there are one or more Community-based Applications, that/those application(s) would need to be processed first through Community Priority Evaluation before looking at the auction bids. Alternative 1 - Vickrey Auction (No Private Resolution) -- Addresses goals 1, 2, 4, and 6. -- The principle pro here is the seemingly near elimination of private resolution. However, the principle con is the substantial complications this approach introduces (see Additional Considerations, Mostly For Alternative 1 below). Other cons are that other forms of private resolution might be impacted (e.g., joint ventures, string change, etc.) in seeking to eliminate private resolution for financial benefit and that bids are submitted with no contextual information. Alternative 2 - Sealed-Bid Auction allowing Private Resolution -- It seems to be supportive of, or at least not impede, 1, 2, and 6, but in a less pronounced manner as it relates to Alternative 1; the maker of this Alternative has acknowledged that it does not fully address concerns around potential collusion and profiteering on application withdrawals. -- However, some benefits are likely derived by obtaining sealed bids (which can reduce the incentive for all parties to agree to private resolution, if an applicant already knows they have the highest bid). The other main pro here is simplicity - most other processes remain unaffected. Discussion: -- Re: Alternative 2: First bullet point and third bullet point seem incompatible. Third bullet point: “Applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or to choose another string as was suggested for ‘brands’ of the same name.” -- Assuming you stayed in only those applicants who stayed in would be revealed on reveal day. So you could still have private resolution. -- For clarity, the third bullet could be swapped with the fourth bullet and add “post reveal day”. In third bullet point, after "opportunity", you would need to insert "after reveal day" or something to clarify that parties become known. -- Question: Wasn’t one of the proposals to outlaw private auctions? So not sure why we are still allowing private resolution. Answer: If we went with alternative 1 we would eliminate private resolution, but not for alternative 2. So that is one of the drawbacks with alternative 2. -- Thought alternative 2 was to allow participants to know how many contention sets there are. Add as a third alternative: Alternative three could remove some of the elements about private resolution. -- They may not resolve privately and should only have a limited period to resolve. If not resolved in a limited period, it should proceed to the sealed bid winner. I am not seeing the time limit in alternative 2 though. Is it there? -- Question: How would the timing work with a string contention objection process? -- How could private auctions be prevented? -- Objections should not be triggered until a winner (or a private resolution winner) is identified. -- Re: Alternative 2 there should be a limited time for private resolution. -- Helpful to put these alternatives out for public comment and indicate whether the WG has a preference. -- Re: Alternative 2 -- Question: For string confusion objections those would have to be heard right away. Additional Considerations: Public Comment: Comments from the public are solicited on all applications regardless of where they are placed in the queue. To do it otherwise would mean opening up separate public comment periods depending on whether there is a need to go to the second bidder, and that would be impossible to monitor. Discussion: -- Strongly support 1 public comment period, for the exact same length of time for all. -- Impractical to have multiple public comments. String Similarity Evaluation: Discussion: -- Don’t see how this fits with the notion of closed bids and timing. You have a scenario where you have some who know who they are bidding against and everyone else doesn’t. -- In the scenario where the result of a string similarity evaluation is that some would have insight into who is in the set -- this is an unfair result. -- Which is why getting every applicant to submit a bid at the point of application is something to consider, even though it may be cumbersome for many. -- What if this fact situation should default to sealed bid only? -- Why would they not be all announced at the same time? -- So we are proposing to treat some applicants differently from others? That does not seem to be in line with the Bylaws. -- Wouldn’t alternative 1 solve this issue? -- What about plurals? -- There was only one case in 2012 that was found to be similar (unicorn/unicom). -- Why string similarity evaluation after reveal day? Why not make it before reveal day? That is a possibility. -- is string similarity not subject to accountability mechanisms and appeals? would that not “reveal” it in some manner? -- Agree with that suggestion re string similarity evaluation occurring first and before reveal day. bids would have to be in before appeal. Objections: Objections on the highest bidder’s application must be filed within the objection period. With respect to objections to the other applications, ICANN would create a system for the filing of “an intent to file an objection.” Discussion: -- Question: What happens when someone indicates that they are filing a community objection and they are filing it against all of the applicants for a string. Answer: All applicants should have a chance to respond. Add text to relay your comment on "can indicate that an objection will apply to all applications for same string"?  -- Objections should not come into full proceedings unless and until there is a winner - it's a huge waste of time and money if it does proceed but private parties need to know what the value of the string may be. -- Some concern about not having to submit the objections on a standard timeline, although support not engaging fees or panels until the objection is necessary, based on bidder ordering . -- “time” may benefit some as they build their case. Or could the “intent to file” require some key points that will be included in the objection filing? -- Question: We are agreeing on the principle that the intent to object is a good idea, but when would that happen? Would one party have to state the type of objection and the grounds? Could it just be a party filing very general intent to objection concerning a risk associated with that application. Would there be a panel for an intent to object process? Answer: Proposal was that the objection would be “bare bones”. There would be no panel if it was just an intent to object to one application, but if for all applications (to the string) then one could request a panel. You file your objection against the applicant first in the queue and an intent to file against the others in the queue. Or, you could say I have the same objection to all of the applicants/string. -- Important for private parties in resolution to know that there is an intent to object (but that doesn’t pertain to alternative 1 as there is no private resolution). -- The objection should be submitted within a certain time period. -- The nature of the applicant is important. It's not just the existence of the string. It depends on who is operating it and what the purpose of the tld as stated in the application in Question 18 answers and services to be provided in answer to Question 23. There should be an intent to object process prior to determining the order of the queue with no panel convened. Other complications: Objections if there is more than one Community Application String Confusion Objection Results in the Creation of a New Contention Set or Adds to an Existing Contention Set Appeals/Accountability Mechanisms Applicant Support Program Discussion: -- Seems that these are all related to the attempt to gain efficiencies to know the order of the contention sets. If you don’t need to know the order then you could leave the program untouched. If you go back to the goals knowing the order of the contention sets goes to goals 3, 4, and 5. -- Add a goal: “Increase efficiencies in application evaluation by way of understanding the contention set?” -- Note that alternative 1 would eliminate the goal to allow contention resolution. “If there is contention for strings, applicants may: i) resolve contention between them within a pre-established timeframe” _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg(a)icann.org<mailto: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(a)icann.org<mailto: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.

4 7

Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019
by Pruis, Elaine 20 Dec '19

20 Dec '19

Thanks for the response Kristine, Let me clarify, I said we should recognize that ICANN is a steward of public assets, TLDs. I didn’t say we should operate all TLDs only as a public benefit. Not the same thing at all. Elaine From: "Dorrain, Kristine" <dorraink(a)amazon.com> Date: Friday, December 20, 2019 at 3:49 PM To: "Pruis, Elaine" <epruis(a)verisign.com>, "kurt(a)kjpritz.com" <kurt(a)kjpritz.com> Cc: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [EXTERNAL] RE: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Thanks Elaine, Just a quick response so I hope it makes sense. I didn’t say that some people weren’t paid to lose. I said it was a hypothetical problem. So my answer to your question at the end of #1 is “no, it’s not a problem.” If two willing parties felt like a TLD was worth a certain amount, it’s not a problem. They could have walked away. I think the auction (private and otherwise) prices were high the first round because people were betting on running very profitable registries. I don’t see that being the reality. A few are, but not most. Not yet. Will folks show up to write these big checks in the next round given the slow start to new gTLDs? Regarding #2 – if we start to insist that all TLDs operate only as a public benefit, we will discourage what little competition the new gTLD program currently permits. No one willing to take a risk, or do anything creative with the DNS will be able to pass the test because they’re simply experimenting (many experiments fail or require iteration and may take a while to prove their status as a public benefit). You will simply perpetuate the same “speculators snatch up domains at low cost, from registrars who are forced to compete to sell them for next to nothing, to sell them at a markup to people who want to start a website” philosophy. This does not encourage anything more than what we’ve been doing for 20 years already. Private resolution means MORE than an auction. It means that the parties may agree to exchange other valuable consideration or join forces. It provides opportunities to innovate. Paul’s proposal to let the parties decide doesn’t actually hurt anyone. If you don’t want to participate in a private resolution (auction or otherwise) don’t. It doesn’t affect you. But why limit what others can do? Thanks, Kristine From: Pruis, Elaine <epruis(a)verisign.com> Sent: Friday, December 20, 2019 8:32 AM To: Dorrain, Kristine <dorraink(a)amazon.com>; kurt(a)kjpritz.com Cc: gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Happy Holidays! I was hoping we’d have this conversation on the last call. Now we’re heading into a long break, so I’ll put some thoughts out to the list for further discussion on these two points: 1. Kristine wrote: “I even included a “pro” in the ICANN Auction of Last Resort category because I know some folks on here believe there is a hypothetical problem with “applicants being paid to lose”. And Paul McGrady suggesting in his comments, “There have been rumors of gaming in the last round.” A quick google of “Minds + Machines auction” very clearly exemplifies “being paid to lose” as a winning strategy in the 2012 round. It isn’t a “hypothetical”. Here is one of many examples; “….MMX, which applied for .inc and .llc, said this morning that it has benefited from a $2.4 million windfall by losing both auctions.” The ICANN Board has expressed their concern around the “practice of participating in private auctions for the sole purpose of being paid to drop out” via their Subsequent Procedures Supplemental Report public comments for this PDP WG to address. This practice is not hypothetical, nor a rumor, but is this a “problem”? I think we can best answer that question by considering another of Paul’s statements, 1. “Weaknesses…Enriches ICANN (which has never justified why it thinks it “owns” the undelegated TLD resource).” Are TLDs public assets? If not, what are they? How do you justify your answer to that question? We’ve created a MSM that defines ICANN as a steward of this resource. If we don’t treat TLDs as public assets, we decrease ICANN’s legitimacy. Imagine if new TLD application fees were $50k, and private auctions are a part of the contention resolution formula. There will be thousands of speculative “pay me to go away” applications, instead of just hundreds like in 2012. People noticed the windfalls in the last round and are hoping that it is a business strategy they can deploy in the next round, with no intention of actually operating the TLD. Donna suggested some rules or policy that might prevent speculative participation. But a recent article<https://www.aei.org/technology-and-innovation/experiments-in-market-solutio…> on the “Experiments in market solutions: The FCC’s toll-free number auction” states “This creates incentives for strategic behavior by RespOrgs such as warehousing or hoarding available numbers, which ties up these resources unproductively and leads to quicker exhaustion of the limited supply of numbers in each area code. Historically the Commission has tried to control this strategic behavior via regulation, which can be costly and is not guaranteed to be effective. Moreover, assignment via a first-in-time rule can lead to inefficient allocation of toll-free numbers, as they flow to customers with the fastest trigger fingers, rather than those who value the number the most. Woke: Toll-free assignment auction To address this inefficiency, the FCC voted last year to allocate the most popular numbers in the new area code via auction. The structure is a single-round Vickrey auction. Qualified bidders submit a sealed bid for each available toll-free number they are interested in. The highest bid wins the number, but the bidder is only required to pay the value of the second-highest bid. The single-round structure reduces the agency’s administrative costs compared to the multi-round structure used for more valuable spectrum auctions. And as the Commission notes, the Vickrey design discourages strategic bidding by encouraging a participant to bid its true estimate of a number’s value, knowing it will only have to pay the value placed on it by the runner-up.” I think it is impossible to prevent private resolution. Those that want to make deals will do it before or after the delegation. But I don’t think we should set up the program to encourage private auctions. We need to treat TLDs as a public asset. Perhaps we can recommend that auction funds to ICANN be used strictly for security and stability purposes (for example, fund the RIRs). I’d like us to look at this piece through the lens of “public benefit” and not “private gain”. Elaine From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> on behalf of "Dorrain, Kristine via Gnso-newgtld-wg" <gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>> Reply-To: "Dorrain, Kristine" <dorraink(a)amazon.com<mailto:dorraink@amazon.com>> Date: Thursday, December 12, 2019 at 3:43 PM To: Kurt Pritz <kurt(a)kjpritz.com<mailto:kurt@kjpritz.com>> Cc: "gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>" <gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>> Subject: [EXTERNAL] Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Fair points. I also prefer a model where ICANN is not enriched and the process *is* cost neutral. Therefore, I support having this conversation at a policy level. Regarding the preferability of Vickrey, I think there will be a range of outcomes regardless of what scheme is used, which is why I like the idea of choice. Applicants can select for themselves what model fits their situation. To answer your question below, even with Vickrey, the most well-off applicants can simply bid an outrageous amount, so Vickrey does favor deep pockets, as Paul pointed out in the table. The only option currently on the list that provides ANY hope for a resolution that doesn’t necessarily cost a pile of money is private resolution. Kristine From: Kurt Pritz <kurt(a)kjpritz.com<mailto:kurt@kjpritz.com>> Sent: Thursday, December 12, 2019 12:11 PM To: Dorrain, Kristine <dorraink(a)amazon.com<mailto:dorraink@amazon.com>> Cc: McGrady, Paul D. <PMcGrady(a)taftlaw.com<mailto:PMcGrady@taftlaw.com>>; gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Thanks for your comments Kristine. I did purposefully leave off the “paid to ICANN” part as that is a separate policy question I think. I don’t think we need to assume that the money would go to ICANN: * as that did not go so well the first time, and * we should consider what a “cost neutral” application process really means. If we think the process should be cost neutral to ICANN, then I think / suppose that placing the auction funds aside in a foundation of sorts would satisfy the neutrality requirement. (Although, the lie might have been put to that when ICANN replenished its reserve out of the auction funds.) If we think the process should be cost neutral to ICANN AND the applicants, then should not the money go back to the applicants in some way? Isn’t that truly cost neutral? Additionally, as a question of policy, maybe the money can be placed in some more effective foundation than one that is taking years to establish. I think these are policy choices for us. Finally, to me it seems that Vickrey is probably preferable to a highest price auction but, as I said in an earlier email, it is a complex economics issue. For example, can the Vickrey scheme be gamed in someway where there are well-off and not-well-off applicants? Or does the Vickrey scheme tend to defeat that gaming? We should tell ICANN what our policy goals are for this and ask them to figure it out in implementation, which will be reviewed by the community. Whew, sorry, Kurt On Dec 12, 2019, at 11:56 AM, Dorrain, Kristine <dorraink(a)amazon.com<mailto:dorraink@amazon.com>> wrote: I fully support Paul’s choice model and have added a few more pros and cons to the table. In the interest of equity, I even included a “pro” in the ICANN Auction of Last Resort category because I know some folks on here believe there is a hypothetical problem with “applicants being paid to lose.” The Auction of Last Resort can be effective against any perception that this might be a problem because applicants must ALL agree to any other mechanism. I generally support Kurt’s additions, with a few questions/suggestions in red. I’m going to be late for the call that starts shortly… Kristine From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Kurt Pritz Sent: Thursday, December 12, 2019 11:35 AM To: McGrady, Paul D. <PMcGrady(a)taftlaw.com<mailto:PMcGrady@taftlaw.com>> Cc: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 I think the table is a great idea. If it helps clarify the discussion, under ‘Auction Type,’ I think the options could be: Sealed Bid - winner pays highest price bid to ICANN (why would the winner not pay the second highest price…did I miss something? I think this option is more about timing, not any other change to the Vickrey model) Sealed Bid - Vickrey (winner pays second highest price bid to ICANN) Ascending auctions (paid to ICANN) - similar to the previous round Private resolution (fully private...notably, participants could self-select a sealed bid auction as their private auction mechanism of choice) Additionally, under ‘Auction Type’ or ‘Auction Timing' as a separate table the options would be: (I do like the idea of making this clear in the chart) Timing - bids submitted at time of TLD application Timing - bids submitted at near time of TLD award (after evaluation, clearing of objectionsetc) I think breaking it out this way would make the identification of strengths and weaknesses easier and clearer. Best regards, Kurt On Dec 10, 2019, at 2:25 PM, McGrady, Paul D. <PMcGrady(a)taftlaw.com<mailto:PMcGrady@taftlaw.com>> wrote: Hi All! I have really enjoyed the conversation on the calls and on this list regarding auctions. It is a great reminder of how rich in talent our community is. Below I have summarized some of the pros and cons of each process discussed (these are not meant to be exhaustive or dismissive, just my own thoughts which I encourage others to supplement). I’ve also proposed a possible way forward that could disrupt the current default status quo (ICANN Last Resort auction found in 2012 AGB, but which in my opinion is based on the false premise that ICANN “owns” all the undelegated gTLD space) but not force everyone into a one-sized-fits-all solution. I hope that the below encourages communication and helps us reach a consensus position that everyone in the WG can stand behind. Auction Type Strengths Weaknesses Vickrey (place maximum bid amount at the time application is filed) • Straightforward. • Eliminates significant delays caused by contention sets. • Favors single TLD applicants. • Favors deep pockets. • Bad for .brand applicants who could end up paying significantly more • Enriches ICANN (which has never justified why it thinks it “owns” the undelegated TLD resource). • Assumes no changes in the round/procedures/ other circumstances between filing of the application and the auction. • Assumes money is the only way to solve a contention. Modified Vickrey (place maximum bid amount at the time contention sets are formed) • Straightforward. • Eliminates much of the delay caused by contention sets • Eliminates ICANN Last Resort auctions. • Allows multiple TLD applicants to use resources more efficiently. • Favors deep pockets. • Enriches ICANN (which has never justified why it thinks it “owns” the undelegated TLD resource). • Assumes money is the only way to solve a contention. Private Resolution (could be dollar amounts, acquisitions, other consideration, etc.) • Allows for full creativity to resolve contention sets. • Doesn’t enrich ICANN (which has never justified why it thinks it “owns” the undelegated TLD resource). • The parties may agree on an auction process to resolve the contention set or they may agree instead to negotiate toward a mutually rewarding outcome. • There have been rumors of gaming in the last round. • Favors deep pockets.Amend to say: may favor deep pockets…private resolutions do not require the expenditure of ANY cash. ICANN Last Resort (status quo from 2012 AGB) None. • No applicant “gets paid to lose.” • Favors deep pockets. • Enriches ICANN (which has never justified why it thinks it “owns” the undelegated TLD resource). A possible way forward: Choice. Let each applicant choose how they would like to proceed. If all of the other members in the contention set make the same choice, that is the method that will be used. If, however, the members of the contention set do not agree, then ICANN Last Resort (status quo) will be default. There is no harm to the pro-Vickrey applicants in this option since whatever dollar amount they designated in their applications can, if they so choose, become their maximum dollar amount in an ICANN Last Resort if need be. Since an applicant submitting a Vickrey auction preference might be compromised in an ICANN Last Resort, the maximum dollar amount they are prepared to spend should be lodged with a third party under strict confidentiality obligations, e.g. with one of the large accounting firms. The same is true for the pro-Modified Vickrey applicants. Whatever maximum dollar amount that they would have bid once contention sets were finalized can become their maximum bid in an ICANN Last Resort if need be. Likewise, if an applicants selected Private Resolution and the other member(s) of the contention set did not, they would simply bid in the ICANN Last Resort whatever they were prepared to pay in a private auction. Because Private Resolution opens up the door to creative problem solving between members of a contention set, the applicants in that contention set should be allowed to select – after contention sets are formed – to try Private Resolution. Such a selection should be unanimous and if it doesn’t lead to resolution (e.g. negotiations are attempted and fail instead of the parties using a private auction), then the ICANN Last Resort option would kick in. I hope the above is helpful and moves us a bit closer to a consensus position. Thanks. Best, Paul 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(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Justine Chew Sent: Monday, December 9, 2019 6:49 PM To: Austin, Donna <Donna.Austin(a)team.neustar<mailto:Donna.Austin@team.neustar>> Cc: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Thank you, Donna, for picking this up. Just in relation to Goal No. 1, on reflection, I think the text "...in which the winner ultimately overpays for the TLD" should be omitted or reworded, firstly as Donna has explained, we don't know what "overpays" actually means. Secondly, even if that is the case, why should we be concerned if an applicant chooses to "overpay". Thirdly, At-Large's concerns had to do with the situation of wealthier applicants outbidding less-wealthy applicants, thereby potentially stifling competition. So, perhaps the goal should be re-stated as "Reduce the risk of unintended outcomes from “bidding wars". As for the remaining texts, I would like to be able to review the flowcharts for the 3 Alternatives before making further comments. Thanks, Justine Chew ----- On Sat, 7 Dec 2019 at 04:57, Austin, Donna via Gnso-newgtld-wg <gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>> wrote: Thanks for the notes Julie, these are particularly helpful as I wasn’t able to attend the call. I have listened to the recording and I wanted to address a couple of issues that were discussed and are captured in your notes. I don’t agree that Alternative 1 addresses the following goal: 1. Reduce the risk of “bidding wars” in which the winner ultimately overpays for the TLD. a. Tentative, related goal for discussion: encourage applicants to bid their true value for a TLD. I personally struggle with this as a goal because it’s a subjective assessment that applicants from 2012 overpaid for a TLD. Only the successful applicant can make that judgement and if the applicant willingly entered into a private or ICANN auction of last resort they didn’t do so blindly: they had an opportunity to assess the market and combined with their own personal objectives for wanting a string made a judgement about how much they were willing to pay for the string. As I noted previously, my main issue with Alternative 1 is that the sealed bid has to be provided at the time of application, which is unfair to any applicant that ultimately finds themselves in a contention set. No-one can predict how many applications will be received and how many strings will end up in a contention set so the applicant has no information available at the time of submitting their application on which to assess the value of the TLD to them. It would be eminently fairer to all applicants to submit sealed bids at a time when more information is available that would allow them to make a more informed decision about the value of the TLD to them, which is ultimately why I proposed Alternative 2 originally. Donna Donna Austin Neustar, Inc. / Senior Policy Manager, Registry Solutions Mobile: +1 310 890 9655 donna.austin(a)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 Julie Hedlund Sent: Monday, December 02, 2019 8:52 AM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019 Dear Working Group members, Please see below the notes from the meeting on 02 December 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-12-02+New+gTLD+Subsequent+Pr…<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_di…>. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: ACTION ITEM 1: Add a third alternative. ACTION ITEM 2: Add another goal (#7): “Increase efficiencies in application evaluation by way of understanding the contention set?” ACTION ITEM 3: Create a flow chart with a fictional string to show how alternative 1 would work. ACTION ITEM 4: Update the list of goals. Notes: 1. Review Agenda/Statements of Interest: Susan Payne was reappointed IPC Secretary for another year. 2. String Contention Mechanisms of Last Resort:https://docs.google.com/document/d/16qDoiK6vydQp6a0v9tMvU2l5fcypJY24… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> What is the issue we are trying to address: -- The Working Group has discussed a number of potential issues with the mechanisms of last resort used in the 2012 New gTLD Round. These issues are captured in the Supplemental Initial Report. -- Although the Working Group ultimately believes that when there is string contention, an auction process should be used to select the Registry Operator invited to enter into a Registry Agreement with ICANN, the Working Group is still discussing what forms of private resolution should be allowed (if any), the specific type of auction to be used, and the timing of such an auction. Policy Goals / What the WG is Seeking to Accomplish: -- The WG is largely supportive of existing Implementation Guideline F: Implementation Guideline F: If there is contention for strings, applicants may: i) resolve contention between them within a pre-established timeframe ii) if there is no mutual agreement, a claim to support a community by one party will be a reason to award priority to that application. If there is no such claim, and no mutual agreement a process will be put in place to enable efficient resolution of contention and; iii) the ICANN Board may be used to make a final decision, using advice from staff and expert panels. Other goals include: 1. Reduce the risk of “bidding wars” in which the winner ultimately overpays for the TLD. * Tentative, related goal for discussion: encourage applicants to bid their true value for a TLD. 1. Reduce collusion, profiteering, and/or speculation, especially as it relates to financial transactions external to the program (Note, while this is not an explicit goal for the mechanisms of last resort, it has been discussed as a motivation for altering the auction mechanism). 2. Increase transparency. 3. Resolve contention more quickly. 4. Increase predictability. 5. Encourage new entrants into the field. b. Which could include, making it easier to implement “multipliers” for certain types of applicants, such as those eligible for Applicant Support. -- Note that some of the terminology may need to be further defined if the above goals are adopted. In order to ensure that recommendations align with goals, it is important for the Working Group to agree on specific objectives. Discussion: -- Do we still need iii)? An alternative may be, "The ICANN Board may use expert panels to make Community Priority Evaluation determinations." This may also be dependent on recommendations on the new appeals mechanism. -- ICANN Board says it does not make policy. Its decision would be subject to RFR and IRP - very messy so it may be better to stick with what we developed earlier. -- This isn’t about the Board making policy, but making it clear that it’s an auction process rather than the Board making a decision. -- There should be a reference instead to Auction of last resort. -- Agree they are good goals so suggest removing possible description What are we Proposing? -- The Working Group is leaning towards recommending a sealed-bid auction as the ultimate form of auction used as a mechanism to resolve string contention. When a sealed-bid auction is held where bids are submitted without knowing the bid of others in the auction (e.g., prior to evaluating any of the applications) it is also called a Vickrey Auction. A sealed-bid auction can also be used as a mechanism of last resort and at the end of the process. -- With a sealed-bid auction, each applicant submits a sealed bid, stating the amount that they are willing to pay for the TLD. The ultimate “winner” pays the amount submitted by the second-highest bidder.. -- Regardless of when the sealed bid auction is held, if there are one or more Community-based Applications, that/those application(s) would need to be processed first through Community Priority Evaluation before looking at the auction bids. Alternative 1 - Vickrey Auction (No Private Resolution) -- Addresses goals 1, 2, 4, and 6. -- The principle pro here is the seemingly near elimination of private resolution. However, the principle con is the substantial complications this approach introduces (see Additional Considerations, Mostly For Alternative 1 below). Other cons are that other forms of private resolution might be impacted (e.g., joint ventures, string change, etc.) in seeking to eliminate private resolution for financial benefit and that bids are submitted with no contextual information. Alternative 2 - Sealed-Bid Auction allowing Private Resolution -- It seems to be supportive of, or at least not impede, 1, 2, and 6, but in a less pronounced manner as it relates to Alternative 1; the maker of this Alternative has acknowledged that it does not fully address concerns around potential collusion and profiteering on application withdrawals. -- However, some benefits are likely derived by obtaining sealed bids (which can reduce the incentive for all parties to agree to private resolution, if an applicant already knows they have the highest bid). The other main pro here is simplicity - most other processes remain unaffected. Discussion: -- Re: Alternative 2: First bullet point and third bullet point seem incompatible. Third bullet point: “Applicants would still have an opportunity to resolve the contention set through other means such as private auction, a joint venture arrangement or to choose another string as was suggested for ‘brands’ of the same name.” -- Assuming you stayed in only those applicants who stayed in would be revealed on reveal day. So you could still have private resolution. -- For clarity, the third bullet could be swapped with the fourth bullet and add “post reveal day”. In third bullet point, after "opportunity", you would need to insert "after reveal day" or something to clarify that parties become known. -- Question: Wasn’t one of the proposals to outlaw private auctions? So not sure why we are still allowing private resolution. Answer: If we went with alternative 1 we would eliminate private resolution, but not for alternative 2. So that is one of the drawbacks with alternative 2. -- Thought alternative 2 was to allow participants to know how many contention sets there are. Add as a third alternative: Alternative three could remove some of the elements about private resolution. -- They may not resolve privately and should only have a limited period to resolve. If not resolved in a limited period, it should proceed to the sealed bid winner. I am not seeing the time limit in alternative 2 though. Is it there? -- Question: How would the timing work with a string contention objection process? -- How could private auctions be prevented? -- Objections should not be triggered until a winner (or a private resolution winner) is identified. -- Re: Alternative 2 there should be a limited time for private resolution. -- Helpful to put these alternatives out for public comment and indicate whether the WG has a preference. -- Re: Alternative 2 -- Question: For string confusion objections those would have to be heard right away. Additional Considerations: Public Comment: Comments from the public are solicited on all applications regardless of where they are placed in the queue. To do it otherwise would mean opening up separate public comment periods depending on whether there is a need to go to the second bidder, and that would be impossible to monitor. Discussion: -- Strongly support 1 public comment period, for the exact same length of time for all. -- Impractical to have multiple public comments. String Similarity Evaluation: Discussion: -- Don’t see how this fits with the notion of closed bids and timing. You have a scenario where you have some who know who they are bidding against and everyone else doesn’t. -- In the scenario where the result of a string similarity evaluation is that some would have insight into who is in the set -- this is an unfair result. -- Which is why getting every applicant to submit a bid at the point of application is something to consider, even though it may be cumbersome for many. -- What if this fact situation should default to sealed bid only? -- Why would they not be all announced at the same time? -- So we are proposing to treat some applicants differently from others? That does not seem to be in line with the Bylaws. -- Wouldn’t alternative 1 solve this issue? -- What about plurals? -- There was only one case in 2012 that was found to be similar (unicorn/unicom). -- Why string similarity evaluation after reveal day? Why not make it before reveal day? That is a possibility. -- is string similarity not subject to accountability mechanisms and appeals? would that not “reveal” it in some manner? -- Agree with that suggestion re string similarity evaluation occurring first and before reveal day. bids would have to be in before appeal. Objections: Objections on the highest bidder’s application must be filed within the objection period. With respect to objections to the other applications, ICANN would create a system for the filing of “an intent to file an objection.” Discussion: -- Question: What happens when someone indicates that they are filing a community objection and they are filing it against all of the applicants for a string. Answer: All applicants should have a chance to respond. Add text to relay your comment on "can indicate that an objection will apply to all applications for same string"?  -- Objections should not come into full proceedings unless and until there is a winner - it's a huge waste of time and money if it does proceed but private parties need to know what the value of the string may be. -- Some concern about not having to submit the objections on a standard timeline, although support not engaging fees or panels until the objection is necessary, based on bidder ordering . -- “time” may benefit some as they build their case. Or could the “intent to file” require some key points that will be included in the objection filing? -- Question: We are agreeing on the principle that the intent to object is a good idea, but when would that happen? Would one party have to state the type of objection and the grounds? Could it just be a party filing very general intent to objection concerning a risk associated with that application. Would there be a panel for an intent to object process? Answer: Proposal was that the objection would be “bare bones”. There would be no panel if it was just an intent to object to one application, but if for all applications (to the string) then one could request a panel. You file your objection against the applicant first in the queue and an intent to file against the others in the queue. Or, you could say I have the same objection to all of the applicants/string. -- Important for private parties in resolution to know that there is an intent to object (but that doesn’t pertain to alternative 1 as there is no private resolution). -- The objection should be submitted within a certain time period. -- The nature of the applicant is important. It's not just the existence of the string. It depends on who is operating it and what the purpose of the tld as stated in the application in Question 18 answers and services to be provided in answer to Question 23. There should be an intent to object process prior to determining the order of the queue with no panel convened. Other complications: Objections if there is more than one Community Application String Confusion Objection Results in the Creation of a New Contention Set or Adds to an Existing Contention Set Appeals/Accountability Mechanisms Applicant Support Program Discussion: -- Seems that these are all related to the attempt to gain efficiencies to know the order of the contention sets. If you don’t need to know the order then you could leave the program untouched. If you go back to the goals knowing the order of the contention sets goes to goals 3, 4, and 5. -- Add a goal: “Increase efficiencies in application evaluation by way of understanding the contention set?” -- Note that alternative 1 would eliminate the goal to allow contention resolution. “If there is contention for strings, applicants may: i) resolve contention between them within a pre-established timeframe” _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg(a)icann.org<mailto: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(a)icann.org<mailto: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 0

Post call / New gTLD Subsequent Procedures Working Group call / Monday, 16 December 2019 at 20:00 UTC
by Julie Bisland 16 Dec '19

16 Dec '19

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Monday, 16 December 2019 at 20:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/5ZYzBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards, Julie

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 16 December 2019
by Julie Hedlund 16 Dec '19

16 Dec '19

Dear Working Group members, Please see below the notes from the meeting on 16 December 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-12-16+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: ACTION ITEM 1: See if we think there are any variations in the rules for the SPIRT and the rules for the IRT and spell them out. ACTION ITEM 2: Adjust the language in Jeff’s proposal -- The SPIRT makes a recommendation to the Council, and then the Council has 30 days to decide either to take it up as a full issue or by default or affirmation, or if only one Councilor asks to consider the recommendation more fully, then the Council would be given a certain number of meetings to make its decision. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Predictability Framework: https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecG… -- The way to make progress is to address some of the specific questions in the latter part of the paper. Role of the SPIRT & GNSO policy change process in change control: -- SPIRT should begin after the publication of the final AGB. -- Constituted in advance if possible and follow the IRT Principles and Guidelines document. -- The SPIRT can review any potential change before it is made to determine which of the categories delineated above are relevant to the change. -- It is also the group that can raise any issues of policy-implementation conflict to the GNSO Council for further discussion and possible uses of for example, the EPDP or the GNSO Guidance Process. Discussion: -- Question Re: Constituted in advance “to the extent possible and applicable and follow the IRT Principles and Guidelines” -- suggests that they might not follow the Principles and Guidelines? Answer: It might be that not every principle will apply. There are some rules of an IRT that are not intended to apply to a standing IRT. We can say they can use it as a guide, but if we make it a mandate not everything will fit in. Question: What would prevent the SPIRT from going off in a different direction that was not anticipated. Answer: Why not say “the IRT should develop the exact rules for the SPIRT based on the IRT Principles and Guidelines document.” What if we put in a note that we are not being prescriptive but we recommend that there are rules in place before the SPIRT begins work. Take out “if applicable”. Say, “...should apply to the greatest extent possible.” Role of the SPIRT -- What decision-making authority does the SPIRT have, if any? All “decisions” are advisory in nature and intended to serve as guidance for ICANN staff as well as the GNSO Council and community. -- When must the GNSO Council be consulted? SPIRT will submit its advice/recommendations to the GNSO Council who maintains a supervisory role. The GNSO Council should employ processes and procedures to consider the SPIRT recommendations as expeditiously as possible. -- Ultimately the GNSO Council can choose to accept the recommendations of the SPIRT or reject them by letting the SPIRT know of its decision, rationale and proposed next steps. -- Proposal from Jeff: We could state that unless the Council objects to the advice/recommendation within a certain period of time it is deemed accepted without a formal approval. We could also state that if there is a threshold of Councilors that would like to consider the advice more in depth and require an express approval or rejection vote of the Council, then it can do so. -- If we did that, what would be that threshold? One Councilor or some %? [Remember, we are going for efficiency] Discussion: -- Don’t ask the IRT to define the SPIRT role. -- IRT should not be filing in "holes". No way can we or the IRT anticipate all situations. If situations arise that don't fit the IRT rules as applied to SPIRT, the GNSO Council must weigh in. Too many layers +delay. The SPIRT just acts as an IRT after the applications come in, so not sure why there is a need for the IRT should deliberate on what the SPIRT should do. Once you constitute the SPIRT it just acts like an IRT. There doesn’t need to be another layer. -- All the roles should be settled by the time the SPIRT is formed. -- We could do a gap analysis of how we think the SPIRT is different from a standard IRT. -- It's easier to just say that if SPIRT wants to deviate from IRT rules (other than its standing status), it must review that with GNSO Council as Greg proposed. -- Accepted unless rejected within a certain period of time is pretty scary. We would be inviting filibuster at the Council table. -- All voting can be done by e-mail, but requires both discussion and prior notice. So it's not as quick. -- Limit Council deliberation to 2 meetings. -- The problem is the substantive changes after the AGB is published. -- There could be an issue if this rule is introduced as to which process is being followed because it only takes one Councilor to raise an issue under the Input, Guidance, and EPDP process. ACTION: See if we think there are any variations in the rules for the SPIRT and the rules for the IRT and spell them out. ACTION: Adjust the language in Jeff’s proposal -- The SPIRT makes a recommendation to the Council, and then the Council has 30 days to decide either to take it up as a full issue or by default or affirmation, or if only one Councilor asks to consider the recommendation more fully, then the Council would be given a certain number of meetings to make its decision. Composition of the SPIRT: Discussion: -- I think the community organizations (such as the SOs and ACs) should have members on the SPIRT. -- IRT rules note that re: composition the IRT should be open but may not be representative of the community depending on level of interest. -- Just note that CPIF already has a provision re technical expertise on IRT and IRT rules apply. Question: Are you saying that a technical expert may not be a standing member and may need to be added? Answer: We could create a standing slot for an expert, or say that when necessary the SPIRT would reach out to experts. -- Then just say that you add an expert - doesn't change the fact that the SPIRT should be representative of the community. -- Re: Notion of an IRT being open; SPIRT could have nominated members rather than a completely open team seems to contrast with a notion of a standing panel. -- See for an ordinary IRT the limitation to topic expertise makes sense (to me at least) but for SPIRIT the engagement should be perhaps wide, inclusive and specific in design (yet allow flexibility for the AC/SOs). -- The issue about appointed representatives is a significant one. -- I think we should look to the Customer Standing Committee composition for a good example— four “expert” members and liaisons from all AC/SOs. 2 year appointment so that there is consistency and corporate memory. -- So the question could then be if the participation should be “obligatory”? -- Re: the principle of efficiency and size -- if your goal is to have a standing group that can take an issue and make a recommendation relatively quickly, then looking at the IRT composition doesn’t exactly fit. -- The narrow scope of the CSC is also testament to its success, so clearly articulating the scope of the SPIRT is also important. -- Yes SPIRIT needs balance and/or the ability for inclusion of all interested parties but still limited in size as such. -- The CSC is by nature a narrowly focused, technically oriented, group aimed at the functioning of IANA. It doesn’t get into policy debates. So it is easy to define what types of expertise are needed. Unless we have a very narrow scope for the SPIRT the CSC structure won’t work. -- I don't think we are saying that the group should be the same composition. I think we are saying it should be a closed group (whatever the composition), and one where people are appointed for a good period of time (for continuity).  -- On the other hand, we have to look at the balance between not taking too long time to get a result and properly represented. -- Staff should also be members of the SPIRT, as they are also potential experts for changes being requested from other parts of the community. I think you can draw parallels from the CSC. Or staff could be in a supporting role. -- Question: Are there requirements for IRT participants to have participated in the PDP or other policy processes? -- Are we getting confused between those who implement and those who review implementation? -- Agree on the scope and then we can argue about the membership of the SPIRT. Because this will be a standing panel, its realistic to think that members will swap in and out depending on the change under discussion. -- You need more than one person with the PDP WG background. If there is only ONE member, there are no checks and balances on that one member's interpretation of what happened in the policy-making process. -- Given that timeline, the SPIRT should certainly have members of the IRT, even if somehow the WG members all fade away by that time… Length of the Term of SPIRT members? Proposal from Jeff: Given that the role of the SPIRT is intended to be a Standing Committee, I would recommend a term of 2 years unless replaced by that particular group that put the person on the SPIRT Team. I did not believe there is a need for a term limit, but what do others think? -- Leave it to the appointing group. -- Don’t have to be so prescriptive. -- Don’t need to set a term limit -- let the appointing group decide. Role of the SPIRT member (representative vs independent judgment) -- If the group is “representative” of the community, what should the role of the IRT member(s) be? Should theyiet be acting in a “representative capacity” or should they be required to exercise independent judgement? [Jeff’s Proposal is that they exercise independent judgment. If the group that put them there is not satisfied with that person’s activities, they can always replace them through their own internal processes?] -- Independent is okay. As a practical matter, trying to find one representative for the GNSO isn’t possible. -- Even if every group in ICANN could appoint someone it would be virtually impossible for them to be representative. -- Think about the multi-stakeholder balance -- We are saying that the person who comes from that community should exercise independent judgment. But would think it would be up to the appointing organization to decide how the member should be accountable. -- Some appointing bodies may have specific rules or requirements. Conflicts of Interest: SPIRT members must complete a Statement of Interest, which are subject to periodic review. In some circumstances, where an issue has a specific effect on a member of the SPIRT, that member may want to recuse themselves from consideration of that issue. [Jeff: Perhaps an expanded SOI akin to that of the Name Collision Project] -- Makes sense. -- More detailed SOI tailored to SPIRT team. -- Realize that there will be members that will be conflicted but it shouldn’t preclude them from participating. -- Declaration as applicant is good, perhaps just to also mention inclusion of relevant (PDP) experience. -- Just has to be a known as opposed to Unknown set of issues. -- Perhaps, there should be a restriction on participation that there should only be one person representing an organisation, for example Neustar could only have one employee on the SPIRT. Confidentiality obligations: Absent extraordinary circumstances, all proceedings of the SPIRT shall be open, recorded, transcribed, and publicly available. ICANN Staff role and level of participation: Should ICANN’s role in this process be akin to their participation in IRTs? As ICANN Org may surface an issue itself, and should ICANN Org utilize/wield the Predictability Framework where applicable. -- Another inconsistency with the IRT guidelines. Decision-making process: -- Consensus, Majority, or something else? -- Is there extra weight given to directly impacted parties similar to that currently given to contracted parties in their Agreements? -- Jeff: Propose Majority? Discussion: -- We don’t want the majority to rush things through, but unlike policy groups where you could have a majority but not consensus, in the SPIRT the group has to make a decision. -- Concerns about majority: can make decisions in a timely manner and the question is what is the standard for those decisions. Set a time limit. -- But SPIRT makes recommendations not decisions necessarily, right? -- I assume there will be a Chair of this group, would the Chair have the discretion to call it? -- Look at how the IRT makes decisions since SPIRT is supposed to be a standing IRT. IRTs in general do not have chairs.  IRTs are "chaired" if at all by GDD. -- SPIRT makes recommendations not decisions necessarily, plus there's oversight by GNSO Council. -- This all underscores the importance of 1 Councilor being able to bring the outcomes to Council. It really takes the fear out an abuse by a Chair or an obstinate member of the Spirit. -- The IRT guidelines point to the decision-making process in the WG Guidelines. Discuss on the List: Role of Public Comment? Jeff Proposal: Recommendations are advisory in nature and therefore public comment may not be necessary on the recommendations. GNSO Council has oversight. ALAC: Response to question - Believes additional consideration is needed about whether all operational changes should be subject to public comment. Fundamental/possible policy impact changes must always go through a GNSO procedure.

1 0

Re: [Gnso-newgtld-wg] FW: ALAC Input on Scope of Upcoming New gTLDs Subsequent Procedures PDP WG Public Comment
by Vanda Scartezini 16 Dec '19

16 Dec '19

Dear colleagues Though I agree with ALAC’s position to make public understand easily all propositions, the feedback from public comment will be checked against the majority of WG own position and it will be clear for us, that have been exhausting debating about these propositions, which to select. I believe open up will not make more complex our final deliberation. I am not able to attend all call due to a busy schedule conflicts but I am following all the transcripts. I apologize for this absence. Let me use the opportunity to wish you all a happy and peaceful holidays and a successful 2020! Kisses to all Vanda Scartezini Polo Consultores Associados Av. Paulista 1159, cj 1004 01311-200- Sao Paulo, SP, Brazil Land Line: +55 11 3266.6253 Mobile: + 55 11 98181.1464 Sorry for any typos. From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Jeff Neuman <jeff.neuman(a)comlaude.com> Date: Monday, December 16, 2019 at 06:04 To: Gnso-newgtld-wg <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] FW: ALAC Input on Scope of Upcoming New gTLDs Subsequent Procedures PDP WG Public Comment FYI. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: ICANN At-Large Staff <staff(a)atlarge.icann.org> Sent: Monday, December 16, 2019 8:28 AM To: Jeff Neuman <jeff.neuman(a)comlaude.com>; langdonorr(a)gmail.com Cc: Maureen Hilyard <maureen.hilyard(a)gmail.com>; Justine Chew <justine.chew(a)gmail.com>; Manal Ismail <manal(a)tra.gov.eg>; Steve Chan <steve.chan(a)icann.org>; Julie Hedlund <julie.hedlund(a)icann.org>; Emily Barabas <emily.barabas(a)icann.org>; Evin Erdogdu <evin.erdogdu(a)icann.org>; ICANN At-Large Staff <staff(a)atlarge.icann.org> Subject: ALAC Input on Scope of Upcoming New gTLDs Subsequent Procedures PDP WG Public Comment Dear Cheryl and Jeff, Please find attached a letter from the ALAC Chair, Maureen Hilyard, regarding ALAC Input on Scope of Upcoming New gTLDs Subsequent Procedures PDP WG Public Comment. Thank you. Kind Regards, ICANN Policy Staff in support of the At-Large Community Website: atlarge.icann.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__atlarge.icann.org_&d=D…> Facebook: facebook.com/icannatlarge<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_icann…> Twitter: @ICANNAtLarge<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANNAtLar…> ________________________________ 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>

3 2

FW: ALAC Input on Scope of Upcoming New gTLDs Subsequent Procedures PDP WG Public Comment
by Jeff Neuman 16 Dec '19

16 Dec '19

FYI. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: ICANN At-Large Staff <staff(a)atlarge.icann.org> Sent: Monday, December 16, 2019 8:28 AM To: Jeff Neuman <jeff.neuman(a)comlaude.com>; langdonorr(a)gmail.com Cc: Maureen Hilyard <maureen.hilyard(a)gmail.com>; Justine Chew <justine.chew(a)gmail.com>; Manal Ismail <manal(a)tra.gov.eg>; Steve Chan <steve.chan(a)icann.org>; Julie Hedlund <julie.hedlund(a)icann.org>; Emily Barabas <emily.barabas(a)icann.org>; Evin Erdogdu <evin.erdogdu(a)icann.org>; ICANN At-Large Staff <staff(a)atlarge.icann.org> Subject: ALAC Input on Scope of Upcoming New gTLDs Subsequent Procedures PDP WG Public Comment Dear Cheryl and Jeff, Please find attached a letter from the ALAC Chair, Maureen Hilyard, regarding ALAC Input on Scope of Upcoming New gTLDs Subsequent Procedures PDP WG Public Comment. Thank you. Kind Regards, ICANN Policy Staff in support of the At-Large Community Website: atlarge.icann.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__atlarge.icann.org_&d=D…> Facebook: facebook.com/icannatlarge<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_icann…> Twitter: @ICANNAtLarge<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANNAtLar…> ________________________________ 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>

2 1

Post call / New gTLD Subsequent Procedures Working Group call / Thursday, 12 December 2019 at 20:00 UTC
by Julie Bisland 13 Dec '19

13 Dec '19

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 12 December 2019 at 20:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/45YzBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards, Julie

1 0

Re: [Gnso-newgtld-wg] Predictability Framework with some examples
by Jeff Neuman 13 Dec '19

13 Dec '19

Thanks Donna. I don't have the power to reject any proposal, so everything from Anne below is on the table and I was just offering my thoughts. My concern however is even reflected in your language, "It may be possible for the Council to come up with a mechanism". That introduces even more variables outside the control of our group and provides yet even more uncertainty about potential delays. Plus, if one of the key roles for the SPIRT is to provide advice/recommendations to the Council as to whether they believe an issue amounts to a policy/implementation or execution change, and their advice/recommendations will be subject to review of the Council anyway, then what is the potential downside of having the issues from the Board/staff go to this new standing committee established with the expertise to handle precisely these types of situations. The second concern I personally have is that we have been increasing the role of Council incredibly over the years. Initially, there role was strictly as managers of the policy process. Now with the new Empowered Community, they have been given additional responsibilities. To give the Council the first right to deal with these types of things would now introduce even more importance to serving on the Council and finding expertise even more expertise in this new area. Giving the Council oversight over issues and the work of this group makes complete sense. Bringing these issues directly to the Council, when they most likely will not involve "policy" per se, as opposed to directly to a group that has the requisite expertise (technically, operationally and policy-wise on the new gTLD Program) does not seem to make the most sense to me especially if the GNSO Council does retain oversight authority. Lets run through some examples (and assume for these that the AGB did not already account for how these changes would be made): Caveat: I am making all of the following up for illustrative purposes. Lets not get bogged down is why ICANN may actually want to recommend doing the following things. Some of them may not be realistic, but they are provided as examples to see how we would deal with this. Ex. 1 ICANN receives 10,000 applications when it only planned for 2,000 and as a result would like to do the following: * Add another provider for providing evaluation services of the applications; * Change the back-end system for public comment but has same functionality * Change the timelines for completing initial evaluation from what was in the AGB; * Change the mechanism for batching the applications by stating that they will now review all applications that have self designated as community applications before other applications; * Cut off the number of applications at 5,000 and push the remaining 5,000 applications to the next round; Ex 2: Completely unrelated to the first example, the ICANN Board wants to add provisions into the new gTLD Registry Agreement to require all new gTLD Registries to now verify that all registrants are who they say they are and that they have a legal right to a registration in any new gTLD. For Example 1: In my mind (personally speaking), a, b and c are modifications of ICANN's internally processing systems. 1. seemingly should be able to be done without any consultation with a SPIRT, but with just notice to the community 2. there should be some consultation with the SPIRT to verify that the new system really would not have an impact on the functionality and if so the SPIRT would recommend that ICANN just be allowed to make the change. If it would have an impact on the applicants, it could recommend that notice go out to the community about the change and solicit comment. The SPIRT could then review the comments with ICANN staff and make recommendations on how that new system should be implemented. Of course the GNSO would have oversight and could if it wanted choose to use one of its own processes to deal with the proposal. Sending this to the GNSO Council first before the SPIRT team would (n my mind) just add unnecessary delay and the Councilors presumably are not equipped to evaluation this type of change. To wait a period of time just for the Council to ultimately send it to the SPIRT would not make sense in my mind. 3. Changing the timelines is a little trickier, but it would seem that this could go to the SPIRT to discuss the potential ramifications and whether the AGB already had a mechanism in there to handle this. They could then recommend to the GNSO Council whether they thought the ICANN proposal was consistent or inconsistent with the AGB and if inconsistent could send a recommendation to the GNSO council on a proposed process forward on how process further (eg., should there just be an opportunity for the public to comment or should it go through a GNSO process). For examples (d) and (e), these are more significant changes. Arguably (d) should go to the SPIRT to recommend whether they believe this is something that is consistent with (or inconsistent) with the AGB and if inconsistent should then send a recommendation to the GNSO Council on how they believe this proposal should be dealt with. The GNSO Council would then get those recommendations and figure out how to process. (e) would seemingly be inconsistent with the AGB and should go straight to the GNSO Council to initiate one of its processes. In my mind this would not be the type of change that the SPIRT team would be equipped to handle and would involve such a large number of changes, that going to the SPIRT team would not serve a purpose. For Example 2 above (changing the Registry Agreement), this too would be of such huge policy significance that it should go directly to the GNSO Council for it to process and figure out how that request should be handled. No referral to the SPIRT team would be necessary. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Austin, Donna <Donna.Austin(a)team.neustar> Sent: Thursday, December 12, 2019 10:04 PM To: Jeff Neuman <jeff.neuman(a)comlaude.com>; Aikman-Scalese, Anne <AAikman(a)lrrc.com>; gnso-newgtld-wg(a)icann.org Subject: RE: Predictability Framework Jeff, I don't think it really matters which way you slice this process they will all create the potential for delays. The line between policy and implementation is very vague which is why I think it makes more sense to have the Council consider the question first rather, because they are the experts on this particular question, as opposed to the SPIRT. I like Anne's suggestion about how to consider requests from the Board, community vs ICANN org staff and we should think about that some more. It may be possible for the Council to come up with a mechanism that would respond to concerns about delay and make the consideration process more streamlined. So I don't think we should reject any suggestion outright at this point and encourage others from the working group to contribute to the discussion. Donna From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org] On Behalf Of Jeff Neuman Sent: Thursday, December 12, 2019 1:52 PM To: Aikman-Scalese, Anne <AAikman(a)lrrc.com<mailto:AAikman@lrrc.com>>; gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Predictability Framework [cid:image001.gif@01D5B198.C08589A0] Thanks Anne. I do disagree with this and probably didn't do well explaining why, but I will try again. The GNSO Council is not intended as a body that can take quick actions. It is not as if the GNSO Council Chair can get a request and use her or his discretion to forward it to the SPIRT Team. The Council Chair would have to send it to the rest of the Council. Then the Council does not have a process where it can approve the forwarding of the request to the SPIRT team immediately. It would have to take that action at a meeting. And if the request does not come in within 14 days before a meeting (I may have the number of days wrong), then it cannot be dealt with at that next meeting, but has to be dealt with at the following one or a newly set up extraordinary meeting (which could be up to 40+ days after the request comes in). Then, if the SPIRT team is just going to discuss and recommend that it is a policy level change and must be dealt with through the GNSO anyway. So, that process could take at least another 30 days to send it back from where it came. So, in total now, you could have up to 70 days just to get to the point of sending back the request to the body that initially had the quest. That is a VERY long time if the request is urgent. We have to think of the gTLD Program like a business. It needs to move efficiently. If something is clearly policy on its face, then it should go straight to the GNSO to deal with. But most things are never that clear. And sending it directly to the SPIRT to get its thoughts and recommendations to help the Council and Community is essentially. The Council can accept/reject those as it sees fit. Please look out for an email from me in next couple of days with a better explanation about why this is needed. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Aikman-Scalese, Anne <AAikman(a)lrrc.com<mailto:AAikman@lrrc.com>> Sent: Thursday, December 12, 2019 9:39 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Cc: Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>>; Steve Chan <steve.chan(a)icann.org<mailto:steve.chan@icann.org>>; Cheryl Langdon-Orr <langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>> Subject: Predictability Framework Hi all, I think Donna's suggestion to run through GNSO Council if request comes from Board or from Councilor FIRST to determine whether an issue is policy or is implementation and should be addressed by SPIRT makes perfect sense. (Jeff may disagree with this.) If issue is raised by staff, it should be reviewed by SPIRT and SPIRT should make a recommendation to GNSO Council as to whether it is policy or implementation. (Any Council member could challenge and invoke a process that is in the Annexes. This is true even if SPIRT treats the issue as implementation but someone on Council believes it is policy.) I still believe it may be prudent to limit requests to the SPIRT team on which it commences work to those coming from either (a) staff or from (b) GNSO Council. Community members can still give input to the Board, the GNSO Council, and/or staff. It's just chatter until a written request comes (a) From the Board to the GNSO Council and from GNSO Council to the SPIRT OR (b) from staff to the SPIRT with a recommendation from SPIRT to the GNSO Council. That would be my view of a possible compromise - not sure Jeff would agree. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman(a)lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@01D5B198.C08589A0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lrrc.com_&d=DwMFAw&c=MO…> [cid:image003.jpg@01D5B198.C08589A0] Because what matters to you, matters to us.(tm) ________________________________ 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. ________________________________ 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=DwMFAw&…> ________________________________ 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>

1 0