From Patrick.Mevzek@afnic.fr Tue Aug 2 08:51:29 2011 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3CB21F86DF for ; Tue, 2 Aug 2011 08:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVQUZw5QgVYp for ; Tue, 2 Aug 2011 08:51:28 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id 349A521F8663 for ; Tue, 2 Aug 2011 08:51:24 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 972AD1C0C74 for ; Tue, 2 Aug 2011 17:51:30 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 894801C0803 for ; Tue, 2 Aug 2011 17:51:30 +0200 (CEST) Received: from [10.1.86.96] (citrine.tech.prive.nic.fr [10.1.86.96]) by relay1.nic.fr (Postfix) with ESMTP id 84FA656812D; Tue, 2 Aug 2011 17:51:30 +0200 (CEST) From: Patrick Mevzek To: "ire@ietf.org" Content-Type: text/plain; charset="UTF-8" Organization: AFNIC Date: Tue, 02 Aug 2011 17:51:30 +0200 Message-ID: <1312300290.27026.315.camel@citrine> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Subject: [ire] Some comments on draft-arias-noguchi-registry-data-escrow-02 X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:51:29 -0000 Hello Some comments below. 1) §5.1 says: The container or root element for a Registry Data Escrow deposits is . This element contains the following child elements: watermark, deletes, contents, and extension. However §5.4 "Child 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 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 in EPP, why not use the same instead of ? In the same way: why create where it is 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 instead of ? 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 ) 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 , which is never explained anywhere... Same for Only 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 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 and 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