Change:
max_ack_delay transport parameter is in milliseconds (Section 18.2 of QUIC-TRANSPORT), min_ack_delay is specified in microseconds. <ins> The min_ack_delay transport parameter is a unilateral indication of support for receiving ACK_FREQUENCY frames.  If an endpoint sends the transport parameter, the peer is allowed to send ACK_FREQUENCY frames independent of whether it also sends the min_ack_delay transport parameter or not. </ins> This Transport Parameter is encoded as per Section 18 of QUIC- TRANSPORT.

Discussion:
Clearly declares that the TP only works in one direction.
To me it seems that the draft can be interpreted in the following two ways. It would be great if there was a clarification regarding which is correct: TP is a declaration that the endpoint will recognize ACKFREQUENCY frames. The receiver of the TP can send ACKFREQUENCY frames regardless of it sending TP or not. Use of delayed acks are negotiated by both endpoints sending TP. ACK_FREQUENCY frames can be used only when the both endpoints send the TP. I assume that the intent to be the latter, but I'm not sure.
Interesting, I actually interpreted it to be the former. I think it is reasonable for an implementation to accept ACK_FREQUENCY without having any intention of sending them itself. I.e. I don't see any reason it has to be mutually negotiated.
I agree that it's totally fine to consider the use being allowed independently for each direction. Though, for the ease of testing, I might prefer the use being negotiated mutually. It's a bit complex to have two flags; one that emits the minackdelay TP and another that controls the recognition of that TP sent by the peer. Endpoints that are not interested in sending ACKFREQUENCY frames can just send the minackdelay TP ~with the value set to maxack_delay~.
NAME -- that's not quite right. If this were unilateral, that would mean that an endpoint that receives the TP would not need to advertise the TP. That's a bit confusing, since the endpoint that sends the TP intends to use the ACK_FREQUENCY frame, which it wouldn't then be able to do. The most straightforward interpretation is the second one that NAME proposes.
I think it can be quite natural depending on how you see it. We can define the TP as a proclamation by an endpoint to respect ACK_FREQUENCY frames. I would also point out that most (maybe all) transport parameters are unilateral declarations of endpoint properties, rather than a negotiation. That said, with either of the approaches, it is impossible for an endpoint to declare support for multiple versions. I'm not sure if that's required, but it might be necessary.

If we want to support multiple versions, then, we can either: Say that each endpoint unilaterally declares it's capabilities (or supported versions); then the peer chooses what to use and sends the chosen capability (or the version) using a frame, much like how ALPN is being selected. Say that the support for delayed-ack is negotiated by both endpoints. Each endpoints send a list of supported versions, and we define a logic for choosing one from the lists provided by both endpoints. Personally, I think I prefer the former, especially if we are to negotiate use of multiple extensions at once. But the necessity is still unclear.
Ah. I clearly misread what NAME was saying. Yeah, this does align with the rest of the TPs, and it also aligns well with the intent of this TP -- each endpoint has to declare that it will respect and act on an ACK_FREQUENCY frame when one is received. I like the unilateral declaration of capabilites. I don't think we will need to support multiple versions in the longer term, but it's worth supporting if it isn't difficult to do. And in this case, I think it naturally aligns well with the intent of the frame.
There's been no change on this in a while, so I'm planning to merge NAME PR soon unless someone speaks up.