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

[Éric Vyncke via Datatracker <[e-mail]>]

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

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 ? ;-)

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