Dear Working Group members, Please see below the notes from the meeting on 22 October 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/x/oooCBw. Kind regards, Emily Notes and Action Items: Actions: ACTION ITEM: Working Group members to respond on list to the proposal to add a Public Interest Commitment stating that the registry operator will not engage in fraudulent and deceptive practices. Are there objections? Notes: 1. Welcome and Updates to Statements of Interest * No SOI updates * Phil Buckingham shared an update on the mailing list. 2. Review of summary documents: a. Auctions: Mechanisms of Last Resort:https://docs.google.com/document/d/15S_sUuP_gmKqba26tU9kYQ8mVF76W_3CSl4raxSg... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> * On the last call, the WG focused mechanisms of last resort and then went on to discuss private resolution. We covered what was in the summary document, but we will talk more today about Donna’s proposal on the last call, Jeff’s version as he has interpreted the proposal, and possible alternatives. * Taking a step back, what is the problem or perceived problem that we are trying to solve? This requires going back to Supplemental Initial Report, Board letter, and other materials. * Concern raised by the Board with respect to private auctions - possibility of gaming, potential financial benefit to parties who do not intend to use the string. Concerns also raised by GAC, ALAC, and others. * Review of Supplemental Initial Report text on concerns raised about gaming (see page 19). * Community comments indicate that it doesn’t feel right or send the right message to those outside ICANN that we are creating a secondary market for top level domains. This is the problem we are trying to solve. * Note that there were other comments that said that this issue should be studied further before the WG should make any recommendations. It’s important to keep this in mind before making a conclusion. * Response: the WG tried to study this issue, but there are confidentiality agreements and some parties do not want to share information. It is possible to look at some public data (links shared in chat). * In defense of private auctions, there is the argument that all parties must consent to go to private auction. There is also the question of whether ICANN should be getting involved in transactions between private actors. At the same time, it is important to take comments from the Board and governments and address those in some way. * Proposals regarding alternatives to auction, such as RFPs or random draws, did not receive favorable comments. Therefore, the auction is likely to stay in some form, but there are different types to consider. * One member raised that the ICANN Board is an interested party in the issue of auctions of last resort, and this should be taken into account when reviewing Board comments on the topic. * Response – the Board comments did not advocate for auctions of last resort. They raised concerns about perception issues about private auctions. * Staff comment – Looking back at the Supplemental Initial Report, one connection that the WG made based on the links Jeff provided, was that there is evidence that applicants were able to gain financially from private auctions. This will be known in future rounds, and may incentivize an increase in private auctions in subsequent procedures absent measures to disincentivize the practice. * Donna’s proposal for sealed bid auction process: Applicants submit applications, ICANN determines which applications would be in contention, ICANN would contact applicants and let them know that there is contention but not which parties are in the contention set. Applicants could submit a sealed bid before reveal day or withdraw the application. After reveal day applicants would go through all of the steps as they would in 2012. If the applications still remained in contention at that point, there would be a period for private resolution. If that didn’t resolve contention, the bids would be opened and the string would be granted to highest bidder. * Second option: the beginning would be the same. Applicants submit applications, ICANN determines which applications would be in contention, ICANN would contact applicants and let them know that there is contention but not which parties are in the set. Applicants could submit a sealed bid before reveal day or withdraw the application. After reveal day, there would be string similarity review to see if there might be other strings in the contention set, string confusion objections, CPE. Once that is done, before evaluation of applications from a technical perspective, bids are opened, the highest bidder is selected and only that applicant moves through the process. Jeff’s email provides additional detail about different scenarios. * Question about Donna’s proposal – the applicants do not learn about the identities of the other applicants when they are notified of contention, correct? * Response – it might be helpful to first focus on the high-level idea, and then get into details. * For both proposals, the idea is that parties would be told that there was contention, but does not state who is in the contention set. * Donna’s proposal solves for the issue of having a long drawn-out auction of last resort, but doesn’t solve for the concern that private auctions may have financial benefit. All applications still need to be evaluated, so there are not necessarily cost savings. * Jeff’s alternative would make things more complicated, but it would not allow for private resolution. You would only evaluate one application, as opposed to evaluating all applications. The additional complication might or might not be worth it. * Discussion will continue of the list on the different options. Unless we stay with the status quo, this will likely need to go out for public comment. * Consideration - We have already ruled out other things that could have addressed collusion or profiting from the program – for example, we could have raised the application fee, or could have said that portfolio applicants are not allowed. We are potentially running out of options and this is what we are left with. It’s tricky and we may not completely be able to prevent the behavior. * We can revisit some of the other solutions, but there were many negative public comments on them. * Clarification – there is no need to revisit the other solutions that were eliminated, it’s just important to acknowledge the challenges of the solutions we are still considering. * This will be discussed further on the mailing list. We might be able to develop some additional materials on email and then if necessary, another call can be scheduled on this topic to discuss further. b. Base Registry Agreement:https://docs.google.com/document/d/14HxLzQMXs90hAkpRStPAwHDC4CxaYXWqxZ-psTmx... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> * Review of policy goals and high-level agreements. * Proposed high-level agreement would leave quite a bit of detail for the IRT to work out. * Review of concerns and new ideas regarding the proposed high-level agreement. Is there more detail we can add to the high-level agreement to address concerns raised by ICANN org? * Maybe the proposed high-level agreement is already getting into implementation issues. Perhaps the policy should be higher-level -- ICANN org should accommodate different business models and be open to new ideas as long as it doesn’t do any harm to the rest of the industry. * We are putting ICANN in a difficult situation. If we just have that high-level recommendation, we are putting ICANN in a position where it needs to make a judgement call without further guidance. We talk about equitable treatment on the one hand and flexibility on the other. * Maybe it will solve the problem to provide advice to lean towards innovation. * We can add language that the purpose is to encourage innovation and allow ICANN to be more lenient towards additional types of business models and make a balanced determination about modifications where it’s either in the public interest to do so or no harm to the public interest in doing so. * Further analysis might be needed of RySG proposal: “The existing process of obtaining an exemption to the Code of Conduct results in some ambiguity under the Registry Agreement, since the registry operator is still bound by section 2.9. Since, under the current model, all exemptions must be for single- registrant models wherein the registry (as registrant) may still chose its registrar, we do not believe this language should apply to Specification 9 exempt TLDs, regardless of whether they additionally qualify for Specification 13.” * Review of comment on the process for obtaining exemptions - how can ICANN balance the need to consider unique aspects on applications while also treating each registry operator equitably? * RrSG suggests that SLA metrics should be equal. One WG member responded that he did not object to this approach. * Review of comments on suggestion that for exemptions or exceptions, the proposer could provide the specific problematic provisions, the underlying policy justifications for those provisions, and the reasons why the relief is not contrary to those justifications. * Neustar commented that this would require the proposer to know the underlying policy justification for any given part of the RA. To address this concern, perhaps instead the proposer must provide justification for the requested exemption. This would then potentially go out for public comment. Some information may be confidential, but the proposer and ICANN might be able to put forward a explanation that does not reveal any confidential information. * Review of comments on including a covenant in the RA that the registry operator will not engage in fraudulent and deceptive practices. This was suggested in response to a PICDRP case. The idea is that this would give ICANN a remedy if fraud was found to exist. * Thoughts on making this a PIC? If it’s in the RA, ICANN is the only one enforcing. If it’s a PIC, a complaint can be filed by a third party and ICANN has the discretion to initiate a PICDRP using the third-party complaint. * If it’s a PIC, we need to reconcile with the groups that oppose PICs in general, although some of the concerns about PICs may be the name used – the term “public interest” may be a misnomer. * Proposal to suggest that this is included in PICs. ACTION ITEM: Working Group members to respond on list to the proposal to add a Public Interest Commitment stating that the registry operator will not engage in fraudulent and deceptive practices. Are there objections? * Review of comment on registration terms, billing cycles, and presumptive renewals. In response to Google’s comment on this topic: the concerns should probably be addressed by asking for an exemption and providing a rationale. Otherwise there are mechanisms (SSAC, IETF – the EPP Protocol) to deal with these concerns, but this is outside of the WG’s area of expertise. * Review of comments on premium pricing. Note that there was also an issue that SubPro had referred to RPMs – reservation of names that later go to premium pricing, and whether they go around RPMs. * There is a fine balance about whether issues related to premium pricing are in scope or not. We can say that transparency is key, that provisions in the agreement are there to require this transparency, and that ICANN should be enforcing the provisions of the RA and RAA. * Comment from ICANN Org – it would be helpful to have a set of policy goals/principles in relation to exemptions. It’s hard to consider exemption requests in a vacuum. This would be helpful both in implementation of the program and also for guiding applicants as to whether an exemption is something they should pursue. * Maybe the group can look at the RSEP request form and some of the goals listed there as an example – encourage competition, reduce harm, etc. c. Registrar Non-Discrimination / Registry/Registrar Standardization (https://docs.google.com/document/d/14HxLzQMXs90hAkpRStPAwHDC4CxaYXWqxZ-psTmxHdU/edit#<https://docs.google.com/document/d/14HxLzQMXs90hAkpRStPAwHDC4CxaYXWqxZ-psTmxHdU/edit>) * Review of policy goals and high-level agreement. * Review of comments on revision of recommendation 19 to make current with the current environment. * Review of general comments on the topic of vertical integration. * Review of comments on whether registry operators granted an exemption from the Code of Conduct should also be exempt from section 2.9 of the Registry Agreement. * Review of comments – if complete exemptions are granted, are there any obligations that should be imposed on .Brand registries? * Review of comments - additional situations where exemptions to the Code of Conduct should be available? * Review of comments - there are provisions in the Registrar Stakeholder Group Charter that some feel disfavor those who have been granted exemptions to the Code of Conduct. Would it be better to phrase the preliminary recommendation as “unless the Registry Code of Conduct does not apply” rather than “unless an exemption to the Registry Code of Conduct is granted”? * Main takeaways for this topic – there should be transparency and enforcement of existing provisions. 3. AOB * DNS Abuse – * Staff and leadership team are preparing a paper on this topic to support further discussion. CCT-RT recommendations address this topic. Many of those CCT-RT recommendations have not been approved by the Board, but those issues should still be discussed by this group. The discussion will focus on whether this group should make recommendations or let the community resolve this through another process since other discussions are ongoing. * If we want, we can make a recommendation regarding new TLDs going forward, but this would create a disparity between new TLDs and existing TLDs. We will not get into questions about what DNS Abuse is, unless the group feels strongly that we should be making recommendations. We will also look at relevant public comments from the Initial Report. * ICANN 66 * 4 sessions are scheduled for this group. * First 2 sessions are to receive the Report and recommendations from WT5. The full WG can ask questions of the Work Track. * In the 3rd and 4th session, we will talk about what topics need to go out for public comment as well as topics that were supposed to be addressed in small groups. * Request to get materials/slides ahead of time to review. It would be helpful to understand what the leadership team wants from the group in those sessions will help to ensure the group makes progress at ICANN66.