[gtld-tech] URS Technical Requirements - version 3

[Gould, James]

Kal,

My comments are embedded below.

-- 
 
JG
 

 
James Gould
Principal Software Engineer
jgould at verisign.com
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com




On 10/9/13 11:20 PM, "Kal Feher" <Kal.Feher at ariservices.com> wrote:

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

Some text changes would help here, since registries that support auto
renew, should be required to provide a single notice at expiry / auto
renew.  Registries that do not support auto renew should provide a notice
at expiry.  Maybe the text could be updated to "The Registry Operator MUST
promptly notify the URS Provider via email if an applicable life-cycle
event occurs for a URS Locked or URS Suspended domain name including: (a)
expired ,(b) auto-renewed, (c) restored, (d) deleted, (e) purged.  An
applicable life-cycle event is based on the supported registry domain name
life-cycle.  For example, a registry that supports auto-renew MUST send a
single auto-renewed notice at expiry, while a registry that does not
support auto-renew MUST send an expired notice at expiry."


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

Good point.  The question for the list is whether restricting the use of
restore of URS Suspended domain names should be removed.  One issue is
whether registries prohibit the use of the restore command for domain
names with the serverUpdateProhibited status. I see restore as a different
action from update, but there is no standard serverRestoreProhibited
status to block its usage.  An argument could be made that the restore
command is meant to correct a mistake as you point out, so should it ever
be prohibited?  

>
>> 
>>-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 see initially that the notifications could be handled via the use of
registry URS reports that are then used as the basis for then sending the
signed e-mails.  One question is whether we could forgo the signed e-mail
notices from the registries by utilizing a standard set of reports that
are posted to ICANN via an extension of
draft-lozano-icann-registry-interfaces.  The interface between the
registries and ICANN is trusted, and the URS Providers could have a
similar trusted ICANN interface for getting the URS reports.  I'm not sure
if there is a security issue with all of the URS providers getting all of
the URS reports, but it would remove the complexity of dealing with the
PGP signed e-mails from the registries to the URS Providers.

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

Yes agreed.  Inclusion of full automation and an EPP interface might be a
significant waste, but the more manual the process is the more likelihood
there is for mistakes.  I see a mix of automation and manual steps at
least initially until the volume gets high enough to warrant the push for
a fully automated EPP interface.  There should be room for adjustment and
recovery while the process matures.  I might start work on drafting a URS
EPP extension  to at least get something down while the definition of the
flow is being worked out.  Let me know if you're interested in working
together on the draft.

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