Skip to main content

Last Call Review of draft-ietf-ippm-rfc8321bis-02

Request Review of draft-ietf-ippm-rfc8321bis
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2022-06-21
Requested 2022-06-07
Authors Giuseppe Fioccola , Mauro Cociglio , Greg Mirsky , Tal Mizrahi , Tianran Zhou
I-D last updated 2022-06-24
Completed reviews Genart Last Call review of -02 by Elwyn B. Davies (diff)
Secdir Last Call review of -03 by Dan Harkins
Intdir Telechat review of -02 by Timothy Winters (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Request Last Call review on draft-ietf-ippm-rfc8321bis by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 02 (document currently at 03)
Result Ready w/nits
Completed 2022-06-24
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

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:

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.