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

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 07 November 2022 22:11 UTC

MIME-Version: 1.0
References: <166781063036.36297.18160333094833245338@ietfa.amsl.com> <202211072042124575625@zte.com.cn>
In-Reply-To: <202211072042124575625@zte.com.cn>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Mon, 07 Nov 2022 22:11:29 +0000
Message-ID: <CAL0qLwY4NU0+B4Fr=KCxL_Odh1M5uUzExXsrw3i6rVDTt08eHQ@mail.gmail.com>
To: xiao.min2@zte.com.cn
Cc: draft-ietf-ippm-ioam-conf-state@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com
Content-Type: multipart/alternative; boundary="0000000000003ed71705ece8b59e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/2yBNOQz9EQMTzDwqRACFq6PnH6s>
Subject: Re: [ippm] Murray Kucherawy's No Objection on draft-ietf-ippm-ioam-conf-state-08: (with COMMENT)
Precedence: list

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 standardization
>
> NEW
>
>       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].

[ippm] Murray Kucherawy's No Objection on draft-i… Murray Kucherawy via Datatracker
Re: [ippm] Murray Kucherawy's No Objection on dra… xiao.min2
Re: [ippm] Murray Kucherawy's No Objection on dra… Murray S. Kucherawy
Re: [ippm] Murray Kucherawy's No Objection on dra… xiao.min2
Re: [ippm] Murray Kucherawy's No Objection on dra… xiao.min2