Hi Jensen, Thank you so much for the review. Please see inline, Sabine
From: alto [mailto:[email protected]] On Behalf Of Jensen Zhang Sent: Thursday, July 05, 2018 9:58 AM To: Gurbani, Vijay (Nokia - US/Naperville) <[email protected]> Cc: IETF ALTO <[email protected]> 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 ------- Best, Jensen On Wed, Jul 4, 2018 at 5:23 AM Danny Alex Lachos Perez <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> > Sent: Tuesday, July 3, 2018 10:55:18 AM > To: Vijay K. Gurbani > Cc: [email protected]<mailto:[email protected]>; Chan Dawn; > Randriamasy, Sabine (Nokia - FR/Paris-Saclay); > [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> > 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 > <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > 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:[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>] >> On Behalf Of >> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> >> Sent: Monday, July 02, 2018 5:09 PM >> To: >> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> >> Cc: >> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> >> 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><http://tools.ietf.org>. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> alto mailing list >> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> >> https://www.ietf.org/mailman/listinfo/alto >> >> _______________________________________________ >> alto mailing list >> [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> >> https://www.ietf.org/mailman/listinfo/alto >> > > - vijay > -- > Vijay K. Gurbani / > [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> > Network Data Science, Nokia Networks > Calendar: http://goo.gl/x3Ogq > - vijay -- Vijay K. Gurbani / [email protected]<mailto:[email protected]> Network Data Science, Nokia Networks Calendar: http://goo.gl/x3Ogq _______________________________________________ alto mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
