[gtld-tech] URS Technical Requirements - version 3

[Kal Feher]

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.

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

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

Kal Feher
Enterprise Architect
ARI Registry Services



From: gtld-tech-bounces at icann.org [mailto:gtld-tech-bounces at icann.org] On Behalf Of Gustavo Lozano
Sent: Tuesday, 24 September 2013 10:52 AM
To: gtld-tech at 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