[regext] Opsdir last call review of draft-ietf-regext-dnrd-objects-mapping-06

Joe Clarke via Datatracker <noreply@ietf.org> Sun, 08 March 2020 13:18 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: regext@ietf.org
Delivered-To: regext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 561793A090A; Sun, 8 Mar 2020 06:18:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joe Clarke via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: regext@ietf.org, draft-ietf-regext-dnrd-objects-mapping.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.120.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158367353531.6743.14142296844767968400@ietfa.amsl.com>
Reply-To: Joe Clarke <jclarke@cisco.com>
Date: Sun, 08 Mar 2020 06:18:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/EmKW32exlPgLbBUIbS8OjdYUJWc>
Subject: [regext] Opsdir last call review of draft-ietf-regext-dnrd-objects-mapping-06
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 08 Mar 2020 13:18:56 -0000

Reviewer: Joe Clarke
Review result: Has Issues

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, 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