Change:
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'.

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!