Re: [ippm] RFC8321bis and 8889bis

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Tue, 07 September 2021 10:15 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BAF3A18D4 for <ippm@ietfa.amsl.com>; Tue, 7 Sep 2021 03:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXB5Ndjv5unV for <ippm@ietfa.amsl.com>; Tue, 7 Sep 2021 03:15:21 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C365E3A18D2 for <ippm@ietf.org>; Tue, 7 Sep 2021 03:15:20 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4H3h1B2pyrz67x87; Tue, 7 Sep 2021 18:13:18 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Tue, 7 Sep 2021 12:15:17 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.008; Tue, 7 Sep 2021 12:15:17 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: tom petch <ietfa@btconnect.com>, Martin Duke <martin.h.duke@gmail.com>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] RFC8321bis and 8889bis
Thread-Index: AQHXoNyJrgu91InVX06THGAJcAf2WKuTddsggAAlFACAAlTb8IACM0KAgAAiwyA=
Date: Tue, 07 Sep 2021 10:15:17 +0000
Message-ID: <ae685c71e5e4447f9bcb9f54619f3c13@huawei.com>
References: <CAM4esxRP=bp7LyQZ1_B5_hcjYgFs5bFnuKm-keWp5yDS_X7Lxg@mail.gmail.com> <47ed2045398f48579a5251b40dabfceb@huawei.com> <AM6PR07MB5544B7C40EDE41996F08D647A2D09@AM6PR07MB5544.eurprd07.prod.outlook.com> <762ca8b9ca6e449a9f174d3df452feda@huawei.com> <DB7PR07MB55465C8489197A98AE69AAB8A2D39@DB7PR07MB5546.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB55465C8489197A98AE69AAB8A2D39@DB7PR07MB5546.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.81.125]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/V8bXscxWAkJq7vnE8EFHUQAAs50>
Subject: Re: [ippm] RFC8321bis and 8889bis
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2021 10:15:27 -0000

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.

Regards,

Giuseppe


-----Original Message-----
From: tom petch <ietfa@btconnect.com> 
Sent: Tuesday, September 7, 2021 10:34 AM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; Martin Duke <martin.h.duke@gmail.com>; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] RFC8321bis and 8889bis

From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
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.

<tp>
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

Regards,

Giuseppe

-----Original Message-----
From: tom petch <ietfa@btconnect.com>
Sent: Saturday, September 4, 2021 1:22 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; Martin Duke <martin.h.duke@gmail.com>; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] RFC8321bis and 8889bis

From: ippm <ippm-bounces@ietf.org> on behalf of Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
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?

<tp>

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.

Regards,

Giuseppe


From: ippm <ippm-bounces@ietf.org> On Behalf Of Martin Duke
Sent: Friday, September 3, 2021 5:55 PM
To: IETF IPPM WG <ippm@ietf.org>
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!
Thanks
Martin