Re: [ippm] Murray Kucherawy's No Objection on draft-ietf-ippm-rfc8889bis-03: (with COMMENT)

Giuseppe Fioccola <> Thu, 22 September 2022 10:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 568A6C159527; Thu, 22 Sep 2022 03:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 IdSkS4VWOI87; Thu, 22 Sep 2022 03:41:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE460C159526; Thu, 22 Sep 2022 03:41:38 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4MYBdB4klQz67PfY; Thu, 22 Sep 2022 18:40:30 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 22 Sep 2022 12:41:36 +0200
Received: from ([]) by ([]) with mapi id 15.01.2375.031; Thu, 22 Sep 2022 12:41:35 +0200
From: Giuseppe Fioccola <>
To: Murray Kucherawy <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Murray Kucherawy's No Objection on draft-ietf-ippm-rfc8889bis-03: (with COMMENT)
Thread-Index: AQHYzks2IbQpz8VHSU6HKkT/FrCAQa3rJ+Ig
Date: Thu, 22 Sep 2022 10:41:35 +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] Murray Kucherawy's No Objection on draft-ietf-ippm-rfc8889bis-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: Thu, 22 Sep 2022 10:41:40 -0000

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



-----Original Message-----
From: Murray Kucherawy via Datatracker <> 
Sent: Thursday, September 22, 2022 8:19 AM
To: The IESG <>
Subject: Murray Kucherawy's No Objection on draft-ietf-ippm-rfc8889bis-03: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-ippm-rfc8889bis-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:


Thanks for the work on this.  It was pretty easy to follow.

[GF]: Thanks.

In Section 5, the document suddenly starts using the term "arc".  What's an arc?

[GF]: For this purpose, we can further explain that a monitoring network can be modeled as a set of nodes and a set of directed arcs which connect pairs of nodes.

Two problems in Section 9.  The first:

      One flag: packet loss measurement MUST be done as described in
      Section 6 by applying the network clustering partition described
      in Section 5.  While delay measurement MUST be done according to
      the Mean delay calculation representative of the multipoint path,
      as described in Section 7.1.1.  Single-marking method based on the
      first/last packet of the interval cannot be applied, as mentioned
      in Section 7.2.1.

The "While delay ..." sentence seems to be incomplete.  Should it be attached
(via comma) to the sentence before it, or is there something missing here?

[GF]: I will revise the text. That sentence can be attached via comma to the sentence before or "While" can also be removed.

The same problem occurs in the next ("Two flags:") paragraph.

[GF]: Right, I will also revise it.

The second problem is the SHOULD in that same paragraph.  SHOULD presents the
implementer with a choice, and I suggest adding some prose here to explain why
one might legitimately decide to do something other than what the SHOULD says.

[GF]: There are more details later, but, I agree, it would be better to add some considerations also here.

Lastly, some nits:

In Section 5:

   In addition, it is also possible to leverage [...]

You don't need both "In addition" and "also".

[GF]: I will delete one of them.

In Section 7.2.1:

      Double marking or multiplexed marking work but only through
      statistical means.  [...]


[GF]: Ok

   If it is performed a delay measurement for more than one [...]

Suggest "If a delay measurement is performed for more than one ...".

[GF]: Ok, I will replace it.

In Section 9:

   ... there is different kind of information that can be derived.

Missing "a", I believe?

[GF]: Yes, I will add it.

      For example, to get measurements on a multipoint-paths
      basis, one flag can be used.  While, to get measurements on a
      single-packet basis, two flags are preferred.

Suggest removing "While".

[GF]: Ok, I will remove it.