Subject: [bmwg] Fwd: Publication Request for draft-ietf-bmwg-protection-term-08

From: Al Morton <[email-masked]>
Date: Sat, 10 Apr 2010 11:19:47 -0400

BMWG,

After a successful WGLC and agreed at the working group
session during IETF-77, we are moving this draft to the
Publication Requested state.

The completed Document Shepherd's form is below.

Al
bmwg chair

>Date: Sat, 10 Apr 2010 11:13:43 -0400
>To: Ron Bonica <[email-masked]>, [email-masked]
>From: Al Morton <[email-masked]>
>Subject: Publication Request for draft-ietf-bmwg-protection-term-08
>Cc: Dan Romascanu
>
>This is a publication request for
>http://tools.ietf.org/html/draft-ietf-bmwg-protection-term-08
>as an INFORMATIONAL RFC.
>
>
>     (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 shepherd, has read this version and says its ready.
>
>     (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, I believe so. This work was initially proposed in 2002, and was
>discussed extensively with many members of the community before
>working group adoption in 2006. Extensive review was sought in the last
>two rounds of WGLC.
>
>     (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. There will likely be a few more issues raised by the IESG, but
>no laws-of-physics class violations that might stall the work.
>
>     (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. Has an IPR disclosure related to this document
>           been filed? If so, please include a reference to the
>           disclosure and summarize the WG discussion and conclusion on
>           this issue.
>There are no concerns and no IPR disclosures.
>
>     (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?
>The consensus is solid. Many WG members read and agreed
>with this document at various times. Many readers completed the
>BMWG Active Review template for this draft.
>
>     (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?
>
>There are a few errors in the nits:
>http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-bmwg-protection-term-08.txt
>These can be corrected after AD-review, but there will be some work
>necessary to adopt the new boilerplate, update references, fix
>page lengths, etc.
>
>     (1.h) Has the document split its references into normative and
>           informative? Are there normative references to documents that
>           are not ready for advancement or are otherwise in an unclear
>           state? If such normative references exist, what is the
>           strategy for their completion? Are there normative references
>           that are downward references, as described in [RFC3967]? If
>           so, list these downward references to support the Area
>           Director in the Last Call procedure for them [RFC3967].
>Yes, the references are split.
>
>There is a normative dependency on:
>"Benchmarking Terminology for IGP Convergence",
>draft-ietf-bmwg-igp-dataplane-conv-term-21, (to be published) which is
>also effectively at the Publication Requested state.
>(Authors: this reference needs to be updated in the next version)
>
>     (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 suggest a
>           reasonable name for the new registry? See [RFC5226]. 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?
>N/A
>
>     (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?
>N/A
>
>     (1.k) The IESG approval announcement includes a Document
>           Announcement Write-Up. Please provide such a Document
>           Announcement Write-Up? 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.
>
>    The purpose of this document is to provide a single terminology for
>    benchmarking sub-IP protection mechanisms.
>
>    Technologies that transport IP packets can be designed to provide
>    protection for IP traffic by providing the failure recovery at lower
>    layers. Possibly, the outage is not even observed at the IP-layer.
>    Sub-IP protection technologies include, but are not limited to,
>    High Availability (HA) stateful failover, Virtual Router Redundancy
>    Protocol (VRRP), Automatic Link Protection (APS) for SONET/SDH,
>    Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for
>    Multi-Protocol Label Switching (MPLS-FRR).
>
>    Benchmarking terminology was defined for IP-layer convergence in
>    draft-ietf-bmwg-igp-dataplane-conv-term-21 .
>    Different terminology and methodologies specific to
>    benchmarking sub-IP layer protection mechanisms are required.  The
>    metrics for benchmarking the performance of sub-IP protection
>    mechanisms are measured at the IP layer, so that the results are
>    independent of the specific protection mechanism being used.
>
>           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?
>    Working group consensus was smoothly achieved over a period of
>    several years, with many controversies ironed-out before WG adoption.
>    Several authors came and went, but others were willing to pick-up the
>    work and complete it, so here we are.
>
>           Document Quality
>
>Q - Are there existing implementations of the protocol?
>
>A  these documents neither propose a new protocol nor extend any existing
>one, hence current implementations are not required to support this
>document. The document only attempts to standardize the benchmarking
>strategies so that service providers could evaluate multiple protection
>implementations using standard figures of merit with an aim of
>producing consistent test results across multiple platforms.
>
>Q - Have a significant number of vendors indicated their plan to implement
>the specification?
>
>A - Several test vendors, including the leading ones, have
>shown their support and interest in the execution of these methodologies.
>The authors have regularly acknowledged them in WG status presentations.
>
>Reference/acknowledgements were shared in the following:
>http://www.ietf.org/proceedings/06jul/slides/bmwg-3/bmwg-3.ppt
>
>Q - 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?
>
>A - The following lays down the history of this work item, which
>demonstrates substantial revisions of the documents based on comments form
>the BMWGers
>
>1.  July 2005: Common protection terminology created due to merger of
>draft-kimura-protection-term-02.txt and
>draft-poretsky-mpls-protection-meth-02 as result of series of reviews and
>comments. New draft-poretsky-protection-term-00.txt created.
>
>2.  December 2005: another effort with additional test scenarios
>(draft-vapiwala-bmwg-frr-failover-meth-00.txt) was merged into
>draft-poretsky-meth-05. It was felt that additional scenarios proposed were
>needed to offer comprehensive MPLS (including the services) based protection
>techniques evaluation. Terms checked against this new methodology.
>
>3.  June 2006: Due to additional test items proposal, a new draft was
>created  draft-papneja-mpls-protection-meth-merge-00.txt
>
>4.  Also in the combined effort Mr. Vapiwala were included as one of the
>co-authors due to his contribution to the effort in the form of additional
>test scenarios for the methodology document, and accordingly updating the
>terminology document.
>
>5.  The acknowledgement section is included for terminology document to
>thank those who significantly helped in shaping the final version. The
>document did receive comments from one of co-authors of original fast
>reroute RFC 4090 in the early versions of the work item document in addition
>to other pioneers in the MPLS field.