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

[Tianran Zhou <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, February 20, 2024 6:08 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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.