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]> 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]> > *Sent:* Thursday, October 31, 2019 3:22 PM > *To:* [email protected] > *Cc:* IETF ALTO <[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
