[SLE Team] {SPAM/L} RE: FW: SLEs - Working Draft

Wed Aug 5 23:30:48 UTC 2015

Thanks for the response Kim. I'm sorry to hear you were blindsided by the
email discussion, I thought we were at a place where the WG team members
were being asked to contribute.  I greatly appreciate the work you and Adam
have done to this point, and in no way am I blaming IANA for any of the
confusion around my example. Rather the intention is to point out examples
of issues from a recent experience with items not covered in the draft.

On Wed, Aug 5, 2015 at 9:43 AM, Kim Davies <kim.davies at icann.org> wrote:

> Hi Elaine, Hi all,
>
> Again, apologies if I don’t have the full context of this email exchange.
> Comments below.
>
> 1. In Assumptions, Section E, Add "email requests" to the change request
> submission types, along with metrics and reporting.
> Background:
>  Donuts (along with our backend operator, as well as our DNS provider)
> recently transitioned and migrated a live new gTLD from another registry
> operator, which had contracted with a different backend operator and DNS
> provider (Category III in the SLE doc). The legacy operator had an RZM
> credential but our arrangement was for Donuts to handle the migration with
> very little involvement from the legacy operator. (This same scenario could
> exist in the case of an EBERO migration). Because the legacy operator had
> the RZM credential, but Donuts performed all of the migration work, change
> requests to IANA were not submitted via the RZM portal. Rather, they were
> submitted via an email request to rzm at iana.org.  Obviously the review of
> the email request, confirmation of receipt, and follow up communication was
> not part of the automated system and did not occur via the RZM portal. In
> addition, the TLD did not "appear" in the Donuts RZM portal until well
> after the sponsoring organization AND DNS change requests were processed
> and completed.  We were in a sticky spot because contractually we were the
> registry operator but had no ability via the RZM to self-manage the TLD.
> This example of service via email communication is timely and the same
> issue will soon be repeated in another TLD transition. In an era of TLDs
> changing hands as rapidly as they are being delegated or launched, there is
> a strong case to include in Assumptions, Section E, email submission as a
> means for change requests, with response time metrics, as well as inclusion
> of the metrics in reporting.
>
>
> Can you explain a little bit more about how you foresee this working?
>
> If Donuts is the proposed recipient of a delegation, under the current
> procedures it is not the officially recognised manager until such time as
> that change request is implemented (i.e. in the current situation, NTIA has
> authorised such a change, and the change has been effected.) What is
> described as the “legacy operator” above is, in fact, the “current
> operator” until the conclusion of the IANA change request. I am not sure if
> you are suggesting that Donuts should have the ability to use RZMS to
> modify another entity’s domain.
>

Donuts acquired a live new gTLD via an auction. The commercial terms
directed that Donuts would manage the transition (lawyers didn't ask
beforehand about transition / migration process). So the legacy operator
thought once the contract was signed their obligations were
done.  According to my records the assignment was approved by ICANN on May
26th, but the TLD didn't show up in our RZM portal until June 18th. We had
no visibility into what happened in between. Was it stuck with NTIA? Should
that part be included in an SLE?
We were under a tight deadline to take over services by June 30th.  So we
were trying to action change requests via email since the TLD wasn't in our
portal. They old operator did not submit any change requests via their RZM
portal, rather they expected Donuts to send in the requests (we were only
able to do so via email.  Luckily they were cooperative and approved the
change requests when received during the three weeks of limbo, even though
it was now "our" TLD).
I can see something like this happening in an EBERO situation as well,
where a legacy operator just washes their hands of the thing.

So I'm asking for two things: 1. That email as a means of change requests
be added to the SLE (right now it only includes RZM or fax/phone) 2. That
as soon as ICANN affirms the assignment of a TLD from one operator to
another, IANA moves the TLD to the new sponsor's RZM portal.

>
> To be clear, I am not opposed to having SLEs for email submission,
>
Excellent. This is just an example of a situation where email was the only
option.

> but I’d like to better understand the use cases where it assumed the email
> is actually a normal or desirable operation. Our goal has been to automate
> the submission processes as much as possible such that you shouldn’t have
> to rely on email. The need to use email should be limited as much as
> possible to circumstances where it is basically customer preference, rather
> than because the automation system inhibits a TLD manager managing their
> own domains.
>
That would be fantastic.

> The assumptions have been circumstances where the incumbent manager should
> not be involved in the transfer should be rare indeed.
>
I think the assumptions then do not account for the real-life scenario I've
described?

> Indeed in the context of ccTLDs, the FOIWG discussions have made it clear
> the incumbent manager has a primary role to play in any transfer except in
> extreme circumstances.
>
That obligation is lacking in the new TLD registry agreements / transition
process. If the operator is no longer contracted to ICANN to manage the TLD
they have no impetus but goodwill to participate in the process. Just an
observation, not asking for you to fix.

