[GROW] Roman Danyliw's No Objection on draft-ietf-grow-nrtm-v4-09: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-grow-nrtm-v4-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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-nrtm-v4/



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

Thank you to Paul Kyzivat for the GENART review.

** Section 6.3
   *  The hash attribute in snapshot and delta elements MUST be the
      hexadecimal encoding of the SHA-256 hash [SHS] of the referenced
      file.  The mirror client MUST verify this hash when the file is
      retrieved and reject the file if the hash does not match.

This document is hard-coding SHA-256.  What is the proposed approach for
algorithm agility?

** Section 6.4
   *  Implementations MUST support ES256 for interoperability.  The
      algorithm MUST NOT be Deprecated

Consider if it worth emphasizing (since RFC9864 needed to clarify) that “The
selected algorithm MUST NOT be marked as Deprecated or _Prohibited_”? (i.e.,
add text about “Prohibited”).