[regext] Opsdir last call review of draft-ietf-regext-dnrd-objects-mapping-06
Joe Clarke via Datatracker <firstname.lastname@example.org> Sun, 08 March 2020 13:18 UTC
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)
Content-Type: text/plain; charset="utf-8"
From: Joe Clarke via Datatracker <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Reply-To: Joe Clarke <email@example.com>
Date: Sun, 08 Mar 2020 06:18:55 -0700
Subject: [regext] Opsdir last call review of draft-ietf-regext-dnrd-objects-mapping-06
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:email@example.com?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 18.104.22.168), 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?
- [regext] Opsdir last call review of draft-ietf-re… Joe Clarke via Datatracker