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

"Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <> Wed, 06 December 2017 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C1CF1241F5; Wed, 6 Dec 2017 10:18:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u5FOaO8pF0U3; Wed, 6 Dec 2017 10:18:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 225ED127286; Wed, 6 Dec 2017 10:18:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yC9ZL8qYH2hcQN769ddr1dbgSCb8AYTePTW/I3Jd6bo=; b=R2GtxXOs+HrUzBBbDyBCpoErEDFaftXwZ4sy5TYUBrTFlIWRjEQJGLQj7mNMlQ0ZOAfKQ/UBXwCPM8QdqF58KrcKA9PFJyT6wE0n8VNFpwYTueNg+DauMGTHWMKuTsD23IAzAkf4nVw7ir0wk3+G28N4BlZ0Sku2n7spGEO1Rqo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Wed, 6 Dec 2017 18:18:50 +0000
Received: from ([fe80::20a0:d0b2:5906:bbd3]) by ([fe80::20a0:d0b2:5906:bbd3%17]) with mapi id 15.20.0302.007; Wed, 6 Dec 2017 18:18:50 +0000
From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <>
To: Jensen Zhang <>, "" <>
Thread-Topic: Update review of draft-ietf-alto-cost-calendar-02
Thread-Index: AQHTa0Q/fcEpL+fI/0u3qBwxKoVAUaM2jsJ5
Date: Wed, 6 Dec 2017 18:18:50 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: [2a01:cb00:a00:b000:91f8:b328:90ce:693b]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2459; 6:55QuAy4EaFS9BHgOYNLGE6waboXV15SJpgnF99xhffjAvpl172nI1DTZFPk3HpN0DymP+PNUBRFkOKu+Mod+IC4OJSzH/1CEYZfim6pYnXx4xRDv5J7dRQwRAGBZv8pAz68iRXwFW2fuWBvXoL9iz7lPRIHWxZY7aRC4v+RKb3/tqQEbGQ87CXPjqTpEv+RS3AqGHwWfP9zPWCYkuW2RBU2ZIFJOCrMcZzlL0OJXrY38DnJhlZXu+ghE4lr4q3yMigt8FulYAquGqqDEIxmxtIm3ca8DKN1as/Fr0drZQ8CdSQH5OYjHj5DYPwJRgWZW5ORMUWgY+/gjpUWRTMBOV9JS3QN6H+RcSn/sYdaL6YE=; 5:eGtBxZT/PO5HVw9FF4jYDdQN7ut9KOqyJWPwVAaosB+YLA3Geh27w6O6xdTjFAIAIBJg+mo6JiW/1WwCu4TmPHKM3qoeN0gQSZd0JcIvQST4J9FWUqXYw0qmLDBxDels1FhEPpd4aWMB90aZWOKxUe7GigeFSRmCVvOYJWqChtI=; 24:x8MlNDAlNmLeZKJfzkPGlwUKVTtNgOLSCqxqmJlU28iFYfdpVxweoQmYnTCj35097AaPjdb/gdZH/K8ApOpgcQL5jcijQlNQMFhwkK1vnho=; 7:kVGKAXZ48EA808DL6v1nxU83hJ6bN5lMUponGowuzBz0ZZb6PvH7CKWAaaCmpk/63+XgXApQytLGTZc30MQfbo4mxpeYqzVhJF2eomGKXSRYSTu0OjGKxLkjAHtMmKP0kMJeMSE17XtfIr01V/0Dr3pSqtVfz0IORnFLZQ3VGjCpSJ1mb3aE5uLm41YbXCAeZlCMvL2Nq4vsPvOLc42Wf6FADVWz9MRGg8uoucSUBlCOBs254/SoafuK+3iSeEjt
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b36a68a0-78e6-4cb9-9b37-08d53cd5ccde
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:HE1PR0701MB2459;
x-ms-traffictypediagnostic: HE1PR0701MB2459:
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231022)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:HE1PR0701MB2459; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB2459;
x-forefront-prvs: 05134F8B4F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(39860400002)(189003)(199004)(53434003)(229853002)(2501003)(15650500001)(478600001)(101416001)(6506006)(6436002)(316002)(6306002)(6606003)(110136005)(9686003)(55016002)(53936002)(14454004)(54896002)(7696005)(6246003)(2906002)(2950100002)(5250100002)(236005)(33656002)(76176011)(8676002)(81166006)(99286004)(8936002)(6116002)(102836003)(4326008)(7736002)(86362001)(106356001)(81156014)(39060400002)(97736004)(3280700002)(19627405001)(230783001)(606006)(5660300001)(105586002)(68736007)(25786009)(2900100001)(74316002)(3660700001)(90052001)(560514002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2459;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB24593310746D7F896A23FDBD95320HE1PR0701MB2459_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b36a68a0-78e6-4cb9-9b37-08d53cd5ccde
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 18:18:50.4384 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2459
Archived-At: <>
Subject: Re: [alto] Update review of draft-ietf-alto-cost-calendar-02
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Dec 2017 18:18:56 -0000

Hi Jensen,

Indeed, the revison of the drafts is in progress and thanks a lot for your comments that will be considered for the next version. Please see my feedback inline.

In the new text proposals, text in ++blabla++ format means "blabla" is added to the initial text.



De : Jensen Zhang <>
Envoyé : samedi 2 décembre 2017 09:04
À : Randriamasy, Sabine (Nokia - FR/Paris-Saclay);
Objet : Update review of draft-ietf-alto-cost-calendar-02

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".

=> OK, the text may be too careful and we may allow a client to consider the first set of attributes and ignore the next ones.
The sentence would then become: "... the ALTO client SHOULD  ++ only consider the first occurrence of "calendar-attributes and++  ignore any  ++additional++  calendar capabilities   ..."

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.

==> the motivation here was mainly to lighten the data volume by using only one fieldand make sure that a change in either units and number of units will not be missed by the client.
Do you mean that the parsing of the value of the current "time-interval-size" is longer and more complex?

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.

==> Indeed, we should minimize the error messages. So how about writing: "This field MUST NOT be specified if ++no++ member "calendar-attributes" is  present for this information resource.  ++ It  will be ignored by a legacy ALTO Server, according to section 8.3.7 of RFC 7285. A Calendar-aware Server will return a response with a single cost value as specified in RFC 7285 ++ ".

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".

==> good catch, thanks a lot.


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