IETF Last Call Review of draft-ietf-tls-dtls-rrc-13
review-ietf-tls-dtls-rrc-13-opsdir-lc-clarke-2025-05-30-00

I have been asked to review this draft on behalf of OPS DIR.  This draft
specifies a new DTLS sub-protocol for return routability checks when a DTLS
client or server notices a change in address or port.  Overall, it is a
well-written draft, and I appreciate the detailed examples with flow diagrams. 
I also appreciate the consideration paid to selecting timer values to minimize
user experience issues.  I found a few nits in the document, and I have one
overarching question.

Section 4:

s/Naturally, implementation MUST/Naturally, implementations MUST/

I think the plural reads better.

Section 7:

In the first sentence, the word "update" threw me initially.  Wouldn't "change"
be a better choice here?

When you say, the choice may be offered as a configuration option to the user,
who is the user in this case?  Is this the client, initiator, responder?  This
felt vague to me.

My overarching question on the OPS front is, while it might be out of scope for
this document, would it be valuable to mention any operational logging or
statistics that may be required around RRC?  that is, logging RRC failures,
counting the number of times an RRC is needed, recording the time it takes to
validate RRCs?  The details might spawn other work, but noting any interesting
operational events could be helpful for implementors.