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

[Jensen Zhang <[e-mail]>]

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


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"


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


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.


Section 6., paragraph 8:

>    For potential undesirable guidance of ALTO information, an ALTO

  potential -> the potential


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?


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

-------

Best,
Jensen

On Wed, Jul 4, 2018 at 5:23 AM Danny Alex Lachos Perez <[e-mail]>
wrote:

> Hello ALTO WG
>
> 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"
>
> Ss
>
> Danny Lachos
>
>
> On Tue, Jul 3, 2018 at 12:58 PM Vijay K. Gurbani <[e-mail]>
> 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.
>>
>> Cheers,
>>
>> 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 <[e-mail]>
>> > Sent: Tuesday, July 3, 2018 10:55:18 AM
>> > To: Vijay K. Gurbani
>> > Cc: [e-mail]; Chan Dawn; Randriamasy, Sabine (Nokia
>> - FR/Paris-Saclay); [e-mail]; [e-mail]
>> > 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 <[e-mail]
>> <mailto:[e-mail]>> 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 [mailto:[e-mail]<mailto:[e-mail]>]
>> On Behalf Of [e-mail]<mailto:[e-mail]>
>> >> Sent: Monday, July 02, 2018 5:09 PM
>> >> To: [e-mail]<mailto:[e-mail]>
>> >> Cc: [e-mail]<mailto:[e-mail]>
>> >> 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:
>> >> https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/
>> >>
>> >> There are also htmlized versions available at:
>> >> https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-06
>> >> https://datatracker.ietf.org/doc/html/draft-ietf-alto-cost-calendar-06
>> >>
>> >> A diff from the previous version is available at:
>> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-calendar-06
>> >>
>> >>
>> >> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org<http://tools.ietf.org>.
>> >>
>> >> Internet-Drafts are also available by anonymous FTP at:
>> >> ftp://ftp.ietf.org/internet-drafts/
>> >>
>> >> _______________________________________________
>> >> alto mailing list
>> >> [e-mail]<mailto:[e-mail]>
>> >> https://www.ietf.org/mailman/listinfo/alto
>> >>
>> >> _______________________________________________
>> >> alto mailing list
>> >> [e-mail]<mailto:[e-mail]>
>> >> https://www.ietf.org/mailman/listinfo/alto
>> >>
>> >
>> > - vijay
>> > --
>> > Vijay K. Gurbani / [e-mail]<mailto:
>> [e-mail]>
>> > Network Data Science, Nokia Networks
>> > Calendar: http://goo.gl/x3Ogq
>> >
>>
>> - vijay
>> --
>> Vijay K. Gurbani / [e-mail]
>> Network Data Science, Nokia Networks
>> Calendar: http://goo.gl/x3Ogq
>>
>> _______________________________________________
>> alto mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>