Hey, Gustavo. I’ve read through the changes, and yes, you addressed my concerns. Thanks for the additional normative language and the attention to defining terminology.
Joe > On Aug 12, 2020, at 19:07, Gustavo Lozano <gustavo.loz...@icann.org> wrote: > > Thank you Joe, > > Version 09 of the draft has been published. The authors believe that this > version addresses your feedback. > > The differences are here: > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-dnrd-objects-mapping-09 > > Regards, > Gustavo > > On 7/25/20, 08:47, "Joe Clarke via Datatracker" <nore...@ietf.org> 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 regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
