Subject: [regext] Roman Danyliw's No Objection on draft-ietf-regext-dnrd-objects-mapping-09: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 24 Aug 2020 12:30:37 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-regext-dnrd-objects-mapping-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this document and the various XLS/CSV examples related to
particular elements of the data model.

** Section 4.4.  Per the use of SHA-256 as a checksum algorithm, what
identifier should be used in the cksumAlg attribute?

** Section 4.4.  I concur with the OPSDIR reviewer (Joe Clarke), it would seem
like native support (in the format itself) for a more robust checksum algorithm
would be desirable.

** Section 4.6.2.1.  Per “The <rdeCsv:file> child element defines a reference
to the CSV file name”, is any file path information permitted, or are do all
referenced files in dump need to be unique?

** Section 5.8.1.  Please add a normative reference to XPath

** Section 7.  If one had a business model requiring that checksums  be
computed using SHA-384 (set @cksumAlg) or using 7z compression (set
@compression), how would one specify that in the profile per the defined steps
in this section – nothing needs to be extended (step 1, step 3) or <policy>
doesn’t seem to support specifying a particular attribute (step 2), so would
one hard-code that into a custom schema (step 4)?

** Editorial Nits
- Section 9.1  Typo. s/Seperated/Separated/

- Section 11.  Typos.  A few repeated instances.  s/section Section/Section/g