Re: [regext] [Ext] Opsdir telechat review of draft-ietf-regext-dnrd-objects-mapping-08

Gustavo Lozano <gustavo.lozano@icann.org> Wed, 12 August 2020 23:07 UTC

Return-Path: <gustavo.lozano@icann.org>
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 A3A863A0CB0; Wed, 12 Aug 2020 16:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 bwETq0toB6Ay; Wed, 12 Aug 2020 16:07:29 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 EB02A3A0CA5; Wed, 12 Aug 2020 16:07:28 -0700 (PDT)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 07CN7R0p010813 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Aug 2020 23:07:27 GMT
Received: from MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.595.3; Wed, 12 Aug 2020 16:07:26 -0700
Received: from MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) by MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) with mapi id 15.02.0595.003; Wed, 12 Aug 2020 16:07:26 -0700
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: Joe Clarke <jclarke@cisco.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-regext-dnrd-objects-mapping.all@ietf.org" <draft-ietf-regext-dnrd-objects-mapping.all@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [Ext] Opsdir telechat review of draft-ietf-regext-dnrd-objects-mapping-08
Thread-Index: AQHWYpr2lF7enUVoE0eS52ACjY/9mak1NXiA
Date: Wed, 12 Aug 2020 23:07:26 +0000
Message-ID: <8499DA6B-6ABB-42D7-B396-B117DB992E51@icann.org>
References: <159569207226.17171.11673402373410373537@ietfa.amsl.com>
In-Reply-To: <159569207226.17171.11673402373410373537@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.38.20061401
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: text/plain; charset="utf-8"
Content-ID: <476E3BEEF68C2E468FC7E57C77EF8C14@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-12_19:2020-08-11, 2020-08-12 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/eAE8s7pjF0rQdV0WcqxOWh0xeGU>
Subject: Re: [regext] [Ext] Opsdir telechat review of draft-ietf-regext-dnrd-objects-mapping-08
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: Wed, 12 Aug 2020 23:07:31 -0000

Thank you Joe,

Version 09 of the draft has been published. The authors believe that this version addresses your feedback.

The differences are here:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-dnrd-objects-mapping-09

Regards,
Gustavo

On 7/25/20, 08:47, "Joe Clarke via Datatracker" <noreply@ietf.org> wrote:

    Reviewer: Joe Clarke
    Review result: Has Issues

    I didn't see any of my comments addressed in the text nor do I recall seeing a
    reply to my previous review.  I;m copying my previous review here.

    I have been assigned to review this document on behalf of the Ops Area
    Directorate.  This document augments the work set forth in
    I-D.ietf-regext-data-escrow to specify the objects that can be used in Domain
    Name Registration Data escrow deposits.  What I found most useful in this
    document is the incremental examples of the objects with the full XML and CSV
    deposit (and diff deposit) examples at the bottom.  In general, the fields in
    the object models were well specified and coupled with the examples, it helped
    to piece together the product one might need to produce.

    That said, I went back and forth between "Has Nits" and "Has Issues".  One
    thing that would really help this document is a full terminology/glossary
    section that includes expansions of abbreviations like RDE, EPP, NNDN, etc. 
    Some abbreviations like TLD, CSV, and IDN are expanded, but this is very much
    required for all and throughout with very common ones done so in the
    terminology section.

    Next, in Section 4.4, you talk about CSV file checksums.  First, you reference
    ISO-3309 (HDLC?) but there is no actual reference like there is with
    ISO-3166-1.  But why use crc32 for a file checksum?  Why reference HDLC as the
    model?  I would think a SHA-2 checksum would be better for an actual file to
    ensure it has not been tampered with.

    When you talk about file compression for CSV (Section 4.6.2.1), you mention
    compression may use zip or gzip.  There is no normative language here, and I
    can imagine escrow holders would need to know the allowed values.  If I use xz
    will that be allowed?  Will the consumer know how to decompress that?  What is
    "zip" and "gzip" exactly and how should they be handled?  My advice is some
    normative text here explaining the supported or allowed formats and by what
    standard those are defined.

    Finally, as a nit, I noticed two instances of IPv6 address
    1080:0:0:0:8:800:200C:417A when showing XML model examples.  In the CSV
    examples you use an address from the doc range.  Did you mean to do so here as
    well?