[gtld-tech] URS Technical Requirements - version 3

Fri Oct 4 18:37:49 UTC 2013

Kal,

Thank you for your feedback,

Comments inline.

Regards,
Gustavo

On 9/30/13 5: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?

GL - Thank you, and we will provide a response soon, I want to focus on
the technical related questions/comments.

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

GL - Thank you, and we will provide a response soon, I want to focus on
the technical related questions/comments.

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

GL - Agree. If URS provider supports DNSSEC, key data and DS data will be
provided. Version 1.0 to be published on the new gTLD microsite will
include this.

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

GL - Thank you for the suggestion. The text in version 1.0 will be:

The Registry Operator MUST promptly notify the URS Provider via email if a
URS
Locked or URS Suspended domain name has been: (a) deleted or (b) purged
(if the
Registry Operator implements Redemption Grace Period (RGP)).

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

GL - Yes, the additional year is not subject to the registration period
being 12 months or less. The standard renew verb is enough, there is no
need for extensions or new verbs.

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

GL - Registrar Requirement 2 deals with URS locked domain names and
Registry Requirement 11 deals with URS suspended domain names.

The purpose of Registry Requirement 11 is:

* Deactivate serverDeleteProhibited in order to allow Registrars delete a
URS Suspended domain name following the normal domain name cycle. A URS
Suspended Domain shall be deleted (an later purged, if RGP is used) after
expiration.
* Disambiguate the serverUpdateProhibited behaviour regarding restore for
URS. RFC3915 extends the update verb for restoration, and in some SRSs the
serverUpdateProhibited prohibits restore and in other is considered a
different verb.

>-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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5045 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20131004/0ad0aa23/smime.p7s>