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 rev. no specific revision (document currently at 02)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-05-17
Requested 2016-04-10
Draft 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
Review review-ietf-tls-falsestart-01-opsdir-lc-baker-2016-05-09
Reviewed rev. 01 (document currently at 02)
Review result Ready
Review completed: 2016-05-09

Review
review-ietf-tls-falsestart-01-opsdir-lc-baker-2016-05-09

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