jiebi/TextFlow huggingface dataset:
Original text:
The above is necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks. <del> Note that there is no requirement to use of the anti-replay window </del>  mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions, <del> the "anti-replay window" or "newer algorithm" will prevent address </del>  updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic.  Application protocols that implement protection against these attacks depend on being aware of changes in peer addresses so that they can engage the necessary mechanisms.  When delivered such an event, an application layer-specific address validation mechanism can be <del> triggered, for example one that is based on successful exchange of </del>  minimal amount of ping-pong traffic with the peer.  Alternatively, an DTLS-specific mechanism may be used, as described in I-D.tschofenig- tls-dtls-rrc.

Reviewer comments:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Revised text:
The above is necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks.  <ins> Note that there is no requirement for use of the anti-replay window </ins> mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions,  <ins> the "anti-replay window" or "newer" algorithm, will prevent address </ins> updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic. <ins> Note that datagrams that pass the DTLS cryptographic verification procedures but do not trigger a change of peer address are still valid DTLS records and are still to be passed to the application. </ins> Application protocols that implement protection against these attacks depend on being aware of changes in peer addresses so that they can engage the necessary mechanisms.  When delivered such an event, an application layer-specific address validation mechanism can be  <ins> triggered, for example one that is based on successful exchange of a </ins> minimal amount of ping-pong traffic with the peer.  Alternatively, an DTLS-specific mechanism may be used, as described in I-D.tschofenig- tls-dtls-rrc.
Original text:
dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a <del> zero-length CID we use the term 'connection_id=empty'. </del>  Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message is encrypted, namely the Finished message.  Since the example shows <del> how to use the CID for payloads sent from the client to the server only the record layer payloads containing the Finished messages include a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </del>  8.

Reviewer comments:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Revised text:
dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a  <ins> zero-length CID is present in the "connection_id" extension we use the notation 'connection_id=empty'. </ins> Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message is encrypted, namely the Finished message.  Since the example shows  <ins> how to use the CID for payloads sent from the client to the server, only the record layer payloads containing the Finished message or application data include a CID. </ins> 8.
Original text:
details about record padding can be found in Section 5.4 and Appendix E.3 of RFC 8446. <del> Finally, endpoints can use the CID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this concern with CIDs that contain arbitrary values.  Implementations concerned about this aspects SHOULD refuse to use CIDs. </del>  9.

Reviewer comments:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Revised text:
details about record padding can be found in Section 5.4 and Appendix E.3 of RFC 8446.  <ins> Finally, endpoints can use the CID to attach arbitrary per-connection metadata to each record they receive on a given connection.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this concern with CIDs that contain arbitrary values.  Implementations concerned about this aspect SHOULD refuse to use CIDs. </ins> 9.
Original text:
asymmetry of request/response message sizes. Additionally, an attacker able to observe the data traffic exchanged <del> between two DTLS peers is able to replay datagrams with modified IP address/port numbers. </del>  The topic of peer address updates is discussed in peer-address- update.

Reviewer comments:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Revised text:
asymmetry of request/response message sizes. Additionally, an attacker able to observe the data traffic exchanged  <ins> between two DTLS peers is able to modify IP address/port numbers. When the optional DTLS replay detection is not in use, such an attacker can also replay the observed packets, and the multiple copies of each packet can have different IP address/port numbers as well. </ins> The topic of peer address updates is discussed in peer-address- update.
Original text:
"ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD1) as described in the table below.  IANA is requested to add an extra column to the TLS ExtensionType Values <del> registry to indicate whether an extension is only applicable to DTLS. </del>  Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document <del> describes an extension for DTLS 1.2 only; it is not to TLS (1.3). The DTLS 1.3 functionality is described in I-D.ietf-tls-dtls13. </del>  IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2.

Reviewer comments:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Revised text:
"ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD1) as described in the table below.  IANA is requested to add an extra column to the TLS ExtensionType Values  <ins> registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document  <ins> describes the behavior of this extension for DTLS 1.2 only; it is not applicable to TLS, and its usage for DTLS 1.3 is described in I- D.ietf-tls-dtls13. </ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2.
Original text:
confidence to the receiving peer that the sending peer is reachable at the indicated address and port.  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Revised text:
confidence to the receiving peer that the sending peer is reachable at the indicated address and port. <ins> Note however that, irrespective of CID, if RRC has been successfully negotiated by the peers, path validation can be used at any time by either endpoint.  For instance, an endpoint might use RRC to check that a peer is still in possession of its address after a period of quiescence. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Original text:
I-D.ietf-tls-dtls13.  The presentation language used in this document is described in Section 4 of RFC8446.  3. The use of RRC is negotiated via the "rrc" DTLS-only extension.  On

