Re: [ire] New versions of data escrow drafts

Christopher Browne <> Thu, 04 April 2013 21:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1945021F8ED4 for <>; Thu, 4 Apr 2013 14:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AHZPDnWFaHUu for <>; Thu, 4 Apr 2013 14:10:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 613DC21F8BEA for <>; Thu, 4 Apr 2013 14:10:33 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.69) (envelope-from <>) id 1UNrQW-0008QS-5N for; Thu, 04 Apr 2013 21:10:32 +0000
Received: from ([]) by with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <>) id 1UNrQW-0003A2-4p for; Thu, 04 Apr 2013 21:10:32 +0000
Received: by with SMTP id eb20so4513802lab.1 for <>; Thu, 04 Apr 2013 14:10:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=GEtAOpnD5k3jAY4CfGPJH11dst5++FLzbL3+xZkGXqg=; b=l3sVOyiKKhPuSPsfd4FRIjVba4is9OspIJ192CYNB3dWbuab4EXNVQYHJO7iGjcu4B SZqqhCaRNM38ITxO+OvjQQDA6TsPiGevAynFNFl519KfMPaYTqLibwrdUk+xm26tszq7 ZbOGSbNUC+Gu7AdJcm8I0BG15m3HkLM0qcbLf/O7C7P3ZCKqtkGlucoZzgyAAicCxKfh YJoZMB32zEbE7rCOG+byxYs3Yqsao7znGPOQs20XZGETQgdxTdcW6divYXtJxWINDALq 5/0kOL+WVIUgGqGYyYcl+nYsRLZGtFbqKLibCq4LPEBMwQdyB9jeYc6Vsa2rjC8UnK+F u5Ew==
X-Received: by with SMTP id i9mr11856049wjq.18.1365109826046; Thu, 04 Apr 2013 14:10:26 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id i9mr11856040wjq.18.1365109825944; Thu, 04 Apr 2013 14:10:25 -0700 (PDT)
Received: by with HTTP; Thu, 4 Apr 2013 14:10:25 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 4 Apr 2013 17:10:25 -0400
Message-ID: <>
From: Christopher Browne <>
To: Francisco Obispo <>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQm4LPLEEjxL+lDiQrpQ6lginiPKRTP6D/LSeLnKVGpumrjOVNH0683JtfBFkomwCz+om2TQZHGT/zQqb4WSyz8dJtDhLXoAu1PXJ7B5vz0j4JyF1g9QFRZBV8pP93GAsK+FXU3/
Cc: "" <>
Subject: Re: [ire] New versions of data escrow drafts
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Apr 2013 21:10:34 -0000

On Thu, Apr 4, 2013 at 4:33 PM, Francisco Obispo <>; 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."


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

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