<div dir="ltr">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.<div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 5, 2015 at 9:43 AM, Kim Davies <span dir="ltr"><<a href="mailto:kim.davies@icann.org" target="_blank">kim.davies@icann.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
Hi Elaine, Hi all,
<div><br>
</div>
<div>Again, apologies if I don’t have the full context of this email exchange. Comments below.</div>
<div><br>
<div><span>
<blockquote type="cite">
<div>
<div style="font-family:SourceSansPro-Regular;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div>
<div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
1. In Assumptions, Section E, Add "email requests" to the change request submission types, along with metrics and reporting.<u></u><u></u></div>
</div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
Background:<u></u><u></u></div>
</div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
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> </span><a href="mailto:rzm@iana.org" style="color:purple;text-decoration:underline" target="_blank">rzm@iana.org</a>.
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. <u></u><u></u></div>
</div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
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.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><div>Can you explain a little bit more about how you foresee this working?</div>
<div><br>
</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></div></div></blockquote><div><br></div><div class="gmail_extra">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?</div><div class="gmail_extra">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). </div><div class="gmail_extra">I can see something like this happening in an EBERO situation as well, where a legacy operator just washes their hands of the thing.</div><div class="gmail_extra"><br></div><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>
<div><br>
</div>
<div>To be clear, I am not opposed to having SLEs for email submission, </div></div></div></div></blockquote><div>Excellent. This is just an example of a situation where email was the only option.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>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. </div></div></div></div></blockquote><div>That would be fantastic.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>The assumptions have been circumstances where the incumbent manager should not be involved in the transfer should be rare indeed.</div></div></div></div></blockquote><div>I think the assumptions then do not account for the real-life scenario I've described?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>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></div></div></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>
<div><br>
</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></div></div></div></blockquote><div>I think I've provided a pretty strong use case. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><span>
<br>
<blockquote type="cite">
<div style="font-family:SourceSansPro-Regular;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div>
<div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<u></u><u></u></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="color:rgb(31,73,125)">Agreed, I will make the necessary changes.<u></u><u></u></span></div>
</div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<u></u> <u></u></div>
</div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
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.</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><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><span>
<div><br></div></span></div></div></div></blockquote><div>Makes sense, so it would be great if the categorization was tracked throughout the process, with a notice of update if it changes categories. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><span><div>
</div>
<blockquote type="cite">
<div style="font-family:SourceSansPro-Regular;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div>
<div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
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?<span style="color:rgb(31,73,125)"><span> </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>
</div>
</span><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></div></div></blockquote><div>Thanks. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>
<div><br>
</div>
<blockquote type="cite">
<div style="font-family:SourceSansPro-Regular;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div>
<div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
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”</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</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></div></div></div></blockquote><div>Just as there is an SLE for a response to an inquiry via the RZM, there could be one for requests via email.</div><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><span>
<br>
<blockquote type="cite">
<div style="font-family:SourceSansPro-Regular;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div>
<div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<span style="color:rgb(31,73,125)">Ok.<u></u><u></u></span></div>
</div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
<u></u> <u></u></div>
</div>
<div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">
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)"></span></div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span><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> <u>
prior</u> </i>to its completion if you are the potential beneficiary to it, but not the current manager of the domain? </div></div></div></div></blockquote><div> </div><div>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?</div><div><br></div><div>A thousand thanks.</div><div><br></div></div><div><br></div>-- <br><div><div dir="ltr"><br style="color:rgb(0,0,0);font-family:Times;font-size:medium"><br style="color:rgb(0,0,0);font-family:Times;font-size:medium"><div style="min-width:960px;min-height:82px;line-height:18px;margin:6px 0px;padding:8px;border-top-width:1px;border-top-color:rgb(153,153,153);border-top-style:dotted;border-bottom-width:1px;border-bottom-color:rgb(153,153,153);border-bottom-style:dotted;font-family:'Lucida Grande',Verdana,Arial,sans-serif;font-size:12px;color:rgb(153,153,153)"><a href="http://www.donuts.domains" title="donuts.domains" target="_blank"><img src="http://www.donuts.domains/images/D-99x124.png" alt="Donuts Inc." width="37" height="54" style="float:left;padding:2px 6px 0px 0px;border:none"></a><div style="padding:6px 0px 0px"><span style="font-size:14px"><strong style="color:rgb(51,51,51)">Elaine Pruis</strong>, Vice President, Operations</span><br><strong><a href="http://www.donuts.domains" title="donuts.domains" style="color:rgb(102,102,102);text-decoration:none;border-bottom-width:1px;border-bottom-color:rgb(204,204,204);border-bottom-style:dotted" target="_blank">Donuts Inc.</a></strong><br>10500 NE 8th Street, Suite 350, Bellevue Washington, 98004, U.S.A. | Telephone: <a href="tel:509.899.3161" value="+15098993161" target="_blank">509.899.3161</a><br><a href="https://twitter.com/DonutsInc" target="_blank"><img src="http://www.donuts.domains/images/social_twitter_box_white_512.png" alt="Twitter" width="30" height="30" style="float:left;margin:2px 4px 0px 0px;border:none"></a><a href="https://www.facebook.com/donutstlds" target="_blank"><img src="http://www.donuts.domains/images/social_facebook_box_white_512.png" alt="Facebook" width="30" height="30" style="float:left;margin:2px 4px 0px 0px;border:none"></a><a href="http://www.linkedin.com/company/donuts-inc-" target="_blank"><img src="http://www.donuts.domains/images/social_linkedin_box_white_512.png" alt="Linked In" width="30" height="30" style="float:left;margin:2px 4px 0px 0px;border:none"></a></div><div style="clear:both"></div></div><br style="color:rgb(0,0,0);font-family:Times;font-size:medium"><br style="color:rgb(0,0,0);font-family:Times;font-size:medium"><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> </span><br></div></div>
</div></div></div>