> # No need to obsolete already obsoleted RFCs (RFCs 5077, 5246, 6961, 8422). Likewise, I didn’t find new updates of 5705 and 6066 beyond what was already updated by RFC8446. > > CURRENT: > This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes > RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies > new requirements for TLS 1.2 implementations.
As noted in my response to Ketan, I think it's best if this text lists all the obsoleted/updated protocols. > # (nit) Introduction: “application protocols ..with their application protocol” > > OLD: > Application protocols using TLS > MUST specify how TLS works with their application protocol, including > how and when handshaking occurs, and how to do identity verification. > > Maybe > > NEW: > Applications using TLS > MUST specify how TLS works with their application protocol, including > how and when handshaking occurs, and how to do identity verification. This change is incorrect. It is the protocols (e.g., HTTP) that must specify this, not the applications (e.g., Firefox). > # (nit) 4.2.8: omission and inclusion > > OLD: > For this reason, the omission of a share for group A and inclusion of > one for group B does not mean that the client prefers B to A. > > NEW: > For this reason, the omission of a share for group A and inclusion of > one for group B do not mean that the client prefers B to A. I'm not sure this is actually correct. I see the argument that this is plural, but I think there's also an argument that it's a single act. Let's let the RPC copy edit phase resolve this. > # (nit) 4.2.8.1 > > OLD: the contents of the public value is > NEW: the contents of the public value are Fixed in This was fixed separately. > # (nit) Section 11: please double check this sentence: > > CURRENT: > The changes > between [RFC8446] and [RFC8447] this document are described in > Section 11.1. IANA has updated these to reference this document. This looks correct to me, but I'll be separately going over the IANA considerations. -Ekr On Mon, May 12, 2025 at 6:52 AM Mohamed Boucadair via Datatracker < nore...@ietf.org> wrote: > Mohamed Boucadair has entered the following ballot position for > draft-ietf-tls-rfc8446bis-12: No Objection > > 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-rfc8446bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi Eric, > > Thanks for the effort put into the maintenance of this key specification. > > I reviewed only the diff vs. RFC8446. Please find below some few comments, > most > are nits: > > # No need to obsolete already obsoleted RFCs (RFCs 5077, 5246, 6961, 8422). > Likewise, I didn’t find new updates of 5705 and 6066 beyond what was > already > updated by RFC8446. > > CURRENT: > This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes > RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies > new requirements for TLS 1.2 implementations. > > # (nit) Introduction: “application protocols ..with their application > protocol” > > OLD: > Application protocols using TLS > MUST specify how TLS works with their application protocol, including > how and when handshaking occurs, and how to do identity verification. > > Maybe > > NEW: > Applications using TLS > MUST specify how TLS works with their application protocol, including > how and when handshaking occurs, and how to do identity verification. > > # (nit) 4.2.8: omission and inclusion > > OLD: > For this reason, the omission of a share for group A and inclusion of > one for group B does not mean that the client prefers B to A. > > NEW: > For this reason, the omission of a share for group A and inclusion of > one for group B do not mean that the client prefers B to A. > > # (nit) 4.2.8.1 > > OLD: the contents of the public value is > NEW: the contents of the public value are > > # (nit) Section 11: please double check this sentence: > > CURRENT: > The changes > between [RFC8446] and [RFC8447] this document are described in > Section 11.1. IANA has updated these to reference this document. > > Cheers, > Med > > > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