>
> If there is a use case where a non-credentialed party should be able to
> submit change requests for a TLD they do not manage, we would like to
> automate that process too. The anecdotal feedback I’ve received from TLD
> managers has typically been in the opposite direction, submission of change
> requests should be explicitly restricted to only being able to be submitted
> by the current manager.
>
I think I've provided a pretty strong use case.

>
> Agreed, I will make the necessary changes.
>
> 2. In Assumptions, Section K, categorization of change requests, it
> appears as if each category will have a different SLE.  Please add "IANA
> notice to customer of category type" as a requirement.   If IANA informs a
> customer of the type of request they are processing, the registry operator
> can better plan timelines for things like DNSkey changes, NS updates, etc.
> According to the chart, the first four categories will have metrics a
> customer can refer to and possibly depend on, but the Cat 5s will not. In
> this case it is essential that the registry operator be aware of the
> uncertainty of the turn around time.
>
>
> It is worth noting that the applicable category is almost wholly in the
> hands of the customer, based on what they have requested. It may also be
> worth noting the the categorisation may change throughout the life of a
> change request.
>
> Makes sense, so it would be great if the categorization was tracked
throughout the process, with a notice of update if it changes categories.

> 3. In Assumptions, Section L, please confirm that the X in the box
> indicates a defined SLE is to be determined as part of our work. If not,
> what does the X mean? Yes the X in the box indicates that the step is
> applicable to the process and will have a defined SLE.
>
>
> My understanding is the X in the box only indicated that the step is
> applicable to the process. My assumption is that for each X there will, in
> fact, be typically more than one SLE for that category. However, for which
> measures there is an SLE is defined and what the SLE is is beyond the remit
> of the work we have done so far, and needs to be done in line with the
> DT-A’s principles at a later time (i.e. a later exercise based on analysis
> of collected data).
>
Thanks.

>
> 4. In Service Level Expectation, page 11, add a Service Area "Email
> Communication" "Response to sponsoring organizations that do not yet have
> RZM credentials for the TLD”
>
>
> Can you clarify what this means? Does this mean that every time any party
> emails IANA that is a prospective sponsoring organisation, there is an SLE
> associated with how long it takes to get a response? Is it only within the
> scope of certain process flows? How should this differ from IANA’s general
> commitment to respond to email enquiries within an SLE? I think there needs
> to be clarity exactly what is proposed to be measured, in what
> circumstances, and how that could be instrumented and fully automatically
> collected.
>
Just as there is an SLE for a response to an inquiry via the RZM, there
could be one for requests via email.
Essentially, if a change request has to be made via email instead of the
RZM, there should be SLEs on that process as well.  Several times
throughout our recent transition we were not sure if IANA had seen the
email, was actioning an item, what state it was in etc. We need visibility
similar to what is provided via the RZM, into the status of an email
request.

>
> Ok.
>
> 5. In Reporting Mechanisms, page 12, I assume the Status Tracker is part
> of the RZM interactive service. The same information should be made
> available to registry operators that are transitioning a TLD, that do not
> yet have access to the TLD via their RZM account. (This issue would go away
> if IANA provided access to the TLD via the RZM immediately upon the
> sponsoring organization being updated).
>
>
> Currently, IANA tries to provide credentials to TLDs as soon as
> practicable after a change request is complete. (It is currently a manual
> process so it sometimes takes a day or so, but it is something we are
> looking to fully automate in a future revision of RZMS as described in
> recent presentations at ICANN). That said, I am not sure how if that was
> instantaneous after updating the SO it would address your earlier concern.
> Unless this is an unrelated observation, you appear to wish for IANA to
> introduce a new service to allow you to login and view the status of a
> request* prior *to its completion if you are the potential beneficiary to
> it, but not the current manager of the domain?
>

Yes. Are there good reasons for not making all requests entirely public? If
only the sponsoring organization can make changes, does it matter if anyone
can see the changes taking place? Regardless, If ICANN says the new
operator is the beneficiary on May 26th the new operator should see the TLD
in their RZM portal within X hours. Not X weeks? Or is there some process
that happens in between the assignment and the update at IANA?

A thousand thanks.

-- 

[image: Donuts Inc.] <http://www.donuts.domains>
*Elaine Pruis*, Vice President, Operations
*Donuts Inc. <http://www.donuts.domains>*
10500 NE 8th Street, Suite 350, Bellevue Washington, 98004, U.S.A. |
Telephone: 509.899.3161
[image: Twitter] <https://twitter.com/DonutsInc>[image: Facebook]
<https://www.facebook.com/donutstlds>[image: Linked In]
<http://www.linkedin.com/company/donuts-inc->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt1/attachments/20150805/f62aad3b/attachment-0001.html>