Alissa Cooper's Yes on draft-ietf-httpbis-http2-16: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-httpbis-http2-16: Yes

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 http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for all of your work on this. I'm not thrilled with the decisions
around TLS and opportunistic security, but I understand how we got here.

= Section 3.1 =
It might be worth keeping this sentence from the text that is marked for
deletion:

"Examples and text throughout the rest of this document use "h2" as a
   matter of editorial convenience only."

= Section 3.2 =
"A server that supports HTTP/2 can accept the upgrade with a 101
   (Switching Protocols) response."

Is there a reason why this behavior is not normatively described? Is
there some other response that clients should expect that has the same
semantic?

= Section 5.1 =
"WINDOW_UPDATE or RST_STREAM frames can be received in this state
      for a short period after a DATA or HEADERS frame containing an
      END_STREAM flag is sent. ...
      endpoints MAY choose to treat frames that arrive a significant
      time after sending END_STREAM as a connection error
      (Section 5.4.1) of type PROTOCOL_ERROR."

Can some ballpark guidance be given about how long "a short period" and
"a significant time" are expected to be? Or how an implementation might
calibrate these values?

s/Frame of unknown types/Frames of unknown types/

= Section 5.2.2 =
"Deployments that do not require this capability can advertise a flow
   control window of the maximum size, incrementing the available space
   when new data is received."

I found this a little vague. Does this mean deployments can advertise a
flow control window of size 2^31-1 and then locally increment available
memory as new data is received? Would be good to state here both what the
maximum size is and what is meant by "available space."

= Section 6.8 =
s/the remote can know/the remote peer can know/

= Section 8.2 =

s/that is not cacheable, unsafe or that/that is not cacheable, safe or
that/

= Section 10.7 =
"Intermediaries SHOULD retain padding for DATA frames, but MAY drop
   padding for HEADERS and PUSH_PROMISE frames.  A valid reason for an
   intermediary to change the amount of padding of frames is to improve
   the protections that padding provides."

The different recommendations for different frame types here are a bit
puzzling. Why are intermediaries expected to be able to improve
padding-based protection for HEADERS and PUSH_PROMISE frames more so than
for DATA frames?

= Section 10.8 =

Is there anything more you could say about possible mitigations for the
fingerprinting issue? Or there might not be, absent some coordination
between endpoints, which would likewise be useful to note.

Received on Tuesday, 20 January 2015 21:55:18 UTC