Re: [ire] CSV woes

Roger Francisco Castillo Cortazar <rcastillo@nic.mx> Fri, 06 June 2014 23:21 UTC

Return-Path: <rcastillo@nic.mx>
X-Original-To: ire@ietfa.amsl.com
Delivered-To: ire@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6101A0247 for <ire@ietfa.amsl.com>; Fri, 6 Jun 2014 16:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.335
X-Spam-Level: *
X-Spam-Status: No, score=1.335 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MX=0.535] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USYUvdUS4ray for <ire@ietfa.amsl.com>; Fri, 6 Jun 2014 16:21:27 -0700 (PDT)
Received: from mail-ax.axtel-mty.nic.net.mx (mail-ax.axtel-mty.nic.net.mx [IPv6:2001:1250:ffe0:1::2]) by ietfa.amsl.com (Postfix) with ESMTP id A144F1A0086 for <ire@ietf.org>; Fri, 6 Jun 2014 16:21:27 -0700 (PDT)
Received: from EXCHANGE-AX.nic.com.mx (exchange-ax.nic.com.mx [10.20.20.49]) by mail-ax.axtel-mty.nic.net.mx (Postfix) with ESMTP id 2B7116DA436 for <ire@ietf.org>; Fri, 6 Jun 2014 18:21:18 -0500 (CDT)
Received: from EXCHANGE-AX.nic.com.mx ([10.20.20.49]) by EXCHANGE-AX.nic.com.mx ([10.20.20.49]) with mapi id 14.01.0438.000; Fri, 6 Jun 2014 18:21:17 -0500
From: Roger Francisco Castillo Cortazar <rcastillo@nic.mx>
To: "ire@ietf.org" <ire@ietf.org>
Thread-Topic: [ire] CSV woes
Thread-Index: AQHOvp7kznO0Qldb10+jO0bMY1Lx85ngJ+oAgYYKY8A=
Date: Fri, 6 Jun 2014 23:21:17 +0000
Message-ID: <646E78088D2A9F4D9F94512C78674EEE0B04B791@EXCHANGE-AX.nic.com.mx>
References: <524AA490.9060808@knipp.de> <CE703AC8.4EADE%jgould@verisign.com>
In-Reply-To: <CE703AC8.4EADE%jgould@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.150.88.9]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-NICMX-MailScanner-Information: Please contact the ISP for more information
X-NICMX-MailScanner-ID: 2B7116DA436.A1424
X-NICMX-MailScanner: Found to be clean
X-NICMX-MailScanner-From: rcastillo@nic.mx
Archived-At: http://mailarchive.ietf.org/arch/msg/ire/B58B3WAYiA4UAG54ycxtiohmbx8
Subject: Re: [ire] CSV woes
X-BeenThere: ire@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <ire.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ire>, <mailto:ire-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ire/>
List-Post: <mailto:ire@ietf.org>
List-Help: <mailto:ire-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ire>, <mailto:ire-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jun 2014 23:21:29 -0000

Hi All.

Sorry to resurrect this old topic, but we're having some issues with our implementation, especially with handling hosts.

To set the context let me copy the last paragraph of the replied message:

<copied text>

The hosts are referenced by ROIDs instead of the host name, since use of a natural key (host name), will not work for some host models (hostAttr as well as having a separate set of external hosts per registrar) and will not support host name changes.  A host name change should only result in a change to a single record and not all links to that host record.  The contact identifier is unique and can't be changed, so it can be used directly without use of a surrogate key via the ROID.

</copied text>

So far so god. Our system uses the HostObject approach, and a host name change only results in a change to a single record and not to all links to that host record. Now, we are implementing our deposits using the XML format, and we see that the specification does not consider using the ROID to link the domainObject  and the hostObjects but only the by the HostName. We think this  could be an omission in the specification and could be amended. The CVS version actually uses the ROID to link domainObjects and hostObjects(nameservers).

Any thoughts?
Thanks in advance

Roger Castillo
NIC Mexico

---

Below we can find excerpts from " draft-arias-noguchi-dnrd-objects-mapping-05"

In the XML specification for domain objects reads:

The <domain> element contains the following child elements:
...

   o  An OPTIONAL <ns> element that contains the fully qualified names
      of the delegated host objects or host attributes (name servers)
      associated with the domain name object.  See Section 1.1 of
      [RFC5731] for a description of the elements used to specify host
      objects or host attributes.
...

The CVS Spec for domain objects includes:
...

  "domainNameServers"  Defines the fields and CSV file references used
      for the domain name delegated hosts (name servers).  The
      "domainNameServers" CSV files define the relationship between a
      domain name object and a delegated host.  To support both the
      <domain:hostAttr> and the <domain:hostObj> model, defined in
      [RFC5731], the host <rdeCsv:fRoid> field element is used to
      reference the host.

....

-----Original Message-----
From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of Gould, James
Sent: martes, 01 de octubre de 2013 08:18 a.m.
To: Klaus Malorny; ire@ietf.org
Subject: Re: [ire] CSV woes

Klaus,

I respond to your feedback below.

-- 
 
JG
 

 
James Gould
Principal Software Engineer
jgould@verisign.com
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com




On 10/1/13 6:31 AM, "Klaus Malorny" <Klaus.Malorny@knipp.de>; wrote:

>
>
>Hi all,
>
>unfortunately, I now have to deal with the CSV format and read through 
>the -05
>version* of the document (previously, I skipped that CSV parts). I got 
>the following questions:
>
>- the separator: a separator different to the default comma separator can
>   be specified by the "sep" attribute. Following the schema definition,
>   it can be any token, including multi-character strings or even an empty
>   string (which makes the file unparsable, of course). I don't think that
>   this is intended

