ICANN - San Francisco
14 March 2011
New gTLDs Service Level Agreement


>>CRAIG SCHWARTZ:   So we're going to go ahead and get started on this
next session.  And thanks to all those who have spent the bulk of
their day hanging out in this room and are sticking around for one
more piece of information.

My name is Craig Schwartz.  I'm the chief gTLD registry liaison at
ICANN.  I'm also joined up front by Francisco Arias who is a registry
technical liaison with ICANN, and with Michael Young who is with a
company called Tiny Planet.

And the session today is on the Service Level Agreement in the draft
registry agreement that's part of the Applicant Guidebook.  And the
reason that we have convened this session today is to get community
input on a new direction that the Service Level Agreements are taking
for new gTLDs registries.

I see a lot of registry operators in the room, and most understand
that the way the Service Level Agreements work now is that registries
self-report the -- their performance on a monthly basis for various
parameters defined in their agreement.

The shift in direction here is to move from a self-reporting mechanism
to one that is conducted by independent external measurements, and the
exact way that that works is defined within the registry agreement and
specifically specification 6.

Part of the goal for having independent measurements is to have
measurements both from a perspective user perspective on the Internet
rather than the way it is being measured now from within registry
systems.  And what is primarily driving the need for quicker
information -- that is, rather than in the monthly reports that come
20 days after the end of a month to real time -- is to enable ICANN to
engage with registries when we see that performance metrics are not
being met that are defined in the SLA.  And in some cases, to enable
us to take emergency action to ensure the ongoing services of the
critical functions of a registry that are defined in numerous places
throughout the Applicant Guidebook.

What we will do today is have Francisco Arias present the
specifications as they are defined right now in the applicant, and
then we will have Michael Young produce -- or, excuse me, present a
proposal that's come from a group of interested parties from within
the community in response to those -- what's in the specification now.
And this is important to know that while there was a pretty big gap
between what we had proposed and what some of these interested
community members originally responded with, the gap has actually
closed a bit and there have been some concessions on both sides with
regard to both some of the metrics and some of how those metrics are
measured.

So after Francisco and Michael present the two presentations, we'd
really like to hear from folks, you folks out in the community, on
what you think about this and concerns that you might have or support
that you might have.  Because up until now, the conversation really
has been pretty limited to occurring between ICANN and this small
group of interested parties.

So we want to make this more of an open and transparent conversation
about the specs.

So I will turn the mic over to Francisco.

>>FRANCISCO ARIAS:   Thank you, Craig.

So what's the new gTLD SLA.  The Service Level Agreement is included
in the draft registry agreement for the new gTLDs.  It defines the
service levels that are expected for the new gTLDs in the critical
functions of the new gTLDs.

We will be talking a little bit later about what are those critical
functions of the new gTLDs.

And what this SLA -- this SLA allows the registrants and the Internet
users to know what they can expect from these services from the
registries.

The parameters that are proposed to be measured are availability,
which is defined as the time that the service is available during
monthly basis.  The response time, which is how long does it take for,
for example, the DNS server to respond to a query made from the
Internet.  And the third parameter to be measured is the update time.
That is, for example, how long does it take for an update to a domain
name to be presented in the WHOIS or in the DNS.

The service to be measured, we know that the registries have more than
these services that are shown here.  And as we know, when the new
gTLDs come, there will be some new services that will be presented.
But we know that there are these five critical functions that all the
registries will probably be offering.  These are DNS, DNSSEC, which
some people may say is the same thing.

We are given -- we are presenting these as two different services in
order to allow for possible differentiation, especially at the
beginning of the new gTLD rollout, since DNSSEC is just starting, at
least from the root.

The third service is WHOIS.  The fourth is EPP, which is the
provisioning system for the domains, which is what ultimately allows
the registrants to have the domains register, modified, et cetera.

And the fifth critical function is data escrow, which this is the
operation that has been there for a few years that requires the
registries to provide, let's say, a copy of their database which
contains the domain names, the contacts, et cetera, all the
information to a third party that holds that information.  And if
there were some certain conditions -- for example, catastrophe -- then
ICANN will have access to that information and could turn it to
another registry operator.

