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

[Éric Vyncke via Datatracker <[e-mail]>]

É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 ?

## Section 1

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

## 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).

## Section 3.5

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

## Section 4

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

# NITS (non-blocking / cosmetic)

## Section 3.1

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

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

## Appendix A

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