Mtt, thanks for your review. Lucien, than you for your responses. I have entered a No Objection ballot position on this document.
Alissa > On Jun 16, 2017, at 1:09 AM, Lucien Avramov <[email protected]> wrote: > > Hi Matthew! > > Thank you for the review! > We incorporated your feedback and now it's in -12: of the draft > <https://datatracker.ietf.org/doc/draft-ietf-bmwg-dcbench-terminology/> > > Please see inline more details to each of your feedback. > > Thank you for such a detailed write up. > > Best, > Lucien > > > >> >> Subject: Genart last call review of draft-ietf-bmwg-dcbench-terminology-10 >> >> Reviewer: Matthew Miller >> Review result: Almost Ready >> >> 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 >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>. >> >> 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 > > > fixed! >> >> >> * 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. > > > These are the standard security considerations all BMWG uses for the drafts. > We want to stay with the considerations we chose. >> >> >> Minor issues: >> >> * RFC 2119 should be a normative reference, as the reader MUST >> understand what the terms as-written mean. > > done > >> >> >> * 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. > > done >> >> >> * 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. > > done >> >> >> * 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. > > Section 1.2 has the purpose to explain how the document is formatted. > it has 3 subsections each time moving forward as described in 1.2. We use > that third subsection in this document to explain how to measure the topic > discussed. > > Definition: The specific definition for the term. > Discussion: A brief discussion about the term, its application > Measurement Units >> >> >> * 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? > > We wanted to keep MUST , MAY and MUST NOT to explain that : 1) is the way to > go ALWAYS. 2) can be done but it very specific to particular corner use case. > 3) should never be done, although 1) negates 3), we want to call out 3, > because people often time do 1) and don't follow 3. (they would do a LIFO > test although they must not do it). > > > > These are the standard security considerations all BMWG uses for the drafts. > We want to stay with the considerations we chose. >> >> >> Nits/editorial comments: >> >> * It would be helpful to include a reference to what "north-south" >> and "east-west" mean, if possible. > > done! >> >> >> * the acronyms DUT and SUT -- at the least -- need to be >> expanded on first use, or in Section 1.1. "Terminology". > > > done! >> >> >> * 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. > > done! >> >> >> * 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." > > done! >> >> >> * Section 2.3., the phrase "the application commonly need to" should >> be changed to "the application commonly needs to". >> > > done! >> * In Section 5.2., there is a comma missing between "crystals" and >> "or" in "The crystals or clock modules, usually have a specific". > > done! >> >> >> * Also in Section 5.2., the term "devices under test" is used >> instead of DUTs the rest of the document seems to use. > > done! >> >> >> * Throughout Section 6.1., the acronyms "cos" and "dcsp" should be >> expanded on first use. > > done! >> >> >> * 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. > > done! >> >> >> * 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. > > > fixed as much as i could, there is a problem with nits in submission tool > when >> >> >> * The affiliation and email address for Lucien Avramov is Google, >> but the street address is mostly that for Cisco Systems, Inc. > > done > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