And this is the matrix that joins the three parameters that are going
to be measured against the five critical functions.

The other thing that is important to mention that was -- that Craig
was talking about is the change in how this is going to be measured.
As Craig said before, currently the registries measure themselves from
inside their registry, the registry networks.  And what we are
proposing now in this registry registrar is there will be probes over
the Internet which will measure these services.

The probes will be measuring the services every one or five minutes,
depending on the service.  For example, DNS and WHOIS will be every
minute and EPP five minutes, every five minutes.

The other important thing is that we will have centralize data
gathering for all this information so we can act upon any emergency,
for example, and contact the registry and see how to solve any issue
we identified.

And also, to, in extreme case, to do what is called an emergency
transition, which is also described in a document in the Applicant
Guidebook, which is basically to pass these registry services to an
emergency operator that will be in standby, contracted by ICANN, ready
to run any registry that goes into trouble.

This is how the SLA looks like.  We can see the different parameters
being proposed to be measured.  I'm not sure if that's visible.  I do
not intend to go over all the details here.

You can see that in the draft registry agreement or in the
presentation in the Web site.

And these are the emergency thresholds that I was talking about.  This
is when, for example, if a registry has four hours continuous downtime
on all the servers for the gTLD, we will be starting an emergency
transition to this emergency operator that will be on standby.

We have the same threshold for DNSSEC, four hours.  And the others, as
you can see, the other thresholds for other services.  EPP, five day
continuous down time; WHOIS, seven day continuous down time.  And in
data escrow, the draft agreement currently says if the registry misses
one full deposit or five differential deposits and there is no
response from the registry within 12 days, that's when the emergency
threshold is started -- the emergency transition.

And that's it.  Thank you.

>>MICHAEL YOUNG:   While I am waiting for my slides to come up, just a
little bit of explanation for those of you who don't know me already.

My name is Michael Young, and I worked in this industry for the last
ten years.  I was writing development in operations for Afilias for
six or seven of those years, and then ran product development
management for them for the last three years.

So I actually was the person running the teams that launched all five
of these critical services for dot info, and subsequent TLDs that
Afilias were involved with.  So that's how I came to represent the
group.  And though I have transitioned to another company, I have
offered to follow through on this because I think it's very important
to community.

So, we will just jump to the -- Let's get to the point.  Jump to the
next slide.

What are the issues we are going to go through, what is the solution
to these issues.

And these proposals, if you haven't read them already, I do advise you
to.  They are long, they are complicated.  And what I have done in the
revised SLA proposal is try to make it human readable and not just to
people who have a massive technologist background.  The introduction
is meaningful.

Okay.  The following issues to consider.  I am going to use a little
analogy here for those of you who aren't technical, and that is the
significant change in this SLA proposal, the one that's in the draft
book, changes the responsibility of EPP or registry transactions
monitoring from within the complex to outside the complex.  So the
analogy I am going to use is imagine if you were running a burger
shop, and you promised to your customer that they get a five-minute
hamburger.

Today, the way the registries operate, you come in, you order your
hamburger at the counter, and we serve it up within five minutes.

This proposal that's on the table now changes it to the counter for
the five minutes starting when you leave your house.

So this is public networks.

Now the test is coming across public networks, just like you left your
house.  I don't know where you live, I don't know what road you are
taking to get to the burger shop.  I don't know if you are going to
stop on the way and buy some shampoo at the drugstore but all of that
is supposed to be the responsibility of the registries and they have
no control over that in this monitoring solution.

So we have got some ideas to help with that in the next slide.

The second thing was we had to go and have a conversation, and thank
you, Craig.  You guys were very -- and Francisco.  You guys were very
helpful in explaining your motivations.  But all the things that Craig
said early on about why this proposal was done the way it was is not
clear in the written text.

So the revised proposal tries to explain the reasoning behind things.

