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

[Giuseppe Fioccola <[e-mail]>]

Hi John,
Thanks for the quick reply.
Please find my answer inline tagged as [GF]

Regards,

Giuseppe

-----Original Message-----
From: John Scudder <[e-mail]> 
Sent: Tuesday, July 12, 2022 5:44 PM
To: Giuseppe Fioccola <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: John Scudder's No Objection on draft-ietf-ippm-rfc8321bis-02: (with COMMENT)

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.

[GF]: I will add a new paragraph in section 10 to better highlight the controlled domain requirement, similarly to the security considerations of draft-ietf-6man-ipv6-alt-mark.

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/sta
> tements/handling-ballot-positions/__;!!NEt6yMaO-gk!G3SdLz5mjg5yXyOxfMd
> xfDPtVehdRrFlQwblDaE2oRemvIsN-xBTa0MmSZ6Xl0qXJ1eavJO3_EGh5durU-P1bmgFq
> Q$ 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-iet
> f-ippm-rfc8321bis/__;!!NEt6yMaO-gk!G3SdLz5mjg5yXyOxfMdxfDPtVehdRrFlQwb
> lDaE2oRemvIsN-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