Change:
contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. <del> 7. </del> <ins> 8. </ins> The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection.  Every identifier introduces the risk of linkability, as explained in RFC6973. <del> In addition, endpoints can use the CID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to </del> <ins> An on-path adversary observing the DTLS protocol exchanges between the DTLS client and the DTLS server is able to link the observed payloads to all subsequent payloads carrying the same ID pair (for bi-directional communication).  Without multi-homing or mobility, the use of the CID exposes the same information as the 5-tuple. With multi-homing, a passive attacker is able to correlate the communication interaction over the two paths and the sequence number makes it possible to correlate packets across CID changes.  The lack of a CID update mechanism in DTLS 1.2 makes this extension unsuitable for mobility scenarios where correlation must be considered. Deployments that use DTLS in multi-homing environments and are concerned about this aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and sequence number encryption is available. The specification introduces record padding for the CID-enhanced record layer, which is a privacy feature not available with the original DTLS 1.2 specification.  Padding allows to inflate the size of the ciphertext making traffic analysis more difficult.  More details about record padding can be found in Section 5.4 and Appendix E.3 of RFC 8446. Finally, endpoints can use the CID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to </ins> communicate per-connection information to on-path observers.  There <del> is no straightforward way to address this with CIDs that contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids. An on-path adversary, who is able to observe the DTLS protocol exchanges between the DTLS client and the DTLS server, is able to link the observed payloads to all subsequent payloads carrying the same connection id pair (for bi-directional communication).  Without multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple. An on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  The lack of a CID update mechanism makes this extension unsuitable for mobility scenarios where correlation must be considered. Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a client/server pair do a rehandshake to change CID, that does not provide much privacy benefit. The CID-enhanced record layer introduces record padding; a privacy feature not available with the original DTLS 1.2 RFC.  Padding allows to inflate the size of the ciphertext making traffic analysis more difficult.  More details about the padding can be found in Section 5.4 and Appendix E.3 of RFC 8446. </del> <ins> is no straightforward way to address this concern with CIDs that contain arbitrary values.  Implementations concerned about this aspects SHOULD refuse to use CIDs. </ins> <del> 8. </del> <ins> 9. An on-path adversary can create reflection attacks against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. Additionally, an attacker able to observe the data traffic exchanged between two DTLS peers is able to replay datagrams with modified IP address/port numbers. The topic of peer address updates is discussed in peer-address- update. 10. </ins> IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for

Discussion:
The part of PR didn't made to the draft, or did I miss it? In the meantime, I would even go further: Applying and may validates the record cryptographically, and so the receive windows may be updated and the application data may be forwarded. But, if the epoch/sequencenumber is not newer than the newest successfully validate epoch/sequencenumber before, the address update event itself may be wrong! Assuming, that a address-change is located somewhere on the message's route, it seems to be not possible to distinguish, if the message was delayed after the "address change" (and so that address is deprecated) or before that (and so the address would be the new one). If that could not be decided, I would go for updating the address only for newer records. Using that approach, updating the address only for newer records (based on epoch/sequence_number) with validated , would also mitigate the first two attacks of issue , though retransmitting an record with changed address will not update the address, because these records are NOT newer.
I have updated the text of URL and was wondering whether it captures your issue. I am not sure what steps I have to take to meet your requirements.
As long as doesn't get mandatory (MUST), everything for me will be OK. So, yes, PR addresses it in the right way.
It looks like closes this issue?
Thanks!
The changes look good to me.This split makes sense to me. Thanks for making the change!