[bmwg] Refinements to the BMWG Last Call Process

Al Morton <acmorton@att.com> Tue, 27 April 2004 14:45 UTC

Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04750 for <bmwg-archive@lists.ietf.org>; Tue, 27 Apr 2004 10:45:14 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIThm-00028l-6H; Tue, 27 Apr 2004 10:37:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BITb0-0000ef-Mp for bmwg@optimus.ietf.org; Tue, 27 Apr 2004 10:30:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03979 for <bmwg@ietf.org>; Tue, 27 Apr 2004 10:29:56 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BITau-0002Th-BK for bmwg@ietf.org; Tue, 27 Apr 2004 10:29:56 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BITa1-0002Ry-00 for bmwg@ietf.org; Tue, 27 Apr 2004 10:29:02 -0400
Received: from ckmso2.att.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1BITZK-0002Nk-00 for bmwg@ietf.org; Tue, 27 Apr 2004 10:28:19 -0400
Received: from attrh4i.attrh.att.com ([135.41.15.238]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i3RERnTb012468 for <bmwg@ietf.org>; Tue, 27 Apr 2004 10:27:50 -0400
Received: from custsla.mt.att.com (135.21.14.109) by attrh4i.attrh.att.com (7.1.006) id 406335550011E51B; Tue, 27 Apr 2004 10:23:31 -0400
Received: from acmortonw.att.com (acmortonw.mt.att.com [135.16.251.5]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id i3REfuL28035; Tue, 27 Apr 2004 10:41:56 -0400 (EDT)
Message-Id: <6.0.3.0.0.20040427095005.06132d60@custsla.mt.att.com>
X-Sender: acm@custsla.mt.att.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0
Date: Tue, 27 Apr 2004 10:27:45 -0400
To: bmwg@ietf.org
From: Al Morton <acmorton@att.com>
Cc: Kevin Dubray <kdubray@juniper.net>, david.kessens@nokia.com, bwijnen@lucent.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [bmwg] Refinements to the BMWG Last Call Process
Sender: bmwg-admin@ietf.org
Errors-To: bmwg-admin@ietf.org
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>

BMWG,

When a BMWG Draft begins the Last Call Process, the WG-level
quality of the draft improves when there is an active
review, as opposed to a tacit approval or minimal discussion.
To this end, we are going to try adding a step in the Last Call
Process for new drafts entering this phase of development.
We are defining the "Last Call Process" as one or more WG Last Calls
prior to forwarding the draft(s) up to AD-level review.
We alerted BMWG to the need for more active review at the IETF-58,
as captured in the minutes from that meeting.

The primary change is a requirement that approximately four WG members
complete a review template for the draft (or set of drafts),
upon entry to the Last Call Process. The WG reviewers should be
outside the body of active contributors (editors + authors).
The goal is to produce a quality review with valuable feedback
on the draft(s), and not to set a minimum number of people willing
to complete the review template. Directed feedback,
regardless of quantity, is a better condition by which BMWG can
more clearly assess a draft's readiness to advance.

The review template is appended below. Reviewers will complete
the template and send it to the list. Ideally, the reviewers
will have varied backgrounds, perspectives, and expertise
(test/network equipment developer/designer, network operator,
and subject matter expert). The chairs will ask for volunteers
and also do some recruiting for reviewers.

The use of reviewers does NOT SUPPLANT the need for the
general BMWG community to review and to comment on WG deliverables.
It is hoped that use of directed reviews AND community input will
improve the quality of BMWG work items. We also seek to increase our
WG "throughput", and make more room for new work proposals.

In BMWG's recent history, some drafts have spent several cycles
in the WG Last Call Process.  Our intent is to make substantial
improvements to the draft(s) early in the process (when such
changes are needed).  Therefore, subsequent WG Last Calls would
proceed as they do today, but there should be fewer cycles needed.

Our plan is to take one pass through this process, then
take a WG-consensus as to whether it is worth continuing, possibly
with modifications, or just return to the free-form Last Call.

We hope that you will make the time to participate
in the review program, whether you volunteer or respond
to a request to help.

Kevin, Al
BMWG Co-Chairs


Last Call Review Template

I-D Title(s):
Filename(s):
Reviewer Name:
Date:

Please organize your comments in the following categories below.

Review Summary:

Overall:

    * Does/Do the draft(s) provide clear identification of the
      scope of work? E.g., is the class of device, system, or
      service being characterized clearly articulated.


    * If a terminology memo, are the measurement areas clearly
      defined or otherwise cited?  Is the working set of
      supporting terminology sufficient and correct?  To your
      knowledge, are the areas of the memo that may conflict
      with other bodies of work? Are there any measurements or
      terminology that are superfluous?  Are any missing?


    * If a methodology memo, does the methodology AND its
      corresponding terminology adequately define a benchmarking
      solution for its application area? Do the methodologies present
      sufficient detail for the experimental control of the benchmarks?


    * If neither a terminology or methodology, does the offered
      memo offer complementary information important to the use
      or application of the related benchmarking solution?


    * Do you feel there are undocumented limitations or caveats to
      the benchmarking solution being proposed?  If so, please
      describe.


    * Does the memo attempt to define acceptance criteria for
      any of the benchmark areas?


Technical Content:  (Accuracy, Completeness of coverage)

    Are definitions accurate? Is the terminology offered relevant?


    To your knowledge, are there technical areas that are erroneous?
    Are there questionable technical areas that need to be re-examined
    or otherwise scrutinized.


    Does the solution adequately address IPv6?


    Do you feel the memo(s) being offered are technically mature enough
    for advancement to informational RFC?



Clarity and Utility:

   If you had a need, would you utilize the benchmarking solutions
   advocated by this and its related memos?  If not, why?


Conformance to BMWG principles: (see BMWG charter)
http://www.ietf.cnri.reston.va.us/html.charters/bmwg-charter.html


   Do you have confidence that the benchmarks, as explicitly
   defined, will yield consistent results if repeated on the
   same device (DUT/SUT), multiple times for a given test condition.
   If not, cite benchmark(s) and issue(s).


   Do you have confidence that the benchmarks, if executed for a
   given test condition, utilizing the documented methodology
   on multiple test infrastructure (e.g., test equipment), would
   yield correct and consistent results on the same DUT/SUT?
   (Said differently, are the benchmark's methodology written
   with enough exacting detail, that benchmark implementation
   differences do not yield a difference in the measured quantities?)
   If not, cite benchmark(s) and issue(s).


   Do you feel that the benchmarks form a basis of comparison between
   implementations of quantity being characterized? (I.e., are the
   benchmarks suitable for comparing solutions from different vendors.)


   If not, cite benchmarks and issues.


   For those benchmarks cited above, do you feel that the benchmarks,
   as specified, have universal applicability for the given
   behavior being characterized?  (i.e., benchmarks might not form
   a basis for cross-vendor comparison, can be used universally
   in a different role.)



Editorial Comments:
(includes any deficiencies noted w.r.t. I-D Nits, spelling, & grammar)



_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg