Thanks for the updates. I however, didn’t notice the change in section 2.2 egarding JSON number format, which previously was agreed to be changed, in the 25th of this document.
//Zahed > On 28 Feb 2022, at 22:14, Y. Richard Yang <[email protected]> wrote: > > Hi Zaheduzzaman, > > We have posted the latest version of the document: > https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-24 > <https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-24> > > Could you please take a look to see if all of your comments are addressed? In > particular, > - We checked and made sure that the normative references are correct. > - We updated the abstract to clarify the wording and added sentences in Sec. > 1 on the uses. > - We revised the final wording of 2.2 on the number format > - We checked all json examples and fixed the issues. > > Please take a look and let us know if there are remaining issues to be > addressed. > > Thank you so much! > Richard > > On Thu, Dec 2, 2021 at 8:32 AM Qin Wu <[email protected] > <mailto:[email protected]>> wrote: > Hi, Zaheduzzaman: > -----邮件原件----- > 发件人: Zaheduzzaman Sarker via Datatracker [mailto:[email protected] > <mailto:[email protected]>] > 发送时间: 2021年12月2日 19:35 > 收件人: The IESG <[email protected] <mailto:[email protected]>> > 抄送: [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]>; [email protected] <mailto:[email protected]> > 主题: Zaheduzzaman Sarker's Discuss on draft-ietf-alto-performance-metrics-20: > (with DISCUSS and COMMENT) > > Zaheduzzaman Sarker has entered the following ballot position for > draft-ietf-alto-performance-metrics-20: 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/ > <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/ > <https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/> > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I perhaps understand the intention of extending the ALTO protocol so that the > ALTO client and server have defined way of exchanging values for already > defined metrics. However, I need to agree with my fellow AD colleagues that > this document need to describe why those metrics are needed and describe the > relationship with other RFCs those defines those metrics mostly for other > contexts. To that end all the RFCs in the Table 1 in section 1 need to be > normative references. > > [Qin Wu] I think the key use case is defined in RFC7752 section 2.2, i.e., > export BGP-LS collected topology data to ALTO server and the ALTO server > expose data to the client. RFC8571 provides additional performance metric > related data which is part of topology data. Most of performance cost metrics > derived from metrics defined in RFC8571. > Another two relevant use cases are documented in section 3 of > draft-xie-alto-lmap-00, one is targeted to network operators who need to > understand the performance of their networks, the performance of the > suppliers (downstream and upstream networks), the performance of Internet > access services, and the impact that such performance has on the experience > of their customers. > The other is targeted to regulators who want to evaluate the performance of > the network services offered by operators. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the work on this document and thanks to Brian Trammell for his > TSVART early review. > > I have following comments which I believe will improve the document quality - > > 1. In the abstract I read about "a better delay performance" and was hoping > it will be clear to me what is "a better delay performance". Unfortunately, I > was unable to get that. This comes to the point that this document needs to > describe why purpose of using the defined metrics well. > [Qin Wu] See clarification above. > > 2. Section 2.2 says > > The number MUST be a non-negative JSON integer in the range [0, 100] > (i.e., > greater than or equal to 0 and less than or equal to 100), followed by an > optional decimal part, if a higher precision is needed. > > This should be a JSON number type not integer type. > [Qin Wu] See clarification to Ben's comments. The format of percentile is > integer number followed by optional decimal part starting with the '.' > separator. > 3. There are number of broken JSON examples. for example, in section 4.2.3 > "ipv4:192.0.2.2" { > "ipv4:192.0.2.89" : 0, > "ipv4:198.51.100.34": 2000 > } > missing ":" after ipv4:192.0.2.2 > [Qin Wu] Agree to fix this. > 4. Content-Length: TBA in the examples, I actually don't know how to > interpret it. > > [Qin Wu] Agree to fix this. > > _______________________________________________ > alto mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/alto > <https://www.ietf.org/mailman/listinfo/alto> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
