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 < [email protected]> 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? > > >
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
