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

[Giuseppe Fioccola <[e-mail]>]

Hi John,
Thank you for your revision.
Please find my answers inline tagged as [GF].
I plan to address your comments in the next revision.

Best Regards,

Giuseppe

-----Original Message-----
From: John Scudder via Datatracker <[e-mail]> 
Sent: Monday, July 11, 2022 10:49 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: John Scudder's No Objection on draft-ietf-ippm-rfc8321bis-02: (with COMMENT)

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?

[GF]: I agree. I can replace "guarantee" with "enhance" or "optimize"

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."

[GF]: Sure. I will revise that sentence as suggested.

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.)

[GF]: I may also delete that sentence. I assumed a fixed color switching timer (e.g. 1min or 5min) and data collected every interval for a real time monitoring. But it was just an example, and, in case I keep the sentence, it is better to mention all the options and add the possibility to collect data with less frequency.

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.

[GF]: It makes sense. I can retitle the section.

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.

[GF]: Yes, I will replace that sentence with: "For security reasons, the Alternate Marking Method MUST only be applied in controlled domains."

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?

[GF]: Both, as further explained in section 10

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?

[GF]: I see your point. I can revise this sentence as follows:
"This document specifies a method to perform measurements that does not directly affect Internet security nor applications that run on the Internet."

Nits:

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

[GF]: Ok