Skip to main content

Last Call Review of draft-ietf-regext-dnrd-objects-mapping-06
review-ietf-regext-dnrd-objects-mapping-06-opsdir-lc-clarke-2020-03-08-00

Request Review of draft-ietf-regext-dnrd-objects-mapping
Requested revision 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 Ibarra , James Gould , Chethan Thippeswamy
I-D 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
Request Last Call review on draft-ietf-regext-dnrd-objects-mapping by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/MwpZmBQr1hZbr15Iqm00ZbkR0dk
Reviewed revision 06 (document currently at 11)
Result Has issues
Completed 2020-03-08
review-ietf-regext-dnrd-objects-mapping-06-opsdir-lc-clarke-2020-03-08-00
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?