Subject: Re: [ire] FW: New Version Notification for draft-arias-noguchi-registry-data-escrow-01

From: Francisco Arias <[email-masked]>
Date: Fri, 5 Nov 2010 11:07:20 -0700

Hello Jim,

I have not problem with your suggestion to separate the objects in different documents, except that it may complicate the specification and I’m not sure what’s the benefit.

On the verbosity issue, do you have any specific suggestion?

Maybe we could talk in person while in Beijing, will you be there?

Sorry for the late response.

__
Francisco

On 10/25/10 10:59 AM, "James Gould" <[email-masked]> wrote:

Francisco,

I’m glad to see that redefining the namespace does not have to be done on a per-object perspective, but I really don’t see the focus on extensibility in the draft.  Instead of defining the concrete objects (domain, host, contact, and registrar) in the base document, why not make them first class objects in their own documents?  Ideally the base would be a wrapper for defining the deposit for an extensible set of objects, where there is a parent element for an object type with a sequence of object type specific sub-elements.  This would be very similar to EPP, which is a model that we should consider using for Data Escrow since Registries might have many types of objects to escrow outside the core objects.  I wouldn’t want to consider the .NAME specific objects like Email Forwarding or Defensive Registration to be considered extensions but as first class objects with a custom data escrow mapping.  Another item is that registrar users of a registrar need to be escrowed as well, since some Registries track updates at the user level.  There needs to be an out-of-band method of escrowing the encrypting or hashing algorithm used for data like passwords as well as auth info values.

Finally, as I noted previously I have a real concern related to the verbosity of the deposits.  It’s nice to match the EPP specifications for readability, but I’m not sure if readability is needed for escrowing a large data set even with the magic of compression.

---

From: "Michael Young" <[email-masked]>
Date: Fri, 5 Nov 2010 14:39:10 -0400

James I think your thoughts are very valid, this really should be object
independent and I share the concern about verbosity.

Best Regards,

Michael Young

Vice-President,

Product Development

Afilias

O: +14166734109

C: +16472891220

From: Francisco Arias [mailto:[email-masked]] 
Sent: November-05-10 2:07 PM
To: James Gould; [email-masked]
Subject: Re: [ire] FW: New Version Notification for
draft-arias-noguchi-registry-data-escrow-01

Hello Jim,

I have not problem with your suggestion to separate the objects in different
documents, except that it may complicate the specification and I'm not sure
what's the benefit.

__ 
Francisco

Francisco, 

I'm glad to see that redefining the namespace does not have to be done on a
per-object perspective, but I really don't see the focus on extensibility in
the draft.  Instead of defining the concrete objects (domain, host, contact,
and registrar) in the base document, why not make them first class objects
in their own documents?  Ideally the base would be a wrapper for defining
the deposit for an extensible set of objects, where there is a parent
element for an object type with a sequence of object type specific
sub-elements.  This would be very similar to EPP, which is a model that we
should consider using for Data Escrow since Registries might have many types
of objects to escrow outside the core objects.  I wouldn't want to consider
the .NAME specific objects like Email Forwarding or Defensive Registration
to be considered extensions but as first class objects with a custom data
escrow mapping.  Another item is that registrar users of a registrar need to
be escrowed as well, since some Registries track updates at the user level.
There needs to be an out-of-band method of escrowing the encrypting or
hashing algorithm used for data like passwords as well as auth info values.

Finally, as I noted previously I have a real concern related to the
verbosity of the deposits.  It's nice to match the EPP specifications for
readability, but I'm not sure if readability is needed for escrowing a large
data set even with the magic of compression.

---

From: Francisco Arias <[email-masked]>
Date: Fri, 5 Nov 2010 14:07:15 -0700

Michael,

Any suggestion on the verbosity issue?

Regards,

__
Francisco

On 11/5/10 11:39 AM, "Michael Young" <[email-masked]> wrote:

James I think your thoughts are very valid, this really should be object independent and I share the concern about verbosity.

Best Regards,

Michael Young

Vice-President,
Product Development
Afilias
O: +14166734109
C: +16472891220

From: Francisco Arias [mailto:[email-masked]]
Sent: November-05-10 2:07 PM
To: James Gould; [email-masked]
Subject: Re: [ire] FW: New Version Notification for draft-arias-noguchi-registry-data-escrow-01

Hello Jim,

__
Francisco

---

From: "Michael Young" <[email-masked]>
Date: Fri, 5 Nov 2010 17:19:16 -0400

Well that was why the original proposal was not xml based.

Best Regards,

Michael Young

Vice-President,

Product Development

Afilias

O: +14166734109

C: +16472891220

From: Francisco Arias [mailto:[email-masked]] 
Sent: November-05-10 5:07 PM
To: Michael Young; [email-masked]
Subject: Re: [ire] FW: New Version Notification for
draft-arias-noguchi-registry-data-escrow-01

Michael,

Regards,

__ 
Francisco

Best Regards,
 
