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
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. 2. 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. 3. 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? 4. 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-...> [PDF, 96K]. Thanks, -- JG [cid:264774DA-B8EE-4AC9-BDEF-36ACFCC2C78F] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> Date: Thursday, October 24, 2013 4:05 PM To: "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@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
Jim, I also have feedback :) From: <Gould>, James <JGould@verisign.com<mailto:JGould@verisign.com>> Date: Wednesday, 4 December 2013 7:54 am To: Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>>, "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@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-...> [PDF, 96K]. Thanks, -- JG [cid:264774DA-B8EE-4AC9-BDEF-36ACFCC2C78F] James Gould Principal Software Engineer jgould@verisign.com<mailto:jgould@verisign.com> 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> Date: Thursday, October 24, 2013 4:05 PM To: "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@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
James, My feedback to your feedback is below. -- JG [cid:3499AFC8-31AC-425A-AA8B-965E3FBEF2F6] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: James Mitchell <james.mitchell@ausregistry.com.au<mailto:james.mitchell@ausregistry.com.au>> Date: Wednesday, December 4, 2013 5:12 AM To: James Gould <jgould@verisign.com<mailto:jgould@verisign.com>>, Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>>, "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@icann.org>> Subject: Re: [gtld-tech] Version 1.0 of the URS technical requirements published Jim, I also have feedback :) From: <Gould>, James <JGould@verisign.com<mailto:JGould@verisign.com>> Date: Wednesday, 4 December 2013 7:54 am To: Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>>, "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@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 required 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. In DNS if the A/AAAA records are removed as a result on the URS Suspension, the DNS A/AAAA records will be added back when the URS Suspension is removed. In the registry system, there is no change to the host object as part of adding or removing the URS Suspension on a domain. The hosts are independent objects when using the host object model of RFC 5731. 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?). The contact and host objects are independent objects that are associated with the domain being suspended and should not implicitly get touched. I don't agree that the contact objects or host objects should be locked based on the locking of a referencing 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. I recommend following the RFC's as defined, where the pending statuses (pendingDelete, pendingTransfer, and pendingUpdate) MUST NOT be combined with their associated prohibited statuses. In the case of the pendingDelete, it does not make much sense to add URS Lock on the domain that is being deleted. In the case of pendingTransfer, either the transfer should be cancelled by the server before adding the URS Lock or the URS Lock should not be added. In the case of pendingUpdate, either the update should be cancelled by the server before adding the URS Lock or the URS Lock should not be added. I recommend a conference call on this to discuss the options. 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-...> [PDF, 96K]. Thanks, -- JG [cid:264774DA-B8EE-4AC9-BDEF-36ACFCC2C78F] James Gould Principal Software Engineer jgould@verisign.com<mailto:jgould@verisign.com> 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> Date: Thursday, October 24, 2013 4:05 PM To: "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@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
participants (3)
-
Gould, James -
Gustavo Lozano -
James Mitchell