>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. [JMC] Thanks for the changes. I’m still wondering where this would need to be. There are two “users” of a TLS implementation (client and server). Would this be more of a config on the client side where they wouldn’t want lag (for example)? >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 :-) [JMC] We’re actually working on a revision to RFC 5706 right now 😊 . The specifics would certainly be fodder for new work, but would It be helpful to have a sentence or short paragraph to implementors in this draft that recommends logging RRC failures? For example, Initiators MAY wish to log any unsuccessful RRC operations for Security Information and Event Management (SIEM) and troubleshooting purposes. Joe cheers, t
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
