[Gnso-newgtld-wg] Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Monday, 04 May at 15:00 UTC for 120 Minutes

Justine Chew justine.chew at gmail.com
Sat May 2 05:39:21 UTC 2020


Not to mention when/how to integrate (allowable) Application Change
Requests for changes in applied-for string to resolve contentions which may
or may not require revelation of applicant identities or Application Change
Request resulting from a combination of business or JVs which would
certainly require revelation of applicant identities.

Justine


On Sat, 2 May 2020 at 06:55, Rubens Kuhl <rubensk at nic.br> wrote:

>
>
> On 1 May 2020, at 19:12, Alexander Schubert <alexander at schubert.berlin>
> wrote:
>
> Hi there,
>
> Regarding the attached PDF “Auction discussion points”:
>
> In Option 2 we have two reveals: one is revealing only the strings, the
> second the applicants as well. Prior to the reveal of applicants we
> establish the contention sets – and require contention set members to place
> an “auction of last resort” sealed bid.
>
> My question is: How are the “contention sets” being established?
> ·         Like in the 2012 round?
> ·         Or “automatically”: only identical strings?
>
> If we strive to establish contention sets like in 2012 – we run into a big
> problem: that process took many years. Think “string similarity objection”.
>
>
>
>
> Contention sets indeed might require more evaluations (Geo, CPE) and
> objection processing to be done, so I suggest making it clear to bidders
> where some other member in the contention set has self-identified as Geo or
> Community. We would still require them to bid, and use that bid if no other
> criteria ends up settling the contention set.
>
> But I suggest bidding to only occur after ICANN's own string similarity
> analysis, so cases like unicom/unicorn would already appear in the strings
> reveal as in contention, while the final size and shape of the contention
> sets might be changed later down the road by string confusion objections.
> Since the bidders (and everyone) would know the full list of strings, they
> can assess the risk of a string confusion objection to add more
> applications to fight with the winning bid.
>
> This is also a reason to limit disclosure of the bid amounts until after
> contention sets are finalised and new bids are requested from the
> applicants initially not in contention for the contention sets formed after
> the first reveal. Such amounts need to be disclosed at some point, and any
> limit of filing appeals, RfRs etc. should only start counting after
> disclosing of the winning bids.
>
> Linking to another topic, do we also want for strings reveal day to also
> feature the results of name collision risk assessments ? It might be useful
> for bidders to know whether they are going for a smooth path to delegation
> or to a convoluted mitigation framework design / evaluation path.
>
>
> Rubens
>
>
>
>
>
>
> _______________________________________________
> 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/20200502/3ff1d21c/attachment.html>


More information about the Gnso-newgtld-wg mailing list