The other thing that we need to look at here is, let's face it, we
always want to control costs and balance that with being responsible.
So the current proposal, the costs associated with this kind of
operational monitoring for ICANN will increase with every registry
that's added, with every new TLD that's added.  The complexity becomes
more and more difficult to manage as time goes on.  And to give you an
example of that, every EPP registry requires credentials to log into.
So imagine ICANN operating 40 or 50 monitoring nodes, and imagine a
thousand registries out there.  It gets better.  Not only do you have
to have the authentications for a thousand registries out there in
those 40 or 50 nodes, and how are you going to protect those
authentications out there in those 40 or 50 nodes, but registries also
only allow traffic from known source IPs.

So all 40 or 50 nodes have to be cleared with every one of those
registry operations.  So you have 500, a thousand.  The environment
and the industry goes to 1500, 2,000, 2,500.  You can just see how
complicated it gets to maintain that.

The current proposal had some basic flaws in some consideration around
DNSSEC operational concerns that have been addressed in the revised
proposal.

An example of that was a requirement added to propagate DNS out to all
name servers, all service addresses within 60 minutes.  Well, for
those of you who are familiar with DNSSEC, if you have to resign an
entire registry say the size of info or org or com, under those
circumstances 60 minutes doesn't cut it.  And there are other reasons
and considerations in managing any DNS operation where it may be very
appropriate to delay the propagation of DNS information to certain DNS
nodes, certain DNS service addresses.  And that wasn't reflected in
the original proposal, so we tried to add that into the revised
proposal.

Okay.  Some of the things we tried to do to solve this.  And I can't
go through it, I have a 13-page proposal so I will hit some ideas of
the highlights.

We tried to break the new proposal into concepts of SLAs, which is
performance consideration and conformance, against emergency
escalations.  There are two things we are trying to solve here.  We
are trying to make sure the user has a good experience, and that
there's some contractual compliance to that experience, which is fair.
And then we're trying to identify -- or ICANN is trying to identify
when someone is in trouble, when it's an emergency.  So we tried to
separate those concepts because they really are two different concepts
and can follow two different sets of concerns in the rules.

So when you read through the revised proposal, you will see that those
are broken out.  And emergency escalations are given fairly aggressive
consideration because everybody wants to know if there's a problem
brewing so they can help address it.  And by separating it from
contractual -- immediate contractual breach, you get a much higher
degree of cooperation and community support between different players.

Another way we support that concept is to break critical public
services and services between contracted parties into two ideas.  What
does that mean?  It means that we think of things as either a
registrant, consumer-based consumed service, versus something between
contracted parties such as a registrar and a registry.

So WHOIS and DNS falls into a public service.  And conveniently, are
not authenticated public services.

So ICANN can certainly monitor those independently and remotely, and I
think that's a very important thing for them to do because it is the
-- those are really the two critical services.  DNS by far, but WHOIS
is very important to a lot of agencies.  Particularly, we hear this
all the time, for law enforcement, that WHOIS is a crucial tool for
them.

So we then take EPP services, which is really between a registrar and
a registry, and we leave that monitoring between them.  So registries
would be expected to continue to monitor, state the results to stay in
conformance with performance metrics.  And another thing we added was
in the event that a registrar does have a problem with the registry
and they don't feel that they are getting their problem resolved
within a reasonable frame, they have an escalation path through to
ICANN to say, look, we are struggling, the registry operator is not
helping us with an activity or service problem that we are having.

Because registrants do not avail directly of EPP services to
registries.  So keep it where the problem lies.

Okay.  Again, the third point really just says we're treating
emergencies, and we're treating performance, contractual obligations,
as separate ideas.

And without ICANN having to worry about authentication tracking,
securing, and considerations with all those nodes, it reduces the
overall cost exposure over time.

Okay.  And mapping the solution to the proposal.  This is just a
little map for those of you who have not read the proposal.  As
promised we took section one and we explained the problem set.

Hopefully, in a meaningful way that everyone can understand, whether
or not you are highly technical.

Section two is further support of that, and that brings us our
definitions.

Section three breaks down to thresholds and emergency escalation
thresholds, which are not far different than what was suggested by
ICANN anyway.

So we're pretty close on those things.

And four throws out the methodology in great detail, as well as
references an attachment that gives a specific DNS test that's
suggested that covers both UDPTCP and straight DNS test and the DNSSEC
test.

