Re: [ippm] Roman Danyliw's No Objection on draft-ietf-ippm-explicit-flow-measurements-03: (with COMMENT)

Giuseppe Fioccola <> Wed, 24 May 2023 12:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF498C13AE3F; Wed, 24 May 2023 05:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VRUQKwTPyxUg; Wed, 24 May 2023 05:06:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C090FC14CE3B; Wed, 24 May 2023 05:06:25 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4QR8y5185rz67fBs; Wed, 24 May 2023 20:05:01 +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; Wed, 24 May 2023 14:06:23 +0200
Received: from ([]) by ([]) with mapi id 15.01.2507.023; Wed, 24 May 2023 14:06:23 +0200
From: Giuseppe Fioccola <>
To: Roman Danyliw <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-ippm-explicit-flow-measurements-03: (with COMMENT)
Thread-Index: AQHZjeMkuqDjp2ZfyUG5xCrUkoWF9a9pULkg
Date: Wed, 24 May 2023 12:06:22 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [ippm] Roman Danyliw's No Objection 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: Wed, 24 May 2023 12:06:30 -0000

Hi Roman,
Thank you for the review.
Please find my replies inline tagged as [GF].



-----Original Message-----
From: Roman Danyliw via Datatracker <> 
Sent: Wednesday, May 24, 2023 3:58 AM
To: The IESG <>
Subject: Roman Danyliw's No Objection on draft-ietf-ippm-explicit-flow-measurements-03: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-ippm-explicit-flow-measurements-03: 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
for more information about how to handle DISCUSS and COMMENT positions.

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


Thank you to Steve Hanna for the SECDIR review.

** Certain documents previously published out of IPPM were only intended for
closed deployments (sometimes called “limited domains”).  Are the approaches
described in this document intended for the Internet?  It would be helpful to
state the applicability.

[GF]: The methods described in this document are transport agnostic and potentially applicable to any transport-layer protocol, especially valuable for encrypted protocols. In theory, these methods can be applied to both limited domains and Internet, depending on the specific protocol application. I will add this consideration in the next version of the draft.

** Section 6.  Given that Section 7 reminds the reader that “[a]uthentication
techniques may be used where appropriate to guard against these traffic
attacks”, what would that mean in the context of QUIC and TCP?

[GF]: This is a general statement. It may not be valid for QUIC since in that case the scope of the measurements should be to make performance information directly visible to the path.

** Section 7.  It appears that these measurement fields introduced in the
packet are intended only for the sender and recipient with little information
to any intermediaries.  This seems like a recipe for a covert channel not
inspected by typical security devices.  Consider noting this possibility.

[GF]: Ok, we will add a consideration about the possibility of a covert channel in the next version.