Re: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-ioam-yang-11: (with COMMENT)

Tianran Zhou <zhoutianran@huawei.com> Wed, 21 February 2024 07:30 UTC

Return-Path: <zhoutianran@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 F0685C14F60D; Tue, 20 Feb 2024 23:30:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Level:
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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, 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 C9ec3SG9xcd2; Tue, 20 Feb 2024 23:29:59 -0800 (PST)
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 03A26C14F604; Tue, 20 Feb 2024 23:29:59 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Tfnr20Fn7z6K6HR; Wed, 21 Feb 2024 15:25:54 +0800 (CST)
Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 1585D140135; Wed, 21 Feb 2024 15:29:56 +0800 (CST)
Received: from dggpemm100005.china.huawei.com (7.185.36.231) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 21 Feb 2024 07:29:55 +0000
Received: from kwepemd100004.china.huawei.com (7.221.188.31) by dggpemm100005.china.huawei.com (7.185.36.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 21 Feb 2024 15:29:53 +0800
Received: from kwepemd100004.china.huawei.com ([7.221.188.31]) by kwepemd100004.china.huawei.com ([7.221.188.31]) with mapi id 15.02.1258.028; Wed, 21 Feb 2024 15:29:52 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Éric Vyncke <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-ioam-yang@ietf.org" <draft-ietf-ippm-ioam-yang@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "marcus.ihlar@ericsson.com" <marcus.ihlar@ericsson.com>, "Zhukeyi(Kaiyin,Datacom Standard&Patent)" <zhukeyi@huawei.com>
Thread-Topic: Éric Vyncke's No Objection on draft-ietf-ippm-ioam-yang-11: (with COMMENT)
Thread-Index: AQHaY+S5+mWpl5NIukSN4U7Eqin7QbEUUsWg
Date: Wed, 21 Feb 2024 07:29:52 +0000
Message-ID: <0f0eae20f65b4da4ad2de03e4055fb09@huawei.com>
References: <170842367992.49668.12540958839671310616@ietfa.amsl.com>
In-Reply-To: <170842367992.49668.12540958839671310616@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.118]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/5oGH2A-hHeOxv8Nj8_PjbRE7sRs>
Subject: Re: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-ioam-yang-11: (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, 21 Feb 2024 07:30:03 -0000

Hi Eric,

Thanks very much for your comments.
Please see in line with my reply.

Cheers,
Tianran

-----Original Message-----
From: Éric Vyncke via Datatracker [mailto:noreply@ietf.org] 
Sent: Tuesday, February 20, 2024 6:08 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-ioam-yang@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; marcus.ihlar@ericsson.com; marcus.ihlar@ericsson.com
Subject: Éric Vyncke's No Objection on draft-ietf-ippm-ioam-yang-11: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-ippm-ioam-yang-11: 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-yang/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-ippm-ioam-yang-11

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Marcus Ihlar for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Missing NMDA statement

While I am not a YANG expert, there are often a statement whether NMDA is
supported by the data model(s) under specification. Should this be the case
here as well ?

ZTR> Yes, I will add the statement.

## Section 1

Should the reference to NSH and IPv6 already be in this section rather than
later in section 3.1 ?

ZTR> A little different. The terms in Section 1 are just to mention the NSH and IPv6 protocols themselves. But they are well known. So I did not give a reference.
The later one is Section 3.1 actual refer to the IOAM encapsulation in NSH and IPv6. So I gave a reference.
I will not insist on this. What's your thoughts?

## Section 3.3

Does incremental tracing require a "max-length" defined at encapsulation mode ?
Conversely, should 'max-length' be renamed into 'length' for the pre-allocated
? (of course at the expense of having two leaves rather than one).

ZTR> Both incremental tracing and pre-allocated tracing need the max-length. They use the max-length in the same way to initiate the " RemainingLen" field in the IOAM header.

## Section 3.5

May I assume that there is no 'namespace' associated with the PoT profile type ?

ZTR> I think you are right. The 'namespace' was missing since some version. We will add it. Thanks.

## Section 4

Suggest to add leading text stating that the YANG module refers to RFC 8343 and
8532 to avoid id-nits warning messages.

ZTR> Yes. People always miss the reference from YANG model. This is a good way to avoid warning.

# NITS (non-blocking / cosmetic)

## Section 3.1

s/read only information/read-only information/ ?

ZTR> Yes. Thanks.

Unsure how to parse `IOAM actions MUST be driven by the accepted packets`

ZTR> The whole sentence is:  IOAM actions MUST be driven by the accepted packets, when the matched ACE "forwarding" action is  "accept".
In this IOAM module, we define " node-action" for encap, decap, transit.
I mean the device will only do the node-action for the accepted packets.
And here we use the term in ACL, i.e., accept/drop/reject. As in RFC8519, the forwarding actions are defined as follows:

  /*
   * Forwarding actions for a packet
   */

  identity forwarding-action {
    description
      "Base identity for actions in the forwarding category.";
  }

  identity accept {
    base forwarding-action;
    description
      "Accept the packet.";
  }

  identity drop {
    base forwarding-action;
    description
      "Drop packet without sending any ICMP error message.";
  }

  identity reject {
    base forwarding-action;
    description
      "Drop the packet and send an ICMP error message to the source.";
  }


## Appendix A

s/Hop by Hop/Hop-by-Hop/

ZTR> Yes. Thanks.