Reviewer comments:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Revised text:
I-D.ietf-tls-dtls13.  The presentation language used in this document is described in Section 4 of RFC8446. <ins> This document reuses the definition of "anti-amplification limit" from RFC9000 to mean three times the amount of data received from an unvalidated address.  This includes all DTLS records originating from that source address, excluding discarded ones. </ins> 3. The use of RRC is negotiated via the "rrc" DTLS-only extension.  On
Original text:
The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. <del> The receiver that observes the peer's address and or port update MUST </del>  stop sending any buffered application data (or limit the data sent to <del> a TBD threshold) and initiate the return routability check that proceeds as follows: </del>  <del> A cookie is placed in a "return_routability_check" message of type path_challenge; </del>  <del> The message is sent to the observed new address and a timeout T is started; </del>  The peer endpoint, after successfully verifying the received <del> "return_routability_check" message echoes the cookie value in a "return_routability_check" message of type path_response; </del>  When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it

Reviewer comments:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Revised text:
The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context.  <ins> 5. The receiver that observes the peer's address or port update MUST </ins> stop sending any buffered application data (or limit the data sent to  <ins> the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: </ins>  <ins> An unpredictable cookie is placed in a "return_routability_check" message of type path_challenge; </ins>  <ins> The message is sent to the observed new address and a timer T (see timer-choice) is started; </ins> The peer endpoint, after successfully verifying the received  <ins> "return_routability_check" message responds by echoing the cookie value in a "return_routability_check" message of type path_response; </ins> When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it
Original text:
However, the server wants to test the reachability of the client at his new IP address. <del> 6. </del>  Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker

Reviewer comments:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Revised text:
However, the server wants to test the reachability of the client at his new IP address.  <ins> 7. </ins> Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker
Original text:
those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <del> 7. </del>  IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" defined in this

Reviewer comments:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Revised text:
those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity.  <ins> 8. </ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" defined in this
Original text:
"rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. <del> 8. </del>  Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues <del> 9. </del>  We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this

Reviewer comments:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

Revised text:
"rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext.  <ins> 9. </ins> Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues  <ins> 10. </ins> We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this
Original text:
upper layer protocol MUST NOT write any record that exceeds the maximum record size of 2^14 bytes.  Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively <del> The DTLS record layer SHOULD allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing. If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in Section 14 of RFC4340), then the DTLS record layer MUST inform the upper layer protocol of the error. </del>  The DTLS record layer SHOULD NOT interfere with upper layer protocols performing PMTU discovery, whether via RFC1191 or RFC4821 mechanisms.

Reviewer comments:
I am OK with this change. There are no normative changes in there because the normative text segment is only moved to a different paragraph.
I was referring to this added clause: "alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing."
What is awkward here is that this is phrased as normative requirements on an API. Maybe worded as advice "an application that uses DTLS might need information from DTLS to allow it to estimate the PMTU; DTLS could report a PMTU estimate less any DTLS overheads, or it can report those overheads and allow the application to perform its own estimation"
There has historically been API language here, so I think we should keep it and just adjust it as here.
This one probably needs consensus given new normative language.

Revised text:
upper layer protocol MUST NOT write any record that exceeds the maximum record size of 2^14 bytes. <ins> The DTLS record layer SHOULD also allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing; alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing. </ins> Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively  <ins> If there is a transport protocol indication that the PMTU was exceeded (either via ICMP or via a refusal to send the datagram as in Section 14 of RFC4340), then the DTLS record layer MUST inform the upper layer protocol of the error. </ins> The DTLS record layer SHOULD NOT interfere with upper layer protocols performing PMTU discovery, whether via RFC1191 or RFC4821 mechanisms.
Original text:
DTLS implementations SHOULD follow the following rules: If the DTLS record layer informs the DTLS handshake layer that a <del> message is too big, it SHOULD immediately attempt to fragment it, using any existing information about the PMTU. </del>  If repeated retransmissions do not result in a response, and the PMTU is unknown, subsequent retransmissions SHOULD back off to a

Reviewer comments:
I am OK with this change. There are no normative changes in there because the normative text segment is only moved to a different paragraph.
I was referring to this added clause: "alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing."
What is awkward here is that this is phrased as normative requirements on an API. Maybe worded as advice "an application that uses DTLS might need information from DTLS to allow it to estimate the PMTU; DTLS could report a PMTU estimate less any DTLS overheads, or it can report those overheads and allow the application to perform its own estimation"
There has historically been API language here, so I think we should keep it and just adjust it as here.
This one probably needs consensus given new normative language.

Revised text:
DTLS implementations SHOULD follow the following rules: If the DTLS record layer informs the DTLS handshake layer that a  <ins> message is too big, the handshake layer SHOULD immediately attempt to fragment the message, using any existing information about the PMTU. </ins> If repeated retransmissions do not result in a response, and the PMTU is unknown, subsequent retransmissions SHOULD back off to a