Hi Vijay, Ok, then I will post a revision by Monday. Cheers, Sabine
From: Vijay Gurbani <[email protected]> Sent: Thursday, October 31, 2019 5:47 PM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]> Cc: [email protected]; IETF ALTO <[email protected]> Subject: Re: Chair review of cost-calendar-13 Sabine: Thank you for going over my comments, and doubly so for getting a new revision out by Mon. Regarding the comment in S4.1.1, I am okay if your preference is to put a normative MUST, although from my understanding, a 'can' suffices as well since the rest of the processing will yield the desired result. But that is a minor point, and I am fine with the MUST. Cheers, - vijay On Thu, Oct 31, 2019 at 11:21 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]<mailto:[email protected]>> wrote: Hi Vijay, Great thanks for your thorough review and suggestions. Besides section 4.1.1, I will integrate them since they definitely improve clarity. I can definitely upload a new version by next Monday. Regarding comments on the MUST rule in section 4.1.1, I would prefer to keep the MUST rule for the following reason: If a Calendar-aware client does NOT provide a boolean array “calendared<1..*>”, then, whether the resource has calendaring capabilities or not, the Server will return a non-Calendar aware response (i.e. single cost value) for all requested metrics. If Client does provide “calendared<1..*>” to a non-Calendar aware ALTO server, the latter will ignore it and send a non-Calendar aware response. So if the Client really wants calendars, it has to insert “calendared<1..*>”, with values set to ‘true’ for those metrics for which it wants a Calendar. This rule also covers the case where a Client does not want Calendars for all the calendared metrics in a resource. Does this sound reasonable? Thanks, Sabine From: Vijay Gurbani <[email protected]<mailto:[email protected]>> Sent: Thursday, October 31, 2019 3:22 PM To: [email protected]<mailto:[email protected]> Cc: IETF ALTO <[email protected]<mailto:[email protected]>> Subject: Chair review of cost-calendar-13 Dear Sabine: First of all, I must apologize for being the bottleneck on cost-calendar. I appreciate your patience while I got to it. I have reviewed the -13 version and I think we are good to go with minor edits as noted below. I realize Mon is the cutoff date for I-Ds, so sorry for the late post of the edits. But if you are able to spin a new version by Monday, I can move the work ahead. Here are the comments, mostly editorial: - S2.3: What is a "generic timezone"? Is it UTC or GMT? Later on, in S4 you state that the reference timezone is UTC. Why not mention that in S2.3? Something like this: * time zone (in UTC), - S2.4: s/to be light/to be lightweight/ - S2.4.2: s/That is a legacy/That is, a legacy/ - S3.1: s/lasts respectively 5 minutes and 2 hours./lasts 5 minutes and 2 hours, respectively./ - S3.3: '"string-servicestatus": refers to fictitious metric "servicestatus" in some example mode "string",', here what do you mean by "some example mode "string""? "string" is not an example mode as much as it denotes a data type. Perhaps you meant to say '"string-servicestatus": refers to a fictitious metric "servicestatus" containing a string to reflect...' - S3.3: s/The design of the Calendar capabilities allows that some Calendars on a cost type name are available in several information resources with different Calendar Attributes./The design of the Calendar capabilities allows some Calendars with the same cost type name to be available in several information resources with different Calendar Attributes./ - S4.1.1, second paragraph: The use of normative MUST is a bit puzzling. There is certainly nothing that prevents a Calendar-aware ALTO client from not inserting the 'calendared' field if it chooses to. (Perhaps it is talking to a non-Calendar aware ALTO server.) I think that s/MUST/can/ is sufficient here, unless there is a specific reason on why a Calendar-aware ALTO client must always insert the 'calendared' parameter. Is there? (The MUST NOT in the next paragraph is perfect, as it allows for backwards compatibility.) - S8: "it should develop self-check", what exactly is meant here? My suspicion is that you are trying to motivate the use of SSE here. If that is the case, I would recommend that you re-write parts of the paragraph as follows: OLD: ...adapt and extend protection strategies specified in Section 15.2 of the base protocol: it should develop self-check and also ensure information update, to reduce the impact of this risk. To address the risk of unexpected ALTO Values changes that the ALTO Client would be unaware of, it is RECOMMENDED that Servers supporting Calendars also support the "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service, specified in [draft-ietf-alto-incr-update-sse]. Likewise, it is RECOMMENDED that Clients using Calendars also support the SSE Service. NEW: ...adapt and extend protection strategies specified in Section 15.2 of the base protocol. For example, to be notified immediately when a particular ALTO value that the client depends on changes, it is RECOMMENDED that both the ALTO Client and ALTO Server using this extension support "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service [draft-ietf-alto-incr-update-sse]. Thanks again for your patience. Cheers, - vijay
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