Five is on reporting, and six really talks about the escalation
principles and responsibilities, which I think is a newer concept.
Not something that's been done in the past between ICANN and
registries and registrars, but certainly has been done on a volunteer
and cooperative basis in certain circumstances when there have been
issues in the past in the industry.

So this is just really a formalization of the intent, and that leads
me to my last slide.  I'm going to jump to the last point because I
think that's really the most important one on this slide, and that is
everybody -- registries, registrars and registrants -- have it in
their own self-interest to make this work, to make sure that the
experience is robust, to make sure that the customers have a good
experience.

If we don't change this proposal from its current nature, most new
TLDs will struggle to stay in contractual compliance and conformance
with this.  So it does need to change.  We are setting people up for
failure.

And again, further, if we're going to set successful criteria for
them, then the goals and objectives have to be clear and they have to
be in alignment with operational realities.

And lastly, of course, as always, this is a new endeavor for ICANN to
open basically an operations center to produce and maintain this type
of monitoring.  For those of you that don't know or haven't been
aware, for the last nine years I have been involved in operating
registries, ICANN has meant to or had the intention to build a DNS
monitoring tool system.  And it's in -- if you look back in time, you
will see that statement in registry agreements going back all the way
to 2001.  But that hasn't been built in that time.  And somehow, we
have managed to grow, flourish, and succeed without it at all.

Okay.

So that's all I have to say.  Thank you, everyone.

>>CRAIG SCHWARTZ:   Thanks, Francisco, and thanks, Michael.

So what we'd like to do is open up the floor to questions and comments
and statements, and also acknowledge that there's not a public comment
period running right now on -- well, on this particular document.  So
if you're interested in submitting something in writing, just send it
to registries@icann.org and we can then kind of filter it through the
process and, you know, act on it as we're working through the next
specification for the registry agreement.

Jeff.

>>JEFF NEUMAN:   Thanks.  Jeff Neuman with NeuStar.

I want to thank you guys for doing -- you know, working so hard on
this issue.  I think, you know, the Registry Stakeholder Group
certainly appreciates the work that Michael's done on our behalf.  And
we certainly thank ICANN for listening to our concerns.

I guess my question is -- I know Michael's proposed it, but what parts
of those proposals does ICANN agree with, not agree with?  What still
needs work?  You know, we'd like your feedback as much as, you know,
you're asking for ours, so that, you know, when it does go into the
next version -- I mean, I think what Michael's suggesting, obviously,
NeuStar, we've reviewed it, and we think it's a great document.  We
think it reflects what should address your concerns.

So is there feedback you can give us?

>>FRANCISCO ARIAS:   Yes, sure.  I think it's very positive some of
the points that are shown in that proposal, for example, the section
where the motivation for this is explained.  Also the reporting and
the escalation procedure are some things really, really positive.

So we -- I understand we are basically closing the issue about
monitoring publicly the DNS and WHOIS in the proposal.  So I guess the
main issue now will be EPP, shall it be monitored by ICANN?  Should
not?  And I guess that's the main issue right now.

>>JEFF NEUMAN:   So I think one of the things to discuss for people in
the room is, you know, why is it such a concern -- you know, it's
interesting, and we're just talking about certain people, registrars
have no SLAs to ICANN.  So a registrar can operate however it wants.
The SLAs with respect to EPP, it doesn't affect whether an registrant
is up, whether the Web site is up.  Really, all it affects is the
ability to register, renew, modify a name, delete a name.  But that
really doesn't impact the end user.

Certainly, you know, those should be monitored.  But as Michael was
talking about the difficulties and complexities of actually monitoring
EPP transactions from outside the firewall of the registry is
certainly very difficult and relies on a whole bunch of other things
that are outside the control of the registry.  So I'm not sure why --
you know, has anyone expressed to you the need that this must be done
by ICANN?  Just on EPP, not on the DNS or WHOIS.

>>FRANCISCO ARIAS:   Yes, the idea by monitoring EPP is EPP is what
allows registrants to eventually have access to their provisioning
system.  So we think that should be monitored by us so we know that at
least the registry is there, ready to accept the request from the
registrar on behalf of the registrant.

