<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="">
Dear Elaine,
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class=""><span style="font-family: SourceSansPro-Regular;" class="">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.</span></div>
</blockquote>
<div><br class="">
</div>
<div>No worries. I appreciate the constructive feedback and glad everything is getting back on track.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="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;" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I think perhaps the key disconnect here could be that the ICANN processes (i.e. dealing with GDD, the Portal, signing contracts, etc.) is wholly separate from IANA, and the two are not connected. This is by design. The community wants ICANN and IANA to
operate for practical purposes independently, as affirmed by this NTIA transition itself which is calling for further separation of IANA from the rest of ICANN. Therefore, the activity “approved by ICANN on May 26th” did not involve IANA and we were unaware
of it. Activities such as contract amendments and assignments don’t trigger anything to happen in IANA. After a contract is signed or an assignment is approved, a delegation or redelegation request is later submitted to IANA to start the IANA process, and
that process is conducted independently from the other parts of ICANN. When we receive a request to redelegate a gTLD, we look to make sure the the most recently posted signed contract for the given gTLD matches the proposed new sponsoring organisation.</div>
<div><br class="">
</div>
<div>I suspect tighter integration of those processes is probably off the table if a high level goal is to keep (and indeed expand) the ring-fencing of the IANA functions from the rest of ICANN.</div>
<div class=""><br class="">
</div>
<div class="">As an aside, in the context of ccTLDs, it is much the same. A ccTLD operator is expected to support them operating a domain, but rather than being contractual with ICANN, it is through gaining consensus from the local community (i.e. from the
government, community etc.) This is independent of the process of submitting a request to IANA to have a delegation or redelegation recognised and implemented. Here is a slide we show at ICANN meetings trying to illustrate the difference:</div>
<div class=""><br class="">
</div>
<div class=""><img apple-inline="yes" id="8AB9231E-D839-4B66-BCC0-BD57824B99CF" height="480" width="636" apple-width="yes" apple-height="yes" src="cid:DA6B366F-0C7D-4C4D-8671-B4808177E9DE" class=""></div>
<div><br class="">
</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="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;" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>We have a distinct process for EBERO where an EBERO event director can make an emergency change, if the conditions that are empowered by the contracts that gTLDs have signed.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="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;" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">So I'm asking for</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="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;" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">...</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" style="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;" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">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>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I think for the reasons above, I don’t think this can happen simply as they are two unrelated processes performed by different parts of the company. Also, because the assignment of a TLD does not mean IANA has done any of its policy reviews, to do so would
entirely pre-empt IANA’s processes and reviews. It might be an idea worth exploring, but it would be a significant shift that will need to be discussed in detail with the broader community.</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" style="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;" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">
<div style="word-wrap: break-word;" class="">
<div class="">
<div class="">
<div class="">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 class="">I think the assumptions then do not account for the real-life scenario I've described?</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I would think in the normal case, the proposed registry would need to do a coordinated transfer of registry assets (customer databases etc.) from the incumbent registry, coordinate a timely technical cutover etc. In the typical cases we see, both parties
are involved in any transfer until it is complete. I think this is the first time I have heard of the proposed registry making a commitment to the incumbent that they can walk away without further involvement prior to implementation of a redelegation. I can
appreciate though, in the context of new gTLDs, how the mixed signals have come about.</div>
<div><span style="font-family: SourceSansPro-Regular;" class=""> </span></div>
<blockquote type="cite" class="">
<div dir="ltr" style="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;" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">
<div style="word-wrap: break-word;" class="">
<div class="">
<div class="">
<div class="">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 class="">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>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I appreciate you raising the issue, it certainly is thought provoking for me. I think it needs to be considered and thought out, although perhaps outside the scope of the SLE discussion. :)</div>
<div><br class="">
</div>
<div>I will raise it with the other departments here and try to kick off some dialogue on it.</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" style="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;" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">
<div style="word-wrap: break-word;" class="">
<div class="">
<div class="">
<div class="">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 class="">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 class="">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>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>If it is just in relation to the initial submission of a CR, rather than any kind of email, I think it is a much more tractable problem we can define.</div>
<div><br class="">
</div>
<div>I did see in an earlier email a reference to <a href="mailto:rzm@iana.org" class="">
rzm@iana.org</a> — if this is the email address you are emailing this could be the problem. This is our mailer daemon and is used to detect bounces from the automated emails our system sends. Our official email address from root zone management, as listed in
all our documentation, for at least 15 years is and continues to be <b class=""><a href="mailto:root-mgmt@iana.org" class="">root-mgmt@iana.org</a></b>. If you email this email address you should get an almost immediate automated response with a ticket number
that will assure you your email was received.</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" style="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;" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">
<div style="word-wrap: break-word;" class="">
<div class="">
<div class="">
<div class="">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=""><span class="Apple-converted-space"> </span><u class="">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 class=""> </div>
<div class="">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?
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Many TLD managers have expressed the desire for confidentiality of pending requests, and that is the status quo expectation. Anecdotally, some of the concern relates to not advertising operational changes in advance, some relates to potential political
concerns in the case of ccTLDs for certain changes, and some relates to avoiding potential embarrassment. I could potentially see if the general public can look in and see a particular TLD is always failing its technical checks or other kinds of IANA review,
they may draw certain conclusions.</div>
<div><br class="">
</div>
<div>I think as staff we are entirely neutral on the topic, but a shift to transparency of pending requests would need to be canvassed and agreed by the affected communities (ccTLDs and gTLDs alike). [I should note that we did consult publicly on noting the
identity of proposed operators resulting from pending delegation and redelegation change requests. This is a very limited form of additional disclosure we are currently working with NTIA on finding a way to implement, but I don’t think is in line with the
broader disclosure envisaged here.]</div>
<div class=""><br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" style="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;" class="">
<div class="">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="">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>
</div>
</div>
</div>
</blockquote>
</div>
<div><br class="">
</div>
<div>Per above, the two processes are not linked. Following assignment (whether it was minutes or months later), someone at Donuts must have actively submitted a change request to IANA to commence a redelegation request. That will be the first time IANA knows
about it.</div>
<div><br class="">
</div>
<div>kim</div>
<div><br class="">
</div>
<div><br class="">
</div>
<br class="">
</div>
</body>
</html>