Original text:
QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake, which has a basic packet loss retransmission timer. <del> This may allow loss recovery to occur more quickly for QUIC data. </del>  QUIC datagrams, while unreliable, can support acknowledgements, allowing applications to be aware of whether a datagram was Application protocols using datagrams are responsible for defining the semantics of the Datagram Data field, and how it is parsed.  If the application protocol supports the coexistence of multiple <del> entities using datagrams inside a single QUIC connection, it may need </del>  a mechanism to allow demultiplexing between them.  For example, using datagrams with HTTP/3 involves prepending a flow identifier to all datagrams, see I-D.schinazi-quic-h3-datagram. and do not contribute to any per-flow or connection-wide data limit. The risk associated with not providing flow control for DATAGRAM <del> frames is that a receiver may not be able to commit the necessary resources to process the frames.  For example, it may not be able to store the frame contents in memory.  However, since DATAGRAM frames are inherently unreliable, they MAY be dropped by the receiver if the receiver cannot process them. </del>  5.3. DATAGRAM frames employ the QUIC connection's congestion controller. <del> As a result, a connection may be unable to send a DATAGRAM frame </del>  generated by the application until the congestion controller allows it I-D.ietf-quic-recovery.  The sender implementation MUST either delay sending the frame until the controller allows it or drop

Reviewer comments:
There are several instances of lowercase "may" in this document. It is ambiguous if these are normative requirements or not.
Could you elaborate on why it's ambiguous? We have a reference to RFC 8174.
I sometimes assume typos :) If you're happy the present document is correct, I will close this issue
I'm not aware of errors like this, do you have any specific ones in mind?
Gah, fat fingered accidental close. The example that triggered opening this issue is below, I had to read this several times. Perhaps that's just a sign that editorial tweaks would help, regardless of the exact words in use
I can fix this
Thanks!

Revised text:
QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake, which has a basic packet loss retransmission timer.  <ins> This can allow loss recovery to occur more quickly for QUIC data. </ins> QUIC datagrams, while unreliable, can support acknowledgements, allowing applications to be aware of whether a datagram was Application protocols using datagrams are responsible for defining the semantics of the Datagram Data field, and how it is parsed.  If the application protocol supports the coexistence of multiple  <ins> entities using datagrams inside a single QUIC connection, it can use </ins> a mechanism to allow demultiplexing between them.  For example, using datagrams with HTTP/3 involves prepending a flow identifier to all datagrams, see I-D.schinazi-quic-h3-datagram. and do not contribute to any per-flow or connection-wide data limit. The risk associated with not providing flow control for DATAGRAM  <ins> frames is that a receiver might not be able to commit the necessary resources to process the frames.  For example, it might not be able to store the frame contents in memory.  However, since DATAGRAM frames are inherently unreliable, they MAY be dropped by the receiver if the receiver cannot process them. </ins> 5.3. DATAGRAM frames employ the QUIC connection's congestion controller.  <ins> As a result, a connection might be unable to send a DATAGRAM frame </ins> generated by the application until the congestion controller allows it I-D.ietf-quic-recovery.  The sender implementation MUST either delay sending the frame until the controller allows it or drop