Stephen Farrell's Discuss on draft-ietf-httpbis-http2-16: (with DISCUSS and COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-httpbis-http2-16: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Just a quick one, I'm not sure if it's me reading it wrong
or a bug... happy to clear and let you fix once we've
figured it out anyway.

8.2.2 says that clients MUST validate that a proxy is
configured for the correspondsing request. Since you say
MUST, don't you need to say what exacftly is meant there?
If that is somewhere here, I'm not seeing it. I realise that
some of that may be controversial, but if so, I think saying
that would be better than leaving it dangling (Note that
I've also a comment below about 10.1 not saying enough, if
the fix for this were to be a new paragraph or two about
when pushed stuff is ok, then you might handle my comment on
10.1 here, and that might be better, not sure.)


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


(Putting this one first as I'd really like an answer
but will not be blocking on it no matter how much I
dislike the answer:-)

- 6.1, and elsewhere, I just want to check that the 256
octet limit on padding isn't too restrictive a design. Is it
still possible to say arrange that every response from a
server has the same size? (Say from a server that is only
used for serving images and where there could be a 2KB
variation in file size or something.) I think that can work
via HEADERS and CONTINUATIONs but wanted to check the limits
of flexibility here. I'm similarly interested in the limits
within which a client can add padding to a request, but I
think the same trick works if it works at all.

- 3.1: a question on the text to be removed about
draft-specific identifiers - did the WG consider how to
handle drafts produced from now until the RFC issues?  I've
not yet looked to see if there are normative dependencies
that might lengthen that process, but if there might be it
could be useful to discuss in the WG if it turns out there
are a bunch of discusses that might take a while and a few
versions to sort out. If the IESG eval is clean enough and
there are no delaying normative refs then that's probably
not needed.

- 3.2, the last para before 3.2.1 is hard to read, maybe it
was added late but it seems to use concepts not yet
explained at that point (e.g. half-closed) Maybe a forward
ref to Figure 2 would be enough to fix.

- 5.3.4, "can be moved" in 1st sentence - I don't get why
it's ok to not say MUST or SHOULD there, iff the change is
as a result of a peer's action. Shouldn't a 404 for a
dependecy have a predictable impact on the overall page
load?

- 6.10, odd that there's no padding here

- 8.1, a bit of abnf here might have helped, ah well

- 8.1.2.3, I assume the underscors in "_:authority_" are a
typo, if not they are possibly confusing

- end of p57, does the last para mean that a header field
value can be split betwee a HEADERS frame and the subsequent
CONTINUATION frame (with possible padding in between when
looked at on-the-wire)? If so, then I think you might want
to be clearer about that since I could see it leading to
interop issues.  

- p64, DNS-ID is what (dNSName?)? And "Common Name" might be
better as commonName, but both probably need a reference.
(I don't care about nitty capitalisations, but wouldn't some
coders need to reference?)

- 9.1, which TLS library allows a client to know that it'll
shortly be time to re-key? Doing so is doable, as e.g. NTP
has a mechanism like that for pre-announcing leap seconds
I'm told. Buti I'm not sure anyone actually does it at all
today.

- 9.2.1 - the renegotiation text is confusing. First para on
that starts with "MUST be disable" next one says "MAY use"
for client cert confid. I think adding something like "Other
than as noted below" before the start of  the 1st renego
para (the 3rd para of 9.2.1) might fix this, but could be
some more editing would be better.

- 9.2.2 - Isn't it sad that there are so many undesirable
TLS ciphersuites. Sorry about that;-)

- 10.1 - I think this could be a lot clearer about which
pushed things are to be thrown away and I think being
clearer about that might avoid some future problems. 

- 10.5.1 has a few typos, no harm being nice to the RFC
editor and fixing those if you're pushing out a -17

- 10.7 - what general purpose padding does TLS1.2 provide?
I'm sad that this section is so negative - does that
indicate that people haven't really tried this out so much?
While it is clear there can be failed attempts at using
padding to thwart traffic analysis I think having this
mechanism defined so we can in future learn how to better
mitigate traffic analysis is a good thing and we ought not
be so down on that.

- For the record, I'm also sad that this isn't all and only
over TLS with the option of opportunistic security for http:
schemed URIs but I accept that the wg debated that and
decided for this.

Received on Thursday, 22 January 2015 12:55:32 UTC