An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector
draft-ietf-alto-path-vector-25

[S1; question]

* I assume that all of this querying is inherently asymmetric?

  By that I mean that if an app wants to truly estimate bidirectional flow
  usage between "a" and "b" it needs to query for "a->b" and "b->a", in case
  there's some fundamental asymmetry in flow characteristics.

[S4.2.1; nit]

* s/QEB/QEP/g

Thank you for the work on this document.

Many thanks to Paul Kyzivat for his review: https://mailarchive.ietf.org/arch/msg/art/S97ViLB3YGpv2ljI9xnQGLCQYgM/ , and thanks to the authors for addressing it.

I only had time to scan the document, but did not find any major ART issues. One thing I noted is that the reference to RFC7540 should be replaced with a ref to draft-ietf-httpbis-http2bis/.

Francesca

Section 6.2.1 should be at least a sentence, perhaps:

  The Entity Domain Type is "ane".

I think Section 7.2.1 would be better expressed as:

   The media type of the multipart Filtered Cost Map resource is
   "multipart/related" and the required "type" parameter MUST have
   a value of "application/alto-costmap+json".

By constraining the type to be a specific string, you're removing the flexibility of a MIME parser to allow intervening whitespace, line wrapping, etc.

Why are the RECOMMENDEDs in 7.2.6 and 7.3.6 not REQUIRED?  Is there ever a reason to send them out-of-order?

Thanks to Samuel Weiler for the SECDIR review.

Thanks for addressing my COMMENTs and DISCUSS feedback.

I'm balloting No Objection based largely on the basis of the OpsDir review. I have never seen deployments of this, but the OpsDir reviewer is familiar and it appears that the authors have addresses his concerns...

Thank you for the work put into this document. 


Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Vijay Gurbani for the shepherd's write-up as it seems to indicate a low number of WGLC reviews.

I hope that this helps to improve the document,

Regards,

-éric

While it seems clear that knowledge of the path to some endpoints can help the applications to select the "most suitable" endpoints to connect to, I wonder whether knowledge about a single ISP will be enough. Assuming that a single ISP is the topic of this I-D as the singular form "ISP" is used rather than "ISPs".

Nothing bad of course, but I read this IETF draft more like an IRTF draft, i.e., it reads more like research and conjectures.

As only "max-reservable-bandwidth" is actually specified to this document, I wonder whether other characteristics/properties could also have been defined, e.g., max-latency, max-packet-drop, ... ?

-- Section 3 --
May I assume that the first paragraph should be removed before publication? If so, then please add a note to the RFC Editor.

-- Section 4.2.1 --
On figure 5, please use consistently "v" or "V" but not a mix. Unsure whether "f1" label (?) should be in the picture as it brings nothing.

-- Section 4.2.2 --
I find amusing to see the old telephony concept of "central office(CO)" being used in an IETF draft ;-)

== NITS ==

-- Section 1 --
Please expand IRD at first use.

-- Section 8.1 (and other places) --
Please use only lowercase in IPv6 addresses (and thank you for finally using some IPv6 examples)

A huge thanks to all involved for the quick turnaround in updating this
document and getting draft-bw-alto-cost-mode in place to help
rationalize the IANA registry situation across the ALTO documents!  I'm
sorry that my turnaround time here was not so quick.

Fortunately, I can report that the changes address my previous Discuss
concern and comments, and I have just one additional comment, in Section 6.5.2:

   The cost mode "array" indicates that every cost value in the response
   body of a (Filtered) Cost Map or an Endpoint Cost Service MUST be
   interpreted as a JSON array object.  This cost mode can be applied to
   all cost metrics.

Would it be accurate to say that "additional specifications will be
needed to clarify the semantics of the array cost mode when combined
with path metrics other than 'ane-path'"?
That is to say, I do agree that the cost mode should be applicable to
all cost metrics, but I'm not sure if the current specifications are
unambiguous about what it means to have an array of ordinal, for
example.