I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ippm-ioam-data-11 Reviewer: Dan Romascanu Review Date: 2020-12-05 IETF LC End Date: 2020-12-08 IESG Telechat date: Not scheduled for a telechat Summary: This is a very useful and rather complex document that discusses the data fields and associated data types for IOAM that can be encapsulated into a variety of protocols. It's well written, detailed and accurate. It is READY from a Gen-ART perspective, with a few editorial comments that I suggest being addressed before approval or as part of the final editorial process. Major issues: Minor issues: Nits/editorial comments: 1. How are specific IOAM encapsulations being defined? Will specifications that define IOAM encapsulations into various protocols be within the scope of the IPPM WG? of the IETF? Do they require to be RFCs? Some clarification text would be useful. 2. In Section 5.4.2.12 I found the following: > The authors acknowledge that in some operational cases there is a need for the units to be consistent across a packet path through the network, hence RECOMMEND the implementations to use standard units such as Bytes. 'The authors ... RECOMMEND' seems a little bit odd. The active verb form is not within the list of keywords as per [RFC2119], also mentioned in Section 3 of this document. To be on the safe side I would recommend reformulating the sentence so that the RECOMMENDED form is used. Alternatively, just do not use capitalization here. 3. In Section 8.7 I found: > The expert will post the request on the IPPM mailing list, and possibly on other relevant mailing lists, to allow for community feedback. I assume that this means the IPPM WG mailing list. The abbreviation of IPPM may be very familiar for the current audiences, but the situation may change in the future. The scope even of this document may outlive the WG. I suggest to expand IPPM in Section 3 and possibly reformulate the sentence so that posting the request on the IPPM list does not sound as the eternal procedure.