Subject: Re: [regext] [Ext] Opsdir telechat review of draft-ietf-regext-dnrd-objects-mapping-08

From: Gustavo Lozano <[email-masked]>
Date: Wed, 12 Aug 2020 23:07:26 +0000

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" <[email-masked]> 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?

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 13 Aug 2020 11:52:19 +0000

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 <[email-masked]> wrote:
> 
> Thank you Joe,
>