Original text:
If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a <del> ConnectionErrorHandler of type SETTINGS_TIMEOUT. </del>  6.6.

Reviewer comments:
This isn't TCP RTT based. For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.

Revised text:
If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a  <ins> ConnectionErrorHandler of type SETTINGS_TIMEOUT.  In setting a timeout, some allowance need to be made for processing delays at the peer; a timeout that is solely based on the round trip time between endpoints might result in spurious errors. </ins> 6.6.