[gtld-tech] URS Technical Requirements - version 20131017
alexander.mayrhofer at nic.at
Fri Oct 18 12:43:04 UTC 2013
one comment that we made a long time ago obviously didn't make it into the specs / process descriptions yet, namely about the "pre-communication of URS nameservers".
We would appreciate if all URS providers would pre-publish their list of nameservers they intend to use for URS suspension. The reasons for this is:
a) we would appreciate if we could pre-create the respective host objects in each registry, so that the URS process itself would not need to consider the creation of those objects.
b) we could "screen" the URS requests against those nameservers in the process of the actual suspension. This would give another level of security against rogue redirection requests (think "hacked URS provider"...)
P.S.: Are people who are planning to attend the IETF meeting in Vancouver interesting in holding a "Registry Backend (Bar) BoF"? I'd definitely be interested in that.
Von: gtld-tech-bounces at icann.org [mailto:gtld-tech-bounces at icann.org] Im Auftrag von Gustavo Lozano
Gesendet: Freitag, 18. Oktober 2013 02:51
An: gtld-tech at icann.org
Betreff: [gtld-tech] URS Technical Requirements - version 20131017
Attached you will find the latest version of the URS technical requirements in clean and redline.
This version incorporates the latest feedback from the list.
For those new to this document, the objective is to define the technical requirements of the URS Procedures (latest version: http://newgtlds.icann.org/en/applicants/urs/procedure-01mar13-en.pdf) included in the AGB. The objective is to use the EPP RFCs as much as possible while trying to not impact the normal domain registration lifecycle.
The procedures define email as the communication mechanism between URS providers and Registries/Registrars, therefore the URS technical requirements document defines email as the communication mechanism. If the volume of URS request grows high, the ICANN community may want to define a new mechanism (EPP, using an API, centralized operations, etc.) in the future and ICANN is willing to help in the effort.
Regarding other policies that may be impacted by the URS and the leverage of Registries/Registrars to act on URS locked or URS suspended domain names, ICANN is always open to receive questions from Registries/Registrars and provide guidance.
Based on the feedback from the list, we believe that this version could be publish as version 1.0, please let us know as soon as possible if you find any major roadblocks.
We are planning to publish version 1.0 on Tuesday, 22/Oct/2013.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gtld-tech