From nobody Tue Oct 7 05:56:15 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037761A1BE3; Tue, 7 Oct 2014 05:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSSs4CkBe7B5; Tue, 7 Oct 2014 05:56:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B41D51A1BC6; Tue, 7 Oct 2014 05:56:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141007125609.6579.8123.idtracker@ietfa.amsl.com> Date: Tue, 07 Oct 2014 05:56:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/JZD0FbCZJnfCKfih0x3rBSWOLE0 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-lmap-path-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 12:56:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance Authors : Marcelo Bagnulo Trevor Burbridge Sam Crawford Phil Eardley Al Morton Filename : draft-ietf-ippm-lmap-path-07.txt Pages : 16 Date : 2014-10-07 Abstract: This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. Other similar measurement projects may also be able to use the extensions described here for measurement point location. The purpose is to create an efficient way to describe the location of the measurement point(s) used to conduct a particular measurement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-lmap-path/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-lmap-path-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-lmap-path-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 7 06:20:44 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9039E1A212D; Tue, 7 Oct 2014 06:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0u5GqF7RuklL; Tue, 7 Oct 2014 06:20:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D48E51A2119; Tue, 7 Oct 2014 06:20:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141007132034.32523.1882.idtracker@ietfa.amsl.com> Date: Tue, 07 Oct 2014 06:20:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/FE4uXt6xtDrGnv8n1bikRtjNRm8 Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-morton-ippm-2680-bis-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 13:20:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A One-Way Loss Metric for IPPM Authors : Guy Almes Sunil Kalidindi Matt Zekauskas Al Morton Filename : draft-morton-ippm-2680-bis-04.txt Pages : 20 Date : 2014-10-07 Abstract: This memo (RFC 2680 bis) defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-morton-ippm-2680-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-morton-ippm-2680-bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-morton-ippm-2680-bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 7 06:23:37 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037AC1A6EDE; Tue, 7 Oct 2014 06:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btUXk4y8wObf; Tue, 7 Oct 2014 06:23:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A691A6EDB; Tue, 7 Oct 2014 06:23:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141007132332.3230.34899.idtracker@ietfa.amsl.com> Date: Tue, 07 Oct 2014 06:23:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/aJuOH-MJL8e1rWeBYdBlETF1y0w Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-morton-ippm-2679-bis-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 13:23:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A One-Way Delay Metric for IPPM Authors : Guy Almes Sunil Kalidindi Matt Zekauskas Al Morton Filename : draft-morton-ippm-2679-bis-06.txt Pages : 24 Date : 2014-10-07 Abstract: This memo (RFC 2679 bis) defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-morton-ippm-2679-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-morton-ippm-2679-bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-morton-ippm-2679-bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 7 07:05:39 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613181A9142 for ; Tue, 7 Oct 2014 06:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.988 X-Spam-Level: X-Spam-Status: No, score=-4.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH66zo4tvuyJ for ; Tue, 7 Oct 2014 06:38:11 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8248C1A6EDC for ; Tue, 7 Oct 2014 06:38:11 -0700 (PDT) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id B07BC121331; Tue, 7 Oct 2014 09:46:56 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-azure.research.att.com (Postfix) with ESMTP id DD3EEE023D; Tue, 7 Oct 2014 09:38:10 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Tue, 7 Oct 2014 09:38:10 -0400 From: "MORTON, ALFRED C (AL)" To: "ippm-chairs@tools.ietf.org" Date: Tue, 7 Oct 2014 09:38:10 -0400 Thread-Topic: [ippm] I-D Action: draft-morton-ippm-2679-bis-06.txt Thread-Index: Ac/iMe/tCPX0qfC0SjWhmdeN/AQotAAAIf9I Message-ID: <4AF73AA205019A4C8A1DDD32C034631D797C6117@NJFPSRVEXG0.research.att.com> References: <20141007132332.3230.34899.idtracker@ietfa.amsl.com> In-Reply-To: <20141007132332.3230.34899.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/cpuAn-avH2ip_49ZHjBLgiGAaOY X-Mailman-Approved-At: Tue, 07 Oct 2014 07:05:35 -0700 Cc: "ippm@ietf.org" Subject: Re: [ippm] I-D Action: draft-morton-ippm-2679-bis-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 13:38:13 -0000 Bill and Brian, IPPM, As discussed in Toronto, I've updated both of the "bis" drafts, according to the slides I presented there. Also, the sections describing changes from the original specs needed update (these are mandatory sections, as I understand it), so that's now done. Last, the "temporary" Reference sections are now incorporated with =20 normal XML xref syntax. I left these named "draft-morton-" for easy diff with previous versions. My plan is to upload draft-ietf-ippm versions soon, with unused references removed, and a new set of ACKs for those who have helped with their=20 reviews so far. There are still about two open issues from Joachim's review, but I will=20 pursue these with him shortly. regards, Al "guest editor" ________________________________________ From: ippm [ippm-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org [i= nternet-drafts@ietf.org] Sent: Tuesday, October 07, 2014 9:23 AM To: i-d-announce@ietf.org Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-morton-ippm-2679-bis-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of t= he IETF. Title : A One-Way Delay Metric for IPPM Authors : Guy Almes Sunil Kalidindi Matt Zekauskas Al Morton Filename : draft-morton-ippm-2679-bis-06.txt Pages : 24 Date : 2014-10-07 Abstract: This memo (RFC 2679 bis) defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-morton-ippm-2679-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-morton-ippm-2679-bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-morton-ippm-2679-bis-06 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Tue Oct 7 08:28:31 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377F51A6FAB; Tue, 7 Oct 2014 08:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYoDAMW_lIKb; Tue, 7 Oct 2014 08:28:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDF01A6F9C; Tue, 7 Oct 2014 08:28:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141007152827.25462.89556.idtracker@ietfa.amsl.com> Date: Tue, 07 Oct 2014 08:28:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/GYSwEdaB3cu69Qohze5hJd7TLHc Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 15:28:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Rate Measurement Test Protocol Problem Statement Author : Al Morton Filename : draft-ietf-ippm-rate-problem-07.txt Pages : 12 Date : 2014-10-07 Abstract: This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. The rate measurement scenario has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-rate-problem-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 9 06:49:11 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C8B1A1B37; Thu, 9 Oct 2014 06:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs0TP8ngzWXZ; Thu, 9 Oct 2014 06:48:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 670901ACEF6; Thu, 9 Oct 2014 06:48:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141009134848.14423.76522.idtracker@ietfa.amsl.com> Date: Thu, 09 Oct 2014 06:48:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/JbPPa5s-en7Gbf2ZlMdAHPXwvhE Cc: ippm mailing list , ippm chair , RFC Editor Subject: [ippm] Document Action: 'A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance' to Informational RFC (draft-ietf-ippm-lmap-path-07.txt) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 13:49:06 -0000 The IESG has approved the following document: - 'A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance' (draft-ietf-ippm-lmap-path-07.txt) as Informational RFC This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ippm-lmap-path/ Technical Summary This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. The methods for measurement point location may be applicable to similar measurement projects using the extensions described here. Working Group Summary The document has had broad review within the IPPM and LMAP working groups. Many comments were received during first WGLC resulting in a substantial revision and a second WGLC. There is consensus within the IPPM working group (including participants from LMAP) to publish the document. Document Quality This document defines the reference path to be used in metric definitions and provides other guidance on how to use and deploy IPPM metrics in an LMAP context. Personnel The document shepherd is Brian Trammell. The responsible Area Director is Spencer Dawkins. From nobody Fri Oct 10 09:49:04 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18791A8A8B for ; Fri, 10 Oct 2014 09:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14I9DhxNlrhF for ; Fri, 10 Oct 2014 09:49:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 110281A9028 for ; Fri, 10 Oct 2014 09:43:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141010164333.30112.24757.idtracker@ietfa.amsl.com> Date: Fri, 10 Oct 2014 09:43:33 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/7itYgnVAtuqpMYQrLjZ9zvww43U Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 16:49:03 -0000 Changed milestone "Submit draft updating the IPPM Framework (2330-update) to IESG as Proposed Standard", resolved as "Done". Deleted milestone "Submit draft on registry for active performance metrics to IESG as Proposed Standard". Deleted milestone "Submit draft on registry for passive performance metrics to IESG as Proposed Standard". URL: http://datatracker.ietf.org/wg/ippm/charter/ From nobody Fri Oct 10 15:01:58 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DC31A8861 for ; Fri, 10 Oct 2014 15:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlQFZDdpdRXa for ; Fri, 10 Oct 2014 15:01:50 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 29C6E1AD423 for ; Fri, 10 Oct 2014 15:01:50 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 1D55A12277E; Fri, 10 Oct 2014 18:06:55 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id 44FC8F03FF; Fri, 10 Oct 2014 17:57:56 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Fri, 10 Oct 2014 17:57:56 -0400 From: "MORTON, ALFRED C (AL)" To: "draft-elkins-ippm-pdm-option@tools.ietf.org" Date: Fri, 10 Oct 2014 17:57:28 -0400 Thread-Topic: draft-elkins-ippm-pdm-option-01 Thread-Index: AQHP5NUujtOkr2pKe0Gp1+IUVJuKMw== Message-ID: <4AF73AA205019A4C8A1DDD32C034631D797C6136@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_4AF73AA205019A4C8A1DDD32C034631D797C6136NJFPSRVEXG0rese_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/B-j1BJkunZO_SZj6xUF1YJmVwl4 Cc: "ippm@ietf.org" Subject: [ippm] draft-elkins-ippm-pdm-option-01 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 22:01:56 -0000 --_002_4AF73AA205019A4C8A1DDD32C034631D797C6136NJFPSRVEXG0rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nalini, Mike, Robert, I finally made time to read your draft, I see it has been revised since I originally added intended to read it, that's progress. My detailed comments are in the text file attached, you can search for "ACM:" if necessary, but there are quite a few. One main area to sort out is terminology: the fields in the PDM, like timestamps and sequence numbers, are information for making measurements and calculating metrics. So the fields are the info, not metrics themselves. The concepts of metrics, measurements and measured results are important to sort-out, everywhere I've been recently this is an important first step. regards, Al --_002_4AF73AA205019A4C8A1DDD32C034631D797C6136NJFPSRVEXG0rese_ Content-Type: text/plain; name="draft-elkins-ippm-pdm-option-00_ACM.txt" Content-Description: draft-elkins-ippm-pdm-option-00_ACM.txt Content-Disposition: attachment; filename="draft-elkins-ippm-pdm-option-00_ACM.txt"; size=34212; creation-date="Fri, 10 Oct 2014 21:57:38 GMT"; modification-date="Fri, 10 Oct 2014 21:57:38 GMT" Content-Transfer-Encoding: base64 IA0KDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTi4gRWxraW5zDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBJbnNpZGUgUHJvZHVjdHMNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBIYW1pbHRv bg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENoZW1pY2Fs IEFic3RyYWN0cyBTZXJ2aWNlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBNLiBBY2tlcm1hbm4NCkludGVuZGVkIFN0YXR1czogUHJv cG9zZWQgU3RhbmRhcmQgICAgICAgICAgICAgICAgICAgICAgICAgQkNCUyBNaWNoaWdhbg0KRXhw aXJlczogTWFyY2ggMjAxNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlcHRl bWJlciA4LCAyMDE0DQoNCg0KDQoNCiAgICAgICAgSVBQTSBDb25zaWRlcmF0aW9ucyBmb3IgdGhl IElQdjYgUERNIERlc3RpbmF0aW9uIE9wdGlvbg0KICAgICAgICAgICAgICAgICAgZHJhZnQtZWxr aW5zLWlwcG0tcGRtLW9wdGlvbi0wMC50eHQgDQoNCi4uLg0KQWJzdHJhY3QNCg0KICAgVG8gbWVh c3VyZSBwZXJmb3JtYW5jZSBhbmQgdG8gZGlhZ25vc2UgcGVyZm9ybWFuY2UgYW5kIGNvbm5lY3Rp dml0eQpBQ006CiAgIFRvIGFzc2VzcyBwZXJmb3JtYW5jZSAuIC4gLgoNCiAgIHByb2JsZW1zLCBt ZXRyaWNzIGVtYmVkZGVkIGluIGVhY2ggcGFja2V0IGFyZSBjcml0aWNhbCBmb3IgdGltZWx5IGFu ZApBQ006CiJtZXRyaWNzIiBhcmUgbm90IGVtYmVkZGVkLCBtZXRyaWNzIGFyZSBtZWFzdXJlZCAu IC4gLgpzdWdnZXN0OgptZWFzdXJlbWVudHMgYmFzZWQgb24gb3B0aW9uYWwgc2VxdWVuY2UgbnVt YmVycyAoYW5kIHRpbWVzdGFtcHMgPykgCmVtYmVkZGVkIGluIGVhY2ggcGFja2V0LiAuIC4KDQog ICBhY2N1cmF0ZSBwcm9ibGVtIHJlc29sdXRpb24uIFN1Y2ggZGlhZ25vc3RpY3MgbWF5IGJlIGlu dGVycHJldGVkIGluDQogICByZWFsLXRpbWUgb3IgYWZ0ZXIgdGhlIGZhY3QuIFRoZSBiYXNlIG1l dHJpY3MgYXJlOiBwYWNrZXQgc2VxdWVuY2UNCiAgIG51bWJlciBhbmQgcGFja2V0IHRpbWluZy4g CkFDTToKbWF5YmUgZGVsZXRlIHRoaXMgc2VudGVuY2Ugbm93ICh0aGUgYmFzZSBtZXRyaWNzIC4g LiAuKQoKICAgQW4gaW1wbGVtZW50YXRpb24gb2YgdGhlIGV4aXN0aW5nIElQdjYNCiAgIERlc3Rp bmF0aW9uIE9wdGlvbnMgZXh0ZW5zaW9uIGhlYWRlciwgdGhlIFBlcmZvcm1hbmNlIGFuZCBEaWFn bm9zdGljDQogICBNZXRyaWNzIChQRE0pIERlc3RpbmF0aW9uIE9wdGlvbnMgZXh0ZW5zaW9uIGhl YWRlciBoYXMgYmVlbiBwcm9wb3NlZC4KQUNNOgouIC4gLiBpbiBhIGNvbXBhbmlvbiBkb2N1bWVu dD8KDQogICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIG1ldHJpY3MsIGZpZWxkIGxpbWl0 cywgY2FsY3VsYXRpb24sIGFuZA0KICAgdXNhZ2Ugb2YgdGhlIFBETS4KQUNNOiBzdWdnZXN0CiAg ICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgZmllbGQgbGltaXRzLCBjYWxjdWxhdGlvbnMs IGFuZCANCiAgIHVzYWdlIG9mIHRoZSBQRE0gaW4gbWVhc3VyZW1lbnQuDQoNClN0YXR1cyBvZiB0 aGlzIE1lbW8NCg0KLiAuIC4NCg0KMSAgQmFja2dyb3VuZA0KCkFDTToKc2FtZSBmaXhlcyBhcyBB YnN0cmFjdCBiZWxvdy4NCiAgIFRvIG1lYXN1cmUgcGVyZm9ybWFuY2UgYW5kIHRvIGRpYWdub3Nl IHBlcmZvcm1hbmNlIGFuZCBjb25uZWN0aXZpdHkNCiAgIHByb2JsZW1zLCBtZXRyaWNzIGVtYmVk ZGVkIGluIGVhY2ggcGFja2V0IGFyZSBjcml0aWNhbCBmb3IgdGltZWx5IGFuZA0KICAgYWNjdXJh dGUgcHJvYmxlbSByZXNvbHV0aW9uLiBTdWNoIGRpYWdub3N0aWNzIG1heSBiZSBpbnRlcnByZXRl ZCBpbg0KICAgcmVhbC10aW1lIG9yIGFmdGVyIHRoZSBmYWN0LiBUaGUgYmFzZSBtZXRyaWNzIGFy ZTogcGFja2V0IHNlcXVlbmNlDQogICBudW1iZXIgYW5kIHBhY2tldCB0aW1pbmcuICBBbiBpbXBs ZW1lbnRhdGlvbiBvZiB0aGUgZXhpc3RpbmcgSVB2Ng0KICAgRGVzdGluYXRpb24gT3B0aW9ucyBl eHRlbnNpb24gaGVhZGVyLCB0aGUgUGVyZm9ybWFuY2UgYW5kIERpYWdub3N0aWMNCiAgIE1ldHJp Y3MgKFBETSkgRGVzdGluYXRpb24gT3B0aW9ucyBleHRlbnNpb24gaGVhZGVyIGhhcyBiZWVuIHBy b3Bvc2VkLg0KICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBtZXRyaWNzLCBmaWVsZCBs aW1pdHMsIGNhbGN1bGF0aW9uLCBhbmQNCiAgIHVzYWdlIG9mIHRoZSBQRE0uDQoNCg0KMS4xIFRl cm1pbm9sb2d5DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlS RUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJS RUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBh cmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4N Cg0KMS4yIEVuZCBVc2VyIFF1YWxpdHkgb2YgU2VydmljZSAoUW9TKQ0KDQogICBUaGUgZGVsdGEg dmFsdWVzIGluIHRoZSBQRE0gdHJhdmVsaW5nIGFsb25nIHdpdGggdGhlIHBhY2tldCB3aWxsIGJl CkFDTToKICAgVGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB2YWx1ZXMgaW4gdGhlIFBETSAuIC4gLgoN CiAgIHVzZWQgdG8gY2FsY3VsYXRlIFFvUyBhcyBleHBlcmllbmNlZCBieSBhbiBlbmQgdXNlciBk ZXZpY2UuDQpBQ006CiAgIHVzZWQgdG8gZXN0aW1hdGUgLiAuIC4gDQogDQoNCg0KRWxraW5zICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIwMTUgICAgICAgICAgICAgICAgIFtQ YWdlIDNdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgIGVsa2lucy1pcHBtLXBkbS1tZXRyaWNz LTAwICAgICAgU2VwdGVtcGVyIDQsIDIwMTQNCg0KDQogICBFbmQtdG8tZW5kIHJlc3BvbnNlIGlz IHdoYXQgdGhlIHVzZXIgb2YgYSBuZXR3b3JrIHN5c3RlbSBhY3R1YWxseQpBQ006CkZvciBtYW55 IGFwcGxpY2F0aW9ucywgdGhlIGtleSB1c2VyIHBlcmZvcm1hbmNlIGluZGljYXRvciBpcyByZXNw b25zZSB0aW1lLgoNCiAgIGV4cGVyaWVuY2VzLiAgV2hlbiB0aGUgZW5kIHVzZXIgaXMgYW4gaW5k aXZpZHVhbCwgaGUgaXMgZ2VuZXJhbGx5DQogICBpbmRpZmZlcmVudCB0byB3aGF0IGlzIGhhcHBl bmluZyBhbG9uZyB0aGUgbmV0d29yazsgd2hhdCBoZSByZWFsbHkNCiAgIGNhcmVzIGFib3V0IGlz IGhvdyBsb25nIGl0IHRha2VzIHRvIGdldCBhIHJlc3BvbnNlIGJhY2suICBCdXQgdGhpcyBpcw0K ICAgbm90IGp1c3QgYSBtYXR0ZXIgb2YgaW5kaXZpZHVhbHMnIHBlcnNvbmFsIGNvbnZlbmllbmNl LiAgSW4gbWFueQ0KICAgY2FzZXMsIHJhcGlkIHJlc3BvbnNlIGlzIGNyaXRpY2FsIHRvIHRoZSBi dXNpbmVzcyBiZWluZyBjb25kdWN0ZWQuDQoNCiAgIFdoZW4gdGhlIGVuZCB1c2VyIGlzIGEgZGV2 aWNlIChlLmcuIHdpdGggdGhlIEludGVybmV0IG9mIFRoaW5ncyksDQogICB3aGF0IG1hdHRlcnMg aXMgdGhlIHNwZWVkIHdpdGggd2hpY2ggcmVxdWVzdGVkIGRhdGEgY2FuIGJlDQogICB0cmFuc2Zl cnJlZCAtLSBzcGVjaWZpY2FsbHksIHdoZXRoZXIgdGhlIHJlcXVlc3RlZCBkYXRhIGNhbiBiZQ0K ICAgdHJhbnNmZXJyZWQgaW4gdGltZSB0byBhY2NvbXBsaXNoIHRoZSBkZXNpcmVkIGFjdGlvbnMu ICBUaGlzIGNhbiBiZQ0KICAgaW1wb3J0YW50IHdoZW4gdGhlIHJlbGV2YW50IGV4dGVybmFsIGNv bmRpdGlvbnMgYXJlIHN1YmplY3QgdG8gcmFwaWQNCiAgIGNoYW5nZS4NCg0KICAgUmVzcG9uc2Ug dGltZSBhbmQgY29uc2lzdGVuY3kgYXJlIG5vdCBqdXN0ICJuaWNlIHRvIGhhdmUiLiAgT24gbWFu eQ0KICAgbmV0d29ya3MsIHRoZSBpbXBhY3QgY2FuIGJlIGZpbmFuY2lhbCBoYXJkc2hpcCBvciBl bmRhbmdlciBodW1hbg0KICAgbGlmZS4gIEluIHNvbWUgY2l0aWVzLCB0aGUgZW1lcmdlbmN5IHBv bGljZSBjb250YWN0IHN5c3RlbSBvcGVyYXRlcw0KICAgb3ZlciBJUCwgbGF3IGVuZm9yY2VtZW50 IHVzZXMgVENQL0lQIG5ldHdvcmtzLCB0cmFuc2FjdGlvbnMgb24gb3VyDQogICBzdG9jayBleGNo YW5nZXMgYXJlIHNldHRsZWQgdXNpbmcgSVAgbmV0d29ya3MuICBUaGUgY3JpdGljYWwgbmF0dXJl DQogICBvZiBzdWNoIGFjdGl2aXRpZXMgdG8gb3VyIGRhaWx5IGxpdmVzIGFuZCBmaW5hbmNpYWwg d2VsbC1iZWluZyBkZW1hbmQNCiAgIGEgc29sdXRpb24uICAgDQoNCjEuMyAgV2h5IFBhY2tldCBT ZXF1ZW5jZSBOdW1iZXIKQUNNOgo/IE5lZWQgZm9yIGEgUGFja2V0IFNlcXVlbmNlIE51bWJlcg0K DQogICBXaGlsZSBwZXJmb3JtaW5nIG5ldHdvcmsgZGlhZ25vc3RpY3Mgb2YgYW4gZW5kLXRvLWVu ZCBjb25uZWN0aW9uLCBpdA0KICAgb2Z0ZW4gYmVjb21lcyBuZWNlc3NhcnkgdG8gZmluZCB0aGUg ZGV2aWNlIGFsb25nIHRoZSBuZXR3b3JrIHBhdGgNCiAgIGNyZWF0aW5nIHByb2JsZW1zLiAgRGlh Z25vc3RpYyBkYXRhIG1heSBiZSBjb2xsZWN0ZWQgYXQgbXVsdGlwbGUNCiAgIHBsYWNlcyBhbG9u ZyB0aGUgcGF0aCAoaWYgcG9zc2libGUpLCBvciBhdCB0aGUgc291cmNlIGFuZA0KICAgZGVzdGlu YXRpb24uIFRoZW4sIHRoZSBkaWFnbm9zdGljIGRhdGEgbXVzdCBiZSBtYXRjaGVkLiAgCkFDTToK VGhlbiwgdGhlIGRpYWdub3N0aWMgZGF0YSBjb3JyZXNwb25kaW5nIHRvIGVhY2ggcGFja2V0IGF0 IGRpZmZlcmVudApvYnNlcnZhdGlvbiBwb2ludHMgbXVzdCBiZSBtYXRjaGVkIGZvciBwcm9wZXIg bWVhc3VyZW1lbnRzLgpBIHNlcXVlbmNlIG51bWJlciBpbiBlYWNoIHBhY2tldCBwcm92aWRlcyBz dWZmaWNpZW50IGJhc2lzIGZvciB0aGUgCm1hdGNoaW5nIHByb2Nlc3MuICANCg0KICAgVGhpcyBt ZXRob2Qgb2YgZGF0YSBjb2xsZWN0aW9uIGFsb25nIHRoZSBwYXRoIGlzIG9mIHNwZWNpYWwgdXNl IG9uDQogICBsYXJnZSBtdWx0aS10aWVyIG5ldHdvcmtzIHRvIGRldGVybWluZSB3aGVyZSBwYWNr ZXQgbG9zcyBvciBwYWNrZXQNCiAgIGNvcnJ1cHRpb24gaXMgaGFwcGVuaW5nLiAgTXVsdGktdGll ciBuZXR3b3JrcyBhcmUgdGhvc2Ugd2hpY2ggaGF2ZQ0KICAgbXVsdGlwbGUgcm91dGVycyBvciBz d2l0Y2hlcyBvbiB0aGUgcGF0aCBiZXR3ZWVuIHRoZSBzZW5kZXIgYW5kIHRoZQ0KICAgcmVjZWl2 ZXIuCkFDTToKSG1tLCBNdWx0aS10aWVyIGlzIHVuZmFtaWxpYXIgdGVybWlub2xvZ3kuICBNb3N0 IG5ldHdvcmtzIGhhdmUgbWFueQpyb3V0ZXJzIGFuZCBzd2l0Y2hlcyBvbiB0aGUgcGF0aCwgd2hh dCBpcyBzcGVjaWFsIGhlcmU/DQoNCiAgIFRoZSBwYWNrZXQgc2VxdWVuY2UgbnVtYmVyIG5lZWRz IHRvIGJlIHVuaXF1ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUNCiAgIHNlc3Npb24gKDUtdHVwbGUp Lg0KDQoxLjQgUmF0aW9uYWxlIGZvciBwcm9wb3NlZCBzb2x1dGlvbg0KDQogICBUaGUgY3VycmVu dCBJUHY2IHNwZWNpZmljYXRpb24gZG9lcyBub3QgcHJvdmlkZSB0aW1pbmcgbm9yIGEgc2ltaWxh cg0KICAgZmllbGQgaW4gdGhlIElQdjYgbWFpbiBoZWFkZXIgb3IgaW4gYW55IGV4dGVuc2lvbiBo ZWFkZXIuIFNvLCB3ZQ0KICAgcHJvcG9zZSB0aGUgSVB2NiBQZXJmb3JtYW5jZSBhbmQgRGlhZ25v c3RpYyBNZXRyaWNzIGRlc3RpbmF0aW9uDQogICBvcHRpb24gKFBETSkgW0VMSy1QRE1dLg0KDQog ICBBZHZhbnRhZ2VzIGluY2x1ZGU6DQogDQoNCg0KRWxraW5zICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgTWFyY2ggMTIsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJTlRFUk5F VCBEUkFGVCAgICAgICAgIGVsa2lucy1pcHBtLXBkbS1tZXRyaWNzLTAwICAgICAgU2VwdGVtcGVy IDQsIDIwMTQNCg0KDQogICAxLiAgUmVhbCBtZWFzdXJlIG9mIGFjdHVhbCB0cmFuc2FjdGlvbnMu DQogICAyLiAgSW5kZXBlbmRlbmNlIGZyb20gdHJhbnNwb3J0IGxheWVyIHByb3RvY29scy4NCiAg IDMuICBBYmlsaXR5IHRvIHNwYW4gb3JnYW5pemF0aW9uYWwgYm91bmRhcmllcyB3aXRoIGNvbnNp c3RlbnQgDQogICAgICAgaW5zdHJ1bWVudGF0aW9uDQogICA0LiAgTm8gdGltZSBzeW5jaHJvbml6 YXRpb24gbmVlZGVkIGJldHdlZW4gc2Vzc2lvbiBwYXJ0bmVycw0KDQoNCiAgIFRoZSBQRE0gZG9l cyBub3Qgc29sdmUgZXZlcnkgcmVzcG9uc2UgdGltZSBpc3N1ZSBmb3IgZXZlcnkgc2l0dWF0aW9u Lg0KICAgTmV0d29yayBjb25uZWN0aW9ucyB3aXRoIG11bHRpcGxlIGhvcHMgd2lsbCBzdGlsbCBu ZWVkIG1vcmUgZ3JhbnVsYXINCiAgIG1ldHJpY3MsIGFzIHdpbGwgdGhlIGRpZmZlcmVudGlhdGlv biBiZXR3ZWVuIG11bHRpcGxlIGNvbXBvbmVudHMgYXQNCiAgIGVhY2ggaG9zdC4gIApBQ006Ck5v dCBjbGVhciB3aGF0IHRoaXMgY29uZGl0aW9uLCAibXVsdGlwbGUgaG9wcyBuZWVkIG1vcmUgZ3Jh bnVsYXIgbWV0cmljcyIuCkFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlIHJhbmdlIG9mIHRoZSBzZXF1 ZW5jZSBudW1iZXJzIG5lZWRzIHRvIGJlIGxhcmdlciAKaWYgYSBsb25nZXIgcGF0aCBpcyBpbnZv bHZlZD8gT3IgdGhhdCBtb3JlIGludGVybWVkaWF0ZSBtZWFzdXJlbWVudHMgYXJlCm5lZWRlZCBp ZiB0aGUgaG9zdCBvciBuZXR3b3JrIGRpc2NyaW1pbmF0aW9uIGlzIG5vdCBzdWZmaWNpZW50PwoK ICAgVGhhdCBpcywgVENQL0lQIHN0YWNrIHRpbWUgdnMuIGFwcGxpY2F0aW9ucyB0aW1lIHdpbGwN CiAgIHN0aWxsIG5lZWQgdG8gYmUgYnJva2VuIG91dCBieSBjbGllbnQgc29mdHdhcmUuICBXaGF0 IHRoZSBQRE0gZG9lcw0KICAgcHJvdmlkZSBpcyB0aGUgYWJpbGl0eSB0byBkbyByYXBpZCB0cmlh Z2UuICBUaGF0IGlzLCB0byBkZXRlcm1pbmUNCiAgIHF1aWNrbHkgaWYgdGhlIHByb2JsZW0gaXMg aW4gdGhlIG5ldHdvcmsgb3IgaW4gdGhlIHNlcnZlcg0KICAgKGFwcGxpY2F0aW9uKS4KQUNNOiBz dWdnZXN0IHJlcGxhY2UgbGFzdCB0d28gc2VudGVuY2VzIHdpdGg6ClRoZSBQRE0gcHJvdmlkZXMg dGhlIGFiaWxpdHkgdG8gcXVpY2tseSBkZXRlcm1pbmUgaWYgdGhlIChsYXRlbmN5KSAKcHJvYmxl bSBpcyBpbiB0aGUgbmV0d29yayBvciBpbiB0aGUgc2VydmVyIChhcHBsaWNhdGlvbikuDQoNCjIg IE1ldHJpY3MgRGVyaXZlZCBmcm9tIFBETQoKQUNNOgpTbyBJIGhvcGUgd2UncmUgY2xlYXIgb24g Im1ldHJpY3MiIG5vdywgdGhpcyBzZWN0aW9uIGNvdWxkIGJlOgoiMiAgTWVhc3VyZW1lbnQgSW5m b3JtYXRpb24gRGVyaXZlZCBmcm9tIFBETSINCg0KICAgRWFjaCBwYWNrZXQgY29udGFpbnMgaW5m b3JtYXRpb24gYWJvdXQgdGhlIHNlbmRlciBhbmQgcmVjZWl2ZXIuIEluIElQDQogICBwcm90b2Nv bCwgIHRoZSBpZGVudGlmeWluZyBpbmZvcm1hdGlvbiBpcyBjYWxsZWQgYSAiNS10dXBsZSIuICAN Cg0KICAgVGhlIDUtdHVwbGUgY29uc2lzdHMgb2Y6DQoNCiAgICAgIFNBRERSIDogSVAgYWRkcmVz cyBvZiB0aGUgc2VuZGVyDQogICAgICBTUE9SVCA6IFBvcnQgZm9yIHNlbmRlcg0KICAgICAgREFE RFIgOiBJUCBhZGRyZXNzIG9mIHRoZSBkZXN0aW5hdGlvbg0KICAgICAgRFBPUlQgOiBQb3J0IGZv ciBkZXN0aW5hdGlvbg0KICAgICAgUFJPVEMgOiBQcm90b2NvbCBmb3IgdXBwZXIgbGF5ZXIgKGV4 LiBUQ1AsIFVEUCwgSUNNUCwgZXRjLikNCg0KICAgVGhlIFBETSBjb250YWlucyB0aGUgZm9sbG93 aW5nIG1ldHJpY3M6DQoNCg0KICAgICAgUFNOVFAgICAgOiBQYWNrZXQgU2VxdWVuY2UgTnVtYmVy IFRoaXMgUGFja2V0DQogICAgICBQU05MUiAgICA6IFBhY2tldCBTZXF1ZW5jZSBOdW1iZXIgTGFz dCBSZWNlaXZlZA0KICAgICAgREVMVEFMUiAgOiBEZWx0YSBMYXN0IFJlY2VpdmVkDQogICAgICBQ U05MUyAgICA6IFBhY2tldCBTZXF1ZW5jZSBOdW1iZXIgTGFzdCBTZW50DQogICAgICBERUxUQUxT ICA6IERlbHRhIExhc3QgU2VudA0KDQogICBUaGVzZSBtZXRyaWNzLCBjb21iaW5lZCB3aXRoIHRo ZSA1LXR1cGxlLCBhbGxvdyBkZXJpdmF0aW9uIG9mOg0KQUNNOgpUaGlzIGluZm9ybWF0aW9uLCBj b21iaW5lZCB3aXRoIHRoZSA1LXR1cGxlLCBhbGxvd3MgdGhlIG1lYXN1cmVtZW50Cm9mIHRoZSBm b2xsb3dpbmcgbWV0cmljczoKDQogICAgICAxLiAgUm91bmQtdHJpcCBkZWxheQ0KICAgICAgMi4g IFNlcnZlciBkZWxheQ0KDQoyLjEgUm91bmQtVHJpcCBEZWxheQ0KDQogICBSb3VuZC10cmlwIGRl bGF5IGlzIHRoZSB0aW1lIHRha2VuIHRvIHRyYXZlcnNlIHRoZSBwYXRoIGJvdGggd2F5cw0KICAg YmV0d2VlbiBvbmUgbmV0d29yayBkZXZpY2UgdG8gYW5vdGhlci4gIFRoZSBlbnRpcmUgZGVsYXkg dG8gdHJhdmVsDQogICBmcm9tIEEgdG8gQiBhbmQgQiB0byBBIGlzIHVzZWQuIFJvdW5kLXRyaXAg ZGVsYXkgY2Fubm90IHRlbGwgaWYgb25lDQpBQ006ClBsZWFzZSBwYXJhcGhyYXNlIHRoZSBkZWZp bml0aW9uIGluIFJGQyAyNjgxIG1vcmUgY2xvc2VseSBhYm92ZS4NCg0KDQpFbGtpbnMgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2Ug NV0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICAgZWxraW5zLWlwcG0tcGRtLW1ldHJpY3MtMDAg ICAgICBTZXB0ZW1wZXIgNCwgMjAxNA0KDQoNCiAgIHBhdGggaXMgcXVpdGUgZGlmZmVyZW50IGZy b20gYW5vdGhlci4gIFJvdW5kLXRyaXAgZGVsYXkgaXMgZGlzY3Vzc2VkDQogICBpbiAiQSBSb3Vu ZC10cmlwIERlbGF5IE1ldHJpYyBmb3IgSVBQTSIgW1JGQzI2ODFdLg0KDQoyLjIgU2VydmVyIERl bGF5DQoNCiAgIFNlcnZlciBkZWxheSBpcyB0aGUgaW50ZXJ2YWwgYmV0d2VlbiB3aGVuIGEgcGFj a2V0IGlzIHJlY2VpdmVkIGJ5IGENCiAgIGRldmljZSBhbmQgYSBzdWJzZXF1ZW50IHBhY2tldCBp cyBzZW50IGJhY2sgaW4gcmVzcG9uc2UuICAKQUNNOgrJZGV2aWNlIGFuZCB0aGUgZmlyc3QgY29y cmVzcG9uZGluZyBwYWNrZXQgaXMgc2VudCBiYWNrIGluIHJlc3BvbnNlLgoKICAgVGhpcyBtYXkg YmUNCiAgICJTZXJ2ZXIgUHJvY2Vzc2luZyBUaW1lIi4gIEl0IG1heSBhbHNvIGJlIGEgZGVsYXkg Y2F1c2VkIGJ5DQogICBhY2tub3dsZWRnZW1lbnRzLiAgU2VydmVyIHByb2Nlc3NpbmcgdGltZSBp bmNsdWRlcyB0aGUgdGltZSB0YWtlbiBieQ0KICAgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBzdGFj ayBhbmQgYXBwbGljYXRpb24gdG8gcmV0dXJuIHRoZSByZXNwb25zZS4KQUNNOgpNdWNoIG9mICJz dGFjayBkZWxheSIgaXMgcmVsYXRlZCB0byBuZXR3b3JrIHBlcmZvcm1hbmNlLgpOZWVkIHRvIG1h a2UgYSBjbGVhciBkaXN0aW5jdGlvbiBiZXR3ZWVuIHB1cmUgcHJvY2Vzc2luZyB0aW1lIGFuZCAK bmV0d29yay1jYXVzZWQgZGVsYXkgaW4gdGhlIHN0YWNrLg0KDQozIFBlcmZvcm1hbmNlIGFuZCBE aWFnbm9zdGljIE1ldHJpY3MgRGVzdGluYXRpb24gT3B0aW9uIExheW91dA0KDQozLjEgIERlc3Rp bmF0aW9uIE9wdGlvbnMgSGVhZGVyDQoNCiAgIFRoZSBJUHY2IERlc3RpbmF0aW9uIE9wdGlvbnMg SGVhZGVyIGlzIHVzZWQgdG8gY2Fycnkgb3B0aW9uYWwNCiAgIGluZm9ybWF0aW9uIHRoYXQgbmVl ZCBiZSBleGFtaW5lZCBvbmx5IGJ5IGEgcGFja2V0J3MgZGVzdGluYXRpb24NCiAgIG5vZGUocyku IFRoZSBEZXN0aW5hdGlvbiBPcHRpb25zIEhlYWRlciBpcyBpZGVudGlmaWVkIGJ5IGEgTmV4dA0K ICAgSGVhZGVyIHZhbHVlIG9mIDYwIGluIHRoZSBpbW1lZGlhdGVseSBwcmVjZWRpbmcgaGVhZGVy IGFuZCBpcyBkZWZpbmVkDQogICBpbiBSRkMyNDYwIFtSRkMyNDYwXS4gVGhlIElQdjYgUGVyZm9y bWFuY2UgYW5kIERpYWdub3N0aWMgTWV0cmljcw0KICAgRGVzdGluYXRpb24gT3B0aW9uIChQRE0p IGlzIGFuIGltcGxlbWVudGF0aW9uIG9mIHRoZSBEZXN0aW5hdGlvbg0KICAgT3B0aW9ucyBIZWFk ZXIgKE5leHQgSGVhZGVyIHZhbHVlID0gNjApLiAgVGhlIFBETSBkb2VzIG5vdCByZXF1aXJlDQog ICB0aW1lIHN5bmNocm9uaXphdGlvbi4NCg0KMy4yICBQZXJmb3JtYW5jZSBhbmQgRGlhZ25vc3Rp YyBNZXRyaWNzIERlc3RpbmF0aW9uIE9wdGlvbg0KDQogICBUaGUgSVB2NiBQZXJmb3JtYW5jZSBh bmQgRGlhZ25vc3RpYyBNZXRyaWNzIERlc3RpbmF0aW9uIE9wdGlvbiAoUERNKQ0KICAgY29udGFp bnMgdGhlIGZvbGxvd2luZyBmaWVsZHM6DQoNCiAgICAgIFRJTUVCQVNFIDogQmFzZSB0aW1lciB1 bml0DQogICAgICBTQ0FMRURMICA6IFNjYWxlIGZvciBEZWx0YSBMYXN0IFJlY2VpdmVkDQogICAg ICBTQ0FMRURTICA6IFNjYWxlIGZvciBEZWx0YSBMYXN0IFNlbnQNCiAgICAgIFBTTlRQICAgIDog UGFja2V0IFNlcXVlbmNlIE51bWJlciBUaGlzIFBhY2tldA0KICAgICAgUFNOTFIgICAgOiBQYWNr ZXQgU2VxdWVuY2UgTnVtYmVyIExhc3QgUmVjZWl2ZWQNCiAgICAgIERFTFRBTFIgIDogRGVsdGEg TGFzdCBSZWNlaXZlZA0KICAgICAgREVMVEFMUyAgOiBEZWx0YSBMYXN0IFNlbnQNCg0KICAgVGhl IFBETSBkZXN0aW5hdGlvbiBvcHRpb24gaXMgZW5jb2RlZCBpbiB0eXBlLWxlbmd0aC12YWx1ZSAo VExWKSANCiAgIGZvcm1hdCBhcyBmb2xsb3dzOg0KDQogICAgICAwICAgICAgICAgICAgICAgICAg IDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEN CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICAgICB8ICBPcHRpb24gVHlwZSAgfCBPcHRpb24gTGVuZ3RoIHxU QiB8U2NhbGVETCAgICAgIHwgICBTY2FsZURTICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwg ICBQU04gVGhpcyBQYWNrZXQgICAgICAgICAgICAgfCAgUFNOIExhc3QgUmVjZWl2ZWQgICAgICAg ICAgICB8DQogICAgICB8LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgIERlbHRhIExhc3QgUmVjZWl2ZWQgICAg ICAgICB8ICBEZWx0YSBMYXN0IFNlbnQgICAgICAgICAgICAgIHwNCiANCg0KDQpFbGtpbnMgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAxNSAgICAgICAgICAgICAgICAgW1Bh Z2UgNl0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICAgZWxraW5zLWlwcG0tcGRtLW1ldHJpY3Mt MDAgICAgICBTZXB0ZW1wZXIgNCwgMjAxNA0KDQoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCg0KDQogICBP cHRpb24gVHlwZQ0KDQogICBUQkQgPSAweFhYIChUQkQpICBbVG8gYmUgYXNzaWduZWQgYnkgSUFO QV0gW1JGQzI3ODBdDQoNCg0KICAgT3B0aW9uIExlbmd0aA0KDQogICA4LWJpdCB1bnNpZ25lZCBp bnRlZ2VyLiBMZW5ndGggb2YgdGhlIG9wdGlvbiwgaW4gb2N0ZXRzLCBleGNsdWRpbmcNCiAgIHRo ZSBPcHRpb24gVHlwZSBhbmQgT3B0aW9uIExlbmd0aCBmaWVsZHMuIFRoaXMgZmllbGQgTVVTVCBi ZSBzZXQgdG8NCiAgIDE2Lg0KDQogICBUaW1lIEJhc2UNCkFDTTogKGFiYnJldmlhdGVkIFRCIGFi b3ZlKQpBQ006IChJIHRoaW5rIHlvdSBhcmUgcmVhbGx5IGRlc2NyaWJpbmcgIlRpY2sgUmVzb2x1 dGlvbiwgVFIiICkKDQogICAyLWJpdCB1bnNpZ25lZCBpbnRlZ2VyLiAgSXQgd2lsbCBpbmRpY2F0 ZSB0aGUgbG93ZXN0IGdyYW51bGFyaXR5DQogICBwb3NzaWJsZSBmb3IgdGhpcyBkZXZpY2UuICBU aGF0IGlzLCBmb3IgYSB2YWx1ZSBvZiAwMCBpbiB0aGUgVGltZQ0KICAgQmFzZSBmaWVsZCwgYSB2 YWx1ZSBvZiAxIGluIHRoZSBERUxUQSBmaWVsZHMgaW5kaWNhdGVzIDEgcGljb3NlY29uZC4gDQoN CiAgIFRoaXMgZmllbGQgaXMgYmVpbmcgaW5jbHVkZWQgc28gdGhhdCBhIGRldmljZSBtYXkgY2hv b3NlIHRoZQ0KICAgZ3JhbnVsYXJpdHkgd2hpY2ggbW9zdCBzdWl0cyBpdHMgdGltZXIgdGlja3Mu ICAgVGhhdCBpcywgc28gdGhhdCBpdA0KICAgZG9lcyBub3QgaGF2ZSB0byBkbyBtb3JlIHdvcmsg dGhhbiBuZWVkZWQgdG8gY29udmVydCB2YWx1ZXMgcmVxdWlyZWQNCiAgIGZvciB0aGUgUERNLgpB Q006CkkgdGhpbmsgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIG9kZCAidGltZSBwZXIgdGljayIgdmFs dWVzIGV4aXN0LgpUaG9zZSBzeXN0ZW1zIHdvdWxkIHN0aWxsIGhhdmUgdG8gZG8gc29tZSBjb252 ZXJzaW9uLCBhbmQgcG9zc2libHkKbGVhdmUgZGlnaXRzIHNldCBhdCB6ZXJvIChmb3IgZXhhbXBs ZSwgdGhlIDEgbmFuby1zZWNvbmQgZGlnaXQgaWYgCmNvbnZlcnNpb24geWllbGRzIDEwIG5hbm9z ZWNvbmQgcmVzb2x1dGlvbiBhdCBiZXN0KS4NCg0KICAgVGhlIHBvc3NpYmxlIHZhbHVlcyBvZiBU aW1lIEJhc2UgYXJlIGFzIGZvbGxvd3M6DQogICAgICAgICAgIDAwIC0gcGljb3NlY29uZHMgDQog ICAgICAgICAgIDAxIC0gbmFub3NlY29uZHMNCiAgICAgICAgICAgMTAgLSBtaWNyb3NlY29uZHMN CiAgICAgICAgICAgMTEgLSBtaWxsaXNlY29uZHMNCkFDTToKVGhpcyBpcyBhIHZlcnkgd2lkZSBy YW5nZSwgYSBmYWN0b3Igb2YgMTAwMCBmb3IgZWFjaCBzZXR0aW5nLgpJIGNvdWxkIHNlZSB0aGUg Zm9sbG93aW5nIGFsc286CgowMCAtIG5hbm9zZWNvbmRzCjAxIC0gMTAwIG5hbm9zZWMKMTAgLSAx MCBtaWNyb3NlYwoxMSAtIG1pbGlzZWNvbmRzCgooZmFjdG9yIG9mIDEwMCBzcGFjaW5nLCBub3Qg Y2xlYXIgYW55b25lIHdpbGwgbmVlZCBwaWNvc2Vjb25kISkKDQogICAgU2NhbGUgRGVsdGEgTGFz dCBSZWNlaXZlZCAoU0NBTEVETFIpDQoNCiAgICA3LWJpdCBzaWduZWQgaW50ZWdlci4gIFRoaXMg aXMgdGhlIHNjYWxpbmcgdmFsdWUgZm9yIHRoZSBEZWx0YSBMYXN0DQogICBSZWNlaXZlZCAoREVM VEFMUikgZmllbGQuICBUaGUgcG9zc2libGUgdmFsdWVzIGFyZSBmcm9tIC0xMjggdG8gKzEyNy4N CiAgIFNlZSBTZWN0aW9uIDQgZm9yIGZ1cnRoZXIgZGlzY3Vzc2lvbiBvbiBUaW1pbmcgQ29uc2lk ZXJhdGlvbnMgYW5kDQogICBmb3JtYXR0aW5nIG9mIHRoZSBzY2FsaW5nIHZhbHVlcy4NCg0KICAg IFNjYWxlIERlbHRhIExhc3QgU2VudCAoU0NBTEVETFMpDQoNCiAgICA3LWJpdCBzaWduZWQgaW50 ZWdlci4gIFRoaXMgaXMgdGhlIHNjYWxpbmcgdmFsdWUgZm9yIHRoZSBEZWx0YSBMYXN0DQogICBT ZW50IChERUxUQUxTKSBmaWVsZC4gIFRoZSBwb3NzaWJsZSB2YWx1ZXMgYXJlIGZyb20gLTEyOCB0 byArMTI3Lg0KDQoNCiAgIFBhY2tldCBTZXF1ZW5jZSBOdW1iZXIgVGhpcyBQYWNrZXQgKFBTTlRQ KQ0KDQogICAxNi1iaXQgdW5zaWduZWQgaW50ZWdlci4gIFRoaXMgZmllbGQgd2lsbCB3cmFwLiBJ dCBpcyBpbnRlbmRlZCBmb3INCiANCg0KDQpFbGtpbnMgICAgICAgICAgICAgICAgICAgRXhwaXJl cyBNYXJjaCAxMiwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCklOVEVSTkVUIERS QUZUICAgICAgICAgZWxraW5zLWlwcG0tcGRtLW1ldHJpY3MtMDAgICAgICBTZXB0ZW1wZXIgNCwg MjAxNA0KDQoNCiAgIGh1bWFuIHVzZS4KQUNNOgpodW1hbiB1c2UsIGRvIHlvdSBtZWFuIGR1cmlu ZyBhbmFseXNpcyBvZiBwYWNrZXQgY2FwdHVyZXM/ClRoZW4gd2h5IHJhbmRvbWl6ZSB0aGUgc3Rh cnQgbnVtYmVyIGJlbG93Pw0KDQogICBJbml0aWFsaXplZCBhdCBhIHJhbmRvbSBudW1iZXIgYW5k IG1vbm90b25pY2FsbHkgaW5jcmVtZW50ZWQgZm9yIGVhY2gNCiAgICBwYWNrZXQgb24gdGhlIDUt dHVwbGUuICBUaGUgNS10dXBsZSBjb25zaXN0cyBvZiB0aGUgc291cmNlIGFuZA0KICAgZGVzdGlu YXRpb24gSVAgYWRkcmVzc2VzLCB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBwb3J0cywgYW5k IHRoZQ0KICAgdXBwZXIgbGF5ZXIgcHJvdG9jb2wgKGV4LiBUQ1AsIElDTVAsIGV0YykuDQoNCiAg IE9wZXJhdGluZyBzeXN0ZW1zIE1VU1QgaW1wbGVtZW50IGEgc2VwYXJhdGUgcGFja2V0IHNlcXVl bmNlIG51bWJlcg0KICAgY291bnRlciBwZXIgNS10dXBsZS4gT3BlcmF0aW5nIHN5c3RlbXMgTVVT VCBOT1QgaW1wbGVtZW50IGEgc2luZ2xlDQogICBjb3VudGVyIGZvciBhbGwgY29ubmVjdGlvbnMu DQoNCg0KICAgUGFja2V0IFNlcXVlbmNlIE51bWJlciBMYXN0IFJlY2VpdmVkIChQU05MUikNCg0K ICAgMTYtYml0IHVuc2lnbmVkIGludGVnZXIuICBUaGlzIGlzIHRoZSBQU04gb2YgdGhlIHBhY2tl dCBsYXN0IHJlY2VpdmVkDQogICBvbiB0aGUgNS10dXBsZS4NCg0KDQogICBEZWx0YSBMYXN0IFJl Y2VpdmVkIChERUxUQUxSKQ0KDQogICBBIDE2LWJpdCB1bnNpZ25lZCBpbnRlZ2VyIGZpZWxkLiAg VGhlIHZhbHVlIGlzIGFjY29yZGluZyB0byB0aGUgc2NhbGUNCiAgIGluIFNDQUxFRExSLg0KDQog ICBERUxUQUxSID0gU2VuZCB0aW1lIHBhY2tldCAyIC0gUmVjZWl2ZSB0aW1lIHBhY2tldCAxDQoN Cg0KICAgRGVsdGEgTGFzdCBTZW50IChERUxUQUxTKQ0KDQogICBBIDE2LWJpdCB1bnNpZ25lZCBp bnRlZ2VyIGZpZWxkLiAgIFRoZSB2YWx1ZSBpcyBhY2NvcmRpbmcgdG8gdGhlDQogICBzY2FsZSBp biBTQ0FMRURTLg0KDQogICBEZWx0YSBMYXN0IFNlbnQgPSBSZWNlaXZlIHRpbWUgcGFja2V0IDIg LSBTZW5kIHRpbWUgcGFja2V0IDENCg0KDQogICBPcHRpb24gVHlwZQ0KDQogICBUaGUgdHdvIGhp Z2hlc3Qtb3JkZXIgYml0cyBvZiB0aGUgT3B0aW9uIFR5cGUgZmllbGQgYXJlIGVuY29kZWQgdG8N CiAgIGluZGljYXRlIHNwZWNpZmljIHByb2Nlc3Npbmcgb2YgdGhlIG9wdGlvbjsgZm9yIHRoZSBQ RE0gZGVzdGluYXRpb24NCiAgIG9wdGlvbiwgdGhlc2UgdHdvIGJpdHMgTVVTVCBiZSBzZXQgdG8g MDAuIFRoaXMgaW5kaWNhdGVzIHRoZQ0KICAgZm9sbG93aW5nIHByb2Nlc3NpbmcgcmVxdWlyZW1l bnRzOg0KDQogICAwMCAtIHNraXAgb3ZlciB0aGlzIG9wdGlvbiBhbmQgY29udGludWUgcHJvY2Vz c2luZyB0aGUgaGVhZGVyLg0KDQogICBSRkMyNDYwIFtSRkMyNDYwXSBkZWZpbmVzIG90aGVyIHZh bHVlcyBmb3IgdGhlIE9wdGlvbiBUeXBlIGZpZWxkLg0KICAgVGhlc2UgTVVTVCBOT1QgYmUgdXNl ZCBpbiB0aGUgUERNLiAgVGhlIG90aGVyIHZhbHVlcyBhcmUgYXMgZm9sbG93czoNCg0KICAgMDEg LSBkaXNjYXJkIHRoZSBwYWNrZXQuDQoNCiANCg0KDQpFbGtpbnMgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBNYXJjaCAxMiwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCklOVEVS TkVUIERSQUZUICAgICAgICAgZWxraW5zLWlwcG0tcGRtLW1ldHJpY3MtMDAgICAgICBTZXB0ZW1w ZXIgNCwgMjAxNA0KDQoNCiAgIDEwIC0gZGlzY2FyZCB0aGUgcGFja2V0IGFuZCwgcmVnYXJkbGVz cyBvZiB3aGV0aGVyIG9yIG5vdCB0aGUNCiAgIHBhY2tldCdzIERlc3RpbmF0aW9uIEFkZHJlc3Mg d2FzIGEgbXVsdGljYXN0IGFkZHJlc3MsIHNlbmQgYW4gSUNNUA0KICAgUGFyYW1ldGVyIFByb2Js ZW0sIENvZGUgMiwgbWVzc2FnZSB0byB0aGUgcGFja2V0J3MgU291cmNlIEFkZHJlc3MsDQogICBw b2ludGluZyB0byB0aGUgdW5yZWNvZ25pemVkIE9wdGlvbiBUeXBlLg0KDQogICAxMSAtIGRpc2Nh cmQgdGhlIHBhY2tldCBhbmQsIG9ubHkgaWYgdGhlIHBhY2tldCdzIERlc3RpbmF0aW9uIEFkZHJl c3MNCiAgIHdhcyBub3QgYSBtdWx0aWNhc3QgYWRkcmVzcywgc2VuZCBhbiBJQ01QIFBhcmFtZXRl ciBQcm9ibGVtLCBDb2RlIDIsDQogICBtZXNzYWdlIHRvIHRoZSBwYWNrZXQncyBTb3VyY2UgQWRk cmVzcywgcG9pbnRpbmcgdG8gdGhlIHVucmVjb2duaXplZA0KICAgT3B0aW9uIFR5cGUuDQoNCiAg IEluIGtlZXBpbmcgd2l0aCBSRkMyNDYwIFtSRkMyNDYwXSwgdGhlIHRoaXJkLWhpZ2hlc3Qtb3Jk ZXIgYml0IG9mIHRoZQ0KICAgT3B0aW9uIFR5cGUgc3BlY2lmaWVzIHdoZXRoZXIgb3Igbm90IHRo ZSBPcHRpb24gRGF0YSBvZiB0aGF0IG9wdGlvbg0KICAgY2FuIGNoYW5nZSBlbi1yb3V0ZSB0byB0 aGUgcGFja2V0J3MgZmluYWwgZGVzdGluYXRpb24uDQoNCiAgIEluIHRoZSBQRE0sIHRoZSB2YWx1 ZSBvZiB0aGUgdGhpcmQtaGlnaGVzdC1vcmRlciBiaXQgTVVTVCBiZSAwLiAgVGhlDQogICBwb3Nz aWJsZSB2YWx1ZXMgYXJlIGFzIGZvbGxvd3M6DQoNCiAgIDAgLSBPcHRpb24gRGF0YSBkb2VzIG5v dCBjaGFuZ2UgZW4tcm91dGUNCg0KICAgMSAtIE9wdGlvbiBEYXRhIG1heSBjaGFuZ2UgZW4tcm91 dGUNCg0KICAgVGhlIHRocmVlIGhpZ2gtb3JkZXIgYml0cyBkZXNjcmliZWQgYWJvdmUgYXJlIHRv IGJlIHRyZWF0ZWQgYXMgcGFydA0KICAgb2YgdGhlIE9wdGlvbiBUeXBlLCBub3QgaW5kZXBlbmRl bnQgb2YgdGhlIE9wdGlvbiBUeXBlLiAgVGhhdCBpcywgYQ0KICAgcGFydGljdWxhciBvcHRpb24g aXMgaWRlbnRpZmllZCBieSBhIGZ1bGwgOC1iaXQgT3B0aW9uIFR5cGUsIG5vdCBqdXN0DQogICB0 aGUgbG93LW9yZGVyIDUgYml0cyBvZiBhbiBPcHRpb24gVHlwZS4NCg0KNCBDb25zaWRlcmF0aW9u cyBvZiBUaW1pbmcgUmVwcmVzZW50YXRpb24NCg0KNC4xIEVuY29kaW5nIHRoZSBEZWx0YS1UaW1l IFZhbHVlcw0KDQogICBUaGlzIHNlY3Rpb24gbWFrZXMgcmVmZXJlbmNlIHRvIGFuZCBleHBhbmRz IG9uIHRoZSBkb2N1bWVudCAiRW5jb2RpbmcNCiAgIG9mIFRpbWUgSW50ZXJ2YWxzIGZvciB0aGUg VENQIFRpbWVzdGFtcCBPcHRpb24iIFtUUkFNLVRDUE1dLg0KDQo0LjIgVGltZXIgcmVnaXN0ZXJz IGFyZSBkaWZmZXJlbnQgb24gZGlmZmVyZW50IGhhcmR3YXJlDQoNCiAgIE9uZSBvZiB0aGUgcHJv YmxlbXMgd2l0aCB0aW1lc3RhbXAgcmVjb3JkaW5nIGlzIHRoZSB2YXJpZXR5IG9mDQogICBoYXJk d2FyZSB0aGF0IGdlbmVyYXRlcyB0aGUgdGltZSB2YWx1ZSB0byBiZSB1c2VkLiBEaWZmZXJlbnQg Q1BVcw0KICAgdHJhY2sgdGhlIHRpbWUgaW4gcmVnaXN0ZXJzIG9mIGRpZmZlcmVudCBzaXplcywg YW5kIHRoZSBtb3N0LQ0KICAgZnJlcXVlbnRseS1pdGVyYXRlZCBiaXQgY291bGQgYmUgdGhlIGZp cnN0IG9uIHRoZSBsZWZ0IG9yIHRoZSBmaXJzdA0KICAgb24gdGhlIHJpZ2h0LiBJbiBvcmRlciB0 byBnZW5lcmF0ZSBzb21lIGV4YW1wbGVzIGhlcmUgaXQgaXMgbmVjZXNzYXJ5DQogICB0byBpbmRp Y2F0ZSB0aGUgdHlwZSBvZiB0aW1lciByZWdpc3RlciBiZWluZyB1c2VkLg0KDQogICBBcyBkZXNj cmliZWQgaW4gdGhlICJJQk0gei9BcmNoaXRlY3R1cmUgUHJpbmNpcGxlcyBvZiBPcGVyYXRpb24i DQogICBbSUJNLVBPUFNdLCB0aGUgVGltZS1PZi1EYXkgY2xvY2sgaW4gYSB6U2VyaWVzIENQVSBp cyBhIDEwNC1iaXQNCiAgIHJlZ2lzdGVyLCB3aGVyZSBiaXQgNTEgaXMgaW5jcmVtZW50ZWQgYXBw cm94aW1hdGVseSBldmVyeQ0KICAgbWljcm9zZWNvbmQ6DQoNCg0KIA0KDQoNCkVsa2lucyAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDE1ICAgICAgICAgICAgICAgICBbUGFn ZSA5XQ0KDA0KSU5URVJORVQgRFJBRlQgICAgICAgICBlbGtpbnMtaXBwbS1wZG0tbWV0cmljcy0w MCAgICAgIFNlcHRlbXBlciA0LCAyMDE0DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMQ0KICAgMCAgICAgICAg MSAgICAgICAgIDIgICAgICAgICAzICAgICAgICAgNCAgICAgICAgIDUgICAgICAgICA2ICAgICAg MA0KICAgKy0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLSst LS0tLS0tLS0rLS0rLi4uKw0KICAgfCAgICAgICAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgfCAgICAgICAgIHwqICAgICAgICB8ICAgICAgfA0KICAgKy0tLS0tLS0tKy0tLS0tLS0tLSst LS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0rLS0rLi4uKw0KICAgXiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeICAgICAgICAgICAg ICAgXg0KICAgMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDUxID0gMSB1c2VjICAgIDEwMw0KDQogICBUbyByZXByZXNlbnQgdGhlc2UgdmFsdWVzIGNvbmNp c2VseSBhIGhleGFkZWNpbWFsIHJlcHJlc2VudGF0aW9uIHdpbGwNCiAgIGJlIHVzZWQsIHdoZXJl IGVhY2ggZGlnaXQgcmVwcmVzZW50cyA0IGJpbmFyeSBiaXRzLiBUaHVzOg0KDQogICAwMDAwIDAw MDAgMDAwMCAwMDAxID0gMSB0aW1lciB1bml0ICgyKiotMTIgdXNlYywgb3IgYWJvdXQgMjQ0IHBz ZWMpDQogICAwMDAwIDAwMDAgMDAwMCAxMDAwID0gMSBtaWNyb3NlY29uZA0KICAgMDAwMCAwMDAw IDAwM0UgODAwMCA9IDEgbWlsbGlzZWNvbmQNCiAgIDAwMDAgMDAwMCBGNDI0IDAwMDAgPSAxIHNl Y29uZA0KICAgMDAwMCAwMDM5IDM4NzAgMDAwMCA9IDEgbWludXRlDQogICAwMDAwIDBENjkgM0E0 MCAwMDAwID0gMSBob3VyDQogICAwMDAxIDQxREQgNzYwMCAwMDAwID0gMSBkYXkNCg0KICAgTm90 ZSB0aGF0IG9ubHkgdGhlIGZpcnN0IDY0IGJpdHMgb2YgdGhlIHJlZ2lzdGVyIGFyZSBjb21tb25s eQ0KICAgcmVwcmVzZW50ZWQsIGFzIHRoYXQgcmVwcmVzZW50cyBhIGNvdW50IG9mIHRpbWVyIHVu aXRzIG9uIHRoaXMNCiAgIGhhcmR3YXJlLiAgQ29tbW9ubHkgdGhlIGZpcnN0IDUyIGJpdHMgYXJl IGFsbCB0aGF0IGFyZSBkaXNwbGF5ZWQsIGFzDQogICB0aGF0IHJlcHJlc2VudHMgYSBjb3VudCBv ZiBtaWNyb3NlY29uZHMuIA0KDQoNCjQuMyBUaW1lciBVbml0cyBvbiBPdGhlciBTeXN0ZW1zIFRC RA0KDQo0LjQgVGltZSBCYXNlDQoNCiAgIFdlIHByb3Bvc2UgYSBiYXNlIHVuaXQgZm9yIHRoZSB0 aW1lLiAgVGhpcyBpcyBhIDItYml0IGludGVnZXINCiAgIGluZGljYXRpbmcgdGhlIGxvd2VzdCBn cmFudWxhcml0eSBwb3NzaWJsZSBmb3IgdGhpcyBkZXZpY2UuICBUaGF0IGlzLA0KICAgZm9yIGEg dmFsdWUgb2YgMDAgaW4gdGhlIFRpbWUgQmFzZSBmaWVsZCwgYSB2YWx1ZSBvZiAxIGluIHRoZSBE RUxUQQ0KICAgZmllbGRzIGluZGljYXRlcyAxIHBpY29zZWNvbmQuDQoNCiAgIFRoZSBwb3NzaWJs ZSB2YWx1ZXMgb2YgVGltZSBCYXNlIGFyZSBhcyBmb2xsb3dzOg0KDQogICAgICAgICAgIDAwIC0g cGljb3NlY29uZHMgDQogICAgICAgICAgIDAxIC0gbmFub3NlY29uZHMNCiAgICAgICAgICAgMTAg LSBtaWNyb3NlY29uZHMNCiAgICAgICAgICAgMTEgLSBtaWxsaXNlY29uZHMNCg0KDQo0LjUgVGlt ZXItdmFsdWUgc2NhbGluZw0KDQogICBBcyBkaXNjdXNzZWQgaW4gW1RSQU0tVENQTV0gd2UgcHJv cG9zZSBzdG9yaW5nIG5vdCBhbiBlbnRpcmUgdGltZS0NCiAgIGludGVydmFsIHZhbHVlLCBidXQg anVzdCB0aGUgbW9zdCBzaWduaWZpY2FudCBiaXRzIG9mIHRoYXQgdmFsdWUsDQogICBhbG9uZyB3 aXRoIGEgc2NhbGluZyBmYWN0b3IgdG8gaW5kaWNhdGUgdGhlIG1hZ25pdHVkZSBvZiB0aGUgdGlt ZS0NCiAgIGludGVydmFsIHZhbHVlLiAgSW4gb3VyIGNhc2UsIHdlIHdpbGwgdXNlIHRoZSBoaWdo LW9yZGVyIDE2IGJpdHMuIFRoZQ0KIA0KDQoNCkVsa2lucyAgICAgICAgICAgICAgICAgICBFeHBp cmVzIE1hcmNoIDEyLCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSU5URVJORVQg RFJBRlQgICAgICAgICBlbGtpbnMtaXBwbS1wZG0tbWV0cmljcy0wMCAgICAgIFNlcHRlbXBlciA0 LCAyMDE0DQoNCg0KICAgc2NhbGluZyB2YWx1ZSB3aWxsIGJlIHRoZSBudW1iZXIgb2YgYml0cyBp biB0aGUgdGltZXIgcmVnaXN0ZXIgdG8gdGhlDQogICByaWdodCBvZiB0aGUgMTZ0aCBzaWduaWZp Y2FudCBiaXQuIFRoYXQgaXMsIGlmIHRoZSB0aW1lciByZWdpc3Rlcg0KICAgY29udGFpbnMgdGhp cyBiaW5hcnkgdmFsdWU6DQoNCiAgICAgICAgICAgICAxMTEwMTAwMDExMDEwMTAwMTAxMDAxMDEw MDAxMDAwMDAwMDAwMDAwDQogICAgICAgICAgICAgPC0xNiBiaXRzICAgICAtPjwtMjQgYml0cyAg ICAgICAgICAgICAtPg0KDQogICB0aGVuLCB0aGUgdmFsdWVzIHN0b3JlZCB3b3VsZCBiZSAgMTEx MCAxMDAwIDExMDEgMDEwMCBpbiBiaW5hcnkgKEU4RDQNCiAgICBoZXhhZGVjaW1hbCkgZm9yIHRo ZSB0aW1lIHZhbHVlIGFuZCAyNCBmb3IgdGhlIHNjYWxpbmcgdmFsdWUuIE5vdGUNCiAgIHRoYXQg dGhlIGRpc3BsYXllZCB2YWx1ZSBpcyB0aGUgYmluYXJ5IGVxdWl2YWxlbnQgb2YgMSBzZWNvbmQN CiAgIGV4cHJlc3NlZCBpbiBwaWNvc2Vjb25kcy4gDQoNCiAgIFRoZSBiZWxvdyB0YWJsZSByZXBy ZXNlbnRzIGEgZGV2aWNlIHdoaWNoIGhhcyBhIFRpbWVCYXNlIG9mDQogICBwaWNvc2Vjb25kIChv ciAwMCkuICAgIFRoZSBzbWFsbGVzdCBhbmQgc2ltcGxlc3QgdmFsdWUgdG8gcmVwcmVzZW50DQog ICBpcyAxIHBpY29zZWNvbmQ7IHRoZSB0aW1lIHZhbHVlIHN0b3JlZCBpcyAxLCBhbmQgdGhlIHNj YWxpbmcgdmFsdWUgaXMNCiAgIDAuIFVzaW5nIHZhbHVlcyBmcm9tIHRoZSB0YWJsZSBiZWxvdywg d2UgaGF2ZToNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICBUaW1lIHZhbHVlIGluICAgICBF bmNvZGVkICAgIFNjYWxpbmcgICANCiAgICAgICAgIERlbHRhIHRpbWUgICAgICAgIHBpY29zZWNv bmRzICAgICAgIHZhbHVlICAgICBkZWNpbWFsICAgDQogICAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgMSBwaWNvc2Vj b25kICAgICAgICAgICAgICAgMSAgICAgICAgICAgMSAgICAgICAgIDAgDQogICAgICAgICAxIG1p bGxpc2Vjb25kICAgICAgICAgICAgM0U4ICAgICAgICAgM0U4ICAgICAgICAgMCAgICAgIA0KICAg ICAgICAgMSBtaWNyb3NlY29uZCAgICAgICAgICBGNDI0MCAgICAgICAgRjQyNCAgICAgICAgIDQg ICAgICAgICAgICAgICAgDQogICAgICAgICAxIG1pbGxpc2Vjb25kICAgICAgIDNCOUFDQTAwICAg ICAgICAzQjlBICAgICAgICAxNiAgICANCiAgICAgICAgIDEgc2Vjb25kICAgICAgICAgIEU4RDRB NTEwMDAgICAgICAgIEU4RDQgICAgICAgIDI0ICAgIA0KICAgICAgICAgMSBtaW51dGUgICAgICAg IDM2OTFENkFGQzAwMCAgICAgICAgMzY5MSAgICAgICAgMzINCiAgICAgICAgIDEgaG91ciAgICAg ICAgIGNjYTJlNTEzMTAwMDAgICAgICAgIENDQTIgICAgICAgIDM2ICAgICANCiAgICAgICAgIDEg ZGF5ICAgICAgICAxMzJmNDU3OWM5ODAwMDAgICAgICAgIDEzMkYgICAgICAgIDQ0DQogICAgICAg ICAzNjUgZGF5cyAgIDFiNWE2NjBlYTQ0YjgwMDAwICAgICAgICAxQjVBICAgICAgICA1Mg0KDQog ICBTYW1wbGUgYmluYXJ5IHZhbHVlcyAoaGlnaCBvcmRlciAxNiBiaXRzIHRha2VuKSAgDQoNCg0K ICAgMSBwaWNvICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAwMDAxDQogICAxIG5hbm9zICAgICAgICAgM0U4ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMDAxMSAxMTEwIDEwMDANCiAgIDEgbWljcm8gICAgICAgRjQyNDAg ICAgICAgICAgICAgICAgICAgICAgICAgIDExMTEgMDEwMCAwMDEwIDAxMDAgMDAwMA0KICAgMSBt aWxsaSAgICAzQjlBQ0EwMCAgICAgICAgICAgMDAxMSAxMDExIDEwMDEgMTAxMCAxMTAwIDEwMTAg MDAwMCAwMDAwDQogICAxIHNlYy4gICBFOEQ0QTUxMDAwIDExMTAgMTAwMCAxMTAxIDAxMDAgMTAx MCAwMTAxIDAwMDEgMDAwMCAwMDAwIDAwMDANCg0KDQo0LjMgTGltaXRhdGlvbnMgd2l0aCB0aGlz IGVuY29kaW5nIG1ldGhvZA0KDQogICBJZiB3ZSBmb2xsb3cgdGhlIHNwZWNpZmljYXRpb24gaW4g W1RSQU0tVENQTV0sIHRoZSBzaXplIG9mIHRoZSB0aW1lLQ0KICAgaW50ZXJ2YWwgZmllbGRzIGlz IGxpbWl0ZWQgdG8gYW4gMTEtYml0IHZhbHVlIGFuZCBmaXZlLWJpdCBzY2FsZSwgc28NCiAgIHRo YXQgdGhleSBmaXQgaW50byBhIDE2LWJpdCBzcGFjZS4gICBXZSwgaG93ZXZlciwgaGF2ZSAxNiBi aXRzDQogICBhdmFpbGFibGUgdG8gdXMgZm9yIG91ciB0aW1lLWludGVydmFsIG9yIGRlbHRhIHZh bHVlcy4gICBXZSBhbHNvIGhhdmUNCiAgIGEgNy1iaXQgc2NhbGUuDQoNCiANCg0KDQpFbGtpbnMg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAxNSAgICAgICAgICAgICAgICBb UGFnZSAxMV0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICAgZWxraW5zLWlwcG0tcGRtLW1ldHJp Y3MtMDAgICAgICBTZXB0ZW1wZXIgNCwgMjAxNA0KDQoNCiAgIFRoZSBtYXhpbXVtIHZhbHVlIHRo YXQgY291bGQgYmUgc3RvcmVkIGluIDE2IGJpdHMgaXMgaGV4IEZGRkYgb3INCiAgIDY1LDUzNS4g ICBUaGUgbWF4aW11bSB2YWx1ZSBvZiB0aGUgc2NhbGUgYXMgYSBzaWduZWQgaW50ZWdlciBvZiA3 DQogICBiaXRzIGlzIC02NCB0byArNjMuDQoNCiAgIFRoaXMgdmFsdWUgY29ycmVzcG9uZHMgdG8g YW55IHRpbWUgZGlmZmVyZW50aWFsIGJldHdlZW4gMSBwaWNvc2Vjb25kDQogICBhbmQgRkZGRiAq IDIgdG8gdGhlIDYzcmQgcGljb3NlY29uZHMuIEdpdmVuIHRoYXQgMzY1IGRheXMgaXMgMUI1QQ0K ICAgd2l0aCBhIHNjYWxlIG9mIDUyLCB0aGVuIHdlIGhhdmUgcXVpdGUgYSBiaXQgb2Ygcm9vbSBv biB0aGUgdXBwZXINCiAgIGJvdW5kIGZvciB0aGlzIG51bWJlci4NCg0KNC40IExhY2sgb2YgcHJl Y2lzaW9uIGluZHVjZWQgYnkgdGltZXIgdmFsdWUgdHJ1bmNhdGlvbg0KDQogICBXaGVuIHRoZSBi aXQgdmFsdWVzIGZvbGxvd2luZyB0aGUgZmlyc3QgMTYgc2lnbmlmaWNhbnQgYml0cyBhcmUNCiAg IHRydW5jYXRlZCwgb2J2aW91c2x5IGxvc3Mgb2YgcHJlY2lzaW9uIGluIHRoZSB2YWx1ZSByZXN1 bHRzLiBUaGUNCiAgIHJhbmdlIG9mIHZhbHVlcyB0aGF0IHdpbGwgYmUgdHJ1bmNhdGVkIHRvIHRo ZSBzYW1lIGVuY29kZWQgdmFsdWUgaXMNCiAgIDIqKihTY2FsZSktMSBwaWNvc2Vjb25kcy4NCg0K ICAgW1RCRF0NCg0KDQo1IFNhbXBsZSBJbXBsZW1lbnRhdGlvbiBGbG93IFBETQ0KDQogICBGb2xs b3dpbmcgaXMgYSBzYW1wbGUgc2ltcGxlIGZsb3cgZm9yIHRoZSBQRE0gd2l0aCBvbmUgcGFja2V0 IHNlbnQNCiAgIGZyb20gSG9zdCBBIGFuZCBvbmUgcGFja2V0IHJlY2VpdmVkIGJ5IEhvc3QgQi4g IFRoZSBQRE0gZG9lcyBub3QNCiAgIHJlcXVpcmUgdGltZSBzeW5jaHJvbml6YXRpb24gYmV0d2Vl biBIb3N0IEEgYW5kIEhvc3QgQi4gIFRoZQ0KICAgY2FsY3VsYXRpb25zIHRvIGRlcml2ZSBtZWFu aW5nZnVsIG1ldHJpY3MgZm9yIG5ldHdvcmsgZGlhZ25vc3RpY3MgYXJlDQogICBzaG93biBiZWxv dyBlYWNoIHBhY2tldCBzZW50IG9yIHJlY2VpdmVkLg0KDQogICBFYWNoIHBhY2tldCwgaW4gYWRk aXRpb24gdG8gdGhlIFBETSBjb250YWlucyBpbmZvcm1hdGlvbiBvbiB0aGUNCiAgIHNlbmRlciBh bmQgcmVjZWl2ZXIuIEFzIGRpc2N1c3NlZCBiZWZvcmUsIGEgNS10dXBsZSBjb25zaXN0cyBvZjoN Cg0KICAgICAgU0FERFIgOiBJUCBhZGRyZXNzIG9mIHRoZSBzZW5kZXINCiAgICAgIFNQT1JUIDog UG9ydCBmb3Igc2VuZGVyDQogICAgICBEQUREUiA6IElQIGFkZHJlc3Mgb2YgdGhlIGRlc3RpbmF0 aW9uDQogICAgICBEUE9SVCA6IFBvcnQgZm9yIGRlc3RpbmF0aW9uDQogICAgICBQUk9UQyA6IFBy b3RvY29sIGZvciB1cHBlciBsYXllciAoZXguIFRDUCwgVURQLCBJQ01QKQ0KDQogICBJdCBzaG91 bGQgYmUgdW5kZXJzdG9vZCB0aGF0IHRoZSBwYWNrZXQgaWRlbnRpZmljYXRpb24gaW5mb3JtYXRp b24gaXMNCiAgIGluIGVhY2ggcGFja2V0LiBXZSB3aWxsIG5vdCByZXBlYXQgdGhhdCBpbiBlYWNo IG9mIHRoZSBmb2xsb3dpbmcNCiAgIHN0ZXBzLg0KDQoNCg0KDQoNCg0KDQoNCg0KIA0KDQoNCkVs a2lucyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDE1ICAgICAgICAgICAg ICAgIFtQYWdlIDEyXQ0KDA0KSU5URVJORVQgRFJBRlQgICAgICAgICBlbGtpbnMtaXBwbS1wZG0t bWV0cmljcy0wMCAgICAgIFNlcHRlbXBlciA0LCAyMDE0DQoNCg0KNS4xIFN0ZXAgMQ0KDQogICBQ YWNrZXQgMSBpcyBzZW50IGZyb20gSG9zdCBBIHRvIEhvc3QgQi4gIFRoZSB0aW1lIGZvciBIb3N0 IEEgaXMgc2V0DQogICBpbml0aWFsbHkgdG8gMTA6MDBBTS4NCg0KICAgVGhlIHRpbWUgYW5kIHBh Y2tldCBzZXF1ZW5jZSBudW1iZXIgYXJlIHNhdmVkIGJ5IHRoZSBzZW5kZXINCiAgIGludGVybmFs bHkuICBUaGUgcGFja2V0IHNlcXVlbmNlIG51bWJlciBhbmQgZGVsdGEgdGltZXMgYXJlIHNlbnQg aW4NCiAgIHRoZSBwYWNrZXQuDQoNCiAgIFBhY2tldCAxDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAgICstLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICB8DQogICAgICAgICAg ICAgICAgICAgICAgIHwgICBIb3N0ICAgfCAtLS0tLS0tLS0tPiB8ICAgSG9zdCAgIHwNCiAgICAg ICAgICAgICAgICAgICAgICAgfCAgICBBICAgICB8ICAgICAgICAgICAgIHwgICAgQiAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0t LS0tLS0tLSsNCg0KICAgUERNIENvbnRlbnRzOg0KDQogICBQU05UUCAgICA6IFBhY2tldCBTZXF1 ZW5jZSBOdW1iZXIgVGhpcyBQYWNrZXQ6ICAgICAyNSANCiAgIFBTTkxSICAgIDogUGFja2V0IFNl cXVlbmNlIE51bWJlciBMYXN0IFJlY2VpdmVkOiAgIC0gDQogICBERUxUQUxSICA6IERlbHRhIExh c3QgUmVjZWl2ZWQ6ICAgICAgICAgICAgICAgICAgICAtIA0KICAgU0NBTEVETCAgOiBTY2FsZSBv ZiBEZWx0YSBMUjogICAgICAgICAgICAgICAgICAgICAgMA0KICAgREVMVEFMUyAgOiBEZWx0YSBM YXN0IFNlbnQ6ICAgICAgICAgICAgICAgICAgICAgICAgLQ0KICAgU0NBTEVEUyAgOiBTY2FsZSBv ZiBEZWx0YSBMUzogICAgICAgICAgICAgICAgICAgICAgMCANCiAgIFRJTUVCQVNFIDogR3JhbnVs YXJpdHkgb2YgVGltZTogICAgICAgICAgICAgICAgICAgMDAgKFBpY29zZWNvbmRzKQ0KDQoNCiAg IEludGVybmFsbHksIHdpdGhpbiB0aGUgc2VuZGVyLCBIb3N0IEEsIGl0IG11c3Qga2VlcDoNCg0K ICAgUGFja2V0IFNlcXVlbmNlIE51bWJlciBvZiB0aGUgbGFzdCBwYWNrZXQgc2VudDogICAgIDI1 DQogICBUaW1lIHRoZSBsYXN0IHBhY2tldCB3YXMgc2VudDogICAgICAgICAgICAgICAgMTA6MDA6 MDANCg0KICAgTm90ZSwgdGhlIGluaXRpYWwgUFNOVFAgZnJvbSBIb3N0IEEgc3RhcnRzIGF0IGEg cmFuZG9tIG51bWJlci4gIEluDQogICB0aGlzIGNhc2UsIDI1LiAgVGhlIHRpbWVzdGFtcCBpcyBp biBzZWNvbmRzIGZvciB0aGUgc2FrZSBvZg0KICAgc2ltcGxpY2l0eS4NCg0KDQo1LjIgU3RlcCAy DQoNCiAgIFBhY2tldCAxIGlzIHJlY2VpdmVkIGF0IEhvc3QgQi4gIEl0cyB0aW1lIGlzIHNldCB0 byBvbmUgaG91ciBsYXRlcg0KICAgdGhhbiBIb3N0IEEuICBJbiB0aGlzIGNhc2UsIDExOjAwQU0N Cg0KICAgSW50ZXJuYWxseSwgd2l0aGluIHRoZSByZWNlaXZlciwgSG9zdCBCLCBpdCBtdXN0IG5v dGU6DQoNCiAgIFBhY2tldCBTZXF1ZW5jZSBOdW1iZXIgb2YgdGhlIGxhc3QgcGFja2V0IHJlY2Vp dmVkOiAgICAyNQ0KICAgVGltZSB0aGUgbGFzdCBwYWNrZXQgd2FzIHJlY2VpdmVkICAgICAgICAg ICAgICAgICA6ICAgIDExOjAwOjAzDQogDQoNCg0KRWxraW5zICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgTWFyY2ggMTIsIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJTlRFUk5F VCBEUkFGVCAgICAgICAgIGVsa2lucy1pcHBtLXBkbS1tZXRyaWNzLTAwICAgICAgU2VwdGVtcGVy IDQsIDIwMTQNCg0KDQogICBOb3RlLCB0aGlzIHRpbWVzdGFtcCBpcyBpbiBIb3N0IEIgdGltZS4g IEl0IGhhcyBub3RoaW5nIHdoYXRzb2V2ZXIgdG8NCiAgIGRvIHdpdGggSG9zdCBBIHRpbWUuICBU aGUgUGFja2V0IFNlcXVlbmNlIE51bWJlciBvZiB0aGUgbGFzdCBwYWNrZXQNCiAgIHJlY2VpdmVk IHdpbGwgYmVjb21lIFBTTkxSIHdoaWNoIHdpbGwgYmUgc2VudCBvdXQgaW4gdGhlIHBhY2tldCBz ZW50DQogICBieSBIb3N0IEIgaW4gdGhlIG5leHQgc3RlcC4gIFRoZSB0aW1lIGxhc3QgcmVjZWl2 ZWQgd2lsbCBiZSB1c2VkIHRvDQogICBjYWxjdWxhdGUgdGhlIERFTFRBTFIgdmFsdWUgdG8gYmUg c2VudCBvdXQgaW4gdGhlIHBhY2tldCBzZW50IGJ5IEhvc3QNCiAgIEIgaW4gdGhlIG5leHQgc3Rl cC4NCg0KDQo1LjMgU3RlcCAzDQoNCiAgIFBhY2tldCAyIGlzIHNlbnQgYnkgSG9zdCBCIHRvIEhv c3QgQS4gIE5vdGUsIHRoZSBpbml0aWFsIHBhY2tldA0KICAgc2VxdWVuY2UgbnVtYmVyIChQU05U UCkgZnJvbSBIb3N0IEIgc3RhcnRzIGF0IGEgcmFuZG9tIG51bWJlci4gIEluDQogICB0aGlzIGNh c2UsIDEyLiAgIEJlZm9yZSBzZW5kaW5nIHRoZSBwYWNrZXQsIEhvc3QgQiBkb2VzIGEgY2FsY3Vs YXRpb24NCiAgIG9mIGRlbHRhcy4gIFNpbmNlIEhvc3QgQiBrbm93cyB3aGVuIGl0IGlzIHNlbmRp bmcgdGhlIHBhY2tldCwgYW5kIGl0DQogICBrbm93cyB3aGVuIGl0IHJlY2VpdmVkIHRoZSBwcmV2 aW91cyBwYWNrZXQsIGl0IGNhbiBkbyB0aGUgZm9sbG93aW5nDQogICBjYWxjdWxhdGlvbjoNCg0K ICAgU2VuZGluZyB0aW1lIChwYWNrZXQgMikgLSByZWNlaXZlIHRpbWUgKHBhY2tldCAxKQ0KDQog ICBXZSB3aWxsIGNhbGwgdGhlIHJlc3VsdCBvZiB0aGlzIGNhbGN1bGF0aW9uOiBEZWx0YSBMYXN0 IFJlY2VpdmVkIA0KDQogICBUaGF0IGlzOg0KDQogICBERUxUQUxSID0gU2VuZGluZyB0aW1lIChw YWNrZXQgMikgLSByZWNlaXZlIHRpbWUgKHBhY2tldCAxKQ0KDQogICBOb3RlLCBib3RoIHNlbmRp bmcgdGltZSBhbmQgcmVjZWl2ZSB0aW1lIGFyZSBzYXZlZCBpbnRlcm5hbGx5IGluIEhvc3QNCiAg IEIuICBUaGV5IGRvIG5vdCB0cmF2ZWwgaW4gdGhlIHBhY2tldC4gT25seSB0aGUgRGVsdGEgaXMg aW4gdGhlDQogICBwYWNrZXQuDQoNCiAgIEFzc3VtZSB0aGF0IHdpdGhpbiBIb3N0IEIgaXMgdGhl IGZvbGxvd2luZzoNCg0KICAgUGFja2V0IFNlcXVlbmNlIE51bWJlciBvZiB0aGUgbGFzdCBwYWNr ZXQgcmVjZWl2ZWQ6ICAgICAyNQ0KICAgVGltZSB0aGUgbGFzdCBwYWNrZXQgd2FzIHJlY2VpdmVk OiAgICAgICAgICAgICAgICAgICAgICAxMTowMDowMw0KICAgUGFja2V0IFNlcXVlbmNlIE51bWJl ciBvZiB0aGlzIHBhY2tldDogICAgICAgICAgICAgICAgICAxMg0KICAgVGltZSB0aGlzIHBhY2tl dCBpcyBiZWluZyBzZW50OiAgICAgICAgICAgICAgICAgICAgICAgICAxMTowMDowNw0KDQogICBX ZSBjYW4gbm93IGNhbGN1bGF0ZSBhIGRlbHRhIHZhbHVlIHRvIGJlIHNlbnQgb3V0IGluIHRoZSBw YWNrZXQuIA0KICAgREVMVEFMUiBiZWNvbWVzOg0KDQogICA0IHNlY29uZHMgPSAxMTowMDowNyAt IDExOjAwOjAzDQoNCiAgIFRoaXMgaXMgdGhlIGRlcml2ZWQgbWV0cmljOiBTZXJ2ZXIgRGVsYXku ICAgVGhlIHRpbWUgYW5kIHNjYWxpbmcNCiAgIGZhY3RvciBtdXN0IGJlIGNhbGN1bGF0ZWQuICBU aGVuLCB0aGlzIHZhbHVlLCBhbG9uZyB3aXRoIHRoZSBwYWNrZXQNCiAgIHNlcXVlbmNlIG51bWJl cnMgd2lsbCBiZSBzZW50IHRvIEhvc3QgQSBhcyBmb2xsb3dzOg0KDQogICBQYWNrZXQgMg0KDQog ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKyAgICAgICAgICAgICArLS0tLS0tLS0t LSsNCiANCg0KDQpFbGtpbnMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAx NSAgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICAgZWxr aW5zLWlwcG0tcGRtLW1ldHJpY3MtMDAgICAgICBTZXB0ZW1wZXIgNCwgMjAxNA0KDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICB8ICAgSG9zdCAgIHwgPC0tLS0tLS0tLS0gfCAgIEhvc3Qg ICB8DQogICAgICAgICAgICAgICAgICAgICAgIHwgICAgQSAgICAgfCAgICAgICAgICAgICB8ICAg IEIgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAg IHwgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSsgICAgICAg ICAgICAgKy0tLS0tLS0tLS0rDQoNCiAgIFBETSBDb250ZW50czoNCg0KICAgUFNOVFAgICAgOiBQ YWNrZXQgU2VxdWVuY2UgTnVtYmVyIFRoaXMgUGFja2V0OiAgICAxMg0KICAgUFNOTFIgICAgOiBQ YWNrZXQgU2VxdWVuY2UgTnVtYmVyIExhc3QgUmVjZWl2ZWQ6ICAyNQ0KICAgREVMVEFMUiAgOiBE ZWx0YSBMYXN0IFJlY2VpdmVkOiAgICAgICAgICAgICAgICAgM0EzNSAoNCBzZWNvbmRzKQ0KICAg U0NBTEVETCAgOiBTY2FsZSBvZiBEZWx0YSBMUjogICAgICAgICAgICAgICAgICAgICAyNQ0KICAg REVMVEFMUyAgOiBEZWx0YSBMYXN0IFNlbnQ6ICAgICAgICAgICAgICAgICAgICAgICAgLQ0KICAg U0NBTEVEUyAgOiBTY2FsZSBvZiBEZWx0YSBMUzogICAgICAgICAgICAgICAgICAgICAgMA0KICAg VElNRUJBU0UgOiBHcmFudWxhcml0eSBvZiBUaW1lOiAgICAgICAgICAgICAgICAgICAwMCAoUGlj b3NlY29uZHMpDQoNCiAgIFRoZSBtZXRyaWMgbGVmdCB0byBiZSBjYWxjdWxhdGVkIGlzIHRoZSBS b3VuZC1UcmlwIERlbGF5LiBUaGlzIHdpbGwNCiAgIGJlIGNhbGN1bGF0ZWQgYnkgSG9zdCBBIHdo ZW4gaXQgcmVjZWl2ZXMgUGFja2V0IDIuDQoNCjUuNCBTdGVwIDQNCg0KICAgUGFja2V0IDIgaXMg cmVjZWl2ZWQgYXQgSG9zdCBBLiAgUmVtZW1iZXIsIGl0cyB0aW1lIGlzIHNldCB0byBvbmUNCiAg IGhvdXIgZWFybGllciB0aGFuIEhvc3QgQi4gSW50ZXJuYWxseSwgaXQgbXVzdCBub3RlOg0KDQog ICBQYWNrZXQgU2VxdWVuY2UgTnVtYmVyIG9mIHRoZSBsYXN0IHBhY2tldCByZWNlaXZlZDogICAg MTINCiAgIFRpbWUgdGhlIGxhc3QgcGFja2V0IHdhcyByZWNlaXZlZCAgICAgICAgICAgICAgICAg OiAgICAxMDowMDoxMg0KDQogICBOb3RlLCB0aGlzIHRpbWVzdGFtcCBpcyBpbiBIb3N0IEEgdGlt ZS4gIEl0IGhhcyBub3RoaW5nIHdoYXRzb2V2ZXIgdG8NCiAgIGRvIHdpdGggSG9zdCBCIHRpbWUu DQoNCiAgIFNvLCBub3csIEhvc3QgQSBjYW4gY2FsY3VsYXRlIHRvdGFsIGVuZC10by1lbmQgdGlt ZS4gVGhhdCBpczoNCg0KICAgRW5kLXRvLUVuZCBUaW1lID0gVGltZSBMYXN0IFJlY2VpdmVkIC0g VGltZSBMYXN0IFNlbnQNCg0KICAgRm9yIGV4YW1wbGUsIHBhY2tldCAyNSB3YXMgc2VudCBieSBI b3N0IEEgYXQgMTA6MDA6MDAuIFBhY2tldCAxMiB3YXMNCiAgIHJlY2VpdmVkIGJ5IEhvc3QgQSBh dCAxMDowMDoxMiBzbzoNCg0KICAgRW5kLXRvLUVuZCB0aW1lID0gMTA6MDA6MTIgLSAxMDowMDow MCBvciAxMgpBQ006Cm9yIFNlcnZlciBhbmQgTmV0d29yayBSVCBkZWxheSBjb21iaW5lZC4gDQoN CiAgIFRoaXMgZGVyaXZlZCBtZXRyaWMgd2Ugd2lsbCBjYWxsIERFTFRBTFMgb3IgRGVsdGEgTGFz dCBTZW50Lg0KDQogICBXZSBjYW4gbm93IGFsc28gY2FsY3VsYXRlIHR3by13YXkgZGVsYXkuICBU aGUgZm9ybXVsYSBpczoNCg0KICAgVHdvLXdheSBkZWxheSA9IERFTFRBTFMgLSBERUxUQUxSDQoN CiAgIE9yOg0KDQogICBUd28td2F5IGRlbGF5ID0gMTIgLSA0IG9yIDgKQUNNOgpXaHkgbm90IGlu Y2x1ZGUgIk5ldHdvcmsiIGluIHRoZSBuYW1lIG9mIHRoZSBtZXRyaWMgaGVyZT8NCiANCg0KDQpF bGtpbnMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAxNSAgICAgICAgICAg ICAgICBbUGFnZSAxNV0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICAgZWxraW5zLWlwcG0tcGRt LW1ldHJpY3MtMDAgICAgICBTZXB0ZW1wZXIgNCwgMjAxNA0KDQoNCiAgIE5vdywgdGhlIG9ubHkg cHJvYmxlbSBpcyB0aGF0IGF0IHRoaXMgcG9pbnQgYWxsIG1ldHJpY3MgYXJlIGluIHRoZQ0KICAg SG9zdCBhbmQgbm90IGV4cG9zZWQgaW4gYSBwYWNrZXQuIApBQ006Ckhvc3QgQSBvbmx5PwoKICAg VG8gZG8gdGhhdCwgd2UgbmVlZCBhIHRoaXJkIHBhY2tldC4NCg0KNS41IFN0ZXAgNQ0KDQogICBQ YWNrZXQgMyBpcyBzZW50IGZyb20gSG9zdCBBIHRvIEhvc3QgQi4NCg0KICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLSsgICAgICAgICAgICAgKy0tLS0tLS0tLS0rDQogICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgIHwNCiAgICAg ICAgICAgICAgICAgICAgICAgfCAgIEhvc3QgICB8IC0tLS0tLS0tLS0+IHwgICBIb3N0ICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICB8ICAgIEEgICAgIHwgICAgICAgICAgICAgfCAgICBCICAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICB8ICAg ICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAgICAg ICstLS0tLS0tLS0tKw0KDQogICBQRE0gQ29udGVudHM6DQoNCiAgIFBTTlRQICAgIDogUGFja2V0 IFNlcXVlbmNlIE51bWJlciBUaGlzIFBhY2tldDogICAgMjYgDQogICBQU05MUiAgICA6IFBhY2tl dCBTZXF1ZW5jZSBOdW1iZXIgTGFzdCBSZWNlaXZlZDogIDEyIA0KICAgREVMVEFMUiAgOiBEZWx0 YSBMYXN0IFJlY2VpdmVkOiAgICAgICAgICAgICAgICAgICAgMCANCiAgIFNDQUxFREwgIDogU2Nh bGUgb2YgRGVsdGEgTFIgICAgICAgICAgICAgICAgICAgICAgIDANCiAgIERFTFRBTFMgIDogRGVs dGEgTGFzdCBTZW50OiAgICAgICAgICAgICAgICAgICAgIDEwNWUgKDEyIHNlY29uZHMpDQogICBT Q0FMRURMICA6IFNjYWxlIG9mIERlbHRhIExSICAgICAgICAgICAgICAgICAgICAgIDI2DQogICBU SU1FQkFTRSA6IEdyYW51bGFyaXR5IG9mIFRpbWU6ICAgICAgICAgICAgICAgICAgIDAwIChQaWNv c2Vjb25kcykNCg0KDQogICBUbyBjYWxjdWxhdGUgVHdvLVdheSBEZWxheSwgYW55IHBhY2tldCBj YXB0dXJlIGRldmljZSBtYXkgbG9vayBhdA0KICAgdGhlc2UgcGFja2V0cyBhbmQgZG8gd2hhdCBp cyBuZWNlc3NhcnkuDQoNCjYgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZXJlIGFy ZSBubyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4KQUNNOgoibm8iIHdvbid0IGZseSwgd2UgaGF2 ZSB0byBnaXZlIHRoaXMgc29tZSB0aG91Z2h0LgpXaGF0IGFyZSB0aGUgcG9zc2libGUgYXR0YWNr cywgTWFuLWluLXRoZS1taWRkbGUgY2hhbmdpbmcgdmFsdWVzPwpvdGhlcnM/DQoNCjcgSUFOQSBD b25zaWRlcmF0aW9ucw0KDQogICBUaGVyZSBhcmUgbm8gSUFOQSBjb25zaWRlcmF0aW9ucy4KQUNN OgpidXQgc2VjdGlvbiA0IHNheXM6CiAgIE9wdGlvbiBUeXBlDQoNCiAgIFRCRCA9IDB4WFggKFRC RCkgIFtUbyBiZSBhc3NpZ25lZCBieSBJQU5BXSBbUkZDMjc4MF0NCg0KOCBSZWZlcmVuY2VzDQoN CjguMSBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAi S2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgUmVxdWlyZW1lbnQgTGV2 ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KICAgW1JGQzI0NjBdICBEZWVy aW5nLCBTLiBhbmQgUi4gSGluZGVuLCAiSW50ZXJuZXQgUHJvdG9jb2wsIFZlcnNpb24gNg0KICAg KElQdjYpIFNwZWNpZmljYXRpb24iLCBSRkMgMjQ2MCwgRGVjZW1iZXIgMTk5OC4NCg0KICAgW1JG QzI2ODFdICBBbG1lcywgRy4sIEthbGlkaW5kaSwgUy4sIGFuZCBNLiBaZWthdXNrYXMsICJBIFJv dW5kLXRyaXANCiAgIERlbGF5IE1ldHJpYyBmb3IgSVBQTSIsIFJGQyAyNjgxLCBTZXB0ZW1iZXIg MTk5OS4NCiANCg0KDQpFbGtpbnMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAxMiwg MjAxNSAgICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICAg ZWxraW5zLWlwcG0tcGRtLW1ldHJpY3MtMDAgICAgICBTZXB0ZW1wZXIgNCwgMjAxNA0KDQoNCiAg IFtSRkMyNzgwXSAgQnJhZG5lciwgUy4gYW5kIFYuIFBheHNvbiwgIklBTkEgQWxsb2NhdGlvbiBH dWlkZWxpbmVzIEZvcg0KICAgVmFsdWVzIEluIHRoZSBJbnRlcm5ldCBQcm90b2NvbCBhbmQgUmVs YXRlZCBIZWFkZXJzIiwgQkNQIDM3LCBSRkMNCiAgIDI3ODAsIE1hcmNoIDIwMDAuDQoNCiAgIFtJ Qk0tUE9QU10gSUJNIENvcnBvcmF0aW9uLCAiSUJNIHovQXJjaGl0ZWN0dXJlIFByaW5jaXBsZXMg b2YNCiAgIE9wZXJhdGlvbiIsIFNBMjItNzgzMiwgMTk5MC0yMDEyDQoNCjguMiBJbmZvcm1hdGl2 ZSBSZWZlcmVuY2VzDQoNCiAgIFtFTEstUERNXSAgRWxraW5zLCBOLiwgImRyYWZ0LWVsa2lucy02 bWFuLWlwdjYtcGRtLWRlc3Qtb3B0aW9uLTA3IiwNCiAgIEludGVybmV0IERyYWZ0LCBTZXB0ZW1i ZXIgMjAxNC4gW1dvcmsgaW4gUHJvZ3Jlc3NdDQoNCiAgIFtUUkFNLVRDUE1dIFRyYW1tZWwsIEIu LCAiRW5jb2Rpbmcgb2YgVGltZSBJbnRlcnZhbHMgZm9yIHRoZSBUQ1ANCiAgIFRpbWVzdGFtcCBP cHRpb24tMDEiLCBJbnRlcm5ldCBEcmFmdCwgIEp1bHkgMjAxMy4gW1dvcmsgaW4gUHJvZ3Jlc3Nd DQoNCjkgQWNrbm93bGVkZ21lbnRzDQoNCiAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhh bmsgS2V2ZW4gSGFpbmluZywgQWwgTW9ydG9uLCBCcmlhbg0KICAgVHJhbW1lbCwgRGF2aWQgQm95 ZXMsIGFuZCBSaWNrIFRyb3RoIGZvciB0aGVpciBjb21tZW50cyBhbmQNCiAgIGFzc2lzdGFuY2Uu DQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICAgICAgTmFsaW5pIEVsa2lucw0KICAgICAgIElu c2lkZSBQcm9kdWN0cywgSW5jLg0KICAgICAgIDM2QSBVcHBlciBDaXJjbGUNCiAgICAgICBDYXJt ZWwgVmFsbGV5LCBDQSA5MzkyNA0KICAgICAgIFVuaXRlZCBTdGF0ZXMNCiAgICAgICBQaG9uZTog KzEgODMxIDY1OSA4MzYwDQogICAgICAgRW1haWw6IG5hbGluaS5lbGtpbnNAaW5zaWRldGhlc3Rh Y2suY29tDQogICAgICAgaHR0cDovL3d3dy5pbnNpZGV0aGVzdGFjay5jb20NCg0KICAgICAgIFJv YmVydCBIYW1pbHRvbg0KICAgICAgIENoZW1pY2FsIEFic3RyYWN0cyBTZXJ2aWNlDQogICAgICAg QSBEaXZpc2lvbiBvZiB0aGUgQW1lcmljYW4gQ2hlbWljYWwgU29jaWV0eQ0KICAgICAgIDI1NDAg T2xlbnRhbmd5IFJpdmVyIFJvYWQNCiAgICAgICBDb2x1bWJ1cywgT2hpbyAgNDMyMDINCiAgICAg ICBVbml0ZWQgU3RhdGVzDQogICAgICAgUGhvbmU6ICsxIDYxNCA0NDcgMzYwMCB4MjUxNw0KICAg ICAgIEVtYWlsOiByaGFtaWx0b25AY2FzLm9yZw0KICAgICAgIGh0dHA6Ly93d3cuY2FzLm9yZw0K DQogICAgICAgTWljaGFlbCBTLiBBY2tlcm1hbm4NCiAgICAgICBCbHVlIENyb3NzIEJsdWUgU2hp ZWxkIG9mIE1pY2hpZ2FuDQogICAgICAgUC5PLiBCb3ggMjg4OA0KICAgICAgIERldHJvaXQsIE1p Y2hpZ2FuIDQ4MjMxDQogICAgICAgVW5pdGVkIFN0YXRlcw0KICAgICAgIFBob25lOiArMSAzMTAg NDYwIDQwODANCiANCg0KDQpFbGtpbnMgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAx MiwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCklOVEVSTkVUIERSQUZUICAgICAg ICAgZWxraW5zLWlwcG0tcGRtLW1ldHJpY3MtMDAgICAgICBTZXB0ZW1wZXIgNCwgMjAxNA0KDQoN CiAgICAgICBFbWFpbDogbWFja2VybWFubkBiY2JzbWkuY29tDQogICAgICAgaHR0cDovL3d3dy5i Y2JzbWkuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkVsa2lu cyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDE1ICAgICAgICAgICAgICAg IFtQYWdlIDE4XQ0K --_002_4AF73AA205019A4C8A1DDD32C034631D797C6136NJFPSRVEXG0rese_-- From nobody Tue Oct 14 05:35:38 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9331A003B for ; Fri, 10 Oct 2014 16:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH4rSnm7XYir for ; Fri, 10 Oct 2014 16:03:26 -0700 (PDT) Received: from nm4-vm4.bullet.mail.ne1.yahoo.com (nm4-vm4.bullet.mail.ne1.yahoo.com [98.138.91.164]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005641A001B for ; Fri, 10 Oct 2014 16:03:25 -0700 (PDT) Received: from [98.138.100.114] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 10 Oct 2014 23:03:25 -0000 Received: from [98.138.89.248] by tm105.bullet.mail.ne1.yahoo.com with NNFMP; 10 Oct 2014 23:03:25 -0000 Received: from [127.0.0.1] by omp1040.mail.ne1.yahoo.com with NNFMP; 10 Oct 2014 23:03:25 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 192730.44610.bm@omp1040.mail.ne1.yahoo.com Received: (qmail 57308 invoked by uid 60001); 10 Oct 2014 23:03:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1412982205; bh=8cX6FMrHIhmTb0LCU81oWdriV8opM/zWB+WRgvlpWmA=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OHzrJbEKKVx05LudYeKIanVpE8VDEotU5i0NtiECuPmcI6LqsL2aJnl5kCvJYjPzQ+Basx4zeC/Nd8AnsjzyAtnKjXpvkT8waKjiL2W1SVxdYESBxeAtdb9vcvOyh0r6ox7uP5knU6bMa1ugc7XNp7u0tSmAxKVHHPkdaupw5zk= X-YMail-OSG: TEw9WEEVM1lTN9K3UpqZ_LsbwMl_11GzYXRqSywqYePe9gw eHoAZB6muRye93tGLXvbXQiagD2KC85Zshqpepo1g7eLyl4aCE3T3rE4rx5a 64swk8YQW0yvmRZ8ou73fvwotFiaCcJ7PRClCfG75amDJihhPrk5JAJzieEE aam_OGSruBSP16HhOejP691qi3Aj0CWB11NpCul4jh4BrgiKJi3FwVJHs5B2 ZsSmZTLlWbN3ZrhMzTZOu.y7ruxwe7zDHULXcu.InPVVUwqyYWNcShSMMkkf jyzyKFiKoNcVZDpOnboNNCJfjAD6Oucu8L1nPqSX59G1pTUE_w7H25iCGGBW D08yNWxihluxcySJpEyVOHO8282713UEZlQDg0SeKT4.EZGr5ubOyybYGwvp dTJtcUXujMgNVIaOBTLdMCriuec0QXhr.MzQoV_RLW.vMR9tgXW3qIqyW5AC v8TPEw1t9o1szQ1uDbyjpG2mrEifuU2u9h.VeZEME0KdgmwjFzG0gdZ79pbB Keg9HRSuQzwSXlkm8LZokGCzIjXKxgzMbhXalrG4_VBNCQUl6CEzJ4Defjcy tK1IVSn_j9ZebTlpS3gR9c.JxMGrPBNZXlfVeK8uy9UQ0kDQcwMqFKhMvJon 6vdz6Le3_4aUgkQ-- Received: from [162.201.69.37] by web125102.mail.ne1.yahoo.com via HTTP; Fri, 10 Oct 2014 16:03:24 PDT X-Rocket-MIMEInfo: 002.001, QWwsCgpUaGFua3Mgc28gbXVjaCBmb3IgeW91ciBjb21tZW50cy4KCldlIHdpbGwgcmV2aXNlIGFwcHJvcHJpYXRlbHkuCgoKTmFsaW5pIEVsa2lucwpJbnNpZGUgUHJvZHVjdHMsIEluYy4KKDgzMSkgNjU5LTgzNjAKd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRnJvbTogTmFsaW5pIEVsa2lucyA8bmFsaW5pX2Vsa2luc0BpbnNpZGV0aGVzdGFjay5jb20.ClRvOiAiTU9SVE9OLCBBTEZSRUQgQyAoQUwpIiA8YWNtQHJlc2VhcmNoLmF0dC5jb20.OyABMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.696 References: <4AF73AA205019A4C8A1DDD32C034631D797C6136@NJFPSRVEXG0.research.att.com> <1412982046.48501.YahooMailNeo@web125103.mail.ne1.yahoo.com> Message-ID: <1412982204.64428.YahooMailNeo@web125102.mail.ne1.yahoo.com> Date: Fri, 10 Oct 2014 16:03:24 -0700 From: Nalini Elkins To: Nalini Elkins , "MORTON, ALFRED C \(AL\)" , "draft-elkins-ippm-pdm-option@tools.ietf.org" In-Reply-To: <1412982046.48501.YahooMailNeo@web125103.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-559651860-1662983834-1412982204=:64428" Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/Wk9msJx4rAPrFvnc0trxCSMDX2k X-Mailman-Approved-At: Tue, 14 Oct 2014 05:35:28 -0700 Cc: "ippm@ietf.org" Subject: Re: [ippm] draft-elkins-ippm-pdm-option-01 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Nalini Elkins List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 23:03:27 -0000 ---559651860-1662983834-1412982204=:64428 Content-Type: text/plain; charset=us-ascii Al, Thanks so much for your comments. We will revise appropriately. Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: Nalini Elkins To: "MORTON, ALFRED C (AL)" ; "draft-elkins-ippm-pdm-option@tools.ietf.org" Cc: "ippm@ietf.org" Sent: Friday, October 10, 2014 4:00 PM Subject: Re: [ippm] draft-elkins-ippm-pdm-option-01 Thanks so much, Al. We will look & revise appropriately. Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com ________________________________ From: "MORTON, ALFRED C (AL)" To: "draft-elkins-ippm-pdm-option@tools.ietf.org" Cc: "ippm@ietf.org" Sent: Friday, October 10, 2014 2:57 PM Subject: [ippm] draft-elkins-ippm-pdm-option-01 Hi Nalini, Mike, Robert, I finally made time to read your draft, I see it has been revised since I originally added intended to read it, that's progress. My detailed comments are in the text file attached, you can search for "ACM:" if necessary, but there are quite a few. One main area to sort out is terminology: the fields in the PDM, like timestamps and sequence numbers, are information for making measurements and calculating metrics. So the fields are the info, not metrics themselves. The concepts of metrics, measurements and measured results are important to sort-out, everywhere I've been recently this is an important first step. regards, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm ---559651860-1662983834-1412982204=:64428 Content-Type: text/html; charset=us-ascii
Al,

