Re: [alto] I-D Action: draft-ietf-alto-cost-calendar-06.txt

"Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <> Thu, 05 July 2018 09:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 152FB130E2E for <>; Thu, 5 Jul 2018 02:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 AVflF-GhsEej for <>; Thu, 5 Jul 2018 02:58:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45482124C04 for <>; Thu, 5 Jul 2018 02:58:20 -0700 (PDT)
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:X-MS-Exchange-SenderADCheck; bh=9GzEqSUtIZ4zktH36rVac2dZqmF8wjmZujNhW70V1IU=; b=PYb666CCqJ5RtFvecg5X4ro8k1tN1I54rJPX1s2KsOtHFq4bOFZ1le5LIdYg3vES0iN+8ZBbTQ8QR4b4bwdLDVbHv3ppiQKrBcZ8H95Z/pIV2XrnFw9pj3C2a4fyBM14xc278yez8YTjeDRQlWxYQLQED2ZTBS6eTue4L3VKpk0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.13; Thu, 5 Jul 2018 09:58:17 +0000
Received: from ([fe80::541e:d559:1263:9c69]) by ([fe80::541e:d559:1263:9c69%5]) with mapi id 15.20.0930.016; Thu, 5 Jul 2018 09:58:16 +0000
From: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <>
To: Jensen Zhang <>, "Gurbani, Vijay (Nokia - US/Naperville)" <>
Thread-Topic: [alto] I-D Action: draft-ietf-alto-cost-calendar-06.txt
Date: Thu, 5 Jul 2018 09:58:16 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2a01:cb00:a00:b000:5400:1fcf:79f:c71b]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB1633; 7:krYwygI13Xur7frNUW+7VtCLgMbRG0VPekgD/+j6lYty4jqyuOYSYl00IyHk2zxeCc8aA38L3V59oiBvmPyqTBDrpfM0E9mowyf+XFKPYklhtc7EwyeidWnXRk4EMCs1gW0C408dpro5CUAfcssJ11qQp/3/GuFbtjboEka1ZIOVjnD7spTunvC9aZ4XicOMZezh5Xe0Q1EP7gobiUWCRaZdCTUYHv+ziotjEFRwaX/PJ9xFmPCwAlLFdfSyO8SO
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(346002)(39860400002)(136003)(199004)(189003)(13464003)(5660300001)(345774005)(97736004)(8676002)(81166006)(81156014)(14444005)(8936002)(68736007)(4326008)(39060400002)(102836004)(53946003)(446003)(7736002)(14454004)(6246003)(53366004)(53376002)(74316002)(46003)(86362001)(478600001)(5070765005)(99286004)(2906002)(966005)(186003)(110136005)(316002)(256004)(6506007)(53936002)(53386004)(476003)(7696005)(486006)(53546011)(76176011)(25786009)(105586002)(229853002)(55016002)(33656002)(54896002)(6306002)(236005)(606006)(790700001)(9686003)(6116002)(6436002)(11609785009)(2900100001)(5250100002)(106356001)(93886005)(11346002)(90052001)(9984715007)(4068875011); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1633;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
x-ms-office365-filtering-correlation-id: 1f83857c-8e46-47fa-fbce-08d5e25dd41e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(109105607167333)(17574466456847); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:AM4PR07MB1633;
x-ms-traffictypediagnostic: AM4PR07MB1633:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(20558992708506)(278428928389397)(120809045254105)(192374486261705)(82608151540597)(85827821059158)(109105607167333)(148501403981450);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231254)(11241501184)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:AM4PR07MB1633; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1633;
x-forefront-prvs: 0724FCD4CD
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: VKePZ16ob3oy40G0vLXOASWZxQCsIcMboCU+B5JHBPxpjsIy0DtLVUwdvBH4UbCfEYjWyBIbsFTWF6w0TtOFvXZ0V3DRlv1WTYWhbQoWmAPR93Ubhqp2rd1fqig38FGh698FKCG5cKvpmF18c5smvU9KWrKP87n0uAaYMMbqhl1dCywO5M/1DGQ4pT2y6yjJBPRBjgw7ydIimVyOGjCSuDvhWd/gieIauja+4KgKBoB4Cf6uiXdMUBZTAK1H22zHd/p1nvDPqQD6lL/MHrmZaN83l5gaoP89qUld9P3f20OgdT7DUJkRp4G/RWEk/jdj7YdyFvdgKlwOxtfzTdU4RlFPbS0Q7/tQvKCQnhDGkew=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM4PR07MB32364EB98ED2384754DD51A895400AM4PR07MB3236eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f83857c-8e46-47fa-fbce-08d5e25dd41e
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2018 09:58:16.0788 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1633
Archived-At: <>
Subject: Re: [alto] I-D Action: draft-ietf-alto-cost-calendar-06.txt
X-Mailman-Version: 2.1.26
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: Thu, 05 Jul 2018 09:58:27 -0000

Hi Jensen,

Thank you so much for the review. Please see inline,

From: alto [] On Behalf Of Jensen Zhang
Sent: Thursday, July 05, 2018 9:58 AM
To: Gurbani, Vijay (Nokia - US/Naperville) <>
Subject: Re: [alto] I-D Action: draft-ietf-alto-cost-calendar-06.txt

