Hi Mahesh, Thanks for your review and comments.
On Tue, 8 Jul 2025 at 00:48, Mahesh Jethanandani via Datatracker <[email protected]> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hear, hear! My DISCUSS is probably the easiest to address > > This document updates RFC9146, but does not seem to include explanatory text > about this in the abstract. To provide a bit more context, "Updates: 9146" was suggested by Med in [1]. We agreed to make the suggested change based on 'Other uses of “Updates” may be appropriate when it’s important for readers to know about them' in https://wiki.ietf.org/group/iesg/useofupdatestag So, there is not one bit of 9146 that is altered by this document, which makes the "summarize any changes made from the RFCs being updated or obsoleted" part slightly trickier than usual :-) In this draft PR [2], I have attempted to capture the essence of the 'Updates'. Could you please confirm whether this would work for you? [1] https://mailarchive.ietf.org/arch/msg/tls/f_JWgsCbxKIaDX1AcD8e47MIWUU/ [2] https://github.com/tlswg/dtls-rrc/pull/101/commits/7655b19e > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 5, paragraph 1 > > This document describes two kinds of checks: basic (Section 5.1) and > > enhanced (Section 5.2). The choice of one or the other depends on > > whether the off-path attacker scenario described in Section 8.1.2 is > > to be considered. (The decision on what strategy to choose depends > > mainly on the threat model, but may also be influenced by other > > considerations. Examples of impacting factors include: the need to > > minimise implementation complexity, privacy concerns, and the need to > > reduce the time it takes to switch path. The choice may be offered > > as a configuration option to the user of the TLS implementation.) > > From an operations perspective, the ability for the user to configure the > option should be highlighted in a separate section called "Operational > Considerations". There are two other instances of operational considerations that we decided to keep closer to the context in which they are relevant, rather than moving thme into §7. I believe this one falls into the same bucket. > The IANA review of this document has not concluded yet. > > Check whether Expert Review is an appropriate registration policy here. > > Possible DOWNREF from this Standards Track doc to [IANA.tls-parameters]. If > so, > the IESG needs to approve it. I agree with EKR that we should not touch this. The TLS WG has consensus that this should be under Expert Review. See [3] and [4]. [3] https://mailarchive.ietf.org/arch/msg/tls/FJrmvpVz45ETjq1v32G4PLf0w8c/ [4] https://mailarchive.ietf.org/arch/msg/tls/sOoIZQBrc9txNeLL3PlvtfBMLjQ/ > ------------------------------------------------------------------------------- > NIT > ------------------------------------------------------------------------------- > > All comments below are about very minor potential issues that you may choose > to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > Reference [RFC6347] to RFC6347, which was obsoleted by RFC9147 (this may be on > purpose). Yes, the reference to RFC6347 is intentianol, since RRC applies to 1.2 and 1.3 cheers! _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