Thanks so much for your comments.

We will revise appropriately.


Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

From: Nalini Elkins <nalini_elkins@insidethestack.com>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>; "draft-elkins-ippm-pdm-option@tools.ietf.org" <draft-elkins-ippm-pdm-option@tools.ietf.org>
Cc: "ippm@ietf.org" <ippm@ietf.org>
Sent: Friday, October 10, 2014 4:00 PM
Subject: Re: [ippm] draft-elkins-ippm-pdm-option-01

Thanks so much, Al.

We will look & revise appropriately.


Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com



From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: "draft-elkins-ippm-pdm-option@tools.ietf.org" <draft-elkins-ippm-pdm-option@tools.ietf.org>
Cc: "ippm@ietf.org" <ippm@ietf.org>
Sent: Friday, October 10, 2014 2:57 PM
Subject: [ippm] draft-elkins-ippm-pdm-option-01

Hi Nalini, Mike, Robert,

I finally made time to read your draft, I see it has been revised
since I originally added intended to read it, that's progress.

My detailed comments are in the text file attached, you can search
for "ACM:" if necessary, but there are quite a few.

One main area to sort out is terminology:
the fields in the PDM, like timestamps and sequence numbers,
are information for making measurements and calculating metrics.
So the fields are the info, not metrics themselves.
The concepts of metrics, measurements and measured results
are important to sort-out, everywhere I've been recently this
is an important first step.

