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

[Lucien Avramov <[e-mail]>]

Thank you Dan, much appreciative of your feedback.

Lucien

> On Jun 10, 2017, at 08:27, Dan Romascanu <[e-mail]> wrote:
> 
> 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 
>> 
>