Hi Gustavo! Thanks for answers below and addressing my comments in -09. Please consider my feedback resolved.
Thanks, Roman > -----Original Message----- > From: Gustavo Lozano <gustavo.loz...@icann.org> > Sent: Thursday, October 8, 2020 5:44 PM > To: Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org> > Cc: draft-ietf-regext-dnrd-objects-mapp...@ietf.org; regext-cha...@ietf.org; > regext@ietf.org; Scott Hollenbeck <shollenb...@verisign.com> > Subject: Re: [Ext] Roman Danyliw's No Objection on draft-ietf-regext-dnrd- > objects-mapping-09: (with COMMENT) > > Thank you Roman, > > Comments below are prefixed with Authors-. > > A new version of the I-D has been published here: > https://www.ietf.org/id/draft-ietf-regext-dnrd-objects-mapping-10.txt > > Regards, > Gustavo > > On 8/24/20, 12:30, "Roman Danyliw via Datatracker" <nore...@ietf.org> > wrote: > > 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss- > criteria.html__;!!PtGJab4!tk33CgA_IPEteHsusEK0roZWxzw786v35y7J1dr- > z2AkTO_ktFH_C2B8qt_qla02uh-Mn0wQLRk$ > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf- > regext-dnrd-objects- > mapping/__;!!PtGJab4!tk33CgA_IPEteHsusEK0roZWxzw786v35y7J1dr- > z2AkTO_ktFH_C2B8qt_qla02uh-MCOlAdzI$ > > > > ---------------------------------------------------------------------- > 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? > > Authors- text added in the next version of the I-D. > > ** 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. > > Authors- text added in the next version of the I-D. > > ** 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? > > Authors- The CSV file name reference can be any file path, but in general is > only > a file name that is relative to the location of the XML definition file. > > ** Section 5.8.1. Please add a normative reference to XPath > > Authors- text added in the next version of the I-D. > > ** 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)? > > Authors- only the values need to be specified in @cksumAlg and @compression > after an out-of-band negotiation. Escrow services are regulated using legal > agreements, and the details are usually specified based on out-of-band- > negotiations. > > ** Editorial Nits > - Section 9.1 Typo. s/Seperated/Separated/ > > Authors- fixed in the next version of the I-D. > > - Section 11. Typos. A few repeated instances. s/section > Section/Section/g > > Authors- fixed in the next version of the I-D. > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
