Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-performance-metrics-20: (with DISCUSS and COMMENT)

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 <bill.wu=40huawei.com@dmarc.ietf.org>
wrote:

> Hi, Zaheduzzaman:
> -----邮件原件-----
> 发件人: Zaheduzzaman Sarker via Datatracker [mailto:noreply@ietf.org]
> 发送时间: 2021年12月2日 19:35
> 收件人: The IESG <iesg@ietf.org>
> 抄送: draft-ietf-alto-performance-metrics@ietf.org; alto-chairs@ietf.org;
> alto@ietf.org; ietf@j-f-s.de; ietf@j-f-s.de
> 主题: 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
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>