[gnso-rpm-wg] Information on GNSO consensus designation and practices (99%+ reduction in sunrise utilization rate per TLD supports EFF call for elimination of sunrise)

Mary Wong mary.wong at icann.org
Thu Aug 17 18:28:33 UTC 2017

Dear Jonathan and everyone,

If I may, here is some information on the GNSO rules and procedures that may be of assistance.

  1.  Definition of consensus:

  *   This is specified in the GNSO Working Group Guidelines which apply to all PDP and non-PDP Working Groups (see Section 3.6 on pages 8-9: https://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-01sep16-en.pdf).

  *   Essentially, Full Consensus means unanimity, and Consensus means most members except for a small minority agree. There are also several other designations possible, including No Consensus (or Divergence) and the possibility of Minority Views (for which minority statements can be filed and included as part of the Final Report of the group).

  *   Note that it is the co-chairs’ responsibility to designate the various levels of consensus. Typically this is done through a formal consensus call lasting two or more weeks after the co-chairs determine that sufficient deliberation on all proposals has occurred. The consensus call involves all Working Group members and is always announced (and reminded) via the mailing list.

  1.  Whether consensus is required for PDP recommendations:

  *   Typically, a PDP Final Report will include all recommendations and the various levels of consensus that were reached for each recommendation. It is also common to include any proposals that remained on the table at the end but that did not achieve any of the consensus levels specified (e.g. these may be proposals on which there is Divergence).

  *   In practice, the GNSO Council will vote to adopt those final recommendations that have achieved either Full Consensus or Consensus designations only (although they do not have to; however, the GNSO’s PDP Manual specifically outlines how the Council should deal with different recommendations (see Section 12 on Page 8: https://gnso.icann.org/en/council/annex-2-pdp-manual-01sep16-en.pdf):
     *   “In the event that the Final Report includes recommendations that did not achieve the consensus within the PDP Team, the GNSO Council should deliberate on whether to adopt them or remand the recommendations for further analysis and work. Although the GNSO Council may adopt all or any portion of the recommendations contained in the Final Report, it is recommended that the GNSO Council take into account whether the PDP Team has indicated that any recommendations contained in the Final Report are interdependent. The GNSO Council is strongly discouraged from itemizing recommendations that the PDP Team has identified interdependent or modifying recommendations wherever possible. In the event the GNSO Council expresses concerns or proposes changes to the PDP recommendations, it may be more appropriate to pass these concerns or recommendations for changes back to the respective PDP Team for input and follow-up.”

  1.  Is consensus required to recommend that Sunrise be retained, changed or dropped?

  *   As Jeremy and others have noted, Sunrise (and the other 2012 round RPMs) are not specific Consensus Policies but were mechanisms developed during the Applicant Guidebook iterative process to address what had been identified as overarching issues, including trademark protections. Given the GNSO’s procedures and practices, any recommendation on Sunrise – including as a Consensus Policy and in what form (e.g. whether as is or modified), or not used – will need to go through the consensus process as described.

I hope this is helpful.


From: <gnso-rpm-wg-bounces at icann.org> on behalf of "J. Scott Evans via gnso-rpm-wg" <gnso-rpm-wg at icann.org>
Reply-To: "J. Scott Evans" <jsevans at adobe.com>
Date: Thursday, August 17, 2017 at 14:27
To: Jeremy Malcolm <jmalcolm at eff.org>, 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


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[gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_improvements_gnso-2Dworking-2Dgroup-2Dguidelines-2Dfinal-2D10dec10-2Den.pdf&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DJ69mAe-idEhpAMF1nu2x6c2w3xl7xb5cjS_7sB4h6Y&m=ptZBFOeKgA-Dkt0QExGcJsAKLWwBx7oqNts-jGhaRpg&s=9svIWoIuO0iLF4up5jYLYUXo5QAvyn3NS2CbOEfLhXk&e=>

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

J. Scott


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


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


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[na01.safelinks.protection.outlook.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.eff.org-252Ffiles-252F2016-252F11-252F27-252Fkey-5Fjmalcolm.txt-26data-3D02-257C01-257C-257Cf342a263cf754a12325108d4e59b9dac-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636385903925250819-26sdata-3D7iIbRiCOfDMaEhDYHOl-252FpSggHMoXLSKHOmp-252BKnvBYSs-253D-26reserved-3D0&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DJ69mAe-idEhpAMF1nu2x6c2w3xl7xb5cjS_7sB4h6Y&m=ptZBFOeKgA-Dkt0QExGcJsAKLWwBx7oqNts-jGhaRpg&s=CYyu9-V_LxSLJvSmn5OPZRKPgoYoG0t8kGDCPUzJXzU&e=>

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/02d42d8e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1578 bytes
Desc: image001.gif
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20170817/02d42d8e/image001-0001.gif>

More information about the gnso-rpm-wg mailing list