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-rfc8321bis-02 Reviewer: Elwyn Davies Review Date: 2022-06-24 IETF LC End Date: 2022-06-21 IESG Telechat date: 2022-07-14 Summary: Ready with a number of nits. I found that the discussion of possible uses besides the core proposal to be somewhat distracting and perhaps detracts from the value of the basic proposal. Major issues: None. Minor issues: Nits/editorial comments: Abstract: s/It could be considered/According to the classification defined in RFC 7799, it could be considered/ s1.1, para 1:s/overtaking./building on/; s/in the original/that was based on the original/ s1.1, last para:  Delete.  The change log wil not be in the final document. s2, para 3: s/will have the same color/will have the same notional "color"/ s3.1, para 6: s/shows how a flow looks like when it is split in traffic blocks/shows how a flow appears when it is split into traffic blocks/ s3.1, second set of bullets: The problem is easier to solve for multicast traffic, where load-balancing is seldom used and static joins are frequently used to force traffic forwarding and replication. Is the term 'static joins' sufficiently well-known to not need a reference? s3.2.2, para1: s/statistic distribution/statistical distribution/ s3.2.2, para2:  The term 'security time gap'  didn't seem obvious in this section: Between packets with the second marking, there should be a security time gap to avoid out-of-order issues and also to have a number of measurement packets that are rate independent. I suggest 'adequate time gap'. s4.1, para2: s/ number of involved nodes/number of nodes involved/ s7, last para:  This paragraph is not future proof.  The two drafts referenced are not working group drafts and it is not clear if they will eventually become RFCs.   I would be inclined to omit the paragraph or at least reduce it to just refer to the IEEE work.  It could also be moved to an appendix.   s8, para 2: Not an academic paper!  s/We used/The mechanisms described in this document use/ s8, bullet 5: s/strictly related each other/strictly related to each other/ s8, bullet 7: Suggest replacing text with: Verification: the methodology  has been tested and deployed experimentally in both lab and operational network scenarios performing packet loss and delay measurements on traffic patterns created by traffic generators together with precision test instruents and network emiulators. s8, bullet 11:  Singleton whats???? s8, bullet 12:  "currently, the main parameter of the method is...."   Once this becomes an RFC the parameters are set in stone - 'currently' is not a good way of describing that state. Also the bullet asks about 'parameters'.  If there is just one parameter say that.  If there are others they need to be described here.