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

Vijay Gurbani <vijay.gurbani@gmail.com> Thu, 31 October 2019 16:46 UTC

Return-Path: <vijay.gurbani@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CC912008B; Thu, 31 Oct 2019 09:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LxA8oezOMRN; Thu, 31 Oct 2019 09:46:50 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6374B12006F; Thu, 31 Oct 2019 09:46:50 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id k1so7463033iom.9; Thu, 31 Oct 2019 09:46:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9tRFZNnmvcrXuyhe+v/+zHk9kKisnRAojZRhPewjmM8=; b=Vot/OyB3beF0IThn98iMG9ETN7FkFOuz8zshRaVxUFgHq6Cw59FYet1PAH7hoAnsvi nf5f9hwq7XWiSET+ajxuhxkY+I1Q7Nvmf29w5QlhxocuYRrU5dLK2JHK7/Dm7PSMhGpv uMO1PnXmThqrLrWZdoJshnbjRL7yHvBVYEJprPWzABoBGM9Ukd7LXw1pHQhIYWTHgQ9+ VvN/yu/eLTz1iC03SBVcNHaoJtbxQYRdZ20IPnhaJg+zXyd6vg1MXiD9/OWixsSRnghF BW9Yzs3k3evlTlOxxrtlr+bbjExJ6Wrs0avXMsBNmmygrCQqjz7tbcoF7NHVS4BdEfCV GFTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9tRFZNnmvcrXuyhe+v/+zHk9kKisnRAojZRhPewjmM8=; b=PdYaSrr1ixWQ/AJ7WtOp7e9XIxyi570h8CTp6wMswNDcD8i/gBUlbCwd3LW6vkrlsu CFnSsVGtyPNs9fgiiL4H7nSuy8hRjalEv25OUDfIN1herLYDppQaZ0nbo9rWasfPuBVw 1hz4TTHv9IKx2f2lZfibxYpgB2VWNdrBOOJZacrRI++q/4MlaZ+YO/v+Yg4gKnNDmGOX yMbwYsjTZ99RrST9mhEIHduu+f3QlmcDf0ah0VJ88P0QDQc8iMqPq81zTydukIfzI2KV AZUcINgILT8JS0gB0t+fzpHRiFYWoT5oVxw2QJhtyIs1R1IcJYoyy5xVjsHsRF0/MHrC K/eA==
X-Gm-Message-State: APjAAAXaJscj7AR+MKS83tyLBH+N0TiFSmL0oDo6akQ8buK7S3BWUh2S VdyNjxGa7/dO5il5JNET2FYFoUXc4uCYdYsAGCI=
X-Google-Smtp-Source: APXvYqxjWHVhjEz7jsqatJ6FEFTAnaNYWerG0ur6+Yv16NRxH8ANjUcsReo87jlzSnJtvXtjEARsvFVkFbhK7WQY7zA=
X-Received: by 2002:a5e:9b04:: with SMTP id j4mr6221814iok.45.1572540409521; Thu, 31 Oct 2019 09:46:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMTW_KvP4OvvxAZWrBPfGFqt3qccVsDQ7_ePFhYFw+CJeivDg@mail.gmail.com> <PR1PR07MB5100C8EDC7C42FAFDA9D4BAC95630@PR1PR07MB5100.eurprd07.prod.outlook.com>
In-Reply-To: <PR1PR07MB5100C8EDC7C42FAFDA9D4BAC95630@PR1PR07MB5100.eurprd07.prod.outlook.com>
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Thu, 31 Oct 2019 11:46:40 -0500
Message-ID: <CAMMTW_LaaVkrsFz5Dh-F3phDy65=9B=bLZNWf_w9W2JYF8H7rw@mail.gmail.com>
To: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>
Cc: "draft-ietf-alto-cost-calendar@ietf.org" <draft-ietf-alto-cost-calendar@ietf.org>, IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000816c5005963798a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/DnxCFJ0clKuCs7fCGOkH8QMfIaw>
Subject: Re: [alto] Chair review of cost-calendar-13
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2019 16:46:54 -0000

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) <sabine.randriamasy@nokia-bell-labs.com>; 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 <vijay.gurbani@gmail.com>;
> *Sent:* Thursday, October 31, 2019 3:22 PM
> *To:* draft-ietf-alto-cost-calendar@ietf.org
> *Cc:* IETF ALTO <alto@ietf.org>;
> *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
>