Dear Elwyn, Thank you for your review. I will work on a new version to address your comments. Please see my replies inline tagged as [GF]. Best Regards, Giuseppe -----Original Message----- From: Elwyn Davies via Datatracker <noreply@xxxxxxxx> Sent: Friday, June 24, 2022 10:03 PM To: gen-art@xxxxxxxx Cc: draft-ietf-ippm-rfc8321bis.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx Subject: Genart last call review of draft-ietf-ippm-rfc8321bis-02 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. [GF]: Ok, I will try to revise and possibly reduce the discussion about the possible uses. 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/ [GF]: Agree s1.1, para 1:s/overtaking./building on/; s/in the original/that was based on the original/ [GF]: Ok s1.1, last para: Delete. The change log wil not be in the final document. [GF]: Ok, will do. s2, para 3: s/will have the same color/will have the same notional "color"/ [GF]: Ok 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/ [GF]: Ok 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? [GF]: Sure, a reference can be added, but I think this sentence could also be omitted to reduce the discussion of possible uses (in this case multicast traffic) besides the core proposal s3.2.2, para1: s/statistic distribution/statistical distribution/ [GF]: Ok 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'. [GF]: Yes, it makes sense. s4.1, para2: s/ number of involved nodes/number of nodes involved/ [GF]: Ok 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. [GF]: Ok, I would reduce it and just refer to the IEEE work s8, para 2: Not an academic paper! s/We used/The mechanisms described in this document use/ [GF]: Ok, will do. s8, bullet 5: s/strictly related each other/strictly related to each other/ [GF]: Ok 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. [GF]: Ok, good suggestion. s8, bullet 11: Singleton whats???? [GF]: I will clarify. The definition of singleton comes from RFC6390. 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. [GF]: Sure, I will simply list the parameters. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
