Gustavo, Under what circumstances would a name transition from URS Suspension to URS Lock? I am referring to your Note under the definition of URS Lock. I've reviewed both the technical and non-technical requirements and neither explain when this would occur. Also will there be further detail on how URS interacts with other processes, such as UDRP? Kal Feher Enterprise Architect ARI Registry Services From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Gustavo Lozano Sent: Wednesday, 28 August 2013 7:23 AM To: gtld-tech@icann.org Subject: [gtld-tech] Second version of the URS High Level Technical Requirements for Registries and Registrars Colleagues, 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. This second version incorporates the feedback obtained from the conference call on August 07. We appreciate your feedback. Please send your feedback to the list or in private. Based on the feedback in this list, a new conference call may be required or this version may be published as the final version. 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). Thank you, Gustavo

As the second version still shows issues that the community addressed in the past for domain registrations, it seems to us that registries should handle URS providers the same ways they handle domain registrars: thru EPP. URS providers could have proper EPP credentials that would allow them to make a limited set of transformations (URS Suspension, URS Lock, URS Roll-back) to every domain in the registry (except for mandatory domains like NIC or WHOIS). Everything we are trying to do with e-mail have already been done with a higher degree of process integrity thru EPP. Rubens Em 27/08/2013, às 18:22:000, Gustavo Lozano escreveu:

Colleagues,

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.

This second version incorporates the feedback obtained from the conference call on August 07.

We appreciate your feedback. Please send your feedback to the list or in private.

Based on the feedback in this list, a new conference call may be required or this version may be published as the final version.

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

Thank you, Gustavo

<IRI_54420_v3_ICANN _ URS _ Technical Requirements Draft Final 26-08-2013.pdf><IRI_54420_v3_ICANN _ URS _ Technical Requirements Draft Final 26-08-2013-redline.pdf>

Gustavo, Can you please send around a word version of the document and we would be happy to do some redlines to assist with the discussion. Thanks. Jeffrey J. Neuman Neustar, Inc. / Vice President, Business Affairs From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Gustavo Lozano Sent: Tuesday, August 27, 2013 5:23 PM To: gtld-tech@icann.org Subject: [gtld-tech] Second version of the URS High Level Technical Requirements for Registries and Registrars Colleagues, 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. This second version incorporates the feedback obtained from the conference call on August 07. We appreciate your feedback. Please send your feedback to the list or in private. Based on the feedback in this list, a new conference call may be required or this version may be published as the final version. 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). Thank you, Gustavo

Gustavo, Thanks for providing the update to the URS High Level Technical Requirements. I have the following feedback: 1. 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. 2. 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. 3. 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. 4. 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. Thanks, Jim James F. Gould Verisign Principal Software Engineer jgould@verisign.com ________________________________ From: gtld-tech-bounces@icann.org [gtld-tech-bounces@icann.org] on behalf of Gustavo Lozano [gustavo.lozano@icann.org] Sent: Tuesday, August 27, 2013 5:22 PM To: gtld-tech@icann.org Subject: [gtld-tech] Second version of the URS High Level Technical Requirements for Registries and Registrars Colleagues, 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. This second version incorporates the feedback obtained from the conference call on August 07. We appreciate your feedback. Please send your feedback to the list or in private. Based on the feedback in this list, a new conference call may be required or this version may be published as the final version. 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). Thank you, Gustavo