jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-masque-h3-datagram

Commentary: it clear what the spec is allowing , we should make a note in Section 4.4 that the ordering / buffering requirements of DATGRAM frames and register capsules ( from sec 3 ) do not apply to intermediaries when forwarding . That 's tangential to Luca 's OP so we can spin it off separately . Originally posted by in
Endpoints MUST NOT send DATAGRAM frames using a Context ID until they
have either sent or received a REGISTER_DATAGRAM_CONTEXT Capsule with
the same Context ID.  However, due to reordering, an endpoint that
receives a DATAGRAM frame with an unknown Context ID MUST NOT treat
it as an error, it SHALL instead drop the DATAGRAM frame silently, or
buffer it temporarily while awaiting the corresponding
REGISTER_DATAGRAM_CONTEXT Capsule.
Endpoints MUST NOT send DATAGRAM frames using a Context ID until they
have either sent or received a REGISTER_DATAGRAM_CONTEXT Capsule with
the same Context ID.  However, reordering can cause DATAGRAM frames
to be received with an unknown Context ID.  Receipt of such frames
MUST NOT be treated as an error.  Endpoints SHALL drop the DATAGRAM
frame silently, or buffer it temporarily while awaiting the
corresponding REGISTER_DATAGRAM_CONTEXT Capsule.  Intermediaries
SHALL drop the DATAGRAM frame silently, MAY buffer it, or forward it
on immediately.
Draft: draft-ietf-masque-h3-datagram

Commentary: This prevents some flavors of DoS attacks and provides clearer assumptions to endpoints .
Endpoints MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a
stream before they have sent at least one HEADERS frame on that
stream.  This removes the need to buffer REGISTER_DATAGRAM_CONTEXT
capsules when the endpoint needs information from headers to
determine how to react to the capsule.  If an endpoint receives a
REGISTER_DATAGRAM_CONTEXT capsule on a stream that hasn't yet
received a HEADERS frame, the endpoint MUST abruptly terminate the
corresponding stream with a stream error of type
H3_GENERAL_PROTOCOL_ERROR.
Servers MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a stream
before they have received at least one REGISTER_DATAGRAM_CONTEXT
capsule from the client on that stream.  This ensures that clients
control whether datagrams are allowed for a given request.  If a
client receives a REGISTER_DATAGRAM_CONTEXT capsule on a stream where
the client has not yet sent a REGISTER_DATAGRAM_CONTEXT capsule, the
client MUST abruptly terminate the corresponding stream with a stream
error of type H3_GENERAL_PROTOCOL_ERROR.
Draft: draft-ietf-masque-h3-datagram

Commentary: As discussed at IETF 110 , some MASQUE servers may prefer to avoid sticking out ( i.e. they may wish to be indistinguishable from a non - MASQUE - capable HTTP/3 server ) . The H3_DATAGRAM SETTINGS parameter may stick out . Therefore , we should add a note about this to the Security Considerations section . A simple solution could be to encourage widespread HTTP/3 servers to always send this .
This document does not have additional security considerations beyond
those defined in QUIC and DGRAM.
Since this feature requires sending an HTTP/3 Settings parameter, it
"sticks out".  In other words, probing clients can learn whether a
server supports this feature.  Implementations that support this
feature SHOULD always send this Settings parameter to avoid leaking
the fact that there are applications using HTTP/3 datagrams enabled
on this endpoint.
Draft: draft-schinazi-masque-h3-datagram

Commentary: There 's some good guidance about parsing the Flow ID out of the HTTP/3 Datagram with respect to datagram payload length . But I 'm not sure if the recommend error code of PROTOCOLVIOLATION is the most appropriate . This implies that the error is a Transport Error but I 'd argue that at this point ( parsing of the frame payload ) that its an HTTP/3 Application error . Since we 're not actually parsing a true HTTP/3 frame , just a view over a transport frame , H3FRAMEERROR seems too specific . So I think H3GENERALPROTOCOLERROR is the most straightforward . I wonder what others think . 
 I honestly am fine with any error for this , though I 'd prefer to reuse an existing one to reduce complexity .
Endpoints MUST treat receipt of a DATAGRAM frame whose payload is too
short to parse the flow identifier as a connection error of type
PROTOCOL_VIOLATION.
Endpoints MUST treat receipt of a DATAGRAM frame whose payload is too
short to parse the flow identifier as an HTTP/3 connection error of
type H3_GENERAL_PROTOCOL_ERROR.
Draft: draft-schinazi-masque-h3-datagram

