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?