[Ballot comment]
- Please address the OPS-DIR review by Bert Wijnen

The one thing that concerns me a little bit is the fact that this
document uses RFC2119 language. I think that is in-appropriate.
Using lower case for the MUST, SHOULD and RECOMMEND in the document
is perfectly fine I think.

- Support Adrian's comment regarding the title "Reporting IP Network Performance Metrics: Different Points of View"

- Next to the question "How will the results be used?", it would have been nice to ask the question "Which audience will read the results"
Network Characterization = network operator
Application Performance Estimation = application designer, service developer, etc..
Actually, this is what you did, without clearly mentioning it, asking the question about "how", and answering with "two main audience categories"

-

2. Application Performance Estimation - describes the network
conditions in a way that facilitates determining affects on user
applications, and ultimately the users themselves. This point-
of-view looks outward, toward the user(s), accepting the network
as-is.

What do you mean "accepting the network as-is."?
It's not because the results will be used for application performance estimation that you can't optimize your network.

- "The scope of this memo primarily covers the design and reporting of
the loss and delay metrics [RFC2680] [RFC2679]."

What do you mean by design of metric? Do you mean choosing the measurement characteristics of a metric?
Note: multiple occurrences of "metric design" in the draft.

- Section 2
"These memos effectively describe two
different categories of metrics,

o [RFC3148] includes restrictions of congestion control and the
notion of unique data bits delivered, and

o [RFC5136] using a definition of raw capacity without the
restrictions of data uniqueness or congestion-awareness.

It might seem at first glance that each of these metrics has an
obvious audience (Raw = Network Characterization, Restricted =
Application Performance), but reality is more complex and consistent
with the overall topic of capacity measurement and reporting. For
example, TCP is usually used in Restricted capacity measurement
methods, while UDP appears in Raw capacity measurement. "

I was not sure what you meant by Raw and Restricted.

However, I saw a definition way down in the document, in section 6 and 7
Raw capacity refers to the metrics defined in [RFC5136] which do not
include restrictions such as data uniqueness or flow-control response
to congestion...

Restricted capacity refers to the metrics defined in [RFC3148] which
include criteria of data uniqueness or flow-control response to
congestion...

Please add those "definitions" in section 2.
It's specifically important since RFC5136 and RFC3148 don't mention Raw/Restricted

- I learned to avoid "we", "our", "us" in RFCs.
I double-checked if it's still the case with the RFC-editor. I will let you know the answer.

- I would add an extra point to "For these and other reasons, such as"
Something such as:

o the ability to drill down to a specific measurement interval for deeper analysis

Justification: most of the time, when checking SLA, we check with large measurement interval, but want to ability to do a postmortem analysis

- I don't understand
"Fortunately, application performance estimation activities are not
adversely affected by the estimated worst-case transfer time.
Although the designer's tendency might be to set the Loss Threshold
at a value equivalent to a particular application's threshold, this
specific threshold can be applied when post-processing the
measurements. "

- "We can say that the Delay and Loss metrics are Orthogonal"
Orthogonal -> orthogonal?

- section 7.4. Bulk Transfer Capacity Reporting

When BTC of a link or path is estimated through some measurement
technique, the following parameters SHOULD be reported:

Also transport type, link layer type, tunneling yes/no, etc...?

- Personal preference, no need to modify the document unless you feel like it.
All my customers are interested in delay, loss, and delay variation (jitter).
It would have been nice to have a clear pointer in the table of content, with a clear entry "Effect of POV on the Delay Variation Metric . . . . . . . . . . . . . ." instead of addressing delay variation in "delay metric" section 5.1.3

-

Section 4.1 of [RFC3393] describes this specification and its
rationale (ipdv = inter-packet delay variation in the quote below).
Use IPDV (Remember you used Packet Delay Variation (PDV)) in the document, and refer to RFC5481
Several ipdv instances in the draft.

-

"Network Characterization has traditionally used Poisson-distributed
inter-packet spacing, as this provides an unbiased sample."

Is this correct? or Poisson-distributed start, with fixed inter-packet spacing, to match, for example, a voice/video application