[alto] Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-alto-cost-calendar-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3.1

   The capabilities of a Calendar-aware information resource entry have
   a member named "calendar-attributes" which is an array of objects of
   type CalendarAttributes.  It is necessary to use an array because of
   resources such as Filtered Cost Map and Endpoint Cost Map, for which
   the member "cost-type-names" is an array of 1 or more values.

I don't really follow this argument.  Why does the value for "cost-type-names"
affect the structure of the containing "calendar-attributes"?

   An ALTO Client should assume that the time interval size specified in
   the IRD is the smallest possible one that the ALTO Server can
   provide.  The Client can aggregate cost values on its own if it needs
   a larger granularity.

Where is the normative requirement on the server to behave in this fashion?

It's weird to use string packing for units instead of a separate
structured element in the language/structure.

Section 4.1.1

   This field is an array of 1 to N boolean values, where N is the
   number of requested metrics.  Each boolean value indicates whether or
   not the ALTO Server should provide the values for this Cost Type as a
   calendar.  The array MUST contain exactly N boolean values, otherwise
   the server returns an error.

Is it a MUST requirement for the server to check?

Section 4.2.2

   If the ALTO client provides member "calendared" in the input
   parameters with a value equal to 'true' for given requested Cost
   Types, the "meta" member of a Calendared Endpoint Cost response MUST
   include, for these Cost Types, the same additional member "calendar-
   response-attributes", as specified for the Filtered Cost Map Service.

On first reading I thought this was a requirement for data/value
consistency between endpoint icost and filtered cost map service
responses, but rereading it looks like it's just data structure reuse.
So maybe something like "the contents of which obey the same rules as
for the Filtered Cost Map Service (Section 4.1.2)".

Section 6

Thanks for these well-thought-out security considerations; it's a
pleasure to see.

With respect to the last paragraph's mention of how the provided future
guidance can be wrong, is this going to be a scenario where it would be
helpful for the client to be able to just ping the server to ask "you
gave me this data yesterday and I just want to double-check that it's
still fresh/correct"?  I don't see an obvious way in which this would be
helpful (unless the size of the JSON responses are getting to be
prohibitively large or something, I suppose), but I'm writing this on a
plane so the risk of me missing something is higher even than its usual
rate.