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

Giuseppe Fioccola <> Fri, 26 May 2023 09:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABA93C15109F; Fri, 26 May 2023 02:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WcWl4vs-KfZI; Fri, 26 May 2023 02:00:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 750B3C151082; Fri, 26 May 2023 02:00:29 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4QSJfn3MsXz6H6hf; Fri, 26 May 2023 16:55:45 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 26 May 2023 11:00:27 +0200
Received: from ([]) by ([]) with mapi id 15.01.2507.023; Fri, 26 May 2023 11:00:27 +0200
From: Giuseppe Fioccola <>
To: Éric Vyncke <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: Éric Vyncke's Abstain on draft-ietf-ippm-explicit-flow-measurements-03: (with COMMENT)
Thread-Index: AQHZjwpigzr1SpEUr0OKA/rJlq1KM69rM6KQ
Date: Fri, 26 May 2023 09:00:26 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [ippm] Éric Vyncke's Abstain on draft-ietf-ippm-explicit-flow-measurements-03: (with COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 May 2023 09:00:33 -0000

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



-----Original Message-----
From: Éric Vyncke via Datatracker <> 
Sent: Thursday, May 25, 2023 3:11 PM
To: The IESG <>
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
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


# Éric Vyncke, INT AD, comments for

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:
(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,




## 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., and others).

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