Original text:
2.1.1. Implementations of HTTP/3 that are willing to receive HTTP Datagrams <del> can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1. </del>  <del> The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or 1.  A value of 0 indicates that the implementation is not willing to receive HTTP Datagrams.  If the H3_DATAGRAM SETTINGS parameter is </del>  received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR. <del> QUIC DATAGRAM frames MUST NOT be sent until the H3_DATAGRAM SETTINGS parameter has been both sent and received with a value of 1. </del>  When clients use 0-RTT, they MAY store the value of the server's <del> H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send </del>  QUIC DATAGRAM frames in 0-RTT packets.  When servers decide to accept <del> 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater </del>  than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client <del> 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. </del>  It is RECOMMENDED that implementations that support receiving HTTP <del> Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter </del>  with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the <del> H3_DATAGRAM Settings Parameter.  This allows new draft revisions to </del>  make incompatible changes.  Multiple draft versions MAY be supported <del> by sending multiple values for H3_DATAGRAM.  Once SETTINGS have been sent and received, an implementation that supports multiple drafts MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both peers negotiate the same draft version. </del>  2.2. 4. Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires <del> sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports HTTP </del>  Datagrams over QUIC DATAGRAM frames.  As some servers might wish to obfuscate the fact that they offer application services that use HTTP datagrams, it's best for all implementations that support this <del> feature to always send this Settings parameter, see setting. </del>  Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those

Reviewer comments:
This looks big but it consists of some minor operations H3DATAGRAM -> SETTINGSH3_DATAGRAM SETTINGS parameter -> setting Tweak the security considerations so it is explicit and grammar ain't borke
We deviate from the usual way of referring to settings, this will likely get picked up later on so may as well fix it now.

Revised text:
2.1.1. Implementations of HTTP/3 that are willing to receive HTTP Datagrams  <ins> can indicate that to their peer by sending the SETTINGS_H3_DATAGRAM setting with a value of 1. </ins>  <ins> The value of the SETTINGS_H3_DATAGRAM setting MUST be either 0 or 1. A value of 0 indicates that the implementation is not willing to receive HTTP Datagrams.  If the SETTINGS_H3_DATAGRAM setting is </ins> received with a value that is neither 0 or 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR.  <ins> QUIC DATAGRAM frames MUST NOT be sent until the SETTINGS_H3_DATAGRAM setting has been both sent and received with a value of 1. </ins> When clients use 0-RTT, they MAY store the value of the server's  <ins> SETTINGS_H3_DATAGRAM setting.  Doing so allows the client to send </ins> QUIC DATAGRAM frames in 0-RTT packets.  When servers decide to accept  <ins> 0-RTT data, they MUST send a SETTINGS_H3_DATAGRAM setting greater </ins> than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client  <ins> stores the value of the SETTINGS_H3_DATAGRAM setting with their 0-RTT state, they MUST validate that the new value of the SETTINGS_H3_DATAGRAM setting 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 SETTINGS_H3_DATAGRAM setting parameter is 1. </ins> It is RECOMMENDED that implementations that support receiving HTTP  <ins> Datagrams using QUIC always send the SETTINGS_H3_DATAGRAM setting </ins> with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the  <ins> SETTINGS_H3_DATAGRAM setting.  This allows new draft revisions to </ins> make incompatible changes.  Multiple draft versions MAY be supported  <ins> by sending multiple values for SETTINGS_H3_DATAGRAM.  Once SETTINGS have been sent and received, an implementation that supports multiple drafts MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both peers negotiate the same draft version. </ins> 2.2. 4. Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires  <ins> sending the HTTP/3 SETTINGS_H3_DATAGRAM setting, it "sticks out".  In other words, probing clients can learn whether a server supports HTTP </ins> Datagrams over QUIC DATAGRAM frames.  As some servers might wish to obfuscate the fact that they offer application services that use HTTP datagrams, it's best for all implementations that support this  <ins> feature to always send this setting, see setting. </ins> Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those