Subject: Re: [ire] New draft-arias-noguchi-registry-data-escrow-00

From: Francisco Arias <[email-masked]>
Date: Fri, 16 Jul 2010 17:49:27 -0700

Thank you, Jim. Sorry for taking so long to respond, this has been a busy
week.

I took care of the nits.  See below my responses to your other comments.

On 7/12/10 10:55 AM, "James Gould" <[email-masked]> wrote:
 
> 1. High Level 
>> 1. I¹m not sure if I¹m on the same page of using XML for use of Data Escrow
>> considering the amount of data for large Registries.  What is generally used
>> for databases for export and import?   If XML is used, then the XML tags
>> should be abbreviated to reduce the verbosity of the files.  The file sizes
>> will have a direct impact on the processing time and cost for generation,
>> transport, and storage of the escrow data.  I would have to look at a
>> comparison between an XML version of a domain record versus a CSV version of
>> a domain record, but with non-abbreviated XML tags it¹s most likely a 10x
>> difference in size.

I think the size problem has a simple solution, we add compression to the
specification. It could be as it was defined in the previous draft using PGP
message format and we could also add encryption.
   
>> 2. Why not define a base specification like RFC 5730 ³EPP² that defines the
>> basic framework for an extensible set of escrow objects and object
>> extensions?  The base specification could also define the considerations for
>> the transport mappings similar to section 2.1 of RFC 5730 ³EPP² that is the
>> bases for RFC 5734 ³EPP over TCP².  This draft assumes a static set of escrow
>> objects that will not work across the board.  I also recommend breaking the
>> objects out to separate specifications similar to RFC 5731  RFC 5733.  The
>> breakup of the specifications in EPP sounds like a natural way to distribute
>> the work for the data escrow.

I don't see a big problem with your suggestion (except from the transport
mapping, see below). My only concern would be that we may require several
documents and I don't see the benefit of having separate documents.

> 3. Section 2 ³Terminology²
>> 1. The definition and use Differential and Incremental Deposits.  This sound
>> like the same thing; although the incremental is the data of all transactions
>> from the last previous full deposit instead of from all the deposit types for
>> the Differential Deposit.  What is defined as the Differential Deposit is
>> generally the definition for an Incremental Deposit, where there is a Full
>> Deposit and then there is a daily Incremental Deposit from the last Full or
>> Incremental deposit.  Is there are reason for having three types of deposits
>> instead of simply two?

Definitions are similar but different, the idea is to give room for people
to implement whatever choice they prefer. I don't see the problem with
keeping both, do you?

>> 2. The definition of Registry Services might be too specific to a domain
>> registry considering that the Registry Service could be built for just about
>> any kind of object (ex. Email Forwarding, Defensive Registration, and
>> NameWatch) as defined by an EPP Mapping.

Could you elaborate on the problem you see here.
 
> 4. Section 3 ³Problem Scope²
>> 1. In the paragraph on ³The solution SHALL NOT include in the specification
>> those objects of delicate confidentiality...² you might want to also include
>> financial related information considering the deposits and credits don¹t
>> automatically migrate as well.

It was not the idea to name all possible pieces of information that may be
too delicate to include.
   
> 5. Section 5 ³Protocol Description²
>> 1. The sentence ³Only the format of the objects deposited is defined, nothing
>> is prescribed about the way to transfer such deposits between the Registry
>> and the Escrow Agent or vice versa.² makes the value much less for a
>> standard.  Maybe the transport would be defined in a separate specification
>> similar to what was done with RFC 5734 ³EPP over TCP².  Defining the file
>> format is a piece of the problem, but specifying the mechanism by what the
>> deposits are made is equally important.  Is the channel encrypted, is the
>> data encrypted, are there checksums included for validation, etc.?

I remember many people in the list mentioned that they did not want to have
a transport defined.

I certainly agree there should be data encryption.

