<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style>
<!--
@font-face
{font-family:"?? ??"}
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Cambria}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:Cambria}
.MsoChpDefault
{font-family:Cambria}
@page WordSection1
{margin:1.0in 1.25in 1.0in 1.25in}
-->
</style><style type="text/css" id="owaParaStyle"></style>
</head>
<body style="word-wrap:break-word; color:rgb(0,0,0); font-size:14px; font-family:Calibri,sans-serif" fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">
<div>Gustavo, </div>
<div><br>
</div>
<div>Thanks for providing the update to the URS High Level Technical Requirements. I have the following feedback:</div>
<div><br>
</div>
<div>1.<span class="Apple-tab-span" style="white-space:pre"> </span>The text for requirement 8 provides two options for handling a domain that expires while in URS Lock that focuses on allowing the URS Lock domain to be deleted (online or offline) after the
expiry and the subsequent auto renew. I believe that this is a corner case that adds some additional complexity. Allowing deletion of the URS Lock domain post-expiry makes the domain expiration date an element that must be considered when submitting the URS
complaint. If the main driver of this requirement is to allow the domain to be deleted within the auto renew grace period, the likelihood of the URS process exceeding the auto renew grace period is extremely low. Based on my calculation the maximum URS duration
is 45 days which matches our auto renew grace period of 45 days. The auto renew grace period of various TLD's could be shorter, but the auto renew grace period will most likely be a long enough period to cover the URS process. My recommendation is to not
do anything at expiry of URS Lock domains and allow the URS process to complete prior to allowing the domain to be deleted.</div>
<div>2.<span class="Apple-tab-span" style="white-space:pre"> </span>The text in requirement 9 "Registry Operator MUST offer the option for the URS Complainant to extend a URS Suspended domain name registrations for up to one year from the date the domain name
was Suspended", sounds like the renew command behavior needs to change for URS Suspension domains. The renew command should extend from the prior expiration date and not the date the domain name was suspended. I do not recommend making any change to the
renew logic for URS Suspension domains, since it will impact all of the registries and the registrars. I recommend that the registries allow for the renew of URS Suspension domains and leave it up to the Registrars to ensure that the renew is done at most
once for URS Suspension domains, by the URS Complainant, according to the Registry-Registrar Agreement. </div>
<div>3.<span class="Apple-tab-span" style="white-space:pre"> </span>Handling the URS Suspension of domains when the domain has child hosts. The redirect of the domain with child hosts could impact many other domains outside that TLD, since the resolution of
those name servers will not or should not work. If a registry shares the same pool of name servers across TLD's, the glue for the child hosts might be returned in DNS, but the resolvers might not trust cross-TLD name server glue. Consider the case of URS
Suspension domain foo.com with child host ns1.foo.com, where bar.net uses ns1.foo.com as a name server. A query for bar.net could include the IP addresses for ns1.foo.com, but since .com and .net are different TLD's the resolver could and most likely independently
attempt to resolve ns1.foo.com. Resolution of ns1.foo.com will not work if foo.com is redirected to the URS Provider's name servers. This issue impacts TLD's outside of that registry, since they most likely would not have the glue. There might be nothing
that can be done about potentially breaking resolution of other domains using child name servers of a URS Suspension domain, but we should discuss it and determine if there is anything that needs to be done to minimize the impact. </div>
<div>4.<span class="Apple-tab-span" style="white-space:pre"> </span>A related topic to #3 is what to do with the child hosts when a URS Suspension domain is auto-deleted / auto-purged at expiry. In our registries, a domain cannot be deleted if there are child
hosts being used as name servers for other domains in our registry database. The registrars will typically rename the child hosts under another domain to allow for the domain to get deleted. My recommendation is to remove the serverDeleteProhibited status
at expiry of a URS Suspension domain instead of auto-deleting or auto-purging it, and allow the domain to auto renew. The Registrar can and will most likely go ahead and delete the domain during the auto renew grace period following the existing process that
they follow in deleting domains with child hosts being used as name servers for other domains. I recommend disallowing the use of the RGP restore command for URS Suspension domains that entered RGP after deletion. Without the ability to restore, the domain
will propagate through the RGP statuses (redemptionPeriod and pendingDelete) prior to getting purged from the registry, which is consistent with how domains are currently deleted. </div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Jim</div>
<div><br>
</div>
<div>James F. Gould</div>
<div>Verisign</div>
<div>Principal Software Engineer </div>
<div>jgould@verisign.com</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div id="divRpF590599" style="direction: ltr; "><font face="Tahoma" size="2" color="#000000"><b>From:</b> gtld-tech-bounces@icann.org [gtld-tech-bounces@icann.org] on behalf of Gustavo Lozano [gustavo.lozano@icann.org]<br>
<b>Sent:</b> Tuesday, August 27, 2013 5:22 PM<br>
<b>To:</b> gtld-tech@icann.org<br>
<b>Subject:</b> [gtld-tech] Second version of the URS High Level Technical Requirements for Registries and Registrars<br>
</font><br>
</div>
<div></div>
<div>
<div>
<p class="MsoNormal">Colleagues,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Attached you will find the second version of the "URS High Level Technical Requirements for Registries and Registrars" and a redline version of the document.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">This second version incorporates the feedback obtained from the conference call on August 07.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">We appreciate your feedback. Please send your feedback to the list or in private.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Based on the feedback in this list, a new conference call may be required or this version may be published as the final version.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Registry Operators will know the name servers deployed by the URS providers soon, in order to allow Registry Operators to create host objects (if necessary).</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thank you,</p>
<p class="MsoNormal">Gustavo</p>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</body>
</html>