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

[Benjamin Kaduk <[e-mail]>]

Hi Sabine,

Generally these look good; a few replies inline.

On Thu, Jan 24, 2019 at 02:15:29PM +0000, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:
> 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."  

That would be good, so that clients have a reason to think that the
assumption will be useful.

> 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? 

I don't think it's necessary to include the latter sentence.

> 
> 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)."

Yes, that is a big help.

> 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


Excellent; thank you!

-Benjamin