Skip to main content

Last Call Review of draft-ietf-tls-falsestart-01
review-ietf-tls-falsestart-01-opsdir-lc-baker-2016-05-09-00

Request Review of draft-ietf-tls-falsestart
Requested revision No specific revision (document currently at 02)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-05-17
Requested 2016-04-10
Authors Adam Langley , Nagendra Modadugu , Bodo Moeller
I-D last updated 2016-05-09
Completed reviews Secdir Last Call review of -01 by Charlie Kaufman (diff)
Opsdir Last Call review of -01 by Fred Baker (diff)
Assignment Reviewer Fred Baker
State Completed
Request Last Call review on draft-ietf-tls-falsestart by Ops Directorate Assigned
Reviewed revision 01 (document currently at 02)
Result Ready
Completed 2016-05-09
review-ietf-tls-falsestart-01-opsdir-lc-baker-2016-05-09-00
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.

I claim no expertise in the internals of TLS, and am not reviewing this from
the perspective of correctness in action. I frankly hope that the working group
did that for itself. I am looking at this for operational impact - would an
operator/network administrator of a client host using this procedure, or the
operator of a network carrying its traffic, observe or have to deal with a
difference in behavior?

My view: this is good to go. Apart from possibly needing to turn it on, I see
no interaction an operator would need to be involved with or notice.

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail