Re: [bmwg] Genart last call review of draft-ietf-bmwg-dcbench-terminology-10

[Lucien Avramov <[e-mail]>]

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>.
>
> 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