Re: [ippm] RFC8321bis and 8889bis

Giuseppe Fioccola <> Wed, 08 September 2021 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 871163A27F8 for <>; Wed, 8 Sep 2021 06:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d8pBmTiXWTsE for <>; Wed, 8 Sep 2021 06:15:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 405A03A27F7 for <>; Wed, 8 Sep 2021 06:15:27 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4H4Myg5bhzz67g00; Wed, 8 Sep 2021 21:13:31 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 8 Sep 2021 15:15:23 +0200
Received: from ([]) by ([]) with mapi id 15.01.2308.008; Wed, 8 Sep 2021 15:15:23 +0200
From: Giuseppe Fioccola <>
To: tom petch <>, Martin Duke <>, IETF IPPM WG <>
Thread-Topic: [ippm] RFC8321bis and 8889bis
Thread-Index: AQHXoNyJrgu91InVX06THGAJcAf2WKuTddsggAAlFACAAlTb8IACM0KAgAAiwyCAAWcqAIAAd/Xw
Date: Wed, 8 Sep 2021 13:15:22 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [ippm] RFC8321bis and 8889bis
X-Mailman-Version: 2.1.29
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, 08 Sep 2021 13:15:33 -0000

Hi Tom,
It is a good suggestion. We can definitely make a summary of the experiment and therefore highlight the few parts of the RFC that are not carried forward.



-----Original Message-----
From: tom petch <> 
Sent: Wednesday, September 8, 2021 10:04 AM
To: Giuseppe Fioccola <>om>; Martin Duke <>om>; IETF IPPM WG <>
Subject: Re: [ippm] RFC8321bis and 8889bis

From: Giuseppe Fioccola <>
Sent: 07 September 2021 11:15

Hi Tom,
Yes, that's exactly the plan.
Regarding RFC8321, the first four sections will remain almost unchanged, while the subsequent sections (5, 6, 7) need some modifications.
Besides, RFC8889 does not define new bits but it basically describes the general way of aggregating counters and timestamps for multipoint unicast flows in order to allow flexible monitoring. This can be kept in the same document or can be separated, depending on the debate.


For me, I would keep the documents separate.  I see it as more straightforward, less likely to introduce errors which, as I said before, are often what determines how long something takes. 

Also, I think that any ...bis should include a section on the changes from the RFC, especially here as it is likely that parts of the RFC are not carried forward.  It might be tempting to put these parts in an Informative Appendix but, for me, that would give them too much weight and a summary of what has been removed would be better IMHO.

Tom Petch


-----Original Message-----
From: tom petch <>
Sent: Tuesday, September 7, 2021 10:34 AM
To: Giuseppe Fioccola <>om>; Martin Duke <>om>; IETF IPPM WG <>
Subject: Re: [ippm] RFC8321bis and 8889bis

From: Giuseppe Fioccola <>
Sent: 05 September 2021 22:53

Hi Tom, All,
Note that, in this specific case, the new I-D will not add nothing more to the original RFC 8321 and RFC 8889. It will elevate Alternate Marking to Proposed Standard by picking only the deployed methods from the two RFCs. Therefore, it will be reused most of the text and omitted the parts related to the experiment.
For this reason, I'm just trying to figure out what can be the fastest way to progress.
Probably Martin, Ian and Tommy could give important advices here.

The fastest way is the one that makes the fewest mistakes:-)

I see very little in RC8321 that is about an experiment. and what there is will mostly vanish when the Category is changed.
   Rather the key part I see is going through sections 5, 6, and 7 and removing the parts that are not ready to be elevated to Standards Track.  I think that the most reliable way to do that is to start with RFC8321, change the Category and then review those three sections to see what can be kept, what must go.  That is where the WG comes in, rather than AD or WG Chairs,  to give consensus to that IMHO.  Some of this has happened already in the posts in support of this status change but I think we need that 8321bis to work from and make it formal.

Tom Petch



-----Original Message-----
From: tom petch <>
Sent: Saturday, September 4, 2021 1:22 PM
To: Giuseppe Fioccola <>om>; Martin Duke <>om>; IETF IPPM WG <>
Subject: Re: [ippm] RFC8321bis and 8889bis

From: ippm <> on behalf of Giuseppe Fioccola <>
Sent: 04 September 2021 08:08

Hi Martin, All,
I can surely start working on a bis document and lead it together with those who already expressed interest.
I'm just wondering if the new I-D on RFC8321bis and RFC8889bis can be submitted directly to IESG as individual submission with the help of a sponsoring AD or as IPPM WG document.
What's your thought?


Two WG documents.  Anything else creates more work for an AD and may lead to procedural  issues - e.g. lack of IETF consensus - at a later date.

Tom Petch
an interested bystander.



From: ippm <> On Behalf Of Martin Duke
Sent: Friday, September 3, 2021 5:55 PM
Subject: [ippm] RFC8321bis and 8889bis

Hello IPPM,

Last Call on the status change still has some way to run, but there is already quite a bit of resistance to doing this without a bis document.

Consider this a formal invitation to get the process started. A bis document should eliminate both experiment-related boilerplate, and any bits of the design that we don't feel are mature enough for Proposed Standard.

Submit a -00!