The biggest vulnerability to registrants when dealing with a failed registry operator is the change of a back-end service provider. Yet, we currently have a system where we require the failed registries names to be changed to an EBERO and then perhaps to a new registry operator and back-end service provider. Two changes in a short period of time. It would make more sense to have a continuation requirement where the existing back-end continues to provide services in case of a registry operator's failure. We would just need to figure out how to compensate that back-end during the transition period (COI or otherwise). The other catch is what happens if a failed registry operator also is providing the back-end services. In that case, we may need an EBERO, but it probably is not a very likely scenario. Jon
On Feb 16, 2017, at 8:34 PM, Michael Flemming <flemming@brightsconsulting.com> wrote:
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@comlaude.com <mailto:jeff.neuman@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@valideus.com <mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com <mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 <tel:(703)%20635-7514> M: +1.202.549.5079 <tel:(202)%20549-5079> @Jintlaw
From: gnso-newgtld-wg-wt2-bounces@icann.org <mailto:gnso-newgtld-wg-wt2-bounces@icann.org> [mailto:gnso-newgtld-wg-wt2-bounces@icann.org <mailto:gnso-newgtld-wg-wt2-bounces@icann.org>] On Behalf Of Steve Chan Sent: Thursday, February 16, 2017 2:07 PM To: gnso-newgtld-wg-wt2@icann.org <mailto:gnso-newgtld-wg-wt2@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@icann.org <mailto:steve.chan@icann.org> mobile: +1.310.339.4410 <tel:(310)%20339-4410> office tel: +1.310.301.5800 <tel:(310)%20301-5800> office fax: +1.310.823.8649 <tel:(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-e...>.
Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO <https://twitter.com/ICANN_GNSO> Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ <https://www.facebook.com/icanngnso/> http://gnso.icann.org/en/ <http://gnso.icann.org/en/> _______________________________________________ Gnso-newgtld-wg-wt2 mailing list Gnso-newgtld-wg-wt2@icann.org <mailto:Gnso-newgtld-wg-wt2@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2 <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2>
_______________________________________________ Gnso-newgtld-wg-wt2 mailing list Gnso-newgtld-wg-wt2@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt2