[alto] Update review of draft-ietf-alto-cost-calendar-02

Jensen Zhang <jingxuan.n.zhang@gmail.com> Sat, 02 December 2017 08:05 UTC

Return-Path: <jingxuan.n.zhang@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 45F8E126DEE; Sat, 2 Dec 2017 00:05:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YzF2XZxKFVww; Sat, 2 Dec 2017 00:05:01 -0800 (PST)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 D075D124207; Sat, 2 Dec 2017 00:04:57 -0800 (PST)
Received: by mail-oi0-x231.google.com with SMTP id w131so8713366oiw.0; Sat, 02 Dec 2017 00:04:57 -0800 (PST)
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=Y6AisTwcfhrByi3P3YPb8+hc6ucKcfv1lhRHmrBzbd8=; b=rdfsy7/D88f09s+CVqfwwY4sf3fGfuNnMlUZnp1E17dZ5PvQGWGiBS6p10R0ntiCBc dKbwyTzQZTxRKSaHwIffLf8OeuvYeSn7oOoUB6XGNG522r8jjm1GepYPr2z2dSwryTeN V5s2dCHQwl5FesMClkWbECMIFw7lXDMR2KnWX69XRRBzCbrggbuaAQkWKHVjj2++7qte UCU7aoWV2Xj/InCQQdTb7u1chPId4F1x4SqbzcZT3FFrGEIav5ZgMrXJYnzXaSUpcr2J UA/rdXdc9PWDtimmdjjr7nkhNp0TLYW6wFE46Ow4EcrZ1++O21ISmikudhuXMtMd5WDy baAQ==
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=Y6AisTwcfhrByi3P3YPb8+hc6ucKcfv1lhRHmrBzbd8=; b=TBVU0zAMt0eiTTbw7a89iihIMCUXYg8+Sld4Mmo3nd7Pe5w0YSpGXWIEuDEXIZ4nxg Be2APEA5GfqTsIjs14IX+QEG9pZ04Cds/Z7P0mRMQ9j4ykct12Ybl+1+zHUYRvges+zw eSaBi1kGHa+/ZviK/KMk+aZo1v2/401pvmWR3BedF6Vd4ywt7vrqOURCBfje0JkEsdbV LKPKVt3hb8MXYByEa5HuC22q0wGqO/lFsvdHkB+m7PL+aXvt0zjLBXQbIKSX+x56muCZ m0QjrIURxqt/f3VlBBhOYBqjPc+LKsHxPQ0Q/4cVRJzQ3HEv8wIa6iGQQuLsPN8UzRep 8H/Q==
X-Gm-Message-State: AJaThX4RZhPBDJ94NBN8L+pNuj5HrUFZtJEzg+NJKazDdT7nCT17nFvS pM4czg+MfQku1NRCvM1OMtxjEuvMGcSLcLEAeYE=
X-Google-Smtp-Source: AGs4zMbb3OReD+yMvSsGI/e6iYfldBRCSgiR28Aaui6GmnD6C0mBgzzAhoho67E8mLhjpzmm9EaHM+SRyEZlkA6m2J8=
X-Received: by with SMTP id b187mr8861960oif.264.1512201897076; Sat, 02 Dec 2017 00:04:57 -0800 (PST)
MIME-Version: 1.0
From: Jensen Zhang <jingxuan.n.zhang@gmail.com>
Date: Sat, 02 Dec 2017 08:04:46 +0000
Message-ID: <CAAbpuyrt9yo_TE-nKGOHaSSHg-M8VprcT-4c2PAKZaXXTOXe3w@mail.gmail.com>
To: "Randriamasy, Sabine (Nokia - FR)" <sabine.randriamasy@nokia-bell-labs.com>, draft-ietf-alto-cost-calendar@ietf.org
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="001a113cdff2e7704c055f56f071"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/D8CW8uIAHMfNzpu1_rzVCjxxkLY>
Subject: [alto] Update review of draft-ietf-alto-cost-calendar-02
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 02 Dec 2017 08:05:03 -0000

Hi Sabine and other authors,

How are you? Since the last review from Dawn (
I have not found the draft was updated yet. From the agreement in IETF 99,
there are a lot of text harmonization work. I assume the revision is in
progress. I just append some technical review for the current version
below. Hopefully, it will be helpful.


Section 3.1., paragraph 3:

>    A member "calendar-attributes" MUST appear only once for each
>    applicable cost type name of a resource entry.  If "calendar-
>    attributes" are specified several times for a same "cost-type-name"
>    in the capabilities of a resource entry, the ALTO client SHOULD
>    ignore any calendar capabilities on this "cost-type-name" for this
>    resource entry.

  I think it will be much better to adopt the finest granularity than
  just ignore all, if there are more than one "calendar-attributes"
  object for the same "cost-type-name".

Section 3.1., paragraph 9:

>       *  is the duration of an ALTO calendar time interval, expressed as
>          a time unit appended to the number of these units.  The time
>          unit, ranges from "second" to "year".  The number is encoded
>          with an integer.  Example values are: "5 minute" , "2 hour",
>          meaning that each calendar value applies on a time interval
>          that lasts respectively 5 minutes and 2 hours.

  I prefer to use another field (i.e. "time-interval-unit")
  to express the time unit and make "time-interval-size" a simple
  JSONNumber. Because it can simplify the data validation. In this way,
  the server and client only need to check the data type (number and
  enumeration) without validating the data content.

Section 4.1.1., paragraph 5:

>    This field MUST NOT be specified if member "calendar-attributes" is
>    not present for this information resource.

  From section 8.3.7 of RFC7285, "ALTO implementations MUST ignore
  unknown fields when processing ALTO messages", I think we need
  to change "This field MUST NOT be specified" to "This field MUST
  be ignored". Because if "calendar-attributes" is not present,
  the server should be a legacy ALTO server which doesn't support
  calendar extension. So the "calendared" field is an unknown field
  in the request.

Section 4.2.1., paragraph 1:

>    The extensions to the requests for calendared Endpoint Cost Maps are
>    the same as for the Filtered Cost Map Service, specified in section
>    XXXX of this draft.

  Just a reminder. Don't forget to change "section XXXX".


Once we have an update, I would like to proofread the revision.