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

From: Francisco Arias <[email-masked]>
Date: Mon, 25 Oct 2010 10:11:57 -0700

Hello,

Just to let you know that Shoji and I today submitted a new version of the
draft:

http://datatracker.ietf.org/doc/draft-arias-noguchi-registry-data-escrow/

We tried to include the feedback we received. We also added a few new
elements to support DS/DNSKEY, RGP and IDN data. Section 13.1 lists all the
changes.

We'd appreciate your feedback.

Regards,

__ 
Francisco

------ Forwarded Message
From: IETF I-D Submission Tool <[email-masked]>
Date: Mon, 25 Oct 2010 10:00:27 -0700
To: Francisco Arias <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: New Version Notification for
draft-arias-noguchi-registry-data-escrow-01

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

Filename:  draft-arias-noguchi-registry-data-escrow
Revision:  01
Title:   Domain Name Data Escrow Specification
Creation_date:  2010-10-25
WG ID:   Independent Submission
Number_of_pages: 42

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

The IETF Secretariat.

------ End of Forwarded Message

---

From: James Gould <[email-masked]>
Date: Mon, 25 Oct 2010 13:59:59 -0400

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.

-- 

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: Mon, 25 Oct 2010 13:11:57 -0400
To: <[email-masked]>
Subject: [ire] FW: New Version Notification for
draft-arias-noguchi-registry-data-escrow-01

Hello,

Regards,

__
Francisco

------ Forwarded Message

Abstract:

The IETF Secretariat.

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