Last Call Review of draft-ietf-regext-dnrd-objects-mapping-06

Request Review of draft-ietf-regext-dnrd-objects-mapping
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2020-03-09
Requested 2020-02-24
Authors Gustavo Lozano, James Gould, Chethan Thippeswamy
Draft last updated 2020-03-08
Completed reviews Genart Last Call review of -06 by Roni Even (diff)
I18ndir Last Call review of -06 by Marc Blanchet (diff)
Opsdir Last Call review of -06 by Joe Clarke (diff)
Opsdir Telechat review of -08 by Joe Clarke (diff)
Assignment Reviewer Joe Clarke 
State Completed
Review review-ietf-regext-dnrd-objects-mapping-06-opsdir-lc-clarke-2020-03-08
Posted at
Reviewed rev. 06 (document currently at 11)
Review result Has Issues
Review completed: 2020-03-08


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 well?