Re: [bmwg] FW: IETF WG state changed for draft-ietf-bmwg-sip-bench-term

[joel jaeggli <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you.

joel

On 7/19/14, 9:54 AM, MORTON, ALFRED C (AL) wrote:
> Joel and BMWG,
> 
>> The IETF WG state of draft-ietf-bmwg-sip-bench-term has been
>> changed to "Submitted to IESG for Publication" from "WG
>> Consensus: Waiting for Write-Up" by Al Morton:
>> 
>> http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-term/
> 
> The IETF WG state of draft-ietf-bmwg-sip-bench-meth has been
> changed to "Submitted to IESG for Publication" from "WG Consensus:
> Waiting for Write-Up" by Al Morton:
> 
> http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-meth/
> 
> After a quiet WGLC closing on the 14th, we are declaring WG
> Consensus and submitting the SIP benchmarking terms and methodology
> drafts for publication.
> 
> The combined shepherding forms have been entered in the datatracker
>  for each draft, and appended below.
> 
> Congratulations to the co-authors, and please stay vigilant as the 
> drafts proceed through AD-review, IETF Last Call, and IESG review.
> 
> see you at IETF-90, Al doc shepherd and co-chair
> 
> -=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> This is a publication request for: draft-ietf-bmwg-sip-bench-meth
> -11 2014-07-02   	Active draft-ietf-bmwg-sip-bench-term -11
> 2014-07-02   	Active
> 
> 
> Al Morton is the Document Shepherd, and prepared this form.
> 
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)? Why
> is this the proper type of RFC? Is this type of RFC indicated in
> the title page header?
> 
> Informational, as indicated on the title page. All BMWG RFCs are
> traditionally Informational, in part because they do not define
> protocols and the traditional conditions for Stds track
> advancement did not apply.  However, they are specifications and 
> the RFC 2119 terms are applicable to identify the level of
> requirements.
> 
> (2) 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:
> 
> All networking devices have a limited capacity to serve their 
> purpose. In some cases these limits can be ascertained by counting 
> physical features (e.g., interface card slots), but in other cases 
> standardized tests are required to be sure that all vendors count 
> their protocol-handling capacity in the same way, to avoid
> specmanship. This draft addresses one such case, where the SIP
> session-serving capacity of a device can only be discovered and
> rigorously compared with other devices through isolated laboratory
> testing.
> 
> This document describes the methodology for benchmarking Session 
> -or- This document describes the terminology for benchmarking
> Session Initiation Protocol (SIP) performance as described in SIP 
> benchmarking terminology document.  The methodology and
> terminology are to be used for benchmarking signaling plane
> performance with varying signaling and media load.  Both scale and
> establishment rate are measured by signaling plane performance.
> The SIP Devices to be benchmarked may be a single device under test
> or a system under test.  Benchmarks can be obtained and compared
> for different types of devices such as SIP Proxy Server, Session
> Border Controller, and server paired with a media relay or
> Firewall/NAT device.
> 
> Working Group Summary:
> 
> There were periods of intense and constructive feedback on this
> draft, but also several pauses in progress during development. The
> most lively discussions were prompted by presentation of actual
> test results using the draft methods, which require significant
> time investment but are well- worth the result. These drafts serve
> a useful purpose for the industry.
> 
> Document Quality:
> 
> There are existing implementations of the method, as noted above.
> 
> Dale Worley conducted an early review, following BMWG's request of
> the RAI area.  Dales's comments were addressed in version 05. 
> Henning Schulzrinne commented on the original work proposal.
> 
> Personnel:
> 
> Who is the Document Shepherd? Who is the Responsible Area
> Director? Al Morton is Shepherd, Joel Jaeggli is Responsible AD.
> 
> (3) Briefly describe the review of this document that was performed
> by the Document Shepherd. If this version of the document is not
> ready for publication, please explain why the document is being
> forwarded to the IESG.
> 
> The shepherd has reviewed the drafts many times, and his comments
> are in the BMWG archive.
> 
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed? No.
> 
> (5) Do portions of the document need review from a particular or
> from broader perspective, e.g., security, operational complexity,
> AAA, DNS, DHCP, XML, or internationalization? If so, describe the
> review that took place.
> 
> No. Cross-area review has been obtained, however it impossible to
> get the attention of everyone who considers themselves a SIP
> expert.
> 
> (6) Describe any specific concerns or issues that the Document
> Shepherd has 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 concerns, this is still a valuable memo, as mentioned above.
> 
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of
> BCP 78 and BCP 79 have already been filed. If not, explain why?
> 
> There are not outstanding IPR disclosures, according to the
> authors.
> 
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.
> 
> No.
> 
> (9) 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?
> 
> Although the comments and review intensity was highly variable, it
> now appears that the WG is satisfied. The first WGLC was completed
> on 5 April 2010 with comments. The second WGLC was completed on 18
> May 2012 with comments. The third WGLC was completed on 10 Dec 2012
> with comments, and the 1st Pub Request. A IETF Last Call followed,
> and completed on 30 Jan 2013 with comments. A fourth WGLC was
> completed 11 June 2014 with comments from expert review. The
> current versions (11) address Dale Worley's RAI area early review 
> and Robert Spark's reviews. The fifth WGLC completed quietly on
> July 14th, 2014.
> 
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> publicly available.)
> 
> No.
> 
> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the
> Internet-Drafts Checklist). Boilerplate checks are not enough; this
> check needs to be thorough.
> 
> Nits are warnings requiring no action for these drafts.
> 
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type
> reviews.
> 
> N/A
> 
> (13) Have all references within this document been identified as
> either normative or informative?
> 
> Yes.
> 
> (14) 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 plan for their completion?
> 
> The -term and -meth drafts are proceeding toward publication as a
> pair.
> 
> (15) Are there downward normative references references (see RFC
> 3967)? If so, list these downward references to support the Area
> Director in the Last Call procedure.
> 
> No.
> 
> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header,
> listed in the abstract, and discussed in the introduction? If the
> RFCs are not listed in the Abstract and Introduction, explain why,
> and point to the part of the document where the relationship of
> this document to the other RFCs is discussed. If this information
> is not in the document, explain why the WG considers it
> unnecessary.
> 
> No.
> 
> (17) Describe the Document Shepherd's review of the IANA
> considerations section, especially with regard to its consistency
> with the body of the document. Confirm that all protocol extensions
> that the document makes are associated with the appropriate
> reservations in IANA registries. Confirm that any referenced IANA
> registries have been clearly identified. Confirm that newly created
> IANA registries include a detailed specification of the initial
> contents for the registry, that allocations procedures for future
> registrations are defined, and a reasonable name for the new
> registry has been suggested (see RFC 5226).
> 
> No requests of IANA.
> 
> (18) List any new IANA registries that require Expert Review for
> future allocations. Provide any public guidance that the IESG would
> find useful in selecting the IANA Experts for these new
> registries.
> 
> N/A
> 
> (19) Describe reviews and automated checks performed by the
> Document Shepherd to validate sections of the document written in a
> formal language, such as XML code, BNF rules, MIB definitions,
> etc.
> 
> N/A
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPKe5IACgkQ8AA1q7Z/VrL1mQCfedJHe0gFQN6JSnTBZONV4cr2
Ab8Anj0V2KcBiKUEmjFjJrtc+Id9C38Z
=/M2E
-----END PGP SIGNATURE-----