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

xiao.min2@zte.com.cn Mon, 07 November 2022 12:42 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 5C3ECC1524CF; Mon, 7 Nov 2022 04:42:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 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_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 DEvtNoTcIJyv; Mon, 7 Nov 2022 04:42:20 -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 F256DC1524B9; Mon, 7 Nov 2022 04:42:18 -0800 (PST)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (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 4N5W8T11cNz8RV7K; Mon, 7 Nov 2022 20:42:17 +0800 (CST)
Received: from njxapp02.zte.com.cn ([10.41.132.201]) by mse-fl1.zte.com.cn with SMTP id 2A7Cg8p8056974; Mon, 7 Nov 2022 20:42:08 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid201; Mon, 7 Nov 2022 20:42:12 +0800 (CST)
Date: Mon, 07 Nov 2022 20:42:12 +0800
X-Zmail-TransId: 2afc6368fd24ffffffffa8f5256f
X-Mailer: Zmail v1.0
Message-ID: <202211072042124575625@zte.com.cn>
In-Reply-To: <166781063036.36297.18160333094833245338@ietfa.amsl.com>
References: 166781063036.36297.18160333094833245338@ietfa.amsl.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: superuser@gmail.com
Cc: iesg@ietf.org, draft-ietf-ippm-ioam-conf-state@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 2A7Cg8p8056974
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 6368FD29.000 by FangMail milter!
X-FangMail-Envelope: 1667824937/4N5W8T11cNz8RV7K/6368FD29.000/10.5.228.132/[10.5.228.132]/mse-fl1.zte.com.cn/<xiao.min2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6368FD29.000/4N5W8T11cNz8RV7K
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/cewVdv1v4m6cdJ6uiU46xeT6Svk>
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: Mon, 07 Nov 2022 12:42:24 -0000

Hi Murray,



 


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.