Hi Zaheduzzaman, We have posted the latest version of the document: 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]> wrote: > Hi, Zaheduzzaman: > -----邮件原件----- > 发件人: Zaheduzzaman Sarker via Datatracker [mailto:[email protected]] > 发送时间: 2021年12月2日 19:35 > 收件人: The IESG <[email protected]> > 抄送: [email protected]; [email protected]; > [email protected]; [email protected]; [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/ > 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: > ---------------------------------------------------------------------- > > 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] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
