Re: [Gen-art] Genart last call review of draft-ietf-ippm-rfc8321bis-02

Giuseppe Fioccola <> Mon, 27 June 2022 14:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B6BCC13CD95; Mon, 27 Jun 2022 07:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FXST_bzDZL1Q; Mon, 27 Jun 2022 07:57:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE710C13CD94; Mon, 27 Jun 2022 07:57:43 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4LWrPW24qNz6H7lW; Mon, 27 Jun 2022 22:55:27 +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.24; Mon, 27 Jun 2022 16:57:41 +0200
Received: from ([]) by ([]) with mapi id 15.01.2375.024; Mon, 27 Jun 2022 16:57:41 +0200
From: Giuseppe Fioccola <>
To: Elwyn Davies <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Genart last call review of draft-ietf-ippm-rfc8321bis-02
Thread-Index: AQHYiAVqBiBaj4+0D0KaFypycrDTFq1jEuNw
Date: Mon, 27 Jun 2022 14:57:41 +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: [Gen-art] Genart last call review of draft-ietf-ippm-rfc8321bis-02
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jun 2022 14:57:48 -0000

Dear Elwyn,
Thank you for your review.
I will work on a new version to address your comments.
Please see my replies inline tagged as [GF].

Best Regards,


-----Original Message-----
From: Elwyn Davies via Datatracker <> 
Sent: Friday, June 24, 2022 10:03 PM
Subject: Genart last call review of draft-ietf-ippm-rfc8321bis-02

Reviewer: Elwyn Davies
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-ippm-rfc8321bis-02
Reviewer: Elwyn Davies
Review Date: 2022-06-24
IETF LC End Date: 2022-06-21
IESG Telechat date: 2022-07-14

Ready with a number of nits.  I found that the discussion of possible uses besides the core proposal to be somewhat distracting and perhaps detracts from the value of the basic proposal.

[GF]: Ok, I will try to revise and possibly reduce the discussion about the possible uses.

Major issues:

Minor issues:

Nits/editorial comments:
Abstract: s/It could be considered/According to the classification defined in RFC 7799, it could be considered/

[GF]: Agree

s1.1, para 1:s/overtaking./building on/; s/in the original/that was based on the original/

[GF]: Ok

s1.1, last para:  Delete.  The change log wil not be in the final document.

[GF]: Ok, will do.

s2, para 3: s/will have the same color/will have the same notional "color"/

[GF]: Ok

s3.1, para 6: s/shows how a flow looks like when it is split in traffic blocks/shows how a flow appears when it is split into traffic blocks/

[GF]: Ok

s3.1, second set of bullets:
The problem is easier to solve for multicast traffic, where load-balancing is seldom used and static joins are frequently used to force traffic forwarding and replication.

Is the term 'static joins' sufficiently well-known to not need a reference?

[GF]: Sure, a reference can be added, but I think this sentence could also be omitted to reduce the discussion of possible uses (in this case multicast traffic) besides the core proposal

s3.2.2, para1: s/statistic distribution/statistical distribution/

[GF]: Ok

s3.2.2, para2:  The term 'security time gap'  didn't seem obvious in this
section: Between packets with the second marking, there should be a security time gap to avoid out-of-order issues and also to have a number of measurement packets that are rate independent.

I suggest 'adequate time gap'.

[GF]: Yes, it makes sense.

s4.1, para2: s/ number of involved nodes/number of nodes involved/

[GF]: Ok

s7, last para:  This paragraph is not future proof.  The two drafts referenced are not working group drafts and it is not clear if they will eventually become RFCs.   I would be inclined to omit the paragraph or at least reduce it to just refer to the IEEE work.  It could also be moved to an appendix.

[GF]: Ok, I would reduce it and just refer to the IEEE work

s8, para 2: Not an academic paper!  s/We used/The mechanisms described in this document use/

[GF]: Ok, will do.

s8, bullet 5: s/strictly related each other/strictly related to each other/

[GF]: Ok

s8, bullet 7: Suggest replacing text with:
Verification: the methodology  has been tested and deployed experimentally in both lab and operational network scenarios performing packet loss and delay measurements on traffic patterns created by traffic generators together with precision test instruents and network emiulators.

[GF]: Ok, good suggestion.

s8, bullet 11:  Singleton whats????

[GF]: I will clarify. The definition of singleton comes from RFC6390.

s8, bullet 12:  "currently, the main parameter of the method is...."   Once this becomes an RFC the parameters are set in stone - 'currently' is not a good way of describing that state. Also the bullet asks about 'parameters'.  If there is just one parameter say that.  If there are others they need to be described here.

[GF]: Sure, I will simply list the parameters.