Re: [alto] Chair review of cost-calendar-13

[Vijay Gurbani <[e-mail]>]

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