Reviewer: Jürgen Schönwälder
Review result: Has Issues
I am not an ALTO expert so keep this in mind in case some of my
comments have little meaning for ALTO experts.
- If multiple clients retrieve information about costs in the future
and take independent scheduling decisions based on that information,
it might turn out that a "cheap" time turns into "expensive" time,
i.e., the result may not be an improvement of QoE but rather the
opposite. How is this dealt with? I see this issue touched on in
some places and the suggestion seems to be the advice to implement
SSE. But should ALTO servers make promises long into the future if
clients do not implement SSE?
I am concerned that announcements of "cheap" times can easily turn
into instabilities if many clients start to opt for the announced
"cheap" times and I think this deserves to be discussed explicitly
in the Operational Considerations section.
- p6: "time zone (in UTC)" ?? do you mean "time zone offset relative
to UTC"? After reading, I think this is misleading. Perhaps you
wanted to say "start time (including time zone)"
- p7: broken sentence
The extensions in this document and encode requests and responses
using JSON [RFC8259].
- p7: editorial nit
OLD
this document extends: the IRD, the ALTO
NEW
this document extends the IRD and the ALTO
- I am a bit concerned about changing the type of json fields, i.e.,
from a number to an array of numbers. The ALTO specifications may
allow this but is there a certain risk of implementations not being
smart in handling this correctly? Were alternatives considered that
do not change the type of existing json fields? Given the explicit
text why this is OK from an ALTO perspective, it might be that the
WG did iterate on this (sorry if I raise a closed issue again).
- p9: can a time-interval-size be negative? can it be zero?
- p9: what does 'at least equal to 1' mean? Do you mean 'a positive
integer number of values'?
- p14: I am confused about the time zone aspect. The time zone pops up
in section 3.2 but it is a bit unclear what is meant there (see
above). On page 14, there is a statement about a 'reference time
zone' (what is this?) and then there is text about HTTP header
fields, and I am lost how that format relates to the rest of the
document. Was the idea to say that calendar-start-time uses the HTTP
header time format? Then say this where calendar-start-time is
defined. And why do you use the HTTP format and not RFC 3339 format?
Perhaps this data format for date and time is popular in ALTO and
hence it makes sense, I guess I do not know enough about it. Anyway,
the time zone seems to be part of the calendar-start-time - if so
this was not clear while reading top-down. And if there is free
choice for the data and time format, I would find RFC 3339 probably
a good robust alternative.
- p17: Why is this SHOULD needed? Because you want to ensure that
there is always a value that can be used 'right now'? What about
values that are stale, i.e., calendar-start-time is way in the past?
[...] The value provided for the "calendar-
start-time" attribute SHOULD NOT be later than the request date.
- p17: I am confused by the description of "repeated". Is the intent
to say that the calendar value array simply repeats N times? Am I
right in assuming that if "repeated" is not present, it defaults to
1? Or does "repeated" always have to be present? (Similarly for
number-of-intervals, can it be absent and then it defaults to 1?
- In which sense is draft-ietf-alto-incr-update-sse normative given
that the current text says 'can be used' but does not mandate its
use? In which sense is RFC 8259 normative? Is it required to make
ALTO clients and servers switch to RFC 8259? The Operational
Considerations section says "RECOMMENDED" to switch. But how does an
implementation work that does both RFC7285 (w/o UTF-8) and RFC8259
(with UTF-8)? I think a clearer message that ALTO clients and
servers implementing this extension must comply to RFC 8259 is
desirable.
- Since you write "SHOULD at least IEEE 754 double-precision floating
point", does this not make the IEEE 754 reference a normative
reference? Similarly, if you import the data format from HTTP/1.1,
does this not make the HTTP/1.1 RFC a normative reference?
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
