Re: [ippm] Murray Kucherawy's No Objection on draft-ietf-ippm-ioam-conf-state-08: (with COMMENT)

xiao.min2@zte.com.cn Wed, 09 November 2022 12:12 UTC

Return-Path: <xiao.min2@zte.com.cn>
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 11884C1522A8; Wed, 9 Nov 2022 04:12:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxPfDXZwEp1c; Wed, 9 Nov 2022 04:12:48 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3F9C1524A2; Wed, 9 Nov 2022 04:12:36 -0800 (PST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4N6kPG3WW3z8QrkZ; Wed, 9 Nov 2022 20:12:34 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl2.zte.com.cn with SMTP id 2A9CCMH6051793; Wed, 9 Nov 2022 20:12:22 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Wed, 9 Nov 2022 20:12:25 +0800 (CST)
Date: Wed, 09 Nov 2022 20:12:25 +0800
X-Zmail-TransId: 2afb636b99297a4c282c
X-Mailer: Zmail v1.0
Message-ID: <202211092012255980992@zte.com.cn>
In-Reply-To: <202211081123089591409@zte.com.cn>
References: 166781063036.36297.18160333094833245338@ietfa.amsl.com, 202211072042124575625@zte.com.cn, CAL0qLwY4NU0+B4Fr=KCxL_Odh1M5uUzExXsrw3i6rVDTt08eHQ@mail.gmail.com, 202211081123089591409@zte.com.cn
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: superuser@gmail.com
Cc: draft-ietf-ippm-ioam-conf-state@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 2A9CCMH6051793
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 636B9932.000 by FangMail milter!
X-FangMail-Envelope: 1667995954/4N6kPG3WW3z8QrkZ/636B9932.000/10.5.228.133/[10.5.228.133]/mse-fl2.zte.com.cn/<xiao.min2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 636B9932.000/4N6kPG3WW3z8QrkZ
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/H8mItsPtlFsfrGKOSpYbUmJBuZ0>
Subject: Re: [ippm] Murray Kucherawy's No Objection on draft-ietf-ippm-ioam-conf-state-08: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 09 Nov 2022 12:12:52 -0000

Hi Murray,





I've posted -09 revision to address your comments on IANA section. Link as below.


https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-conf-state-09





Best Regards,


Xiao Min



Original



From: 肖敏10093570
To: MurrayS.Kucherawy <superuser@gmail.com>;
Cc: draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;
Date: 2022年11月08日 11:23
Subject: Re: Murray Kucherawy's No Objection on draft-ietf-ippm-ioam-conf-state-08: (with COMMENT)




Hi Murray,


 


Thank you very much for providing the text you want on section 5.1.


Please check inline the proposed changes on section 5.2.


 


Best Regards,


Xiao Min










From: MurrayS.Kucherawy <superuser@gmail.com>
To: 肖敏10093570;
Cc: draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;
Date: 2022年11月08日 06:11
Subject: Re: Murray Kucherawy's No Objection on draft-ietf-ippm-ioam-conf-state-08: (with COMMENT)




Hi Xiao,


On Mon, Nov 7, 2022 at 12:42 PM <xiao.min2@zte.com.cn> wrote:


Thank you for the review and thoughtful comments.
Please check inline the proposed changes that will be incorporated into the next revision.


 


Best Regards,


Xiao Min



Original


From: MurrayKucherawyviaDatatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>;
Cc: draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;ippm-chairs@ietf.org <ippm-chairs@ietf.org>;ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;
Date: 2022年11月07日 16:43
Subject: Murray Kucherawy's No Objection on draft-ietf-ippm-ioam-conf-state-08: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-ippm-ioam-conf-state-08: 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 https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-conf-state/
 
 
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
I think the two IANA registries being created in this document are
under-specified.  I suggest enumerating the fields in each entry, describing
what they're for, and what their valid values are, before providing the initial
values.  As it stands, IANA has to read other parts of the document to infer
valid values for the first column in both cases.

[XM]>>> I'm not sure I fully understand your suggestion, so let me try. Propose the changes on IANA registries as below.

OLD

 SoP Description ---- ----------- 0b00 64-bit "PktID" and 64-bit "Cumulative" data NEW

 SoP (Size of POT) Description ---- ----------- 0b00 64-bit "PktID" and 64-bit "Cumulative" data
 0b01 Reserved for future standardization
 0b01 Reserved for future standardization 
 0b11 Reserved for future standardization
OLD

 TSF Description ---- ----------- 0b00 PTP Truncated Timestamp Format 0b01 NTP 64-bit Timestamp Format 0b10 POSIX-based Timestamp Format 0b11 Reserved for future standardizationNEW

 TSF (TimeStamp Format) Description ---- ----------- 0b00 PTP Truncated Timestamp Format 0b01 NTP 64-bit Timestamp Format 0b10 POSIX-based Timestamp Format 0b11 Reserved for future standardization


I also concur with Lars' point about the limited set of available values in

each registry, but I see the latest version dealt with that.







What I have in mind for 5.1 is the following, and then 5.2 would do something similar:


OLD

5.1. IOAM SoP Capability Registry This registry defines 4 code points for the IOAM SoP Capability field for identifying the size of "PktID" and "Cumulative" data as explained in Section 4.5 of [RFC9197]. The following code points are defined in this document: SoP Description ---- ----------- 0b00 64-bit "PktID" and 64-bit "Cumulative" data 0b01 - 0b11 are available for assignment via IETF Review process as per [RFC8126].

NEW

5.1. IOAM SoP Capability Registry This registry defines 4 code points for the IOAM SoP Capability field for identifying the size of "PktID" and "Cumulative" data as explained in Section 4.5 of [RFC9197].

 A new entry in this registry requires the following fields:

 * SoP: size of POT; a two-bit binary field as defined in Section 3.2.3

 * Description: a terse description of the meaning of this SoP value

 The registry initially contains the following value:
 SoP Description ---- ----------- 0b00 64-bit "PktID" and 64-bit "Cumulative" data 0b01 - 0b11 are available for assignment via IETF Review process as per [RFC8126].
[XM-2]>>> I see. Propose the similar changes on section 5.2 as below.

OLD

5.2. IOAM TSF Capability Registry This registry defines 4 code points for the IOAM TSF Capability field of identifying the timestamp format as explained in Section 5 of [RFC9197]. The following code points are defined in this document: TSF Description ---- ----------- 0b00 PTP Truncated Timestamp Format 0b01 NTP 64-bit Timestamp Format 0b10 POSIX-based Timestamp Format 0b11 Reserved for future standardization 0b11 is available for assignment via IETF Review process as per [RFC8126].NEW

5.2. IOAM TSF Capability Registry This registry defines 4 code points for the IOAM TSF Capability field for identifying the timestamp format as explained in Section 5 of [RFC9197].

 A new entry in this registry requires the following fields: * TSF: timestamp format; a two-bit binary field as defined in Section 3.2.4 * Description: a terse description of the meaning of this TSF value The registry initially contains the following values: TSF Description ---- ----------- 0b00 PTP Truncated Timestamp Format 0b01 NTP 64-bit Timestamp Format 0b10 POSIX-based Timestamp Format 0b11 is available for assignment via IETF Review process as per [RFC8126].