>> 3. Section 5.2 ³Child <summary> element²
>>> 1. Why do we need the summary counts?  Is this used for some sort of
>>> validation?  A checksum would be better for ensuring that the entire deposit
>>> is there.  
>>> 2. ³<contentsCount>² is tied to only Domain Registry Services objects
>>> (domain, host, contact) and a new Registrar object.  This needs to be
>>> extensible to support any kind of object.  I see the need for Registrar
>>> User¹s, Registrar Contacts, and additional Registry Service objects like
>>> Email Forwarding, Defensive Registration, and NameWatch for a registry like
>>> .NAME.  
>>> 3. ³<deleteCount>² element same extensibility comment as with the
>>> <contentsCount> element.

Now that you mentioned, I'm not sure why we added this, do you Shoji?

>> 4. Section 5.3 ³Child <contents> element²
>>> 2. It would be nice to provide an example of the extension element for other
>>> objects types.  Another note about being too specific to one kind of
>>> Registry Service.

ok

>> 6. Section 6 ³Object Description²
>>> 1. Break this section into separate specifications and define how object
>>> extensions are defined here.
>>> 2. Section 6.1 ³RDE Domain Object²
>>>> 1. This is way too verbose for data escrow.  Put the rdeDomain namespace
>>>> with each domain record and then having tags that match the EPP tags will
>>>> produce an extremely large data escrow.  It would be better to have the
>>>> rdeDomain element following by a list of records without the need for the
>>>> namespace with each record.  The tags should match the intent of EPP but
>>>> don¹t have to syntactically match it.

If we add compression this will not be an issue, will it?

>>> 3. Section 6.4 ³RDE Registrar Object²
>>>> 1. There is the need for a RDE Registrar User as well that captures things
>>>> like the login name and password of the user.  The algorithm used for the
>>>> password hashing / encrypted must be available somehow as well.

Ok, maybe something like the "authinfo" element in EPP for contacts and
domains?

__ 
Francisco

---

From: "Gould, James" <[email-masked]>
Date: Fri, 16 Jul 2010 23:55:41 -0400

Francisco,

>From a high level I don't believe that compression is the magic answer to the verbosity issue.  Compression will be resource intensive for massive files and might not reduce the files to a managable size.  The generation time, compression time, and resulting file size on a per object basis would need to be tested to ensure that the specification scales.  I believe it is too verbose for escrow.

It's best to define a base specification with extension points and a place holder for defining the tranports.  Creating one large specification that is tied to a specific set of objects is not extensible enough and without a transport defined will make it a challenge to quickly recover a registry from the deposited escrow files.

Jim

----- Original Message -----
From: Francisco Arias <[email-masked]>
To: Gould, James; [email-masked] <[email-masked]>
Sent: Fri Jul 16 20:49:27 2010
Subject: Re: [ire] New draft-arias-noguchi-registry-data-escrow-00

 

 

ok

__ 
Francisco

---

From: Francisco Arias <[email-masked]>
Date: Mon, 19 Jul 2010 16:18:10 -0700

Jim,

What would be your proposal to deal with the verbosity issue?

The idea is that the proposal was extensible, if it is not, we need to fix it. But certainly the idea is to keep it under the realm of the domain name industry, this was not intended to be a generic escrow protocol.

Could you exemplify what you are thinking as examples of transport options, please.

Regards,

__
Francisco

On 7/16/10 8:55 PM, "Gould, James" <[email-masked]> wrote:

Francisco,

Jim

----- Original Message -----
From: Francisco Arias <[email-masked]>
To: Gould, James; [email-masked] <[email-masked]>
Sent: Fri Jul 16 20:49:27 2010
Subject: Re: [ire] New draft-arias-noguchi-registry-data-escrow-00

On 7/12/10 10:55 AM, "James Gould" <[email-masked]> wrote:

> 1. High Level
>> 1. I'm not sure if I'm on the same page of using XML for use of Data Escrow
>> a domain record, but with non-abbreviated XML tags it's most likely a 10x
>> difference in size.

