[Gnso-newgtld-wg-wt2] - GDD Response to EBERO questions

Fri Feb 17 01:34:38 UTC 2017

Steve and the GDD Team,

Thank you for providing this answer. This is very helpful and assists us in
our work.

Jeff,

You are right this does go to the heart of the issue. What we can take from
this is that the EBERO process still has not been used. Still, this does
not support us in evaluating whether or not the actual EBERO process proves
to be sufficient as a Registrant Protection. We are able to gather that
ICANN has been able to resolve any emergency escalations prior to the need
to use EBERO and thus circumvented the need. One question we might gather
from this:

"Do we need to reconsider the level of emergency escalation required for
EBERO?" or ask for more clarity as to "At what point of emergency
escalation would ICANN consider using the EBERO process?"

I don't want to swing at a problem that isn't there and therefore the above
questions may not be necessary to ask. For EBERO, I really think we should
apply the Neuman rule, "If its not broken, don't fix it." There is likely a
consensus that the EBERO is a powerful Registrant Protection and because no
incidents of the EBERO having been used are available for our
consideration, then we should leave it in place for handling necessary
emergency situations for registries until due time that the EBERO process
is unable to support emergency situations.

The COI and the Registrant Protections being necessary for all TLDs require
separate consideration.

Other thoughts?

Michael Flemming

On Fri, Feb 17, 2017 at 6:04 AM, Jeff Neuman <jeff.neuman at comlaude.com>
wrote:

> Thanks Steve.  Please thank the GDD Staff for us.   I think the last
> paragraph is the key one we should pay attention to.  Namely:
>
>
>
> Since the launch of the New gTLD program, an SLA has reached or exceeded
> the emergency threshold 27 times. However, no EBERO events have been
> declared to date. In each of these 27 cases, ICANN technical teams were
> already working with the registry before the threshold was reached. In many
> of the cases, the TLD had no registrations. In the cases in which there
> were registrations, ICANN considered the EBERO option. However, ICANN
> determined that it would have less of a security and stability impact to
> assist the RSP through resolution rather than activating an EBERO event.”
>
>
>
> I think this goes to the heart of one of the main issues with the EBERO
> solution.
>
>
>
> *Jeffrey J. Neuman*
>
> *Senior Vice President *|*Valideus USA* | *Com Laude USA*
>
> 1751 Pinnacle Drive, Suite 600
>
> Mclean, VA 22102, United States
>
> E: jeff.neuman at valideus.com or jeff.neuman at comlaude.com
>
> T: +1.703.635.7514 <(703)%20635-7514>
>
> M: +1.202.549.5079 <(202)%20549-5079>
>
> @Jintlaw
>
>
>
>
>
> *From:* gnso-newgtld-wg-wt2-bounces at icann.org [mailto:gnso-newgtld-wg-wt2-
> bounces at icann.org] *On Behalf Of *Steve Chan
> *Sent:* Thursday, February 16, 2017 2:07 PM
> *To:* gnso-newgtld-wg-wt2 at icann.org
> *Subject:* [Gnso-newgtld-wg-wt2] - GDD Response to EBERO questions
>
>
>
> Dear WT2 Members,
>
>
>
> On the 19 January 2017 meeting of this Work Track, WT2 discussed
> Registrant Protections and in particular, the EBERO. During the course of
> the meeting, several questions were identified that the WT wanted to put
> forth to the GDD:
>
>
>
> Ask ICANN 1) has the Emergency Threshold been breached 2) has EBERO been
> triggered? 3) If someone went above the threshold and EBERO wasn't used,
> then why?
>
>
>
> Below, please see the response from GDD:
>
>
>
> “Section 6 of Specification 10 of the Registry Agreement for new gTLDs
> provides emergency thresholds for the 5 critical registry functions. Per
> the Registry Agreement, reaching any one of these thresholds could trigger
> an EBERO event.
>
> ICANN monitors registries’ performance of these critical registry
> functions, and regularly engages with Registry Operators and Registry
> Service Providers when service outages occur. Not all services outages
> reach emergency thresholds. If emergency thresholds are reached, ICANN
> evaluates each individual case and make decisions regarding whether to
> trigger an EBERO event based on the unique circumstances.
>
> Since the launch of the New gTLD program, an SLA has reached or exceeded
> the emergency threshold 27 times. However, no EBERO events have been
> declared to date. In each of these 27 cases, ICANN technical teams were
> already working with the registry before the threshold was reached. In many
> of the cases, the TLD had no registrations. In the cases in which there
> were registrations, ICANN considered the EBERO option. However, ICANN
> determined that it would have less of a security and stability impact to
> assist the RSP through resolution rather than activating an EBERO event.”
>
>
>
> Hopefully this response adequately addresses your questions. If you have
> any additional questions or require clarifications, please do not hesitate
> to let the policy staff support know and we will be sure to liaise with our
> GDD colleagues.
>
>
>
> Best,
>
> Steve
>
>
>
>
>
>
>
>
>
> *Steven Chan*
>
> Sr. Policy Manager
>
>
>
> *ICANN*
>
> 12025 Waterfront Drive, Suite 300
>
> Los Angeles, CA 90094-2536
>
> steve.chan at icann.org
>
> mobile: +1.310.339.4410 <(310)%20339-4410>
>
> office tel: +1.310.301.5800 <(310)%20301-5800>
>
> office fax: +1.310.823.8649 <(310)%20823-8649>
>
>
>
> Find out more about the GNSO by taking our interactive courses and
> visiting the GNSO Newcomer pages
> <http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-efforts.htm#newcomers>
> .
>
>
>
> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO
>
> Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/
>
> http://gnso.icann.org/en/
>
> _______________________________________________
> Gnso-newgtld-wg-wt2 mailing list
> Gnso-newgtld-wg-wt2 at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20170217/af8e2a0a/attachment.html>