[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