[bmwg] Fwd: Publication Request for draft-ietf-bmwg-hash-stuffing-07

[Al Morton <[e-mail]>]

BMWG,

The 4th WGLC closed without comments, and after 3 prior rounds
of very active discussion, it appears that we can recognize (at least)
"rough consensus" to request publication of this draft.

In accordance with the process in:
http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-08.txt
here's a copy of the Document Shepherd write-up.

Al
bmwg co-chair

>Date: Mon, 04 Dec 2006 10:01:12 -0500
>To: David Kessens <[e-mail]>, Dan Romascanu 
><[e-mail]>, [e-mail]
>From: Al Morton <[e-mail]>
>Subject: Publication Request for draft-ietf-bmwg-hash-stuffing-07
>
>Hi David, Dan,
>
>The text below is the publication request/Document Shepherd write-up
>for the hash and stuffing draft.
>
>This draft is intended to become an Informational RFC, as is the
>practice with all BMWG RFCs.
>
>I'll be the Document Shepherd again.
>
>Al
>
>============================================================================
>
>Publication Request for Informational RFC
>WG Chair Shepherding Write-up
>
>       Title     :Hash and Stuffing: Overlooked Factors in Network Device
>                 Benchmarking
>         Author(s): D. Newman, T. Player
>         Filename: draft-ietf-bmwg-hash-stuffing-07.txt
>         Pages   : 34
>         Date    : 2006-11-22
>http://www.ietf.org/internet-drafts/draft-ietf-bmwg-hash-stuffing-07.txt
>
>
>    (1.a)  Who is the Document Shepherd for this document?  Has the
>           Document Shepherd personally reviewed this version of the
>           document and, in particular, does he or she believe this
>           version is ready for forwarding to the IESG for publication?
>Al Morton is the Document Shepherd.
>He has reviewed this version of the draft and believes it is ready for
>publication.
>There is one typo in the Acknowledgements section:
>Dan Romascanu's name is misspelled.
>
>    (1.b)  Has the document had adequate review both from key WG members
>           and from key non-WG members?  Does the Document Shepherd have
>           any concerns about the depth or breadth of the reviews that
>           have been performed?
>Yes, the document benefited from extensive WG commentary prior to and
>during 3 WGLC, with the 4th WGLC passing quietly.
>We requested an early Security Directorate Review. Joe Salowey and Jeffrey
>Altman reviewed version 05 of the draft and provided some comments.
>No concerns about the depth or breadth of the reviews.
>
>    (1.c)  Does the Document Shepherd have concerns that the document
>           needs more review from a particular or broader perspective,
>           e.g., security, operational complexity, someone familiar with
>           AAA, internationalization or XML?
>No.
>
>    (1.d)  Does the Document Shepherd have any specific concerns or
>           issues with this document that the Responsible Area Director
>           and/or the IESG should be aware of?  For example, perhaps he
>           or she is uncomfortable with certain parts of the document, or
>           has concerns whether there really is a need for it.  In any
>           event, if the WG has discussed those issues and has indicated
>           that it still wishes to advance the document, detail those
>           concerns here.
>No.
>
>    (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?
>As stated above, WG review has been extensive and many people have commented
>and had their concerns addressed.
>
>    (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>           discontent?  If so, please summarize the areas of conflict in
>           separate email messages to the Responsible Area Director.  (It
>           should be in a separate email because this questionnaire is
>           entered into the ID Tracker.)
>No.
>
>    (1.g)  Has the Document Shepherd personally verified that the
>           document satisfies all ID nits?  (See
>           http://www.ietf.org/ID-Checklist.html and
>           http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>           not enough; this check needs to be thorough.  Has the document
>           met all formal review criteria it needs to, such as the MIB
>           Doctor, media type and URI type reviews?
>The boilerplate and automated nits check-out fine.
>The draft conforms to the I-D guidelines in all the following ways:
>- Use of network byte order in diagrams
>- Content of the IANA considerations section
>- Proper split of Normative/Informative references
>(the Informative References are bibliographical)
>- Meaningful abstract
>- Meaningful security considerations
>- Proper values for example addresses, names, numbers
>- Proper references, particularly to non-IETF documents
>- No text that will be outdated after publication
>- No Protocol issues (ipv4 specificity, congestion, internationalization,
>  proper specification of data to be checksummed, etc)
>
>
>    (1.h)  Has the document split its references into normative and
>           informative?
>Yes
>           Are there normative references to documents that
>           are not ready for advancement or are otherwise in an unclear
>           state?
>No
>           If such normative references exist, what is the
>           strategy for their completion?  Are there normative references
>           that are downward references, as described in [RFC3967]?
>No
>           If
>           so, list these downward references to support the Area
>           Director in the Last Call procedure for them [RFC3967].
>
>    (1.i)  Has the Document Shepherd verified that the document IANA
>           consideration section exists and is consistent with the body
>           of the document?  If the document specifies protocol
>           extensions, are reservations requested in appropriate IANA
>           registries?  Are the IANA registries clearly identified?  If
>           the document creates a new registry, does it define the
>           proposed initial contents of the registry and an allocation
>           procedure for future registrations?  Does it suggested a
>           reasonable name for the new registry?  See
>           [I-D.narten-iana-considerations-rfc2434bis].  If the document
>           describes an Expert Review process has Shepherd conferred with
>           the Responsible Area Director so that the IESG can appoint the
>           needed Expert during the IESG Evaluation?
>This document makes no requests of IANA.
>
>    (1.j)  Has the Document Shepherd verified that sections of the
>           document that are written in a formal language, such as XML
>           code, BNF rules, MIB definitions, etc., validate correctly in
>           an automated checker?
>NA
>
>    (1.k)  The IESG approval announcement includes a Document
>           Announcement Write-Up.  Please provide such a Document
>           Announcement Writeup?  Recent examples can be found in the
>           "Action" announcements for approved documents.  The approval
>           announcement contains the following sections:
>
>           Technical Summary
>              Relevant content can frequently be found in the abstract
>              and/or introduction of the document.  If not, this may be
>              an indication that there are deficiencies in the abstract
>              or introduction.
>
>    Test engineers take pains to declare all factors that affect a given
>    measurement, including intended load, packet length, test duration,
>    and traffic orientation.  However, current benchmarking practice
>    overlooks two factors that have a profound impact on test results.
>    First, existing methodologies do not require the reporting of
>    addresses or other test traffic contents, even though these fields
>    can affect test results.  Second, "stuff" bits and bytes inserted in
>    test traffic by some link-layer technologies add significant and
>    variable overhead, which in turn affects test results.  This document
>    describes the effects of these factors; recommends guidelines for
>    test traffic contents; and offers formulas for determining the
>    probability of bit- and byte-stuffing in test traffic.
>
>           Working Group Summary
>              Was there anything in WG process that is worth noting?  For
>              example, was there controversy about particular points or
>              were there decisions where the consensus was particularly
>              rough?
> From the initial work proposal through the final WG Last Call, there was
>wide agreement that this work was important for BMWG in that it added key
>testing considerations to our body of literature.
>
>           Document Quality
>              Are there existing implementations of the protocol?  Have a
>              significant number of vendors indicated their plan to
>              implement the specification?  Are there any reviewers that
>              merit special mention as having done a thorough review,
>              e.g., one that resulted in important changes or a
>              conclusion that the document had no substantive issues?  If
>              there was a MIB Doctor, Media Type or other expert review,
>              what was its course (briefly)?  In the case of a Media Type
>              review, on what date was the request posted?
>All BMWG RFCs are Informational, but they are implemented by
>test equipment vendors and cited in trade publications and advertisements.
>The Acknowledgements recognize individuals who have done careful reviews.
>There is one publicly reported implementation, and others reported to
>be in progress.
>
>           Personnel
>              Who is the Document Shepherd for this document?
>Al Morton
>              Who is the Responsible Area Director?
>David Kessens


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