Subject: [alto] Review of draft-ietf-alto-performance-metrics-02

From: Kai Gao <[email-masked]>
Date: Tue, 28 Nov 2017 10:37:19 +0800

Dear ALTO working group,

Below is a review of draft-ietf-alto-performance-metrics-02. Most of 
them are minor edits and I think section 2 could be better organized. 
Your feedback and comments are highly appreciated.

Thanks!

Regards,

Kai

============================================================

p3, table 1, last row:
missing a "]"

p3, introduction, last paragraph

"explicitly specified" -> "standard" or "ISP independent"

p4, 2nd para

"If some are subject to ... them to the client"

Could be

"For example, those that are subject to privacy concerns should not be 
provided
to unauthorized ALTO clients."

p4, figure 1

"retrieve and aggregation" -> "retrieval and aggregation"

p4, 3rd para

SHOULD -> MUST since if a metric is not announced to clients in IRD, 
it's strange to say it's "supported".

p4, 4th para

further versions -> maybe "future extensions" is better? Can we add new 
types if this document becomes standard?

as for example, ... metrics. -> such as many metrics related to 
end-to-end path bandwidth.

ALTO may convey ... capacity related measurements. -> I don't quite 
understand this part. Is it saying ALTO should provide some unified 
aggregation mechanism since these metrics cannot be provided by a single 
party?

p4, 5th para

will rapidly give up... -> SHOULD/CAN rapidly give up

sec2

I wonder if we could use "Data sources and computation of ALTO 
performance cost metrics". Many metric specifications point back to this 
section so I think it should also give guidelines or suggestions while 
talking about challenges.

The specifications are generally good but is it possible to split the 
examples a bit? There are many large blank blocks.

---

From: Qin Wu <[email-masked]>
Date: Thu, 30 Nov 2017 06:48:24 +0000

Thanks Kai for valuable review, please see my reply inline below.

-----邮件原件-----
发件人: alto [mailto:[email-masked]] 代表 Kai Gao
发送时间: 2017年11月28日 10:37
收件人: IETF ALTO
主题: [alto] Review of draft-ietf-alto-performance-metrics-02

Dear ALTO working group,

Below is a review of draft-ietf-alto-performance-metrics-02. Most of them are minor edits and I think section 2 could be better organized. 
Your feedback and comments are highly appreciated.

Thanks!

Regards,

Kai

p3, table 1, last row:
missing a "]"

[Qin]: Fixed.

[Qin]: I prefer to change it into "standard".
p4, 2nd para

Could be

"For example, those that are subject to privacy concerns should not be provided to unauthorized ALTO clients."

[Qin]:Good, accepted.
p4, figure 1

[Qin]:It is typo, fixed.
p4, 3rd para

SHOULD -> MUST since if a metric is not announced to clients in IRD, it's strange to say it's "supported".

[Qin]: Agree to change RFC2119 language into MUST.

p4, 4th para

further versions -> maybe "future extensions" is better? Can we add new types if this document becomes standard?

[Qin]: Good suggested change, I think new types should be added in the future extension rather than in this document.
I don't think we should enumerate all possible metrics in this base drafts. But definitely we should allow future extension for this base model draft.

as for example, ... metrics. -> such as many metrics related to end-to-end path bandwidth.

[Qin]: Accepted, thanks.

ALTO may convey ... capacity related measurements. -> I don't quite understand this part. Is it saying ALTO should provide some unified aggregation mechanism since these metrics cannot be provided by a single party?

[Qin]: Good catch, as I said earlier, this draft is not aimed to include all the metrics. To avoid confusion, I suggest just remove the last two sentences.
p4, 5th para

[Qin]: I prefer to change to SHOULD, thanks.

sec2

I wonder if we could use "Data sources and computation of ALTO performance cost metrics". Many metric specifications point back to this section so I think it should also give guidelines or suggestions while talking about challenges.

[Qin]: I think the guidelines or suggestions has already been provided following the challenge that is described in each paragraph. Let me know if you believe we miss anything.

The specifications are generally good but is it possible to split the examples a bit? There are many large blank blocks.

[Qin]: Good catch, we can remove these blank blocks by splitting examples.
_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto