Dear Kai: Thank you. I will perform a chair review of -13 as part of the shepherd writeup. Thanks, - vijay
On Thu, Nov 19, 2020 at 3:47 AM <kai...@scu.edu.cn> wrote: > Hi Jan, Vijay and Qin, > > > As we discussed in the ALTO meeting today, -12 has addressed the comments > of both Qiao and Luis but the revision proposed by Richard was not > integrated. Also, Qin mentioned that a shorter and more concise abstract is > expected. > > > I have integrated the revisions of Richard and written a new abstract as > below. Could you please take a look and see if the abstract makes sense? If > it does, I will upload -13 once the submit tool is available. > > > Thanks for the comments and looking forward to your feedback! > > > Best, > > Kai > > > ---------------------------------- > > The performance of many applications, such as large-scale data > transfers and/or mobile applications, depends on the properties of > different components of networks. Thus, such information is useful > to help clients better determine the choices of delivering traffic, > e.g., by avoiding shared bottlenecks. This document extends the base > Application-Layer Traffic Optimization (ALTO) protocol with a graph > representation format using path vectors. It 1) complements existing > path-based ALTO cost map representation with the ability to specify > components of networks for a source and a destination, and 2) uses > the ALTO property map to associate these components to their > properties. Together, this extension provides a more complete but > still abstract representation of networks for informed traffic > optimization among endpoints. > > > 2020-11-03 06:04:06"'Richard Yang'" <y...@cs.yale.edu>wrote: > > H Luis, > > Thanks a lot for the wonderful review! As we upload the revision, here is > a summary of the changes that we make. Please see inline to see if you are > OK. After you approve, we will finalize all. > > On Sun, Oct 25, 2020 at 5:01 PM LUIS MIGUEL CONTRERAS MURILLO < > luismiguel.contrerasmuri...@telefonica.com> wrote: > >> Hi all, >> >> >> >> I have performed a review of the draft, with comments as follows: >> >> >> >> /* Technical comments */ >> >> .- Section III Terminology – Path Vector bullet. Please, rephrase the >> description, it is hard to understand, especially the second sentence. Not >> clear. >> > > OLD > Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array > of ANE Names. It conveys the information that the path between a > source and a destination traverses the ANEs in the same order as > they appear in the Path Vector. > > NEW > > Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array > of ANE Names. This extension (i.e., ALTO path vector extension) > generalizes > BGP path vector, where a standard BGP path vector specifies the > sequence of > autonomous systems from a source to a destination. In this > extension, the path > vector specifies the sequence of general ANEs computed according to > a user > request. > > .- Section 4.2 – it refers to recent use cases, but it is not relevant how >> recent are the use cases (in fact, for this, see my next comment). So I >> would suggest to remove any reference to recent either in the title or the >> text. Simply refer to use cases. >> > > Very good point. We have removed the word "recent" in the title and the > text. > > > >> .- Section 4.2 – there is a reference to an expired I-D which last from >> 2013 (so pretty old). I would suggest to remove such a reference since >> somehow the potential use cases it refers should be present here. >> > > Sounds good. Yes. Removed. > > >> .- Section 5.1.3, 2nd paragraph – “… and the response must return and >> only return the selected properties …” – two comments here: (1) must should >> be MUST in this context?; (2) “… and only return …” – probably redundant, >> better either remove or rephrase as “MUST/must only return”. >> > > Good point. > > OLD > "... and the > response must return and only return the selected properties for the > ANEs in the response." > > NEW > "... and the > response MUST include and only include the selected properties > specified in the filter. " > > .- Figure 4 – the figure shows two response messages, but some questions >> arise in this respect: (1) what happens if second response is not >> received?; (2) what happens if only the second response is received? Is it >> silently discarded?; (3) is there some expected timer for accounting >> time-out in the responses? It is mentioned in bullet 2 that there could be >> some processing among messages, so it can be assumed that some maximum >> delay could happen between both responses. >> > > Good point. > > OLD > Specifically, the > Path Vector extension requires the ALTO client to include the source > and destination pairs and the requested ANE properties in a single > request, and encapsulates both Path Vectors and properties associated > with the ANEs in a single response, as shown in Figure 4. > > NEW > > Specifically, the > Path Vector extension requires that (1) the ALTO client include the > source > and destination pairs and the requested ANE properties in a single > request; (2) the ALTO server MUST return a single response with the > Path Vectors followed by the > properties associated with the ANEs in the Path Vectors, as shown in > Figure 4. > > In addition, in 5.3.3, we add the specification on the essential > completeness issue: > > OLD > 5.3.3. Order of Part Message > > NEW > 5.3.3. Order and Completeness of Part Message > > We add a sentence at the end of 5.3.3 > > The ALTO server MUST always send the complete response including both > parts. The client should check the completeness of response and > implementing a timeout mechanism to avoid hanging issues. > > > .- Section 6.2.4, last paragraph - Hard to understand, not clear. Please, >> rephrase/review. >> > > OLD > Specifically, the defining resource of ephemeral ANEs is the Property > Map part of the multipart response. The defining resource of > persistent ANEs is the Property Map on which standalone queries for > properties of persistent ANEs are made. > > NEW > Note that there are two types of ANEs (see Section 5.1.2): ephemeral > ANEs and > persistent ANEs. For ephemeral ANEs, the defining resource is the > Property > Map part of the multipart response; the defining resource of > persistent ANEs is the Property Map on which standalone queries for > properties of persistent ANEs are made. > > .- Section 6.4.2, Intended semantics text – it is not clear the >> association of persistent to ephemeral. Why is this? What is the purpose? >> > .- Section 6.4.2, last paragraph – The value of ephemeral is provided, but >> what would be the value of persistent one? >> > > It looks that we need a bit more update. We will finalize the update > shortly. > > >> .- Section 9.3, 1st and past paragraph – they seem inconsistent since in >> one hand the first claims incompatibility while the second claims >> compatibility. Please, review them. >> > > As SSE is finalized now, we will update this part shortly. > > >> .- Section 9.4 – When used with the calendar extension, should the ANE be >> always persistent? I mean, same ANE for all the time views, otherwise could >> not properly work. Please, clarify. >> > > It should. We will update. > > >> >> >> /* Editorial comments */ >> >> .- Section I Introduction, pag. 5, penultimate paragraph – “… Path Vector >> response involve two ALTO …” -> “… Path Vector response involves two >> ALTO …” >> > > Good catch. Fixed. > > >> .- Section I Introduction, pag. 5, last paragraph – “… the rest of the >> document are organized …” -> “… the rest of the document is organized …” >> > > Good catch. Fixed. > > >> .- Section III Terminology stands that the document extends the >> terminology used in RFC 7285 and in Unified Properties draft. This implies >> some precedence in the edition of the documents as RFCs, if they finally >> progress to that stage. So I would recommend to add a note for RFC Editor >> mention that precedence (note to be remove once the document becomes a >> RFC). >> > > Good idea. Unified, which is newer, should have precedence. > > >> .- Section 5.1 – the text (2nd paragraph) auto-refers to section 5.1. >> Redundant, better to remove. >> > > Fixed. > > >> .- Section 5.2 – 1st paragraph – correct -> correctly >> > > Fixed. > > >> .- Section 5.3, last sentence before Figure 4 – “… the ANEs in a single >> response …” -> “… the ANEs in an additional response …” >> > > Fixed. > > >> .- Section 6.6 – The second paragraph starts with NOTE; probably better >> to rephrase writing it as a normal paragraph. >> > > Chaned to "Note that ..." > > >> .- Section 9.2, last sentence – “compatible” -> “compatibility” >> >> >> > > Good catch. Fixed. > > Thank you so so much!! > > Richard > > >> Best regards >> >> >> >> Luis >> >> >> >> __________________________________ >> >> Luis M. Contreras >> >> >> >> Technology and Planning >> >> Transport, IP and Interconnection Networks >> >> Telefónica I+D / Global CTIO unit / Telefónica >> >> >> >> Distrito Telefónica, Edificio Sur 3, Planta 3 >> >> 28050 Madrid >> >> España / Spain >> >> >> >> Skype (Lync): +34 91 312 9084 >> >> Mobile: +34 680 947 650 >> >> luismiguel.contrerasmuri...@telefonica.com >> >> >> >> >> >> ------------------------------ >> >> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, >> puede contener información privilegiada o confidencial y es para uso >> exclusivo de la persona o entidad de destino. Si no es usted. el >> destinatario indicado, queda notificado de que la lectura, utilización, >> divulgación y/o copia sin autorización puede estar prohibida en virtud de >> la legislación vigente. Si ha recibido este mensaje por error, le rogamos >> que nos lo comunique inmediatamente por esta misma vía y proceda a su >> destrucción. >> >> The information contained in this transmission is privileged and >> confidential information intended only for the use of the individual or >> entity named above. If the reader of this message is not the intended >> recipient, you are hereby notified that any dissemination, distribution or >> copying of this communication is strictly prohibited. If you have received >> this transmission in error, do not read it. Please immediately reply to the >> sender that you have received this communication in error and then delete >> it. >> >> Esta mensagem e seus anexos se dirigem exclusivamente ao seu >> destinatário, pode conter informação privilegiada ou confidencial e é para >> uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o >> destinatário indicado, fica notificado de que a leitura, utilização, >> divulgação e/ou cópia sem autorização pode estar proibida em virtude da >> legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos >> o comunique imediatamente por esta mesma via e proceda a sua destruição >> _______________________________________________ >> alto mailing list >> alto@ietf.org >> https://www.ietf.org/mailman/listinfo/alto >> > > > -- > -- > ===================================== > | Y. Richard Yang <y...@cs.yale.edu> | > | Professor of Computer Science | > | http://www.cs.yale.edu/~yry/ | > ===================================== > >
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto