[gtld-tech] URS Technical Requirements - version 20131017

[Gustavo Lozano]

Alex, et al., 
 
We are planning share the NSs used by the URS providers with Registries.
 
The "screen" of the URS request against those nameservers is a good extra
layer of security, but it's important to mention that the security mechanism
of the solution is PGP and the NSs may change in the future.
 
Regards,
Gustavo

From:  Alexander Mayrhofer <alexander.mayrhofer at nic.at>
Date:  Friday, October 18, 2013 5:43 AM
To:  Gustavo Lozano <gustavo.lozano at icann.org>, "gtld-tech at icann.org"
<gtld-tech at icann.org>
Subject:  AW: URS Technical Requirements - version 20131017

> Gustavo, colleagues,
>  
> 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”...)
> 
>  
> thanks,
> Alex
>  
> 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
>  
> Colleagues,
>  
> 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.
>  
> Regards,
> Gustavo


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