Commentary: In layspeak I think this is saying " if a server sent the value 1 before , it MUST send 1 now . If a server sent 0 before , it MUST send 0 or 1 now " . Could we maybe editorialize this to make it less likely for someone to do and end up sending ? 
 There is text in the doc stating that only 0 and 1 are valid . But I do agree that the current text is somewhat clunky . Can you send a PR ? 
 Sure , I 'll make a PR .
When clients use 0-RTT, they MAY store the value of the server's
H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to use
HTTP/3 datagrams in 0-RTT packets.  When servers decide to accept
0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater
or equal to the value they sent to the client in the connection where
they sent them the NewSessionTicket message.  If a client stores the
value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state,
they MUST validate that the new value of the H3_DATAGRAM SETTINGS
parameter sent by the server in the handshake is greater or equal to
the stored value; if not, the client MUST terminate the connection
with error H3_SETTINGS_ERROR.
When clients use 0-RTT, they MAY store the value of the server's
H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to use
HTTP/3 datagrams in 0-RTT packets.  When servers decide to accept
0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater
than or equal to the value they sent to the client in the connection
where they sent them the NewSessionTicket message.  If a client
stores the value of the H3_DATAGRAM SETTINGS parameter with their
0-RTT state, they MUST validate that the new value of the H3_DATAGRAM
SETTINGS parameter sent by the server in the handshake is greater
than or equal to the stored value; if not, the client MUST terminate
the connection with error H3_SETTINGS_ERROR.  In all cases, the
maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1.
Draft: draft-schinazi-quic-h3-datagram

Commentary: The comparison to UDP sockets is not as good as a comparison to streams . UDP sockets are sometimes spun up in the fashion described , but they are also often a fixed thing , such as the socket that a DNS server listens on . That evokes the wrong model in which the caller chooses and there is some possibility of persistence .
Flow identifiers represent bidirectional flows of datagrams within a
single QUIC connection.  These are conceptually similar to UDP ports
and allow basic demultiplexing of application data.  The primary role
of flow identifiers is to provide a standard mechanism for
demultiplexing application data flows, which may be destined for
different processing threads in the application, akin to UDP sockets.
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.  Of
course flows lack any of the ordering or reliability guarantees of
streams.
Draft: draft-h3-datagram

Commentary: Minor editorial nits :) 
 Thanks !
The QUIC DATAGRAM extension I-D.pauly-quic-datagram provides
application protocols running over QUIC I-D.ietf-quic-transport with
a way to send unreliable data while leveraging the security and
congestion-control properties of QUIC.  However, QUIC DATAGRAM frames
do not provide a means to demultiplex application contexts.  This
document defines how to use QUIC DATAGRAM frames when the application
protocol running over QUIC is HTTP/3 I-D.ietf-quic-http by adding an
identifier at the start of the frame payload.
The QUIC DATAGRAM extension I-D.pauly-quic-datagram provides
application protocols running over QUIC I-D.ietf-quic-transport with
a mechanism to send unreliable data while leveraging the security and
congestion-control properties of QUIC.  However, QUIC DATAGRAM frames
do not provide a means to demultiplex application contexts.  This
document defines how to use QUIC DATAGRAM frames when the application
protocol running over QUIC is HTTP/3 I-D.ietf-quic-http, by adding an
identifier at the start of the frame payload.
Flow identifiers represent bidirectional flows of datagrams within a
single QUIC connection.  These are effectively equivalent to UDP
ports, that allow basic demultiplexing of application data.  The
primary role of slow identifiers is to provide a standard mechanism
for demultiplexing application data flows, which may be destined for
different processing threads in the application, akin to UDP sockets.
Flow identifiers represent bidirectional flows of datagrams within a
single QUIC connection.  These are effectively equivalent to UDP
ports and allow basic demultiplexing of application data.  The
primary role of flow identifiers is to provide a standard mechanism
for demultiplexing application data flows, which may be destined for
different processing threads in the application, akin to UDP sockets.
This document currently does not have additional security
considerations on top of the ones defined in I-D.ietf-quic-transport
and I-D.pauly-quic-datagram.
This document currently does not have additional security
considerations beyond those defined in I-D.ietf-quic-transport and I-
D.pauly-quic-datagram.