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

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hello Benjamin,

Thanks for your comments. A new version of this draft will be submitted and the updates hopefully addressing your comments. 
Please see inline for the responses.  
All the best for 2019,

Sabine


-----Original Message-----
From: Benjamin Kaduk <[e-mail]> 
Sent: Thursday, December 06, 2018 10:22 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; Gurbani, Vijay (Nokia - US/Naperville) <[e-mail]>; [e-mail]; Gurbani, Vijay (Nokia - US/Naperville) <[e-mail]>; [e-mail]
Subject: Benjamin Kaduk's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

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"?
[[SR]] The wording is indeed unclear. It relates to a previous design where Attributes were explicitly attached to cost types. 
 Would the following update in 3.1 be OK?
- First paragraph of 3.1: 
" When for an applicable resource, an ALTO Server provides a Cost Calendar for a given Cost Type, it MUST indicate this in the IRD capabilities of this resource, by an object of type ’CalendarAttributes’, that associates one or more Cost Types with Calendar Attributes and is specified below. "
- 2nd paragraph (you quoted) of 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. Each CalendarAttributes object applies to a set of one or more Cost Types. Different Calendar Attributes may apply to different Cost Types supported by this resource. "

   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?
[[SR]] Actually there is none. Maybe, we could instead write:
" it is RECOMMENDED  for an ALTO Server that the time interval size specified in the IRD is the smallest possible one that it can provide. The Client can aggregate cost values on its own if it needs a larger granularity."  

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?
[[SR]] Yes, otherwise the Server cannot understand for which Cost Type the Client wants a Calendar. 
Should we append this latter sentence to the paragraph you quoted? 


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)".
[[SR]] Would the following re-wording be ok?
"   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, an additional member "calendar-
   response-attributes", 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.
[[SR]] This will be addressed by: it is RECOMMENDED that Servers supporting calendars also support ALTO Incremental Updates
   Using Server-Sent Events (SSE)" service, specified in [draft-ietf-alto-incr-update-sse] and likewise, that Clients using Calendars also support the SSE service