regards,
Al
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm




---559651860-1662983834-1412982204=:64428-- From nobody Wed Oct 15 09:43:10 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D24B1A8A08 for ; Wed, 15 Oct 2014 09:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxX2eTsD7KiF for ; Wed, 15 Oct 2014 09:43:02 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859321A8A07 for ; Wed, 15 Oct 2014 09:43:02 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by gateway2.nyi.internal (Postfix) with ESMTP id 9FAF41FF9 for ; Wed, 15 Oct 2014 12:43:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 15 Oct 2014 12:43:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type :content-transfer-encoding:date:subject:to:message-id :mime-version; s=smtpout; bh=a3tar66lh3xeXYGARPwNU+sLcsc=; b=Hja Lpy8fUiTl/jgqcmUxz16b/xSBG7gBAcK27xjqqfkC0eEy/dPXlPj/9RIp/swbElL 9uBm30vcEKkG+UwvBAriQUqN5H3JFJzBBfQUbDbyESLPLPI5w6+Y9Kx/8SyagIBI EDdFC99/FpxHX3nWTFqHWhZnvRu6HPtZvAinsids= X-Sasl-enc: tIlLoGKx5S/iVUS1TNigxhtu5WySPenIp2ohp0TfBZZv 1413391380 Received: from eng-6-31.aa.arbor.net (unknown [216.130.192.4]) by mail.messagingengine.com (Postfix) with ESMTPA id 3B34268012A; Wed, 15 Oct 2014 12:43:00 -0400 (EDT) From: Bill Cerveny Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2014 12:42:59 -0400 To: ippm@ietf.org Message-Id: <921A90FC-799E-4981-97C0-9C2F791FCF96@wjcerveny.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/F1ooJLo1np1u_Kw0PMzImeAnUPs Subject: [ippm] IPPM at IETF91 draft agenda and other notes X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 16:43:05 -0000 Dear IPPM WG participants, While not official yet, it appears we may have a 3:20 - 5:20pm HST = (0120-0320 UTC) agenda time on Tuesday, November 11, 2014, at IETF91 in = Honolulu, Hawaii. Some administrative notes: 1) checksum-trailer and type-p-monitor are on deck to become IPPM WG = documents and will become working group documents as soon as we send a = couple of our current WG documents to the IESG. 2) We will be commencing a WGLC on draft-ietf-ippm-ipsec-05 shortly. = Reviews of IPPM documents, and particularly ippm-ipsec, are greatly = appreciated. =20 More reviews =3D=3D more documents to IESG queue =3D=3D new documents = added to IPPM WG document list. 3) Based on presentation responses, the agenda currently looks a little = like the below. If you are an author who will be at IETF91 and would = like to present at the IPPM WG meeting, please let me know and I=92ll = try to add you to the agenda. IETF91 Draft IPPM Agenda - Agenda Bash=20 - Intro / Status / Adoption / Agenda - Working Group Documents =97 ippm-(2679,2680)-bis =97 ippm-rate-problem - Individual Drafts =97 draft-elkins-ippm-pdm-option =97 draft-mornuley-ippm-initial-registry Thanks, Bill Cerveny IPPM co-chair= From nobody Wed Oct 15 11:39:56 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4861A90BC for ; Wed, 15 Oct 2014 11:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiOqoUlpTwpo for ; Wed, 15 Oct 2014 11:39:51 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F501A90CE for ; Wed, 15 Oct 2014 11:39:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by gateway2.nyi.internal (Postfix) with ESMTP id 97B6A2625 for ; Wed, 15 Oct 2014 14:39:47 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 15 Oct 2014 14:39:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type:subject:date :references:to:message-id:mime-version; s=smtpout; bh=gPNU+321Ec 5LBRYNqQw5VEXyWqc=; b=Ke8yamPLDa1AeR1yhOKa0DL2/+pec4OuEKjvAuqxKH yyyVS2DPdfDQI3OADZfDpji4rgo+1F7zwWMbnt3Lq6a+ydekWY4l/Fh5uo8dgs42 u+ek8+s1Q7mjwszqA4OgXJG3F0SApFWAcwbTliEiaH4nJ3xmq/o1osmPUgGUvUqj w= X-Sasl-enc: BOmOtENhwlFaX2mVh3IrmUwi2JtUZjqWh03DPCdGQmCe 1413398386 Received: from eng-6-31.aa.arbor.net (unknown [216.130.192.4]) by mail.messagingengine.com (Postfix) with ESMTPA id E3BAA680156 for ; Wed, 15 Oct 2014 14:39:46 -0400 (EDT) From: Bill Cerveny Content-Type: multipart/alternative; boundary="Apple-Mail=_2CB566C3-D6A8-47FD-B523-8813740BF6C0" Date: Wed, 15 Oct 2014 14:39:46 -0400 References: <20140919143517.9076.18495.idtracker@ietfa.amsl.com> To: ippm@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/NgFebOxLqag105c0vtpJ7cXGmic Subject: [ippm] WGLC: draft-ietf-ippm-ipsec-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 18:39:54 -0000 --Apple-Mail=_2CB566C3-D6A8-47FD-B523-8813740BF6C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A WGLC is being commenced for draft-ietf-ippm-ipsec until Saturday, = November 1, 2014. The authors are particularly interested in comments = regarding changes made to the document since IETF90. These changed can = be observed at: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-ippm-ipsec-04&difftype=3D--= html&submit=3DGo%21&url2=3Ddraft-ietf-ippm-ipsec-05 Regards, Bill Cerveny IPPM WG co-chair Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [ippm] I-D Action: draft-ietf-ippm-ipsec-05.txt > Date: September 19, 2014 at 10:35:17 AM EDT > To: i-d-announce@ietf.org > Cc: ippm@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Performance Metrics Working Group = of the IETF. >=20 > Title : IKEv2-based Shared Secret Key for O/TWAMP > Authors : Kostas Pentikousis > Emma Zhang > Yang Cui > Filename : draft-ietf-ippm-ipsec-05.txt > Pages : 12 > Date : 2014-09-19 >=20 > Abstract: > The O/TWAMP security mechanism requires that both the client and > server endpoints possess a shared secret. Since the currently- > standardized O/TWAMP security mechanism only supports a pre-shared > key mode, large scale deployment of O/TWAMP is hindered > significantly. At the same time, recent trends point to wider IKEv2 > deployment which, in turn, calls for mechanisms and methods that > enable tunnel end-users, as well as operators, to measure one-way = and > two-way network performance in a standardized manner. This document > discusses the use of keys derived from an IKEv2 SA as the shared key > in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/ > TWAMP can support certificate-based key exchange, which would allow > for more operational flexibility and efficiency. The key derivation > presented in this document can also facilitate automatic key > management. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ippm-ipsec-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-ipsec-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_2CB566C3-D6A8-47FD-B523-8813740BF6C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii A WGLC = is being commenced for draft-ietf-ippm-ipsec until Saturday, November 1, = 2014.  The authors are particularly interested in comments = regarding changes made to the document since IETF90. These changed can = be observed at:
Regards,

