Re: [bmwg] Genart last call review of draft-ietf-bmwg-dcbench-methodology-07

[Dan Romascanu <[e-mail]>]

Hi,

All answers are acceptable. Thanks for addressing my comments.

Regards,

Dan


On Fri, Jun 9, 2017 at 8:11 AM, Lucien Avramov <[e-mail]> wrote:

> Hi Dan,
>
> Thank you very much for the comments. I addressed them and published
> version -09.
>
> Inline are some the comments / answer to your feedback. The parts without
> answers mean they have been addressed.
>
> Again, thank you for spending the time to read this in this fine detail.
>
> Lucien
>
>
>
> On Thu, Jun 8, 2017 at 5:29 AM, Dan Romascanu <[e-mail]> wrote:
>
>> Reviewer: Dan Romascanu
>> Review result: Ready with Issues
>>
>> 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-methodology-??
>> Reviewer: Dan Romascanu
>> Review Date: 2017-06-08
>> IETF LC End Date: 2017-06-13
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary:
>>
>> This Informational I-D describes test and evaluation methodology and
>> measurement techniques for physical network equipment in the data center.
>> It's
>> an useful and clearly written document and it is ready for publication,
>> after a
>> number of minor issues and nits will be addressed.
>>
>> Major issues:
>>
>> Minor issues:
>>
>> 1. There is one single mention of the scope being benchmarking of
>> 'physical
>> network equipment in the data center'. I assume this is written as
>> opposed to
>> virtual networking equipment. This is not included in the title or
>> repeated any
>> place else. I suggest to make more clear the scope by mentioning 'physical
>> equipment' at least once more, for example in the Introduction section.
>>
>> 2. Section 1.2: I am a little concerned about adding additional
>> interpretations
>> to the keywords in RFC2119.
>>
>> Especially about:
>>
>> 'MAY: Comprehensive metric for the scenario described'
>>
>
> *Thank you, MAY provides an optional metric, I have addressed your
> comment *
>
>>
>> MAY has a different meaning in 2119, and the fact that a metric is
>> 'comprehensive' (whatever this means) seems to me orthogonal to the 2119
>> semantics. The proposed interpretation makes little sense to me, if
>> 'comprehensive' than why not required? or at least as a 'should'?
>>
>> 3. Section 6.2: 'The intensity of a microburst MAY be varied ...' It
>> would be
>> useful to make clear what is meant by 'intensity'.
>>
>
> The intensity of a microburst is defined in the definitions document [1]
> so i referenced it that way
>
>
>>
>> Nits/editorial comments:
>>
>> 1. The different formatting of the references [1], [2], etc. vs.
>> [RFC2119],
>> etc. is slightly confusing. Unless there is some good reason I suggest to
>> fix
>> this. Also use of references is inconsistent through the text, sometimes
>> they
>> are mentioned, sometimes they are not.
>>
>
> Fixed it for [2] and [3], however kept [1] as [1], as this document is not
> an RFC yet.
>
>
>>
>> 2. Section 2.2: 'Alternatively when a traffic generator CAN NOT be
>> connected '
>> - this capitalization is not conformant to RFC2119.
>>
>> 3. 'vlan ZZZ' is not consistent with 'vlan X' and 'vlan Y' previously
>> used.
>>
>> 4. Missing reference - RFC 6985
>>
>> 5. Missing expansion and references for DSCP and COS
>>
>> 6. Sections 3.3 and 6.3: s/number of iteration/number of iterations/
>>
>> 7. The methodology (e.g. in section 5) makes an assumption that the DUT
>> has at
>> least nine ports. This may be trivial in a DC, but it's worth being
>> mentioned
>>
>> Thanks added this in section 2.3 as it was making more sense to be
> clarified there
>
>