[CCAMP] Please publish draft-ietf-ccamp-dpm-06.txt
Lou Berger <lberger@labn.net> Fri, 08 June 2012 20:51 UTC
Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F91911E818A for <ccamp@ietfa.amsl.com>; Fri, 8 Jun 2012 13:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.693
X-Spam-Level:
X-Spam-Status: No, score=-99.693 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGEXgR-PNLKG for <ccamp@ietfa.amsl.com>; Fri, 8 Jun 2012 13:51:54 -0700 (PDT)
Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 72EFE11E8187 for <ccamp@ietf.org>; Fri, 8 Jun 2012 13:51:54 -0700 (PDT)
Received: (qmail 4288 invoked by uid 0); 8 Jun 2012 20:51:51 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 8 Jun 2012 20:51:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=to7btxBNsb6u+j+4vKwjkvQKnv+xwUb4iyoh/S9x7ts=; b=2CdIeYKR6FJHgc7wXrygeoU55TxhUhZvaHJJPFyiAVomazCzO8oZTsPiiq8FAfvWhOQ05fbtaMwLZQO378kb+3N7MUZ8YNpKLaDPh7C5ndhlmV624AywbtRqU/ogKlBS;
Received: from box313.bluehost.com ([69.89.31.113]:47453 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1Sd69v-0003M8-Bp; Fri, 08 Jun 2012 14:51:51 -0600
Message-ID: <4FD265E5.8080306@labn.net>
Date: Fri, 08 Jun 2012 16:51:49 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Adrian Farrel <afarrel@juniper.net>, The IESG <iesg-secretary@ietf.org>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: CCAMP <ccamp@ietf.org>
Subject: [CCAMP] Please publish draft-ietf-ccamp-dpm-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jun 2012 20:51:56 -0000
Proto-write-up for: draft-ietf-ccamp-dpm-06.txt > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Standards Track. > Why is this the proper type of RFC? It defines test methodology and metrics of the kind defined in [RFC2679], [RFC2681] and [RFC5814], all of which are Standards Track. > Is this type of RFC indicated in the title page header? Yes. > > > (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 This document defines a series of performance metrics to evaluate the availability of data path during the signaling process. The metrics defined in this document complements the control plane metrics defined in [RFC5814]. These metrics can be used to verify the conformance of implementations against related specifications, as elaborated in [RFC6383]. > 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? No. Document was a result of discussions that took place related to RFC5814. There were no objections raised to it's publication. > 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? > Implementation status is unknown (as is often the case), but contributors include a number of different types of vendors and carriers. Al Morton commented on the document while it was being moved through the working group. He also reviewed it as a member of the Performance Metrics Directorate. > > Personnel > > Who is the Document Shepherd? Who is the Responsible Area > Director? Lou Berger is the Document Shepherd. Adrian Farrel is the Area Director. > > (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. To document was reviewed a number of times as it progressed through the WG, as well as during WG last call. The document is ready for publication. > > > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? > No concerns. > > (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. The document was reviewed by the Performance Metrics Directorate (Al Morton). > (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. > (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. Yes. > (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? The WG supports this document, but not may are passionate about it. > (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. No issues. > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. > (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? No. > (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). Not applicable. > (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. Not applicable. > (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. Not applicable.