I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Bottom Line: Almost Ready About Security Considerations For your security considerations phrases like "are limited to" and "will be", and I would suggest that these are your MUSTs or SHOULDs. Given the "MUST NOT" you have in the second paragraph, it seems that "MUST" should be used instead of "SHOULD". In that sense, then, I would suggest the following statements be updated: 1) "Benchmarking activities as described in this memo MUST be limited to technology characterization using controlled stimuli...", "The benchmarking network topology MUST be an independent test setup..." That said, you might consider softening the "MUST NOT" and consequent "MUST" statements to "SHOULD NOT" and "SHOULD", respectively. This because there may well be circumstances where testing in a production environment is necessary. About Rest of Draft The draft describes well-understood concepts of FILO, FIFO, LILO, and LIFO. It then goes on to recast these definitions as "first bit last bit" (or "FL"), and "last bit last bit" (or "LL"), and so on. However, the draft does not really make use of these alternate expressions for the aforementioned well-understood concepts. I recommend picking one of these representations and using it consistently throughout; moreover, I recommend sticking with FILO, FIFO, LILO, and LIFO. There's a sentence in 2.2 which reads, "Data Center DUTs are frequently store-and-forward for smaller packet sizes and then adopting a cut-through behavior." This feels incomplete. When does it adopt cut-through behavior? Is that adopted for larger packet sizes? Is it worthwhile to talk at all about the change threshold? Section 1.2 describes the generally expected definition format. However, section 2 seems to immediately depart from that to some degree by placing terms as top-level sections (i.e. "2. Latency") with children for definition, discussion, and measurement units. To compound this confusion, section 6 further departs from the expectation set in 1.2 by using the top-level section as a grouping construct for "Buffering" (without defining "Buffering"). Buffering has two children which are "buffer" and "incast". Buffer, itself is never defined, but instead has a "definition" subsection consisting of many other terms. The same sort of thing happens with "6.2 Incast". Please pick a format and make clear what things are terms, and which are not terms. Then rewrite section 1.2, so that it more properly describes what the reader should expect. There are, at several locations, uses of the capitalized word "CAN" in a way that suggests normative-type intent. "CAN" does not seem to be an RFC2119 keyword. In one case, it seems that "CAN" may actually mean a lower case "may" or "can" (see 6.1.1 on page 12). Nits Throughout the draft sometimes terms are capitalized, sometimes they are not. I believe they should more often not be capitalized, but if they are, do so consistently. Generally speaking (this may be stylistic) the first word after a colon (':') should be capitalized. Example: This is. Find acronyms/initializations and ensure they're expanded at least on the first occurrence (i.e. "PDV" on page 6) In the abstract s/as it is to/as to/ In 2.1 s/in unit of/in units of/ and s/store forward/store and forward/ In 2.3 s/follow:/follows:/ In 2.3, item 2: Is "proceed data" a common term? In 4.1 s/test on/tests on/ In 4.3 s/of :/of:/ In 4.3 s/[4.1s]/section 4.1/ In 5.3, if "CAN" is changed to "can", then s/line rate can measured/line rate can be measured/ In 6.1.1 s/expressed in Byte;/B (bytes),/ or s/expressed in Byte;/Bytes,/ In 6.1.1 s/amount of buffer a single/amount of buffer for a single/ In 6.1.1 recommend striking "it is a burst" In 6.2.1 s/by synchronous/by synchronous arrival time/ In 6.2.2 s/In a ingress/In an ingress/ In 6.2.2 s/In either cases/In either case/ In 6.2.3 s/non null/non-null/ In 7.3 the first paragraph could be improved by simply writing, "When S represents the payload bytes, which does not include packet or TCP headers, and Ft is the Finishing Time of the last sender, the Goodput, G, is then measured by the following formula..." Kind regards, Adam