[regext] draft-ietf-regext-data-escrow Examples Validation

"Gould, James" <jgould@verisign.com> Tue, 10 December 2019 20:06 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE6A120A76 for <regext@ietfa.amsl.com>; Tue, 10 Dec 2019 12:06:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 iRxN_797BYMB for <regext@ietfa.amsl.com>; Tue, 10 Dec 2019 12:05:59 -0800 (PST)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F225B120A47 for <regext@ietf.org>; Tue, 10 Dec 2019 12:05:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=45364; q=dns/txt; s=VRSN; t=1576008359; h=from:to:subject:date:message-id:mime-version; bh=Cy2Y7qCsx0D5wzZIIjq4zZNgNu71ewW5vGHZ8/w6xzI=; b=JHLVMhNTXJoL4BrVNaGmtB06yylzy7Lrz8XqYFY2ijfSH5lQmxnTS7UZ +lpzqH0Vk9dg7tnBzoaAQH/ib0yAjV/L6tgUa2fp8SzoMTgc4nllRsqV7 9rH+yz8FSjUuAe4+PkLSchVCk8lqIjSWPyxYDiEshG9cCj2HeGkzDOt3a VBotAtFIa8JOc+UZeIBOvQVs41Hz+kxZbp1gW5Z6pm7ho52T0LpdNNiOq xgMtQj4Qs/wz/ReD5dCuJ0KfbkCgLE+xViJrXkb99BvfQzW0OmNqlYb44 qQNJgoBM1rNJ2afrPLVgujCKA6i4L4EgxpJ1EJGHIjvvnrj3jIUwQuzM9 Q==;
IronPort-SDR: ypz3MmCv3IVxUflU0BCmkxAN/quZZjh+6qY+2Fn2AyyCFUubpEXADAzS4Os19yyIu4pQZGOCRj ppyAvKxFDbh8/wBnDm03FPqBJ3Qc0y3BYQwbng4vlTJrP8E06qhvBNygRJwoxhGW6ID2GFYepz 6KCry842iAeIT/M113McqpFZWx3CUyW+EZgIxP3J0wx7mpi+aEfnjwA8GTwlQgY6qK6Ws/zBnE sdwdj87blElS2tUAOEaqFjoLiMQgCk7iPxuRYNmKSTJy2nIzfCFm2dZqJZEZsXrPH4t9k1EBBo Wuc=
X-IronPort-AV: E=Sophos;i="5.69,300,1571702400"; d="png'150?scan'150,208,217,150";a="290053"
IronPort-PHdr: 9a23:K1gvwBE/pT+XwLiIQvVHCZ1GYnF86YWxBRYc798ds5kLTJ7zoMuwAkXT6L1XgUPTWs2DsrQY0rGQ6vG7EjVbuN6oizMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vIhi6txjdu80YjIdtN6o8xAbFqWZUdupLwm9lOUidlAvm6Meq+55j/SVQu/Y/+MNFTK73Yac2Q6FGATo/K2w669HluhfFTQuU+3sTSX4WnQZSAwjE9x71QJH8uTbnu+Vn2SmaOcr2Ta0oWTmn8qxmRgPkhDsBOjUk9mzcl85+g79BoB+5pxJx3ZPaYJ2bOvR9cKzdfM8VSmVaU8ZLSyBBB5mxY5cVAucDO+tTsonzp0EJrRu7HQSgCuLhyjhVhn/ywKI2y/kqHwXc0wwlAd0Oq3rYp8jyOacQXuC1y7TIzTHeYP5Nxzfy9pLIchE6ofGNUrJwd9DdxlUoFwPAl1idr5HuMT2S1uQIqWeb7uxgWPqxi2E5sQFxoyOvxsYjionPh4IVzEzL+T9lz4YyIN21TlNwb928EJZIqi2WK5F6Tt4gTmxmoio2170LtJChcCUFy5kr3wPTZ+Cdf4SV4B/vSPydLSp3iX9mYr6zmhW//VCuyuLiVcS4zFNHoy9fndTPsn0CzBne58aZRvRg/0qs3C2A2gTS5+xGJE05m6TWJpw8zbM2i5Edq17MHjXsl0XzlKKWc0Ik9fW25On/ebXmo4OcN5dzigHjLqQigsy/Dvo8MggJR2WW5Piy2qX+8UL5WLtEgfw5nrXEvJzAO8QUuqm5AxVN0oo58RmwEi2q0MoCnXkcKlJJYg6Ij4/sO13WIfD4C+mwg0i0nTt22/zKJKDtD5fDI3TZjbvsfbhw51RTxQcw1dxf4ohbCrAFIPL9QE/xs9nYAwc7Mwy7xObnFdF92Z4FVGKRHKCZKqLSsUSJ5uIgJemAfpMauDH4K/Q9/f7hkWc5mUMBfamuxZYXcm63Hvt4LESWfXrhmdYBHnkWvgowVuDqj0eCUTEAL0q1Cugm6z42GJ6ODIrfSMaqmrPLlHOhE5JbdnxuC12QHzHvbYrSCNkWbyfHaOBmjzgIEfCDQooszlvm4A31zKdjIsLK9zcZrpPs0p5+4OiFxkJ6ziB9E8nIizLFdGpzhG5dHzI=
X-IPAS-Result: A2HoEgCU+e9d/zCZrQpiA4NggXCBMQqDeY5kCIIegzNelwc8CQEBAQEBAQEBAQMBAwETDBABAQKEPhmCETgTAgMBAQsBAQEEAQEBAQEFAwEBAQKGIAELgjsicS8JATgBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHTQdHKwEdAggBXQEGHwEBARgBCQIEBRABDgwnBBIBBgiDFAGWEpp/dYEyhDoBgRSEdhCBNowygUI+gTgMFIdqCiaCSTKCLASQJIVTJG6NZYJnhw8DB4IvhgoBgRiOaIJCdJcCjRSBNoFFhX2BA5FsAgQCBAUCFYFpgXtwFTsqAYJBCUcRFIxyF4NQilN0DSSMRiuBBDFfAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 10 Dec 2019 15:06:22 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1779.002; Tue, 10 Dec 2019 15:06:22 -0500
From: "Gould, James" <jgould@verisign.com>
To: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: draft-ietf-regext-data-escrow Examples Validation
Thread-Index: AQHVr5VLAWffddmbAEu3apQIAwsYlw==
Date: Tue, 10 Dec 2019 20:06:22 +0000
Message-ID: <2C88A3FA-0037-4B8B-8A88-9391A1B9DB3B@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.f.191014
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_2C88A3FA00374B8B8A889391A1B9DB3Bverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Y2G2yHJppT1DSb8_TYp4uMo0T-s>
Subject: [regext] draft-ietf-regext-data-escrow Examples Validation
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2019 20:06:02 -0000

