Re: [bmwg] WGLC: draft-ietf-bmwg-reset-02

Al, 

Thanks for your review and feedback. Your proposed changes look fine to
me and will improve the readability.

Cheers,
Rajiv

> -----Original Message-----
> From: bmwg-bounces@ietf.org [mailto:bmwg-bounces@ietf.org] On Behalf
Of Al Morton
> Sent: Sunday, November 07, 2010 5:00 PM
> To: bmwg@ietf.org
> Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-reset-02
> 
> At 07:39 AM 10/11/2010, Al Morton wrote:
> >This message begins the Second WG Last call on the draft:
> >
> >         Title           : Device Reset Characterization
> >         Author(s)       : R. Asati, et al.
> >         Filename        : draft-ietf-bmwg-reset-02.txt
> 
> I have the following comments as this last call closes.
> I believe these are entirely editorial suggestions.
> 
> There are several instances where the Time-stamp method
> of recovery time measurement was not fully incorporated
> into the text, but I consider these predominantly
> editorial changes as well.
> 
> Al (as a participant)
> 
> OLD
> 1. Introduction
> 
>     An operational forwarding device (or one of its components) may
need
>     to be re-started for a variety of reasons, an event that we call a
>     "reset" in this draft. Since there may be an interruption in the
>     forwarding operation during a reset, it is useful to know how long
a
>     device takes to resume the forwarding operation. In other words,
it
>     is desired to know how long the recovery time after the reset is.
> 
> Suggest:
>             ...In other words, it
>     is desired to know the duration of the recovery time following the
reset.
> 
> OLD
> 1.1. Scope
> 
>     This document specifies a methodology for characterizing reset
(and
>     recovery time) during benchmarking of forwarding devices, and
>     provides clarity and consistency in reset procedures beyond what
is
>     specified in [RFC2544]. Software upgrades incur additional
>     benchmarking complexities and are outside the scope of this
>     document.
> 
> Suggest:
>           ...Software upgrades involve additional
>                                ^^^^^^^
>     benchmarking complexities and are outside the scope of this
>     document.
> 
> 1.1. Scope, 4th para
> OLD
>     ...
>     This document focuses on only the reset criterion of benchmarking,
>     and presumes that it would be beneficial to [RFC5180], [RFC5695],
>     and other BMWG benchmarking efforts.
> 
> Suggest:
>     This document focuses only on the reset criterion of benchmarking,
>                           ^^^^^^^
>     and presumes that it would be beneficial to [RFC5180], [RFC5695],
>     and other BMWG benchmarking efforts.
> 
> 
> 1.3. Reporting Format (I think a MUST was implied here)
> 
> OLD:
>     All reset results are reported in a simple statement including the
>     frame loss and recovery times.
> 
> Suggest:
>     All reset results MUST be reported in a simple statement including
the
>     frame loss (if measured) and recovery times.
>                 ^^^^^^^^^^^^
> 
> Later in 1.3. Reporting Format  (insert a line under the table header)
> 
> OLD
>           Parameter                Units or Examples
> 
>           Throughput               Frames per second and bits per
>                                    second
> Suggest
>           Parameter                Units or Examples
>    -------------------------------------------------------------------
>           Throughput               Frames per second and bits per
>                                    second
> 
> Section Titles (same comment for 4.2 and 4.3):
> OLD
> 4.1. Hardware Reset
> Suggest
> 4.1. Hardware Reset Test
> (because the description below describes a test, a HW rest is defined
later)
> 
> Later in 4.1:
> ...
> OLD
>     A hardware reset is executed by the operator for example by
physical
>     removal of a physical component, by pressing on a "reset" button
for
>     the component, or could even be triggered from the command line
>     interface.
> Suggest
>     A hardware reset is executed by the operator for example by
physical
>     removal of a hardware component, by pressing on a "reset" button
for
>                  ^^^^^^^^
>     the component, or could even be triggered from the command line
>     interface.
> 
> 4.1.1.1 RP Reset for a single-RP device (REQUIRED)
> ...
>       Procedure
> ...
> OLD
>       Finally, the characterization is completed by recording the
frame
>       loss (as reported by the test tool) and calculating the recovery
>       time (by following the section 1.2).
> Suggest
>       Finally, the characterization is completed by recording the
frame
>       loss or time stamps (as reported by the test tool)
>            ^^^^^^^^^^^^^^
>        and calculating the recovery time (by following the section
1.2).
> 
> (The comment above applies to all similar sections the follow,
> such as  4.1.1.2, 4.2.1, 4.2.2, 4.3.1)
> 
> 
> Typo:
> 4.3.1. Power Interruption (REQUIRED)
> 
>     Objective
> 
>       To characterize time needed for a DUT to recover efrom a
complete
>                                                        ^^^^^
> 
>  >>>> that's it <<<<<<
> 
> 
> 
> 
> 
> 
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg