Dear Working Group members, Please see below the notes from the meeting on 23 June 2020 at ICANN68. 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://68.schedule.icann.org/meetings/xpMnL8W47Yk8sK5kF. Kind regards, Julie Notes and Action Items: 1. Topic 1: Private Resolutions, see attached slides and: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... Slide 11: Space for Compromise? (to aid in discussion): * In summary, the diverging interests appear to be: * Allowing applicants to creatively seek ways to resolve string contention. * Seeking to remove incentives for applicants to submit applications where there is no strong intent to operate the gTLD (e.g., incentives being, to leverage funds for other contention sets and/or financial benefit) Questions: * Assuming that incentivizing frivolous applications is bad for the program, how can creativity still be allowed/encouraged? * Are there program benefits to private auctions and other forms of private resolution (that are consistent with ICANN’s Commitments and Core Values)? Slide 12: Hybrid Proposal 2+: Primary goals of proposal: 1. Reducing incentives for submission of frivolous applications 2. Also, integrating agreed improvements to auctions: mechanism of last resort (i.e., single round, sealed bid auction). Key elements to achieve goal 1: * Add T&Cs against “Prohibited Application Activities” below: * Submitting applications for financial benefit * Resolving contention where non-winning applicants receive financial benefit to lose. * Incorporate mandatory contractual warranty/representation in RA that the Registry Operator did not participate in any of the Prohibited Application Activities. Slide 13: Amending Hybrid Proposal 2+: * Emphasis is on interest of reducing incentives for submission of frivolous applications. * The proposal allows for applicants to create partnerships and joint ventures. Can the support for the interest of creative contention resolution be increased in this proposal? Discussion: -- Are we all on the same page and agreed as to what constitutes a "frivolous" application? -- It's a subjective term that will no doubt be difficult to prove. -- Applying with no intent to actually operate the TLD is usually agreed to. -- The "assumption" that is baked into the question casts applications that had to be let go were retroactively "frivolous" -- Board concern was about applications that were filed without the intent to run a registry. We should address the Board’s concerns: 1) you can’t file an application without the intent to run a registry, and 2) can't file an application for the sole purpose of participating in a private auction. -- So, we should try to answer the questions but rather than focusing on whether an application is “frivolous”, since we don’t agree on what that is, or banning private auctions, we should focus on how to ensure that applicants do intend to operate a registry. -- Focus on how we can find the best candidates and not those with the deepest pockets. -- It seems we can agree that “frivolous” was not the right word to use. -- Also, we're not saying that anyone applied for the sole purpose of making money in the 2012 round, we don't believe that that was the case, but we think that there are applicants in future rounds that could try to do that. -- Suggestion for the use of a randomized draw – noting that the WG did discuss this idea, but there didn’t seem to be support for it. -- We've got the opportunity to put in place some guidelines or as Paul would say guardrails that help us from going down that path once again. -- We are overstating the likelihood of this problem. We should disincentivize it, not shut it down. -- Not sure how the guardrails would work – how can you be assured when an applicant says it will run the registry? -- This is a business decision – let the industry decide. -- Concerned that we are looking to develop policy when there isn't consensus on the intended outcome or motivation of that policy. Picking up on co-chair CLO's response to my question, that "there is considerable concerns being voiced", that tells me that we should try to nail this down before pushing forward. How are we to decide the mechanism if we are not sure what motivates the mechanism? -- The solution is not to ban the so-called private auction or any other private sector solution. The solution is to require applicants to affirmatively represent that they (1) have a bona fide intention to run any registry for which they apply; and (2) that they are not submitting the application for the sole purpose of participating in private auctions. -- This whole process is about ICANN distributing critical pieces of internet infrastructure with the public interest in mind. Full stop. It is not about: Enriching private parties through private auctions or making it easier for portfolio applicants to grab larger slices of the pie. After the .ORG dilemma, ICANN is on the radar in Sacramento, Washington, and Brussels to name a few. Do we as a community want to bring more heat by allowing what happened in 2012 to happen again? -- It's also important to keep in mind that in 2012, any applicant in a contention set could opt to go with ICANN's auction of last resort and many chose to do that. I am aware of a number of applicants, small businesses, who had applied for a string that ended in contention and much to their dismay could not even recoup their costs. -- Banning a particular mechanism isn't the solution. Let's build guardrails to deal with applications that are filed without a bona fide intent to run the registry if awarded and filed sole for the purpose of participating in private auctions. Solves the problem without resulting in ICANN interfering in the private market. -- Re bona fide intention - and to that point, in the trademark context we demand a bona fide/good faith intention to use the mark. This has been enforced/enforceable for a long time, even without being the most precise standard in the world. -- Would be ok to issue "office actions" / clarifying questions seeking to determine whether an applicant truly intends to operate the registry? -- Paul and Heather we're comparing bona fide intend to use to at least in the US system. To what you have to represent when you apply for a trademark and if trademark office if the US patent trademark office has any questions about that they issue what's called an office action and can try to get additional information from the applicant for the trademark. So they were making an analogy there. -- "Letting the market do its thing" requires market correction mechanisms to allow for single TLD applicants, new entrants, Global South & middle applicants. -- it's a shame we can't explore some of the options/suggestions in the chat in more detail. Like @Anne's payment into the applicant support fund. and Paul's applicant assurances. Combining some of these could well give the disincentive being looked for without unduly constraining "genuine applicants" who unfortunately don't win out in contention. -- Question: Do we have evidence that applicants had no intention of running DLD. It seems quite specious to me. I would also question how this was actually determined in the past. The investment and losing money and time to actually apply was already high enough to discourage plenty to apply in the first place without having to try and divine their actual intentions. Answer: We don't have evidence from the last round that applicants initially went into this applying for a pod with the intent to benefit. We only have evidence of applicants actually financially benefiting and in some cases public company filings where they certainly don’t boast about the fact that they've made more money running or in a private auction and getting the TLD, but they certainly use that information to boost the health of their public companies. 2. Topic 2: Predictability Framework, see attached slides and: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kTw... Slide 16: Predictability Framework – Key Features: * The WG is considering a Standing Predictability IRT (SPIRT) to serve in this role. The “Framework” recognizes that issues can be of varying levels of seriousness/impact and accordingly, can be put into 3 buckets. * Minor or non-minor changes to ICANN’s internal processes: This bucket exists in part to allow ICANN Org flexibility to operate the New gTLD Program effectively. Requiring any change, no matter how minor, to be filtered through SPIRT can paralyze program. * New or significantly altered internal ICANN processes: This bucket exists to ensure that where parties are highly likely to be meaningfully affected, that the solution must be developed in collaboration between ICANN Org and the community (i.e., SPIRT). * Policy changes or new policy: This bucket exists for circumstances where an issue arises and there is some ambiguity in how it should be resolved. If an issue is unambiguously policy, there is unlikely to be the need to filter the issue through the SPIRT (e.g., develop policy immediately) Slide 17: Predictability Framework – Key Features: * As currently devised, SPIRT limited to serve as a body that utilizes the Framework and provides that recommendation to the GNSO Council (and if applicable, the issue originator as well). The SPIRT may also be asked to help scope an issue during the course of its consideration of the issue. However: * The SPIRT shall NOT develop solutions (except in collaboration with ICANN Org for issues in bucket 2). It will generally be limited to serving as a triage body that helps in identifying resolution mechanisms. * The SPIRT shall NEVER be used to make policy or circumvent the policy process. * The SPIRT shall ALWAYS be subordinate to the GNSO Council, to help ensure that the SPIRT remains faithful to its remit. Slide 18: Some Concerns Raised: * The SPIRT may develop policy and undermine Council remit. * The SPIRT can be lobbied. * ICANN Org should not be able to make decisions on its own (i.e., bucket 1). * Determining what is policy versus implementation is always hard/subjective, so why would the SPIRT be able to do it better? * Determining which ”bucket” something is in will not always be clear. * The Framework and SPIRT may be seen as overly complicated and need to be simplified * Are there measures to address these concerns? What is the “risk profile” for each of these issues (e.g., likelihood and severity)? Discussion: -- Question: Who decides in what bucket that category falls? Answer: We're hoping that this would be done in collaboration between ICANN org and the SPIRT, but of course the GNSO Council, which has a supervisory role over the SPIRT, can always jump in to the process if it disagrees with the spirit team on its categorization of the issue or the of course the advice that a spirit team gives on how to handle that issue. -- Question: Wonder if that mechanism provides more predictability, or just adds more complexity? Answer: it certainly adds a little more complexity, but we believe that having members of the community and experts serve on this SPIRT could help guide ICANN org and provide some advice so that ICANN org is not dealing with all of these issues on an ad hoc basis escalating all of those issues to the ICANN board when they could be more efficiently vetted through this SPIRT. -- Question: Didn’t think that staff should be determining the bucket – SPIRT should be determining the bucket. Answer: The SPIRT team will certainly be collaborating with ICANN org to help figure out which of the buckets, whether it's three or five these fall into. -- Question: What if the predictions are invalid? Are there any factors that are pre-considered in the predictability framework? Answer: There are certainly areas where we may have predicted that certain things would happen and they turn out differently and issues arise and so where that happens that is precisely the reason for this standing committee. That can help guide a process for moving forward with those issues. So that's certainly one of the important factors for coming up with this in the first place. -- For the composition, the WG could look at the GNSO Standing Selection Committee (SSC). -- Question: What is the community? Are At-large, ALAC, and GAC included? Answer: So although it's envisioned that this SPIRT would fall under the GNSO remit, because the GNSO is tasked with developing policies for generic top level domains, it is certainly envisioned including members from advisory committees and supporting other supporting organizations that may be Impacted and want to participate in these types of endeavors. So short answer is yes. -- Question: What is our take on where we are most everyone on board and working out details are still up in the air on the idea itself. Answer: Unless we're reading things wrong that everyone, or at least we haven't done consensus calls as, as you know, but it seems to us that the group is leaning towards this model and yes I we think we're working out details at this. General Questions: -- Question re: discussion last night about our letter to the GNSO Council, noting that we're not intending to address DNS abuse, as requested by the GAC, Board, and CCT-RT recommendations. How can it make sense to move forward with the next round procedures not addressing DNS abuse at all? It seems counterintuitive and the president atmosphere. Answer: DNS abuse is a topic that is being worked on right now by the entire community in many different ways. There have been contracted parties that have put together their framework. There's excellent discussions going on within the a lot about things that they'd like to see registries do and you know that the working group discussed this issue and certainly felt that any solution or any new mechanisms to deal with DNS abuse should be done in a holistic manner. It doesn't make sense to only apply new procedures to incoming registries when that is going to be at least three, four years away. And the second reason is all of the abuse you see right now is our definition in the existing TLDs and the new gTLDs that will be launched in three, four years. We strongly believe that DNS abuse can be worked on by the community in the next three years in parallel with implementing the new gTLD program. So we believe that by the time a new TLD is delegated in two, three years, that there is a solution out there or mechanisms out there to deal with not only the new gTLDs but also, but all existing TLDs. The other thing is that the mission of the new TLD program or one of the missions is to ensure competition. And usually when you have new entrants into the market, you don't make it more difficult for the new entrants to compete than you do with the legacy or incumbent providers -- that is actually the opposite of what should be done to encourage competition. So from a personal perspective, I would say that or strongly encourage the community to work as a whole to solve these issues with the entire TLD landscape as opposed to trying to pigeonhole it in the new TLD program and then apply it to legacy TLDs in 10 years when their contracts renew. So we're hoping that these things can be done at the same time. -- Question: Regarding DNS abuse -- hear there's an idea foot to form a CCWG as opposed to a PDP in order to address this issue community wide with this holistic approach requiring subsequent PDP in order to incorporate any obligations into contracts parties house contracts and so would that not cause delays? Answer: think that certainly to incorporate new obligations on contracted parties, you are correct. That would require a PDP, but that's a good question for the GNSO Council as they're trying to figure out what the next steps are.