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

[Kim Davies]

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<mailto: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.

To be clear, I am not opposed to having SLEs for email submission, 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. The assumptions have been circumstances where the incumbent manager should not be involved in the transfer should be rare indeed. 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.

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.

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.

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).

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.

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?

kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/dt1/attachments/20150805/47de9c7c/attachment.html>