[gtld-tech] URS technical requirements, comments and questions

Sat Sep 7 01:19:34 UTC 2013

Colleagues,

The following is a list of comments/questions related to the second version
of the URS technical requirements.

Your feedback is appreciated.

Comments from James Gould:

1. The text for requirement 8 provides two options for handling a domain
that expires while in URS Lock that focuses on allowing the URS Lock domain
to be deleted (online or offline) after the expiry and the subsequent auto
renew.  I believe that this is a corner case that adds some additional
complexity. Allowing deletion of the URS Lock domain post-expiry makes the
domain expiration date an element that must be considered when submitting
the URS complaint.  If the main driver of this requirement is to allow the
domain to be deleted within the auto renew grace period, the likelihood of
the URS process exceeding the auto renew grace period is extremely low.
Based on my calculation the maximum URS duration is 45 days which matches
our auto renew grace period of 45 days.  The auto renew grace period of
various TLD's could be shorter, but the auto renew grace period will most
likely be a long enough period to cover the URS process.  My recommendation
is to not do anything at expiry of URS Lock domains and allow the URS
process to complete prior to allowing the domain to be deleted.

GL - For UDRP there is a provision (3.7.5.7) in the
http://www.icann.org/en/resources/registrars/accreditation/eddp for handling
the scenario of active UDRP process during the end of the validity period.

Unfortunately the URS Procedures are silent about what happens if a URS
locked DN expires.

During our internal discussions, the conclusion was that the normal
registration lifecycle should be followed when the URS Procedures are
silent. The auto-renew grace period, as you mentioned may be shorter for
some TLDs and this will create corner cases for the Registrars and the
Registry Operator of that TLD, e.g. Is the registrar billed for the renew?
Who pays the renew? Is credit provided to the Registrar if the URS process
finalize and the registrant/complainant don't want the DN to be renewed?

The number of UDRP cases filled in the last month of the validity period of
a DN is low and we believe this is likely going to be the case for URS.

The proposal is to show a warning message when filling the URS procedure if
the domain name is within the last month of validity, explaining that the
domain name may be deleted during the URS process and the process will be
terminated.

2. The text in requirement 9 "Registry Operator MUST offer the option for
the URS Complainant to extend a URS Suspended domain name registrations for
up to one year from the date the domain name was Suspended", sounds like the
renew command behavior needs to change for URS Suspension domains.  The
renew command should extend from the prior expiration date and not the date
the domain name was suspended.  I do not recommend making any change to the
renew logic for URS Suspension domains, since it will impact all of the
registries and the registrars.  I recommend that the registries allow for
the renew of URS Suspension domains and leave it up to the Registrars to
ensure that the renew is done at most once for URS Suspension domains, by
the URS Complainant, according to the Registry-Registrar Agreement.

GL - The text needs to be clarified, as the idea behind Requirement 9 is
basically what you are proposing. This is the proposed new text:

Registry Requirement 9: In cases where a URS Complainant (as defined in the
URS Rules) has prevailed, Registry Operator MUST offer the option for the
URS Complainant to extend a URS Suspended domain name's registration (if
allowed by the maximum validity period of the TLD).  Registry Operator MAY
collect the renewal fee paid by the URS Complainant for the URS Suspended
domain name from the sponsoring Registrar of the domain name.

It's worth mentioning that in section 4, the following provisions are
defined:

The Registry Operator MUST specify in the Registry-Registrar Agreement for
the Registry Operator¹s TLD that the Registrar MUST accept and process
payments for the renewal of a domain name by a URS Complainant in cases
where the URS Complainant prevailed.

The Registry Operator MUST specify in the Registry-Registrar Agreement for
the Registry Operator¹s TLD that the Registrar MUST NOT renew a domain name
to a URS Complainant who prevailed for longer than one year (if allowed by
the maximum validity period of the TLD).

