From nobody Fri Jun  6 16:21:31 2014
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 im=
plementation, 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 we=
ll as having a separate set of external hosts per registrar) and will not s=
upport host name changes.  A host name change should only result in a chang=
e to a single record and not all links to that host record.  The contact id=
entifier 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 cha=
nge only results in a change to a single record and not to all links to tha=
t 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 thin=
k this  could be an omission in the specification and could be amended. The=
 CVS version actually uses the ROID to link domainObjects and hostObjects(n=
ameservers).

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.

--=20
=20
JG
=20

=20
James Gould
Principal Software Engineer
jgould@verisign.com
=20
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=20
>the -05
>version* of the document (previously, I skipped that CSV parts). I got=20
>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=3D"sep" type=3D"rdeCsv:sepType" default=3D","/> ...

   <simpleType name=3D"sepType">
      <restriction base=3D"string">
         <minLength value=3D"1"/>
         <maxLength value=3D"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 t=
o 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=20
>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=20
>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=20
>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 obje=
ct level.  The "domainContacts" CSV file, either used under the <csvDomain:=
contents> or <csvDomain:deletes> elements, represents the link table betwee=
n 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=20
>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 we=
ll as having a separate set of external hosts per registrar) and will not s=
upport host name changes.  A host name change should only result in a chang=
e to a single record and not all links to that host record.  The contact id=
entifier 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
>
>
>
>*=20
>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 par=
a uso exclusivo del destinatario. Si recibes este mensaje y no eres el dest=
inatario por favor eliminalo, ya que difundir, revelar, copiar o tomar cual=
quier accion basada en el contenido esta estrictamente prohibido. Network I=
nformation 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 publica=
cion en los casos aplicables; el cumplimiento de la relacion existente; asi=
 como para la prevencion o denuncia en la comision de ilicitos. Si eres col=
aborador o candidato a colaborador de NIC Mexico, tus datos seran utilizado=
s para: la creacion y administracion de tu perfil como profesionista; el ot=
orgamiento de herramientas de trabajo; la realizacion de estudios; el otorg=
amiento de programas y beneficios para mejorar tu desarrollo profesional; l=
a gestion y administracion de servicios de pago y/o nomina; asi como para c=
ontacto y/o notificaciones. Si participas en promociones o en estudios podr=
as dejar de participar. Para mayor informacion revisa el Aviso de Privacida=
d [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, sin=
ce 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: provid=
e, research, analyze and improve the service; send communications and notic=
es; transfer and publish your personal data when applicable; fulfill the ex=
isting relationship; prevent or inform in the commission of unlawful acts o=
r events.  If the data is processed in your quality of candidate or collabo=
rator 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; man=
age 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 [htt=
p://www.nicmexico.mx/static/docs/Aviso_de_Privacidad.pdf]


From nobody Fri Jun  6 16:25:21 2014
Return-Path: <fobispo@isc.org>
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 813AA1A0247 for <ire@ietfa.amsl.com>; Fri,  6 Jun 2014 16:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.065
X-Spam-Level: **
X-Spam-Status: No, score=2.065 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_44=0.6, SPF_SOFTFAIL=0.665] 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 cMUOJaix4Otm for <ire@ietfa.amsl.com>; Fri,  6 Jun 2014 16:25:18 -0700 (PDT)
Received: from mail.hostingnet.com (mail.hostingnet.com [208.87.35.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92FD1A0086 for <ire@ietf.org>; Fri,  6 Jun 2014 16:25:18 -0700 (PDT)
Received: from dynamic-200.sna1.uniregistry.net (wsip-98-189-40-200.oc.oc.cox.net [98.189.40.200]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fobispo@uniregistry.com) by mail.hostingnet.com (Postfix) with ESMTPSA id B9D2B4501D2; Fri,  6 Jun 2014 16:25:10 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Francisco Obispo <fobispo@isc.org>
In-Reply-To: <646E78088D2A9F4D9F94512C78674EEE0B04B791@EXCHANGE-AX.nic.com.mx>
Date: Fri, 6 Jun 2014 16:25:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2061A619-6418-4E4E-AFBF-6B75B7A5683A@isc.org>
References: <524AA490.9060808@knipp.de> <CE703AC8.4EADE%jgould@verisign.com> <646E78088D2A9F4D9F94512C78674EEE0B04B791@EXCHANGE-AX.nic.com.mx>
To: Roger Francisco Castillo Cortazar <rcastillo@nic.mx>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/ire/l_AVg0RoCUt6CzBebqMaO-x7wWc
Cc: "ire@ietf.org" <ire@ietf.org>
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:25:19 -0000

Using the hostObjects automatically makes the host:name the natural =
index. so just make sure that every single host mentioned in the domain =
section appears in the <host> section of the deposit and you=92ll be =
good.

Francisco


On Jun 6, 2014, at 4:21 PM, Roger Francisco Castillo Cortazar =
<rcastillo@nic.mx> wrote:

> 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).
>=20
> Any thoughts?
> Thanks in advance
>=20
> Roger Castillo
> NIC Mexico