[gtld-tech] Version 1.0 of the URS technical requirements published

Wed Dec 4 10:12:14 UTC 2013

Jim,

I also have feedback :)

From: <Gould>, James <JGould at verisign.com<mailto:JGould at verisign.com>>
Date: Wednesday, 4 December 2013 7:54 am
To: Gustavo Lozano <gustavo.lozano at icann.org<mailto:gustavo.lozano at icann.org>>, "gtld-tech at icann.org<mailto:gtld-tech at icann.org>" <gtld-tech at icann.org<mailto:gtld-tech at icann.org>>
Subject: Re: [gtld-tech] Version 1.0 of the URS technical requirements published

Gustavo,

I have a few feedback items below:

  1.  The Note under URS Lock and Non-URS State (URS Rollback) states "If glue records were removed when the Registry Operator activated the URS Suspension, the Registry Operator MUST restore the require glue records".  The only changes to the domain when removing the URS Suspension is to attempt to add the previous name servers for a registry supporting the host object model in RFC 5731.  There are no expected changes of the referenced hosts as part of URS since the URS Lock and Suspension is on the domain and not the referenced hosts.

Glue records may have to be restored (to the DNS) upon re-delegation of the domain on transition out of Suspension, e.g. when the domain was delegated to subordinate hosts prior to suspension. I see no problem with this text.

  1.  If a host does not exist anymore that was previously referenced on a URS Rollback, the host will not be created and set as a name server for the domain .  The URS actions only apply to the domain objects and do not apply to hosts and contacts since there is a many-to-many relationship between domains and hosts, as well as domains and contacts.

I agree that there is a corner case whereby the previous delegation information cannot be fully restored, instead we will restore what we can.

I’d appreciate comment from ICANN here on what exactly should be locked. IMO the registry must lock registrant contact, and potentially the administrative contacts, to prevent changes to the Whois information, described in 6.2 of the URS Procedure. I’m impartial as to whether the technical contacts should be locked, however do not see how a change in technical contact information would violate the intent of the URS Procedure. I would also lock subordinate hosts acting as name servers, if only to maintain behavioural consistency with registries using host attributes (assming the hosts attributes will be “locked” with the domain?).

  1.  What should be done if a URS Lock request is made when the domain is already in RGP?  I'm assuming that the domain would not be put on URS Lock since RFC 5731 states that the "pendingDelete" status MUST NOT be combined with "serverDeleteProhibited".  How would the BERO handle this case?

This case also applies to a domain that is pendingTransfer and pendingUpdate (if supported by the server). Our approach is to lock the domain regardless and let the pending action take its course (a course that could be influenced by the registry operator).  I cannot think of a good reason for the restriction in the RFC5731;  we are begrudgingly “hiding” the serverDeleteProhibited on domain names with pendingDelete, and “hiding" serverTransferProhibited on domain names with pendingTransfer, only for compliance with the EPP specification. Note that this restriction applies to the EPP protocol only, and not other views of the data, such as web interfaces, or a registration data directory protocol.

  1.  How can an "Expedited Registry Security Request" ERSR be used when the BERO identifies a security or stability issue in implementing the URS Suspension of a domain name?  The use case that could be an issue is suspending a domain name that has child hosts that are name servers for other domain names (in zone or out of zone), which would cause the resolution of those domain names to fail .  The text for ERSR ( http://www.icann.org/en/resources/registries/ersr ) states the following.  The URS Suspension is not malicious activity and is not a temporary or long-term failure of one or more critical functions.  Please explain how ERSR can be used for this case and whether there is a more lightweight flow that can be used?  For example, can the BERO reply to the URS Suspension request with a request to hold the suspension pending review of the potential security or stability issue by the BERO and / or the URS Provider?
     *   …An Incident could be one or more of the following:
        *   Malicious activity involving the DNS of scale and severity that threatens systematic security, stability and resiliency of a TLD or the DNS;
        *   Unauthorized disclosure, alteration, insertion or destruction of registry data, or the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards;
        *   An occurrence with the potential to cause a temporary or long-term failure of one or more of the critical functions of a gTLD registry as defined in ICANN’s gTLD Registry Continuity Plan<http://www.icann.org/en/registries/continuity/gtld-registry-continuity-plan-25apr09-en.pdf> [PDF, 96K].

Thanks,

--

JG

[cid:264774DA-B8EE-4AC9-BDEF-36ACFCC2C78F]

James Gould
Principal Software Engineer
jgould at verisign.com<mailto:jgould at verisign.com>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: Gustavo Lozano <gustavo.lozano at icann.org<mailto:gustavo.lozano at icann.org>>
Date: Thursday, October 24, 2013 4:05 PM
To: "gtld-tech at icann.org<mailto:gtld-tech at icann.org>" <gtld-tech at icann.org<mailto:gtld-tech at icann.org>>
Subject: [gtld-tech] Version 1.0 of the URS technical requirements published

Colleagues,

Version 1.0 of the URS technical requirements document has been published at:
http://newgtlds.icann.org/en/applicants/urs

The direct download link of the document is: http://newgtlds.icann.org/en/applicants/urs/tech-requirements-17oct13-en.pdf

Regards,
Gustavo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20131204/14098421/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[24].png
Type: image/png
Size: 4109 bytes
Desc: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74[24].png
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20131204/14098421/3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B7424-0001.png>