3. Handling the URS Suspension of domains when the domain has child hosts.
The redirect of the domain with child hosts could impact many other domains
outside that TLD, since the resolution of those name servers will not or
should not work.  If a registry shares the same pool of name servers across
TLD's, the glue for the child hosts might be returned in DNS, but the
resolvers might not trust cross-TLD name server glue.   Consider the case of
URS Suspension domain foo.com with child host ns1.foo.com, where bar.net
uses ns1.foo.com as a name server.  A query for bar.net could include the IP
addresses for ns1.foo.com, but since .com and .net are different TLD's the
resolver could and most likely independently attempt to resolve ns1.foo.com.
Resolution of ns1.foo.com will not work if foo.com is redirected to the URS
Provider's name servers.  This issue impacts TLD's outside of that registry,
since they most likely would not have the glue.  There might be nothing that
can be done about potentially breaking resolution of other domains using
child name servers of a URS Suspension domain, but we should discuss it and
determine if there is anything that needs to be done to minimize the impact.

GL - It's difficult to know which domain names depend on another domain name
as separate entities administer separate sections of the DNS tree. However,
this seems to be a corner case. It would seem unlikely that URS suspended
domain names will be used to define hosts of other domain names, as the
expectation is that these domain names are not used for legitimate purposes,
but we will work with URS providers to add some text that advises the
Registrant of the URS suspended domain name that he/she should notify other
Registrants which domain names may depend on the URS suspended domain name
to take the appropriate action.

4. A related topic to #3 is what to do with the child hosts when a URS
Suspension domain is auto-deleted / auto-purged at expiry.  In our
registries, a domain cannot be deleted if there are child hosts being used
as name servers for other domains in our registry database.  The registrars
will typically rename the child hosts under another domain to allow for the
domain to get deleted.  My recommendation is to remove the
serverDeleteProhibited status at expiry of a URS Suspension domain instead
of auto-deleting or auto-purging it, and allow the domain to auto renew.
The Registrar can and will most likely go ahead and delete the domain during
the auto renew grace period following the existing process that they follow
in deleting domains with child hosts being used as name servers for other
domains.  I recommend disallowing the use of the RGP restore command for URS
Suspension domains that entered RGP after deletion.  Without the ability to
restore, the domain will propagate through the RGP statuses
(redemptionPeriod and pendingDelete) prior to getting purged from the
registry, which is consistent with how domains are currently deleted.

GL - When creating the draft of the URS technical requirements, we followed
the strategy that if something is not clear in the URS Procedures, we should
follow the normal registration life cycle. Your suggestion follows this
strategy; therefore we believe your proposal is adequate.

The activation of serverUpdateProhibited during URS Lock and URS Suspension
should be enough to prohibit the restore from working, therefore there is no
need to specify that a Registrar should not send a restore command for URS
suspended DNs or that the Registry should disallow restore, correct?

Comments from Rubens Kuhl:

As the second version still shows issues that the community addressed in the
past for domain registrations, it seems to us that registries should handle
URS providers the same ways they handle domain registrars: thru EPP.
URS providers could have proper EPP credentials that would allow them to
make a limited set of transformations (URS Suspension, URS Lock, URS
Roll-back) to every domain in the registry (except for mandatory domains
like NIC or WHOIS).

Everything we are trying to do with e-mail have already been done with a
higher degree of process integrity thru EPP.

GL - The idea of using EPP has been discussed internally and was also
mentioned during the conference call. Defining EPP extensions, requiring
registries to modify their SRS implementations and requiring URS providers
to implement EPP may be over engineering if we don't know the volume of URS
procedures and the URS Procedures define email as the interaction mechanism.

In case that the volume of URS procedures is high and the community believes
that EPP support is required, ICANN is willing to consider transitioning the
process to EPP.

Comments from Kal Feher:

Under what circumstances would a name transition from URS Suspension to URS
Lock? I am referring to your Note under the definition of URS Lock.

I¹ve reviewed both the technical and non-technical requirements and neither
explain when this would occur.

GL - This is an unlikely scenario, and the purpose of the note is that if
this transition is required, the Registry Operator regenerates the glue
records.  

Also will there be further detail on how URS interacts with other processes,
such as UDRP?

GL- Section 3(g) of the URS rules define: A URS Complaint may not be filed
against a domain name that is part of an open and active URS or UDRP case.

Regards,
Gustavo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20130906/0536ba24/attachment-0001.html>
-------------- 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/20130906/0536ba24/smime-0001.p7s>