Michael Young
 
Vice-President,
Product Development
Afilias
O: +14166734109
C: +16472891220

Hello Jim,

__ 
Francisco

---

From: James Gould <[email-masked]>
Date: Mon, 08 Nov 2010 12:26:57 -0400

Franscisco,

The big advantage of splitting up the documents is the same benefit there
was in splitting the documents with EPP.  The key advantage is that you¹re
able to define a general framework in the base document for an extensible
set of objects (domain, host, contact, etc.) that are defined in their own
documents.  Some of the objects might be standard in the case of domain,
host, and contact.  Some of the objects might be custom like email forward,
defensive registration, and namewatch with .NAME.  The extension points at
an object level should be supported as well to support adding custom
attributes to standard objects like domain, host, and contact.  The easiest
model is to use a EPP like model.

Now as far as the verbosity I am questioning the need for XML.  XML will
make it easier from a specification perspective since it is easier to match
EPP but staying with a CSV format that keeps the data separate from the
definition (no XML schema and no XML tags) will be easier to create from the
database and will greatly reduce the size of the escrow.  If XML is
absolutely needed then it would be best to reduce the verbosity of the
element and attribute names and to not to require a new namespace on a per
record level for non-standard objects.

As a simple example of the verbosity, if you take your sample pinguino.test
domain in section 6.1.1 of the document.  The same is 1614 bytes
uncompressed and 1023 bytes compressed using ZIP.  I realize there are other
compression formats that can compress it further.  If you consider the size
of a TLD like .COM with approximately 90 million domains it would result in
a full deposit of 145.26 GB uncompressed and 92.16 GB compressed for just
domains without hosts, contacts, and other escrow data.  The size of the
data escrow will increase the cost for the deposits but will also increase
the recovery time. 

In summary it¹s best to create a base specification with a specification per
object type that is extensible in a similar fashion as EPP, but without the
use of XML.  XML adds a lot of extra redundant information that is too
verbose for large datasets.

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.

From: Francisco Arias <[email-masked]>
Date: Fri, 5 Nov 2010 14:07:20 -0400
To: James Gould <[email-masked]>, <[email-masked]>
Subject: Re: [ire] FW: New Version Notification for
draft-arias-noguchi-registry-data-escrow-01

Hello Jim,

I have not problem with your suggestion to separate the objects in different
documents, except that it may complicate the specification and I¹m not sure
what¹s the benefit.

__ 
Francisco

On 10/25/10 10:59 AM, "James Gould" <[email-masked]> wrote:

> Francisco, 
> 
> I¹m glad to see that redefining the namespace does not have to be done on a
> per-object perspective, but I really don¹t see the focus on extensibility in
> and registrar) in the base document, why not make them first class objects in
> their own documents?  Ideally the base would be a wrapper for defining the
> deposit for an extensible set of objects, where there is a parent element for
> an object type with a sequence of object type specific sub-elements.  This
> would be very similar to EPP, which is a model that we should consider using
> for Data Escrow since Registries might have many types of objects to escrow
> outside the core objects.  I wouldn¹t want to consider the .NAME specific
> objects like Email Forwarding or Defensive Registration to be considered
> extensions but as first class objects with a custom data escrow mapping.
> Another item is that registrar users of a registrar need to be escrowed as
> well, since some Registries track updates at the user level.  There needs to
> be an out-of-band method of escrowing the encrypting or hashing algorithm used
> for data like passwords as well as auth info values.
> 
> Finally, as I noted previously I have a real concern related to the verbosity
> of the deposits.  It¹s nice to match the EPP specifications for readability,
> but I¹m not sure if readability is needed for escrowing a large data set even
> with the magic of compression.

---

From: "Michael Young" <[email-masked]>
Date: Mon, 8 Nov 2010 14:06:08 -0500

Again very much onside with the points James is making here. Remember we are
trying to develop this for the future case as well as what we know today.
For example, if the same escrow requirements are applied to a new TLD that
has a corporate model, such as dot IBM or dot Google etc, and they span out
their registration space in vast numbers (hundreds of millions), then size
of deposits becomes absolutely prohibitive using XML despite best
compression methods.

I'd really like to hear a sound argument why XML is truly required, I have
yet to hear one that applies to the problem set we are trying to solve for
here.

Best Regards,

Michael Young

Vice-President,

Product Development

Afilias

O: +14166734109

C: +16472891220

From: James Gould [mailto:[email-masked]] 
Sent: November-08-10 11:27 AM
To: Francisco Arias; [email-masked]
Subject: Re: [ire] FW: New Version Notification for
draft-arias-noguchi-registry-data-escrow-01

Franscisco,

was in splitting the documents with EPP.  The key advantage is that you're

In summary it's best to create a base specification with a specification per
object type that is extensible in a similar fashion as EPP, but without the
use of XML.  XML adds a lot of extra redundant information that is too
verbose for large datasets.  

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

  _____  

Hello Jim,

__ 
Francisco

Francisco,