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 <[email protected]> > Sent: Thursday, December 06, 2018 10:22 AM > To: The IESG <[email protected]> > Cc: [email protected]; Gurbani, Vijay (Nokia - > US/Naperville) <[email protected]>; [email protected]; > Gurbani, Vijay (Nokia - US/Naperville) <[email protected]>; > [email protected] > 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
