Change:
2. <del> Flow identifiers represent bidirectional flows of datagrams within a single QUIC connection.  These are conceptually similar to streams in the sense that they allow multiplexing of application data.  Flows lack any of the ordering or reliability guarantees of streams. </del> <ins> Flows are bidirectional exchanges of datagrams within a single QUIC connection.  These are conceptually similar to streams in the sense that they allow multiplexing of application data.  Flows are identified within a connection by a numeric value, referred to as the flow ID.  A flow ID is a 62-bit integer (0 to 2^62-1). Flows lack any of the ordering or reliability guarantees of streams. </ins> Beyond this, a sender SHOULD ensure that DATAGRAM frames within a single flow are transmitted in order relative to one another.  If multiple DATAGRAM frames can be packed into a single QUIC packet, the <del> sender SHOULD group them by flow identifier to promote fate-sharing within a specific flow and improve the ability to process batches of datagram messages efficiently on the receiver. </del> <ins> sender SHOULD group them by flow to promote fate-sharing within a specific flow and improve the ability to process batches of datagram messages efficiently on the receiver. </ins> 3. Implementations of HTTP/3 that support the DATAGRAM extension MUST <del> provide a flow identifier allocation service.  That service will allow applications co-located with HTTP/3 to request a unique flow identifier that they can subsequently use for their own purposes. The HTTP/3 implementation will then parse the flow identifier of incoming DATAGRAM frames and use it to deliver the frame to the appropriate application. Even-numbered flow identifiers are client-initiated, while odd- numbered flow identifiers are server-initiated.  This means that an HTTP/3 client implementation of the flow identifier allocation service MUST only provide even-numbered identifiers, while a server implementation MUST only provide odd-numbered identifiers.  Note that, once allocated, any flow identifier can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization. The flow allocation service SHOULD also provide a mechanism for applications to indicate they have completed their usage of a flow identifier and will no longer be using that flow identifier, this process is called "retiring" a flow identifier.  Applications MUST NOT retire a flow identifier until after they have received confirmation that the peer has also stopped using that flow identifier.  The flow identifier allocation service MAY reuse previously retired flow identifiers once they have ascertained that there are no packets with DATAGRAM frames using that flow identifier still in flight.  Reusing flow identifiers can improve performance by transmitting the flow identifier using a shorter variable-length integer encoding. </del> <ins> provide a flow ID allocation service.  That service will allow applications co-located with HTTP/3 to request a unique flow ID that they can subsequently use for their own purposes.  The HTTP/3 implementation will then parse the flow ID of incoming DATAGRAM frames and use it to deliver the frame to the appropriate application context. Even-numbered flow IDs are client-initiated, while odd-numbered flow IDs are server-initiated.  This means that an HTTP/3 client implementation of the flow ID allocation service MUST only provide even-numbered IDs, while a server implementation MUST only provide odd-numbered IDs.  Note that, once allocated, any flow ID can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization. The flow ID allocation service SHOULD also provide a mechanism for applications to indicate they have completed their usage of a flow ID and will no longer be using that flow ID, this process is called "retiring" a flow ID.  Applications MUST NOT retire a flow ID until after they have received confirmation that the peer has also stopped using that flow ID.  The flow ID allocation service MAY reuse previously retired flow ID once they have ascertained that there are no packets with DATAGRAM frames using that flow ID still in flight. Reusing flow IDs can improve performance by transmitting the flow ID using a shorter variable-length integer encoding. </ins> 4.

Discussion:
This somewhat of an experiment. While trying to address I got distracted by the document's use of the "flow identifier" term. The document likes to compare "flow identifiers" with QUIC streams, which is fine. But QUIC makes the distinction between streams and stream IDs; the ID is a property of the stream but it isn't the only one, and sometimes it helps to talk about the stream in other contexts. This change tries to channel a similar editorial style. It replaces: "flow identifiers" with "flows" when talking about a logical entitiy "flow identifiers" with "flow IDs" when talking about the wire format, encoding, examples etc. This could be a change too far but I figured it would be a good discussion starter.
The draft doesn't do this. It relies on the QUIC varint encoding for non-negativity in DATAGRAM frames but could contain a negative value. Let's be clear in the spec.
Definitely agree, could you write a PR please?
I will.
fixed in URL
Thanks!