Skip to main content

Last Call Review of draft-ietf-httpbis-early-hints-03
review-ietf-httpbis-early-hints-03-secdir-lc-shore-2017-07-04-00

Request Review of draft-ietf-httpbis-early-hints
Requested revision No specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-07-05
Requested 2017-06-21
Authors Kazuho Oku
I-D last updated 2017-07-04
Completed reviews Opsdir Last Call review of -03 by Bert Wijnen (diff)
Genart Last Call review of -03 by Wassim Haddad (diff)
Secdir Last Call review of -03 by Melinda Shore (diff)
Genart Telechat review of -04 by Wassim Haddad (diff)
Assignment Reviewer Melinda Shore
State Completed
Request Last Call review on draft-ietf-httpbis-early-hints by Security Area Directorate Assigned
Reviewed revision 03 (document currently at 05)
Result Has issues
Completed 2017-07-04
review-ietf-httpbis-early-hints-03-secdir-lc-shore-2017-07-04-00
I have 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 editors and WG chairs should treat 
these comments just like any other last call comments.

Summary:   Has minor issues.

This draft defines a status code for sending an informational 
response that contains header fields that are likely to be included in the 
final response.  A server can send the informational response containing 
some of the header fields to help the client start making preparations 
for processing the final response, and then run time-consuming operations 
to generate the final response.  The informational response can also be used by an
origin server to trigger HTTP/2 server push at a caching intermediary.

Passed nit checker without complaints other than publication date.  Sections
5 and 6 should be appendices.

One minor issue: in the security considerations section, "Therefore, 
a server might refrain from sending Early Hints over HTTP/1.1 unless when 
the client is known to handle informational responses correctly" is a bit squishy
(and contains a superfluous "when").  I'm not sure this merits a text change and
I'm rather certain that it doesn't merit normative 2119 language but it did stand
out as an overly soft recommendation.