<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Elaine, Hi all,
<div class=""><br class="">
</div>
<div class="">Again, apologies if I don’t have the full context of this email exchange. Comments below.</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div class="WordSection1" style="page: WordSection1; font-family: SourceSansPro-Regular; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div class="">
<div class="">
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
1. In Assumptions, Section E, Add &quot;email requests&quot; to the change request submission types, along with metrics and reporting.<o:p class=""></o:p></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
Background:<o:p class=""></o:p></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
&nbsp;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<span class="Apple-converted-space">&nbsp;</span><a href="mailto:rzm@iana.org" style="color: purple; text-decoration: underline;" class="">rzm@iana.org</a>.&nbsp;
 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 &quot;appear&quot; in the Donuts RZM portal until well after the sponsoring
 organization AND DNS change requests were processed and completed.&nbsp; 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.&nbsp;<o:p class=""></o:p></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
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&nbsp;Assumptions,
 Section E, email submission as a means for change requests, with response time metrics, as well as inclusion of the metrics in reporting.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Can you explain a little bit more about how you foresee this working?</div>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<div>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.</div>
<br class="">
<blockquote type="cite" class="">
<div class="WordSection1" style="page: WordSection1; font-family: SourceSansPro-Regular; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div class="">
<div class="">
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
<o:p class=""></o:p></div>
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
<span style="color: rgb(31, 73, 125);" class="">Agreed, I will make the necessary changes.<o:p class=""></o:p></span></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
<o:p class="">&nbsp;</o:p></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
2. In&nbsp;Assumptions, Section&nbsp;K, categorization of change requests, it appears as if each category will have a different SLE.&nbsp; Please add &quot;IANA notice to customer of category type&quot; as a&nbsp;requirement. &nbsp; 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.</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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.</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="WordSection1" style="page: WordSection1; font-family: SourceSansPro-Regular; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div class="">
<div class="">
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
3. In&nbsp;Assumptions, Section&nbsp;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?<span style="color: rgb(31, 73, 125);" class=""><span class="Apple-converted-space">&nbsp;</span>Yes
 the X in the box indicates that the step is applicable to the process and will have a defined SLE.</span></div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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).</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="WordSection1" style="page: WordSection1; font-family: SourceSansPro-Regular; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div class="">
<div class="">
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
4. In Service Level Expectation, page 11, add a Service Area &quot;Email Communication&quot; &quot;Response to sponsoring organizations that do not yet have RZM credentials for the TLD”</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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.</div>
<br class="">
<blockquote type="cite" class="">
<div class="WordSection1" style="page: WordSection1; font-family: SourceSansPro-Regular; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div class="">
<div class="">
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
<span style="color: rgb(31, 73, 125);" class="">Ok.<o:p class=""></o:p></span></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
<o:p class="">&nbsp;</o:p></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;" class="">
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).<span style="color: rgb(31, 73, 125);" class=""></span></div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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<i class=""> <u class="">
prior</u>&nbsp;</i>to its completion if you are the potential beneficiary to it, but not the current manager of the domain?&nbsp;</div>
<br class="">
</div>
<div>kim</div>
</div>
</body>
</html>