I performed a validation of the XML and CSV examples in draft-ietf-regext-dnrd-objects-mapping upon the request of Scott Hollenbeck, the Document Shepherd for draft-ietf-regext-dnrd-objects-mapping.  While performing the validation of draft-ietf-regext-dnrd-objects-mapping, I uncovered an issue with draft-ietf-regext-data-escrow that I include in issue #1 below.  Below are the list of issues identified while performing the validation of the examples in draft-ietf-regext-dnrd-objects-mapping.  I will work with Gustavo to correct the issues.


  1.  draft-ietf-regext-data-escrow
     *   The rde:contentsType should be defined with minOccurs=”0”; otherwise you can’t include a differential or incremental deposit with only deleted objects.  The rde:contents element in draft-ietf-regext-data-escrow of the rde:escrowDepositType should be defined with minOccurs=”0” also for the same reason.
  2.  Section 5.1.1.1 <rdeDomain:domain> object

     *   Found the use of inconsistent XML prefixes for the RDE Domain content example (“rdeDom”) and the delete example (“rdeDomain”).  I believe that “rdeDomain” should be used in place of “rdeDom”.

  1.  Section 17 Example of a full deposit using the XML model

     *   “Domain” is spelled “Domian”.
     *   Remove <rde:deposit> “prevID” attribute for a full deposit.

  1.  Section 5.6.1.2
     *   <rdeNNDN:delete> object </rdeNDN:aName> needs to be </rdeNNDN:aName>

  1.  Section 19 full CSV deposit

     *   Remove <rde:deposit> “prevID” attribute for a full deposit.

  1.  Section 5.5.2.1.1 “idnLanguage CSV File Definition

     *   Example needs to be updated to use <rdeCsv:csv name="idnLanguage" sep=","> and not include the <rdeCsv:sep>,</rdeCsv:sep> element.

  1.  Section 5.2.2.1.3 “hostAddresses” CSV File Definition

     *   Change reference of hostAddressesObj-YYYYMMDD.csv to hostAddresses-YYYYMMDD.csv

  1.  Need to update the dates to a more recent date than 2010 throughout the examples.

     *   Section 17 “full XML deposit”
                                                              i.      <rde:deposit> element “id” attribute value of "20101017001".  I recommend changing it to something like “20191217001”.
                                                            ii.      <rde:watermark> element date should be set to a 2019 value, such as “2019-12-17T00:00:00Z”

     *   Section 18 “differential XML deposit”
                                                              i.      <rde:deposit> element “id” attribute value of "20101017002" and “prevId” attribute value of “20101017001”.  I recommend changing the “id” attribute to “20191217002” and the “prevId” attribute to “20191217001”.
                                                            ii.      <rde:watermark> element date should be set to a 2019 value, such as “2019-12-17T00:00:00Z”

     *   Section 19 “full CSV deposit”
                                                              i.      <rde:deposit> element “id” attribute value of "20101017001".  I recommend changing it to something like “20191217001”.
                                                            ii.      <rde:watermark> element date should be set to a 2019 value, such as “2019-12-17T00:00:00Z”

     *   Section 20 “differential CSV deposit”
        *   <rde:deposit> element “id” attribute value of "20101017002" and “prevId” attribute value of “20101017001”.  I recommend changing the “id” attribute to “20191217002” and the “prevId” attribute to “20191217001”.
        *   <rde:watermark> element date should be set to a 2019 value, such as “2019-12-17T00:00:00Z”

Thanks,

--

JG

[cid:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgould@Verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>