Re: [ippm] Éric Vyncke's Abstain on draft-ietf-ippm-explicit-flow-measurements-03: (with COMMENT)

[Giuseppe Fioccola <[e-mail]>]

Hi Eric,
Thank you for the feedback.
Please see inline [GF].

Regards,

Giuseppe

-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]> 
Sent: Thursday, May 25, 2023 3:11 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Éric Vyncke's Abstain on draft-ietf-ippm-explicit-flow-measurements-03: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-ippm-explicit-flow-measurements-03: Abstain

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-explicit-flow-measurements/



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

# Éric Vyncke, INT AD, comments for
draft-ietf-ippm-explicit-flow-measurements-03

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

I strongly support Jim Guichard's original DISCUSS point on squatting on bits
that may be used by the network. I read the follow-up email conversation and
then I now wonder what it the point of publishing this I-D as a RFC *in the
IETF stream* (as opposed to the *IRTF stream*) to describe a potential plan.
Hence, my current ABSTAIN ballot about the stream selection.

[GF]: I see your point. For this draft, we are following an approach similar to RFC8321/RFC8889, which were elevated to standards-track when the methods were consolidated. Indeed, as informational document, it aims to define transport agnostic methodologies that can theoretically be applicable to different transport-layer protocols.

Other thanks to Pascal Thubert, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-ippm-explicit-flow-measurements-03-intdir-telechat-thubert-2023-05-11/
(and I have seen the email exchange with Giuseppe)

Special thanks to Marcus Ihlar for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status (and the
explanation for 8 authors)

I hope that this review helps to improve the document and possibly trigger a
change of stream,

Regards,

-éric

# COMMENTS

## Section 1

`can be prevented because of the encrypted transport-layer headers (e.g. QUIC,
TCP)` since when TCP is encrypted ? ;-)

[GF]: Of course, we will revise, we meant TCP with TLS.

## Section 8

While it is not really related to privacy, if there is some experimental
traffic over an ISP network with those bit sets, the ISP could put this marked
traffic in a priority queue to deliver a better service and so 'cheat' on an
experiment that would benchmark ISP (e.g., speedtest.net and others).

[GF]: This is a good point. We can mention it.