>>JEFF NEUMAN:   Right.  But with the escalation, I mean, if a
registrar doesn't respond -- if a registrar is having issues in its
interactions with the registry and is not getting the answers it needs
from the registry.  Then with the creation of the escalation, you'll
know about it.  It's not the end of the world if a registrant can't
add or modify or edit a domain name registration if they're out for an
hour or two hours.  You know?  It's not good.  It's not great.  But
you'll certainly know about it.  And we -- if our EPP -- if our SRS,
shared registration service, is down, we're going to know about it.
Registrars are not hesitant in calling us and letting us know.

>>MICHAEL YOUNG:   Jeff, I want to add to what you're saying, is
registry are already contractually obliged to announce, and in this
proposal, to escalate themselves to ICANN if they have service
interruption.

>>JEFF NEUMAN:   That's right.

>>FRANCISCO ARIAS:   The other thing is, we -- in order to be able to
use the emergency thresholds, we need to know really quickly when
things go wrong with the registry.  And one of the critical functions
is EPP.  So we want to know when the registry is not offering the EPP
service, when it's not available, so we can act in case of an
emergency.

>>JEFF NEUMAN:   But EPP -- sorry.  There's someone else at the mike.
I'll let them go and then come back.

>> Carry on.

>>JEFF NEUMAN:   I was just going to say, EPP, you can go back to the
chart that had the SLAs.  When the SRS is down, the shared
registration system is down, I mean, you know, the SLAs are pretty --
what is it?  The emergency threshold was some consecutive days, wasn't
it?

>> It was five days.

>>JEFF NEUMAN:   Five days.  So I would think even without ICANN
monitoring it, ICANN's going to know from a registrar, at least one
registrar, if SRS is down for five days.  I mean, I would think.
Right?

>>CRAIG SCHWARTZ:   Why don't we take that back.  You're making a
great point.  We're not going to solve it right here.  But it's
helpful information.

>>JEFF NEUMAN:   Okay.

>>CRAIG SCHWARTZ:   Thanks, Jeff.

>>GAVIN BROWNE:  My name is Gavin Browne, I'm from Central NIC.  I've
going to say most of what Jeff already said, so I won't re-cover the
same ground.

Obviously, if you've got a five-day window for your escalation,
monitoring the EPP system every five minutes is not really going to
get you much.

But what I would say is that as a registry operator who's not required
to have any sort of service-level agreement, but we have one anyway,
because we have an economic interest in providing a service to our
registrars.  No registry is going to voluntarily take their EPP system
down for extended periods of time because it's going to kill their
business.  So you have to recognize that perhaps there an economic
effect that means you don't have to worry so much about kind of
extensively monitoring things in depth and intensively.  You have an
escalation process.  The registrars are going to be on the ball.
They're going to do that monitoring for you.  As long as you can
maintain good communication between yourself and the registrars,
yourself and the registries, that will get you what you need to
escalate when there's a serious critical outage.

>>CRAIG SCHWARTZ:   Thank you.  Ram.

>>RAM MOHAN:   Hi, I'm Ram Mohan from Afilias.

Perhaps a little different from what the gentleman from Central NIC
was saying, I actually think that if you're ICANN, you do need to have
a view of what's happening at the registries.  So I'm actually coming
here to say the measures that you're proposing, the principle is
correct.  And I certainly would not depend -- if I were ICANN, I would
not depend upon registrars notifying registries notifying ICANN as the
notification mechanism, if you will.  Because this is serious stuff,
and it does need to be monitored.

To Jeff's point, I think you might want to think about maybe replacing
the EPP component with the DNS component, because that's really what
is critical.  That's what really matters in terms of end user impact
and consumer impact in the industry.  And that might be something that
has far greater relevance to the world as compared to EPP.

Clearly, EPP is just a contractual thing.  But as Jeff was saying, if
EPP is down, it doesn't make the news.  If the DNS is down and
significant domain names go down, that makes the news, and you may
have, you know, much greater impact as a result of doing that.

>>CRAIG SCHWARTZ:   So, Ram, are you suggesting that we should
continue to have an SLA for EPP, but just the measuring methodology
should remain as it is now?

