[ippm] 1st review of RFC 8321bis

[Martin Duke <[e-mail]>]

Hello authors,

I've read through this document carefully for the first time. Having done
so, I fully support later doing the reorganization that you've proposed.
The current draft presents the information in a strange order.

I have no serious issues with the changes from 8321, but I have numerous
comments on the 8321 text that ought to be fixed before we take it to
Standard.

MAJOR COMMENTS:

- Why is RFC3393 normative if the other packet definition documents (7679,
7680) are informative? IMO they are all informative, but it should at least
be consistent.

- Sec 1. Can you clarify the relationship of this draft with
[IEEE-Network-PNPM]? Do they repeat each other, or does that one make a
different contribution to this project? If the former, who has change
control over the design?

- I'm concerned about sizing the block based on packet count. It's clearly
your less-preferred option, but including it has some implications. For
example, passive eavesdropping is much easier, as it would be
straightforward to figure out the expected number of packets and therefore
figure out the loss rate. If this wasn't a successful part of the
experiment, perhaps we should just remove it.

- sec 3.2.The guard band calculation does not seem correct to me. If D_max
-> D_min, then the guard band is simply A. But the ingress and egress nodes
still need to account for the packet delay from end to end! I would suggest

d = A + D_max.

This would also cover the reordering constraint, as the delay can be no
more than Dmax.

- sec 3.3.1 "a measurement is valid only if no packet loss occurs and if
packet misordering can be avoided". So what it's not? Do we throw out the
measurement? How can we detect packet misordering unless it delays a packet
over the edge?

- Sec 3.3.2 "The conventional [delay] range (maximum-minimum) should be
avoided". I don't know how to reconcile this with the guard band
calculation, which absolutely uses the range! Is this a valid thing to do
or not?

- Section 4. This entire section is largely a subset of section 3, and
covers the material both (a) inconsistently and (b) worse. There's a
reference to "two-way delay" which occurs nowhere else in the document.
The L considerations don't consider delay, unlike Section 3.2. 4.3 says
that "a proper interval is out off the scope of this document!" But the
document has lots to say about this! Earlier discussions led me to believe
you were going to largely get rid of Section 4; perhaps as an intermediate
step, in the next draft could we delete the text in that section that no
longer applies?

- Section 8. The most potent attack on this would appear to be on the data
collection protocol, which is out of scope. It might be good to point the
reader to some references that discuss security considerations for
gathering data.

NITS: Is there a github? There are numerous editorial cleanup issues that
would be much easier to do if I could just submit a PR.

- Abstract: delete the phrase "a method based on"

- Sec 1. s/On the other hand, performance/Performance also

- Sec 3.1 s/packet loss occurred/if packet loss occurred

- Sec 3.1.1 "some applications" are no longer "reported in section 5."
Delete the sentence.

- Sec 3.1.2 s/a couple of counters are needed/two counters are needed

- Sec 3.3.1.1 s/implicates/implies

- Update references from RFC8889 to RFC8889bis.