The new text looks good to me, thank you -éric
From: "[email protected]" <[email protected]> Date: Monday, 6 December 2021 at 04:34 To: Eric Vyncke <[email protected]> Cc: The IESG <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Re: Éric Vyncke's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT) Hi Éric, Thanks for the comments and please see the replies inline. Best, Kai > -----Original Messages----- > From: "Eric Vyncke (evyncke)" <[email protected]> > Sent Time: 2021-12-01 23:34:50 (Wednesday) > To: "[email protected]" <[email protected]> > Cc: "The IESG" <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" > <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: Éric Vyncke's No Objection on draft-ietf-alto-path-vector-19: > (with COMMENT) > > 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". I see the point. However, the wording might be slightly different as the restriction is mainly on the source and destination PIDs/endpoints, which may or may not be directly related to the locations of the ALTO client and server. The proposed text is as below: NEW: As a single ISP may not have the knowledge of the full Internet paths between arbitrary endpoints, this document is mainly applicable 1) when there is a single ISP between the requested source and destination PIDs or endpoints, for example, ISP-hosted CDN/edge, tenant interconnection in a single public cloud platform, etc.; or 2) when the Path Vectors are generated from end-to-end measurement data. > > > > > 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
