[TLS] Re: draft-ietf-tls-dtls-rrc-13 ietf last call Opsdir review

[Thomas Fossati <[e-mail]>]

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