[Tsv-art] Tsvart last call review of draft-ietf-drip-auth-43

[Gorry Fairhurst via Datatracker <[e-mail]>]

Reviewer: Gorry Fairhurst
Review result: Ready with Issues

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
[e-mail] 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 [e-mail]
   (mailto:[e-mail]) 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.”