Hi Vijay and WG,

I just finish the review of Section 6 and 7 of the cost calendar draft. Hopefully, it is not too late.

There is no major issue in these two sections. But just some sentences are not clear for me. I post my recommended edits. May need authors to check whether my understanding is correct.

Following is my detailed review:

Section 6., paragraph 2:

>    The calendaring information provided by this extension requires
>    additional considerations on three security considerations discussed
>    in the base protocol: potential undesirable guidance to clients
>    (Section 15.2 of [RFC7285]), confidentiality of ALTO information
>    (Section 15.2 of [RFC7285]), and availability of ALTO (Section 15.5
>    of [RFC7285]).  For example, by providing network information in the
>    future in a calendar, this extension may improve availability of

  improve availability -> improve the availability
[[SR]] OK will do

Section 6., paragraph 4:

>    For confidentiality of ALTO information, an operator should be
>    cognizant that this extension may introduce a new risk: an ALTO
>    client may get information for future events that are scheduled
>    through calendaring.  Possessing such information, the client may use
>    it to achieve its goal: (1) initiating connections only at
>    advantageous network costs, leading to unexpected network load; (2)

  "unexpected network load" is not clear for me here. Do you mean the
  skew of the network load which can lead to the congestion? How about
  changing the words to "leading to imbalance of the network load and
  potential congestion"
[[SR]] the expression" unexpected network load" means “undesirable load increase”, which indeed may be "leading to imbalance of the network load and potential congestion" as you mentioned.
Would “undesirable load increase” be clearer?

Section 6., paragraph 6:

>    To mitigate this risk, the operator should address the risk of ALTO
>    information being leaked to malicious clients or third parties.  As
>    specified in Section 15.3.2 ("Protection Strategies") of [RFC7285],
>    the ALTO server should authenticate ALTO clients and use the
>    Transport Layer Security (TLS) protocol so that Man In The Middle
>    (MITM) attacks to intercept an ALTO Calendar are not possible.
>    [RFC7285] ensures the availability of such a solution in its
>    Section 8.3.5.  "Authentication and Encryption", which specifies that

  Please make the reference format consistent: Section 8.3.5
  ("Authentication and Encryption")
[[SR]] thanks, will do

Section 6., paragraph 7:

>    "ALTO server implementations as well as ALTO client implementations
>    MUST support the "https" URI scheme [RFC2818] and Transport Layer
>    Security (TLS) [RFC5246].

  Here misses the close quotation mark.
[[SR]] thanks, will do

Section 6., paragraph 8:

>    For potential undesirable guidance of ALTO information, an ALTO

  potential -> the potential
[[SR]] I think « potential «  without “the” is fine as well in a written document.
Actually, how about we change the sentence to “Regarding potential undesirable… “?

Section 6., paragraph 9:

>    client should be cognizant that using calendaring information can
>    have risks: (1) a repeat pattern may be only statistical, and (2)

  The meaning of the term "repeat pattern" is not clear for me. Do you
  mean the "repeated" attributed provided by the ALTO server is just a
  recommended value and may be different from the real daily pattern?
[[SR]] yes we mean «repeated« value pattern, indicated by attribute “repeated” in the server response.
And yes, similarly to statistical transportation traffic forecast, a calendar cannot predict accidents or meteorological disturbances occurring after the calendar was computed. To prevent this risk, a Client may assume that the Server will accordingly update its values as soon as possible and should “ensure  information update, to reduce the impact of this risk.”

Section 6., paragraph 10:

>    future events may change.  Hence, a more robust ALTO client should
>    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.

  self check -> self-check
[[SR]] Thanks, will do



On Wed, Jul 4, 2018 at 5:23 AM Danny Alex Lachos Perez <<>> wrote:

Some grammar, spelling, and punctuation issues about this draft are as follows:

  *   Introduction

     *   "Statement [RFC5693] and ALTO Requirements [RFC5693].Thus the current"

        *   Consider adding a space after "[RFC5693]."

     *   "locations, e.g. to reduce their costs.  ALTO intentionally avoids"
     *   "e.g. due to diurnal patterns of traffic demand or planned events such"

        *   Consider adding a comma after "e.g."

     *   "In this draft an "ALTO Cost Calendar" is specified by information"

        *   Consider adding a comma after "In this draft"

  *   Section 2

     *   "information resources capabilities, where as attributes with time"

        *   where as -> whereas

     *   "duration of the Calendar: e.g. the number of intervals provided"

        *   Consider adding a comma after "e.g."

     *   "IRD, the ALTO requests and responses for Cost calendars."

        *   Consider adding a comma after "ALTO requests"

     *   "historic or be a prediction for upcoming time periods."

        *   historic -> historical

  *   Section 3

     *   "example an ALTO Server may provide a calendar for ALTO values"

        *   Consider adding a comma after "example"

  *   Section 4

     *   "exchange: by providing it, an ALTO Server will avoid unecessary"

        *   unecessary -> unnecessary

     *   "When the Client gets the Calendar for "routingcost", it sees that the"

        *   sees -> seems

     *   "Monday, Tuesday, Wednesday and Thursday.  The ALTO Client thus may"

        *   Consider adding a comma after "Wednesday"
        *   extra space after "Thursday."

  *   Section 6

     *   "future in a calendar, this extension may improve availability of"

        *   Consider adding the article "the" after "improve"

