Re: [ippm] WG adoption call for RFC8321bis and 8889bis Mon, 18 April 2022 06:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D3983A20B6 for <>; Sun, 17 Apr 2022 23:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kQ3mvwsLvSN8 for <>; Sun, 17 Apr 2022 23:53:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 992603A20B1 for <>; Sun, 17 Apr 2022 23:53:56 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4Khd290rqKz528MJ; Mon, 18 Apr 2022 14:53:53 +0800 (CST)
Received: from ([]) by with SMTP id 23I6rlJu025581; Mon, 18 Apr 2022 14:53:47 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Mon, 18 Apr 2022 14:53:46 +0800 (CST)
Date: Mon, 18 Apr 2022 14:53:46 +0800
X-Zmail-TransId: 2afb625d0afaffffffffe8f-01957
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-MAIL: 23I6rlJu025581
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04- with ID 625D0B01.000 by FangMail milter!
X-FangMail-Envelope: 1650264833/4Khd290rqKz528MJ/625D0B01.000/[]/<>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 625D0B01.000/4Khd290rqKz528MJ
Archived-At: <>
Subject: Re: [ippm] WG adoption call for 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: Mon, 18 Apr 2022 06:54:01 -0000

Hi all,

I support wg adoption of RFC8321bis.
I have no opinion on RFC8889bis because I don't know any implementation of it.

At the same time, I reserve my opinion on reducing the implementation options specified by this document, because IMHO that's a burden to the vendor, operator or even the general reader.
- In section 3.1, two implementation options "flow-based" and "link-based" are provided, I know only "flow-based" implementation.
- In section 3.2, three implementation options "single-marking methodology", "mean delay" and "double-marking methodology" are provided, I know only "double-marking methodology" implementation.

Best Regards,
Xiao Min

日 期 :2022年04月08日 08:04
主 题 :[ippm] WG adoption call for RFC8321bis and 8889bis
ippm mailing list

Hello IPPM,
This email starts an adoption call for draft-fioccola-rfc8321bis and draft-fioccola-rfc8889bis. Please see Martin’s emails below for details — the main idea here is that we’re moving two IPPM RFCs from Experimental to Proposed Standard.
The chairs would like to have a short amount of time spent in the WG processing these documents. If we adopt, we’d plan to very shortly thereafter do a working group last call.
Please reply to this email by Thursday, April 21 and indicate if you support adopting this document.
Tommy & MarcusOn Apr 7, 2022, at 1:16 PM, Martin Duke <> wrote:
Hello IPPM,
You may recall that there was a need to progress RFC8321 and RFC8889 from Experimental to Proposed Standard. There was a feeling that the update would be trivial and we could therefore do it as an AD sponsored document.
I've done 3 rounds of AD review and I've seen the need to substantially adjust the scope of these documents and tweak the design in places. The changes are not revolutionary, but I'm a non-practitioner and have driven some design changes with minimal review. At this point I think it's important to get good IPPM review; if we're going to do that anyway, we might as well do the (expedited) working group process so that there's no confusion as to why IPPM didn't formally review an update to its own documents.
So, as first step, I invite the working group to adopt these two drafts:
Any objections to adoption, as always, should be to the value of doing the work at all, and the general direction of the drafts. I hope to follow up the adoption call with an immediate WGLC to shake out any detailed objections, though we will take as long as we need to address concerns that people have.
I invite you to consult the changelogs on both of these documents, which are not long, to get a sense of what we've done.
For those of you who like diffs, there was a big reorganization between draft-02 and -03 that is hard to follow in a diff. So here is a set of diffs that exclude the -02 to -03 transition:
I believe it's up to the chairs to start the adoption call. If people are good about reading the document during WGLC, I would like to think we could be done before IETF 114.
Your friendly Area Director,
_______________________________________________ippm mailing listippm@ietf.org