Good catch, we can update the schema to support a single character for the separator like below:

...
    <attribute name="sep" type="rdeCsv:sepType" default=","/> ...

   <simpleType name="sepType">
      <restriction base="string">
         <minLength value="1"/>
         <maxLength value="1"/>
      </restriction>
   </simpleType>

Do you have any additional proposals on restrictions?




>
>- it is left open how to deal with special characters, including, but
>   not limited to, quotes, separators and newlines. I wonder why there
>   is no reference to RFC 4180

Additional clarity could be added here.
draft-arias-noguchi-dnrd-objects-mapping does not conform to RFC 4180 (e.g. No header and support for UTF-8), but elements of RFC 4180 could be used to provide additional clarity around the handling of quotes, separators, and newlines in the CSV files.


>
>- it is unclear to me why the "deletes" entries may have subtables 
>included,
>   e.g. the "csvDomain:deletes" the "domainContacts", as depicted in
>   the example in section 5.1.2 on page 23. Does it mean that in 
>incremental or
>   differential escrows, the CSV format allows the addition and removal of
>   individual multi-value entries? For example, if I have the domain
>   "example.tld", and the technical contact has changed from "abc123" to
>   "def456", the "domainContacts" table in the <csvDomain:contents>
>   section would *only* contain the line
>
>     example.tld,def456,tech
>
>   (and missing the admin and billing references) and the "domainContacts"
>   table in the <csvDomain:deletes> section would contain an entry
>
>     example.tld,abc123,tech
>
>   This would be a large difference to the XML format, as there the full
>   object is always being replaced, and it would be also quite a hassle 
>and
>   error-prone to generate or read and process this.


Yes, the CSV model is relational based and not object based, so incremental and differential deposits are done at the record level and not at the object level.  The "domainContacts" CSV file, either used under the <csvDomain:contents> or <csvDomain:deletes> elements, represents the link table between the domain and the contact CSV files.  With the CSV files, you apply the deltas at the record level as opposed to the object level.
That is the fundamental difference between the XML and CSV models in draft-arias-noguchi-dnrd-objects-mapping.

>
>- I do not understand why in "domainNameServers", hosts are referenced
>   by their ROIDs, whereas in "domainContacts", contacts are referenced
>   by their IDs, especially as this seems to have been changed to the
>   worse. The specification argues with supporting both hostAttr and 
>hostObj
>   models, however, it leaves completely open how the hostAttr model
>   is represented.

The hosts are referenced by ROIDs instead of the host name, since use of a natural key (host name), will not work for some host models (hostAttr as well as having a separate set of external hosts per registrar) and will not support host name changes.  A host name change should only result in a change to a single record and not all links to that host record.  The contact identifier is unique and can't be changed, so it can be used directly without use of a surrogate key via the ROID.

>
>These are the questions for now, maybe more come later ;-)

Thank you for your feedback.

>
>Regards,
>
>Klaus
>
>
>
>* 
>http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05
>_______________________________________________
>ire mailing list
>ire@ietf.org
>https://www.ietf.org/mailman/listinfo/ire

_______________________________________________
ire mailing list
ire@ietf.org
https://www.ietf.org/mailman/listinfo/ire


----------


Este mensaje contiene informacion confidencial y se entiende dirigido y para uso exclusivo del destinatario. Si recibes este mensaje y no eres el destinatario por favor eliminalo, ya que difundir, revelar, copiar o tomar cualquier accion basada en el contenido esta estrictamente prohibido. Network Information Center Mexico, S.C., ubicado en Ave. Eugenio Garza Sada 427 L4-6 Col. Altavista, Monterrey, Mexico, C.P. 64840 recaba tus datos personales necesarios para: la prestacion, estudio, analisis y mejora del servicio, la realizacion de comunicaciones y notificaciones; la transferencia y publicacion en los casos aplicables; el cumplimiento de la relacion existente; asi como para la prevencion o denuncia en la comision de ilicitos. Si eres colaborador o candidato a colaborador de NIC Mexico, tus datos seran utilizados para: la creacion y administracion de tu perfil como profesionista; el otorgamiento de herramientas de trabajo; la realizacion de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gestion y administracion de servicios de pago y/o nomina; asi como para contacto y/o notificaciones. Si participas en promociones o en estudios podras dejar de participar. Para mayor informacion revisa el Aviso de Privacidad [http://www.nicmexico.mx/static/docs/Aviso_de_Privacidad.pdf]


This message contains confidential information and is intended only for the individual named. If you are not the named addressee please delete it, since the dissemination, distribuition, copy or taking any action in reliance on the contents is strictly prohibited. Network Information Center Mexico, S.C., located on Av. Eugenio Garza Sada 427 Col. Altavista L4-6, Monterrey, Mexico, CP 64840 collects your personal data which is necessary to: provide, research, analyze and improve the service; send communications and notices; transfer and publish your personal data when applicable; fulfill the existing relationship; prevent or inform in the commission of unlawful acts or events.  If the data is processed in your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your profile as a professional; provide you with working tools; conduct studies; grant benefits and programs to enhance your professional development; manage and administrate payment services and/or payroll; as well as to contact you. If you participate in promotions or surveys you may stop or quit your participation at any time. For more information read the Privacy Note [http://www.nicmexico.mx/static/docs/Aviso_de_Privacidad.pdf]