Bill = Cerveny
IPPM WG co-chair

Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /span>
Subject: = [ippm] I-D = Action: draft-ietf-ippm-ipsec-05.txt
Date: September 19, 2014 at 10:35:17 AM = EDT

<= br>A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the IP Performance Metrics = Working Group of the IETF.

=        Title =           : = IKEv2-based Shared Secret Key for O/TWAMP
=        Authors =         : Kostas Pentikousis
=             &n= bsp;           &nbs= p;Emma Zhang
=             &n= bsp;           &nbs= p;Yang Cui
= Filename        : = draft-ietf-ippm-ipsec-05.txt
Pages =           : = 12
= Date =            : = 2014-09-19

Abstract:
  The O/TWAMP security = mechanism requires that both the client and
  server = endpoints possess a shared secret.  Since the currently-
=   standardized O/TWAMP security mechanism only supports a = pre-shared
  key mode, large scale deployment of O/TWAMP = is hindered
  significantly.  At the same time, = recent trends point to wider IKEv2
  deployment which, in = turn, calls for mechanisms and methods that
  enable = tunnel end-users, as well as operators, to measure one-way and
=   two-way network performance in a standardized manner. =  This document
  discusses the use of keys derived = from an IKEv2 SA as the shared key
  in O/TWAMP.  If = the shared key can be derived from the IKEv2 SA, O/
=   TWAMP can support certificate-based key exchange, which = would allow
  for more operational flexibility and = efficiency.  The key derivation
  presented in this = document can also facilitate automatic key
=   management.


The IETF datatracker status page for = this draft is:
https://d= atatracker.ietf.org/doc/draft-ietf-ippm-ipsec/

There's also a = htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-ippm-ipsec-05

A diff = from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-ipsec-05

=
Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also available by anonymous = FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
ippm mailing = list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

= --Apple-Mail=_2CB566C3-D6A8-47FD-B523-8813740BF6C0-- From nobody Wed Oct 22 08:52:43 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5081ACD9E for ; Wed, 22 Oct 2014 08:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6uLEI2k1cWW for ; Wed, 22 Oct 2014 08:52:39 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646211ACD97 for ; Wed, 22 Oct 2014 08:52:39 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway2.nyi.internal (Postfix) with ESMTP id D61942BB5 for ; Wed, 22 Oct 2014 11:52:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 22 Oct 2014 11:52:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type:subject:date :references:to:message-id:mime-version; s=smtpout; bh=vuaF4cWu1M iRVuIWfS0Mea4QAPM=; b=LEduUqWN1ZqQIcr81ekmOhm838N3WA93+8fj3Myurq UdBRba4zprLV/jM9DxrHFBT/8rsXeXlAlAyZBh226irsqWVUG0NX7sk3IlEaDP6e VbuNhZciq1sZUThoURbe9ub+oVMGSBlvFGfo4mWj4wqWUhplr9cZ0alx1amCkBWp g= X-Sasl-enc: MlQ/YJXkbmAJvX2QOdo5LFzWJOURo6L6MQdAKKBhtUNr 1413993158 Received: from eng-148.ma.arbor.net (unknown [23.30.178.193]) by mail.messagingengine.com (Postfix) with ESMTPA id 209EAC00011; Wed, 22 Oct 2014 11:52:38 -0400 (EDT) From: Bill Cerveny Content-Type: multipart/alternative; boundary="Apple-Mail=_4AF4DC2E-7C25-4A7C-81CF-E75B407B6E48" Date: Wed, 22 Oct 2014 11:52:37 -0400 References: <20140919143517.9076.18495.idtracker@ietfa.amsl.com> To: ippm@ietf.org, ipsec@ietf.org Message-Id: <50C83F71-5733-4733-A8A3-D89817DFCF21@wjcerveny.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/g6zg5ZXZCN9w_fmphVldSbbqXyw Subject: [ippm] WGLC: draft-ietf-ippm-ipsec-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:52:41 -0000 --Apple-Mail=_4AF4DC2E-7C25-4A7C-81CF-E75B407B6E48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Resending to include ipsec e-mail list] A WGLC is being commenced for draft-ietf-ippm-ipsec until Saturday, = November 1, 2014. The authors are particularly interested in comments = regarding changes made to the document since IETF90. These changed can = be observed at: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-ippm-ipsec-04&difftype=3D--= html&submit=3DGo%21&url2=3Ddraft-ietf-ippm-ipsec-05 Regards, Bill Cerveny IPPM WG co-chair Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [ippm] I-D Action: draft-ietf-ippm-ipsec-05.txt > Date: September 19, 2014 at 10:35:17 AM EDT > To: i-d-announce@ietf.org > Cc: ippm@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Performance Metrics Working Group = of the IETF. >=20 > Title : IKEv2-based Shared Secret Key for O/TWAMP > Authors : Kostas Pentikousis > Emma Zhang > Yang Cui > Filename : draft-ietf-ippm-ipsec-05.txt > Pages : 12 > Date : 2014-09-19 >=20 > Abstract: > The O/TWAMP security mechanism requires that both the client and > server endpoints possess a shared secret. Since the currently- > standardized O/TWAMP security mechanism only supports a pre-shared > key mode, large scale deployment of O/TWAMP is hindered > significantly. At the same time, recent trends point to wider IKEv2 > deployment which, in turn, calls for mechanisms and methods that > enable tunnel end-users, as well as operators, to measure one-way = and > two-way network performance in a standardized manner. This document > discusses the use of keys derived from an IKEv2 SA as the shared key > in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/ > TWAMP can support certificate-based key exchange, which would allow > for more operational flexibility and efficiency. The key derivation > presented in this document can also facilitate automatic key > management. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ippm-ipsec-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-ipsec-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_4AF4DC2E-7C25-4A7C-81CF-E75B407B6E48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [Resending to include ipsec e-mail = list]

A WGLC is being commenced for = draft-ietf-ippm-ipsec until Saturday, November 1, 2014.  The = authors are particularly interested in comments regarding changes made = to the document since IETF90. These changed can be observed at:
Regards,

Bill = Cerveny
IPPM WG co-chair

Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /span>
Subject: = [ippm] I-D = Action: draft-ietf-ippm-ipsec-05.txt
Date: September 19, 2014 at 10:35:17 AM = EDT

<= br>A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the IP Performance Metrics = Working Group of the IETF.

=        Title =           : = IKEv2-based Shared Secret Key for O/TWAMP
=        Authors =         : Kostas Pentikousis
=             &n= bsp;           &nbs= p;Emma Zhang
=             &n= bsp;           &nbs= p;Yang Cui
= Filename        : = draft-ietf-ippm-ipsec-05.txt
Pages =           : = 12
= Date =            : = 2014-09-19

Abstract:
  The O/TWAMP security = mechanism requires that both the client and
  server = endpoints possess a shared secret.  Since the currently-
=   standardized O/TWAMP security mechanism only supports a = pre-shared
  key mode, large scale deployment of O/TWAMP = is hindered
  significantly.  At the same time, = recent trends point to wider IKEv2
  deployment which, in = turn, calls for mechanisms and methods that
  enable = tunnel end-users, as well as operators, to measure one-way and
=   two-way network performance in a standardized manner. =  This document
  discusses the use of keys derived = from an IKEv2 SA as the shared key
  in O/TWAMP.  If = the shared key can be derived from the IKEv2 SA, O/
=   TWAMP can support certificate-based key exchange, which = would allow
  for more operational flexibility and = efficiency.  The key derivation
  presented in this = document can also facilitate automatic key
=   management.


The IETF datatracker status page for = this draft is:
https://d= atatracker.ietf.org/doc/draft-ietf-ippm-ipsec/

There's also a = htmlized version available at:
http://tools.= ietf.org/html/draft-ietf-ippm-ipsec-05

A diff from the = previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-ipsec-05

=
Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also available by anonymous = FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
ippm mailing = list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

= --Apple-Mail=_4AF4DC2E-7C25-4A7C-81CF-E75B407B6E48-- From nobody Wed Oct 22 09:05:56 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD8E1ACDD1 for ; Wed, 22 Oct 2014 09:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtsMYPo-kP3k for ; Wed, 22 Oct 2014 09:05:53 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181211ACDC5 for ; Wed, 22 Oct 2014 09:05:52 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway2.nyi.internal (Postfix) with ESMTP id 4D34751DC for ; Wed, 22 Oct 2014 12:05:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 22 Oct 2014 12:05:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type:subject:date :references:to:message-id:mime-version; s=smtpout; bh=pqtFRN8o8o gUDQzga4pbjjJfQ4M=; b=Sc2E7niqsgeK4pDDV/NIe6ur75SJPapnjS1djagzUJ awnEZzRMju46NHMqCLjc/CbccMpmE6C1biJ2aoDoSMYPOfavkeKa8+ZF9NL7S9i/ bq2RBN4bjtqRlsTyUn0OQzO+KD9Ln5a9McnuPLle8liBLRbc7yB271nffIQiOVJ0 U= X-Sasl-enc: yNwdA64zT+1AyHeQzm50nhCedogbdazZvVUubfSXRSt/ 1413993951 Received: from eng-148.ma.arbor.net (unknown [23.30.178.193]) by mail.messagingengine.com (Postfix) with ESMTPA id C21A3680138 for ; Wed, 22 Oct 2014 12:05:51 -0400 (EDT) From: Bill Cerveny Content-Type: multipart/alternative; boundary="Apple-Mail=_82BB398E-9368-4A56-8A84-2060CB01B9DD" Date: Wed, 22 Oct 2014 12:05:51 -0400 References: <20141007152827.25462.89556.idtracker@ietfa.amsl.com> To: ippm@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/JIgGeNCRtunbYTuLGz2lURBjrVI Subject: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 16:05:54 -0000 --Apple-Mail=_82BB398E-9368-4A56-8A84-2060CB01B9DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii draft-ietf-ippm-rate-problem has been updated with changes requested by = IPPM participants. As such, I am kicking off a WGLC for = draft-ietf-ippm-rate-problem-07 until November 5, 2014. Please provide = comments before the WGLC ends. Thanks, Bill Cerveny IPPM WG co-chair Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-07.txt > Date: October 7, 2014 at 11:28:27 AM EDT > To: i-d-announce@ietf.org > Cc: ippm@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Performance Metrics Working Group = of the IETF. >=20 > Title : Rate Measurement Test Protocol Problem = Statement > Author : Al Morton > Filename : draft-ietf-ippm-rate-problem-07.txt > Pages : 12 > Date : 2014-10-07 >=20 > Abstract: > This memo presents an access rate-measurement problem statement for > test protocols to measure IP Performance Metrics. The rate > measurement scenario has wide-spread attention of Internet access > subscribers and seemingly all industry players, including = regulators. > Key test protocol aspects require the ability to control packet size > on the tested path and enable asymmetrical packet size testing in a > controller-responder architecture. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_82BB398E-9368-4A56-8A84-2060CB01B9DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii draft-ietf-ippm-rate-problem has been updated with = changes requested by IPPM participants. As such, I am kicking off a WGLC = for draft-ietf-ippm-rate-problem-07 until November 5, 2014. Please = provide comments before the WGLC = ends.

Thanks,

Bill = Cerveny
IPPM WG co-chair

Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /span>
Subject: = [ippm] I-D = Action: draft-ietf-ippm-rate-problem-07.txt
Date: October 7, 2014 at 11:28:27 AM = EDT

<= br>A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the IP Performance Metrics = Working Group of the IETF.

=        Title =           : Rate = Measurement Test Protocol Problem Statement
=        Author =          : Al = Morton
= Filename        : = draft-ietf-ippm-rate-problem-07.txt
Pages =           : = 12
= Date =            : = 2014-10-07

Abstract:
  This memo presents an access = rate-measurement problem statement for
  test protocols to = measure IP Performance Metrics.  The rate
=   measurement scenario has wide-spread attention of Internet = access
  subscribers and seemingly all industry players, = including regulators.
  Key test protocol aspects require = the ability to control packet size
  on the tested path = and enable asymmetrical packet size testing in a
=   controller-responder architecture.



The IETF = datatracker status page for this draft is:
ht= tps://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/

Th= ere's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-07

A= diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-07<= br>

Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are available = at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
ippm mailing = list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

= --Apple-Mail=_82BB398E-9368-4A56-8A84-2060CB01B9DD-- From nobody Wed Oct 22 09:19:35 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9881ACE09 for ; Wed, 22 Oct 2014 09:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiqst61LfEdQ for ; Wed, 22 Oct 2014 09:19:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D55851ACE0D for ; Wed, 22 Oct 2014 09:18:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022161838.5136.16857.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 09:18:38 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/21Z4EaIi70caphFDOCHjZuWUKt8 Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 16:19:32 -0000 Changed milestone "Submit draft on reference path for measurement location to IESG as Informational", resolved as "Done". Changed milestone "Submit draft on access rate measurement protocol problem statement to IESG as Informational", set due date to November 2014 from April 2014. Changed milestone "Submit draft on OWAMP / TWAMP Security to IESG as Proposed Standard", set due date to November 2014 from April 2014. Changed milestone "Submit draft on model-based TCP bulk transfer capacity metrics to IESG as Experimental", set due date to November 2014 from July 2014. Changed milestone "Submit draft on core registry for performance metrics to IESG as Proposed Standard", set due date to March 2015 from August 2014. URL: http://datatracker.ietf.org/wg/ippm/charter/ From nobody Wed Oct 22 16:50:31 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20C91AD0A0 for ; Wed, 22 Oct 2014 16:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nsi-DtxdQoD for ; Wed, 22 Oct 2014 16:50:21 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6688A1A8822 for ; Wed, 22 Oct 2014 16:50:21 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hq12so2766093vcb.33 for ; Wed, 22 Oct 2014 16:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0/+iFBywNuROHdO7NwUr14CHM6fTXuoT6VAPMIyJJEc=; b=qWBH3dZir/7TFPLdAq7rrF6gqBPvIPe/oAeXiauhfjuVLLWXfSCHrQgv4k83aU2gO9 xpHOs1x7wT2xuVpyYP5OZy6m5mYrTRGmPoia4gh/u41ohWgfuZq00MXIZkzv9GAleqd8 tGvxdE39awJD/ue4ECQUfrqmtq8pCWQI9FCTpaNr/q03hl6JgtrRFnircq7PG74a1Xna vw8ljCT1hO5qUuNXnQQJuWAlsBuntX1c+PUDZDaYKDtIsnFRj3KXjwynDAQHMFmE8mUh YXnO7mCMrcJoW8cSr2nbJ2p6lRF94qCLoy9RtaqRXk6+klZDxqe6+jU3qRlBoZiORhzq JJOQ== MIME-Version: 1.0 X-Received: by 10.52.78.162 with SMTP id c2mr750813vdx.3.1414021820523; Wed, 22 Oct 2014 16:50:20 -0700 (PDT) Received: by 10.221.65.71 with HTTP; Wed, 22 Oct 2014 16:50:20 -0700 (PDT) In-Reply-To: References: <20141007152827.25462.89556.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 16:50:20 -0700 Message-ID: From: Greg Mirsky To: Bill Cerveny Content-Type: multipart/alternative; boundary=001a11365dce51306805060b9c01 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/iL4cogFKdRhWWo0-RakxNcKNAwg Cc: "ippm@ietf.org" Subject: Re: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 23:50:25 -0000 --001a11365dce51306805060b9c01 Content-Type: text/plain; charset=UTF-8 Dear Authors, et. al, please find my WG LC comments below: - Abstract. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. I believe that in our meeting in Toronto the WG agreed that support of asymmetrical test packet rate is required and support of asymmetrical packet size is recommended. Thus I propose following text update. Key test protocol aspects require the ability to control test packet characteristics on the tested path and enable asymmetrical test flow rates in controller-responder architecture. - Requirements Language Because this document is on Informational track, normative language of RFC 2119 not usually used. Use of defined RFC 2119 language may be explained by the following: Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document. - Section 2. Purpose and Scope As the WG agrees that the problem is asymmetric rate I propose to add to the list on p.3 'intra-pair spacing' and 'inter-pair interval' that both are referenced in Section 4. - Section 3. Active Rate Measurement P.5, second paragraph s/a it may be possible/it may be possible/ Not clear the intended role of asterics, double and single, in the text. Are these quotations? - Section 5. Test Protocol Control & Generation Requirements As the WG agreed that asymmetric test packet flow may be created by variating not just packet size but intra-pair spacing and/or inter-pair interval, requirement #4 is not generic but presents only one possible solution. I propose change requirement #4 to: 4. Asymmetric packet flows in a two-way measurement architecture I didn't find the reference to the definition or the definition of 'pseudo-one-way test' in the document and thus I propose the requirement to avoid the term. The next to last paragraph suggests: Implementations may support control and generation for only symmetric packet sizes when none of the above conditions hold. That contradicts earlier explanation that mentions variation of intra-pair spacing and inter-pair interval as possible method to generate asymmetric flow of test packets. Thus a protocol that can control spacing and/or intervals would be suitable to any combination of 1, 3, 4 and 6. Regards, Greg On Wed, Oct 22, 2014 at 9:05 AM, Bill Cerveny wrote: > draft-ietf-ippm-rate-problem has been updated with changes requested by > IPPM participants. As such, I am kicking off a WGLC > for draft-ietf-ippm-rate-problem-07 until November 5, 2014. Please provide > comments before the WGLC ends. > > Thanks, > > Bill Cerveny > IPPM WG co-chair > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **[ippm] I-D Action: draft-ietf-ippm-rate-problem-07.txt* > *Date: *October 7, 2014 at 11:28:27 AM EDT > *To: *i-d-announce@ietf.org > *Cc: *ippm@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Performance Metrics Working Group of > the IETF. > > Title : Rate Measurement Test Protocol Problem Statement > Author : Al Morton > Filename : draft-ietf-ippm-rate-problem-07.txt > Pages : 12 > Date : 2014-10-07 > > Abstract: > This memo presents an access rate-measurement problem statement for > test protocols to measure IP Performance Metrics. The rate > measurement scenario has wide-spread attention of Internet access > subscribers and seemingly all industry players, including regulators. > Key test protocol aspects require the ability to control packet size > on the tested path and enable asymmetrical packet size testing in a > controller-responder architecture. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-rate-problem-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --001a11365dce51306805060b9c01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors, et. al,
please find my WG LC comments below:
  • Abstract.
   Key test protocol aspects require the a=
