[Gen-art] Genart last call review of draft-ietf-ippm-rfc8321bis-02

[Elwyn Davies via Datatracker <[e-mail]>]

Reviewer: Elwyn Davies
Review result: Ready with Nits

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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.