Hello Kai, Thank you for your prompt reply and your actions on the document.
Please find some further comment below, look for EV> Regards -éric On 30/11/2021, 18:01, "[email protected]" <[email protected]> wrote: Hi Éric, Thanks for the review and please see the responses inline. Best, Kai > -----Original Messages----- > From: "Éric Vyncke via Datatracker" <[email protected]> > Sent Time: 2021-11-29 18:59:54 (Monday) > To: "The IESG" <[email protected]> > Cc: [email protected], [email protected], [email protected], [email protected], [email protected] > Subject: Éric Vyncke's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT) > > Éric Vyncke has entered the following ballot position for > draft-ietf-alto-path-vector-19: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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". Yes, this document is targeting the single ISP case. For arbitrary queries, a single ISP may not have the knowledge of the full Internet paths. However, there are cases where the two endpoints are inside the same "ISP", for example, ISP-hosted CDN/edge, tenant interconnection in a single public cloud platform, SDN, etc. Some scenarios are discussed in previous ALTO sessions, including the ISP-hosted CDN service in Telefonica, and edge-assisted data transfer of Tencent (content provider) and China Telecom (ISP). Also, there are approaches that generate the path vectors from end-to-end measurement data that do not even require knowledge from an ISP. Thus, we believe this extension can still be useful. EV> this is indeed quite logical and sensible. I would suggest mentioning this in the introduction with a sentence EV> like "This document is mainly applicable when there is a single ISP between the ALTO client, ALTO server, and the content server". > > Nothing bad of course, but I read this IETF draft more like an IRTF draft, > i.e., it reads more like research and conjectures. > Fair enough. Any suggestion how we can cook more IETF gradient into the document? EV> Not really except deep rewriting > 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, ... ? > Good question. We choose these two initial properties as they are taken from use cases that we already see or are pushing forward the deployment of. Note the max-reservable-bandwidth is important to identify bottlenecks inside a network that can be crucial to determine the end-to-end reservation. But for latency and loss rate, the end-to-end result (i.e., using the base ALTO protocol) is usually sufficient to select endpoints. > -- 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. You are right. The paragraph is intended to be a note to the RFC editor and should be removed before publication. We will make this clear by changing "Note" to "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. Good catch! We will use lowercase "v" for consistency and remove "f1" in the next revision. > > -- Section 4.2.2 -- > I find amusing to see the old telephony concept of "central office(CO)" being > used in an IETF draft ;-) Indeed. But we do see the term being constantly used in literature related to edge computing (perhaps due to historical reasons that the servers are co-located with the central offices?). Actually it is taken from the [SEREDGE] document and we feel it's better to use the term as it is to avoid misunderstanding. > > == NITS == > > -- Section 1 -- > Please expand IRD at first use. Will do. > > -- Section 8.1 (and other places) -- > Please use only lowercase in IPv6 addresses (and thank you for finally using > some IPv6 examples) > > Will do. </[email protected]></[email protected]> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
