Skip to main content

An ALTO Extension: Path Vector
draft-ietf-alto-path-vector-25

Yes

Martin Duke

No Objection

John Scudder
Robert Wilton
(Martin Vigoureux)

Abstain


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

Martin Duke Yes

Erik Kline No Objection

Comment (2021-12-01 for -19)
[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)
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

John Scudder No Objection

Murray Kucherawy No Objection

Comment (2021-12-05 for -19)
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?

Robert Wilton No Objection

Roman Danyliw (was Discuss) No Objection

Comment (2022-02-02 for -21)
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)
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)
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)

Zaheduzzaman Sarker Abstain

Comment (2021-12-02 for -19)
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.

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (2022-03-19 for -24)
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.

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -19)