>>RAM MOHAN:   No.  I was actually saying -- I was agreeing with what
Jeff was saying, that the EPP measurements, they are -- they feel to
me, as an operator, they feel like they're nice-to-have measurements.

The bottom line of, you know, EPP, whether you measure EPP or not,
registry operators make money by EPP being up, okay?  Registrars --
and there's a virtuous chain there, there's an economic benefit that
gets through.  Okay?  So it's in the best interest of those parties to
keep it up and running.

But if you look at the DNS, the impact on end users is much more
significant.  So what I was proposing is to not worry nearly as much
about EPP.

>>CRAIG SCHWARTZ:   Okay.

>>RAM MOHAN:   And to worry much more about DNS, because the impact is
much larger.

>>CRAIG SCHWARTZ:   Thanks.

Jeff.

>>JEFF NEUMAN:   Thanks.  And one thing that Eric just reminded me of,
you know, so I was only addressing the EPP as far as availability and
up time.  But if you go back to the -- just the regular SLAs, on there
is "EPP response time."  And the EPP response time is dependent on a
couple different things.  It's dependent on business model.  For
example, for dot travel, which has authentication that gets kind of in
the -- I don't me in the way, but it's in the middle of EPP response
time, so we have to actually check whether something's -- a change is
authenticated before actually responding.  So that would not
necessarily meet that SLA, but for a good business model reason.

The second thing is that it also doesn't take into account the amount
of -- what really impacts the end user is not only what the registry
does, but it's the registrar's ability to, like, for example, form EPP
commands, send those commands to the registry, take the information
back from the registry, and translate that into the action on behalf
of the registrant.

So even if the registry's making complete -- is fulfilling its
response time completely, you still -- the end user could still be
impacted, if not greater, by the registrar's actions as a result of
that.  So kind of adding on to what Ram said, these are nice-to-haves,
and they're probably pretty important between, you know, for example,
if back-end operators and a front-end operator were going to certainly
commit, as I'm sure Afilias and every other one, is going to commit to
certain service levels with their front-end registry.  It's important
as far as a contractual commitment.  But from an end user standpoint,
I don't believe that's something that really needs to be monitored
from -- internally, or I should say monitored by ICANN externally in
the internal system, yeah.

>>CRAIG SCHWARTZ:   Thanks, Jeff.

>>GAVIN BROWNE:  Yeah, sorry, Gavin Browne again.  Just to follow on
from what Jeff is saying, something that occurred to me when he was
talking about the EPP response time is, if you're a TLD that's in a
sunrise process, there's a good chance that when a create command
comes in, it's going to have to go out to the I.P. clearinghouse.  And
that means that your service level is basically proportional to the
level of your trademark clearinghouse.  So you have to make sure if
you're going to be applying these very strict service levels, you kind
of have to have caveats for these special conditions like the sunrise.

I agree absolutely with Ram that this is a nice thing to have.  We do
have remote monitoring of our EPP system as well.  We have three
different locations all over the world, and we check our response time
for each of the commands we do.  It's really important for us for kind
of measuring the health of the system, for knowing how we're doing in
terms of keeping up with capacity, knowing how much capacity to
provision in the future.  So we do this voluntarily because we need
this information for our business.

And I would agree that, you know, from a research and operational
analysis perspective, it's worth doing these things.  I'm not sure
it's worth baking them into a service-level agreement, though.  But I
do think it's important information to have, which is why we gather it
in the first place.

>>CRAIG SCHWARTZ:   Thank you.

Do we have any additional -- yes, I seen Greg Aaron stepping up to the
mike.

>>GREG AARON:  Greg Aaron from Afilias.

Currently, when we turn in our ICANN reports, those are published.  So
our self-reporting figures are publicly available.

Is ICANN planning on publishing these numbers for the new TLDs?

>>CRAIG SCHWARTZ:   So we will -- we will publish -- I mean, I think
the way the proposals come from Michael Young and the interested
parties is that there's some type of consultation about the
publication of those measurements.  And I would think just as the
current monthly reports are on a 90-day delay, that there would have
to be some consideration for that as well, for the same reasons, that
reports are as they are now.

>>Greg Aaron:  Right.  One of the observations is, if you're measuring
over the Internet, you'll get varying results, depending on where your
probes are and where the registries are.

