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

From: Al Morton <[email-masked]>
Date: Sun, 07 Nov 2010 16:59:50 -0500

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 <<<<<<

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 8 Nov 2010 09:14:52 -0600

Al, 

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

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Al Morton
> Sent: Sunday, November 07, 2010 5:00 PM
> To: [email-masked]
> Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-reset-02
> 
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 09 Nov 2010 11:57:10 -0500

Al, WG,

Many thanks, all of your comments as well as all WGLC comments have been
incorporated into the just posted draft-ietf-bmwg-reset-03 revision,
which is much improved !

Thanks,

-- Carlos.