A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM) Integrity-Protected Options
draft-ietf-ippm-ioam-integrity-yang-08

Thanks to Corey Bonnell for their secdir review.

Section 5, para 2:  I recommend using draft-ietf-tls-8446bis vice RFC 8446.  The draft is in Auth 48.

Thanks for the work done in this document. I can only repeat my comment on draft-ietf-ippm-ioam-data-integrity, i.e., with the use of shared keys by trusted nodes, this smells more like authentication (e.g., see OSPFv3 *authentication* trailer) than integrity. I.e., STRONGLY suggest to s/int/auth/ in the module.

Section 4, paragraph 21
>      grouping int-method-grouping {
>        description
>          "A grouping for Integrity Protection Methods.";
>        leaf int-method {
>          when "derived-from-or-self(../node-action,
>                'ioam:action-encapsulate')";
>          type iana-ioam-ipm:method-id;
>          description
>            "This object indicates the Integrity Protection Method for
>             this profile. 'int-method' is only defined at the
>             encapsulating node.";
>        }
>      }

The int-method leaf is defined as optional (? in the tree diagram) in all 
four integrity-protected profiles, with no default and no mandatory 
statement. The description says it "indicates the Integrity Protection 
Method for this profile" and is "only defined at the encapsulating node."

If the int-method is absent at an encapsulating node, what method does the 
implementation use? Currently, there is only one registered method 
(AES-GMAC, method-0), so implementations may default to it in practice. 
But as the registry grows, an absent int-method will become ambiguous. 

The document should either: (a) add a mandatory true statement 
(since an integrity-protected profile without a method is semantically 
incomplete at the encapsulating node), or (b) define explicit 
default/fallback behavior when int-method is absent. This is important 
for interoperability as the registry expands.

Section 6.1, paragraph 6
>    IANA is requested to add this note to [reference-to-the-iana-foo-
>    registry]:
> 
>    |  When this registry is modified, the YANG module "iana-ioam-
>    |  integrity-protection-methods" [IANA_FOO_URL] must be updated as
>    |  defined in RFC XXXX.

This section contains two unresolved template placeholders that were 
flagged by the INTDIR reviewer (Satoru Matsushima, thanks Saturo-san) 
against -06 and are still present in -07:

Line referencing [reference-to-the-iana-foo-registry] and the note 
itself references [IANA_FOO_URL].

These must be replaced with the actual "IOAM Integrity Protection Methods." 
registry reference and the IANA YANG module URL before publication. 

Appendix A similarly has inline // RFC Ed.: replace the IANA_FOO_URL notes
that need resolution. The shepherd write-up acknowledged this as an 
outstanding issue, but it was not addressed in -07.

Section 7, paragraph 0
>    The authors would like to thank Alex Huang Feng, Will Hawkins, and
>    Mohamed Boucadair for their valuable feedback.

How about the expert reviewers who provided their review?

No reference entries found for these items, which were mentioned in the text:
[reference-to-the-iana-foo-registry] and [IANA_FOO_URL].

Possible DOWNREF from this Standards Track doc to [IANA-IOAM]. If so, the IESG
needs to approve it.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 1
>    This document defines a data model for the management of these
>    Integrity-Protected Options using the YANG data modeling language
>    [RFC7950].  This YANG data model supports four IOAM Integrity-
>    Protected Options, which are as follows:

The YANG Doctor reviewer (Qiufang Ma, thanks Qiufang) against the -06 version
of the document suggested restructuring to "This document defines a 
YANG data model [RFC7950] for the management of these 
Integrity-Protected Options." The current text partially addresses 
the suggestion, but still has "data model...using the YANG data 
modeling language, which is slightly awkward. Consider the suggested form.

Section 4, paragraph 21
> m:ioam-pot-type; description "The type of a particular POT variant that specifies
>                                   ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".)

"Appendix B.", paragraph 3
> otected Proof of Transit and Integrity- Protected Edge-to-Edge Profiles Autho
>                              ^^^^^^^^^^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

Thank you to Roni Even for the GENART review.