On Mon, Jul 7, 2025 at 3:48 PM Mahesh Jethanandani via Datatracker <
[email protected]> wrote:

> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-tls-dtls-rrc-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/
>
>
>
> ----------------------------------------------------------------------
> 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.
>
>
> ----------------------------------------------------------------------
> 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".
>

I don't agree that we should make this change. The text is fine where it is.

-Ekr


>
> 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.
>
>
> -------------------------------------------------------------------------------
> 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).
>
>
>
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to