bility to control packet size
   on the tested path and enable asymmetrical packet size testing in a
   controller-responder architecture.
I believe that in our meeting=
 in Toronto the WG agreed that support of asymmetrical test packet rate is =
required and support of asymmetrical packet size is recommended. Thus I pro=
pose following text update.
Key test protocol aspects requir=
e the ability to control test packet characteristics on the tested path and=
 enable asymmetrical test flow rates in controller-responder architecture.<=
br>
  • Requirements Language
Because this document is on Informational track, normativ= e language of RFC 2119 not usually used. Use of defined RFC 2119 language m= ay be explained by the following:

   Although this=
 document is not a protocol specification, the use of this language clarifi=
es the instructions to protocol designers
   producing solutions that satisfy the requirements set out in this docume=
nt.
  • Section 2. Purpose and Scope
<= div style=3D"margin-left:40px">As the WG agrees that the problem is asymmet= ric rate I propose to add to the list on p.3 'intra-pair spacing' a= nd 'inter-pair interval' that both are referenced in Section 4.
=
  • Section 3. Active Rate Measurement
P.5, second paragraph s/a it may be possible/it may b= e possible/
Not clear the intended= role of asterics, double and single, in the text. Are these quotations?
  • Section 5. Test Protocol Control & Generation Requireme= nts
As the WG agreed that as= ymmetric test packet flow may be created by variating not just packet size = but intra-pair spacing and/or inter-pair interval, requirement #4 is not ge= neric but presents only one possible solution. I propose change requirement= #4 to:
4. Asymmetric packet flows= in a two-way measurement architecture

I d= idn't find the reference to the definition or the definition of 'ps= eudo-one-way test' in the document and thus I propose the requirement t= o avoid the term.

The n= ext to last paragraph suggests:
 Implementations may support control and gen=
eration for only symmetric packet sizes when none of the above conditions h=
old.
That contradicts earlier explan= ation that mentions variation of intra-pair spacing and inter-pair interval= as possible method to generate asymmetric flow of test packets. Thus a pro= tocol that can control spacing and/or intervals would be suitable to any co= mbination of 1, 3, 4 and 6.

Regards,
Greg
<= br>


On Wed, Oc= t 22, 2014 at 9:05 AM, Bill Cerveny <ippm@wjcerveny.com> wr= ote:
= draft-ietf-ippm-rate-problem has been updated with changes requested by IPP= M participants. As such, I am kicking off a WGLC for=C2=A0draft-ietf-ippm-r= ate-problem-07 until November 5, 2014. Please provide comments before the W= GLC ends.

Thanks,

Bill Cerveny<= /div>
IPPM WG co-chair

Begin forwarded message:
<= br>
Subject: = [ippm] I-D Action= : draft-ietf-ippm-rate-problem-07.txt
Date: October 7, 2014 at 11:2= 8:27 AM EDT


A New Internet= -Draft is available from the on-line Internet-Drafts directories.
This = draft is a work item of the IP Performance Metrics Working Group of the IET= F.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Rate Measurement Test Protoc= ol Problem Statement
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Author = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Al Morton
Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0: draft-ietf-ippm-rate-problem-07.txt
Pages =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0: 12
Date= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2014-1= 0-07

Abstract:
=C2=A0=C2=A0This memo presents an access rate-mea= surement problem statement for
=C2=A0=C2=A0test protocols to measure IP= Performance Metrics.=C2=A0 The rate
=C2=A0=C2=A0measurement scenario h= as wide-spread attention of Internet access
=C2=A0=C2=A0subscribers and= seemingly all industry players, including regulators.
=C2=A0=C2=A0Key = test protocol aspects require the ability to control packet size
=C2=A0= =C2=A0on the tested path and enable asymmetrical packet size testing in a =C2=A0=C2=A0controller-responder architecture.



The IETF d= atatracker status page for this draft is:
https://data= tracker.ietf.org/doc/draft-ietf-ippm-rate-problem/

There's a= lso a htmlized version available at:
http://tools.ietf.org= /html/draft-ietf-ippm-rate-problem-07

A diff from the previous v= ersion is available at:
http://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-ippm-rate-problem-07


Please note that it= may take a couple of minutes from the time of submission
until the html= ized version and diff are available at tools.ietf.org.

Internet-Drafts are also availab= le by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

__________= _____________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.o= rg/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
ippm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ippm


