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
