Change:
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!

Discussion:
6. <ins> When a record with a CID is received that has a source address different than the one currently associated with the DTLS connection, the receiver MUST NOT replace the address it uses for sending records to its peer with the source address specified in the received datagram unless the following conditions are met: The received datagram has been cryptographically verified using the DTLS record layer processing procedures. The received datagram is "newer" (in terms of both epoch and sequence number) than the newest datagram received.  Reordered datagrams that are sent prior to a change in a peer address might otherwise cause a valid address change to be reverted.  This also limits the ability of an attacker to use replayed datagrams to force a spurious address change, which could result in denial of service.  An attacker might be able to succeed in changing a peer address if they are able to rewrite source addresses and if replayed packets are able to arrive before any original. There is a strategy for ensuring that the new peer address is able to receive and process DTLS records.  No such test is defined in this specification. The above is necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks. Note that there is no requirement to use of the anti-replay window mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions, the "anti-replay window" or "newer algorithm" will prevent address 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 triggered, for example one that is based on successful exchange of 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. 7. </ins> dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a zero-length CID we use the term 'connection_id=empty'.

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