--001a11365dce51306805060b9c01-- From nobody Thu Oct 23 12:23:38 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DCD1A0A6A; Thu, 23 Oct 2014 12:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riCBcPC4m9D5; Thu, 23 Oct 2014 12:23:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D80B31A07BC; Thu, 23 Oct 2014 12:23:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141023192332.24253.91748.idtracker@ietfa.amsl.com> Date: Thu, 23 Oct 2014 12:23:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/GPSwXcm5W04afI6ZY9VId_UHhpk Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-2679-bis-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 19:23:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A One-Way Delay Metric for IPPM Authors : Guy Almes Sunil Kalidindi Matt Zekauskas Al Morton Filename : draft-ietf-ippm-2679-bis-00.txt Pages : 24 Date : 2014-10-23 Abstract: This memo (RFC 2679 bis) defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-2679-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-2679-bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 23 12:26:07 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF641ACEAD; Thu, 23 Oct 2014 12:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh0YP5TA05wK; Thu, 23 Oct 2014 12:26:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0211A03C7; Thu, 23 Oct 2014 12:26:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141023192603.544.88602.idtracker@ietfa.amsl.com> Date: Thu, 23 Oct 2014 12:26:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/eBGUl7DhUzwpHpxRXfy98li-KBo Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-2680-bis-00.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 19:26:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A One-Way Loss Metric for IPPM Authors : Guy Almes Sunil Kalidindi Matt Zekauskas Al Morton Filename : draft-ietf-ippm-2680-bis-00.txt Pages : 19 Date : 2014-10-23 Abstract: This memo (RFC 2680 bis) defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-2680-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-2680-bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 24 06:28:06 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197AA1A002A for ; Fri, 24 Oct 2014 06:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1bhpb6GoJzn for ; Fri, 24 Oct 2014 06:27:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BC81A00EB for ; Fri, 24 Oct 2014 06:27:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024132751.31608.35944.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 06:27:51 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/GA4jnIUM1toD2QOvrZMTd3kDsU8 Subject: [ippm] Milestones changed for ippm WG X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:28:02 -0000 URL: http://datatracker.ietf.org/wg/ippm/charter/ From nobody Sat Oct 25 14:10:04 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B8E1A1A45 for ; Sat, 25 Oct 2014 14:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugZ6tmhCBj-F for ; Sat, 25 Oct 2014 14:09:28 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC5F1A1A17 for ; Sat, 25 Oct 2014 14:09:20 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id 55B5D12040B; Sat, 25 Oct 2014 17:09:45 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id 0C822E15FB; Sat, 25 Oct 2014 16:57:31 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Sat, 25 Oct 2014 17:00:01 -0400 From: "MORTON, ALFRED C (AL)" To: Bill Cerveny , "ippm@ietf.org" Date: Sat, 25 Oct 2014 17:00:00 -0400 Thread-Topic: [ippm] WGLC: draft-ietf-ippm-ipsec-05.txt Thread-Index: Ac/op3HR9yFKwU52T8O4Elhd0NHlygH7ZJ5/ Message-ID: <4AF73AA205019A4C8A1DDD32C034631D7BBF8A2B@NJFPSRVEXG0.research.att.com> References: <20140919143517.9076.18495.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/VK90Cqi2TxgROxjLezzPJvxxOdA Subject: Re: [ippm] WGLC: draft-ietf-ippm-ipsec-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 21:09:43 -0000 I see a small issue in this draft. =20 Although the proposal is applicable to both OWAMP and TWAMP, we currently have no registry available to extend OWAMP and use this new mode -- IOW, there is no IANA Registry for OWAMP Mode bit positions. In the near term, the draft could be positioned to extend TWAMP and mention clear applicability to OWAMP (but no current way to register the extension). In the long term, IPPM could establish the Modes and Commands=20 registries for OWAMP and (in the process) decide if we will try to simplify life by coordinating bit positions for both -WAMPs (which would mean going back and specifying the OWAMP equivalent of all the applicable existing TWAMP Modes. I'm fairly sure I mentioned this issue to Kostas in an exchange last month, so it's not a complete surprise, and I'm sure we can work out the changes to accomodate the missing OWAMP registry. regards, Al ________________________________________ From: ippm [ippm-bounces@ietf.org] On Behalf Of Bill Cerveny [ippm@wjcerven= y.com] Sent: Wednesday, October 15, 2014 2:39 PM To: ippm@ietf.org Subject: [ippm] WGLC: draft-ietf-ippm-ipsec-05.txt A WGLC is being commenced for draft-ietf-ippm-ipsec until Saturday, Novembe= r 1, 2014. The authors are particularly interested in comments regarding c= hanges made to the document since IETF90. These changed can be observed at: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-ippm-ipsec-04&difftype=3D--h= tml&submit=3DGo%21&url2=3Ddraft-ietf-ippm-ipsec-05 Regards, Bill Cerveny IPPM WG co-chair Begin forwarded message: From: internet-drafts@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-ipsec-05.txt Date: September 19, 2014 at 10:35:17 AM EDT To: i-d-announce@ietf.org Cc: ippm@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of th= e IETF. Title : IKEv2-based Shared Secret Key for O/TWAMP Authors : Kostas Pentikousis Emma Zhang Yang Cui Filename : draft-ietf-ippm-ipsec-05.txt Pages : 12 Date : 2014-09-19 Abstract: The O/TWAMP security mechanism requires that both the client and server endpoints possess a shared secret. Since the currently- standardized O/TWAMP security mechanism only supports a pre-shared key mode, large scale deployment of O/TWAMP is hindered significantly. At the same time, recent trends point to wider IKEv2 deployment which, in turn, calls for mechanisms and methods that enable tunnel end-users, as well as operators, to measure one-way and two-way network performance in a standardized manner. This document discusses the use of keys derived from an IKEv2 SA as the shared key in O/TWAMP. If the shared key can be derived from the IKEv2 SA, O/ TWAMP can support certificate-based key exchange, which would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-ipsec-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-ipsec-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Mon Oct 27 03:43:14 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697971A906A for ; Mon, 27 Oct 2014 03:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.209 X-Spam-Level: X-Spam-Status: No, score=-13.209 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id org-9kvycWgD for ; Mon, 27 Oct 2014 03:41:02 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375E21A9062 for ; Mon, 27 Oct 2014 03:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=191637; q=dns/txt; s=iport; t=1414406461; x=1415616061; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=uSfkPM/aO1kg7ztTUn91Qo1mLFjQEGN8jPS5Mwkf9Bo=; b=CDK76mx1cXQDnOobKKScuo7tgkHzuh+LQszS+ujOvnwPkSKivcqiLMmK 5e3wPJ+84+3UNxsPfF4+HksHAL/bS+shOdfgH5unHGEAK5IOr5zx5RgnR 32+/bAYy+tzfRTr78z1apBoCHfTMkuD+7LvIAeSXVjBH1sB+erxbGusxf g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAAUhTlStJssW/2dsb2JhbABSAQmDYljDQYl8h00CgSgBfYQDAQEDARoBAgpEAwoGCQIsFgEBDQkDAgECAQk8BgEJAwQCAgEBBQsFiB8JDckRAQEBAQEBAQECAQEBAQEBAQEBGQSKbIUrCgEGAQMHAQcdM4RLBYYth3eBRYZmgXdMgX2CUoExESuDDYJyhTCBc4MfhACDeTwEKwGBBQEBBxcGgR8BAQE X-IronPort-AV: E=Sophos;i="5.04,795,1406592000"; d="scan'208,217";a="226977021" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 27 Oct 2014 10:40:42 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9RAee6L018501; Mon, 27 Oct 2014 10:40:40 GMT Message-ID: <544E2128.1030204@cisco.com> Date: Mon, 27 Oct 2014 11:40:40 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: draft-ietf-ippm-metric-registry@tools.ietf.org, IETF IPPM WG , Aamer Akhter References: <544E0FF9.7070904@cisco.com> In-Reply-To: <544E0FF9.7070904@cisco.com> Content-Type: multipart/alternative; boundary="------------010201070901000701030307" Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/KDP4mkB0YccWzlVn_9-f4W1x_pg X-Mailman-Approved-At: Mon, 27 Oct 2014 03:43:11 -0700 Subject: [ippm] draft-ietf-ippm-metric-registry-01 review X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 10:41:24 -0000 This is a multi-part message in MIME format. --------------010201070901000701030307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is my review of draft-ietf-ippm-metric-registry-01. Sent to IPPM to generate some discussions. > Network Working Group M. Bagnulo > Internet-Draft UC3M > Intended status: Best Current Practice B. Claise > Expires: March 14, 2015 Cisco Systems, Inc. > P. Eardley > BT > A. Morton > AT&T Labs > A. Akhter > Cisco Systems, Inc. > September 10, 2014 > > > Registry for Performance Metrics > draft-ietf-ippm-metric-registry-01 > > Abstract > > This document defines the IANA Registry for Performance Metrics. > This document also gives a set of guidelines for Registered > Performance Metric requesters and reviewers. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on March 14, 2015. > > Copyright Notice > > Copyright (c) 2014 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > > > > Bagnulo, et al. Expires March 14, 2015 [Page 1] > > Internet-Draft Registry for Performance Metrics September 2014 > > > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 5. Design Considerations for the Registry and Registered Metrics 7 > 5.1. Interoperability . . . . . . . . . . . . . . . . . . . . 7 > 5.2. Criteria for Registered Performance Metrics . . . . . . . 8 > 5.3. Single point of reference for Performance metrics . . . . 8 > 5.4. Side benefits . . . . . . . . . . . . . . . . . . . . . . 9 > 6. Performance Metric Registry: Prior attempt . . . . . . . . . 9 > 6.1. Why this Attempt Will Succeed? . . . . . . . . . . . . . 10 > 7. Defintion of the Performance Metric Registry . . . . . . . . 10 > 7.1. Summary Category . . . . . . . . . . . . . . . . . . . . 12 > 7.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 12 > 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 13 > 7.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 13 > 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 14 > 7.2. Metric Definition Category . . . . . . . . . . . . . . . 14 > 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 14 > 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 14 > 7.3. Method of Measurement Category . . . . . . . . . . . . . 15 > 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 15 > 7.3.2. Packet Generation Stream . . . . . . . . . . . . . . 15 > 7.3.3. Traffic Filter . . . . . . . . . . . . . . . . . . . 16 > 7.3.4. Sampling distribution . . . . . . . . . . . . . . . . 16 > 7.3.5. Run-time Parameters . . . . . . . . . . . . . . . . . 16 > 7.3.6. Role . . . . . . . . . . . . . . . . . . . . . . . . 17 > 7.4. Output Category . . . . . . . . . . . . . . . . . . . . . 17 > 7.4.1. Value . . . . . . . . . . . . . . . . . . . . . . . . 17 > 7.4.2. Data Format . . . . . . . . . . . . . . . . . . . . . 17 > 7.4.3. Reference . . . . . . . . . . . . . . . . . . . . . . 18 > 7.4.4. Metric Units . . . . . . . . . . . . . . . . . . . . 18 > 7.5. Admisnitratvie information . . . . . . . . . . . . . . . 18 > 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 18 > 7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 18 > 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 18 > 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 18 > 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 18 > 8. The Life-Cycle of Registered Metrics . . . . . . . . . . . . 19 > 8.1. Adding new Performance Metrics to the Registry . . . . . 19 > > > > Bagnulo, et al. Expires March 14, 2015 [Page 2] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 8.2. Revising Registered Performance Metrics . . . . . . . . . 20 > 8.3. Deprecating Registered Performance Metrics . . . . . . . 21 > 9. Performance Metric Registry and other Registries . . . . . . 22 > 10. Security considerations . . . . . . . . . . . . . . . . . . . 22 > 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 > 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 > 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 > 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 > 13.2. Informative References . . . . . . . . . . . . . . . . . 24 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 > > 1. Open Issues > > 1. Many aspects of the Naming convention are TBD, and need > discussion. For example, we have distinguished RTCP-XR metrics > as End-Point (neither active nor passive in the traditional > sense, so not Act_ or Pas_). Even though we may not cast all > naming conventions in stone at the start, it will be helpful to > look at several examples of passive metric names now. > > 2. We should expand on the different roles and responsibilities of > the Performance Metrics Experts versus the Performance Metric > Directorate. At least, the Performance Metric Directorate one > should be expanded. --- (v7) If these are different entities, our > only concern is the role of the "PM Experts". I would in favor or removing the Performance Metric Directorate. The directorates are for the benefit of the AD. From RFC 2418 and http://www.ietf.org/iesg/directorate.html A request for Revision is ONLY permissible when the changes maintain backward-compatibility with implementations of the prior Registry entry describing a Registered Metric (entries with lower revision numbers, but the same Identifier and Name). Also, the directorate live and goal might change along the time. So specify the directorate goal is in stone in a RFC is not appropriate. However, a sentence such as: at the time of writing this line, a performance metric directorate exists, which can help .... > > 3. Revised Registry Entries: Keep for history (deprecated) or > Delete? We should delete. See in line > > 4. Need to include an example for a name for a passive metric > > 5. Definition of Parameter needs more work? > > 6. Whether the name of the metric should contain the version of the > metric No. Because we have a new performance metric revision, and it must be interoperable. > > 7. reserve some values for examples and private use? > > 8. should we define a "type" column with the possible values > "active" "passive" "hybrid" "endpoint"? if we go for all 4 of > them, we should define the corresponding prefixes for the metric > name (at this point only the pas and act are defined) > > 9. URL: should we include a URL link in each registry entry with a > URL specific to the entry that links to a different text page > that contains all the details of the registry entry as in > http://www.iana.org/assignments/xml-registry/xml- > registry.xhtml#ns > > I don't understand which advantages this adds. If I compare with IPFIX, which has got a similar mechanism, it's easier for a collector to download a single file. > > Bagnulo, et al. Expires March 14, 2015 [Page 3] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 2. Introduction > > The IETF specifies and uses Performance Metrics of protocols and > applications transported over its protocols. Performance metrics are > such an important part of the operations of IETF protocols that > [RFC6390] specifies guidelines for their development. > > The definition and use of Performance Metrics in the IETF happens in > various working groups (WG), most notably: > > The "IP Performance Metrics" (IPPM) WG is the WG primarily > focusing on Performance Metrics definition at the IETF. > > The "Metric Blocks for use with RTCP's Extended Report Framework" > (XRBLOCK) WG recently specified many Performance Metrics related > to "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611], > which establishes a framework to allow new information to be > conveyed in RTCP, supplementing the original report blocks defined > in "RTP: A Transport Protocol for Real-Time Applications", > [RFC3550]. > > The "Benchmarking Methodology" WG (BMWG) defined many Performance > Metrics for use in laboratory benchmarking of inter-networking > technologies. > > The "IP Flow Information eXport" (IPFIX) WG Information elements > related to Performance Metrics are currently proposed. > > The "Performance Metrics for Other Layers" (PMOL) concluded WG, > defined some Performance Metrics related to Session Initiation > Protocol (SIP) voice quality [RFC6035]. > > It is expected that more Performance Metrics will be defined in the > future, not only IP-based metrics, but also metrics which are > protocol-specific and application-specific. > > However, despite the importance of Performance Metrics, there are two > related problems for the industry. First, how to ensure that when > one party requests another party to measure (or report or in some way > act on) a particular Performance Metric, then both parties have > exactly the same understanding of what Performance Metric is being > referred to. Second, how to discover which Performance Metrics have > been specified, so as to avoid developing new Performance Metric that > is very similar. The problems can be addressed by creating a > registry of performance metrics. The usual way in which IETF > organizes namespaces is with Internet Assigned Numbers Authority > (IANA) registries, and there is currently no Performance Metrics > Registry maintained by the IANA. > > > > Bagnulo, et al. Expires March 14, 2015 [Page 4] > > Internet-Draft Registry for Performance Metrics September 2014 > > > This document therefore creates a Performance Metrics Registry. It > also provides best practices on how to define new or updated entries > in the Performance Metrics Registry. NEW: This document therefore creates a Performance Metrics Registry. It also provides best practices on how to specify new entries or update ones in the Performance Metrics Registry. > > 3. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. > > The terms Performance Metric and Performance Metrics Directorate are > defined in [RFC6390], and copied over in this document for the > readers convenience. > > Performance Metric: A Performance Metric is a quantitative measure > of performance, specific to an IETF-specified protocol or specific > to an application transported over an IETF-specified protocol. > Examples of Performance Metrics are the FTP response time for a > complete file download, the DNS response time to resolve the IP > address, a database logging time, etc. > > Registered Performance Metric: A Registered Performance Metric (or > Registered Metric) is a Performance Metric expressed as an entry > in the Performance Metric Registry, and comprised of a > specifically named metric which has met all the registry review > criteria, is under the curation of IETF Performance Metrics > Experts, and whose changes are controlled by IANA. I don't understand why"and comprised of a specifically named metric which has met all the registry review criteria," is needed. Candidate to remove "and whose changes are controlled by IANA". It seems to imply that Registered Performance Metric change is normal. Not really. "is under the curation of IETF Performance Metrics Experts". The Performance Metrics Experts are the experts IANA calls for entry validation. NEW: Registered Performance Metric: A Registered Performance Metric (or Registered Metric) is a Performance Metric expressed as an entry in the Performance Metric Registry, administered by IANA. > > Performance Metrics Registry: The IANA registry containing > Registered Performance Metrics. In this document, it is also > called simply "Registry". > > Proprietary Registry: A set of metrics that are registered in a > proprietary registry, as opposed to Performance Metrics Registry. > > Performance Metrics Experts: The Performance Metrics Experts is a > group of experts selected by the IESG to validate the Performance > Metrics before updating the Performance Metrics Registry. The > Performance Metrics Experts work closely with IANA. > > Performance Metrics Directorate: The Performance Metrics Directorate > is a directorate that provides guidance for Performance Metrics > development in the IETF. The Performance Metrics Directorate > should be composed of experts in the performance community, > potentially selected from the IP Performance Metrics (IPPM), > Benchmarking Methodology (BMWG), and Performance Metrics for Other > Layers (PMOL) WGs. PMOL doesn't exist any longer. So the last sentence is difficult to fulfill. At some point in time, the other WGs will not exist any longer. NEW: Performance Metrics Directorate: The Performance Metrics Directorate is a directorate that provides guidance for Performance Metrics development in the IETF. The following sentence (NEW) should not be part of the definition, but be part of a subsequent performance metrics directorate paragraph (note: if we keep it in the draft) The Performance Metrics Directorate should be composed of experts in the performance community, potentially selected from the IP Performance Metrics (IPPM), Benchmarking Methodology (BMWG), and the closed Performance Metrics for Other Layers (PMOL) WGs, or any future performance-related WGs. > > > > Bagnulo, et al. Expires March 14, 2015 [Page 5] > > Internet-Draft Registry for Performance Metrics September 2014 > > > Parameter: An input factor defined as a variable in the definition > of a metric. A numerical or other specified factor forming one of > a set that defines a metric or sets the conditions of its > operation. All Input Parameters must be known to measure using a > metric and interpret the results. Although Input Parameters do > not change the fundamental nature of the metric's definition, some > have substantial influence on the network property being assessed > and interpretation of the results. > > Consider the case of packet loss in the following two cases. NEW: Consider the case of packet loss in the following two Active Measurement Method cases. > The first case is packet loss as background loss where the > parameter set includes a very sparse Poisson stream, and only > characterizes the times when packets were lost. Actual user > streams likely see much higher loss at these times, due to tail > drop or radio errors. The second case is packet loss as > inverse of Throughput where the parameter set includes a very throughput > dense, bursty stream, and characterizes the loss experienced by > a stream that approximates a user stream. These are both "loss > metrics", but the difference in interpretation of the results > is highly dependent on the Parameters (at least), to the > extreme where we are actually using loss to infer its > compliment: delivered throughput. > > Active Measurement Method: Methods of Measurement conducted on > traffic which serves only the purpose of measurement and is > generated for that reason alone, and whose traffic characteristics > are known a priori. An Internet user's host can generate active > measurement traffic (virtually all typical user-generated traffic > is not dedicated to active measurement, but it can produce such > traffic with the necessary application operating). Not sure what the previous sentence adds to the definition. I would add some examples. OWAMP, TWAMP, IP SLA > > Passive Measurement Method: Methods of Measurement conducted on > network traffic, generated either from the end users or from > network elements. "generated" in the previous sentence is wrong Maybe Passive Measurement Method: Methods of Measurement conducted on network traffic, issue either by the end users or by network elements, as opposed to active traffic (see Active Measurement method) > One characteristic of Passive Measurement > Methods is that sensitive information may be observed, and as a > consequence, stored in the measurement system. I would add some examples. IPFIX, PSAMP. [RFC 5470], [RFC 5476] > > Hybrid Measurement Method: Methods of Measurement which use a > combination of Active Measurement and Passive Measurement methods. > > 4. Scope > > The intended audience of this document includes those who prepare and > submit a request for a Registered Performance Metric, and for the > Performance Metric Experts who review a request. The above should be improved. A good example is http://tools.ietf.org/html/rfc7013#section-1.1. > > This document specifies a Performance Metrics Registry in IANA. This > Performance Metric Registry is applicable to Performance Metrics > > > > Bagnulo, et al. Expires March 14, 2015 [Page 6] > > Internet-Draft Registry for Performance Metrics September 2014 > > > issued from Active Measurement, Passive Measurement, from end-point > calculation or any other form of Performance Metric. This registry > is designed to encompass Performance Metrics developed throughout the > IETF and especially for the following existing working groups: IPPM, > XRBLOCK, IPFIX, and BMWG. This document analyzes an prior attempt to > set up a Performance Metric Registry, and the reasons why this design > was inadequate [RFC6248]. Finally, this document gives a set of > guidelines for requesters and expert reviewers of candidate > Registered Performance Metrics. > > This document makes no attempt to populate the Registry with initial > entries. It does provides a few examples that are merely > illustrations and should not be included in the registry at this > point in time. > > Based on [RFC5226] Section 4.3, this document is processed as Best > Current Practice (BCP) [RFC2026]. > > 5. Design Considerations for the Registry and Registered Metrics The title is confusing: it seems that you treat both the Registry and the Registered Metrics in the section. Let me propose 5. Motivation for a Performance Metrics Registry 5.1 Interoperability 5.2 Single point of reference for performance metrics note: this is the actual content of 5.3 5.3 Side Benefits note: this is the actual content of 5.4 6. Criteria for Performance Metrics Registration note: this is the actual content of 5.2 note2: the title has been slightly changed compared to 5.2 I believe it's close to the content. > > In this section, we detail several design considerations that are > relevant for understanding the motivations and expected use of the > Performance Metric Registry. > > 5.1. Interoperability > > As any IETF registry, the primary use for a registry is to manage a > namespace for its use within one or more protocols. In this > particular case of the Performance Metric Registry, there are two > types of protocols that will use the values defined in the Registry > for their operation: NEW: As any IETF registry, the primary use for a registry is to manage a namespace for its use within one or more protocols. In this particular case of the Performance Metric Registry, there are two types of protocols that will use the _Performance Metrics_ defined in the Registry for their operation: > > o Control protocol: this type of protocols is used to allow one > entity to request another entity to perform a measurement using a > specific metric defined by the Registry. One particular example > is the LMAP framework [I-D.ietf-lmap-framework]. Using the LMAP > terminology, the Registry is used in the LMAP Control protocol to > allow a Controller to request a measurement task to one or more > Measurement Agents. In order to enable this use case, the entries > of the Performance Metric Registry must be well enough defined to > allow a Measurement Agent implementation to trigger a specific > measurement task upon the reception of a control protocol message. > This requirements heavily constrains the type of entries that are > acceptable for the Performance Metric Registry. > > o Report protocol: This type of protocols is used to allow an entity > to report measurement results to another entity. By referencing > to a specific Performance Metric Registry, it is possible to > > > > Bagnulo, et al. Expires March 14, 2015 [Page 7] > > Internet-Draft Registry for Performance Metrics September 2014 > > > properly characterize the measurement result data being > transferred. Using the LMAP terminology, the Registry is used in > the Report protocol to allow a Measurement Agent to report > measurement results to a Collector. > > 5.2. Criteria for Registered Performance Metrics NEW: 5.2. Criteria for Performance Metrics Registration > > It is neither possible nor desirable to populate the Registry with > all combinations of input parameters of all Performance Metrics. The > Registered Performance Metrics should be: > > 1. interpretable by the user. > > 2. implementable by the software designer, > > 3. deployable by network operators, without major impact on the > networks, > > 4. accurate, for interoperability and deployment across vendors, > > 5. Operational useful, so that it has significant industry interest > and/or has seen deployment, > > 6. Sufficiently tightly defined, so that changing Parameters does > not change the fundamental nature of the measurement, nor change > the practicality of its implementation. > > In essence, there needs to be evidence that a candidate Registry > entry has significant industry interest, or has seen deployment, and > there is agreement that the candidate Registered Metric serves its > intended purpose. > > 5.3. Single point of reference for Performance metrics metrics -> Metrics > > A Registry for Performance metrics serves as a single point of metrics -> Metrics Maybe more instance. Please check throughout the draft > reference for Performance Metrics defined in different working groups > in the IETF. As we mentioned earlier, there are several WGs that > define Performance Metrics in the IETF and it is hard to keep track > of all them. This results in multiple definitions of similar metrics > that attempt to measure the same phenomena but in slightly different > (and incompatible) ways. Having a Registry would allow both the IETF > community and external people to have a single list of relevant > Performance Metrics defined by the IETF (and others, where > appropriate). The single list is also an essential aspect of > communication about metrics, where different entities that request > measurements, execute measurements, and report the results can > benefit from a common understanding of the referenced metric. > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 8] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 5.4. Side benefits > > There are a couple of side benefits of having such a Registry. > First, the Registry could serve as an inventory of useful and used > metrics, that are normally supported by different implementations of > measurement agents. Second, the results of the metrics would be > comparable even if they are performed by different implementations > and in different networks, as the metric is properly defined. BCP > 176 [RFC6576] examines whether the results produced by independent > implementations are equivalent in the context of evaluating the > completeness and clarity of metric specifications. This BCP defines > the standards track advancement testing for (active) IPPM metrics, > and the same process will likely suffice to determine whether > Registry entries are sufficiently well specified to result in > comparable (or equivalent) results. Registry entries which have > undergone such testing SHOULD be noted, with a reference to the test > results. > > 6. Performance Metric Registry: Prior attempt > > There was a previous attempt to define a metric registry RFC 4148 > [RFC4148]. However, it was obsoleted by RFC 6248 [RFC6248] because > it was "found to be insufficiently detailed to uniquely identify IPPM > metrics... [there was too much] variability possible when > characterizing a metric exactly" which led to the RFC4148 registry > having "very few users, if any". > > A couple of interesting additional quotes from RFC 6248 might help > understand the issues related to that registry. > > 1. "It is not believed to be feasible or even useful to register > every possible combination of Type P, metric parameters, and > Stream parameters using the current structure of the IPPM Metrics > Registry." > > 2. "The registry structure has been found to be insufficiently > detailed to uniquely identify IPPM metrics." > > 3. "Despite apparent efforts to find current or even future users, > no one responded to the call for interest in the RFC 4148 > registry during the second half of 2010." > > The current approach learns from this by tightly defining each entry > in the registry with only a few variable Parameters to be specified > by the measurement designer, if any. The idea is that entries in the > Registry represent different measurement methods which require input represent -> stem from > parameters to set factors like source and destination addresses > (which do not change the fundamental nature of the measurement). The > > > > Bagnulo, et al. Expires March 14, 2015 [Page 9] > > Internet-Draft Registry for Performance Metrics September 2014 > > > downside of this approach is that it could result in a large number > of entries in the Registry. We believe that less is more in this > context - it is better to have a reduced set of useful metrics rather > than a large set of metrics with questionable usefulness. Therefore > this document defines that the Registry only includes metrics that > are well defined and that have proven to be operationally useful. In > order to guarantee these two characteristics we require that a set of > experts review the allocation request to verify that the metric is > well defined and it is operationally useful. > > 6.1. Why this Attempt Will Succeed? > > The Registry defined in this document addresses the main issues > identified in the previous attempt. As we mention in the previous > section, one of the main issues with the previous registry was that > the metrics contained in the registry were too generic to be useful. > In this Registry, the Registry requests are evaluated by an expert > group, the Performance Metrics Experts, who will make sure that the > metric is properly defined. This document provides guidelines to > assess if a metric is properly defined. > > Another key difference between this attempt and the previous one is > that in this case there is at least one clear user for the Registry: > the LMAP framework and protocol. Because the LMAP protocol will use > the Registry values in its operation, this actually helps to > determine if a metric is properly defined. In particular, since we > expect that the LMAP control protocol will enable a controller to > request a measurement agent to perform a measurement using a given > metric by embedding the Performance Metric Registry value in the > protocol, a metric is properly specified if it is defined well-enough > so that it is possible (and practical) to implement the metric in the > measurement agent. This was clearly not the case for the previous > attempt: defining a metric with an undefined P-Type makes its > implementation unpractical. P-Type is really IPPM specific, while the registry is not IPPM specific. Either you should really explain this concept or remove. > > 7. Defintion of the Performance Metric Registry > > In this section we define the columns of the Performance Metric > Registry. This registry will contain all Registered Performance > Metrics including active, passive, hybrid, endpoint metrics and any > other type of performance metric that can be envisioned. Because of > that, it may be the case that some of the columns defined are not > applicable for a given type of metric. If this is the case, the > column(s) SHOULD be populated with the "NA" value (Non Applicable). > However, the "NA" value MUST NOT be used any any metric in the any any -> by any > following columns: Identifier, Name, URI, Status, Requester, > Revision, Revision Date, Description and Reference Specification. > Moreover, In addition, it may be possible that in the future, a new > > > > Bagnulo, et al. Expires March 14, 2015 [Page 10] > > Internet-Draft Registry for Performance Metrics September 2014 > > > type of metric requires additional columns. Should that be the case, > it is possible to add new columns to the registry. The specification > defining the new column(s) MUST define how to populate the new > column(s) for existing entries. MUST -> must > > The columns of the Performance Metric Registry are defined next. The > columns are grouped into "Categories" to facilitate the use of the > registry. Categories are described at the 3.x heading level, and > columns are at the 3.x.y heading level. The Figure below illustrates > this organization. An entry (row) therefore gives a complete > description of a Registered Metric. 3.x and 3.x.y are wrong > > Each column serves as a check-list item and helps to avoid omissions > during registration and expert review. In some cases an entry (row) > may have some columns without specific entries, marked Not Applicable > (NA). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 11] > > Internet-Draft Registry for Performance Metrics September 2014 > > > Registry Categories and Columns, shown as > Category > ------------------ > Column | Column | Some formatting issues. > > Summary > ------------------------------- > ID | Name | URI | Description | > > > Metric Definition > ----------------------------------------- > Reference Definition | Fixed Parameters | > > > Method of Measurement > --------------------------------------------------------------------------------- > Reference Method | Packet Generation | Traffic | Sampling > | Run-time | Role | > | Stream | Filter | distribution > | Param | | > > Output > ----------------------------------------- > | Type | Reference | Data | Units | > | | Definition | Format | | > > > Administrative information > ---------------------------------- > Status |Request | Rev | Rev.Date | > > > Comments and Remarks > -------------------- > > > > 7.1. Summary Category > > 7.1.1. Identifier > > A numeric identifier for the Registered Performance Metric. This > identifier MUST be unique within the Performance Metric Registry. > > The Registered Performance Metric unique identifier is a 16-bit > integer (range 0 to 65535). When adding newly Registered Performance > Metrics to the Performance Metric Registry, IANA SHOULD assign the > lowest available identifier to the next Registered Performance > Metric. SHOULD -> should. > > > > Bagnulo, et al. Expires March 14, 2015 [Page 12] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 7.1.2. Name > > As the name of a Registered Performance Metric is the first thing a > potential implementor will use when determining whether it is > suitable for a given application, it is important to be as precise > and descriptive as possible. , while maintaining readability. > New names of Registered Performance > Metrics: > > 1. "MUST be chosen carefully to describe the Registered Performance > Metric and the context in which it will be used." > > 2. "MUST be unique within the Performance Metric Registry." > > 3. "MUST use capital letters for the first letter of each component > . All other letters MUST be lowercase, even for acronyms. > Exceptions are made for acronyms containing a mixture of > lowercase and capital letters, such as 'IPv4' and 'IPv6'." > > 4. "MUST use '_' between each component composing the Registered > Performance Metric name." > > 5. "MUST start with prefix Act_ for active measurement Registered > Performance Metric." > > 6. "MUST start with prefix Pas_ for passive monitoring Registered > Performance Metric." > > 7. Other types of metrics should define a proper prefix for > identifying the type. > > 8. The remaining rules for naming are left to the Performance > Experts to determine as they gather experience, so this is an > area of planned update by a future RFC. 9. Should be in sync with the different values in the registry. example: must contain "Pas" if the value of Reference Method field is passive, right? > An example is "Act_UDP_Latency_Poisson_99mean" for a active > monitoring UDP latency metric using a Poisson stream of packets and > producing the 99th percentile mean as output. > > 7.1.3. URI > > The URI column MUST contain a URI [RFC 3986] that uniquely identified > the metric. The URI is a URN [RFC 2141]. The URI is automatically > generated by prepending the prefix urn:ietf:params:ippm:metric: to > the metric name. The resulting URI is globally unique. At this point, I see in the 7.X a mix of instruction for the Perf. Metric Experts and for IANA. IANA: the sentence above or the last sentence in 7.1 Shouldn't we separate the instructions in IANA in the IANA considerations section? > > > > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 13] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 7.1.4. Description > > A Registered Performance Metric Description is a written > representation of a particular Registry entry. It supplements the > metric name to help Registry users select relevant Registered > Performance Metrics. > > 7.2. Metric Definition Category > > This category includes columns to prompt all necessary details > related to the metric definition, including the RFC reference and > values of input factors, called fixed parameters, which are left open > in the RFC but have a particular value defined by the performance > metric. > > 7.2.1. Reference Definition > > This entry provides a reference (or references) to the relevant > section(s) of the document(s) that define the metric, as well as any > supplemental information needed to ensure an unambiguous definition > for implementations. The reference needs to be an immutable > document, such as an RFC; for other standards bodies, it is likely to > be necessary to reference a specific, dated version of a > specification. you speak about other standard bodies here (which I agree with), but here is the definition Performance Metric: A Performance Metric is a quantitative measure of performance, specific to an IETF-specified protocol or specific to an application transported over an IETF-specified protocol. NEW: Performance Metric: A Performance Metric is a quantitative measure of performance, targeted to an IETF-specified protocol or targeted to an application transported over an IETF-specified protocol. Proposal: The reference needs to be an immutable document, such as an RFC; in cases where other standards bodies would benefit from the Performance Metric Registry, it is necessary to reference a specific, dated version of a specification. > > 7.2.2. Fixed Parameters > > Fixed Parameters are input factors whose value must be specified in > the Registry. The measurement system uses these values. > > Where referenced metrics supply a list of Parameters as part of their > descriptive template, a sub-set of the Parameters will be designated > as Fixed Parameters. Not a def., so lower case. > For example, for active metrics, Fixed idem. Maybe more occurrences. Please check through the draft. > Parameters determine most or all of the IPPM Framework convention > "packets of Type-P" as described in [RFC2330], such as transport > protocol, payload length, TTL, etc. An example for passive metrics > is for RTP packet loss calculation that relies on the validation of a > packet as RTP which is a multi-packet validation controlled by > MIN_SEQUENTIAL as defined by [RFC3550]. Varying MIN_SEQUENTIAL > values can alter the loss report and this value could be set as a > fixed parameter > > A Parameter which is Fixed for one Registry entry may be designated > as a Run-time Parameter for another Registry entry. > > > > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 14] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 7.3. Method of Measurement Category > > This category includes columns for references to relevant sections of > the RFC(s) and any supplemental information needed to ensure an > unambiguous method for implementations. > > 7.3.1. Reference Method Slightly confused with the difference with 7.2.1 > > This entry provides references to relevant sections of the RFC(s) > describing the method of measurement, as well as any supplemental > information needed to ensure unambiguous interpretation for > implementations referring to the RFC text. > > Specifically, this section should include pointers to pseudocode or > actual code that could be used for an unambigious implementation. > > 7.3.2. Packet Generation Stream > > This column applies to metrics that generate traffic for measurement > purposes including but not necessarily limited to Active metrics. > The generated traffic is referred as stream and this columns describe > its characteristics. Principally, two different streams are used in > IPPM metrics, Poisson distributed as described in [RFC2330] and > Periodic as described in [RFC3432]. Both Poisson and Periodic have > their own unique parameters, and the relevant set of values is > specified in this column. > > Each entry for this column contains the following information: > > o Value: The name of the packet stream scheduling discipline > > o Stream Parameters: The values and formats of input factors for > each type of stream. For example, the average packet rate and > distribution truncation value for streams with Poisson-distributed > inter-packet sending times. > > o Reference: the specification where the stream is defined > > The simplest example of stream specification is Singleton scheduling, singleton > where a single atomic measurement is conducted. Each atomic > measurement could consist of sending a single packet (such as a DNS > request) or sending several packets (for example, to request a > webpage). Other streams support a series of atomic measurements in a > "sample", with a schedule defining the timing between each > transmitted packet and subsequent measurement. > > > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 15] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 7.3.3. Traffic Filter > > This column applies to metrics that observe packets flowing in the > wire i.e. that is not specifically addressed to the measurement > agent. This includes but is not limited to Passive Metrics. The > filter specifies the traffic constraints that the passive measurement > method used is valid (or invalid) for. This includes valid packet > sampling ranges, width of valid traffic matches (eg. all traffic on > interface, UDP packets packets in a flow (eg. same RTP session). > > It is possible that the measurement method may not have a specific > limitation. However, this specific registry entry with it's > combination of fixed parameters implies restrictions. These > restrictions would be listed in this field. I don't understand the above paragraph. Do you want to say that this is applicable to all traffic, that there are no traffic filter. If yes, how do note that. The next section contains "all" if no sampling. Do we want "none" if not traffic filter? Or maybe "N.A." in each cases, to be consistent? > > 7.3.4. Sampling distribution > > The sampling distribution defines out of all the packets that match > the traffic filter, which one of those are actually used for the > measurement. One possibility is "all" which implies that all packets > matching the Traffic filter are considered, but there may be other > sampling strategies. It includes the following information: > > Value: the name of the sampling distribution > > Parameters: if any. > > Reference definition: pointer to the specification where the > sampling distribution is properly defined. > > 7.3.5. Run-time Parameters > > Run-Time Parameters are input factors that must be determined, > configured into the measurement system, and reported with the results > for the context to be complete. However, the values of these > parameters is not specified in the Registry, rather these parameters > are listed as an aid to the measurement system implementor or user > (they must be left as variables, and supplied on execution). > > Where metrics supply a list of Parameters as part of their > descriptive template, a sub-set of the Parameters will be designated > as Run-Time Parameters. > > A Data Format of each Run-time Parameter SHALL be specified in this > column, to simplify the control and implementation of measurement > devices. Don't think it's appropriate to specify a data format in the registry. I could use different encoding such as IPFIX, TWAMP, NETCONF, JSON, ... and still use this registry. > > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 16] > > Internet-Draft Registry for Performance Metrics September 2014 > > > Examples of Run-time Parameters include IP addresses, measurement > point designations, start times and end times for measurement, and > other information essential to the method of measurement. > > 7.3.6. Role > > In some method of measurements, there may be several roles defined > e.g. on a one-way packet delay active measurement, there is one > measurement agent that generates the packets and the other one that > receives the packets. This column contains the name of the role for > this particular entry. In the previous example, there should be two > entries int he registry, one for each role, so that when a > measurement agent is instructed to perform the one way delay source > metric know that it is supposed to generate packets. The values for > this field are defined in the reference method of measurement. I'm missing this "role" goal. Different roles imply different performance metrics, no? > > 7.4. Output Category > > For entries which involve a stream and many singleton measurements, a > statistic may be specified in this column to summarize the results to > a single value. If the complete set of measured singletons is > output, this will be specified here. > > Some metrics embed one specific statistic in the reference metric > definition, while others allow several output types or statistics. > > 7.4.1. Value > > This column contain the name of the output type. The output type > defines the type of result that the metric produces. It can be the > raw results or it can be some form of statistic. The specification > of the output type must define the format of the output. In some > systems, format specifications will simplify both measurement > implementation and collection/storage tasks. Note that if two > different statistics are required from a single measurement (for > example, both "Xth percentile mean" and "Raw"), then a new output > type must be defined ("Xth percentile mean AND Raw"). > > 7.4.2. Data Format Same point as before on the data format. > > This column provides the data format for the output. It is provided > to simplify the communication with collection systems and > implementation of measurement devices. > > > > > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 17] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 7.4.3. Reference > > This column contains a pointer to the specification where the output > type is defined > > 7.4.4. Metric Units > > The measured results must be expressed using some standard dimension > or units of measure. This column provides the units. > > When a sample of singletons (see [RFC2330] for definitions of these > terms) is collected, this entry will specify the units for each > measured value. I guess the above is an example. > > 7.5. Admisnitratvie information > > 7.5.1. Status > > The status of the specification of this Registered Performance > Metric. Allowed values are 'current' and 'deprecated'. All newly > defined Information Elements have 'current' status. > > 7.5.2. Requester > > The requester for the Registered Performance Metric. The requester > MAY be a document, such as RFC, or person. > > 7.5.3. Revision > > The revision number of a Registered Performance Metric, starting at 0 > for Registered Performance Metrics at time of definition and > incremented by one for each revision. > > 7.5.4. Revision Date > > The date of acceptance or the most recent revision for the Registered > Performance Metric. > > 7.6. Comments and Remarks > > Besides providing additional details which do not appear in other > categories, this open Category (single column) allows for unforeseen > issues to be addressed by simply updating this Informational entry. informational > > > > > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 18] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 8. The Life-Cycle of Registered Metrics > > Once a Performance Metric or set of Performance Metrics has been > identified for a given application, candidate Registry entry > specifications in accordance with Section 7 are submitted to IANA to > follow the process for review by the Performance Metric Experts, as > defined below. This process is also used for other changes to the > Performance Metric Registry, such as deprecation or revision, as > described later in this section. > > It is also desirable that the author(s) of a candidate Registry entry > seek review in the relevant IETF working group, or offer the > opportunity for review on the WG mailing list. If we keep the performance metrics directorate notion, then we must have a new paragraph here. > > 8.1. Adding new Performance Metrics to the Registry > > Requests to change Registered Metrics in the Performance Metric > Registry are submitted to IANA, which forwards the request to a > designated group of experts (Performance Metric Experts) appointed by > the IESG; these are the reviewers called for by the Expert Review > RFC5226 policy defined for the Performance Metric Registry. The > Performance Metric Experts review the request for such things as > compliance with this document, compliance with other applicable > Performance Metric-related RFCs, and consistency with the currently > defined set of Registered Performance Metrics. > > Authors are expected to review compliance with the specifications in > this document to check their submissions before sending them to IANA. > > The Performance Metric Experts should endeavor to complete referred > reviews in a timely manner. If the request is acceptable, the > Performance Metric Experts signify their approval to IANA, which > changes changes -> updates > the Performance Metric Registry. If the request is not > acceptable, the Performance Metric Experts can coordinate with the > requester to change the request to be compliant. The Performance > Metric Experts may also choose in exceptional circumstances to reject > clearly frivolous or inappropriate change requests outright. > > This process should not in any way be construed as allowing the > Performance Metric Experts to overrule IETF consensus. Specifically, > any Registered Metrics that were added with IETF consensus require > IETF consensus for revision or deprecation. > > Decisions by the Performance Metric Experts may be appealed as in > Section 7 of RFC5226. > > > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 19] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 8.2. Revising Registered Performance Metrics > > A request for Revision is ONLY permissible when the changes maintain ONLY -> only > backward-compatibility with implementations of the prior Registry > entry describing a Registered Metric (entries with lower revision > numbers, but the same Identifier and Name). > > The purpose of the Status field in the Performance Metric Registry is > to indicate whether the entry for a Registered Metric is 'current' or > 'deprecated'. > > In addition, no policy is defined for revising IANA Performance > Metric entries or addressing errors therein. To be certain, changes > and deprecations within the Performance Metric Registry are not > encouraged, and should be avoided to the extent possible. However, > in recognition that change is inevitable, the provisions of this > section address the need for revisions. > > Revisions are initiated by sending a candidate Registered Performance > Metric definition to IANA, as in Section X, identifying the existing > Registry entry. > > The primary requirement in the definition of a policy for managing > changes to existing Registered Performance Metrics is avoidance of > interoperability problems; Performance Metric Experts must work to > maintain interoperability above all else. Changes to Registered > Performance Metrics may only be done in an inter-operable way; > necessary changes that cannot be done in a way to allow > interoperability with unchanged implementations must result in the > creation of a new Registered Metric and possibly the deprecation of > the earlier metric. > > A change to a Registered Performance Metric is held to be backward- > compatible only when: > > 1. "it involves the correction of an error that is obviously only > editorial; or" > > 2. "it corrects an ambiguity in the Registered Performance Metric's > definition, which itself leads to issues severe enough to prevent > the Registered Performance Metric's usage as originally defined; > or" > > 3. "it corrects missing information in the metric definition without > changing its meaning (e.g., the explicit definition of 'quantity' > semantics for numeric fields without a Data Type Semantics > value); or" > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 20] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 4. "it harmonizes with an external reference that was itself > corrected." > > 5. "BENOIT: NOTE THAT THERE ARE MORE RULES IN RFC 7013 SECTION 5 BUT > THEY WOULD ONLY APPLY TO THE ACTIVE/PASSIVE DRAFTS. TO BE > DISCUSSED." BENOIT should really focus on this :-) > > If a change is deemed permissible by the Performance Metric Experts, NEW: If an Performance Metric revision is deemed permissible by the Performance Metric Experts, according to the rules in this document, > IANA makes the change in the Performance Metric Registry. The > requester of the change is appended to the requester in the Registry. > > Each Registered Performance Metric in the Registry has a revision > number, starting at zero. Each change to a Registered Performance > Metric following this process increments the revision number by one. > > COMMENT: Al (and Phil) think we should keep old/revised entries as- > is, marked as deprecated >>>> Since any revision must be inter- > operable according to the criteria above, there is no need for the > Performance Metric Registry to store information about old revisions. Agreed. > > When a revised Registered Performance Metric is accepted into the > Performance Metric Registry, the date of acceptance of the most > recent revision is placed into the revision Date column of the > Registry for that Registered Performance Metric. > > Where applicable, additions to Registry entries in the form of text > Comments or Remarks should include the date, but such additions may > not constitute a revision according to this process. > > 8.3. Deprecating Registered Performance Metrics > > Changes that are not permissible by the above criteria for Registered > Metric's revision may only be handled by deprecation. A Registered > Performance Metric MAY be deprecated and replaced when: > > 1. "the Registered Performance Metric definition has an error or > shortcoming that cannot be permissibly changed as in > Section Revising Registered Performance Metrics; or" > > 2. "the deprecation harmonizes with an external reference that was > itself deprecated through that reference's accepted deprecation > method; or" > > A request for deprecation is sent to IANA, which passes it to the > Performance Metric Expert for review, as in Section 'The Process for > Review by the Performance Metric Experts'. When deprecating an > Performance Metric, the Performance Metric description in the > Performance Metric Registry must be updated to explain the > > > > Bagnulo, et al. Expires March 14, 2015 [Page 21] > > Internet-Draft Registry for Performance Metrics September 2014 > > > deprecation, as well as to refer to any new Performance Metrics > created to replace the deprecated Performance Metric. > > The revision number of a Registered Performance Metric is incremented > upon deprecation, and the revision Date updated, as with any > revision. > > The use of deprecated Registered Metrics should result in a log entry > or human-readable warning by the respective application. > > Names and Metric ID of deprecated Registered Metrics must not be > reused. > > 9. Performance Metric Registry and other Registries > > BENOIT: TBD. > > THE BASIC IDEA IS THAT PEOPLE COULD DIRECTLY DEFINE PERF. METRICS IN > OTHER EXISTING REGISTRIES, FOR SPECIFIC PROTOCOL/ENCODING. EXAMPLE: > IPFIX. IDEALLY, ALL PERF. METRICS SHOULD BE DEFINED IN THIS > REGISTRY AND REFERS TO FROM OTHER REGISTRIES. > > 10. Security considerations > > This draft doesn't introduce any new security considerations for the > Internet. However, the definition of Performance Metrics may > introduce some security concerns, and should be reviewed with > security in mind. > > 11. IANA Considerations > > This document specifies the procedure for Performance Metrics > Registry setup. IANA is requested to create a new Registry for > Performance Metrics called "Registered Performance Metrics" with the > columns defined in Section 7. > > New assignments for Performance Metric Registry will be administered > by IANA through Expert Review [RFC5226], i.e., review by one of a > group of experts, the Performance Metric Experts, appointed by the > IESG upon recommendation of the Transport Area Directors. The > experts will initially be drawn from the Working Group Chairs and > document editors of the Performance Metrics Directorate [performance- > metrics-directorate]. > > This document requests the allocation of the URI prefix > urn:ietf:params:ippm:metric for the purpose of generating URIs for > registered metrics. > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 22] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 12. Acknowledgments > > Thanks to Brian Trammell and Bill Cerveny, IPPM chairs, for leading > some brainstorming sessions on this topic. > > 13. References > > 13.1. Normative References Please order the RFC numbers. Regards, Benoit > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC2026] Bradner, S., "The Internet Standards Process -- Revision > 3", BCP 9, RFC 2026, October 1996. > > [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, > "Framework for IP Performance Metrics", RFC 2330, May > 1998. > > [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics > Registry", BCP 108, RFC 4148, August 2005. > > [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 5226, > May 2008. > > [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics > (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April > 2011. > > [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New > Performance Metric Development", BCP 170, RFC 6390, > October 2011. > > [RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP > Performance Metrics (IPPM) Standard Advancement Testing", > BCP 176, RFC 6576, March 2012. > > [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform > Resource Identifier (URI): Generic Syntax", STD 66, RFC > 3986, January 2005. > > [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. > > > > > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 23] > > Internet-Draft Registry for Performance Metrics September 2014 > > > 13.2. Informative References > > [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control > Protocol Extended Reports (RTCP XR)", RFC 3611, November > 2003. > > [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. > Jacobson, "RTP: A Transport Protocol for Real-Time > Applications", STD 64, RFC 3550, July 2003. > > [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, > "Session Initiation Protocol Event Package for Voice > Quality Reporting", RFC 6035, November 2010. > > [I-D.ietf-lmap-framework] > Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., > Aitken, P., and A. Akhter, "A framework for large-scale > measurement platforms (LMAP)", draft-ietf-lmap- > framework-08 (work in progress), August 2014. > > [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > Carle, "Information Model for Packet Sampling Exports", > RFC 5477, March 2009. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > RFC 5102, January 2008. > > [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the > RTP Monitoring Framework", RFC 6792, November 2012. > > [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network > Time Protocol Version 4: Protocol and Algorithms > Specification", RFC 5905, June 2010. > > [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation > Metric for IP Performance Metrics (IPPM)", RFC 3393, > November 2002. > > [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information > Reporting Using a Source Description (SDES) Item and an > RTCP Extended Report (XR) Block", RFC 6776, October 2012. > > [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol > (RTCP) Extended Report (XR) Block for Burst/Gap Discard > Metric Reporting", RFC 7003, September 2013. > > > > > > Bagnulo, et al. Expires March 14, 2015 [Page 24] > > Internet-Draft Registry for Performance Metrics September 2014 > > > [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network > performance measurement with periodic streams", RFC 3432, > November 2002. > > [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session > Description Protocol", RFC 4566, July 2006. > > [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation > Applicability Statement", RFC 5481, March 2009. > > Authors' Addresses > > Marcelo Bagnulo > Universidad Carlos III de Madrid > Av. Universidad 30 > Leganes, Madrid 28911 > SPAIN > > Phone: 34 91 6249500 > Email: marcelo@it.uc3m.es > URI: http://www.it.uc3m.es > > > Benoit Claise > Cisco Systems, Inc. > De Kleetlaan 6a b1 > 1831 Diegem > Belgium > > Email: bclaise@cisco.com > > > Philip Eardley > BT > Adastral Park, Martlesham Heath > Ipswich > ENGLAND > > Email: philip.eardley@bt.com > > > Al Morton > AT&T Labs > 200 Laurel Avenue South > Middletown, NJ > USA > > Email: acmorton@att.com > > > > Bagnulo, et al. Expires March 14, 2015 [Page 25] > > Internet-Draft Registry for Performance Metrics September 2014 > > > Aamer Akhter > Cisco Systems, Inc. > 7025 Kit Creek Road > RTP, NC 27709 > USA > > Email: aakhter@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > . > --------------010201070901000701030307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Here is my review of draft-ietf-ippm-metric-registry-01.
Sent to IPPM to generate some discussions.
Network Working Group                                         M. Bagnulo
Internet-Draft                                                      UC3M
Intended status: Best Current Practice                         B. Claise
Expires: March 14, 2015                              Cisco Systems, Inc.
                                                              P. Eardley
                                                                      BT
                                                               A. Morton
                                                               AT&T Labs
                                                               A. Akhter
                                                     Cisco Systems, Inc.
                                                      September 10, 2014


                    Registry for Performance Metrics
                   draft-ietf-ippm-metric-registry-01

Abstract

   This document defines the IANA Registry for Performance Metrics.
   This document also gives a set of guidelines for Registered
   Performance Metric requesters and reviewers.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 14, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Bagnulo, et al.          Expires March 14, 2015                 [Page 1]

Internet-Draft      Registry for Performance Metrics      September 2014


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Open Issues . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Design Considerations for the Registry and Registered Metrics   7
     5.1.  Interoperability  . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Criteria for Registered Performance Metrics . . . . . . .   8
     5.3.  Single point of reference for Performance metrics . . . .   8
     5.4.  Side benefits . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Performance Metric Registry: Prior attempt  . . . . . . . . .   9
     6.1.  Why this Attempt Will Succeed?  . . . . . . . . . . . . .  10
   7.  Defintion of the Performance Metric Registry  . . . . . . . .  10
     7.1.  Summary Category  . . . . . . . . . . . . . . . . . . . .  12
       7.1.1.  Identifier  . . . . . . . . . . . . . . . . . . . . .  12
       7.1.2.  Name  . . . . . . . . . . . . . . . . . . . . . . . .  13
       7.1.3.  URI . . . . . . . . . . . . . . . . . . . . . . . . .  13
       7.1.4.  Description . . . . . . . . . . . . . . . . . . . . .  14
     7.2.  Metric Definition Category  . . . . . . . . . . . . . . .  14
       7.2.1.  Reference Definition  . . . . . . . . . . . . . . . .  14
       7.2.2.  Fixed Parameters  . . . . . . . . . . . . . . . . . .  14
     7.3.  Method of Measurement Category  . . . . . . . . . . . . .  15
       7.3.1.  Reference Method  . . . . . . . . . . . . . . . . . .  15
       7.3.2.  Packet Generation Stream  . . . . . . . . . . . . . .  15
       7.3.3.  Traffic Filter  . . . . . . . . . . . . . . . . . . .  16
       7.3.4.  Sampling distribution . . . . . . . . . . . . . . . .  16
       7.3.5.  Run-time Parameters . . . . . . . . . . . . . . . . .  16
       7.3.6.  Role  . . . . . . . . . . . . . . . . . . . . . . . .  17
     7.4.  Output Category . . . . . . . . . . . . . . . . . . . . .  17
       7.4.1.  Value . . . . . . . . . . . . . . . . . . . . . . . .  17
       7.4.2.  Data Format . . . . . . . . . . . . . . . . . . . . .  17
       7.4.3.  Reference . . . . . . . . . . . . . . . . . . . . . .  18
       7.4.4.  Metric Units  . . . . . . . . . . . . . . . . . . . .  18
     7.5.  Admisnitratvie information  . . . . . . . . . . . . . . .  18
       7.5.1.  Status  . . . . . . . . . . . . . . . . . . . . . . .  18
       7.5.2.  Requester . . . . . . . . . . . . . . . . . . . . . .  18
       7.5.3.  Revision  . . . . . . . . . . . . . . . . . . . . . .  18
       7.5.4.  Revision Date . . . . . . . . . . . . . . . . . . . .  18
     7.6.  Comments and Remarks  . . . . . . . . . . . . . . . . . .  18
   8.  The Life-Cycle of Registered Metrics  . . . . . . . . . . . .  19
     8.1.  Adding new Performance Metrics to the Registry  . . . . .  19



Bagnulo, et al.          Expires March 14, 2015                 [Page 2]

Internet-Draft      Registry for Performance Metrics      September 2014


     8.2.  Revising Registered Performance Metrics . . . . . . . . .  20
     8.3.  Deprecating Registered Performance Metrics  . . . . . . .  21
   9.  Performance Metric Registry and other Registries  . . . . . .  22
   10. Security considerations . . . . . . . . . . . . . . . . . . .  22
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     13.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Open Issues

   1.  Many aspects of the Naming convention are TBD, and need
       discussion.  For example, we have distinguished RTCP-XR metrics
       as End-Point (neither active nor passive in the traditional
       sense, so not Act_ or Pas_).  Even though we may not cast all
       naming conventions in stone at the start, it will be helpful to
       look at several examples of passive metric names now.

   2.  We should expand on the different roles and responsibilities of
       the Performance Metrics Experts versus the Performance Metric
       Directorate.  At least, the Performance Metric Directorate one
       should be expanded. --- (v7) If these are different entities, our
       only concern is the role of the "PM Experts".
I would in favor or removing the Performance Metric Directorate.
The directorates are for the benefit of the AD.
From RFC 2418 and http://www.ietf.org/iesg/directorate.html
   A request for Revision is ONLY permissible when the changes maintain
   backward-compatibility with implementations of the prior Registry
   entry describing a Registered Metric (entries with lower revision
   numbers, but the same Identifier and Name).
Also, the directorate live and goal might change along the time. So specify the directorate goal is in stone in a RFC is not appropriate.
However, a sentence such as: at the time of writing this line, a performance metric directorate exists, which can help ....


   3.  Revised Registry Entries: Keep for history (deprecated) or
       Delete?
We should delete.
See in line

   4.  Need to include an example for a name for a passive metric

   5.  Definition of Parameter needs more work?

   6.  Whether the name of the metric should contain the version of the
       metric
No. Because we have a new performance metric revision, and it must be interoperable.



   7.  reserve some values for examples and private use?

   8.  should we define a "type" column with the possible values
       "active" "passive" "hybrid" "endpoint"? if we go for all 4 of
       them, we should define the corresponding prefixes for the metric
       name (at this point only the pas and act are defined)

   9.  URL: should we include a URL link in each registry entry with a
       URL specific to the entry that links to a different text page
       that contains all the details of the registry entry as in
       http://www.iana.org/assignments/xml-registry/xml-
       registry.xhtml#ns


I don't understand which advantages this adds.
If I compare with IPFIX, which has got a similar mechanism, it's easier for a collector to download a single file.

Bagnulo, et al.          Expires March 14, 2015                 [Page 3]

Internet-Draft      Registry for Performance Metrics      September 2014


2.  Introduction

   The IETF specifies and uses Performance Metrics of protocols and
   applications transported over its protocols.  Performance metrics are
   such an important part of the operations of IETF protocols that
   [RFC6390] specifies guidelines for their development.

   The definition and use of Performance Metrics in the IETF happens in
   various working groups (WG), most notably:

      The "IP Performance Metrics" (IPPM) WG is the WG primarily
      focusing on Performance Metrics definition at the IETF.

      The "Metric Blocks for use with RTCP's Extended Report Framework"
      (XRBLOCK) WG recently specified many Performance Metrics related
      to "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611],
      which establishes a framework to allow new information to be
      conveyed in RTCP, supplementing the original report blocks defined
      in "RTP: A Transport Protocol for Real-Time Applications",
      [RFC3550].

      The "Benchmarking Methodology" WG (BMWG) defined many Performance
      Metrics for use in laboratory benchmarking of inter-networking
      technologies.

      The "IP Flow Information eXport" (IPFIX) WG Information elements
      related to Performance Metrics are currently proposed.

      The "Performance Metrics for Other Layers" (PMOL) concluded WG,
      defined some Performance Metrics related to Session Initiation
      Protocol (SIP) voice quality [RFC6035].

   It is expected that more Performance Metrics will be defined in the
   future, not only IP-based metrics, but also metrics which are
   protocol-specific and application-specific.

   However, despite the importance of Performance Metrics, there are two
   related problems for the industry.  First, how to ensure that when
   one party requests another party to measure (or report or in some way
   act on) a particular Performance Metric, then both parties have
   exactly the same understanding of what Performance Metric is being
   referred to.  Second, how to discover which Performance Metrics have
   been specified, so as to avoid developing new Performance Metric that
   is very similar.  The problems can be addressed by creating a
   registry of performance metrics.  The usual way in which IETF
   organizes namespaces is with Internet Assigned Numbers Authority
   (IANA) registries, and there is currently no Performance Metrics
   Registry maintained by the IANA.



