Hi Joe, Thanks very much for your review. TL;DR. Your suggestions are collected in: https://github.com/tlswg/dtls-rrc/pull/80 On Fri, May 30, 2025 at 08:30:58AM +0100, Joe Clarke via Datatracker wrote:
Document: draft-ietf-tls-dtls-rrc Title: Return Routability Check for DTLS 1.2 and DTLS 1.3 Reviewer: Joe Clarke Review result: Has Nits 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.
yes
Section 7: In the first sentence, the word "update" threw me initially. Wouldn't "change" be a better choice here?
yes
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.
What we mean by "user" is the user of the TLS implementation.
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.
I am not an OPS person, and I am not particularly familiar with what SNMP/NETMOD provides regarding the export of statistics about TLS/DTLS sessions. I am not familiar with QLOG either, but I guess it might have modelled events that are very similar to what RRC would need and could be used as a starting point. As you say, though, this would be separate work, so I wouldn't know how to act on it at this point other than discussing your intriguing observation with other implementers :-) cheers, t -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
