Skip to main content

HTTP Random Access and Live Content
RFC 8673

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.

Alvaro Retana
No Objection
Adam Roach Former IESG member
Yes
Yes (2018-10-08 for -03)
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)

                            
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2018-10-11 for -03)
Please address the Gen-ART review nits.
Ben Campbell Former IESG member
No Objection
No Objection (2018-10-10 for -03)
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)
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)

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2018-10-09 for -03)
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)

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -03)

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-10-10 for -03)
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)