Hi Eric, Martin, all, The authors agree that 8312bis should be a normative reference, and it is in -v22, which we will upload soon.
Thanks, Richard On Tue, Dec 21, 2021 at 8:52 AM Qin Wu <[email protected]> wrote: > I agree with Martin, 8312bis should be listed as normative reference. We > will correct this in v-22. > > > > -Qin > > *发件人:* alto [mailto:[email protected]] *代表 *Martin Duke > *发送时间:* 2021年12月20日 23:27 > *收件人:* Eric Vyncke (evyncke) <[email protected]> > *抄送:* alto-chairs <[email protected]>; > [email protected]; The IESG <[email protected]>; > IETF ALTO <[email protected]> > *主题:* Re: [alto] Éric Vyncke's Discuss on > draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT) > > > > Authors, > > > > 8312bis is still in the informational references; is this an oversight, or > are you arguing that it's not normative? > > > > On Mon, Nov 22, 2021 at 8:39 AM Martin Duke <[email protected]> > wrote: > > Good catch! > > > > I'm not sure that either of these references are actually directly > relevant to the subject, though I'm happy to be convinced otherwise. > > > > It might be that one of the IPPM docs (RFC 8337?) might be a better fit. > > > > If RFC 8312 is the right answer, 8312bis is almost done and they can > simply update to avoid the downref. > > > > Martin > > > > On Mon, Nov 22, 2021 at 7:54 AM Eric Vyncke (evyncke) <[email protected]> > wrote: > > Martin, > > > > The text in § 4.1.3 says: > > Intended Semantics: To give the throughput of a TCP congestion- > > control conforming flow from the specified source to the specified > > destination; see [RFC3649, Section 5.1 of RFC8312 > <https://datatracker.ietf.org/doc/html/rfc8312#section-5.1>] on how TCP > > throughput is estimated. The spatial aggregation level is specified > > in the query context (e.g., PID to PID, or endpoint to endpoint). > > > > So, it is RFC 8312 in the text, RFC 8312 is vaguely related to TCP > bandwidth > > > > -éric > > > > *From: *Martin Duke <[email protected]> > *Date: *Monday, 22 November 2021 at 16:40 > *To: *Eric Vyncke <[email protected]> > *Cc: *The IESG <[email protected]>, alto-chairs <[email protected]>, " > [email protected]" < > [email protected]>, IETF ALTO <[email protected]>, > Jan Seedorf <[email protected]> > *Subject: *Re: Éric Vyncke's Discuss on > draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT) > > > > Thanks Eric, > > > > I think you mean RFC 8321? I am in the early stages of AD sponsoring a > draft to update that to PS. The authors have the choice of doing a downref > or referring to 8321bis and being stuck in the RFCEd queue for a few extra > months. > > > > On Mon, Nov 22, 2021 at 3:32 AM Éric Vyncke via Datatracker < > [email protected]> wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-alto-performance-metrics-19: Discuss > > 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-performance-metrics/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. Please bear with my lack of > knowledge about ALTO in general. > > Please find below one trivial blocking DISCUSS points (probably easy to > address), some non-blocking COMMENT points (but replies would be > appreciated > even if only for my own education), and some nits. > > Special thanks to Jan Seedorf for the shepherd's write-up about the WG > consensus (even if not using the usual template). > > I have appreciated the "operational considerations" section as it addresses > many questions that popped up during reading the document; notably, how > can the > ALTO server measure any metric between the ALTO client and a resource. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == DISCUSS == > > -- Section 4.1.3 -- > A very trivial DISCUSS to fix: this document relies on RFC 8312 to specify > how > TCP throughput is estimated but RFC 8312 does not appear in the normative > reference list (this will probably generate a down ref though). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > == COMMENTS == > > Minor regret about the examples as they are all about the IPv4 address > family > especially in a world of happy eyeballs where the IPv4 and IPv6 paths may > still > have different performance metrics. > > -- Section 2.1 -- > Should the figure 1 use "perf monitoring tools" rather than "management > tool" ? > > -- Section 4 -- > This section title is about 'bandwidth' but the first sub-section is about > 'throughput', while these concepts are related they are also distinct. How > can > the reader reconciliate them ? > > -- Section 4.1 -- > Is the intent of ALTO to only work for TCP and not for other transport > protocols ? I.e., is QUIC out of scope ? > > -- Section 4.2.3 -- > Where are those 'tunnels' in "by subtracting tunnel reservations " coming > from > ? Probably about RSVP-TE but what is the link with ALTO ? (Again I am not > familiar with ALTO so this may be an uneducated question). > > == NITS == > > -- Section 3.1.3 -- > Probably tedious to do but why not replacing "TBA" by the actual value in > the > examples for 'content-length' ? > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
