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. ---------------------------------------------------------------------- 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. 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. 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 4. Content-Length: TBA in the examples, I actually don't know how to interpret it. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