Bagnulo, et al.          Expires March 14, 2015                 [Page 4]

Internet-Draft      Registry for Performance Metrics      September 2014


   This document therefore creates a Performance Metrics Registry.  It
   also provides best practices on how to define new or updated entries
   in the Performance Metrics Registry.
NEW:
   This document therefore creates a Performance Metrics Registry.  It
   also provides best practices on how to specify new entries or update ones
   in the Performance Metrics Registry.

3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   The terms Performance Metric and Performance Metrics Directorate are
   defined in [RFC6390], and copied over in this document for the
   readers convenience.

   Performance Metric:  A Performance Metric is a quantitative measure
      of performance, specific to an IETF-specified protocol or specific
      to an application transported over an IETF-specified protocol.
      Examples of Performance Metrics are the FTP response time for a
      complete file download, the DNS response time to resolve the IP
      address, a database logging time, etc.

   Registered Performance Metric:  A Registered Performance Metric (or
      Registered Metric) is a Performance Metric expressed as an entry
      in the Performance Metric Registry, and comprised of a
      specifically named metric which has met all the registry review
      criteria, is under the curation of IETF Performance Metrics
      Experts, and whose changes are controlled by IANA.
I don't understand why"and comprised of a specifically named metric which has met all the registry review criteria," is needed. Candidate to remove
"and whose changes are controlled by IANA". It seems to imply that Registered Performance Metric change is normal. Not really.
"is under the curation of IETF Performance Metrics Experts". The Performance Metrics Experts are the experts IANA calls for entry validation.

NEW:
  Registered Performance Metric:  A Registered Performance Metric (or
      Registered Metric) is a Performance Metric expressed as an entry
      in the Performance Metric Registry, administered by IANA.



   Performance Metrics Registry:  The IANA registry containing
      Registered Performance Metrics.  In this document, it is also
      called simply "Registry".

   Proprietary Registry:  A set of metrics that are registered in a
      proprietary registry, as opposed to Performance Metrics Registry.

   Performance Metrics Experts:  The Performance Metrics Experts is a
      group of experts selected by the IESG to validate the Performance
      Metrics before updating the Performance Metrics Registry.  The
      Performance Metrics Experts work closely with IANA.

   Performance Metrics Directorate:  The Performance Metrics Directorate
      is a directorate that provides guidance for Performance Metrics
      development in the IETF.  The Performance Metrics Directorate
      should be composed of experts in the performance community,
      potentially selected from the IP Performance Metrics (IPPM),
      Benchmarking Methodology (BMWG), and Performance Metrics for Other
      Layers (PMOL) WGs.
PMOL doesn't exist any longer. So the last sentence is difficult to fulfill.
At some point in time, the other WGs will not exist any longer.

NEW:
      Performance Metrics Directorate:  The Performance Metrics Directorate
      is a directorate that provides guidance for Performance Metrics
      development in the IETF. 

The following sentence (NEW) should not be part of the definition, but be part of a subsequent performance metrics directorate paragraph (note: if we keep it in the draft)
      The Performance Metrics Directorate
      should be composed of experts in the performance community,
      potentially selected from the IP Performance Metrics (IPPM),
      Benchmarking Methodology (BMWG), and the closed Performance Metrics for Other
      Layers (PMOL) WGs, or any future performance-related WGs.




Bagnulo, et al.          Expires March 14, 2015                 [Page 5]

Internet-Draft      Registry for Performance Metrics      September 2014


   Parameter:  An input factor defined as a variable in the definition
      of a metric.  A numerical or other specified factor forming one of
      a set that defines a metric or sets the conditions of its
      operation.  All Input Parameters must be known to measure using a
      metric and interpret the results.  Although Input Parameters do
      not change the fundamental nature of the metric's definition, some
      have substantial influence on the network property being assessed
      and interpretation of the results.

         Consider the case of packet loss in the following two cases.
NEW:
         Consider the case of packet loss in the following two Active Measurement Method cases.
         The first case is packet loss as background loss where the
         parameter set includes a very sparse Poisson stream, and only
         characterizes the times when packets were lost.  Actual user
         streams likely see much higher loss at these times, due to tail
         drop or radio errors.  The second case is packet loss as
         inverse of Throughput where the parameter set includes a very
throughput
         dense, bursty stream, and characterizes the loss experienced by
         a stream that approximates a user stream.  These are both "loss
         metrics", but the difference in interpretation of the results
         is highly dependent on the Parameters (at least), to the
         extreme where we are actually using loss to infer its
         compliment: delivered throughput.

   Active Measurement Method:  Methods of Measurement conducted on
      traffic which serves only the purpose of measurement and is
      generated for that reason alone, and whose traffic characteristics
      are known a priori.  An Internet user's host can generate active
      measurement traffic (virtually all typical user-generated traffic
      is not dedicated to active measurement, but it can produce such
      traffic with the necessary application operating).
Not sure what the previous sentence adds to the definition.
I would add some examples. OWAMP, TWAMP, IP SLA

   Passive Measurement Method:  Methods of Measurement conducted on
      network traffic, generated either from the end users or from
      network elements. 
"generated" in the previous sentence is wrong
Maybe
Passive Measurement Method:  Methods of Measurement conducted on
      network traffic, issue either by the end users or by
      network elements, as opposed to active traffic (see Active Measurement method)
One characteristic of Passive Measurement
      Methods is that sensitive information may be observed, and as a
      consequence, stored in the measurement system.
I would add some examples. IPFIX, PSAMP. [RFC 5470], [RFC 5476]

   Hybrid Measurement Method:  Methods of Measurement which use a
      combination of Active Measurement and Passive Measurement methods.

4.  Scope

   The intended audience of this document includes those who prepare and
   submit a request for a Registered Performance Metric, and for the
   Performance Metric Experts who review a request.
The above should be improved.
A good example is http://tools.ietf.org/html/rfc7013#section-1.1.

   This document specifies a Performance Metrics Registry in IANA.  This
   Performance Metric Registry is applicable to Performance Metrics



Bagnulo, et al.          Expires March 14, 2015                 [Page 6]

Internet-Draft      Registry for Performance Metrics      September 2014


   issued from Active Measurement, Passive Measurement, from end-point
   calculation or any other form of Performance Metric.  This registry
   is designed to encompass Performance Metrics developed throughout the
   IETF and especially for the following existing working groups: IPPM,
   XRBLOCK, IPFIX, and BMWG.  This document analyzes an prior attempt to
   set up a Performance Metric Registry, and the reasons why this design
   was inadequate [RFC6248].  Finally, this document gives a set of
   guidelines for requesters and expert reviewers of candidate
   Registered Performance Metrics.

   This document makes no attempt to populate the Registry with initial
   entries.  It does provides a few examples that are merely
   illustrations and should not be included in the registry at this
   point in time.

   Based on [RFC5226] Section 4.3, this document is processed as Best
   Current Practice (BCP) [RFC2026].

5.  Design Considerations for the Registry and Registered Metrics
The title is confusing: it seems that you treat both the Registry and the Registered Metrics in the section.
Let me propose
    5.  Motivation for a Performance Metrics Registry
        5.1 Interoperability
        5.2 Single point of reference for performance metrics
                note: this is the actual content of 5.3
        5.3 Side Benefits
                note: this is the actual content of 5.4
    6. Criteria for Performance Metrics Registration
                note: this is the actual content of 5.2
                note2: the title has been slightly changed compared to 5.2


I believe it's close to the content.

   In this section, we detail several design considerations that are
   relevant for understanding the motivations and expected use of the
   Performance Metric Registry.

5.1.  Interoperability

   As any IETF registry, the primary use for a registry is to manage a
   namespace for its use within one or more protocols.  In this
   particular case of the Performance Metric Registry, there are two
   types of protocols that will use the values defined in the Registry
   for their operation:
NEW:
   As any IETF registry, the primary use for a registry is to manage a
   namespace for its use within one or more protocols.  In this
   particular case of the Performance Metric Registry, there are two
   types of protocols that will use the Performance Metrics defined in the Registry
   for their operation:

   o  Control protocol: this type of protocols is used to allow one
      entity to request another entity to perform a measurement using a
      specific metric defined by the Registry.  One particular example
      is the LMAP framework [I-D.ietf-lmap-framework].  Using the LMAP
      terminology, the Registry is used in the LMAP Control protocol to
      allow a Controller to request a measurement task to one or more
      Measurement Agents.  In order to enable this use case, the entries
      of the Performance Metric Registry must be well enough defined to
      allow a Measurement Agent implementation to trigger a specific
      measurement task upon the reception of a control protocol message.
      This requirements heavily constrains the type of entries that are
      acceptable for the Performance Metric Registry.

   o  Report protocol: This type of protocols is used to allow an entity
      to report measurement results to another entity.  By referencing
      to a specific Performance Metric Registry, it is possible to



Bagnulo, et al.          Expires March 14, 2015                 [Page 7]

Internet-Draft      Registry for Performance Metrics      September 2014


      properly characterize the measurement result data being
      transferred.  Using the LMAP terminology, the Registry is used in
      the Report protocol to allow a Measurement Agent to report
      measurement results to a Collector.

5.2.  Criteria for Registered Performance Metrics
NEW: 5.2.  Criteria for Performance Metrics Registration

   It is neither possible nor desirable to populate the Registry with
   all combinations of input parameters of all Performance Metrics.  The
   Registered Performance Metrics should be:

   1.  interpretable by the user.

   2.  implementable by the software designer,

   3.  deployable by network operators, without major impact on the
       networks,

   4.  accurate, for interoperability and deployment across vendors,

   5.  Operational useful, so that it has significant industry interest
       and/or has seen deployment,

   6.  Sufficiently tightly defined, so that changing Parameters does
       not change the fundamental nature of the measurement, nor change
       the practicality of its implementation.

   In essence, there needs to be evidence that a candidate Registry
   entry has significant industry interest, or has seen deployment, and
   there is agreement that the candidate Registered Metric serves its
   intended purpose.

5.3.  Single point of reference for Performance metrics
metrics -> Metrics

   A Registry for Performance metrics serves as a single point of
metrics -> Metrics
Maybe more instance. Please check throughout the draft

   reference for Performance Metrics defined in different working groups
   in the IETF.  As we mentioned earlier, there are several WGs that
   define Performance Metrics in the IETF and it is hard to keep track
   of all them.  This results in multiple definitions of similar metrics
   that attempt to measure the same phenomena but in slightly different
   (and incompatible) ways.  Having a Registry would allow both the IETF
   community and external people to have a single list of relevant
   Performance Metrics defined by the IETF (and others, where
   appropriate).  The single list is also an essential aspect of
   communication about metrics, where different entities that request
   measurements, execute measurements, and report the results can
   benefit from a common understanding of the referenced metric.




Bagnulo, et al.          Expires March 14, 2015                 [Page 8]

Internet-Draft      Registry for Performance Metrics      September 2014


5.4.  Side benefits

   There are a couple of side benefits of having such a Registry.
   First, the Registry could serve as an inventory of useful and used
   metrics, that are normally supported by different implementations of
   measurement agents.  Second, the results of the metrics would be
   comparable even if they are performed by different implementations
   and in different networks, as the metric is properly defined.  BCP
   176 [RFC6576] examines whether the results produced by independent
   implementations are equivalent in the context of evaluating the
   completeness and clarity of metric specifications.  This BCP defines
   the standards track advancement testing for (active) IPPM metrics,
   and the same process will likely suffice to determine whether
   Registry entries are sufficiently well specified to result in
   comparable (or equivalent) results.  Registry entries which have
   undergone such testing SHOULD be noted, with a reference to the test
   results.

6.  Performance Metric Registry: Prior attempt

   There was a previous attempt to define a metric registry RFC 4148
   [RFC4148].  However, it was obsoleted by RFC 6248 [RFC6248] because
   it was "found to be insufficiently detailed to uniquely identify IPPM
   metrics... [there was too much] variability possible when
   characterizing a metric exactly" which led to the RFC4148 registry
   having "very few users, if any".

   A couple of interesting additional quotes from RFC 6248 might help
   understand the issues related to that registry.

   1.  "It is not believed to be feasible or even useful to register
       every possible combination of Type P, metric parameters, and
       Stream parameters using the current structure of the IPPM Metrics
       Registry."

   2.  "The registry structure has been found to be insufficiently
       detailed to uniquely identify IPPM metrics."

   3.  "Despite apparent efforts to find current or even future users,
       no one responded to the call for interest in the RFC 4148
       registry during the second half of 2010."

   The current approach learns from this by tightly defining each entry
   in the registry with only a few variable Parameters to be specified
   by the measurement designer, if any.  The idea is that entries in the
   Registry represent different measurement methods which require input
represent -> stem from
   parameters to set factors like source and destination addresses
   (which do not change the fundamental nature of the measurement).  The



Bagnulo, et al.          Expires March 14, 2015                 [Page 9]

Internet-Draft      Registry for Performance Metrics      September 2014


   downside of this approach is that it could result in a large number
   of entries in the Registry.  We believe that less is more in this
   context - it is better to have a reduced set of useful metrics rather
   than a large set of metrics with questionable usefulness.  Therefore
   this document defines that the Registry only includes metrics that
   are well defined and that have proven to be operationally useful.  In
   order to guarantee these two characteristics we require that a set of
   experts review the allocation request to verify that the metric is
   well defined and it is operationally useful.

6.1.  Why this Attempt Will Succeed?

   The Registry defined in this document addresses the main issues
   identified in the previous attempt.  As we mention in the previous
   section, one of the main issues with the previous registry was that
   the metrics contained in the registry were too generic to be useful.
   In this Registry, the Registry requests are evaluated by an expert
   group, the Performance Metrics Experts, who will make sure that the
   metric is properly defined.  This document provides guidelines to
   assess if a metric is properly defined.

   Another key difference between this attempt and the previous one is
   that in this case there is at least one clear user for the Registry:
   the LMAP framework and protocol.  Because the LMAP protocol will use
   the Registry values in its operation, this actually helps to
   determine if a metric is properly defined.  In particular, since we
   expect that the LMAP control protocol will enable a controller to
   request a measurement agent to perform a measurement using a given
   metric by embedding the Performance Metric Registry value in the
   protocol, a metric is properly specified if it is defined well-enough
   so that it is possible (and practical) to implement the metric in the
   measurement agent.  This was clearly not the case for the previous
   attempt: defining a metric with an undefined P-Type makes its
   implementation unpractical.
P-Type is really IPPM specific, while the registry is not IPPM specific.
Either you should really explain this concept or remove.

7.  Defintion of the Performance Metric Registry

   In this section we define the columns of the Performance Metric
   Registry.  This registry will contain all Registered Performance
   Metrics including active, passive, hybrid, endpoint metrics and any
   other type of performance metric that can be envisioned.  Because of
   that, it may be the case that some of the columns defined are not
   applicable for a given type of metric.  If this is the case, the
   column(s) SHOULD be populated with the "NA" value (Non Applicable).
   However, the "NA" value MUST NOT be used any any metric in the
any any -> by any
   following columns: Identifier, Name, URI, Status, Requester,
   Revision, Revision Date, Description and Reference Specification.
   Moreover, In addition, it may be possible that in the future, a new



Bagnulo, et al.          Expires March 14, 2015                [Page 10]

Internet-Draft      Registry for Performance Metrics      September 2014


   type of metric requires additional columns.  Should that be the case,
   it is possible to add new columns to the registry.  The specification
   defining the new column(s) MUST define how to populate the new
   column(s) for existing entries.
MUST -> must

   The columns of the Performance Metric Registry are defined next.  The
   columns are grouped into "Categories" to facilitate the use of the
   registry.  Categories are described at the 3.x heading level, and
   columns are at the 3.x.y heading level.  The Figure below illustrates
   this organization.  An entry (row) therefore gives a complete
   description of a Registered Metric.
3.x and 3.x.y are wrong

   Each column serves as a check-list item and helps to avoid omissions
   during registration and expert review.  In some cases an entry (row)
   may have some columns without specific entries, marked Not Applicable
   (NA).



































Bagnulo, et al.          Expires March 14, 2015                [Page 11]

Internet-Draft      Registry for Performance Metrics      September 2014


 Registry Categories and Columns, shown as
                                                        Category
                                                        ------------------
                                                        Column |  Column |
Some formatting issues.

        Summary
        -------------------------------
        ID | Name | URI | Description |


        Metric Definition
        -----------------------------------------
        Reference Definition | Fixed Parameters |


        Method of Measurement
        ---------------------------------------------------------------------------------
        Reference Method | Packet Generation | Traffic | Sampling     | Run-time | Role |
                         | Stream            | Filter  | distribution | Param    |      |

        Output
        -----------------------------------------
        | Type | Reference  | Data   | Units |
        |      | Definition | Format |       |


        Administrative information
        ----------------------------------
        Status |Request | Rev | Rev.Date |


        Comments and Remarks
        --------------------



7.1.  Summary Category

7.1.1.  Identifier

   A numeric identifier for the Registered Performance Metric.  This
   identifier MUST be unique within the Performance Metric Registry.

   The Registered Performance Metric unique identifier is a 16-bit
   integer (range 0 to 65535).  When adding newly Registered Performance
   Metrics to the Performance Metric Registry, IANA SHOULD assign the
   lowest available identifier to the next Registered Performance
   Metric.
SHOULD -> should.



Bagnulo, et al.          Expires March 14, 2015                [Page 12]

Internet-Draft      Registry for Performance Metrics      September 2014


7.1.2.  Name

   As the name of a Registered Performance Metric is the first thing a
   potential implementor will use when determining whether it is
   suitable for a given application, it is important to be as precise
   and descriptive as possible. 
, while maintaining readability.
New names of Registered Performance
   Metrics:

   1.  "MUST be chosen carefully to describe the Registered Performance
       Metric and the context in which it will be used."

   2.  "MUST be unique within the Performance Metric Registry."

   3.  "MUST use capital letters for the first letter of each component
       . All other letters MUST be lowercase, even for acronyms.
       Exceptions are made for acronyms containing a mixture of
       lowercase and capital letters, such as 'IPv4' and 'IPv6'."

   4.  "MUST use '_' between each component composing the Registered
       Performance Metric name."

   5.  "MUST start with prefix Act_ for active measurement Registered
       Performance Metric."

   6.  "MUST start with prefix Pas_ for passive monitoring Registered
       Performance Metric."

   7.  Other types of metrics should define a proper prefix for
       identifying the type.

   8.  The remaining rules for naming are left to the Performance
       Experts to determine as they gather experience, so this is an
       area of planned update by a future RFC.
9. Should be in sync with the different values in the registry.
    example: must contain "Pas" if the value of Reference Method field is passive, right?
   An example is "Act_UDP_Latency_Poisson_99mean" for a active
   monitoring UDP latency metric using a Poisson stream of packets and
   producing the 99th percentile mean as output.

7.1.3.  URI

   The URI column MUST contain a URI [RFC 3986] that uniquely identified
   the metric.  The URI is a URN [RFC 2141].  The URI is automatically
   generated by prepending the prefix urn:ietf:params:ippm:metric: to
   the metric name.  The resulting URI is globally unique.
At this point, I see in the 7.X a mix of instruction for the Perf. Metric Experts and for IANA.
IANA: the sentence above or the last sentence in 7.1
Shouldn't we separate the instructions in IANA in the IANA considerations section?







Bagnulo, et al.          Expires March 14, 2015                [Page 13]

Internet-Draft      Registry for Performance Metrics      September 2014


7.1.4.  Description

   A Registered Performance Metric Description is a written
   representation of a particular Registry entry.  It supplements the
   metric name to help Registry users select relevant Registered
   Performance Metrics.

7.2.  Metric Definition Category

   This category includes columns to prompt all necessary details
   related to the metric definition, including the RFC reference and
   values of input factors, called fixed parameters, which are left open
   in the RFC but have a particular value defined by the performance
   metric.

7.2.1.  Reference Definition

   This entry provides a reference (or references) to the relevant
   section(s) of the document(s) that define the metric, as well as any
   supplemental information needed to ensure an unambiguous definition
   for implementations.  The reference needs to be an immutable
   document, such as an RFC; for other standards bodies, it is likely to
   be necessary to reference a specific, dated version of a
   specification.
you speak about other standard bodies here (which I agree with), but here is the definition
   Performance Metric:  A Performance Metric is a quantitative measure
      of performance, specific to an IETF-specified protocol or specific
      to an application transported over an IETF-specified protocol.
NEW:
   Performance Metric:  A Performance Metric is a quantitative measure
      of performance, targeted to an IETF-specified protocol or targeted
      to an application transported over an IETF-specified protocol.

Proposal:
   The reference needs to be an immutable
   document, such as an RFC; in cases where other standards bodies would benefit from the Performance Metric Registry, it is
   necessary to reference a specific, dated version of a specification.


7.2.2.  Fixed Parameters

   Fixed Parameters are input factors whose value must be specified in
   the Registry.  The measurement system uses these values.

   Where referenced metrics supply a list of Parameters as part of their
   descriptive template, a sub-set of the Parameters will be designated
   as Fixed Parameters. 
Not a def., so lower case.
For example, for active metrics, Fixed
idem. Maybe more occurrences. Please check through the draft.
   Parameters determine most or all of the IPPM Framework convention
   "packets of Type-P" as described in [RFC2330], such as transport
   protocol, payload length, TTL, etc.  An example for passive metrics
   is for RTP packet loss calculation that relies on the validation of a
   packet as RTP which is a multi-packet validation controlled by
   MIN_SEQUENTIAL as defined by [RFC3550].  Varying MIN_SEQUENTIAL
   values can alter the loss report and this value could be set as a
   fixed parameter

   A Parameter which is Fixed for one Registry entry may be designated
   as a Run-time Parameter for another Registry entry.







Bagnulo, et al.          Expires March 14, 2015                [Page 14]

Internet-Draft      Registry for Performance Metrics      September 2014


7.3.  Method of Measurement Category

   This category includes columns for references to relevant sections of
   the RFC(s) and any supplemental information needed to ensure an
   unambiguous method for implementations.

7.3.1.  Reference Method
Slightly confused with the difference with 7.2.1

   This entry provides references to relevant sections of the RFC(s)
   describing the method of measurement, as well as any supplemental
   information needed to ensure unambiguous interpretation for
   implementations referring to the RFC text.

   Specifically, this section should include pointers to pseudocode or
   actual code that could be used for an unambigious implementation.

7.3.2.  Packet Generation Stream

   This column applies to metrics that generate traffic for measurement
   purposes including but not necessarily limited to Active metrics.
   The generated traffic is referred as stream and this columns describe
   its characteristics.  Principally, two different streams are used in
   IPPM metrics, Poisson distributed as described in [RFC2330] and
   Periodic as described in [RFC3432].  Both Poisson and Periodic have
   their own unique parameters, and the relevant set of values is
   specified in this column.

   Each entry for this column contains the following information:

   o  Value: The name of the packet stream scheduling discipline

   o  Stream Parameters: The values and formats of input factors for
      each type of stream.  For example, the average packet rate and
      distribution truncation value for streams with Poisson-distributed
      inter-packet sending times.

   o  Reference: the specification where the stream is defined

   The simplest example of stream specification is Singleton scheduling,
singleton
   where a single atomic measurement is conducted.  Each atomic
   measurement could consist of sending a single packet (such as a DNS
   request) or sending several packets (for example, to request a
   webpage).  Other streams support a series of atomic measurements in a
   "sample", with a schedule defining the timing between each
   transmitted packet and subsequent measurement.






Bagnulo, et al.          Expires March 14, 2015                [Page 15]

Internet-Draft      Registry for Performance Metrics      September 2014


7.3.3.  Traffic Filter

   This column applies to metrics that observe packets flowing in the
   wire i.e. that is not specifically addressed to the measurement
   agent.  This includes but is not limited to Passive Metrics.  The
   filter specifies the traffic constraints that the passive measurement
   method used is valid (or invalid) for.  This includes valid packet
   sampling ranges, width of valid traffic matches (eg. all traffic on
   interface, UDP packets packets in a flow (eg. same RTP session).

   It is possible that the measurement method may not have a specific
   limitation.  However, this specific registry entry with it's
   combination of fixed parameters implies restrictions.  These
   restrictions would be listed in this field.
I don't understand the above paragraph.
Do you want to say that this is applicable to all traffic, that there are no traffic filter.
If yes, how do note that. The next section contains "all" if no sampling.
Do we want "none" if not traffic filter?
Or maybe "N.A." in each cases, to be consistent?

7.3.4.  Sampling distribution

   The sampling distribution defines out of all the packets that match
   the traffic filter, which one of those are actually used for the
   measurement.  One possibility is "all" which implies that all packets
   matching the Traffic filter are considered, but there may be other
   sampling strategies.  It includes the following information:

      Value: the name of the sampling distribution

      Parameters: if any.

      Reference definition: pointer to the specification where the
      sampling distribution is properly defined.

7.3.5.  Run-time Parameters

   Run-Time Parameters are input factors that must be determined,
   configured into the measurement system, and reported with the results
   for the context to be complete.  However, the values of these
   parameters is not specified in the Registry, rather these parameters
   are listed as an aid to the measurement system implementor or user
   (they must be left as variables, and supplied on execution).

   Where metrics supply a list of Parameters as part of their
   descriptive template, a sub-set of the Parameters will be designated
   as Run-Time Parameters.

   A Data Format of each Run-time Parameter SHALL be specified in this
   column, to simplify the control and implementation of measurement
   devices.
Don't think it's appropriate to specify a data format in the registry.
I could use different encoding such as IPFIX, TWAMP, NETCONF, JSON, ... and still use this registry.





Bagnulo, et al.          Expires March 14, 2015                [Page 16]

Internet-Draft      Registry for Performance Metrics      September 2014


   Examples of Run-time Parameters include IP addresses, measurement
   point designations, start times and end times for measurement, and
   other information essential to the method of measurement.

7.3.6.  Role

   In some method of measurements, there may be several roles defined
   e.g. on a one-way packet delay active measurement, there is one
   measurement agent that generates the packets and the other one that
   receives the packets.  This column contains the name of the role for
   this particular entry.  In the previous example, there should be two
   entries int he registry, one for each role, so that when a
   measurement agent is instructed to perform the one way delay source
   metric know that it is supposed to generate packets.  The values for
   this field are defined in the reference method of measurement.
I'm missing this "role" goal.
Different roles imply different performance metrics, no?

7.4.  Output Category

   For entries which involve a stream and many singleton measurements, a
   statistic may be specified in this column to summarize the results to
   a single value.  If the complete set of measured singletons is
   output, this will be specified here.

   Some metrics embed one specific statistic in the reference metric
   definition, while others allow several output types or statistics.

7.4.1.  Value

   This column contain the name of the output type.  The output type
   defines the type of result that the metric produces.  It can be the
   raw results or it can be some form of statistic.  The specification
   of the output type must define the format of the output.  In some
   systems, format specifications will simplify both measurement
   implementation and collection/storage tasks.  Note that if two
   different statistics are required from a single measurement (for
   example, both "Xth percentile mean" and "Raw"), then a new output
   type must be defined ("Xth percentile mean AND Raw").

7.4.2.  Data Format
Same point as before on the data format.

   This column provides the data format for the output.  It is provided
   to simplify the communication with collection systems and
   implementation of measurement devices.








Bagnulo, et al.          Expires March 14, 2015                [Page 17]

Internet-Draft      Registry for Performance Metrics      September 2014


7.4.3.  Reference

   This column contains a pointer to the specification where the output
   type is defined

7.4.4.  Metric Units

   The measured results must be expressed using some standard dimension
   or units of measure.  This column provides the units.

   When a sample of singletons (see [RFC2330] for definitions of these
   terms) is collected, this entry will specify the units for each
   measured value.
I guess the above is an example.

7.5.  Admisnitratvie information

7.5.1.  Status

   The status of the specification of this Registered Performance
   Metric.  Allowed values are 'current' and 'deprecated'.  All newly
   defined Information Elements have 'current' status.

7.5.2.  Requester

   The requester for the Registered Performance Metric.  The requester
   MAY be a document, such as RFC, or person.

7.5.3.  Revision

   The revision number of a Registered Performance Metric, starting at 0
   for Registered Performance Metrics at time of definition and
   incremented by one for each revision.

7.5.4.  Revision Date

   The date of acceptance or the most recent revision for the Registered
   Performance Metric.

7.6.  Comments and Remarks

   Besides providing additional details which do not appear in other
   categories, this open Category (single column) allows for unforeseen
   issues to be addressed by simply updating this Informational entry.
informational








Bagnulo, et al.          Expires March 14, 2015                [Page 18]

Internet-Draft      Registry for Performance Metrics      September 2014


8.  The Life-Cycle of Registered Metrics

   Once a Performance Metric or set of Performance Metrics has been
   identified for a given application, candidate Registry entry
   specifications in accordance with Section 7 are submitted to IANA to
   follow the process for review by the Performance Metric Experts, as
   defined below.  This process is also used for other changes to the
   Performance Metric Registry, such as deprecation or revision, as
   described later in this section.

   It is also desirable that the author(s) of a candidate Registry entry
   seek review in the relevant IETF working group, or offer the
   opportunity for review on the WG mailing list.
If we keep the performance metrics directorate notion, then we must have a new paragraph here.


8.1.  Adding new Performance Metrics to the Registry

   Requests to change Registered Metrics in the Performance Metric
   Registry are submitted to IANA, which forwards the request to a
   designated group of experts (Performance Metric Experts) appointed by
   the IESG; these are the reviewers called for by the Expert Review
   RFC5226 policy defined for the Performance Metric Registry.  The
   Performance Metric Experts review the request for such things as
   compliance with this document, compliance with other applicable
   Performance Metric-related RFCs, and consistency with the currently
   defined set of Registered Performance Metrics.

   Authors are expected to review compliance with the specifications in
   this document to check their submissions before sending them to IANA.

   The Performance Metric Experts should endeavor to complete referred
   reviews in a timely manner.  If the request is acceptable, the
   Performance Metric Experts signify their approval to IANA, which
   changes
changes -> updates
the Performance Metric Registry.  If the request is not
   acceptable, the Performance Metric Experts can coordinate with the
   requester to change the request to be compliant.  The Performance
   Metric Experts may also choose in exceptional circumstances to reject
   clearly frivolous or inappropriate change requests outright.

   This process should not in any way be construed as allowing the
   Performance Metric Experts to overrule IETF consensus.  Specifically,
   any Registered Metrics that were added with IETF consensus require
   IETF consensus for revision or deprecation.

   Decisions by the Performance Metric Experts may be appealed as in
   Section 7 of RFC5226.






Bagnulo, et al.          Expires March 14, 2015                [Page 19]

Internet-Draft      Registry for Performance Metrics      September 2014


8.2.  Revising Registered Performance Metrics

   A request for Revision is ONLY permissible when the changes maintain
ONLY -> only
   backward-compatibility with implementations of the prior Registry
   entry describing a Registered Metric (entries with lower revision
   numbers, but the same Identifier and Name).

   The purpose of the Status field in the Performance Metric Registry is
   to indicate whether the entry for a Registered Metric is 'current' or
   'deprecated'.

   In addition, no policy is defined for revising IANA Performance
   Metric entries or addressing errors therein.  To be certain, changes
   and deprecations within the Performance Metric Registry are not
   encouraged, and should be avoided to the extent possible.  However,
   in recognition that change is inevitable, the provisions of this
   section address the need for revisions.

   Revisions are initiated by sending a candidate Registered Performance
   Metric definition to IANA, as in Section X, identifying the existing
   Registry entry.

   The primary requirement in the definition of a policy for managing
   changes to existing Registered Performance Metrics is avoidance of
   interoperability problems; Performance Metric Experts must work to
   maintain interoperability above all else.  Changes to Registered
   Performance Metrics may only be done in an inter-operable way;
   necessary changes that cannot be done in a way to allow
   interoperability with unchanged implementations must result in the
   creation of a new Registered Metric and possibly the deprecation of
   the earlier metric.

   A change to a Registered Performance Metric is held to be backward-
   compatible only when:

   1.  "it involves the correction of an error that is obviously only
       editorial; or"

   2.  "it corrects an ambiguity in the Registered Performance Metric's
       definition, which itself leads to issues severe enough to prevent
       the Registered Performance Metric's usage as originally defined;
       or"

   3.  "it corrects missing information in the metric definition without
       changing its meaning (e.g., the explicit definition of 'quantity'
       semantics for numeric fields without a Data Type Semantics
       value); or"




Bagnulo, et al.          Expires March 14, 2015                [Page 20]

Internet-Draft      Registry for Performance Metrics      September 2014


   4.  "it harmonizes with an external reference that was itself
       corrected."

   5.  "BENOIT: NOTE THAT THERE ARE MORE RULES IN RFC 7013 SECTION 5 BUT
       THEY WOULD ONLY APPLY TO THE ACTIVE/PASSIVE DRAFTS.  TO BE
       DISCUSSED."
BENOIT should really focus on this :-)

   If a change is deemed permissible by the Performance Metric Experts,
