Last Call Review of draft-ietf-quic-bit-grease-03
review-ietf-quic-bit-grease-03-secdir-lc-housley-2022-05-19-00
Request | Review of | draft-ietf-quic-bit-grease |
---|---|---|
Requested revision | No specific revision (document currently at 04) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2022-06-01 | |
Requested | 2022-05-18 | |
Authors | Martin Thomson | |
I-D last updated | 2022-05-19 | |
Completed reviews |
Opsdir Last Call review of -03
by Scott O. Bradner
(diff)
Secdir Last Call review of -03 by Russ Housley (diff) Artart Last Call review of -03 by Julian Reschke (diff) Secdir Telechat review of -04 by Russ Housley Opsdir Telechat review of -04 by Scott O. Bradner Intdir Telechat review of -04 by Wassim Haddad |
|
Assignment | Reviewer | Russ Housley |
State | Completed | |
Request | Last Call review on draft-ietf-quic-bit-grease by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/tUvQaSVJJPteFbidY7Uc8TD-3yo | |
Reviewed revision | 03 (document currently at 04) | |
Result | Has issues | |
Completed | 2022-05-19 |
review-ietf-quic-bit-grease-03-secdir-lc-housley-2022-05-19-00
I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-quic-bit-grease-03 Reviewer: Russ Housley Review Date: 2022-05-19 IETF LC End Date: 2022-06-01 IESG Telechat date: Unknown Summary: Has Issues Major Concerns: None Minor Concerns: Section 3 says: Advertising the grease_quic_bit transport parameter indicates that packets sent to this endpoint MAY set a value of 0 for the QUIC Bit. This does not align with the definition of MAY in RFC 2119. I suggest: Advertising the grease_quic_bit transport parameter indicates that packets sent to this endpoint will be accepted with a value of 0 for the QUIC Bit. Section 3 also says: A client MAY forget the value. This might align with the definition of MAY in RFC 2119. The client can either remember or forget, as the implementer chooses? Section 3.1 says: A server cannot remember that a client negotiated the extension in a previous connection and clear the QUIC Bit based on that information. and An endpoint cannot clear the QUIC Bit without knowing whether the peer supports the extension. s/cannot/MUST NOT/ (both places)