Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt

From: James Gould <[email-masked]>
Date: Wed, 17 Feb 2010 18:03:06 -0500

All,

I finally got around to reviewing the draft created by Francisco.  I hope
that we discuss some of this at the BOF, but I want to highlight some of my
initial feedback to the draft:

1. High level
> 1. It would be best to establish some high level format and policies around
> the data content within an RFC that can be extended by additional RFC¹s or
> custom specifications in a similar fashion to EPP RFC 5730 and the associated
> mappings (Domain Name RFC 5731, Host RFC 5732, Contact 5733).   I know for
> .NAME that we have additional provisioning objects to escrow including Email
> Forwarding, Defensive Registration, and NameWatch which is not covered by the
> draft.  What is the process for including additional objects?
> 2. We should use terminology consistent with the EPP RFC¹s and define at a
> minimum the same set of attributes as the EPP RFC¹s.  For example, use of Host
> instead of Name Server.
> 3. The references to {creatorRegistrar} and {updateRegistrar} should be
> changed to {createUser} and {updateUser}, respectively.  There can be multiple
> users per Registrar and there can be multiple users including Registry users
> that can create and update objects, so these should reference a User Handle
> and not a Registrar Handle and be named appropriately.
> 4. Users are completely missing from the draft.  I¹m assuming that at least
> the User Handle and User Identifier (login name), along with other user
> details would be needed.
> 5. It¹s assumed that the roids are derived by the handles?  The Registry
> should indicate in some way what the format of the roids are based on the
> handles.  
> 6. {authInfo} - Question of whether this can be an encrypted value?  This
> functions as a password, so it¹s not a good practice to store them unencrypted
> in the database and I¹m pretty sure that the escrow creation shouldn¹t go
> through the process of decrypted all of the values.  If the value were
> encrypted the Registry should deposit the decryption program and decryption
> key.  
2. Section 5.1 Domain
> 1. There needs to be a method of defining additional attributes at the domain
> level to accommodate a larger set of Registries.
> 2. {creatorRegistrar} - Refer to high-level comment 1.3.
> 3. {authInfo} - Refer to high-level comment 1.6.
> 4. {updateRegistrar} - Refer to high-level comment 1.3.
> 5. {deletionDate} - This should be optional, since this could be dynamically
> calculated based on a combination of reference data and live data.  Maybe the
> policy reference data should be deposited.
> 6. How are hostAttr name servers addressed in RFC 5731?
3. Section 5.2 Contacts
> 1. Where are the RFC 5733 <contact:id> attribute captured?
> 2. {creatorRegistrar} - Refer to high-level comment 1.3.
> 3. {authInfo} - Refer to high-level comment 1.6.
> 4. {updateRegistrar} - Refer to high-level comment 1.3.
> 5. I see the need for additional custom attributes that have been handled by
> EPP extensions by various Registries.
4. Section 5.4 is called Name servers.  Why wouldn¹t we use the EPP 5732
term of Hosts?
> 1. Where are the {createUser}, {UpdateUser}, {lastUpdate}, and
> {lastTransferDate} attributes?
> 2. There should be an optional {parentDomainHandle} added to support child
> hosts.
5. Section 5.5 Name server IP Addresses
> 1. Should be called Host IP Addresses to be consistent with RFC 5731.
6. Section 5.6 Delegation Signer (DS) records
> 1. This will need to be updated based on the work being done on rfc4310bis.
> Specifically, {maximumSigLife} is not an attribute of an individual Delegation
> Signer record, so it should be up in Section 5.1 Domain as an option
> attribute.  In addition rfc4310bis support a DS Data Interface as well as a
> Key Data Interface where there could be a handle for the the DNSKEY and then
> have multiple DS records referencing the DNSKEY.
> 2. It would be good to add a {dsHandle} to be the unique identifier for an
> individual DS.  
7. Section 5.7 Registrars
> 1. We might want to capture some additional information for the Registrar
> like:
>> 1. address 
>> 2. url 
>> 3. whois server 
>> 4. status  The possible values could include ACTIVE, HOLD, INACTIVE and
>> could be up to the definition of the server.
>> 5. createdDate 
>> 6. createdBy 
>> 7. updatedDate 
>> 8. updatedBy
> 2. Should the Registrar Contacts be deposited as well?
> 3. I¹m not sure from the draft what is required and what is not required, but
> the {ianaId} might need to be optional to support escrow of non-regulated
> TLD¹s.  
8. Users - I believe it would be good to include information about the
users, where there could be more than one user per account.  It is the users
that create and update objects.  I would propose the following attributes
for a user:
> 1. {userHandle}, User Handle
> 2. {registrarHandle}, Registrar Handle for the user¹s Registrar.  A Registry
> User could be linked to a Registry Registrar record, but there could be a
> special value for Registry users like REGISTRY.
> 3. {status} - Status of the user like ACTIVE, INACTIVE.  The possible values
> and meanings might be defined by the server.
> 4. {type} - Type of user.  This could include types like EPP, CSR, ADMIN,
> etc.. 
> 5. {name} - User name
> 6. {password} - Hash of password.  The hashing tool and source used by the
> Registry could be deposited, for use of the passwords.  The alternative is
> having to reset all of the passwords
> 7. {phoneNumber} - Phone number of user
> 8. {faxNumber} - FAX number of user
> 9. {email} - E-mail address of user
9. Section 5.16 DS deletions
> 1. It would be good if this referenced the {dsHandle} instead of the
> {domainHandle} 
> 2. Based on rfc4310bis there would be the need for Key deletions as well to
> handle Registries supporting the Key Data Interface.
10. Section 5.17 Internationalized Domain Names (IDNs)
> 1. This is too specific to a single implementation of IDN¹s.  The only fields
> that might be common across Registries would be:
>> 1. {domainHandle}
>> 2. {languageCode} - Which is currently missing from the draft
>> 3. {variant} - General variant information that is server specific.  The
>> question is whether this is needed at all since the variant can be
>> regenerated from the domain name and the code tables.
11. Section 5.18 IANA IDN Tables index
> 1. This should be optional
12. Section 5.19 EPP Contact information disclosure
> 1. This should be optional based on support by the server of the optional
> <contact:disclose> element.
13. Section 5.20 through 5.24 could be handled by simply depositing the EPP
Greeting.  This rarely ever changes, so I¹m not sure what the value is for
depositing this information each time.
14. Section 6
> 1. Why would be deposit the XML schemas for the RFC XML schemas?  I could see
> depositing the XML schemas for custom mappings and extensions, but the RFC
> URI¹s should be good enough for identifying the XML schemas.

-- 

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: by way of Paul Hoffman <[email-masked]>
Date: Mon, 25 Jan 2010 20:40:06 -0500
To: <[email-masked]>
Subject: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Internet Domain Registry Data Escrow specification
        Author(s)       : F. Arias
        Filename        : draft-arias-registry-data-escrow-00.txt
        Pages           : 24
        Date            : 2010-01-25

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arias-registry-data-escrow-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

[The following attachment must be fetched by ftp.  Command-click the URL
below to ask your ftp client to fetch it.]
<ftp://ftp.ietf.org/internet-drafts/draft-arias-registry-data-escrow-00.txt>
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
ire mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ire