So one of the potential effects of publishing the information is,
you're going to give comparisons between registries, which may not be
necessarily equal.  And, of course, those registries are going to be
competing with each other and so forth.

And so, you know, one of the -- one of the problems is comparing
apples to oranges and then putting that out there and people not
understanding what the numbers actually mean.

>>FRANCISCO ARIAS:   Just want to -- Ram was saying everyone will go
to Marina del Rey.  I just want to make clear that the idea is to have
probes all over the Internet, not just in Marina del Rey.

>>RAM MOHAN:   (off mike) -- San Francisco.  My point, really, was
that in what Greg was saying, the user behavior for those registries
that may be marginal would be to relocate their server locations to be
near wherever your monitoring locations are.  Because it's cheaper to
do that in some cases than to try and, you know, get performance
gains.  That's all.

>> Things are coming out of my head in kind of bits and pieces, so I
keep coming up.

If you could go back to the emergency escalation slide, one of the
things that occurs to me is there are situations where you have an EPP
unavailability that could have significant impact on users.  The thing
that comes to mind is if your registry isn't auto renew, it's auto
delete, and if registrars can't renew domains, then you might find
that domains go dark, which is a bad thing.

But there is a possibility that rather than doing a failover at that
point, that the registry might be able to put mechanisms in place to
mitigate those effects.  So, for example, ICANN, if I know that
there's going to be a temporary outage on our registry system or if
it's over Christmas, for example, when we don't have 24/7 support in
our office, I can just turn off domain deletions so that anything that
was due to delete during that time, I just kind of leave it in the
system, and we catch up at the end of the holiday period.  So it may
be worth looking at kind of less extreme alternatives to doing an
emergency failover.  I guess that the escalation process has that.  So
maybe I haven't seen it in the SLA itself.  So there are things that
registries can do if they're having a problem with their front-end,
they can turn switches on in the back-end to keep things running in a
diminished but still mostly functional state.

>>CRAIG SCHWARTZ:   So do we have any other -- any other additional
comments?

This discussion has been helpful.  Some of it we've heard before.
Some of it is new.  Ram just mentioned these, you know, unintended
circumstances.  And for the nontechnical people in the room like me,
that actually makes a lot of sense and is not something that I thought
about before.  So I appreciate those kind of remarks.

Michael, or Francisco, any closing remarks?

I see Norm Ritchie coming to the mike.

>>NORM RITCHIE:  Yeah, just wanted to make one quick comment.  It's
Norm Ritchie, ISC.

We saw on there 100% availability of DNS, which I believe is a correct
thing.  However, that's not possible to measure that.  It's a good
goal, but not possible to measure it.

You couldn't do that with probes.  You can't measure zero down time.
You can report it.  But I don't think it could be measured by a probe.
You'd have to probe continuously.

>>FRANCISCO ARIAS:   I guess you mean from one (inaudible) point of
view.

>>NORM RITCHIE:  No.  You'd have to have continuous probing to ensure
that it was always available.  Which is just not a --

>>CRAIG SCHWARTZ:   I understand what you're saying.

>>NORM RITCHIE:  However, I agree with the target.

>>CRAIG SCHWARTZ:   Thanks, Norm.

Oh, you switched sides.  Okay.

>>What Norm is basically saying is there's an infinite amount of
difference between 99.9999% and 100%, because to guarantee 100% in a
mathematical sense, you have to guarantee the delivery at the resolver
side of every single query that gets sent to the server.  So it's a
kind of mathematical limit that prevents you from saying it.

>>RAM MOHAN:   (Off mike)

>>CRAIG SCHWARTZ:   Yeah, right.

>> That's what I mean, is if you're -- if you want 100% SLA, every
single packet from every single result has to be logged and recorded
as arriving at the destination, which is nice, but very hard.

>>CRAIG SCHWARTZ:   Werner.

>>WERNER STAUB:   Yeah, Werner Staub.  Just a question, what is the
rationale of having such a high availability requirement for EPP for
all the registries?

If a registry has a small number of changes to the zone file, why do
we have to respond that fast?  It's actually a useless cost imposed on
a registry operator in certain cases.  There's absolutely no
justification.