Danny Lachos

On Tue, Jul 3, 2018 at 12:58 PM Vijay K. Gurbani <<>> wrote:
Dawn: Excellent.  Thanks a lot.  Jensen has also volunteered to look at
S6 and S7.

As soon as you post your reviews of these sections by Wed, we'll move
the work ahead, subject to what you find in your review, of course.


On 07/03/2018 10:33 AM, Dawn Chan wrote:
> Hi Vijay,
> I can do a review of S6 and S7 too.
> Dawn
> ________________________________________
> From: Jensen Zhang <<>>
> Sent: Tuesday, July 3, 2018 10:55:18 AM
> To: Vijay K. Gurbani
> Cc:<>; Chan Dawn; Randriamasy, Sabine (Nokia - FR/Paris-Saclay);<>;<>
> Subject: Re: [alto] I-D Action: draft-ietf-alto-cost-calendar-06.txt
> Hi Vijay,
> I will give a review on S6 and S7 by Wednesday.
> Best,
> Jensen
> On Tue, Jul 3, 2018, 6:26 AM Vijay K. Gurbani <<><<>>> wrote:
> Sabine: Thank you for getting this out.  I was hoping that all nits
> identified by IDNits tool will be taken care in this revision.
> Unfortunately, IDNits reports three warnings for -06.  These need to be
> eventually fixed, perhaps as part of Auth-48, etc.
> But before I can send the draft to IESG, I need key members of the WG
> who have reviewed previous versions of this draft to review the newly
> added Security Considerations section.  You only need to review this
> section, as previous versions of the draft were reviewed in their
> entirety.  The new addition here is S6 (Security Considerations) and S7
> (Operations Considerations).
> Can I please request a subset of the following people to review S6 and S7:
>    Yichen Qian, Li Geng, Dawn Chen, and Jensen Zhang
> I will like at least two people from the above set to read S6 and S7 and
> let the WG know whether the draft is ready to be moved out of the WG.
> Please do so soon, preferably by Wed midnight (US Eastern).  The
> sections are short, but your reading and feedback to the WG will be
> invaluable.
> Thank you,
> On 07/02/2018 10:23 AM, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote:
>> Hello,
>> In this version 06:
>> - Section 6 Security Considerations has been revised for a more complete threat model,
>> - A new Section 7 "Operations Considerations" has been added and now contains the initial text on Security Considerations of version draft-ietf-alto-cost-calendar-05.
>> Thanks,
>> Sabine
>> -----Original Message-----
>> From: alto [<><<>>] On Behalf Of<><<>>
>> Sent: Monday, July 02, 2018 5:09 PM
>> To:<><<>>
>> Cc:<><<>>
>> Subject: [alto] I-D Action: draft-ietf-alto-cost-calendar-06.txt
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF.
>>         Title           : ALTO Cost Calendar
>>         Authors         : Sabine Randriamasy
>>                           Richard Yang
>>                           Qin Wu
>>                           Lingli Deng
>>                           Nico Schwan
>>       Filename        : draft-ietf-alto-cost-calendar-06.txt
>>       Pages           : 27
>>       Date            : 2018-07-02
>> Abstract:
>>    The goal of Application-Layer Traffic Optimization (ALTO) is to
>>    bridge the gap between network and applications by provisioning
>>    network related information in order to allow applications to make
>>    network informed decisions.  The present draft extends the ALTO cost
>>    information so as to broaden the decision possibilities of
>>    applications to not only decide 'where' to connect to, but also
>>    'when'.  This is useful to applications that need to schedule their
>>    data transfers and connections and have a degree of freedom to do so.
>>    ALTO guidance to schedule application traffic can also efficiently
>>    help for load balancing and resources efficiency.  Besides, the ALTO
>>    Cost Calendar allows to schedule the ALTO requests themselves and
>>    thus to save a number of ALTO transactions.
>>    This draft proposes new capabilities and attributes on filtered cost
>>    maps and endpoint cost maps enabling an ALTO Server to provide "Cost
>>    Calendars".  These capabilities are applicable to ALTO metrics with
>>    time-varying values.  With ALTO Cost Calendars, an ALTO Server
>>    exposes ALTO cost values in JSON arrays where each value corresponds
>>    to a given time interval.  The time intervals as well as other
>>    Calendar attributes are specified in the IRD and ALTO Server
>>    responses.
>> The IETF datatracker status page for this draft is:
>> There are also htmlized versions available at:
>> A diff from the previous version is available at:
>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at<><>.
>> Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________
>> alto mailing list
>> _______________________________________________
>> alto mailing list
> - vijay
> --
> Vijay K. Gurbani /<><<>>
> Network Data Science, Nokia Networks
> Calendar:

- vijay
Vijay K. Gurbani /<>
Network Data Science, Nokia Networks

alto mailing list<>
alto mailing list<>