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

[Lucien Avramov <lucienav@xxxxxxxxxx>]

Hi Matthew!

Thank you for the review!

We incorporated your feedback and now it's in -12: of the draft

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