>>FRANCISCO ARIAS:   Actually, the SLA is based on the current SLAs
for -- I'm sorry, the SLAs for the current gTLDs.

>>WERNER STAUB:   I know, the current gTLDs typically have a certain
volume.  You talk about things that have a million domains, that have
5 million domains.  And you may well have registries that have, for
good reasons, much smaller volumes.  And there is no reason to have
that.

It is important to have the DNS 100% available.  But for you to be
able to make changes and possibly have to wait half an hour, who
cares?  There used to be updates in the past, one of the biggest
registries, maybe the biggest, you know, whenever you send the thing
through, it would only have an effect once or twice a day.  So there
is no reason to have such a high availability requirement.

>>CRAIG SCHWARTZ:   Thanks, Werner.

It seems like we're spurring some more interest here.  Now lots of
folks coming to the mike.

>> My name is (saying name) and I have dot FR, the AFNIC is the
manager of dot FR, the ccTLD, and we are also interested in gTLDs.

My question, actually, is for those techies in the room.

Can we go back to the escalation slide, please.  Because I was
intrigued by DNSSEC.  And then suddenly I realized, we're speaking
about emergency transfer of registry operations.  And I am wondering,
does that work with the DNSSEC signed registry?  How does that work?
Because I've always understood that you don't do transfers if you
don't have two private keys and so on and so forth.

So my question is, is an emergency transfer possible with a registry
that is DNSSEC-signed?

>>RAM MOHAN:   Yes.

>>FRANCISCO ARIAS:   Yes, indeed.

>> How does that work?

>> You re-sign the entire zone.

>>RAM MOHAN:   We should talk about this offline, but it's definitely
possible.

>> It will take a long time.  First, you have to revoke the DS in the
root.  How long does that take in then you have to introduce the new
operator.  We're talking about a week.

>> That's what I thought.  Thanks.

>>CRAIG SCHWARTZ:   Jeff.

>>JEFF NEUMAN:   Yeah, I think that's a good point that was just
raised about how long it would take for emergency transition.  Because
then you'd actually have to involve IANA, too, and the Department of
Commerce.

One of the observations I wanted to make, and it's a shame, 'cause it
-- a lot of people here from the last discussion, so maybe this is for
the record, but there are members of the GAC that are arguing for
lowering the technical standards for -- to encourage those in
developing countries to apply, in addition to providing funding.  And,
you know, look, this kind of stuff isn't easy, and I'm not sure --
there's a correlation between.  You can't lower the technical
standards and lower the -- you can't lower the technical standards but
then expect them to meet these kind of SLAs.  So, I mean, I think it's
important to give the JAS group and others, and certainly the
Governmental Advisory Committee, that it doesn't work that way,
because they're demanding that these registries stay up, and they're
demanding accountability and compliance and contract compliance, yet
they also, under their breath, say, "But we need to lower the
technical standards to allow developing countries to apply."  You
can't really have both.

>>CRAIG SCHWARTZ:   Thanks, Jeff.

I'm going to give Ram the last word.  And I've been told that we're
over time.  And in this hotel, you can't go over time without
incurring lots of additional costs.  So we need to wrap up.

So, Ram.

>>RAM MOHAN:   Thanks.  I'm going to speak kind of wear an SSAC,
Security and Stability Advisory Committee, hat on.  And I'd like to
say that I think it's important that the technical standards not get
lowered.  You know, it may be a small registry today, but the
expectation of the end user is that the registry run well and the
registry be safe and be stable and be resilient.  And I think in those
areas, it's important to just keep the standard very high.  And, I
mean, the -- I think the world is looking to ICANN to ensure that it
provides the coordination and provides a bar that is pretty high.  And
I would strongly push back against any efforts to cut the standards
down.

>>CRAIG SCHWARTZ:   Thanks, Ram.

Thanks, Francisco, thanks, Michael, and thanks to all the participants
for staying on and contributing.  It's clear that we still have some
work to do together.  So as I said earlier, if you have additional
comments that you'd like to send in, just forward them to
registries@icann.org.  And thank you, and have a good rest of the
night.

[ Applause ]