Thanks for the reminder and the review, Joe. I will make sure your comments are addressed before the document moves forward.
Barry
On Sat, Jul 25, 2020 at 11:47 AM Joe Clarke via Datatracker <noreply@xxxxxxxx> 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?
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
