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

From: Francisco Arias <[email-masked]>
Date: Mon, 5 Jul 2010 22:37:33 -0700

Hello,

Shoji Noguchi from JPRS and myself have been working on a new draft for
Domain Registry Data Escrow based on JPRS implementation and some of the
gTLDs¹. This new specification uses XML and is based on EPP as suggested in
the list.

As you would see it is still in rough 00 status. At this stage we would
appreciate your input specially about the general concept.

Regards,

__ 
Francisco

------ Forwarded Message
From: IETF I-D Submission Tool <[email-masked]>
Date: Mon, 5 Jul 2010 16:34:16 -0700
To: Francisco Arias <[email-masked]>
Cc: <[email-masked]>
Subject: New Version Notification for
draft-arias-noguchi-registry-data-escrow-00

A new version of I-D, draft-arias-noguchi-registry-data-escrow-00.txt has
been successfully submitted by Francisco Arias and posted to the IETF
repository.

Filename:        draft-arias-noguchi-registry-data-escrow
Revision:        00
Title:           Internet Domain Registry Data Escrow specification
Creation_date:   2010-07-06
WG ID:           Independent Submission
Number_of_pages: 34

Abstract:
This document specifies the format and contents of Data Escrow
deposits for Domain Registries.

The IETF Secretariat.

------ End of Forwarded Message

---

From: James Gould <[email-masked]>
Date: Mon, 12 Jul 2010 13:55:36 -0400

Francisco,

Below is my feedback to the draft:

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.
> 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.  
2. Section 1 ³Introduction²
> 1. Nit - ³include all the objectes related² changed to ³include all the
> objects related²
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?
> 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.
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.
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.?
> 2. Section 5.1 ³Root element <escrowDeposit>²
>> 1. Nit - ³This element also contains que following attributes² changed to
>> ³This element also contains the following attributes²
> 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.
>> 4. Nit - ³A <deleteCount> element ontains four elements...² change to ³A
>> <deleteCount> element contains four elements...².
> 4. Section 5.3 ³Child <contents> element²
>> 1. Nit - ³This element MAY also contain and extension element allowing
>> extending the format.² changed to ³This element MAY also contain an extension
>> element allowing extending the format.²
>> 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.  
> 5. Section 5.4 ³Child <delete> element²
>> 1. Nit - ³This element MAY also contain and extension element allowing
>> extending the format.² changed to ³This element MAY also contain an extension
>> element allowing extending the format.²
>> 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.  
> 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.
>> 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.
>> 4. I have similar comments with the other data escrow object types.

-- 

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: Tue, 6 Jul 2010 01:37:33 -0400
To: <[email-masked]>
Subject: [ire] New draft-arias-noguchi-registry-data-escrow-00

Hello,

Regards,

__
Francisco

------ Forwarded Message

Abstract:

The IETF Secretariat.

_______________________________________________
ire mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ire