[gnso-rpm-wg] FOR REVIEW & DISCUSSION: Draft collated proposal for Sunrise-related data collection
claudio di gangi
ipcdigangi at gmail.com
Wed Aug 9 12:20:58 UTC 2017
When analyzing the number of Sunrise registrations in the last round, how
do you suggest factoring-in to the analysis the number of DPML/other
blocking mechanisms, that function as defensive, non-resolving
registrations across hundreds of new gTLDs?
Once a trademark is 'blocked' through one of these additional marketplace
RPMs (for several thousand dollars per mark) - currently offered on a
voluntary basis as an alternative to Sunrise, to reduce social costs
imposed by the new gTLD program, that mark is defensively 'registered'
across hundreds of new gTLDs (at the same time, any of these DPML 'domains'
can be overridden by a non-trademarked registrant upon request to the
On a related point, we have numbers on the number of domains blocked
through these services?
On Wed, Aug 9, 2017 at 7:11 AM George Kirikos <icann at leap.com> wrote:
> Hi folks,
> On Mon, Aug 7, 2017 at 11:47 AM, Beckham, Brian <brian.beckham at wipo.int>
> > Finally, the suggestion that Sunrises may not be meeting their intended
> > purpose due to low uptake statistically-speaking (also as to documented
> > abuses) seems to widely miss the mark. As J Scott and others pointed
> out on
> > the call, the intended purpose is to provide an opportunity to get ahead
> > infringing registrations. Whether that opportunity is taken up by a
> > owner is an altogether separate question.
> This analysis is deeply flawed. It attempts to justify the continued
> existence of the sunrise by measuring "theoretical benefits", despite
> the low uptake rate, as opposed to "actual realized benefits" (as
> measured by the actual low update, data that is actually observable),
> when comparing against the costs of the sunrise period (to competing
> good faith registrants, etc.).
> For example, consider a public library branch that is in a large
> neighbourhood of 100,000 people, but is only used by 100 people per
> year. Using Brian's flawed analysis, the branch should be kept open,
> because "theoretically", 100,000 people have the opportunity to use it
> (even though 99,900 don't actually use it). Instead, it should be
> closed because only 100 people actually use it. The actual benefits
> (the usage by a mere 100 users) are what matter, when compared against
> the costs.
> I agree with the analysis of Paul Keating in this thread, who properly
> weighed the actual benefits (low), vs the costs, and came out in
> favour of elimination of the sunrise period.
> As I discussed in a previous thread on this topic, sunrise demand
> would shift to the landrush period when the sunrise period is
> eliminated. Appropriate safeguards could be instituted to reduce
> cybersquatting in that landrush (e.g. loser pays UDRP costs for
> landrush registrations, thereby raising the bar for those
> registrations, compared to general availability, or other mechanisms
> suggested). See the (long) thread in April 2017, starting with:
> and with other replies at:
> ICANN's history is riddled with examples of bad policy suggestions
> that had theoretical benefits, and whose introduction was based on
> speculative demand that never was realized. It's time to assess those
> policies properly and honestly, and admit that they were failures. The
> sunrise period for new gTLDs is a prime example. By Brian's analysis,
> it can **never** be eliminated, even if just 1 user actually used it,
> because its "theoretical" benefits can **always** be said to be high.
> The purpose of this PDP is to do a proper and intellectually honest
> review, which means looking at the actual benefits. To do otherwise is
> to say that the outcome of this PDP is rigged and predetermined, and
> it doesn't matter what the actual data (as measured by actual usage),
> actual experience and actual statistical evidence, tells us.
> George Kirikos
> gnso-rpm-wg mailing list
> gnso-rpm-wg at icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gnso-rpm-wg