NEW: If an Performance Metric revision is deemed permissible by the Performance Metric Experts, according to the rules in this document,

   IANA makes the change in the Performance Metric Registry.  The
   requester of the change is appended to the requester in the Registry.

   Each Registered Performance Metric in the Registry has a revision
   number, starting at zero.  Each change to a Registered Performance
   Metric following this process increments the revision number by one.

   COMMENT: Al (and Phil) think we should keep old/revised entries as-
   is, marked as deprecated >>>> Since any revision must be inter-
   operable according to the criteria above, there is no need for the
   Performance Metric Registry to store information about old revisions.
Agreed.

   When a revised Registered Performance Metric is accepted into the
   Performance Metric Registry, the date of acceptance of the most
   recent revision is placed into the revision Date column of the
   Registry for that Registered Performance Metric.

   Where applicable, additions to Registry entries in the form of text
   Comments or Remarks should include the date, but such additions may
   not constitute a revision according to this process.

8.3.  Deprecating Registered Performance Metrics

   Changes that are not permissible by the above criteria for Registered
   Metric's revision may only be handled by deprecation.  A Registered
   Performance Metric MAY be deprecated and replaced when:

   1.  "the Registered Performance Metric definition has an error or
       shortcoming that cannot be permissibly changed as in
       Section Revising Registered Performance Metrics; or"

   2.  "the deprecation harmonizes with an external reference that was
       itself deprecated through that reference's accepted deprecation
       method; or"

   A request for deprecation is sent to IANA, which passes it to the
   Performance Metric Expert for review, as in Section 'The Process for
   Review by the Performance Metric Experts'.  When deprecating an
   Performance Metric, the Performance Metric description in the
   Performance Metric Registry must be updated to explain the



Bagnulo, et al.          Expires March 14, 2015                [Page 21]

Internet-Draft      Registry for Performance Metrics      September 2014


   deprecation, as well as to refer to any new Performance Metrics
   created to replace the deprecated Performance Metric.

   The revision number of a Registered Performance Metric is incremented
   upon deprecation, and the revision Date updated, as with any
   revision.

   The use of deprecated Registered Metrics should result in a log entry
   or human-readable warning by the respective application.

   Names and Metric ID of deprecated Registered Metrics must not be
   reused.

9.  Performance Metric Registry and other Registries

   BENOIT: TBD.

   THE BASIC IDEA IS THAT PEOPLE COULD DIRECTLY DEFINE PERF.  METRICS IN
   OTHER EXISTING REGISTRIES, FOR SPECIFIC PROTOCOL/ENCODING.  EXAMPLE:
   IPFIX.  IDEALLY, ALL PERF.  METRICS SHOULD BE DEFINED IN THIS
   REGISTRY AND REFERS TO FROM OTHER REGISTRIES.

10.  Security considerations

   This draft doesn't introduce any new security considerations for the
   Internet.  However, the definition of Performance Metrics may
   introduce some security concerns, and should be reviewed with
   security in mind.

11.  IANA Considerations

   This document specifies the procedure for Performance Metrics
   Registry setup.  IANA is requested to create a new Registry for
   Performance Metrics called "Registered Performance Metrics" with the
   columns defined in Section 7.

   New assignments for Performance Metric Registry will be administered
   by IANA through Expert Review [RFC5226], i.e., review by one of a
   group of experts, the Performance Metric Experts, appointed by the
   IESG upon recommendation of the Transport Area Directors.  The
   experts will initially be drawn from the Working Group Chairs and
   document editors of the Performance Metrics Directorate [performance-
   metrics-directorate].

   This document requests the allocation of the URI prefix
   urn:ietf:params:ippm:metric for the purpose of generating URIs for
   registered metrics.




Bagnulo, et al.          Expires March 14, 2015                [Page 22]

Internet-Draft      Registry for Performance Metrics      September 2014


12.  Acknowledgments

   Thanks to Brian Trammell and Bill Cerveny, IPPM chairs, for leading
   some brainstorming sessions on this topic.

13.  References

13.1.  Normative References
Please order the RFC numbers.

Regards, Benoit

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330, May
              1998.

   [RFC4148]  Stephan, E., "IP Performance Metrics (IPPM) Metrics
              Registry", BCP 108, RFC 4148, August 2005.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6248]  Morton, A., "RFC 4148 and the IP Performance Metrics
              (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April
              2011.

   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
              Performance Metric Development", BCP 170, RFC 6390,
              October 2011.

   [RFC6576]  Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP
              Performance Metrics (IPPM) Standard Advancement Testing",
              BCP 176, RFC 6576, March 2012.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997.








Bagnulo, et al.          Expires March 14, 2015                [Page 23]

Internet-Draft      Registry for Performance Metrics      September 2014


13.2.  Informative References

   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
              Protocol Extended Reports (RTCP XR)", RFC 3611, November
              2003.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC6035]  Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich,
              "Session Initiation Protocol Event Package for Voice
              Quality Reporting", RFC 6035, November 2010.

   [I-D.ietf-lmap-framework]
              Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
              Aitken, P., and A. Akhter, "A framework for large-scale
              measurement platforms (LMAP)", draft-ietf-lmap-
              framework-08 (work in progress), August 2014.

   [RFC5477]  Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
              Carle, "Information Model for Packet Sampling Exports",
              RFC 5477, March 2009.

   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              RFC 5102, January 2008.

   [RFC6792]  Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
              RTP Monitoring Framework", RFC 6792, November 2012.

   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

   [RFC6776]  Clark, A. and Q. Wu, "Measurement Identity and Information
              Reporting Using a Source Description (SDES) Item and an
              RTCP Extended Report (XR) Block", RFC 6776, October 2012.

   [RFC7003]  Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol
              (RTCP) Extended Report (XR) Block for Burst/Gap Discard
              Metric Reporting", RFC 7003, September 2013.





Bagnulo, et al.          Expires March 14, 2015                [Page 24]

Internet-Draft      Registry for Performance Metrics      September 2014


   [RFC3432]  Raisanen, V., Grotefeld, G., and A. Morton, "Network
              performance measurement with periodic streams", RFC 3432,
              November 2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
              Applicability Statement", RFC 5481, March 2009.

Authors' Addresses

   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN

   Phone: 34 91 6249500
   Email: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es


   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   1831 Diegem
   Belgium

   Email: bclaise@cisco.com


   Philip Eardley
   BT
   Adastral Park, Martlesham Heath
   Ipswich
   ENGLAND

   Email: philip.eardley@bt.com


   Al Morton
   AT&T Labs
   200 Laurel Avenue South
   Middletown, NJ
   USA

   Email: acmorton@att.com



Bagnulo, et al.          Expires March 14, 2015                [Page 25]

Internet-Draft      Registry for Performance Metrics      September 2014


   Aamer Akhter
   Cisco Systems, Inc.
   7025 Kit Creek Road
   RTP, NC 27709
   USA

   Email: aakhter@cisco.com












































.


--------------010201070901000701030307-- From nobody Tue Oct 28 09:47:59 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFBB1A9089 for ; Tue, 28 Oct 2014 09:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbNlvQo6EQvC for ; Tue, 28 Oct 2014 09:47:57 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8621A9085 for ; Tue, 28 Oct 2014 09:41:29 -0700 (PDT) Received: by mx2.eict.de (Postfix, from userid 481) id 732211FF58; Tue, 28 Oct 2014 17:41:28 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id D69291FF55; Tue, 28 Oct 2014 17:41:27 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 7120F3783FD; Tue, 28 Oct 2014 17:41:27 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Tue, 28 Oct 2014 17:41:27 +0100 From: Kostas Pentikousis To: "MORTON, ALFRED C (AL)" , Bill Cerveny , "ippm@ietf.org" Date: Tue, 28 Oct 2014 17:41:26 +0100 Thread-Topic: [ippm] WGLC: draft-ietf-ippm-ipsec-05.txt Thread-Index: Ac/xTxebk3+0/VItRoKEJRffeYkkCwBX7z/A Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE72@SBS2008.eict.local> References: <20140919143517.9076.18495.idtracker@ietfa.amsl.com>, <4AF73AA205019A4C8A1DDD32C034631D7BBF8A2B@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D7BBF8A2B@NJFPSRVEXG0.research.att.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/Ye1MeGhA54HNbwEFLRldMyby1Qw Subject: Re: [ippm] WGLC: draft-ietf-ippm-ipsec-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:47:58 -0000 Dear Al, all, | Although the proposal is applicable to both OWAMP and TWAMP, we | currently have no registry available to extend OWAMP and use this new | mode -- IOW, there is no IANA Registry for OWAMP Mode bit positions. |=20 | In the near term, the draft could be positioned to extend TWAMP and | mention clear applicability to OWAMP (but no current way to register | the extension). I think it makes sense to add some text in the beginning of section 4 to cl= early spell out this issue, and then in the remainder of section 4 use "TWA= MP" instead of "O/TWAMP". We could update the draft as soon as the datatrac= ker is open for uploads. Would this be ok? For example: OLD: This section presents a method of binding O/TWAMP and IKEv2 for network mea= surements between a client and a server which both support IPsec. In short= , the shared key used for securing O/TWAMP traffic is derived using IKEv2 [= RFC5996].=20 NEW: This section specifies a method of binding TWAMP and IKEv2 for network meas= urements between a client and a server which both support IPsec. In short,= the shared key used for securing TWAMP traffic is derived using IKEv2 [RFC= 5996]. This document reserves from the TWAMP-Modes registry the Mode value = IANA.TBA.TWAMP.IKEv2Derived which MUST be used by TWAMP implementations com= patible with this specification. Although an implementer MAY use this Mode = value in an OWAMP implementation as well. It should be noted, however, that= IANA does not currently maintain an IANA registry for OWAMP Mode values an= d, therefore, independent OWAMP implementations should be checked for full = compatibility with respect to the use of this Mode value. If you have specific text you would like to see included, please do not hes= itate. | In the long term, IPPM could establish the Modes and Commands | registries for OWAMP and (in the process) decide if we will try to | simplify life by coordinating bit positions for both -WAMPs (which | would mean going back and specifying the OWAMP equivalent of all the | applicable existing TWAMP Modes. I think this makes a lot of sense and I would personally be happy to help i= n this effort. Perhaps a new draft for Dallas? |=20 | I'm fairly sure I mentioned this issue to Kostas in an exchange last | month, so it's not a complete surprise, and I'm sure we can work out | the changes to accomodate the missing OWAMP registry. You're right Al. We did name the Mode as "IANA.TBA.TWAMP.IKEv2Derived" in t= his revision and the IANA considerations does mention only the TWAMP-Modes = registry, but unfortunately we didn't add the aforementioned text which wou= ld have been optimal. Sorry about that. Best regards, Kostas From nobody Tue Oct 28 14:02:37 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600991ACF8C for ; Tue, 28 Oct 2014 14:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKebXDe8Pupd for ; Tue, 28 Oct 2014 14:02:27 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 163521ACF19 for ; Tue, 28 Oct 2014 14:02:21 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id DF9AA120242; Tue, 28 Oct 2014 17:05:43 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id 738B9F0422; Tue, 28 Oct 2014 16:55:51 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Tue, 28 Oct 2014 16:55:51 -0400 From: "MORTON, ALFRED C (AL)" To: Kostas Pentikousis , Bill Cerveny , "ippm@ietf.org" Date: Tue, 28 Oct 2014 16:55:50 -0400 Thread-Topic: [ippm] WGLC: draft-ietf-ippm-ipsec-05.txt Thread-Index: Ac/xTxebk3+0/VItRoKEJRffeYkkCwBX7z/AABBNse0= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D7BBF8A34@NJFPSRVEXG0.research.att.com> References: <20140919143517.9076.18495.idtracker@ietfa.amsl.com>, <4AF73AA205019A4C8A1DDD32C034631D7BBF8A2B@NJFPSRVEXG0.research.att.com>, <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE72@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEA10C7ADE72@SBS2008.eict.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/VN6nXChzoPF9ofV6l0-xbP-0vG0 Subject: Re: [ippm] WGLC: draft-ietf-ippm-ipsec-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:02:33 -0000 Hi Kostas, Two quick thoughts in response: Although we may say some appropriate things in section 4, this right place to take care of this is in a "Scope and Applicability" section, where you could simply say that the control procedures are applicable to OWAMP, but without a registry for Mode values there is no way to extend OWAMP at the time of this writing. And since this is a Standards Track extension of TWAMP, I don't=20 think we will be able to encourage use of a specific Mode value for OWAMP implementations - this "overhanging" the assignment process is strongly frowned upon. Until IETF and IANA take action, arranging for use of this feature must be arranged privately among consenting OWAMP users. (I think that's roughly acceptable language for situations like this.) more later on the registry for OWAMP, Al ________________________________________ From: Kostas Pentikousis [k.pentikousis@eict.de] Sent: Tuesday, October 28, 2014 12:41 PM To: MORTON, ALFRED C (AL); Bill Cerveny; ippm@ietf.org Subject: AW: [ippm] WGLC: draft-ietf-ippm-ipsec-05.txt Dear Al, all, | Although the proposal is applicable to both OWAMP and TWAMP, we | currently have no registry available to extend OWAMP and use this new | mode -- IOW, there is no IANA Registry for OWAMP Mode bit positions. | | In the near term, the draft could be positioned to extend TWAMP and | mention clear applicability to OWAMP (but no current way to register | the extension). I think it makes sense to add some text in the beginning of section 4 to cl= early spell out this issue, and then in the remainder of section 4 use "TWA= MP" instead of "O/TWAMP". We could update the draft as soon as the datatrac= ker is open for uploads. Would this be ok? For example: OLD: This section presents a method of binding O/TWAMP and IKEv2 for network mea= surements between a client and a server which both support IPsec. In short= , the shared key used for securing O/TWAMP traffic is derived using IKEv2 [= RFC5996]. NEW: This section specifies a method of binding TWAMP and IKEv2 for network meas= urements between a client and a server which both support IPsec. In short,= the shared key used for securing TWAMP traffic is derived using IKEv2 [RFC= 5996]. This document reserves from the TWAMP-Modes registry the Mode value = IANA.TBA.TWAMP.IKEv2Derived which MUST be used by TWAMP implementations com= patible with this specification. Although an implementer MAY use this Mode = value in an OWAMP implementation as well. It should be noted, however, that= IANA does not currently maintain an IANA registry for OWAMP Mode values an= d, therefore, independent OWAMP implementations should be checked for full = compatibility with respect to the use of this Mode value. If you have specific text you would like to see included, please do not hes= itate. | In the long term, IPPM could establish the Modes and Commands | registries for OWAMP and (in the process) decide if we will try to | simplify life by coordinating bit positions for both -WAMPs (which | would mean going back and specifying the OWAMP equivalent of all the | applicable existing TWAMP Modes. I think this makes a lot of sense and I would personally be happy to help i= n this effort. Perhaps a new draft for Dallas? | | I'm fairly sure I mentioned this issue to Kostas in an exchange last | month, so it's not a complete surprise, and I'm sure we can work out | the changes to accomodate the missing OWAMP registry. You're right Al. We did name the Mode as "IANA.TBA.TWAMP.IKEv2Derived" in t= his revision and the IANA considerations does mention only the TWAMP-Modes = registry, but unfortunately we didn't add the aforementioned text which wou= ld have been optimal. Sorry about that. Best regards, Kostas From nobody Wed Oct 29 02:55:50 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87C21A7032 for ; Wed, 29 Oct 2014 02:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebF_RpcbnttJ for ; Wed, 29 Oct 2014 02:55:42 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCAF1A7021 for ; Wed, 29 Oct 2014 02:55:41 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-a1-5450b99b2424 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 13.0B.04387.B99B0545; Wed, 29 Oct 2014 10:55:39 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.247]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 10:55:38 +0100 From: Andreas Johnsson A To: Bill Cerveny , "ippm@ietf.org" Thread-Topic: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt Thread-Index: AQHP7hISJOaHepE2E0GkVpCC5iPHTpxG4KhQ Date: Wed, 29 Oct 2014 09:55:38 +0000 Message-ID: References: <20141007152827.25462.89556.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D26039A349A82849AC399E2B92A05EF61A3E73BFESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvje7snQEhBm13FCx6HrxjtpjzspvZ gcljyZKfTB5r3v1nDGCK4rJJSc3JLEst0rdL4MroWbSSsaB7CWPFia3bGBsYJ/czdjFyckgI mEicfNPIAmGLSVy4t56ti5GLQ0jgCKPEjKl/WSGcJUDOoyusIFVsAlYS67u2MXcxcnCICLhJ 3L6vBhIWFrCX2LLrGzuILSLgIPFtwQk2CNtIYtem92CtLAKqEid/vGcGsXkFfCVWTpwOVi8k UCGx8dthsDingKPEs84GJhCbEeig76fWgNnMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWxF iavTl0PV50scftsPtUtQ4uTMJywTGEVmIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4 zIQsvoCRfRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYGwd3PLbagfjweeOhxgFOBiVeHgL JgSECLEmlhVX5h5ilOZgURLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRm3DdaXp GRpz3s3qXLD/xIvTM3R83yzZeTGx8P2Ete4XrhcLT3m5emlGl/1H43MBsdtFQzcGlpo05fX/ DMn51vvx5vunU8waLA7O/Woqw6TX7GDdOVtHvDLm2Qb5LNbL2dbvrW77HlzvcC0jOTtL5vqZ lQxPVyzIFvKpNzn+7/XOhftNO3+ejFdiKc5INNRiLipOBAAIxLDMjgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/CLiQvf7If64vs2OulDBzfzlCpCw Subject: Re: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 09:55:47 -0000 --_000_D26039A349A82849AC399E2B92A05EF61A3E73BFESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I reviewed the document and have three main comments that I feel must be co= nsidered. Two are related to Section 5 while the third is related to Sectio= n 2. Comment 1 In general I think that Section 5 is very confusing. Especially considering= that the group agreed on that asymmetric packet size testing should be a R= ECOMMENDED feature in this draft. I'll give a few examples from this paragr= aph that creates this confusion. In the beginning of Section 5 it is stated that Essentially, the test protocol MUST support the measurement features described in the sections above. This requires: 1. Communicating all test variables to the SENDER and RECEIVER 2. Results collection in a one-way architecture 3. Remote device control for both one-way and two-way architectures 4. Asymmetric packet size and/or pseudo-one-way test capability in a two-way measurement architecture (along with symmetric packet size tests in common use) Bullet 4 says that a test protocol MUST be able to control asymmetric packe= t sizes and/or pseudo-one-way test capabilities. Since pseudo-one-way test = capabilities are not defined in the document this becomes contradictory to = the next paragraph The ability to control and generate asymmetric rates in a two-way architecture is REQUIRED. Two-way architectures are RECOMMENDED to include control and generation capability for both asymmetric and symmetric packet sizes, because packet size often matters in the scope of this problem and test systems SHOULD be equipped to detect directional size dependency through comparative measurements. where it is stated that two-way architectures are RECOMMENDED to include as= ymmetric packet size testing features. So, either the draft must define pseudo-one-way testing or change the MUST = to RECOMMENDED. Comment 2 A set of conditions arguing for asymmetric packet size testing are describe= d in Section 5. I think that it is only the condition describing the MTU - = ACK streams that really requires asymmetric packet size testing. The other = conditions can be dealt with using "pseudo-one-way testing" (assuming it is= defined as creating two TWAMP sessions with two different packet sizes). Therefor I think that the 2nd to last paragraph Implementations may support control and generation for only symmetric packet sizes when none of the above conditions hold. should be removed. Also I think that the draft should state that the condit= ions can be solved either with asymmetrical packet size testing features or= with a pseudo-one-way testing feature (if defined). Comment 3 I strongly believe that the first paragraph of section 2 should mention RFC= 6802 as a test protocol tool. This protocol is the first IETF protocol spe= cifically designed for rate and capacity measurements. Best regards, Andreas Johnsson From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Bill Cerveny Sent: den 22 oktober 2014 18:06 To: ippm@ietf.org Subject: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt draft-ietf-ippm-rate-problem has been updated with changes requested by IPP= M participants. As such, I am kicking off a WGLC for draft-ietf-ippm-rate-p= roblem-07 until November 5, 2014. Please provide comments before the WGLC e= nds. Thanks, Bill Cerveny IPPM WG co-chair Begin forwarded message: From: internet-drafts@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-07.txt Date: October 7, 2014 at 11:28:27 AM EDT To: i-d-announce@ietf.org Cc: ippm@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of th= e IETF. Title : Rate Measurement Test Protocol Problem Statement Author : Al Morton Filename : draft-ietf-ippm-rate-problem-07.txt Pages : 12 Date : 2014-10-07 Abstract: This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. The rate measurement scenario has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_D26039A349A82849AC399E2B92A05EF61A3E73BFESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I reviewed the document and have three main comments= that I feel must be considered. Two are related to Section 5 while the thi= rd is related to Section 2.

 

Comment 1

 

In general I think that Section 5 is very confusing.= Especially considering that the group agreed on that asymmetric packet siz= e testing should be a RECOMMENDED feature in this draft. I’ll give a = few examples from this paragraph that creates this confusion.

 

In the beginning of Section 5 it is stated that=

 

= Essentially, the test protocol MUST support the measurement features

=    described in the sections above.  This requires:

=  

=    1.  Communicating all test variables to the SENDER and RE= CEIVER

=  

=    2.  Results collection in a one-way architecture

=  

=    3.  Remote device control for both one-way and two-way ar= chitectures

=  

=    4.  Asymmetric packet size and/or pseudo-one-way test cap= ability in a

=        two-way measurement architecture (alon= g with symmetric packet

=        size tests in common use)

 

Bullet 4 says that a test protocol MUST be able to c= ontrol asymmetric packet sizes and/or pseudo-one-way test capabilities. Sin= ce pseudo-one-way test capabilities are not defined in the document this be= comes contradictory to the next paragraph

 

= The ability to control and generate asymmetric rates in a two-way

=    architecture is REQUIRED.  Two-way architectures are RECO= MMENDED to

=    include control and generation capability for both asymmetric = and

=    symmetric packet sizes, because packet size often matters in t= he

=    scope of this problem and test systems SHOULD be equipped to d= etect

=    directional size dependency through comparative measurements.<= o:p>

where it is stated that two-way architectures are RE= COMMENDED to include asymmetric packet size testing features.

 

So, either the draft must define pseudo-one-way test= ing or change the MUST to RECOMMENDED.

 

Comment 2

 

A set of conditions arguing for asymmetric packet si= ze testing are described in Section 5. I think that it is only the conditio= n describing the MTU – ACK streams that really requires asymmetric pa= cket size testing. The other conditions can be dealt with using “pseudo-one-way testing” (assuming it = is defined as creating two TWAMP sessions with two different packet sizes).

 

Therefor I think that the 2nd to last par= agraph

 

Implementations may support control and generation for onl= y symmetric

   packet sizes when none of the above condition= s hold.

 

should be removed. Also I think that the draft shoul= d state that the conditions can be solved either with asymmetrical packet s= ize testing features or with a pseudo-one-way testing feature (if defined).=

 

Comment 3

 

I strongly believe that the first paragraph of secti= on 2 should mention RFC 6802 as a test protocol tool. This protocol is the = first IETF protocol specifically designed for rate and capacity measurement= s.

 

 

Best regards,

Andreas Johnsson

 

 <= /p>

 <= /p>

From: ippm [ma= ilto:ippm-bounces@ietf.org] On Behalf Of Bill Cerveny
Sent: den 22 oktober 2014 18:06
To: ippm@ietf.org
Subject: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt

 

draft-ietf-ippm-rate-problem has been updated with c= hanges requested by IPPM participants. As such, I am kicking off a WGLC for=  draft-ietf-ippm-rate-problem-07 until November 5, 2014. Please provid= e comments before the WGLC ends.

 

Thanks,

 

Bill Cerveny

IPPM WG co-chair

 

Begin forwarded message:



From: internet-drafts@ietf.org<= /span>

Subject: [ippm] I-D Action: draft-ietf-ippm-rate-pr= oblem-07.txt

Date: October 7, 2014 at 11:28:27 AM EDT

 


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Performance Metrics Working Group of th= e IETF.

       Title     &nb= sp;     : Rate Measurement Test Protocol Problem S= tatement
       Author     &n= bsp;    : Al Morton
       &n= bsp;    Filename       =  : draft-ietf-ippm-rate-problem-07.txt
       &n= bsp;    Pages       &nb= sp;   : 12
       &n= bsp;    Date       &nbs= p;    : 2014-10-07

Abstract:
  This memo presents an access rate-measurement problem statement= for
  test protocols to measure IP Performance Metrics.  The rat= e
  measurement scenario has wide-spread attention of Internet acce= ss
  subscribers and seemingly all industry players, including regul= ators.
  Key test protocol aspects require the ability to control packet= size
  on the tested path and enable asymmetrical packet size testing = in a
  controller-responder architecture.



The IETF datatracker status page for this draft is:
= https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/

There's also a htmlized version available at:
http= ://tools.ietf.org/html/draft-ietf-ippm-rate-problem-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-07<= br>

Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet= -drafts/

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org= /mailman/listinfo/ippm

 

--_000_D26039A349A82849AC399E2B92A05EF61A3E73BFESESSMB105erics_-- From nobody Wed Oct 29 10:34:06 2014 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4FF1A871B for ; Wed, 29 Oct 2014 10:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye-wSBhEkMUJ for ; Wed, 29 Oct 2014 10:33:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08B41A8546 for ; Wed, 29 Oct 2014 10:33:26 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-a1-545124e5e719 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 03.BC.24955.5E421545; Wed, 29 Oct 2014 18:33:25 +0100 (CET) Received: from ESESSMB107.ericsson.se ([169.254.7.190]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 18:33:24 +0100 From: Christofer Flinta To: Bill Cerveny , "ippm@ietf.org" Thread-Topic: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt Thread-Index: AQHP7hISXscZLfnHokKntUzZHH2tn5xHNYDw Date: Wed, 29 Oct 2014 17:33:24 +0000 Message-ID: References: <20141007152827.25462.89556.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_FE641D5B07B8124C97FF41C800C98E2719E7EB6AESESSMB107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvje5TlcAQg7Y7IhY9D94xW8x52c3s wOSxZMlPJo817/4zBjBFcdmkpOZklqUW6dslcGU8btrKXPB3A2PF06c7mRsYv89m7GLk5JAQ MJFYd/A0G4QtJnHh3nogm4tDSOAIo8Teh/sYIZwljBIH+j8wg1SxCVhIHOubyt7FyMEhIuAm cfu+GkhYWMBeYsuub+wgtoiAg8S3BSfYIGwjiaY/W8DiLAKqEsvvnwSL8wr4Shx+8IwVxBYS qJDY+O0w2HhOAUeJZ50NTCA2o4CsxP3v91hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQ tpLE2sPboerzJa7fuwa1S1Di5MwnLBMYRWYhGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHP HHjMhCy+gJF9FaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgbB3c8lt1B+PlN46HGAU4GJV4 eAsmBIQIsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGQTe+ 2DRP1j03l0132pUp1mI54Yc322Wlq817fKeGP/Se4Nt9wnph/P3WGEVetv+HMladmFOt5RvC JFZ2JWlGYiNb4ob1ho0hDf+vRh87WMxwPnCTwePrXEcPtogUXSm4HbK7RP1eS9Yd4+c/ni1S k9fr3Hlw4sk06abjb5v2TnvmzLWgZ9NpJZbijERDLeai4kQAMWTKtI4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/pSwovLaA60mMIPemHhJ1quGr7Wo Subject: Re: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:33:57 -0000 --_000_FE641D5B07B8124C97FF41C800C98E2719E7EB6AESESSMB107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have reviewed the draft and I have two comments. Comment 1. I think the concept "stream" should be defined. Its use in the text suggests that it is the same thing as a session, but in= Section 4 the following statement is then confusing: "e. Variable number of packets-pairs, ensembles, or streams used in a test session." Is the intention to enable several intermixed streams from the Sender to th= e Receiver within the same session? In that case the session set-up may be = very complex, since a control protocol needs to specify all parameters for = several streams within a session. IMO a better option is to set up several = parallel sessions between the Sender and the Receiver if different profiles= are needed. I think this must be sorted out. Comment 2. Section 5, bullet 4: "4. Asymmetric packet size and/or pseudo-one-way test capability in a two-way measurement architecture (along with symmetric packet size tests in common use)" I am not sure this draft should specify the details of the protocol to be u= sed for rate measurements, e.g. the use of packet size. It should rather be= a general specification for any type of two-way protocol - in the future n= ot necessarily based on TWAMP. As we know, there are many possibilities for= implementing rate measurements in different directions, including sending = packets with asymmetric size, sending trigger packets for trains in reverse= direction and buffering trains in the Receiver. I don't think we should re= strict ourselves to any of these methods in the draft, but let the implemen= ters be able to choose from different alternatives depending on the needs. = Therefore I suggest to replace bullet 4 with a general requirement about ho= w the control protocol sets up the rate measurement sessions: "4. The ability for the control protocol to set up rate measurements in bot= h directions of a session in a two-way measurement architecture. The rate m= easurements can be set up separately for each direction (measuring forward = direction only or reverse direction only during a session) or in parallel (= measuring both forward and reverse direction during the same session)." Best regards, Christofer Flinta From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Bill Cerveny Sent: den 22 oktober 2014 18:06 To: ippm@ietf.org Subject: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt draft-ietf-ippm-rate-problem has been updated with changes requested by IPP= M participants. As such, I am kicking off a WGLC for draft-ietf-ippm-rate-p= roblem-07 until November 5, 2014. Please provide comments before the WGLC e= nds. Thanks, Bill Cerveny IPPM WG co-chair Begin forwarded message: From: internet-drafts@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-07.txt Date: October 7, 2014 at 11:28:27 AM EDT To: i-d-announce@ietf.org Cc: ippm@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics Working Group of th= e IETF. Title : Rate Measurement Test Protocol Problem Statement Author : Al Morton Filename : draft-ietf-ippm-rate-problem-07.txt Pages : 12 Date : 2014-10-07 Abstract: This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. The rate measurement scenario has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ippm-rate-problem-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-rate-problem-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --_000_FE641D5B07B8124C97FF41C800C98E2719E7EB6AESESSMB107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

I have rev= iewed the draft and I have two comments.

 = ;

Comment= 1.

I think th= e concept “stream” should be defined.

Its use in= the text suggests that it is the same thing as a session, but in Section 4= the following statement is then confusing:

“e.  Variable number of packets-=
pairs, ensembles, or streams used in a

       test session.”

Is the int= ention to enable several intermixed streams from the Sender to the Receiver= within the same session? In that case the session set-up may be very complex, since a control protocol needs to specify all paramet= ers for several streams within a session. IMO a better option is to set up = several parallel sessions between the Sender and the Receiver if different = profiles are needed. I think this must be sorted out.

 = ;

Comment= 2.

Section 5,= bullet 4:

“4.  Asymmetric packet size and/or pseudo-one-way test capabilit= y in a

       two-wa= y measurement architecture (along with symmetric packet

       size t= ests in common use)”=

I am not s= ure this draft should specify the details of the protocol to be used for ra= te measurements, e.g. the use of packet size. It should rather be a general specification for any type of two-way protocol - in the futur= e not necessarily based on TWAMP. As we know, there are many possibilities = for implementing rate measurements in different directions, including sendi= ng packets with asymmetric size, sending trigger packets for trains in reverse direction and buffering trai= ns in the Receiver. I don’t think we should restrict ourselves to any= of these methods in the draft, but let the implementers be able to choose = from different alternatives depending on the needs. Therefore I suggest to replace bullet 4 with a general requi= rement about how the control protocol sets up the rate measurement sessions= :

 = ;

“4. = The ability for the control protocol to set up rate measurements in both di= rections of a session in a two-way measurement architecture. The rate measurements can be set up separately for each direction (measuring f= orward direction only or reverse direction only during a session) or in par= allel (measuring both forward and reverse direction during the same session= ).”

 = ;

Best regar= ds,

Christofer= Flinta

 = ;

 = ;

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Bill Cerveny
Sent: den 22 oktober 2014 18:06
To: ippm@ietf.org
Subject: [ippm] WGLC on draft-ietf-ippm-rate-problem-07.txt

 

draft-ietf-ippm-rate-problem has been updated with c= hanges requested by IPPM participants. As such, I am kicking off a WGLC for=  draft-ietf-ippm-rate-problem-07 until November 5, 2014. Please provid= e comments before the WGLC ends.

 

Thanks,

 

Bill Cerveny

IPPM WG co-chair

 

Begin forwarded message:



From: internet-drafts@ietf.org<= /span>

Subject: [ippm] I-D Action: draft-ietf-ippm-rate-pr= oblem-07.txt

Date: October 7, 2014 at 11:28:27 AM EDT

 


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Performance Metrics Working Group of th= e IETF.

       Title     &nb= sp;     : Rate Measurement Test Protocol Problem S= tatement
       Author     &n= bsp;    : Al Morton
       &n= bsp;            = ;  Filename        : draft-i= etf-ippm-rate-problem-07.txt
       &n= bsp;            = ;  Pages          =  : 12
       &n= bsp;            = ;  Date          &= nbsp; : 2014-10-07

Abstract:
  This memo presents an access rate-measurement problem statement= for
  test protocols to measure IP Performance Metrics.  The rat= e
  measurement scenario has wide-spread attention of Internet acce= ss
  subscribers and seemingly all industry players, including regul= ators.
  Key test protocol aspects require the ability to control packet= size
  on the tested path and enable asymmetrical packet size testing = in a
  controller-responder architecture.



The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipp= m-rate-problem/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ippm-rate-pro= blem-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-ippm-rate-problem-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
ippm mailing list
ippm@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/ippm

 

--_000_FE641D5B07B8124C97FF41C800C98E2719E7EB6AESESSMB107erics_--