HTTP Random Access and Live Content
draft-ietf-httpbis-rand-access-live-04
Yes
(Alexey Melnikov)
No Objection
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)
Note: This ballot was opened for revision 03 and is now closed.
Adam Roach Former IESG member
Yes
Yes
(2018-10-08 for -03)
Sent
Thanks to everyone who worked on this document. I have two rather small comments. --------------------------------------------------------------------------- I am quite uncomfortable with the nebulous definition of the term "Very Large Value" in this document. Given that "Very Large Values" are intended to serve as a negotiation mechanism, I would strongly suggest that a more formal definition of that term be added to this document (e.g., a client should send "a value of at least 2^^39 or twice the value of the end of the randomly accessible byte range, whichever is larger") --------------------------------------------------------------------------- §1.1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. This document does not use these words in capitalized form. Especially in light of RFC 8174, this is likely to cause confusion. If the intention is to assign RFC 2119 definitions to the non-uppercased "must", "should", and "may" usage in this document, please capitalize those terms and update the boilerplate to that in RFC 8174. Otherwise, please remove this section.
Alexey Melnikov Former IESG member
Yes
Yes
(for -03)
Unknown
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2018-10-11 for -03)
Sent for earlier
Please address the Gen-ART review nits.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -03)
Not sent
Ben Campbell Former IESG member
No Objection
No Objection
(2018-10-10 for -03)
Sent
I echo Adam's comments, but I have some of my own this time: What is the nature of the experiment? It would be nice to have some sort of statement of why this is experimental, even if that just means we need to get implementation experience. The security considerations don't seem security specific. That is, they talk about what can go wrong, but do not describe the consequences from a security perspective. I suggest either describing those consequences, or perhaps moving the content to an "implementation" or "interop" considerations section.
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-10-10 for -03)
Sent
Thanks for the well-written document! In line with Adam and Ekr's comments, it is perhaps plausible to RECOMMEND a concrete Very Large Value (of 2**53-1 or such) while discussing the cases in which other values would be needed. I agree with Ekr that discussing what happens if you guess wrong and use a too-small value is important, but it also seems that understanding how likely that is to happen can be considered part of the Experiment.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -03)
Not sent
Eric Rescorla Former IESG member
No Objection
No Objection
(2018-10-09 for -03)
Sent
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3189 I can't tell whether this document is intended to have normative content or not. I note that you cite RFC 2119 not RFC 8174, and have some lower-case should-type language.... COMMENTS S 5. > seek request or content-range response. Also, some implementations > (e.g. JavaScript-based clients and servers) are not able to > represent all values beyond 2^^53. So similarly, if there's no > expectation that a representation will ever exceed 2^^53 bytes, > values smaller than this limit should be used for the last-byte-pos > in byte-range requests. What happens if you are wrong about this?
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -03)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -03)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2018-10-10 for -03)
Sent
Inline with Ekr question it seems to me that the text in the security consideration section rather discusses what this experiement is about.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -03)
Not sent