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

[[e-mail]]

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



Original



From: MurrayS.Kucherawy <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
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 <[e-mail]> 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 <[e-mail]>
To: The IESG <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
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].