>> 2. Why not define a base specification like RFC 5730 "EPP" that defines the
>> the transport mappings similar to section 2.1 of RFC 5730 "EPP" that is the
>> bases for RFC 5734 "EPP over TCP".  This draft assumes a static set of escrow
>> objects out to separate specifications similar to RFC 5731 - RFC 5733.  The

> 3. Section 2 "Terminology"

> 4. Section 3 "Problem Scope"
>> 1. In the paragraph on "The solution SHALL NOT include in the specification
>> those objects of delicate confidentiality..." you might want to also include
>> financial related information considering the deposits and credits don't

> 5. Section 5 "Protocol Description"
>> 1. The sentence "Only the format of the objects deposited is defined, nothing
>> and the Escrow Agent or vice versa." makes the value much less for a
>> similar to what was done with RFC 5734 "EPP over TCP".  Defining the file

>> 3. Section 5.2 "Child <summary> element"
>>> 2. "<contentsCount>" is tied to only Domain Registry Services objects
>>> User's, Registrar Contacts, and additional Registry Service objects like
>>> 3. "<deleteCount>" element same extensibility comment as with the
>>> <contentsCount> element.

>> 4. Section 5.3 "Child <contents> element"

ok

>> 6. Section 6 "Object Description"
>>> 2. Section 6.1 "RDE Domain Object"
>>>> don't have to syntactically match it.

>>> 3. Section 6.4 "RDE Registrar Object"

__
Francisco

---

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Jul 2010 18:14:34 -0400

On Jul 16, 2010, at 11:55 PM, Gould, James wrote:

> Francisco,
>
> From a high level I don't believe that compression is the magic  
> answer to the verbosity issue.  Compression will be resource  
> intensive for massive files and might not reduce the files to a  
> managable size.  The generation time, compression time, and  
> resulting file size on a per object basis would need to be tested to  
> ensure that the specification scales.  I believe it is too verbose  
> for escrow.

So, just for giggles (I have a string sense of humor) I decided to  
investigate the compressibility of XML.

I wrote some Python to generate some fairly standard elements,  
covering things like registrant contacts, name-servers, etc in  
serialized EPP. In order to create a good approximation of worst case  
compressibility  I filled in random strings for the values.

Here are some results:

dot:tmp wkumari$ ls -alh huge_epp_dump.xml
-rw-r--r--  1 wkumari  eng   733M Jul 20 18:08 huge_epp_dump.xml

dot:tmp wkumari$ time gzip huge_epp_dump.xml

real	0m8.181s
user	0m7.759s
sys	0m0.412s

dot:tmp wkumari$ ls -alh huge_epp_dump.xml.gz
-rw-r--r--  1 wkumari  eng   2.8M Jul 20 18:08 huge_epp_dump.xml.gz
dot:tmp wkumari$

So, ~8 seconds to compress around 733MB of EPP type XML down to ~ 3MB...

W

>
> It's best to define a base specification with extension points and a  
> place holder for defining the tranports.  Creating one large  
> specification that is tied to a specific set of objects is not  
> extensible enough and without a transport defined will make it a  
> challenge to quickly recover a registry from the deposited escrow  
> files.
>
> Jim
>
> _______________________________________________
> ire mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ire

--
It's a mistake trying to cheer up camels. You might as well drop  
meringues into a black hole. -- Terry Prachett

---

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Jul 2010 18:31:22 -0400

Sent from my iPad

On Jul 20, 2010, at 6:14 PM, Warren Kumari <[email-masked]> wrote:

> So, just for giggles (I have a string sense of humor) I decided to investigate the compressibility of XML.
> 
> I wrote some Python to generate some fairly standard elements, covering things like registrant contacts, name-servers, etc in serialized EPP. In order to create a good approximation of worst case compressibility  I filled in random strings for the values.
> 
> Here are some results:
> 

Whoops, sent before I was ready....

This data is not exact (and is a simplification) but should at least provide a good guideline for both the compressibility and resource requirements for compression of XML encoding of this type of data.  

Most of the time seems to have been spent in I/O operations (reading 733M from disk) and not in processor time...

W

> It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett
> 
>