[alto] Opsdir last call review of draft-ietf-alto-cost-calendar-16

[Jürgen Schönwälder via Datatracker <[e-mail]>]

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?