[ippm] John Scudder's No Objection on draft-ietf-ippm-rfc8321bis-02: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-ippm-rfc8321bis-02: No Objection

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/about/groups/iesg/statements/handling-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-ippm-rfc8321bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this quite readable document.

I support Roman's DISCUSS. I also have some questions and comments:

1. In §2,

                                                   Each change of color
   represents a sort of auto-synchronization signal that guarantees the
   consistency of measurements taken by different devices along the
   path.

I realize this is fairly picky, but isn't "guarantee" over-promising? In
situations like this there's usually some low-probability chance that something
will go awry, and that does seem to be possible in this case. Presumably some
slightly weaker language like "maximizes the probability of" or similar would
be more accurate?

2. In §3.2.1,

        Since the timestamps refer to specific packets (the first packet
   of each block), we are sure that timestamps compared to compute delay
   refer to the same packets.

But two paragraphs down you explain how in real life, we are actually not sure,
because of the potential for packet loss and misordering. It might, then, be
worthwhile to correct the sentence? E.g., "... in the ideal case where no
packet loss or misordering exists, we would be sure that timestamps compared to
compute the delay refer to the same packets."

3. In §4.3, I must be missing something:

                                                          In any case,
      the NMS has to collect all the relevant values from all the
      routers within one cycle of the timer.

"Within one cycle of the timer" seems to assume that the routers don't maintain
a table of past values that can be collected at some less demanding cadence, as
long as entries aren't allowed to age out. Is there some reason that's not so?
(I'm assuming that the timer you're referring to is the fixed color switching
timer. If that's not what it is, clarification is needed here.)

4. Thank you very much for reporting results of the earlier experiment, in §7.
However, I don't understand why a section titled "Results of the Alternate
Marking Experiment" uses RFC 2119 keywords. I guess they'd make more sense if
the part that includes 2119 keywords were called something like
"Recommendations for Deployment"... or you could just retitle the section as
"Results of the Alternate Marking Experiment, with Recommendations for
Deployment" as a minimal patch.

5. In §7.1,

   For security reasons, the Alternate Marking Method is RECOMMENDED
   only for controlled domains.

Do you mean, "the Alternate Marking Method is NOT RECOMMENDED other than in
controlled domains"? Because surely you aren't saying all controlled domains
SHOULD deploy alt-mark, which is what a strict reading of this sentence,
considering the formal definition of RECOMMENDED, means.

Also, what exactly is the controlled domain supposed to control? Is it only the
scope of marked packets? Or is it also the scope of the data derived from the
marked packets?

6. In §10 I find myself bemused by,

   This document specifies a method to perform measurements in the
   context of a Service Provider's network and has not been developed to
   conduct Internet measurements, so it does not directly affect
   Internet security nor applications that run on the Internet.

The Internet is nothing other than the concatenation of many networks, many of
which are Service Provider networks, so I don't see how your premise leads to
your conclusion?

Nits:

7. In §4.2, where you write "(included)" although the meaning is clear, I think
"(inclusive)" is more standard usage.