[bmwg] WG Chair Shepherding Write-up for dsmterm

[Al Morton <[e-mail]>]

BMWG,

FYI -
Here's the shepherding write-up/publication request for the dsmterm draft.


------------------------------------------------------------------
...
3.1  WG Chair Write-Up for Publication Request

Internet-Draft:
Terminology for Benchmarking Network-layer Traffic Control Mechanisms
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-dsmterm-12.txt

WG Chair Shepherd:
Al Morton

    1.a) Have the chairs personally reviewed this version of the Internet
         Draft (ID), and in particular, do they believe this ID is ready
         to forward to the IESG for publication?
Yes.
Note that a few typos have crept into version 12
(in section 3.4.4.5, "Expect" --> "Expected")
and there are two very minor nits, considering that this document
is being edited as a flat file, with little formatting help:

   * There are 2 instances of too long lines in the document, the longest
     one being 2 characters in excess of 72.

   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
   - The page length should not exceed 58 lines per page, but there was 2
     longer pages, the longest (page 11) being 59 lines

but these can be repaired along with future comments.


    1.b) Has the document had adequate review from both key WG members
         and key non-WG members?  Do you have any concerns about the
         depth or breadth of the reviews that have been performed?
Yes, the reviews have been very complete over 5 WG Last Calls. Non-WG
members have been consulted, and there are no known concerns.

    1.c) Do you have concerns that the document needs more review from a
         particular (broader) perspective (e.g., security, operational
         complexity, someone familiar with AAA, etc.)?
No.

    1.d) Do you have any specific concerns/issues with this document that
         you believe the ADs and/or IESG should be aware of?  For
         example, perhaps you are uncomfortable with certain parts of the
         document, or have concerns whether there really is a need for
         it.  In any event, if your issues have been discussed in the WG
         and the WG has indicated it that it still wishes to advance the
         document, detail those concerns in the write-up.
No, Co-Chair comments have been addressed.

    1.e) How solid is the WG consensus behind this document? Does it
         represent the strong concurrence of a few individuals, with
         others being silent, or does the WG as a whole understand and
         agree with it?
This draft precipitated substantial comments from many WG members during
its many WG Last Calls.  The final comments were resolved as summarized
here:
http://www1.ietf.org/mail-archive/web/bmwg/current/msg00845.html
(then, the primary editor left the group, and it took time to get another
editor to correct the I-D nits issues)

...

    1.g) Have the chairs verified that the document adheres to all of the
         ID nits? (see http://www.ietf.org/ID-Checklist.html).
Two lines have >72 characters (1 nit), and there is one warning.
The nit should not impact AD or IESG review.

    1.h) Is the document split into normative and informative references?
         Are there normative references to IDs, where the IDs are not
         also ready for advancement or are otherwise in an unclear state?
         (note here that the RFC editor will not publish an RFC with
         normative references to IDs, it will delay publication until all
         such IDs are also ready for publication as RFCs.)
Yes, the references are split and all the normative references are stable.

    1.i) For Standards Track and BCP documents, the IESG approval
         announcement includes a write-up section with the following
         sections:
The draft is Informational, as are all BMWG RFCs, but we provide the following
summary:

         *    Technical Summary

      This document describes terminology for the benchmarking of
      devices that implement traffic control based on IP precedence or
      Diffserv code point criteria.  The terminology is to be applied
      to measurements made on the data plane to evaluate IP traffic
      control mechanisms.

      New terminology is needed because most existing measurements
      assume the absence of congestion and only a single per-hop-
      behavior.  This document introduces several new terms that will
      allow measurements to be taken during periods of congestion.

      Another key difference from existing terminology is the definition
      of measurements as observed on egress as well as ingress of a
      device/system under test.  Again, the existence of congestion
      requires the addition of egress measurements as well as those
      taken on ingress; without observing traffic leaving a
      device/system it is not possible to say whether traffic-control
      mechanisms effectively dealt with congestion.

      The principal measurements introduced in this document are vectors
      for rate, delay, and jitter, all of which can be observed with or
      without congestion of the DUT/SUT.

         *    Working Group Summary
This document is a product of the BMWG WG.  The WG has consensus
to publish this document as an Informational RFC.

         *    Protocol Quality
This document does not specify a protocol.

    1.j) Please provide such a write-up.  Recent examples can be found in
         the "protocol action" announcements for approved documents.
(above)


_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg