Page History
The call for the New gTLD Subsequent Procedures Working Group will take place on Tuesday, 02 October 2018 at 03:00 UTC for 90 minutes.
(Monday) 20:00 PDT, (Monday) 23:00 EDT, 05:00 Paris CEST, 08:00 Karachi PKT, 12:00 Tokyo JST, 13:00 Melbourne AEST
For other places see: https://tinyurl.com/yau3b4mr
Info |
---|
PROPOSED AGENDA
BACKGROUND DOCUMENTS New gTLD Subsequent Procedures Additional Topics_28Sept2018.pdf DRAFT_New gTLD Subsequent Procedures Supplemental Initial Report_28 Sept 2018.pdf |
Info | ||
---|---|---|
| ||
GNSO transcripts are located on the GNSO Calendar |
Tip | ||
---|---|---|
| ||
Apologies: Katrin Ohlmer, Annebeth Lange, Martin Sutton, Phil Buckingham, Peter LaMantia, Kavouss Arasteh |
Note |
---|
Notes/ Action ItemsActions: Notes and Action Items: 1. Agenda review/SOIs -- None 2. Supplemental Report: Review of sections 1.1, 1.2, 1.3, 1.4, and 1.5 continued -- Goal is to publish the report no later than 12 Oct 2018. -- Comments from several members sent to the list recently, not incorporated into the draft. -- The draft has captured all changes in a cumulative manner. Section 1.1 -- Changes include a potential limit to the number of auctions an applicant could participate in -- ICANN Board has concerns about private auctions -- Could the auction be front-loaded? At the time of application, applicant puts forth the maximum amount they would be willing to pay. If contested, winner is the highest bid, paying the second highest bid amount. Benefits include an accurate valuation to each of the participants, potentially. Would need an applicant support element integrated. Action Item: Sarah L to submit write-up of proposal described above. Rubens Kuhl: One of the challenges for those applying to more than 1 TLD, either 2 or an infinite number of them, is to submit maximum bids for each string, since if hey lose one, they have more resources to pay in another one. -- Do the losing bidders pay anything? Receive any benefit? -- Front-loading the auction flips the emphasis of the current auction of last resort. Would the mony need to go into escrow? Could be fairness issues as there may be subconscious biases related to the bid amouts. -- How would community applications be considered in this process? -- Sarah built off of Greg's idea to front-load contention resolution. Sealed price sealed bid auction. Funds collected should go to public benefit. The highest bidder goes through the initial evaluation process, paying the second highest bid. From the chat: Anne Aikman-Scalese: COMMENT: The way to resolve that may be give Community applicants a priority round. Then you are only resolving contention among community applicants. Then in the general round, the bid could be a "silent auction". COMMENT Michael Casadevall: COMMENT: I can see a tie. Two companies bidding the same nice round number. - When would evaluators know the highest bidder, if ever? It seems like in the beginning, as that seems to drive the evaluation order of the contention set. -- Add additional text as suggested by Anne Aikman-Scalese via email, at the end of the second paragraph. Section 1.2 - Unsure of why emphasis is only on private auctions. Is the issue more about the parties that did not win the string are ending up getting paid off? Are other private resolutions problematic as well? Could result in every contention set ending up in auction. It would be odd to ban private auctions, but not other private resolution methods. From the chat: Rubens Kuhl: Curiously, people seem to be in favor of private resolution by constituing joint-ventures. Rubens Kuhl: But Jon is right, you can't have the cake and eat it too. Michael Casadevall: Well, forming a JV is somewhat different since it's "everyone wins" Jim Prendergast: ff memory serves correct - I think the suggestion for a determination draw was to replace both private auction and ICANN last resort auction Michael Casadevall: It should be noted that banning private resolutions except X is an option. Rubens Kuhl: I can sell shares in a JV for the highest bidder. Justine Chew: Correct, we need to be clear on what should be encouraged vs discouraged (or disallowed). Rubens Kuhl: There's no way to implement such discretionary approach to private resolutions. It's all or nothing. -- Joint ventures seem less objectionable to many. Allowing for changes to strings has been considered as well. - Include concerns about the private resolutions in the private auctions section. Seems like it needs to be all private resolutions are allowed or none are allowed. - Suggestion to pull the preliminary recommendation out of section (c). Prior to Jon's intervention, it seemed like that was the direction of the group previously. - Private auctions is a sub set of private resolutions. There may be some forms of private resolution that could be acceptable, while private auctions may indeed be the most problematic element. Action Item: leadership team to reevaluate how to organize section, given new issues raised by Jon. -- There is still a general sentiment that private auctions are problematic. From the chat: Anne Aikman-Scalese: QUESTION: If the award goes to a certain entity and if the entity changes, ICANN approval is needed, right? Does that reduce gaming in the suggested solutions? QUESTION Anne Aikman-Scalese: Its a question related to whether any system we devise could be easily "gamed". -- Change in entity prior to contract signing, additional due diligence is needed. After contract signing, due diligence needed as well. -- There are public comments to the Initial Report that may be of relevance to the supplemental report. Statistics on auctions from Rubens: From the chat: Rubens Kuhl: Michael, https://newgtlds.icann.org/en/program-status/statistics [newgtlds.icann.org] has the numbers. Rubens Kuhl: Total Contention Sets 234 Rubens Kuhl: Resolved Contention Sets 226 Rubens Kuhl: Contention Sets Resolved via ICANN Auction 16 Rubens Kuhl: Unresolved Contention Sets 8 Rubens Kuhl: Applications Pending Contention Resolution 24 Michael Casadevall: Maybe it's just me, but I haven't heard much support for auctions in general, even as a public last resort. -- Options to auctions are provided, but there is an argument made in section 1.1 for the fairness of auctions. From the chat: Jim Prendergast: here is the Board comment on private auctions - Regarding question 2.7.4.e.2 on “gaming” or abuse of private auction, the Boardbelieves that applications should not be submitted as a means to engage in privateauctions, including for the purpose of using private auctions as a method of financingtheir other applications. This not only increases the workload on processing but putsundue financial pressure on other applicants who have business plans and financingbased on their intention to execute the plan described in the application. In particular, weare concerned about how gaming for the purpose of financing other applications, or withno intent to operate the gTLD as stated in the application, can be reconciled withICANN's Commitments and Core Values. Jon Nevett: Perhaps we should refer to private sales vs. private auctions? Section 1.3 -- No changes since last meeting. Section 1.4 -- Talks about change requests that may allow for contention resolution (e.g., joint ventures and string change). -- No changes since last meeting. - If in a contention set and you are able to choose another string, does it prevent choosing a string that puts you in another contention set? Action Item: Include language above. Section 1.5 -- Added elements about asking registrars for advice. - Is the intention to create a retail space for registry's that are failing? Are we interfering in the marketplace? Is ICANN acting as a regulator by serving in a registrar? Is there a compliance issue here as well? Action Item: Jim P to circulate text to strengthen section concerning elements above. Perhaps create a question. -- ICANN is not just regulating types of things, but it's also regulating how it's distributed. There is already manipulation of the market.
From the chat: Jon Nevett: Jim +1 -- if a registry isn't getting sufficient registrar support, it could start its own - Some have noted challenges with starting a registrar, as well as challenges meet the requirements of the code of conduct, especially for smaller organizations.
From the chat: Christopher Wilkinson: Section 1.5: just to recall that I hae already posted my comments to the List. Rubens Kuhl: Jon, that doesn't work in practice due to (1) high cost of registrar accreditation when used to sell a single TLD (2) registrants inertia or preferrence to use a single registrar/reseller for all their domain registrations. Michael Casadevall: I see Jim's point, but I have concerns that a registar may refuse to carry a gTLD for non-technical/non-financal reasons. I want to see Jim's comments before I dig in deeper though. Jon Nevett: in the 2005-8 policy debate on use of registrars, the key was that the protections required in the RAA are required for all registrations -- protections could be integrated into the Registry Agreement. From the chat: Rubens Kuhl: Michael, must-carry obligations were deemed to be over the top. So this doesn't seem to have much traction indeed. Jim Prendergast: Michael - do you envision a scenario where ICANN shoudl force a registrar to carry a TLD? --Everyone should review text, especially questions, options, etc. a. Draft of the additional Supplemental Report sections. - Jeff added additional context about why this supplemental report is being issued. Noted that public comments related to these subjects will not have been considered. -- Was there a Work Track involved in reviewing these issues? -- If relevant, the relevant section is cited in the sections. However, most topics are mostly new. -- When reviewing comments, will try to identify where those comments may be relevant to the supplemental report. 3. Initial assessment of work required for Final CCT-RT Report -- Overview of columns included in the document -- Recommendation 9: Reading through the What Else Needs to Be Done (final column)? -- Any objections to the approach suggested in this column? - no objections raised. -- Anne Aikman-Scalese - Submitted a question to the list about this document. On recommendation 9, the RPM process is not a PDP. It is a review. General question about recommendations coming out of reviews and how the WG is expected to address these. Please see comment/question on list. From the chat: -- This comment from Anne does not appear to be contrary to the comments in the "What Else Needs To Be Done?" Due to the overlapping nature of the charters, it will be necessary to take into account the work that this group has done. From the chat: -- Main takeway: WG members should look at the recommendations and look at the last column about what needs to be done from our perspective. From the chat: - Clarification: It is not so much that the Board needs to resolve this. To complete the review, the Board will need to provide additional guidance about whether it accepts the recommendations. The Board will provide direction to the GNSO Council, which will direct the PDP. 4. AOB 4.1 Update on the Initial Report public comment review process - Public comments received on Intiial Report - public comment period closed on Wednesday. Close to 70 comments were received including from many of the SO/AC/SG/Cs, GDD, ICANN Board and a number of ccTLDs. - This is a large number of comments. There is a lot of work underway to organize and tabulate comments to support the WG's review of comments. -- Staff has created three Google Sheets that are similiar to the ones used for reviewing CC2. - There is one Google Doc per review SubTeam and one tab per topic area. Each preliminary recommendation, option, and question has a section within the sheet. - Where the specific preliminary recommendation, option, or question is referenced, this excerise is straightforward. Please check staff's categorization of the other comments. -- Goal is to have initial tabulation complete sometime next week, well in advance of ICANN63. |