[gtld-tech] URS Technical Requirements - version 3

Mon Oct 7 12:21:14 UTC 2013

Kal,

I have some follow on questions / comments to your feedback below.

-- 

JG

James Gould
Principal Software Engineer
jgould at 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 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.

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