[gnso-rpm-wg] 99%+ reduction in sunrise utilization rate per TLD supports EFF call for elimination of sunrise

J. Scott Evans jsevans at adobe.com
Thu Aug 17 18:26:40 UTC 2017


Jeremy:

Here is a link to the Working Group Guidelines developed by the community in 2010: https://gnso.icann.org/en/improvements/gnso-working-group-guidelines-final-10dec10-en.pdf

You will find the answer to your questions around consensus in Section 3.6 Standard Methodology for Making Decisions.

J. Scott

[tps://inside.corp.adobe.com/content/dam/brandcenter/images/image002.gif]

J. Scott Evans

408.536.5336 (tel)

345 Park Avenue, Mail Stop W11-544

Director, Trademarks

408.709.6162 (cell)

San Jose, CA, 95110, USA

Adobe. Make It an Experience.

jsevans at adobe.com

www.adobe.com








From: <gnso-rpm-wg-bounces at icann.org> on behalf of Jeremy Malcolm <jmalcolm at eff.org>
Date: Thursday, August 17, 2017 at 11:12 AM
To: Jonathan Frost <jonathan at get.club>, 'icannlists' <icannlists at winston.com>, 'Kathy Kleiman' <kathy at kathykleiman.com>, "gnso-rpm-wg at icann.org" <gnso-rpm-wg at icann.org>
Subject: Re: [gnso-rpm-wg] 99%+ reduction in sunrise utilization rate per TLD supports EFF call for elimination of sunrise

On 17/8/17 10:47 am, Jonathan Frost wrote:

This brings up a couple of philosophical questions that I hope aren’t too far afield, but are implicated by Paul’s comment.

  *   What is the definition of consensus (is it unanimity or something less)?

  *   Is consensus required for this PDP to make recommendations?

  *   Would consensus be required for this PDP to recommend that Sunrise be maintained in the next round (or is consensus only required to recommend a change from the last round)?
I tend to agree with many here that Sunrise leaves a relatively light footprint (as opposed to claims), and are useful in the tapestry of RPMs, so I think Sunrise is a useful mechanism and should be maintained (and improved).  But it’s not clear to me that we can shut down recommendations that are unlikely to reach consensus, when their opposite is also unlikely to meet consensus.

Since the new gTLD RPMs were not adopted as ICANN policy covering all gTLDs, there shouldn't be any automatic presumption that they will apply to future rounds in my view.  It's this group's role to decide whether they should or not.  If *not* making a decision means that we are, by default, deciding to extend the new RPMs to future rounds, then we haven't done our job.  That would create a very bad incentive for people to gum up the process and avoid reaching consensus, just because by doing so they will get the outcome that they are looking for anyway.  What kind of multi-stakeholderism is that?



--

Jeremy Malcolm

Senior Global Policy Analyst

Electronic Frontier Foundation

https://eff.org<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feff.org&data=02%7C01%7C%7Cf342a263cf754a12325108d4e59b9dac%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636385903925250819&sdata=P00qSS6k1qtGVQNkFDIdoaWiy7AigenAs5WDzWZEp8k%3D&reserved=0>

jmalcolm at eff.org<mailto:jmalcolm at eff.org>



Tel: 415.436.9333 ext 161



:: Defending Your Rights in the Digital World ::



Public key: https://www.eff.org/files/2016/11/27/key_jmalcolm.txt<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eff.org%2Ffiles%2F2016%2F11%2F27%2Fkey_jmalcolm.txt&data=02%7C01%7C%7Cf342a263cf754a12325108d4e59b9dac%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636385903925250819&sdata=7iIbRiCOfDMaEhDYHOl%2FpSggHMoXLSKHOmp%2BKnvBYSs%3D&reserved=0>

PGP fingerprint: 75D2 4C0D 35EA EA2F 8CA8 8F79 4911 EC4A EDDF 1122
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20170817/1704f574/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1577 bytes
Desc: image001.gif
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20170817/1704f574/image001-0001.gif>


More information about the gnso-rpm-wg mailing list