Hi Michael, You are welcome. No worries, I will be on vacation next week. Best regards Sabine
>>-----Message d'origine----- >>De : Scharf, Michael (Nokia - DE) >>Envoyé : mercredi 24 février 2016 15:28 >>À : Randriamasy, Sabine (Nokia - FR); Randriamasy, Sabine (Nokia - FR); >>Gurbani, Vijay (Nokia - US); IETF ALTO >>Objet : RE: [alto] State of the WG >> >>Hi Sabine, >> >>Thanks a lot for the review! I am currently busy but I will look into >>it as soon as possible. >> >>Thanks >> >>Michael >> >> >> >>-----Original Message----- >>From: alto [mailto:[email protected]] On Behalf Of EXT Randriamasy, >>Sabine (Nokia - FR) >>Sent: Monday, February 08, 2016 5:50 PM >>To: Randriamasy, Sabine (Nokia - FR); Gurbani, Vijay (Nokia - US); IETF >>ALTO >>Subject: Re: [alto] State of the WG >> >>Hi again, >> >>Apologies, I should also have reviewed the text of my e-mail. The >>attached review "feedback_deployment_13_section1-to-3-4_sr.txt" I just >>sent STOPS at beginning of 3.4, as I wanted to focus on the last >>updates. >> >>Thanks, >>Sabine >> >> >>>>-----Message d'origine----- >>>>De : Randriamasy, Sabine (Nokia - FR) >>>>Envoyé : lundi 8 février 2016 17:42 >>>>À : Randriamasy, Sabine (Nokia - FR); Gurbani, Vijay (Nokia - US); >>>>IETF ALTO Objet : RE: [alto] State of the WG >>>> >>>>Hi Michael, Hans and all, >>>> >>>>As promised, here is my feedback to sections 1 to 3.4 included. I >>>>tried to separate "Nits only" and "nits + comments". >>>>In a first step, I am sending the review as an attachment. >>>> >>>>Again, thanks a lot for the work, this text is very well structured, >>>>clear and interesting. Some parts need a bit of clarifications and >>>>also, some re-phrasing to highlight the advantages of ALTO Services >>>>and providing incentives to use them is suggested here and there. >>>> >>>>Thanks, >>>>Sabine >>>> >>>> >>>>>>-----Message d'origine----- >>>>>>De : alto [mailto:[email protected]] De la part de EXT >>>>>>Randriamasy, Sabine (Nokia - FR) Envoyé : vendredi 5 février 2016 >>>>>>18:56 À : Gurbani, Vijay (Nokia - US); IETF ALTO Objet : Re: [alto] >>>>>>State of the WG >>>>>> >>>>>> >>>>>>Hi Michael, Hans and all, >>>>>> >>>>>>I have volunteered to review draft-ietf-alto-deployment-13. As time >>>>>>passes and the document is long, I prefer to send you my feedback >>>>>>piecewise, focusing first on the updated sections. For the sake of >>>>>>rapidity, I sometimes put Nits and other feedback together. >>>>>> >>>>>>So below, you will find my feedback on section 3.6. >>>>>>Then, I'll send you my feedback on sections 1 to 3.4 included. >>>>>> >>>>>>All in all, thanks for this clarified and enriched version of >>draft- >>>>>>ietf-alto-deployments. I found no major issues but some sentences >>>>need >>>>>>to be re-formulated and figures need be referenced in the text. >>>>>>Don't hesitate to get back to me if needed. >>>>>> >>>>>>Thanks, >>>>>>Sabine >>>>>> >>>>>>------------------------------------------------------ >>>>>>I used the following conventions: >>>>>> >>>>>>(1.2.3) section nb >>>>>>(p12) page nb >>>>>>para 2 = paragraph 2 >>>>>> >>>>>>(++ blabla) = added blabla >>>>>>(-- blabla) = removed blabla >>>>>>"old blabla" ==> "new blabla" = replace "old blabla" by "new >>blabla" >>>>>> >>>>>>--------- >>>>>>General: >>>>>> >>>>>>Figures 14 to 20: the caption should be harmonized with the rest of >>>>>>the document in that the common nouns should be written in low case >>>>>>and not start with a capital letter. >>>>>> >>>>>>In section 3.6.4 Calculation of Cost Map: many clarifications are >>>>>>needed on the path cost calculation >>>>>> >>>>>>--------- >>>>>>(p40) >>>>>>--------- >>>>>>para 1: "Figure 2" should be replaced by "Figure 15" as fas as I >>>>>>understand para 2: "listed information" ==> "listed >>information(++s)" >>>>>> >>>>>>--------- >>>>>>(p41) >>>>>>--------- >>>>>>- para 1: "As example" ==> "For example" >>>>>>- para 2: "information" ==> "information(++s)" >>>>>>- item 1: "Link" ==> "link" >>>>>>- (3.6.2), title: for transition to section 3.6.3 I suggest >>>>"Potential >>>>>>(++ input) Data Processing and Storage" >>>>>>- (3.6.2), para 3: to reference Figure 16, I suggest: "Each router >>>>>>could..." ==> "(++ As illustrated in Figure 16 for the router R2 of >>>>>>Figure 14,) each router could..." >>>>>> >>>>>>--------- >>>>>>(p42) >>>>>>--------- >>>>>>- item 2: to avoid hinting that an endpoint may be associated to >>>>>>several PIDs, I suggest: "AS numbers, or AS distances. >>>>>> Endpoints may belong to..." ==> "AS numbers (--,) or AS distances. >>>>>> Endpoints may be connected to" >>>>>>- para 2: "and/ or" ==> "and/or" >>>>>> >>>>>>- The presence of the remaining text "A suitable information... >>>>>>belongs to its own AS" before Figures 16 and 17 is pretty >>confusing, >>>>>>especially when encountering terms "weights" and "metrics". So I >>>>>>strongly suggest to move this remaining text after Figure 17 (p44). >>>>>> >>>>>>- instead: we need to reference Figure 16 and clarify the example >>>>>>attribute "Metric". So I suggest right after "just to name a few", >>>>>>to append "Figure 16 provides an example set of attributes >>>>>>associated to the router R2 of the exemple network depicted in >>>>>>Figure 14. The attribute "Metric" is an example of ... TBC" >>>>>> >>>>>>--------- >>>>>>(p43) >>>>>>--------- >>>>>>- Figure 16: please clarify what "default client subnet metric" can >>>>be >>>>>>- para 2: reference to Figure 17 needed. i suugest replacing >>"Router >>>>>>R8... " by "Figure 17 provides values for the same attributes >>>>>>associated to router R8. R8... " >>>>>> >>>>>>--------- >>>>>>(p44) >>>>>>--------- >>>>>>- para 1 (after text moved from p42): Insert ref to fig. 18, >>>>>>suggestion: "In the example, the link attributes..." ==> "Figure 18 >>>>>>provides an example where the link attributes..." >>>>>> >>>>>> >>>>>>--------- >>>>>>(p45) >>>>>>--------- >>>>>>- (3.6.3) title: in relation to (3.6.2) I suggest: "Calculation of >>>>>>Network Map (++from the Input Data)" >>>>>>- para 1: suggestion: "presentation of the network to a coarse- >>>>grained >>>>>>matrix presentation" ==> "(++re)presentation of the network to a >>>>>>coarse(++r) grained (++and abstracted) matrix (++re)presentation" >>>>>>- para 2: algorithm(++s) can utilize all (?? you mean "all" or >>"any" >>>>>>?) information .... The functions ... to simplify the map or (-- >>to) >>>>>>hide details ... published (--with) (++in) the resulting ALTO >>>>>>network >>>>map. >>>>>> >>>>>>--------- >>>>>>(p46) >>>>>>--------- >>>>>>- para 2: "Figure 14" ==> "Figure 19" >>>>>>- (3.6.4), para 1: "calculate values unidirectional" ==> "calculate >>>>>>unidirectional values" >>>>>> >>>>>>--------- >>>>>>(p47) >>>>>>--------- >>>>>>It is necessary to clarify the text on path calculation in this >>page. >>>>>> >>>>>>--- para 1: >>>>>>- "or subnet the cost" ==> "or subnet (++,) the cost" >>>>>>- "cost function may calculate" ==> "cost function may (++first) >>>>>>calculate" >>>>>>- "In that case a" ==> "In that case (++,) a" >>>>>>- "required which decide(--s)" ==> "required to decide..." >>>>>>- as this section is about computing values exposed by the ALTO >>>>>>Server, I suggested to append to following text. "resulting cost >>>>>>value" ==> "resulting cost value (++as RFC7285 allows one cost >>value >>>>>>only between >>>>>>2 PIDs.)" >>>>>>- Such (++a) tie-breaker can be (a++) simple function(--s) such as >>>>>>minimum, maximum, or average value. >>>>>> >>>>>> >>>>>>--- para 2: reformulation is needed here in order to cover the most >>>>>>"popular" optimal path extraction methods. >>>>>>- "the minimum path weight." ==> "the minimum weight path." >>>>>> >>>>>>- I recommend the following insertion: "The path weight is the >>>>sum..." >>>>>>==> "(++When the link weight is represented by an additive metric,) >>>>>>the path weight is the sum...". >>>>>>The reason is that: when the link weight metric represents a >>>>bandwidth >>>>>>performance, the metric composition law is "MIN" and path weight is >>>>>>equal to the smallest of the link weights. For a metric such as >>>>packet >>>>>>loss, the path weight is the multiplication over all links. >>>>>> >>>>>>- sentence "Hence, the cost function must first determine the path >>>>>>before it can determine any other metric value": besed on my >>>>>>previous comment, I'd rather say "Hence, the cost function >>generally >>>>>>extracts the optimal path w.r.t. a chosen metric". >>>>>> >>>>>>- sentence "As a result, the metric value can differ from the >>>>>>expectation where the path with the shortest path weight was not >>>>>>considered" is hard to understand and could be removed and replaced >>>>>>with some elaboration on the Dijkstra example. I will propose some >>>>>>formulation right after the next item. >>>>>> >>>>>>- "But it is also possible..." ==> "(--But) it is also possible..." >>>>>> >>>>>>- Suggestion for para 2 (let me know if I missed something) "No >>>>matter >>>>>>what metric the cost function is using, the path from source to >>>>>>destination is usually defined by the minimum (-+ weight) path. >>>>>> (++When the link weight is represented by an additive metric,) the >>>>>>path weight is the sum of the link weights of all traversed links. >>>>>> The path may be determined for instance with the Bellman-Ford or >>>>>>Dijkstra algorithm. The latter progressively builds the shortest >>>>>>path in terms of cumulated link lengths. In our example, the link >>>>>>lengths are link weights with values illustrated in Figure 15. (--2 >>>>>>sentences removed). (--But) It is also possible that more than one >>path..." >>>>>> >>>>>>--- para 3 >>>>>>- "values for other PID pairs for arbitrary reasons" ==> " values >>>>for >>>>>>some PID pairs due to arbitrary reasons" >>>>>> >>>>>> >>>>>>--- para 4 >>>>>>- "In this example, the selected >>>>>> metric..." ==> "Figure 20 provides an example where the selected >>>>>>metric..." >>>>>>- "from source to (++ the endpoints connected to the) destination >>>>PID": >>>>>>otherwise all the values in Figure 20 should be minus 1. >>>>>> >>>>>>--------- >>>>>>(p47) >>>>>>--------- >>>>>>para 1: "Due to the minimum value tie-breaker 3..." ==> "Due to the >>>>>>minimum (++hopcount)value tie-breaker (++,) 3..." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>-----Message d'origine----- >>>>>>>>De : alto [mailto:[email protected]] De la part de Vijay K. >>>>>>>>Gurbani Envoyé : mardi 26 janvier 2016 16:29 À : IETF ALTO >>Objet : >>>>>>>>[alto] State of the WG >>>>>>>> >>>>>>>>Folks: The mailing list has been awfully quiet. >>>>>>>> >>>>>>>>Presently, we have 3 active I-Ds that are being tracked towards >>>>>>>>charter >>>>>>>>fulfillment: >>>>>>>> >>>>>>>>1. draft-ietf-alto-deployments is in its second WGLC. The new >>>>>>>>WGLC ends >>>>>>>> on February 3, 2016. >>>>>>>> >>>>>>>>2. draft-ietf-alto-incr-update-sse appears to be moving along and >>>>>>>>there >>>>>>>> do not seem to be any stop gap issues that we are aware of. >>>>>>>>Authors, >>>>>>>> please inform the WG if there are. >>>>>>>> >>>>>>>>3. draft-ietf-alto-multi-cost is also fairly mature. >>>>>>>> >>>>>>>>It seems reasonable to move 2 and 3 ahead. >>>>>>>> >>>>>>>>Then there are a number of independent submissions dating back to >>>>>>Sep- >>>>>>>>Oct 2015 timeframe. These have not been updated and nor has >>there >>>>>>>>been much discussion on the mailing list. Some of these >>>>submissions >>>>>>>>are important for charter deliverables related to graph >>>>>>representation >>>>>>>>formats. Can the authors of the independent submissions kindly >>>>>>>>share what their plans are with respect to the drafts? >>>>>>>> >>>>>>>>This will help us gauge whether or not we should meet face-to- >>face >>>>>>>>in Buenos Aires or have an interim meeting before it and meet >>>>>>>>face-to-face in Berlin. >>>>>>>> >>>>>>>>Note that while the final plans are still up in the air and >>>>>>>>subject >>>>>>to >>>>>>>>change, there is a good chance that neither Jan or I will be able >>>>to >>>>>>>>make it to Buenos Aires. However, if a F2F meeting is desired, >>it >>>>>>>>is important to get a sense of the energy behind the independent >>>>>>>>drafts, as the list traffic has been woefully quiet on this >>front. >>>>>>>> >>>>>>>>Thanks, >>>>>>>> >>>>>>>>- vijay >>>>>>>>-- >>>>>>>>Vijay K. Gurbani, Bell Laboratories, Nokia 1960 Lucent Lane, Rm. >>>>9C- >>>>>>>>533, Naperville, Illinois 60563 (USA) >>>>>>>>Email: vkg@{bell-labs.com,acm.org} / [email protected] >>>>>>>>Web: http://ect.bell-labs.com/who/vkg/ | Calendar: >>>>>>>>http://goo.gl/x3Ogq >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>alto mailing list >>>>>>>>[email protected] >>>>>>>>https://www.ietf.org/mailman/listinfo/alto >>>>>> >>>>>>_______________________________________________ >>>>>>alto mailing list >>>>>>[email protected] >>>>>>https://www.ietf.org/mailman/listinfo/alto >> >>_______________________________________________ >>alto mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
