Subject: [ire] New versions of data escrow drafts

From: Gustavo Lozano <[email-masked]>
Date: Thu, 4 Apr 2013 12:19:30 -0700

Colleagues,

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:
http://www.ietf.org/internet-drafts/draft-arias-noguchi-registry-data-escrow-06.txt
http://www.ietf.org/internet-drafts/draft-arias-noguchi-dnrd-objects-mapping-03.txt

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.

draft-arias-noguchi-registry-data-escrow-06:

* 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.

draft-arias-noguchi-dnrd-objects-mapping-03:

* 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
example_2009-08-02_full_S1_R0.xml

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.

Regards,
Gustavo

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 4 Apr 2013 13:33:48 -0700

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:

Example:

-rw-r--r-- 1 fobispo fobispo   490 Mar 21 05:05 FOO_2013-03-20_full_S1_R0.asc
-rw-r--r-- 1 fobispo fobispo  3050 Mar 21 05:03 FOO_2013-03-20_full_S1_R0.ryde
-rw-r--r-- 1 fobispo fobispo 13379 Mar 20 01:21 FOO_2013-03-20_full_S1_R0.xml

Now, we could have a tarball with the .ryde and the .asc files to avoid transferring the two files, or, we could encrypt+sign+compress the same file, thus combining the signature with the content.

Francisco

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

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Christopher Browne <[email-masked]>
Date: Thu, 4 Apr 2013 17:10:25 -0400

> 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.

---

From: James Mitchell <[email-masked]>
Date: Fri, 5 Apr 2013 21:24:32 +1100

Gustavo,

The definition of the deposit ID is given below:

      A REQUIRED "id" attribute that is used to uniquely identify the
      escrow deposit.  Each registry is responsible for maintaining its
      own escrow deposits identifier space to ensure uniqueness, e.g.,
      using identifiers as described in Section 2.8 of [RFC5730].

Section 2.8 of RFC 5730 describes globally unique identifiers. I do not believe there is a need for globally unique identifiers, and therefore suggest updating the text to remove the reference to RFC5730 and instead require registries produce locally unique deposit identifiers. I actually see no need for deposit identifiers as the watermark is unique, one could use prevWatermark="" in replacement to prevId="".

If global uniqueness is required, we would like to use the concatenation of the TLD name and date, however the format does not currently allow this. We suggest the depositIdType pattern is updated to use a modified ROID pattern that allows hyphens, e.g. <pattern value="(\w|_|-){1,89}"/>, allowing for identifiers such as id="xn--punycode-20130405". This pattern would be reasonably consistent with the reference to RFC 5730.

Regards,
James

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 9 Apr 2013 02:04:03 -0700

Thank you James,

In the new version of the specification the text will be updated to:

A REQUIRED "id" attribute that is used to uniquely identify the escrow deposit. Each registry is responsible for maintaining its own escrow deposits identifier space to ensure uniqueness. The identifier must be unique even for escrow deposits generated for the same Timeline Watermark.

We need the identifier because the data escrow specification was developed for general escrow in mind, resend is optional (but required for new gTLDs) and several deposits could have the same Timeline Watermark (e.g. resending).

Regards,
Gustavo

From: James Mitchell <[email-masked]<mailto:[email-masked]>>
Date: Friday, April 5, 2013 6:24 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [ire] Deposit Identifiers

Gustavo,

Regards,
James

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 9 Apr 2013 22:28:51 -0700

I would suggest using something like UUID for unique identifiers, or worst case, just free text.

We had a discussion the other day with regards to ROID and its nonsense format on provreg, and I think we should avoid it here if all possible.

Francisco Obispo