Re: [ire] New versions of data escrow drafts

[Gustavo Lozano <[e-mail]>]

Christopher,

XML only and XML+CSV are both supported (see http://www.icann.org/en/news/correspondence/atallah-to-drazek-21feb13-en.pdf)

The authors of both drafts are working on merging the drafts.

A CSV deposit will have an XML file and several CSV files; this is the reason of the requirement for the tarball.  In order to standardize the process for Data Escrow Agents, even if you use XML only, the revised base agreement requires the use of a tarball.

Data escrow agents will:


 1.  Validate the signature (.sig) of the .ryde file.
 2.  Unencrypt the .ryde file obtaining a tarball.
 3.  Untar the tarball.
 4.  Process the XML data file.
 5.  The XML data file could link CSV data file(s) for some objects if using the CSV model.
This has been reflected in the proposed base agreement (see http://blog.icann.org/2013/04/revised-registry-agreement-posted-for-review, Specification 2)

Regards,
Gustavo

On 4/4/13 2:10 PM, "Christopher Browne" <[e-mail]<mailto:[e-mail]>> wrote:

On Thu, Apr 4, 2013 at 4:33 PM, Francisco Obispo <[e-mail]<mailto:[e-mail]>> wrote:
Why do you want to put it in a tarball?

GPG will encrypt+compress the data, leaving you with a .ryde file that already meets the criteria:

Assuming the CSV representation is approved, that will mandate having
a bunch of files, one for each of various streams of data.

That is somewhat problematic, at present, since most of the standard
seems to contemplate there being a single XML file.  I expect that a
reasonably substantial amount of rewording would be required to cope
with accommodating there being multiple files.  And further, since the
file naming conventions are stated not in the IRE standard, but rather
in the registry operator agreement, then presumably there would need
to be amendments made to that document to accommodate the multiplicity
of CSV files.

The wording of draft-arias-noguchi-registry-data-escrow-06 is a bit
curious in this regard; *most* of the document makes no reference to
the concept of a "file", instead indicating an XML schema to represent
the contents of a "deposit."

In section #2 is one of the references; on the one hand, it discusses
the XML model, and does so without actually mentioning files.  But the
addition of CSV requires that the deposit be split into pieces, so it
indicates that the data will be contained in files.  So that implies
that a deposit consists of "files."

Section #11 mentions files, but I imagine that it would be better
worded if the following two sentences were changed:

   "It is also of the utmost importance the authentication of the
parties passing data escrow deposit files."

    to (with a bit of grammar repair that I hope is apropos)

   "It is also of the utmost importance to have proper authentication
of the parties passing data escrow deposits."

also...

    "Validation of the contents by the Escrow Agent is RECOMMENDED to
ensure not only the file was transmitted correctly from the Registry,
but also the contents are also "meaningful"."
    to (with a little bit of wordsmithing)
    "Validation of the contents by the Escrow Agent is RECOMMENDED to
ensure not only that the deposit was transmitted correctly from the
Registry, but also that the contents are "meaningful"."

Throughout section #17, the term "data escrow deposit file" is used
repeatedly (three times); I should think that the word "file" could be
dropped in all three cases without injuring the wording.

The Revised New gTLD Registry Agreement presumably needs to be revised
more significantly, as it makes a lot more specific statements
indicating that the deposits are represented by a single file.
http://www.icann.org/en/news/public-comment/base-agreement-05feb13-en.htm

- In 3.1 it expressly indicates that the deposit "will be compiled
into a file constructed as described in [draft-arias-...]"
- In 3.2, extended data is indicated to be "included in the deposit
file described in section 3.1"
- In 5, a naming convention is given for The Deposit File
- In 8.2, it is indicated that if the file is decomposed into pieces,
they are "put together"

I could readily think of a way of using /usr/bin/tar to turn several
smaller files into one bigger one that might be considered to
represent the deposit, however the RA document:
a) Does not contemplate that, and
b) Specifically indicates that the IRE standard is to be used to
indicate the construction of the file (e.g. - section 3.1 says that
quite specifically).

>From the division of responsibilities that is indicated in the RA
document, it appears as though the IRE specification needs to speak to
how a series of CSV streams would be composed into a singular deposit.