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

[John Scudder <[e-mail]>]

Hi Giuseppe,

This generally sounds good and I look forward to reviewing the next version. One follow-up:

> 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

I do see that §10 talks about privacy considerations, securing of data collection, and so on, and that’s good. As far as I can tell it doesn’t explicitly state that the monitoring stations MUST be within the “controlled domain”, though. If it does, I’d appreciate a pointer. I bring this up because the document rests heavily on the “controlled domain” concept for its security story, and since “controlled domain” is not a well-defined term of art (RFC 8799 notwithstanding) that means any relevant attributes have to be defined within the present document.

Thanks,

—John

> On Jul 12, 2022, at 10:20 AM, Giuseppe Fioccola <[e-mail]> wrote:
> 
> 
> 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!G3SdLz5mjg5yXyOxfMdxfDPtVehdRrFlQwblDaE2oRemvIsN-xBTa0MmSZ6Xl0qXJ1eavJO3_EGh5durU-P1bmgFqQ$
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/__;!!NEt6yMaO-gk!G3SdLz5mjg5yXyOxfMdxfDPtVehdRrFlQwblDaE2oRemvIsN-xBTa0MmSZ6Xl0qXJ1eavJO3_EGh5durU-NVGdBL1w$
> 
> 
> 
> ----------------------------------------------------------------------
> 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