Subject: [ire] Some comments on draft-arias-noguchi-registry-data-escrow-02

From: Patrick Mevzek <[email-masked]>
Date: Tue, 02 Aug 2011 17:51:30 +0200

Hello

Some comments below.

1) 
§5.1 says:
The container or root element for a Registry Data Escrow deposits is
   <deposit>.  This element contains the following child elements:
   watermark, deletes, contents, and extension.

However §5.4 "Child <contents> element" says:
This element MAY also contain an
   extension element allowing extending the format.

Since the two extension element are probably the same it is either child
of deposit or child of contents so one of the two texts should be
changed.
Based on the XML Schema, §5.1 seems right and §5.4 wrong.

But if the need is to handle some other kind of objets, let us say a
defensive registration, it would make more sense I think to have this
object instances both under deletes and contents, alongside other "core"
objects.
So instead of having a separate extension, have 2 of them, one for
contents the other for deletes. Or mandates that the separate extensions
has both contents and deletes as children.

2) id attribute of <contents>

Why not reuse the "algorithm" from RFC5730 §2.8 ?

3) ICANN specifications rely/specify only on deposits types FULL and
DIFFERENTIAL.
Also §3.1 of specification 2 of ICANN future gTLD contract specifically
mention the draft as a possible RFC at some point
otherwise registry operator has to implement the latest version at time
of signing: this could create many different formats if the
specification change in not so subtle manners during ~2012
(the same situation happened with EPP, which has an EPP "0.4" vs an EPP
"1.0"). The wish towards an RFC would need to define some milestones.

4) about RDE Host object

If the registry uses hosts as domain attributes instead of first class
objects, there should some explanation about that in the draft, just
stating that no host objects would appear, and everything related to
nameserver changes would be in domain objects.

5) purely cosmetic : transfer data is <trnData> in EPP, why not use the
same instead of <transfData> ?

In the same way: why create <dnssec> where it is <secDNS> in the EPP
world?

6) icannID : ICANN assigned registrar ID is called GURID, see
https://radar.icann.org/
so the draft should at least mention this, or even use <gurid> instead
of <icannID> ?

7) as for registrar data globally : registries need to maintain often
multiple names/emails/voice combo, and also separate what is available
publicly (through whois or on registry website) to what is used
internally for day to day business (like emergency contact info,
billing/legal affairs, etc.).
Since the format allows only one email and one voice, this means the RDE
consists basically of what is available publicly... which is not
necessarily enough for the registry to conduct its business with
registrars.
Maybe the format should be extended to provide more elements for that?
Because otherwise the current format for gTLDs does not add value since
the registrar part contents is also what is basically available on ICANN
website at http://www.internic.net/alpha.html and each subpage.

Same for authInfo: which password is this ? A given registrar at a given
registry may have more than one password, like one for EPP and one for
some kind of web site, one for FTP access, one for support, etc.

Also, there is the registrar url, but why not the registrar whois server
address, or IRIS server address? (like what is done in Verisign EPP
WhoisInfo extension)

8) IDN table : maybe the id should be mandatory to be, like IANA
filenames, a concatenation of registry TLD, script/language, and
version ?
Or what is its purpose ? The IANA URL is already an URI anyway.

9) Shouldn't the RDE format be also able to store the list of reserved
domain names, that is domain names that can not be registered for
various reasons? They may exist in the database and be associated with
the registry itself (through a fake registrar object). But in other
implementations, they could not exist at all in the database (and hence
not be visible in <contents>) however they kind of form part of the data
of the registry.

This is related to the IDN handling of reserved domain names.

10) §5.1 the text says nothing about the format of type & id attributes,
however the XML schema mandates a specific pattern

Why force some kind of pattern if the text says basically that the
registry should control its uniqueness?
Also, putting the deposit type inside the id pattern kind of defeats the
usefulness of the type attribute (and introduces a risk of inconsistency
between the two).

11) XML schema has <domain:deDate>, which is never explained anywhere...

Same for <domain:extension> <host:extension> <contact:extension>
<registrar:extension> 
Only <idn:extension> does have a phrase of explanation in the text.

I would advise to have the same kind of document than RFC3735 for EPP,
in order to minimize the number of extensions (no need to have 2 of them
doing the same thing with small differences)

12) about rdeEppParams
a registry may have more than one EPP server, either because of a
transition (example: .EU currently), or because its operations are split
among different farms, with distinct SLAs.
So I believe there should be a way to have more than one <eppParams>
block, because each may have distinct version/lang/extensions announced.
And maybe the name and port (defaulting to 700) of each EPP server is
useful since this is something hard-coded in all registrars systems.

13) there should be somewhere in top node a way to store the list of
types of objects stored inside the registry, in order to know in advance
what we expect in <contents> and <deletes>

As for the XML or something else issue as discussed previously, has
anyone had a look towards some kind of "binary XML", such as EBML,
WBXML, EXI or other variants?
It might be a solution since there is no need to edit or view the escrow
content as XML, just to have it as extensible and formatted as possible.

Hope that helps.

-- 
Patrick Mevzek