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-bmwg-dcbench-terminology-10 Reviewer: Matthew A. Miller Review Date: 2017-06-13 IETF LC End Date: 2017-06-13 IESG Telechat date: N/A Summary: This document is almost ready; this document is on the path to its goals set out in the abstract and introduction, but the execution needs more work. I think the authors would benefit from another round of proofreading and submit a new revision. Below are the most obvious or egregious issues I have. Major issues: * In section 6.2 "Incast", it is unclear what is being measured, and what the units (if any) for that measurement are. Is it the percentage of synchronization? Is it the synchronous arrival time (which presumably is measured as a delta over some magnitude of seconds)? Is it the number of ingress and egress ports? If it is the number of ingress and egress ports, then it should define what "egress" means for the purpose of this measurement * In Section 8. "Security Considerations", what is the reason for the "SHOULD" and "SHOULD NOT" in the last paragraph (discussing special capabilities)? At the least it seems safest for the exceptions that rationalize the "SHOULD" and "SHOULD NOT" be explicitly stated here, or changed to "MUST" and "MUST NOT" if that rationale cannot be stated. Minor issues: * RFC 2119 should be a normative reference, as the reader MUST understand what the terms as-written mean. * RFC 5841 needs to be a listed reference; It is explicitly pointed to in Sections 3.1. and 3.2. From the text is seems a Normative reference is warranted but it at least needs to be documented in References. * RFC 2647 needs to be a listed reference. It is explicitly pointed to in Section 7.1.; from the text it seems appropriate to be an Informative reference. * The definition in Section 1.2. of what the "Measurement Units" subsections definitions format doesn't seem to be followed in this document. Specifically, the "Measurement Units" subsections rarely ever mention a unit of measure; instead the unit of measure is almost always specified as part of the "Definition" subsection. It may be worth revisiting the name for the "Measurement Units" subsections, or to move the unit of measure out of the "Definitions" subsections and into the "Measurement Units" subsections. * In section 2.3., the use of MUST, MAY, and MUST NOT seems a little contradictory. The MUST for point 1 would seem to already negate point 3, and prohibit point 2. Would changing that MUST to SHOULD be acceptable? Nits/editorial comments: * It would be helpful to include a reference to what "north-south" and "east-west" mean, if possible. * the acronyms DUT and SUT -- at the least -- need to be expanded on first use, or in Section 1.1. "Terminology". * In a number of subsections (notably under Section 4. and Section 6.), square brackets ("[" and "]") are used instead of parentheses ("(" and ")"), without any clear reason for the difference. They should be switched to parentheses. * In Section 2.2., the word "for" or "at" should be removed in the sentence "The change of behavior happens for at specific larger packet sizes." * Section 2.3., the phrase "the application commonly need to" should be changed to "the application commonly needs to". * In Section 5.2., there is a comma missing between "crystals" and "or" in "The crystals or clock modules, usually have a specific". * Also in Section 5.2., the term "devices under test" is used instead of DUTs the rest of the document seems to use. * Throughout Section 6.1., the acronyms "cos" and "dcsp" should be expanded on first use. * In Section 6.1.1, the definition of "Buffer Size" calls out using some magnitude of bytes (B, KB, MB, GB), then the example denotes "Mb" -- which commonly is used for megabits. From the rest of the definition, it seems this should be MB, but I have not calculated if the numerical value preceding the unit needs to be revisited. * In Section 6.2.1, the Stateful and Stateless terms both use the phrase "such as for example", which is redundant. Either "such as" or "for example" is sufficient, and the other should be removed. * The formatting in Section 10. "References" is very inconsistent. There is odd indentation and inconsistent anchor usage. * The affiliation and email address for Lucien Avramov is Google, but the street address is mostly that for Cisco Systems, Inc.