[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 December 2019

[Justine Chew]

Just to clarify, under the Discussion section for the 2 Alternatives. I
raised a question regarding private auctions as one of the mechanisms under
private resolution. I didn't question retaining private resolution, just
private auctions as one possible private resolution mechanism, because I
thought the WG was leaning towards banning just private auctions.

Justine
-----


On Tue, 3 Dec 2019 at 00:52, Julie Hedlund <julie.hedlund at icann.org> wrote:

> 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+Procedures+PDP
> .
>
>
>
> 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/16qDoiK6vydQp6a0v9tMvU2l5fcypJY24hCzTIVTjKwk/edit?usp=sharing
> [docs.google.com]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_16qDoiK6vydQp6a0v9tMvU2l5fcypJY24hCzTIVTjKwk_edit-3Fusp-3Dsharing&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=adDIs0WEx_lLwFfrsdovxTYY8GkRHo5ibc8SR3Npdh8&m=CQEth_7agzL4nstv-7WTuaAuI6d1I-2inhjqcYiT46I&s=A3JYJRT5C06hqUQZ-Zi8neK99f2OkoiaMb6s-dNpcAk&e=>
>
>
>
> *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.
>
> a.                   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.
>
> .                     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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20191203/1dd3e54a/attachment-0001.html>