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. 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. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
