Skip to main content

An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector


(Martin Duke)

No Objection

John Scudder
(Martin Vigoureux)
(Robert Wilton)


Note: This ballot was opened for revision 19 and is now closed.

Erik Kline
No Objection
Comment (2021-12-01 for -19) Sent
[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
Francesca Palombini
No Objection
Comment (2021-12-02 for -19) Sent
Thank you for the work on this document.

Many thanks to Paul Kyzivat for his review: , 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/.

John Scudder
No Objection
Murray Kucherawy
No Objection
Comment (2021-12-05 for -19) Sent
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?
Roman Danyliw
(was Discuss) No Objection
Comment (2022-02-02 for -21) Sent for earlier
Thanks to Samuel Weiler for the SECDIR review.

Thanks for addressing my COMMENTs and DISCUSS feedback.
Warren Kumari
No Objection
Comment (2021-12-01 for -19) Not sent
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...
Éric Vyncke
No Objection
Comment (2021-11-29 for -19) Sent
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,



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)
Zaheduzzaman Sarker
Comment (2021-12-02 for -19) Not sent
I am struggling with the fact that even if obfuscated path vector provides more information about network and that the network operators need to be extra careful about providing those information. And draft is actually saying that the ISPs will not share details information. Hence, I am confused about the usability of this protocol but don't want to stand in front of it for being published.
Martin Duke Former IESG member
Yes (for -19) Unknown

Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2022-03-19 for -24) Sent for earlier
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
Martin Vigoureux Former IESG member
No Objection
No Objection (for -19) Not sent

Robert Wilton Former IESG member
No Objection
No Objection (for -19) Not sent