Hi, All answers are acceptable. Thanks for addressing my comments.
Regards, Dan On Fri, Jun 9, 2017 at 8:11 AM, Lucien Avramov <[email protected]> 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 <[email protected]> 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 > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
