Re: [alto] Review of draft-ietf-alto-path-vector-11

[Vijay Gurbani <[e-mail]>]

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 <[e-mail]> 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'" <[e-mail]>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 <
> [e-mail]> 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): [phone]
>>
>> Mobile: [phone]
>>
>> [e-mail]
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>>
>
>
> --
> --
>  =====================================
> | Y. Richard Yang <[e-mail]>   |
> | Professor of Computer Science       |
> | http://www.cs.yale.edu/~yry/        |
>  =====================================
>
>