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

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hi Vijay,

Ok, then I will post a revision by Monday.
Cheers,
Sabine


From: Vijay Gurbani <[e-mail]>
Sent: Thursday, October 31, 2019 5:47 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[e-mail]>
Cc: [e-mail]; IETF ALTO <[e-mail]>
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) <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Thursday, October 31, 2019 3:22 PM
To: [e-mail]<mailto:[e-mail]>
Cc: IETF ALTO <[e-mail]<mailto:[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