Kal, I have some follow on questions / comments to your feedback below. -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 9/30/13 8:42 PM, "Kal Feher" <Kal.Feher@ariservices.com> wrote:
Gustavo, thank you for the updated document and your responses to my and other's questions.
I have a follow up question before I comment on the document. I believe you may have misunderstood me when I asked about UDRP. I was actually thinking about the scenario where a domain is URS'd first (because it's a fast process) then, assuming the complainant is successful, a UDRP is sought (because it is permanent). What are Registrars and Registries supposed to do with UDRP results on domains that are currently URS suspended?
-Regarding the document
* Server lock will prevent the registrar from updating the domain in response to normal circumstances, for example to remove Whois privacy services as practised in UDRP cases, or to correct whois information (e.g. mistyped phone number or mailing address). What leeway is given to the registry operator to update registration information in response to out of band requests by registrars attempting to meet their obligations under other ICANN policies?
* URS Suspension: Registries may not accept DS data, instead accept only Key Data (RFC 5910). TThe URS provider should provide name server and both key data and DS data, allowing the registry operator to insert the relevant DNSSEC material into their provisioning systems.
The URS lock will lock the domain and not the referenced contacts. The domain cannot be updated to reference a different contact, but the contact object can be updated since there is not a 1-to-1 relationship between the domain and the referenced contacts. Good question related to what leeway the registry has in making updates based on out-of-band (e.g. call to Customer Support) requests. You are correct that if the URS Provider does intend to DNSSEC enable the redirect on a URS Suspension, where the URS Provider should be prepared to provide both the DS and Key Data to support both models (DS Data Interface and Key Data Interface) defined in RFC 5910.
*Registry Requirement 6: If the URS provider were to record whois at the time of notifying the Registry for an action, the only notifications required should be at deletion (c) and purged (d). All other information regarding state change events is already available to the provider prior to their occurrence. Otherwise Registries are going to either have to modify their system's workflow for URS'd domains (introducing software development costs and risks) or maintain an offline list of to-do items for each domain in URS suspension (introducing operational costs and risks).
The expired and auto-renew notices is really collapsed into a single notice for auto-renew with registries that support auto-renew. I'm assuming that the main registry component that requires update is the auto renew component to delete the serverDeleteProhibited status, which I call URS Lock Expired or URS Suspension Expired.
*Registry Requirement 10: Can you confirm that the option for the complainant to add an additional year to the registration period of the domain is not subject to the registration period being 12 months or less? A simple renew with no caveats would be my preferred approach.
My assumption is that the renew command at the registry level is unchanged.
*Registrar Requirement 2 and Registry Requirement 11 appear not to align with the other's purpose. I'd recommend removing Registry Requirement 11 entirely. Registrars are already obligated to only accept the one extra year (Rr requirement 3). Further applying systematic constraints (Ry Req 11) will simply prevent rectification of mistakes and will add to complexity.
Registrar Requirement 2 deals with URS Locked domains and Registry Requirement 11 deals with URS Suspended domains. The removal of the serverDeleteProhibited status at expiry / auto renew is consistent between URS Locked and URS Suspended domains. The support for restore is removed for URS Suspended domains only. Do you believe that URS Suspended domains should be able to be restored?
-A comment on this approach
I'm concerned that Registry system complexity is being added for what should be a reasonably simple process. Some of this complexity seems to be to relieve the URS provider of technical burdens (Requirement 6 and the absence of EPP support by the URS provider) and applying those burdens onto Registries. These changes will be costly for registries, either in terms of development or labour and will introduce risks. As things stand currently, to make these changes systematic, Registries will have to add "(if domain_urs == true) then." logic throughout the lifecycle for all domains, which is a concern for anyone interested in stability. I'd like common sense to prevail and we simplify these proposals significantly. Whilst the premise was circulated that making the URS provider use EPP was unnecessarily costly without an understanding of expected URS volumes, no such consideration has been applied to the impact of modifying every Registry system to include what is effectively a unique domain lifecycle.
The only registry component that requires a systematic change is the auto renew component to remove the serverDeleteProhibited status at auto renew of URS Locked or URS Suspended domains. Handling of server statuses should already be supported by the registries. Much of the complexity comes from the PGP e-mail interface, which includes PGP e-mail verification of notices from the URS Provider, and generation of PGP signed e-mail to the URS Provider.
I'd recommend removing the technical recommendations, proposing an alternative and greatly simplified work-flow that is carried out without lifecycle changes and committing to reviewing after N months/years based on observed URS volumes. If an EPP (or like) interface is required. We could write up a draft for EPP mapping of URS functions, which registries could switch to within 180 days (Ry Agreement includes provisions for this kind of service introduction).
If the volume warrants the use of EPP, I would be interested in participating in the development of a standard EPP extension.
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: Tuesday, 24 September 2013 10:52 AM To: gtld-tech@icann.org Subject: [gtld-tech] URS Technical Requirements - version 3
Colleagues,
Attached you will find the third version of the URS technical requirements and a redline of the previous version. This version includes the feedback received on this list. We are planning to publish this version as version 1.0 by late next week.
If you believe there are specific issues that should be addressed on the document, please send those specific issues to the list.
The URS Technical Requirements document is a collection of technical implementation guidelines of the URS Procedures that you will find at http://newgtlds.icann.org/en/applicants/urs.
Your feedback is appreciated.
Regards, Gustavo