[alto] Chair review of cost-calendar-13

Vijay Gurbani <vijay.gurbani@gmail.com> Thu, 31 October 2019 14:19 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 370AF1200FF; Thu, 31 Oct 2019 07:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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] 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 YlPO_ATnD6DP; Thu, 31 Oct 2019 07:19:44 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 F29AB12011D; Thu, 31 Oct 2019 07:19:43 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id s6so5559428iln.0; Thu, 31 Oct 2019 07:19:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=s6tQNa4atmgWf7Nzplxguq0Cxnkwtnx+FQcMRPt7pu4=; b=VAOzZV4Y4ia+3zvwoP2EFHvo2C+opJvrj3xP/bJ5tyf6fuFnoKSnLE1sDLHWFy61zL STITHqMEAnognLLywBdUv5xkUBXO8/IJWSgjzskF3Q9pc8t0J3Nf2R7zSvyipvTG8xdr R/GZ5817zZ7m6X+rMYf0/6NaKQ+be1j0EDJJpmoNg91ICZKdvzPDX4CrBY6cEWd2PhzX 2o2RmuKpW8VamIXUUnT8zv/RaFrl5JujWDPYIfBEWz2H2UhAFVn+6LkWqYCBc/s8x9g6 ThtlB0D90oituLj5OMrVS144nYnI8X3wMqyGfh62AyV97uownL4JAh6vZ2FntR5ZXNOV kPhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=s6tQNa4atmgWf7Nzplxguq0Cxnkwtnx+FQcMRPt7pu4=; b=fvfq+bs8Ppwf6OUx+ePZlIZrTABo5dVE58dRGX2zrz5l+FDsceUN/h/ll/lo6c+dXt 8QACRJpwzgTmrT9Fm0bL07Dde49sz6c3DmDL6kXUNdnDSuEMXy+LeqcZppiOrfaYjOcg wfeFbYxxfFj4lG2taBZWABv2T7Svf09v0GMYA5rrh8dhKaqj5qsqIonsFCz6RqxetxLw B1VRRZ6ePD0OiUq2uqvDOEWfsSVUt/Sh9wGCBiNxztQOXkLXud22NiJcomflwCAw43JM S/23OqNuzEBF5WBmlHaE1pqBOzbK9VV6qZMUBOsipGpGIOtCqrM+H4Dv2A7DNXM9qufR l/nA==
X-Gm-Message-State: APjAAAUcIXd/L8nr5Fuhli/jkHljTcP/F4hMHKC1NU7KjA9gRqfmCRXZ xtRs/RsKU0olgkozci0iVqz8YBmZ91mZtkuS68eBKwI/
X-Google-Smtp-Source: APXvYqwAGZfuSk6xLPASQy7yHo9esJgzW0xbTsLZR9MKEcXfu4NcENNQ9cOYO7387/BTbnUgVYQe/2CksNAYQpYngk4=
X-Received: by 2002:a92:8d19:: with SMTP id s25mr4095698ild.273.1572531582678; Thu, 31 Oct 2019 07:19:42 -0700 (PDT)
MIME-Version: 1.0
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Thu, 31 Oct 2019 09:22:06 -0500
Message-ID: <CAMMTW_KvP4OvvxAZWrBPfGFqt3qccVsDQ7_ePFhYFw+CJeivDg@mail.gmail.com>
To: draft-ietf-alto-cost-calendar@ietf.org
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000623d740596358a6c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/eeEPBUZhfj4BiG8QEbOyx05Fn_E>
Subject: [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 14:19:46 -0000

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