[ire] New versions of data escrow drafts

Gustavo Lozano <gustavo.lozano@icann.org> Thu, 04 April 2013 19:19 UTC

Return-Path: <gustavo.lozano@icann.org>
X-Original-To: ire@ietfa.amsl.com
Delivered-To: ire@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0C90921F8D41 for <ire@ietfa.amsl.com>; Thu, 4 Apr 2013 12:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id i+SaA5Ug8HPi for <ire@ietfa.amsl.com>; Thu, 4 Apr 2013 12:19:34 -0700 (PDT)
Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org []) by ietfa.amsl.com (Postfix) with ESMTP id 029EA21F8D0D for <ire@ietf.org>; Thu, 4 Apr 2013 12:19:34 -0700 (PDT)
Received: from EXVPMBX100-1.exc.icann.org ([]) by EXPFE100-1.exc.icann.org ([]) with mapi; Thu, 4 Apr 2013 12:19:33 -0700
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: "ire@ietf.org" <ire@ietf.org>
Date: Thu, 4 Apr 2013 12:19:30 -0700
Thread-Topic: New versions of data escrow drafts
Thread-Index: Ac4xaVZWs1jRwxxBTF2pKS1h4rpYDQ==
Message-ID: <CD832052.F908%gustavo.lozano@icann.org>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CD832052F908gustavolozanoicannorg_"
MIME-Version: 1.0
Subject: [ire] New versions of data escrow drafts
X-BeenThere: ire@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <ire.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ire>, <mailto:ire-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ire>
List-Post: <mailto:ire@ietf.org>
List-Help: <mailto:ire-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ire>, <mailto:ire-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 19:19:35 -0000


New versions of the registry-data-escrow and dndrd-objects-mapping drafts have been published to incorporate suggestions received in this list and by private messages:

As the merge of the CSV draft (dnrd-csv-mapping) with dndrd-object-mapping continues, this minor updates of  registry-data-escrow and dndrd-objects-mapping drafts should clarify some questions and incorporate suggestions received by private messages and in this list from registry operators and data escrow agents.

Main changes are as follows.


* The resend attribute is now only used when the escrow deposit must be re-generated by the registry operator because the escrow verification procedure failed at the receiving party.


* The resend attribute of the <report> element is now an element (<resend>) and contains the same value as the <rde:deposit> resend attribute.

* Data Escrow Agents must send a notification by each successfully received deposit regardless of the result of the verification process.

* Added XPath attribute to policy object.

* Removed optional <authinfo> from XML schemas since the escrow of that element is not required to be escrowed based on the suggestions received in the list.


* I have received questions regarding how the data escrow agent notifies ICANN the status of escrow deposits, as required in the base agreement of new gTLDs. In the following link http://tools.ietf.org/html/draft-lozano-icann-registry-interfaces-00, you will find the specification of the web services we are implementing for such purpose. This draft will be discussed in another forum.

* I have received questions regarding data escrow extensions and new gTLDs. The base agreement, Specification 2, 3.2 defines: " If a Registry Operator offers additional Registry Services that require submission of additional data, not included above, additional “extension schemas” shall be defined in a case by case base to represent that data. ... ICANN and the respective Registry shall work together to agree on such new objects’ data escrow specifications.". In other words, we are going to validate/approve the data escrow extensions in case of Registry Operators that offer additional Registry Services.

If no additional registry services are offered, the data escrow agent uses this specification; if additional registry services are offered, the data escrow agent uses the extensions validated/approved by ICANN.


* I have received questions regarding the process for encrypting the escrow deposits as required in the base agreement of new gTLDs. I attempt to provide answers as follows:

With the incorporation of CSV as an option for doing registry escrow, there is the possibility of an escrow deposit being an XML file plus potentially several CSV data files. Regardless of doing escrow XML only or with CSV, there is always a XML file generated as described in the registry-data-escrow draft.

This XML file is named following the procedure described in specification 2 of the applicant guidebook. The XML file and potentially the CSV files are always aggregated in a tarball file. For example:

gustavolozano$ ls -lh example_2009-08-02_full_S1_R0.xml
15M example_2009-08-02_full_S1_R0.xml

gustavolozano$ tar -tvf example_2009-08-02_full_S1_R0.tar

The tarball is encrypted and optionally compressed by an OpenPGP utility that conforms to RFC4880:

gustavolozano$ gpg --recipient dataescrowagent --output example_2009-08-02_full_S1_R0.ryde --encrypt example_2009-08-02_full_S1_R0.tar

gustavolozano$ ls -lh example_2009-08-02_full_S1_R0.ryde
16K example_2009-08-02_full_S1_R0.ryde

A signature file for the .ryde file is generated:

gustavolozano$ gpg --output example_2009-08-02_full_S1_R0.sig --detach-sig example_2009-08-02_full_S1_R0.ryde

The registry operator would then send the .ryde and .sig file to the data escrow agent.

Questions are suggestions are welcome.