[gtld-tech] URS Technical Requirements - version 3

[Kal Feher]

James, thank you for the comments. I've responded inline with KF-




On 9/30/13 8:42 PM, "Kal Feher" <Kal.Feher at 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.

KF- Given the literal interpretation of requirements so far, I don't see any leeway in the text allowing for a collapsed (single) notice option. Perhaps a line can be added explicitly allowing this.

> 
>*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.  
KF-Yes, since confirmed.


> 
>*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?

KF-Yes, restores should be an option. Preventing a restore is redundant if a Rr is already restricted to only accepting a single renew (of 1 year). We (Rys and Rrs) are now prevented from rectifying mistakes in an orderly manner. If a restore (and restore report) is received, the Rr will be on record as to the reason for the request. If anything is untoward, that information can be used in future proceedings. However if the Rr genuinely makes a mistake and given the non-standard way they will receive renewal requests (could be 9 years after the initial proceeding and arriving outside any system they have) that isn't such a stretch, then the ability to restore will allow them to rectify without too much trouble. Preventing restore appears to be motivated by a desire to restrict gaming opportunities, not any explicit requirement for the URS procedures. Gaming is already prevented in the rules for Registrars, so we don't need to create an overly restrictive system to enforce it.

> 
>-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.
KF- To that I would add the need to either build into the registry or some other side system the notification requirements(which could be 10 years in the future- Ry req6). And we haven't yet heard how UDRP outcomes will interact with URS Suspension or lock.
>
>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.
KF-Volume is the trouble here. If it is too low, building systems to support this workflow will be significant waste. While registries may feel compelled to do so, many Rrs may not. The likelihood of making mistakes increases if these tasks are not automated, yet many of the requirements now prevent recovering from mistakes. Are we simply setting organisations up for failure? For low volume activities, we should really try to deliver the service using current functionality to avoid confusion. If volume increases enough then a URS EPP extension seems to be the consensus. The tech requirements don't seem to deliver either an effective automated service or a simple manual alternative.

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