Last Call Review of draft-ietf-bmwg-dcbench-terminology-10

Request Review of draft-ietf-bmwg-dcbench-terminology
Requested rev. no specific revision (document currently at 19)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-06-13
Requested 2017-05-30
Authors Lucien Avramov,
Draft last updated 2017-06-13
Completed reviews Opsdir Last Call review of -16 by Tim Chown (diff)
Genart Last Call review of -10 by Matthew Miller (diff)
Secdir Last Call review of -09 by Adam Montville (diff)
Assignment Reviewer Matthew Miller
State Completed
Review review-ietf-bmwg-dcbench-terminology-10-genart-lc-miller-2017-06-13
Reviewed rev. 10 (document currently at 19)
Review result Almost Ready
Review completed: 2017-06-13


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


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

* 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"

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