Thanks for writing this document.

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

The protocol defines a format and a set of security procedures. It uses two transmission modes, but does not appear to use IETF-defined transports. I did not identify any critical transport issues.

In reviewing I did find some topics, that I think do not relate to the technical content, but I think ought to be resolved to finish the publication:

1. Section 3 is entitled “Background” and yet it makes requirements. This, to me, seems an odd title. I would strongly suggest a better title for the section, even if that happens to be as benign as “DRIP Authentication Procedure”.

2. The appendices might be normative?  It would be helpful to state that the appendices are normative or informative? - It seems the latter?

3. The IANA procedures do not clearly explain the role of IANA, but almost do... Please check. For instance, does the following result in a request by IANA to the review team, or by the requester directly to the team?
“Registration requests MUST be sent to drip-reg-review@ietf.org
   (mailto:drip-reg-review@ietf.org) and be evaluated within a three-
   week review period on the advice of one or more designated experts.“
===

I have some editorial comments that might be addressed to provide clarification:

I found the following sentence a little hard to parse - it likely could be made easier to read?:
“Note however that if Length octets was exhausted
   exactly at the end of an Authentication Page then the Additional Data
   Length field will occupy the first octet of the following page the
   remainder of which under DRIP will be null padded.”

Later, in 6.2:
“Without any fragmentation or loss of pages with transmission FEC
   (Section 5) MUST NOT be used as it is impractical.”
- Requiring something to not be used because it is impractical seems like an incomplete statement, especially since this seems to depend on loss in some was, I suspect the sentence could be easily reworded to say what is the constraint.

This seems like an oddly phrased requirement:
“It is REQUIRED that a UA send the following DRIP Authentication
   Formats to fulfill the requirements in [RFC9153]:”
- when the requirement itself is followed by a set of keywords stating requirements. Is this a lower case “required”?

I was unsure what is actually intended here, why a “few” and possibly a missing word somewhere?
“In Extended Transports, the hash is over the Message Pack so only few  hashes need to be in a Manifest. “

Could you better explain “radically”, does the hash change (slightly?) when the content is static, it was not clear to me how?
“This message content is static; its hash never changes radically.”

The intent of the sentence below was not clear to me (although it might be explained later, this requirement seems incomplete). It would be nice if the sentence with the keyword clearly explained the requirement, is “as-is” related to sending messages also with another encoding?:
“The DRIP Wrapper MUST NOT be used in place of sending the ASTM messages as is.”