Re: [bmwg] Mirja Kühlewind's No Objection on draft-ietf-bmwg-dcbench-terminology-10: (with COMMENT)

[Lucien Avramov <[e-mail]>]

Hi Mirja,

I believe we have resolved all the comments and suggestions so far.

Can you please let us know what you think?

Thanks!
Lucien

On Wed, Jun 14, 2017 at 7:16 AM, Mirja Kühlewind <[e-mail]>
wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-bmwg-dcbench-terminology-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bmwg-dcbench-terminology/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I didn't put in a discuss because it’s not worth holding up the document
> as the
> content seems fine, BUT I really don't see why this terminology is
> specified
> FOR data centers ONLY. All terminology seem to be applicable in general
> and as
> such this seems to be an extension of RFC1242. Even incast, which is
> actually a
> data center term, is so generally defined that one could use it also in a
> different context as well. Further latency is defined in both documents,
> where
> this drafts mentions RFC1242 and mainly extends the description there.
> That's
> in general fine, but I probably would recommend to simply change the title,
> remove the work data center there, and make this document update RFC 1242.
> (+
> remove the intro text on data centers because the same text is anyway in
> draft-ietf-bmwg-dcbench-methodology).
>
>
>