From nobody Fri Jan 2 07:46:49 2015 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 05D4A1A87A5 for ; Fri, 2 Jan 2015 07:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 1XmzX0GHSAYK for ; Fri, 2 Jan 2015 07:46:45 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 896EA1A8795 for ; Fri, 2 Jan 2015 07:46:45 -0800 (PST) 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 22EDD120745; Fri, 2 Jan 2015 10:59:51 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id 9A124E03B3; Fri, 2 Jan 2015 10:43:19 -0500 (EST) 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, 2 Jan 2015 10:46:44 -0500 From: "MORTON, ALFRED C (AL)" To: Kostas Pentikousis , "ippm@ietf.org" Date: Fri, 2 Jan 2015 10:46:43 -0500 Thread-Topic: New Version Notification for draft-ietf-ippm-ipsec-07.txt Thread-Index: AdAiC6zxCbWVQLhEQ4a73n6+6VyUugAAFNfAASXIWLA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D85375F44@NJFPSRVEXG0.research.att.com> References: <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB607753@SBS2008.eict.local> In-Reply-To: <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB607753@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/v7VvEQeJr-NHMTD-gQfEWx3s0LI Subject: Re: [ippm] New Version Notification for draft-ietf-ippm-ipsec-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: Fri, 02 Jan 2015 15:46:47 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHBtIFttYWlsdG86aXBwbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS29zdGFzIFBlbnRpa291c2lzDQo+IFNlbnQ6 IFNhdHVyZGF5LCBEZWNlbWJlciAyNywgMjAxNCAzOjEyIFBNDQo+IFRvOiBpcHBtQGlldGYub3Jn OyBpcHNlY0BpZXRmLm9yZw0KLi4uDQo+IFdlIGhhdmUgdXBkYXRlZCBkcmFmdC1pZXRmLWlwcG0t aXBzZWMgdG8gYWRkcmVzcyB0aGUgaXNzdWUgdGhhdCBhcm9zZQ0KPiBkdXJpbmcgdGhlIHNoZXBo ZXJkIHJldmlldyAoSUFOQSBjb25zaWRlcmF0aW9ucykuDQo+IA0KPiBQbGVhc2UgbGV0IHVzIGtu b3cgaWYgeW91IGhhdmUgYW55IGZpbmFsIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4NCj4gDQoN Ckxvb2tzIG9rIHRvIG1lLCBLb3N0YXMuDQpBbA0KDQogDQo= From nobody Tue Jan 6 02:24:44 2015 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 5C2C61A914E; Tue, 6 Jan 2015 02:24:42 -0800 (PST) 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 4KrEbotcvShe; Tue, 6 Jan 2015 02:24:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF62D1A914A; Tue, 6 Jan 2015 02:24:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Trammell" To: spencerdawkins.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150106102440.13588.95602.idtracker@ietfa.amsl.com> Date: Tue, 06 Jan 2015 02:24:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/ROHlhYOAxwE_h_MBguUToOArVxw Cc: draft-ietf-ippm-ipsec.all@tools.ietf.org, iesg-secretary@ietf.org, ippm@ietf.org, ippm-chairs@tools.ietf.org Subject: [ippm] Publication has been requested for draft-ietf-ippm-ipsec-07 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, 06 Jan 2015 10:24:42 -0000 Brian Trammell has requested publication of draft-ietf-ippm-ipsec-07 as Proposed Standard on behalf of the IPPM working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ From nobody Tue Jan 6 02:30:14 2015 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 3D9C51A9165 for ; Tue, 6 Jan 2015 02:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vPUDDbFcftsT for ; Tue, 6 Jan 2015 02:30:07 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECB41A9152 for ; Tue, 6 Jan 2015 02:30:05 -0800 (PST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 27E3C1A00A7; Tue, 6 Jan 2015 11:30:03 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Trammell In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D85375F44@NJFPSRVEXG0.research.att.com> Date: Tue, 6 Jan 2015 11:30:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB607753@SBS2008.eict.local> <4AF73AA205019A4C8A1DDD32C034631D85375F44@NJFPSRVEXG0.research.att.com> To: "ippm@ietf.org" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/i9AiQ1Et6Q4nmNxCsLu_jK0EZuk Cc: Kostas Pentikousis , Al Morton Subject: Re: [ippm] New Version Notification for draft-ietf-ippm-ipsec-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: Tue, 06 Jan 2015 10:30:11 -0000 Greetings, all, This revision addresses the last open issue during WG shepherd review, = so I've sent it up to the IESG for publication. Many thanks to the authors for their work on the document to date! Cheers, Brian > On 02 Jan 2015, at 16:46, MORTON, ALFRED C (AL) = wrote: >=20 >> -----Original Message----- >> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Kostas = Pentikousis >> Sent: Saturday, December 27, 2014 3:12 PM >> To: ippm@ietf.org; ipsec@ietf.org > ... >> We have updated draft-ietf-ippm-ipsec to address the issue that arose >> during the shepherd review (IANA considerations). >>=20 >> Please let us know if you have any final comments and suggestions. >>=20 >=20 > Looks ok to me, Kostas. > Al >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Tue Jan 6 07:51:47 2015 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 840041A0018 for ; Tue, 6 Jan 2015 07:51:46 -0800 (PST) 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 WCbV2bpFePmE for ; Tue, 6 Jan 2015 07:51:44 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0611A006E for ; Tue, 6 Jan 2015 07:51:44 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8D30E2099C for ; Tue, 6 Jan 2015 10:51:43 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 06 Jan 2015 10:51:43 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type:subject :message-id:date:to:mime-version; s=smtpout; bh=eW6hVisqIpaSmgbn Tg6YtJqUpho=; b=H2n609I2RY/GgVS9VY9kd8eh1/sYLsqsqEfb6/brlFY4DYV/ QiSlbw/xg6GwvH+uV4GqwGT57fFyZcM712zvnkRRAMxGXWMWDLHtVMpaOj8jEi+S afq4ghKghG9wFvhFrG7vKY3cy+umMv3Sy8ndSsF+pE7bCjQAdsOmeUt3qe8= X-Sasl-enc: G7VddVUZXEgY7Zcwlw98sS1qzBdNRuhzxrLtBE5FOL+l 1420559503 Received: from eng-6-37.aa.arbor.net (unknown [216.130.192.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 31310C00285 for ; Tue, 6 Jan 2015 10:51:43 -0500 (EST) From: Bill Cerveny Content-Type: multipart/alternative; boundary="Apple-Mail=_0ABB2BD0-D9D9-4117-B796-0EEF0EAEF913" Message-Id: Date: Tue, 6 Jan 2015 10:51:42 -0500 To: ippm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/tb_ZuyEILGT8p4-R1tCWXYptuoM Subject: [ippm] WGLC for draft-ietf-ippm-2679-bis-00 and draft-ietf-ippm-2680-bis-00 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, 06 Jan 2015 15:51:46 -0000 --Apple-Mail=_0ABB2BD0-D9D9-4117-B796-0EEF0EAEF913 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As discussed at the IETF meeting, drafts draft-ietf-ippm-2679-bis-00 (A = One-Way Delay Metric for IPPM) and draft-ietf-ippm-2680-bis-00 (A = One-Way Loss Metric for IPPM) are ready for Working Group Last Call = (WGLC). As such, these documents will be in WGLC until Friday, January = 23, 2014. Please send comments to ippm@ietf.org , including = statements that you've reviewed the document and are okay with sending = it up to the IESG for publication.=20 For those new to IETF process, the WGLC process is discussed at: - https://tools.ietf.org/html/rfc2418#section-7.4 = - https://tools.ietf.org/html/rfc6174#section-4.2.7 = Basic information on the documents is below. 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 = 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 = Regards, Bill Cerveny IPPM WG Co-chair= --Apple-Mail=_0ABB2BD0-D9D9-4117-B796-0EEF0EAEF913 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii As discussed at the IETF meeting, = drafts draft-ietf-ippm-2679-bis-00 (A One-Way Delay Metric for = IPPM) and draft-ietf-ippm-2680-bis-00 (A One-Way Loss Metric for IPPM) = are ready for Working Group Last Call (WGLC). As such, these documents = will be in WGLC until Friday, January 23, 2014.

Please send comments to ippm@ietf.org, including = statements that you've reviewed the document and are okay with sending = it up to the IESG for publication. 

For those new to IETF process, the WGLC = process is discussed at:
- https://tools.ietf.org/html/rfc2418#section-7.4
- https://tools.ietf.org/html/rfc6174#section-4.2.7

Basic information on = the documents is below.

       Title =           : A One-Way = Delay Metric for IPPM
       Authors =         : Guy Almes
          &nb= sp;            = ;  Sunil Kalidindi
          &nb= sp;            = ;  Matt Zekauskas
          &nb= sp;            = ;  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/<= br class=3D"">
There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-ippm-2679-bis-00

       Title =           : A One-Way = Loss Metric for IPPM
       Authors =         : Guy Almes
          &nb= sp;            = ;  Sunil Kalidindi
          &nb= sp;            = ;  Matt Zekauskas
          &nb= sp;            = ;  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/<= br class=3D"">
There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-ippm-2680-bis-00

Regards,

Bill Cerveny
IPPM WG Co-chair
= --Apple-Mail=_0ABB2BD0-D9D9-4117-B796-0EEF0EAEF913-- From nobody Wed Jan 7 04:41:22 2015 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 41EF61A89FD for ; Wed, 7 Jan 2015 04:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 REZMbo7oWu8T for ; Wed, 7 Jan 2015 04:41:12 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3E11A8A03 for ; Wed, 7 Jan 2015 04:41:11 -0800 (PST) Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail31.telekom.de with ESMTP; 07 Jan 2015 13:40:45 +0100 X-IronPort-AV: E=Sophos;i="5.07,714,1413237600"; d="scan'208,217";a="736542333" Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 07 Jan 2015 13:40:45 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 7 Jan 2015 13:40:45 +0100 From: To: , Date: Wed, 7 Jan 2015 13:40:44 +0100 Thread-Topic: [ippm] WGLC for draft-ietf-ippm-2679-bis-00 and draft-ietf-ippm-2680-bis-00 Thread-Index: AdApyLUzOrAm1iNQRqu8LIjps0K7OgAhUu4g Message-ID: References: In-Reply-To: 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: multipart/alternative; boundary="_000_CA7A7C64CC4ADB458B74477EA99DF6F50439BD1A13HE111643EMEA1_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/5LYTizB5aun95RgLQlr68th8pzw Cc: ippm@ietf.org Subject: Re: [ippm] WGLC for draft-ietf-ippm-2679-bis-00 and draft-ietf-ippm-2680-bis-00 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, 07 Jan 2015 12:41:21 -0000 --_000_CA7A7C64CC4ADB458B74477EA99DF6F50439BD1A13HE111643EMEA1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bill, Al thanks. both drafts read good and I hope they will get RFC's soon. I however missed one QoS related point during an earlier review I made: 3.6 Methodologies: As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence). If precedence refers to Type of Service, which has been changed to DSCP mea= nwhile, then precedence should be changed to DSCP (and/or ECN codepoint) or= DS field. There is no IP precedence specified for IPv6. 3.8.1. Type-P . . .The value of Type-P-One-way-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP precedence or RSVP) changes. . . If precedence refers to Type of Service, which has been changed to DSCP mea= nwhile, then precedence should be changed to DSCP (and/or ECN codepoint) or= DS field. There is no IP precedence specified for IPv6. And the same comment also relates to draft-ietf-ippm-2680-bis-00: 2.6 Methodologies: As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence). If precedence refers to Type of Service, which has been changed to DSCP mea= nwhile, then precedence should be changed to DSCP (and/or ECN codepoint) or= DS field. There is no IP precedence specified for IPv6. 2.8.1 Type-P . . The value of Type-P-One-way-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP precedence or RSVP) changes... If precedence refers to Type of Service, which has been changed to DSCP mea= nwhile, then precedence should be changed to DSCP (and/or ECN codepoint) or= DS field. There is no IP precedence specified for IPv6. And one nit: 7. RFC 2680 bis ...9. No content. Otherwise my comment is go ahead with both drafts. Regards, Ruediger Von: ippm [mailto:ippm-bounces@ietf.org] Gesendet: Dienstag, 6. Januar 2015 16:52 An: ippm@ietf.org Betreff: [ippm] WGLC for draft-ietf-ippm-2679-bis-00 and draft-ietf-ippm-26= 80-bis-00 As discussed at the IETF meeting, drafts draft-ietf-ippm-2679-bis-00 (A One= -Way Delay Metric for IPPM) and draft-ietf-ippm-2680-bis-00 (A One-Way Loss= Metric for IPPM) are ready for Working Group Last Call (WGLC). As such, th= ese documents will be in WGLC until Friday, January 23, 2014. Please send comments to ippm@ietf.org, including stat= ements that you've reviewed the document and are okay with sending it up to= the IESG for publication. For those new to IETF process, the WGLC process is discussed at: - https://tools.ietf.org/html/rfc2418#section-7.4 - https://tools.ietf.org/html/rfc6174#section-4.2.7 Basic information on the documents is below. 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 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 Regards, Bill Cerveny IPPM WG Co-chair --_000_CA7A7C64CC4ADB458B74477EA99DF6F50439BD1A13HE111643EMEA1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bill, Al

 

thanks. = both drafts read good and I hope they will get RFC’s soon.=

 

I however missed one QoS rela= ted point during an earlier review I made:

 

3.6 Methodologies:

 

=A0= =A0 As with other Type-P-* metrics, the detailed methodology will depend

=A0=A0 on the Type-P (e.= g., protocol number, UDP/TCP port number, size,

=A0=A0 precedence).

 

If precedence refers to Type of Service, which has been c= hanged to DSCP meanwhile, then precedence should be changed to DSCP (and/or= ECN codepoint) or DS field. There is no IP precedence specified for IPv6.<= o:p>

 

3.8.1. Type-P

 

=A0=A0 =A0. . .The value of Type-P-One-way-Delay could chang= e if the

=A0=A0 protoc= ol (UDP or TCP), port number, size, or arrangement for special

=A0=A0 treatment (e.g., IP precede= nce or RSVP) changes. . .

 

If= precedence refers to Type of Service, which has been changed to DSCP meanw= hile, then precedence should be changed to DSCP (and/or ECN codepoint) or D= S field. There is no IP precedence specified for IPv6.

 

And the same comment also relates to dr= aft-ietf-ippm-2680-bis-00:

 

2.6 Methodologies:

 

=A0=A0 As with ot= her Type-P-* metrics, the detailed methodology will depend

=A0=A0 on the Type-P (e.g., protocol n= umber, UDP/TCP port number, size,

=A0=A0 precedence).

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Courier New";color= :#1F497D'> 

If precedence refers to Type of Service, which has been changed to DSCP= meanwhile, then precedence should be changed to DSCP (and/or ECN codepoint= ) or DS field. There is no IP precedence specified for IPv6.

 

2.8.1 Type-P

 

=A0=A0 . . The value of Type-P-One-way-Delay could change if the

=A0=A0 protocol (UDP or TCP), p= ort number, size, or arrangement for special

=A0=A0 treatment (e.g., IP precedence or RSVP) chan= ges...

 

If precede= nce refers to Type of Service, which has been changed to DSCP meanwhile, th= en precedence should be changed to DSCP (and/or ECN codepoint) or DS field.= There is no IP precedence specified for IPv6.

 

And one nit:=A0

 

7. RFC 2680 bis

 

&#= 8230;9.

 

No content= .

 =

Otherwise my comm= ent is go ahead with both drafts.

 

Regards,

 

Ruediger

&nb= sp;

 

 

Von: ippm [mailto:ippm-bounces@iet= f.org]

Gesendet: Dienstag, = 6. Januar 2015 16:52
An: ippm@ietf.org
Betreff: [ippm] = WGLC for draft-ietf-ippm-2679-bis-00 and draft-ietf-ippm-2680-bis-00

 

As discussed at the IETF meeting, drafts draft-ietf-ipp= m-2679-bis-00 (A One-Way Delay Metric for IPPM) and draft-ietf-ippm-2680-bi= s-00 (A One-Way Loss Metric for IPPM) are ready for Working Group Last Call= (WGLC). As such, these documents will be in WGLC until Friday, January 23,= 2014.

 

<= div>

Please send comments to ippm@ietf.org, including statements that you've reviewed th= e document and are okay with sending it up to the IESG for publication.&nbs= p;

 

For those new to IETF process, the WGLC process = is discussed at:

 

= Basic information on the documents is below.

 

 =      Title         =   : A One-Way Delay Metric for IPPM
    &n= bsp;  Authors         : G= uy Almes
          &nb= sp;            =   Sunil Kalidindi
       &n= bsp;            = ;     Matt Zekauskas
    &n= bsp;            = ;        Al Morton
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Filename  &= nbsp;     : draft-ietf-ippm-2679-bis-00.txt
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Pages &n= bsp;         : 24
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Date  &nb= sp;         : 2014-10-23
Abstract:
  This memo (RFC 2679 bis) defines a metric for on= e-way delay of
  packets across Internet paths.  It build= s on notions introduced and
  discussed in the IPPM Framework = document, RFC 2330; the reader is
  assumed to be familiar wit= h that document.



The IETF datatracker status page for this d= raft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-2679-bis/
<= br>There's also a htmlized version available at:
http://tools.ietf.org/html/draf= t-ietf-ippm-2679-bis-00

<= o:p> 

      &n= bsp;Title           : A O= ne-Way Loss Metric for IPPM
       Au= thors         : Guy Almes
 =             &nb= sp;           Sunil = Kalidindi
          &n= bsp;            = ;  Matt Zekauskas
       &n= bsp;            = ;     Al Morton
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Filename     &= nbsp;  : draft-ietf-ippm-2680-bis-00.txt
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Pages    &n= bsp;      : 19
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Date     &nb= sp;      : 2014-10-23

Abstract:
&nb= sp; This memo (RFC 2680 bis) defines a metric for one-way loss of pack= ets
  across Internet paths.  It builds on notions introd= uced 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://dat= atracker.ietf.org/doc/draft-ietf-ippm-2680-bis/

There's also a h= tmlized version available at:
http://tools.ietf.org/html/draft-ietf-ippm-2680-bi= s-00

 

Regards,

 

Bill Cerv= eny

IPPM WG Co-chair

= --_000_CA7A7C64CC4ADB458B74477EA99DF6F50439BD1A13HE111643EMEA1_-- From nobody Wed Jan 7 12:04:23 2015 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 DF6A91A1A4D; Wed, 7 Jan 2015 12:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 30dYnxcd4n7i; Wed, 7 Jan 2015 12:04:13 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA79C1A1AB2; Wed, 7 Jan 2015 12:04:10 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-96-54ad332cce37 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 88.50.25146.C233DA45; Wed, 7 Jan 2015 14:22:53 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0195.001; Wed, 7 Jan 2015 15:03:58 -0500 From: Steve Baillargeon To: "Romascanu, Dan (Dan)" , "MORTON, ALFRED C (AL)" , "ops-dir@ietf.org" , "ippm@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdAYe5l6zzPt7cY0Sz6o+JrRmzElOQAxhuiVACgMtpAABsHwBwACB4rAAC+P7poAAbFTYAAA3/rrAAE0nhAAAIMPkgAAsoIgAABx66sAAE9foAP2BUXw Date: Wed, 7 Jan 2015 20:03:58 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493901@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493909@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB00@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D8549390D@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB97@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493911@NJFPSRVEXG0.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA5C93CC13@AZ-FFEXMB03.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C93CC13@AZ-FFEXMB03.global.avaya.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPlK6u8doQg2vXBS22HpvIaLGxr4nF 4uvPH6wWPQ/eMVv0Ni1hdmD1eNk/h9Hj4Mo57B5Llvxk8vhy+TNbAEsUl01Kak5mWWqRvl0C V8a2X3cZC07/ZayYenwOSwPjnqOMXYycHBICJhJHG1dC2WISF+6tZ+ti5OIQEjjCKPF14X5m CGcZo8Sxrd9ZQKrYBCwk1s9dBpYQEVjOKHH15FImkASzQKbEwaef2UBsYQE7if5zW4EaOICK 7CVW9xuBhEUEmhglViwwAbFZBFQker9NASvnFfCV+N46nxVi2QV2iQmzb4CdxCkQIjH302Kw IkYBWYndZ69D7RKXuPVkPhPE2QISS/acZ4awRSVePv7HCmErSUxaeo4Vol5HYsHuT2wQtrbE soWvmSEWC0qcnPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcxAuPrmASb4w7G BZ8sDzEKcDAq8fBuMFgTIsSaWFZcmXuIUZqDRUmcV7N6XrCQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGxkX8PIaKjb5l+yqt705tvZ5b9Fjwyo/qA6Kafd8CbDuuvjgo/9mmQGxBdc4JTqeU BlPDLk6FO24Jr0rirRccWKJmKcd4zeN6okDk+82tf066KUnpLzt6t+9U/Nf1j7eJpao8SiyY nbsxY966FReNviqEC9x7YRGle3XhQ+2G/5pFjtuefmDMV2Ipzkg01GIuKk4EAF6+TLiQAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/iZi_zRqlOApqthQn76B2tapN21w Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 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, 07 Jan 2015 20:04:19 -0000 I don't why there is so much focus on asymmetrical packet sizes when packet= sizes may not matter at all or may cause the opposite effect i.e. other op= erational problems like rate measurement inaccuracy or packet processing ov= erload if small packets are used. Generating asymmetrical flow rates in different directions or even better, = controlling the flow rate in a given direction (as opposed to sending traff= ic at line rate or attempting to use as much as possible) is a lot more ope= rationally desirable. Steve B -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: December-18-14 10:50 AM To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 Indeed.=20 Thanks and Regards, Dan > -----Original Message----- > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > Sent: Thursday, December 18, 2014 5:41 PM > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Dan, >=20 > Thanks for your compromise. >=20 > On the topic of "increased" traffic: >=20 > This document introduces a RECOMMENDATION for test protocols to add=20 > the capability generate asymmetrical packet sizes in different=20 > directions, something that the current protocols cannot do (but they=20 > can certainly be used to make rate measurements now). >=20 > In fact, this asymmetric size feature REDUCES the test traffic load. > Perhaps you would like this mentioned as a desirable feature from an=20 > operations perspective? >=20 > regards, > Al >=20 > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Thursday, December 18, 2014 10:31 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >=20 > Hi Al, >=20 > I will not further insist on fine tuning the text this I-D, as I do=20 > not like keeping one document 'hostage' even for such important=20 > issues, when we came that close. >=20 > I believe that making the text more clear would have been useful, but=20 > we almost walked the extra mile with the inclusion of the new section,=20 > and that's fine by now. >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > Sent: Thursday, December 18, 2014 5:20 PM > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Dan, > > > > you wrote: > > The goal of this text is exactly to make sure and explicit that=20 > > operators engineer their management traffic load, > > including measurement-related traffic. > > > > The text does that now, adding new considerations. The audience of=20 > > this section are the operators. > > We now know the issue, potential for degradation. Do we need further=20 > > implementation guidance? > > I don't think so. > > > > If the root of your concern is the comparison between active and=20 > > passive, then you have many more factors to consider than traffic.=20 > > One is "What happens to forwarding capacity when I turn on NetFlow?" > > That's a question we helped operators try to answer in BMWG's RFC 6645= . > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > 3A__tools.ietf.org_html_rfc6645&d=3DAwIFAg&c=3DBFpWQw8bsuKpl1SgiZH64Q > > > &r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DgidqHsa1uFlRnPsB > > pwAmd1-VWq9YWDrVjyT2xjxFAm8&s=3D0UDbON- > > YV4jGVyt8H9aBb1kTlyJmt3bJSwfW-5FZwrM&e=3D > > > > regards, > > Al > > > > ________________________________________ > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > Sent: Thursday, December 18, 2014 10:00 AM > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > Hi Al, > > > > But this IS increased traffic, as standardized rate measurements=20 > > were not in practice until now, hence the need for new standards,=20 > > including the ones in IPPM. Yes, it's management traffic, but the=20 > > very issue an operational considerations sections aims is to draw=20 > > the attention that people that design an deploy new protocols need=20 > > to factor in the overall effects of new protocols traffic on the=20 > > networks. New protocols and methods to measure rate generate new=20 > > traffic, active measurement causes more new traffic than passive=20 > > methods, all this needs to be considered. The goal of this text is=20 > > exactly to make sure and explicit that operators engineer their=20 > > management traffic load, > including measurement-related traffic. > > > > Regards, > > > > Dan > > > > > > > -----Original Message----- > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > Sent: Thursday, December 18, 2014 4:34 PM > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Dan, > > > > > > When you added the sentence: > > > It is desirable that the increase load in the traffic levels in=20 > > > the live networks caused by the active measurement protocols > > > and by the management of the active measurement protocols does=20 > > > not lead to any significant degradation of the > > > quality of service of the applications running in the networks=20 > > > or the quality of experience of the users of the applications. > > > > > > You have continued to assume that the measurement traffic is=20 > > > excess traffic ("increased load") and it needs new requirements. =20 > > > As I said, one subscriber's traffic can degrade the traffic of=20 > > > another subscriber, whether the degradation is significant or not=20 > > > depends on too many factors to go into here, but one or both of=20 > > > the subscribers could be running tests related to this problem statem= ent. > > > Operators engineer their management traffic load, including > > > measurement- related traffic. > > > > > > There is simply traffic from many sources, all to be engineered. > > > Operations and Engineering as usual. > > > The section has provided specific cautions and guidance for=20 > > > operators and users. No need for new implementation rules, IMO. > > > > > > regards, > > > Al > > > ________________________________________ > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > Sent: Thursday, December 18, 2014 9:08 AM > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > Hi Al, > > > > > > We are getting close. Your suggested text seems almost=20 > > > appropriate, with two observations: > > > > > > - 'adequately served' is too vague and an explanation of what that=20 > > > means is needed > > > - I do not believe that we need a reference to RFC 3148. Again,=20 > > > the concern is not about the potential of security attacks (like=20 > > > DoS attacks mentioned in 3148). The intent is to warn well=20 > > > intentioned operators, SPs and end users of the potential dangers=20 > > > of not taking into consideration the effects of active methods,=20 > > > and recommend that they design and deploy accordingly > > > > > > Suggested edit to your proposal: > > > > > > OLD: > > > > > > 7. Operational Considerations > > > > > > All forms of testing originate traffic on the network, through=20 > > > their communications for control and results collection, or from=20 > > > dedicated measurement packet streams, or both. > > > Testing traffic primarily falls in one of two categories,=20 > > > subscriber traffic or network management traffic. > > > There is an on-going need to engineer networks so that various=20 > > > forms of traffic are adequately served, and publication of this=20 > > > memo does not change this need. > > > Service subscribers and authorized users SHOULD obtain their=20 > > > network operator's or service provider's permission before conducting= tests. > > > Likewise, a service provider or third party SHOULD obtain the=20 > > > subscriber's permission to conduct tests, since they might=20 > > > temporarily > > reduce service quality. > > > See section 4.1 of [RFC 3148]. > > > > > > Subscribers, their service providers and network operators, and=20 > > > sometimes third parties, all seek to measure network performance. > > > Capacity testing with active traffic often affects the packet=20 > > > transfer performance of streams traversing shared components of=20 > > > the test path, to some degree. The degradation can be minimized by=20 > > > scheduling such tests infrequently, and restricting the amount of=20 > > > measurement traffic required to assess capacity metrics. As a=20 > > > result, occasional short-duration estimates are preferred to=20 > > > measurements based on frequent file transfers of many Megabytes. > > > New measurement methodologies intended for standardization should > be > > > evaluated individually for potential operational issues. > > > However, the scheduled frequency of testing is as important as the=20 > > > methods used (and schedules are not typically submitted for > > standardization). > > > > > > NEW: > > > > > > 7. Operational Considerations > > > > > > All forms of testing originate traffic on the network, through=20 > > > their communications for control and results collection, or from=20 > > > dedicated measurement packet streams, or both. > > > Testing traffic primarily falls in one of two categories,=20 > > > subscriber traffic or network management traffic. > > > There is an on-going need to engineer networks so that various=20 > > > forms of traffic are adequately served, and publication of this=20 > > > memo does not change this need . It is desirable that the increase=20 > > > load in the traffic levels in the live networks caused by the=20 > > > active measurement protocols and by the management of the active=20 > > > measurement protocols does not lead to any significant degradation=20 > > > of the quality of service of the applications running in the=20 > > > networks or the quality of experience of > > the users of the applications. > > > Service subscribers and authorized users SHOULD obtain their=20 > > > network operator's or service provider's permission before conducting= tests. > > > Likewise, a service provider or third party SHOULD obtain the=20 > > > subscriber's permission to conduct tests, since they might=20 > > > temporarily > > reduce service quality. > > > > > > Subscribers, their service providers and network operators, and=20 > > > sometimes third parties, all seek to measure network performance. > > > Capacity testing with active traffic often affects the packet=20 > > > transfer performance of streams traversing shared components of=20 > > > the test path, to some degree. The degradation can be minimized by=20 > > > scheduling such tests infrequently, and restricting the amount of=20 > > > measurement traffic required to assess capacity metrics. As a=20 > > > result, occasional short-duration estimates are preferred to=20 > > > measurements based on frequent file transfers of many Megabytes. > > > New measurement methodologies intended for standardization should > be > > > evaluated individually for potential operational issues. > > > However, the scheduled frequency of testing is as important as the=20 > > > methods used (and schedules are not typically submitted for > > standardization). > > > > > > Regards, > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > Sent: Thursday, December 18, 2014 3:06 PM > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > > > > Hi Dan, > > > > > > > > I now see better where the disconnect is. You are looking for=20 > > > > new explicit statements about operational impact. But you are=20 > > > > assuming that the active measurement traffic is *excess*=20 > > > > traffic, beyond some normal level resulting from all Subscriber=20 > > > > traffic and an operator-chosen level of net management traffic. > > > > However, management traffic includes performance measurement > > traffic > > > > (when the traffic is originated by the operator), and Subscriber=20 > > > > traffic includes active measurement traffic (when originated by=20 > > > > the users). Test- related traffic needs to be engineered and=20 > > > > limited along with > > > all other traffic. > > > > > > > > Also, the requirement you wrote "does not lead to degradation" > > > > doesn't seem attainable, so we need to provide cautions through=20 > > > > other means. Sending a single packet results in larger queue=20 > > > > occupations all along its path =3D degradation. > > > > The packet could be for routing or other network management. > > > > > > > > The active measurement traffic is often launched by subscribers=20 > > > > or their authorized users, and there may well be some degree of=20 > > > > degradation to other subscriber's streams. > > > > Your proposed text recommends against this, yet it is no=20 > > > > different from the degradation caused by a user who chooses to=20 > > > > watch a video instead of testing (except that the video session may= be longer). > > > > > > > > Further, Service providers may be temporarily replacing an idle=20 > > > > user's traffic with active test traffic. Again there may be some=20 > > > > degradation to other subscribers, but it would typically be no=20 > > > > worse than from an additional user using their service. > > > > > > > > There is also the question of test frequency and overall performanc= e: > > > > a user may experience instantaneous packet delay or loss while=20 > > > > another subscriber tests their performance, but then the=20 > > > > performance is at nominal levels for long periods between tests=20 > > > > and the overall performance for a multi-hour session would be > satisfactory. > > > > > > > > It is clear to me that the operational issues primarily=20 > > > > addressed in previous IPPM work include the affects on other=20 > > > > traffic, the accuracy of the measurements (including=20 > > > > preferential treatment or spoofing of measured streams), and the=20 > > > > real or perceived existence of > > DoS attacks. > > > > Although these are not identified as operations issues, they are=20 > > > > certainly relevant in network operations where measurement has=20 > > > > become a growing part of the management portfolio. > > > > So, we should continue to cite the existing IPPM (and BMWG)=20 > > > > guidance on topics such as conservative measurement, and insert=20 > > > > the references I provided earlier into Section 3 (where you=20 > > > > cited the reference from > > > > RFC2680 > > > > - note the reference was to the sentence on high traffic rates,=20 > > > > ("too much > > > > traffic") so the phrase "trivial amounts of additional traffic" > > > > may be an inadequate specification, but it was not the intended=20 > > > > reference > > > material. > > > > > > > > This is the new section I propose: > > > > > > > > 7. Operational Considerations > > > > > > > > All forms of testing originate traffic on the network, through=20 > > > > their communications for control and results collection, or from=20 > > > > dedicated measurement packet streams, or both. > > > > Testing traffic primarily falls in one of two categories,=20 > > > > subscriber traffic or network management traffic. > > > > There is an on-going need to engineer networks so that various=20 > > > > forms of traffic are adequately served, and publication of this=20 > > > > memo does not change this need. > > > > Service subscribers and authorized users SHOULD obtain their=20 > > > > network operator's or service provider's permission before=20 > > > > conducting > tests. > > > > Likewise, a service provider or third party SHOULD obtain the=20 > > > > subscriber's permission to conduct tests, since they might=20 > > > > temporarily > > > reduce service quality. > > > > See section 4.1 of [RFC 3148]. > > > > > > > > Subscribers, their service providers and network operators, and=20 > > > > sometimes third parties, all seek to measure network performance. > > > > Capacity testing with active traffic often affects the packet=20 > > > > transfer performance of streams traversing shared components of=20 > > > > the test path, to some degree. The degradation can be minimized=20 > > > > by scheduling such tests infrequently, and restricting the=20 > > > > amount of measurement traffic required to assess capacity=20 > > > > metrics. As a result, occasional short-duration estimates are=20 > > > > preferred to measurements based on frequent file transfers of many = Megabytes. > > > > New measurement methodologies intended for standardization=20 > > > > should > > be > > > > evaluated individually for potential operational issues. > > > > However, the scheduled frequency of testing is as important as=20 > > > > the methods used (and schedules are not typically submitted for > > > standardization). > > > > > > > > > > > > ________________________________________ > > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > > Sent: Wednesday, December 17, 2014 9:34 AM > > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > Suggested edit: > > > > > > > > Insert section 7 after the Security considerations section with=20 > > > > the following text, and renumber the other sections accordingly: > > > > > > > > 7. Operational Considerations > > > > > > > > The increase in traffic levels caused by applying any active=20 > > > > measurement of live networks is a concern and needs to be=20 > > > > considered and controlled any time active measurements are=20 > > > > applied. It is RECOMMENDED that the increase load in the traffic=20 > > > > levels in the live networks caused by the active measurement=20 > > > > protocols and by the management of the active measurement=20 > > > > protocols does not lead to a degradation of the quality of=20 > > > > service of the applications running in the networks or the=20 > > > > quality of experience of the users of the > > applications. > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > > Sent: Wednesday, December 17, 2014 3:39 PM > > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > > Hi Dan, > > > > > > > > > > I did not say that the operational implications would not be=20 > > > > > dealt with > > > here. > > > > > > > > > > I'm simply saying that IPPM drafts have done as you have asked=20 > > > > > many times already, that is discuss the implications of active=20 > > > > > measurements, and that we would not repeat that guidance (but=20 > > > > > include four references below). Also, that the measurement=20 > > > > > methods would each be vetted on their own, when proposed for > > standardization. > > > > > You need both methods and control/test protocol, and the=20 > > > > > method solutions for this problem are out of scope. > > > > > > > > > > For example, the model-based metrics draft in IPPM introduces=20 > > > > > the notion of a target rate, which is a good thing, because it=20 > > > > > means that the test stream will have an upper bound. > > > > > But that is an operational evaluation of a specific method,=20 > > > > > and OOS for the problem statement. > > > > > > > > > > Is this approach more clear? If not, please suggest some text. > > > > > > > > > > regards, > > > > > Al > > > > > ________________________________________ > > > > > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > > > > > Sent: Wednesday, December 17, 2014 5:25 AM > > > > > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > > > > > > > > > Hi Al, > > > > > > > > > > I kind of disagree that dealing with the operational=20 > > > > > implications of applying active testing should not be=20 > > > > > mentioned in the problem statement, but only when specific=20 > > > > > measurement methods are > > described. > > > > > The problem statement document explicitly describes active=20 > > > > > rate management and includes a section of requirements for=20 > > > > > test protocol control and generation. I believe that the=20 > > > > > operational aspects of generating traffic in production=20 > > > > > networks should be part of the problem statement, and=20 > > > > > explicitly mentioned, not only in the context of > > > > altering measurement results or security considerations. > > > > > > > > > > Regards, > > > > > > > > > > Dan > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > > > > > > Sent: Tuesday, December 16, 2014 5:05 PM > > > > > > To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org > > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > > Subject: RE: OPS-DIR review of=20 > > > > > > draft-ietf-ippm-rate-problem-08 > > > > > > > > > > > > Hi Dan, > > > > > > > > > > > > Thanks for your review. Perhaps we can close this quickly=20 > > > > > > before we both disappear for the holidays (officially, I'm=20 > > > > > > already gone and writing from Chicago, where it is=20 > > > > > > unseasonably > warm). > > > > > > > > > > > > We can certainly add details on the operational impact that=20 > > > > > > test protocols conforming to this memo's problem statement=20 > > > > > > might > cause. > > > > > > This has been a point of issue since the earliest days of=20 > > > > > > IPPM, so we should be able to cover the topic by introducing=20 > > > > > > several > > references. > > > > > > > > > > > > If there is some additional point we can cover here, keeping=20 > > > > > > in mind that measurement methods are a non-goal of this=20 > > > > > > draft and the operational impact of specific methods are=20 > > > > > > best dealt with when such methods are specified, please=20 > > > > > > provide your > thoughts. > > > > > > > > > > > > regards, > > > > > > Al > > > > > > > > > > > > The IPPM Framework RFC 2330, section 11.1, says > > > > > > > > > > > > + The act of measurement can perturb what is being=20 > > > > > > + measured (for > > > > > > example, injecting measurement traffic into a network alt= ers the > > > > > > congestion level of the network), and repeated periodic > > > > > > perturbations can drive a network into a state of synchro= nization > > > > > > (cf. [FJ94]), greatly magnifying what might individually = be minor > > > > > > effects. > > > > > > > > > > > > And also, RFC 2330 adopts the term "conservative" for > measurement > > > > > > methodologies for which:, > > > > > > > > > > > > "... the act of measurement does not modify, or only slightl= y > > > > > > modifies, the value of the performance metric the methodolog= y > > > > > > attempts to measure." > > > > > > > > > > > > However, the constraint that measurements strictly retain=20 > > > > > > the conservative property is updated in RFC 7312 > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > > > > > 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=3DAAIF- > > > > > > > > > > > > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > > > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3DpGbP1qC4qqZh21gJkoiKs > > > > > > BmrE3lDnv8ulVOvmjOAlY0&e=3D > > > > > > > > > > > > It should be noted that this definition of "conservative" in= the > > > > > > sense of [RFC2330] depends to a large extent on the > measurement > > > > > > path's technology and characteristics. In particular,=20 > > > > > > when > deployed > > > > > > on reactive paths, subpaths, links or hosts conforming to th= e > > > > > > definition in Section 1.1 of RFC 7312, measurement packets c= an > > > > > > originate capacity (re)allocations. In addition, small meas= urement > > > > > > flow variations can result in other users on the same=20 > > > > > > path > perceiving > > > > > > significant variations in measurement results. Therefore: > > > > > > > > > > > > It is not always possible for the method to be conservati= ve. > > > > > > > > > > > > And, on modern networks with reactive components, any=20 > > > > > > traffic level will have some impact on other users. =20 > > > > > > Therefore, metrics and their measurement methods should be=20 > > > > > > vetted by the industry SDOs. To make this point clear, we=20 > > > > > > should cite BMWG RFC (2455 considered harmful on production=20 > > > > > > networks), which covers the topic in Section 6 > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > > > > > 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=3DAAIF- > > > > > > > > > > > > > > > > > > > > > g&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd > > > > > > rphpBsFA&m=3DN8q- > > > > > > > > > > > > > > > > > > > > > hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=3D5fEqW5JnBgSuJYNRNSJS > > > > > > mwfu04Mp6cQTBkG_aQNT6qU&e=3D > > > > > > and says: > > > > > > > > > > > > ...There are no specific methods proposed for > > > > > > activation of a packet transfer service in IPPM at this time= . Thus, > > > > > > individuals who need to conduct capacity tests on=20 > > > > > > production > > > networks > > > > > > should actively participate in standards development to=20 > > > > > > ensure > their > > > > > > methods receive appropriate industry review and=20 > > > > > > agreement, in > the > > > > > > IETF or in alternate standards development organizations. > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of=20 > > > > > > Romascanu, Dan > > > > > > (Dan) [dromasca@avaya.com] > > > > > > Sent: Monday, December 15, 2014 10:27 AM > > > > > > To: ops-dir@ietf.org; ippm@ietf.org > > > > > > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > > > > > > Subject: [OPS-DIR] OPS-DIR review of > > > > > > draft-ietf-ippm-rate-problem-08 > > > > > > > > > > > > I have reviewed this document as part of the Operational=20 > > > > > > directorate's ongoing effort to review all IETF documents=20 > > > > > > being processed > > > > by the IESG. > > > > > > These comments were written primarily for the benefit of the=20 > > > > > > operational area directors. > > > > > > Document editors and WG chairs should treat these comments=20 > > > > > > just like any other last call comments. > > > > > > > > > > > > Ready with one issue > > > > > > > > > > > > This I-D is an informational document that does not define a=20 > > > > > > new protocol or protocol extensions. It does however contain=20 > > > > > > a problem statement for test protocols conducting access=20 > > > > > > rate measurement in > > > > > productions networks. > > > > > > These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357)=20 > > > > > > but > > > > also > > > > > > non-IETF protocols. The following operational considerations=20 > > > > > > in Appendix A.1 of RFC 5706 apply, I believe, and do not=20 > > > > > > receive appropriate answers in the > > > > > > document: > > > > > > > > > > > > 5. Has the impact on network operation been discussed? See=20 > > > > > > Section > > > 2.5. > > > > > > * Will the new protocol significantly increase traffic load=20 > > > > > > on existing networks? > > > > > > * Will the proposed management for the new protocol=20 > > > > > > significantly increase traffic load on existing networks? > > > > > > * How will the new protocol impact the behavior of other=20 > > > > > > protocols in the network? Will it impact performance (e.g., > > > > > > jitter) of certain types of applications running in the same ne= twork? > > > > > > > > > > > > I believe that at least a reference to these aspects need to=20 > > > > > > be included, especially as the In-Service testing with=20 > > > > > > injection of active traffic on production network is one of=20 > > > > > > the methods discussed by > > > > > the document. > > > > > > > > > > > > The following reference to the effects of the high level=20 > > > > > > traffic is not sufficient > > > > > > IMO: > > > > > > > > > > > > > > > > > > ? Section 5 of [RFC2680] lists the problems with high > > > > > > measurement traffic rates, and the most relevant for rate=20 > > > > > > measurement > > > > > > > > > > > > ? is the tendency for measurement traffic to skew the=20 > > > > > > results, > > followed > > > > > > by the possibility of introducing congestion on the access l= ink. In- > > > > > > Service testing MUST respect these traffic constraints. Obv= iously, > > > > > > categories of rate measurement methods that use less active = test > > > > > > traffic than others with similar accuracy are preferred for = In- > > > > > > Service testing. > > > > > > > > > > > > Section 5 of RFC2680 does not provide too many details as I=20 > > > > > > was expecting. It actually deals with traffic injection as=20 > > > > > > with a security > > > concern: > > > > > > > > > > > > > > > > > > ? There are two types of security concerns: potential harm=20 > > > > > > caused by > > > > > > > > > > > > ? the measurements, and potential harm to the measurements. > The > > > > > > > > > > > > ? measurements could cause harm because they are active, and > > inject > > > > > > > > > > > > ? packets into the network. The measurement parameters MUST > be > > > > > > > > > > > > ? carefully selected so that the measurements inject trivial > amounts > > of > > > > > > > > > > > > ? additional traffic into the networks they measure. If they = inject > > > > > > > > > > > > ? "too much" traffic, they can skew the results of the > measurement, > > > > and > > > > > > > > > > > > ? in extreme cases cause congestion and denial of service. > > > > > > > > > > > > ? > > > > > > 'trivial amounts of additional traffic' is too vague - I=20 > > > > > > believe that more clear text that deals with the issue as=20 > > > > > > with an operational issue, and makes clear that degradation=20 > > > > > > of service for users is not acceptable if In-Service testing=20 > > > > > > policies are applied would be > > > > welcome. > > > > > > > > > > > > I hope this helps. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Dan _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Thu Jan 8 00:47:47 2015 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 95E7A1A8971; Thu, 8 Jan 2015 00:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.041 X-Spam-Level: X-Spam-Status: No, score=-3.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_MED=-2.3, 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 rhz-30U8S9Lc; Thu, 8 Jan 2015 00:47:39 -0800 (PST) Received: from mail1.zserv.tuwien.ac.at (mail1.zserv.tuwien.ac.at [128.130.35.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5F01A8989; Thu, 8 Jan 2015 00:47:35 -0800 (PST) Received: from [128.131.67.239] (jason.nt.tuwien.ac.at [128.131.67.239]) (authenticated bits=0) by mail1.zserv.tuwien.ac.at (8.13.8/8.13.8) with ESMTP id t088lLog015714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 8 Jan 2015 09:47:21 +0100 Message-ID: <54AE4415.2020509@tuwien.ac.at> Date: Thu, 08 Jan 2015 09:47:17 +0100 From: Joachim Fabini User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Steve Baillargeon , "Romascanu, Dan (Dan)" , "MORTON, ALFRED C (AL)" , "ops-dir@ietf.org" , "ippm@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493909@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB00@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D8549390D@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB97@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493911@NJFPSRVEXG0.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA5C93CC13@AZ-FFEXMB03.global.avaya.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/Zun7cr7Huge3INtoCBcnanbc5z8 Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 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: Thu, 08 Jan 2015 08:47:45 -0000 Steve, you wrote that packet size _may_ not matter. But it does in practice. The decision what is operationally desirable depends on the measurement objective _and_ on the network technology. And the latter is the factor that makes packet size matter. For symmetrical core network paths the flow rate adaption that you propose may work as functional equivalent to asymmetrical packet size. But the closer one gets to the (predominantly asymmetrical) network access, the more important becomes the capability to use asymmetrical packet sizes. First, there is a need to accurately emulate the behavior of request-reply messaging patterns, where requests and replies differ substantially in size. Be it SIP, HTTP, FTP, SMTP, whatever: it's a fact that the request-reply asymmetry is there and that it is substantial. Second, and my main concern is the testing and monitoring of networks with on-demand capacity allocation. Here, the network behavior depends on the exact stream structure (packet size and timing) rather than on the average stream flow rate. Just one example: depending on your RRC state, cellular network schedulers may allocate dedicated channels for transfer of a large packet, whereas a series of small packets could even reuse existing signaling bearers. Depending on network technology, configuration and the exact stream (packet size plus inter-packet delay), the network response may be completly different - at identical stream rate. We had many discussion on the IPPM list and I felt that there was consensus that we need this feature. So, my summary: there IS an effective need for asymmetrical packet size as we have cases that we can not overcome with flow rate. That's why I request and support the asymmetrical packet size feature. regards Joachim Steve Baillargeon wrote: (07.01.2015 21:03) > I don't why there is so much focus on asymmetrical packet sizes when packet sizes may not matter at all or may cause the opposite effect i.e. other operational problems like rate measurement inaccuracy or packet processing overload if small packets are used. > Generating asymmetrical flow rates in different directions or even better, controlling the flow rate in a given direction (as opposed to sending traffic at line rate or attempting to use as much as possible) is a lot more operationally desirable. > > Steve B > > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: December-18-14 10:50 AM > To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org > Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org > Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 > > Indeed. > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] >> Sent: Thursday, December 18, 2014 5:41 PM >> To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org >> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >> >> Hi Dan, >> >> Thanks for your compromise. >> >> On the topic of "increased" traffic: >> >> This document introduces a RECOMMENDATION for test protocols to add >> the capability generate asymmetrical packet sizes in different >> directions, something that the current protocols cannot do (but they >> can certainly be used to make rate measurements now). >> >> In fact, this asymmetric size feature REDUCES the test traffic load. >> Perhaps you would like this mentioned as a desirable feature from an >> operations perspective? >> >> regards, >> Al >> >> ________________________________________ >> From: Romascanu, Dan (Dan) [dromasca@avaya.com] >> Sent: Thursday, December 18, 2014 10:31 AM >> To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org >> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >> >> Hi Al, >> >> I will not further insist on fine tuning the text this I-D, as I do >> not like keeping one document 'hostage' even for such important >> issues, when we came that close. >> >> I believe that making the text more clear would have been useful, but >> we almost walked the extra mile with the inclusion of the new section, >> and that's fine by now. >> >> Regards, >> >> Dan >> >> >>> -----Original Message----- >>> From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] >>> Sent: Thursday, December 18, 2014 5:20 PM >>> To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org >>> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >>> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >>> >>> Hi Dan, >>> >>> you wrote: >>> The goal of this text is exactly to make sure and explicit that >>> operators engineer their management traffic load, >>> including measurement-related traffic. >>> >>> The text does that now, adding new considerations. The audience of >>> this section are the operators. >>> We now know the issue, potential for degradation. Do we need further >>> implementation guidance? >>> I don't think so. >>> >>> If the root of your concern is the comparison between active and >>> passive, then you have many more factors to consider than traffic. >>> One is "What happens to forwarding capacity when I turn on NetFlow?" >>> That's a question we helped operators try to answer in BMWG's RFC 6645. >>> https://urldefense.proofpoint.com/v2/url?u=http- >>> >> 3A__tools.ietf.org_html_rfc6645&d=AwIFAg&c=BFpWQw8bsuKpl1SgiZH64Q >>> >> &r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=gidqHsa1uFlRnPsB >>> pwAmd1-VWq9YWDrVjyT2xjxFAm8&s=0UDbON- >>> YV4jGVyt8H9aBb1kTlyJmt3bJSwfW-5FZwrM&e= >>> >>> regards, >>> Al >>> >>> ________________________________________ >>> From: Romascanu, Dan (Dan) [dromasca@avaya.com] >>> Sent: Thursday, December 18, 2014 10:00 AM >>> To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org >>> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >>> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >>> >>> Hi Al, >>> >>> But this IS increased traffic, as standardized rate measurements >>> were not in practice until now, hence the need for new standards, >>> including the ones in IPPM. Yes, it's management traffic, but the >>> very issue an operational considerations sections aims is to draw >>> the attention that people that design an deploy new protocols need >>> to factor in the overall effects of new protocols traffic on the >>> networks. New protocols and methods to measure rate generate new >>> traffic, active measurement causes more new traffic than passive >>> methods, all this needs to be considered. The goal of this text is >>> exactly to make sure and explicit that operators engineer their >>> management traffic load, >> including measurement-related traffic. >>> >>> Regards, >>> >>> Dan >>> >>> >>>> -----Original Message----- >>>> From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] >>>> Sent: Thursday, December 18, 2014 4:34 PM >>>> To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org >>>> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >>>> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >>>> >>>> Hi Dan, >>>> >>>> When you added the sentence: >>>> It is desirable that the increase load in the traffic levels in >>>> the live networks caused by the active measurement protocols >>>> and by the management of the active measurement protocols does >>>> not lead to any significant degradation of the >>>> quality of service of the applications running in the networks >>>> or the quality of experience of the users of the applications. >>>> >>>> You have continued to assume that the measurement traffic is >>>> excess traffic ("increased load") and it needs new requirements. >>>> As I said, one subscriber's traffic can degrade the traffic of >>>> another subscriber, whether the degradation is significant or not >>>> depends on too many factors to go into here, but one or both of >>>> the subscribers could be running tests related to this problem statement. >>>> Operators engineer their management traffic load, including >>>> measurement- related traffic. >>>> >>>> There is simply traffic from many sources, all to be engineered. >>>> Operations and Engineering as usual. >>>> The section has provided specific cautions and guidance for >>>> operators and users. No need for new implementation rules, IMO. >>>> >>>> regards, >>>> Al >>>> ________________________________________ >>>> From: Romascanu, Dan (Dan) [dromasca@avaya.com] >>>> Sent: Thursday, December 18, 2014 9:08 AM >>>> To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org >>>> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >>>> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >>>> >>>> Hi Al, >>>> >>>> We are getting close. Your suggested text seems almost >>>> appropriate, with two observations: >>>> >>>> - 'adequately served' is too vague and an explanation of what that >>>> means is needed >>>> - I do not believe that we need a reference to RFC 3148. Again, >>>> the concern is not about the potential of security attacks (like >>>> DoS attacks mentioned in 3148). The intent is to warn well >>>> intentioned operators, SPs and end users of the potential dangers >>>> of not taking into consideration the effects of active methods, >>>> and recommend that they design and deploy accordingly >>>> >>>> Suggested edit to your proposal: >>>> >>>> OLD: >>>> >>>> 7. Operational Considerations >>>> >>>> All forms of testing originate traffic on the network, through >>>> their communications for control and results collection, or from >>>> dedicated measurement packet streams, or both. >>>> Testing traffic primarily falls in one of two categories, >>>> subscriber traffic or network management traffic. >>>> There is an on-going need to engineer networks so that various >>>> forms of traffic are adequately served, and publication of this >>>> memo does not change this need. >>>> Service subscribers and authorized users SHOULD obtain their >>>> network operator's or service provider's permission before conducting tests. >>>> Likewise, a service provider or third party SHOULD obtain the >>>> subscriber's permission to conduct tests, since they might >>>> temporarily >>> reduce service quality. >>>> See section 4.1 of [RFC 3148]. >>>> >>>> Subscribers, their service providers and network operators, and >>>> sometimes third parties, all seek to measure network performance. >>>> Capacity testing with active traffic often affects the packet >>>> transfer performance of streams traversing shared components of >>>> the test path, to some degree. The degradation can be minimized by >>>> scheduling such tests infrequently, and restricting the amount of >>>> measurement traffic required to assess capacity metrics. As a >>>> result, occasional short-duration estimates are preferred to >>>> measurements based on frequent file transfers of many Megabytes. >>>> New measurement methodologies intended for standardization should >> be >>>> evaluated individually for potential operational issues. >>>> However, the scheduled frequency of testing is as important as the >>>> methods used (and schedules are not typically submitted for >>> standardization). >>>> >>>> NEW: >>>> >>>> 7. Operational Considerations >>>> >>>> All forms of testing originate traffic on the network, through >>>> their communications for control and results collection, or from >>>> dedicated measurement packet streams, or both. >>>> Testing traffic primarily falls in one of two categories, >>>> subscriber traffic or network management traffic. >>>> There is an on-going need to engineer networks so that various >>>> forms of traffic are adequately served, and publication of this >>>> memo does not change this need . It is desirable that the increase >>>> load in the traffic levels in the live networks caused by the >>>> active measurement protocols and by the management of the active >>>> measurement protocols does not lead to any significant degradation >>>> of the quality of service of the applications running in the >>>> networks or the quality of experience of >>> the users of the applications. >>>> Service subscribers and authorized users SHOULD obtain their >>>> network operator's or service provider's permission before conducting tests. >>>> Likewise, a service provider or third party SHOULD obtain the >>>> subscriber's permission to conduct tests, since they might >>>> temporarily >>> reduce service quality. >>>> >>>> Subscribers, their service providers and network operators, and >>>> sometimes third parties, all seek to measure network performance. >>>> Capacity testing with active traffic often affects the packet >>>> transfer performance of streams traversing shared components of >>>> the test path, to some degree. The degradation can be minimized by >>>> scheduling such tests infrequently, and restricting the amount of >>>> measurement traffic required to assess capacity metrics. As a >>>> result, occasional short-duration estimates are preferred to >>>> measurements based on frequent file transfers of many Megabytes. >>>> New measurement methodologies intended for standardization should >> be >>>> evaluated individually for potential operational issues. >>>> However, the scheduled frequency of testing is as important as the >>>> methods used (and schedules are not typically submitted for >>> standardization). >>>> >>>> Regards, >>>> >>>> Dan >>>> >>>> >>>>> -----Original Message----- >>>>> From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] >>>>> Sent: Thursday, December 18, 2014 3:06 PM >>>>> To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org >>>>> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >>>>> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >>>>> >>>>> >>>>> Hi Dan, >>>>> >>>>> I now see better where the disconnect is. You are looking for >>>>> new explicit statements about operational impact. But you are >>>>> assuming that the active measurement traffic is *excess* >>>>> traffic, beyond some normal level resulting from all Subscriber >>>>> traffic and an operator-chosen level of net management traffic. >>>>> However, management traffic includes performance measurement >>> traffic >>>>> (when the traffic is originated by the operator), and Subscriber >>>>> traffic includes active measurement traffic (when originated by >>>>> the users). Test- related traffic needs to be engineered and >>>>> limited along with >>>> all other traffic. >>>>> >>>>> Also, the requirement you wrote "does not lead to degradation" >>>>> doesn't seem attainable, so we need to provide cautions through >>>>> other means. Sending a single packet results in larger queue >>>>> occupations all along its path = degradation. >>>>> The packet could be for routing or other network management. >>>>> >>>>> The active measurement traffic is often launched by subscribers >>>>> or their authorized users, and there may well be some degree of >>>>> degradation to other subscriber's streams. >>>>> Your proposed text recommends against this, yet it is no >>>>> different from the degradation caused by a user who chooses to >>>>> watch a video instead of testing (except that the video session may be longer). >>>>> >>>>> Further, Service providers may be temporarily replacing an idle >>>>> user's traffic with active test traffic. Again there may be some >>>>> degradation to other subscribers, but it would typically be no >>>>> worse than from an additional user using their service. >>>>> >>>>> There is also the question of test frequency and overall performance: >>>>> a user may experience instantaneous packet delay or loss while >>>>> another subscriber tests their performance, but then the >>>>> performance is at nominal levels for long periods between tests >>>>> and the overall performance for a multi-hour session would be >> satisfactory. >>>>> >>>>> It is clear to me that the operational issues primarily >>>>> addressed in previous IPPM work include the affects on other >>>>> traffic, the accuracy of the measurements (including >>>>> preferential treatment or spoofing of measured streams), and the >>>>> real or perceived existence of >>> DoS attacks. >>>>> Although these are not identified as operations issues, they are >>>>> certainly relevant in network operations where measurement has >>>>> become a growing part of the management portfolio. >>>>> So, we should continue to cite the existing IPPM (and BMWG) >>>>> guidance on topics such as conservative measurement, and insert >>>>> the references I provided earlier into Section 3 (where you >>>>> cited the reference from >>>>> RFC2680 >>>>> - note the reference was to the sentence on high traffic rates, >>>>> ("too much >>>>> traffic") so the phrase "trivial amounts of additional traffic" >>>>> may be an inadequate specification, but it was not the intended >>>>> reference >>>> material. >>>>> >>>>> This is the new section I propose: >>>>> >>>>> 7. Operational Considerations >>>>> >>>>> All forms of testing originate traffic on the network, through >>>>> their communications for control and results collection, or from >>>>> dedicated measurement packet streams, or both. >>>>> Testing traffic primarily falls in one of two categories, >>>>> subscriber traffic or network management traffic. >>>>> There is an on-going need to engineer networks so that various >>>>> forms of traffic are adequately served, and publication of this >>>>> memo does not change this need. >>>>> Service subscribers and authorized users SHOULD obtain their >>>>> network operator's or service provider's permission before >>>>> conducting >> tests. >>>>> Likewise, a service provider or third party SHOULD obtain the >>>>> subscriber's permission to conduct tests, since they might >>>>> temporarily >>>> reduce service quality. >>>>> See section 4.1 of [RFC 3148]. >>>>> >>>>> Subscribers, their service providers and network operators, and >>>>> sometimes third parties, all seek to measure network performance. >>>>> Capacity testing with active traffic often affects the packet >>>>> transfer performance of streams traversing shared components of >>>>> the test path, to some degree. The degradation can be minimized >>>>> by scheduling such tests infrequently, and restricting the >>>>> amount of measurement traffic required to assess capacity >>>>> metrics. As a result, occasional short-duration estimates are >>>>> preferred to measurements based on frequent file transfers of many Megabytes. >>>>> New measurement methodologies intended for standardization >>>>> should >>> be >>>>> evaluated individually for potential operational issues. >>>>> However, the scheduled frequency of testing is as important as >>>>> the methods used (and schedules are not typically submitted for >>>> standardization). >>>>> >>>>> >>>>> ________________________________________ >>>>> From: Romascanu, Dan (Dan) [dromasca@avaya.com] >>>>> Sent: Wednesday, December 17, 2014 9:34 AM >>>>> To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org >>>>> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >>>>> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >>>>> >>>>> Suggested edit: >>>>> >>>>> Insert section 7 after the Security considerations section with >>>>> the following text, and renumber the other sections accordingly: >>>>> >>>>> 7. Operational Considerations >>>>> >>>>> The increase in traffic levels caused by applying any active >>>>> measurement of live networks is a concern and needs to be >>>>> considered and controlled any time active measurements are >>>>> applied. It is RECOMMENDED that the increase load in the traffic >>>>> levels in the live networks caused by the active measurement >>>>> protocols and by the management of the active measurement >>>>> protocols does not lead to a degradation of the quality of >>>>> service of the applications running in the networks or the >>>>> quality of experience of the users of the >>> applications. >>>>> >>>>> Regards, >>>>> >>>>> Dan >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] >>>>>> Sent: Wednesday, December 17, 2014 3:39 PM >>>>>> To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org >>>>>> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >>>>>> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >>>>>> >>>>>> Hi Dan, >>>>>> >>>>>> I did not say that the operational implications would not be >>>>>> dealt with >>>> here. >>>>>> >>>>>> I'm simply saying that IPPM drafts have done as you have asked >>>>>> many times already, that is discuss the implications of active >>>>>> measurements, and that we would not repeat that guidance (but >>>>>> include four references below). Also, that the measurement >>>>>> methods would each be vetted on their own, when proposed for >>> standardization. >>>>>> You need both methods and control/test protocol, and the >>>>>> method solutions for this problem are out of scope. >>>>>> >>>>>> For example, the model-based metrics draft in IPPM introduces >>>>>> the notion of a target rate, which is a good thing, because it >>>>>> means that the test stream will have an upper bound. >>>>>> But that is an operational evaluation of a specific method, >>>>>> and OOS for the problem statement. >>>>>> >>>>>> Is this approach more clear? If not, please suggest some text. >>>>>> >>>>>> regards, >>>>>> Al >>>>>> ________________________________________ >>>>>> From: Romascanu, Dan (Dan) [dromasca@avaya.com] >>>>>> Sent: Wednesday, December 17, 2014 5:25 AM >>>>>> To: MORTON, ALFRED C (AL); ops-dir@ietf.org; ippm@ietf.org >>>>>> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >>>>>> Subject: RE: OPS-DIR review of draft-ietf-ippm-rate-problem-08 >>>>>> >>>>>> Hi Al, >>>>>> >>>>>> I kind of disagree that dealing with the operational >>>>>> implications of applying active testing should not be >>>>>> mentioned in the problem statement, but only when specific >>>>>> measurement methods are >>> described. >>>>>> The problem statement document explicitly describes active >>>>>> rate management and includes a section of requirements for >>>>>> test protocol control and generation. I believe that the >>>>>> operational aspects of generating traffic in production >>>>>> networks should be part of the problem statement, and >>>>>> explicitly mentioned, not only in the context of >>>>> altering measurement results or security considerations. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] >>>>>>> Sent: Tuesday, December 16, 2014 5:05 PM >>>>>>> To: Romascanu, Dan (Dan); ops-dir@ietf.org; ippm@ietf.org >>>>>>> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >>>>>>> Subject: RE: OPS-DIR review of >>>>>>> draft-ietf-ippm-rate-problem-08 >>>>>>> >>>>>>> Hi Dan, >>>>>>> >>>>>>> Thanks for your review. Perhaps we can close this quickly >>>>>>> before we both disappear for the holidays (officially, I'm >>>>>>> already gone and writing from Chicago, where it is >>>>>>> unseasonably >> warm). >>>>>>> >>>>>>> We can certainly add details on the operational impact that >>>>>>> test protocols conforming to this memo's problem statement >>>>>>> might >> cause. >>>>>>> This has been a point of issue since the earliest days of >>>>>>> IPPM, so we should be able to cover the topic by introducing >>>>>>> several >>> references. >>>>>>> >>>>>>> If there is some additional point we can cover here, keeping >>>>>>> in mind that measurement methods are a non-goal of this >>>>>>> draft and the operational impact of specific methods are >>>>>>> best dealt with when such methods are specified, please >>>>>>> provide your >> thoughts. >>>>>>> >>>>>>> regards, >>>>>>> Al >>>>>>> >>>>>>> The IPPM Framework RFC 2330, section 11.1, says >>>>>>> >>>>>>> + The act of measurement can perturb what is being >>>>>>> + measured (for >>>>>>> example, injecting measurement traffic into a network alters the >>>>>>> congestion level of the network), and repeated periodic >>>>>>> perturbations can drive a network into a state of synchronization >>>>>>> (cf. [FJ94]), greatly magnifying what might individually be minor >>>>>>> effects. >>>>>>> >>>>>>> And also, RFC 2330 adopts the term "conservative" for >> measurement >>>>>>> methodologies for which:, >>>>>>> >>>>>>> "... the act of measurement does not modify, or only slightly >>>>>>> modifies, the value of the performance metric the methodology >>>>>>> attempts to measure." >>>>>>> >>>>>>> However, the constraint that measurements strictly retain >>>>>>> the conservative property is updated in RFC 7312 >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https- >>>>>>> 3A__tools.ietf.org_html_rfc7312-23section-2D4.4&d=AAIF- >>>>>>> >>>>>> >>>>> >>>> >>> >> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd >>>>>>> rphpBsFA&m=N8q- >>>>>>> >>>>>> >>>>> >>>> >>> >> hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=pGbP1qC4qqZh21gJkoiKs >>>>>>> BmrE3lDnv8ulVOvmjOAlY0&e= >>>>>>> >>>>>>> It should be noted that this definition of "conservative" in the >>>>>>> sense of [RFC2330] depends to a large extent on the >> measurement >>>>>>> path's technology and characteristics. In particular, >>>>>>> when >> deployed >>>>>>> on reactive paths, subpaths, links or hosts conforming to the >>>>>>> definition in Section 1.1 of RFC 7312, measurement packets can >>>>>>> originate capacity (re)allocations. In addition, small measurement >>>>>>> flow variations can result in other users on the same >>>>>>> path >> perceiving >>>>>>> significant variations in measurement results. Therefore: >>>>>>> >>>>>>> It is not always possible for the method to be conservative. >>>>>>> >>>>>>> And, on modern networks with reactive components, any >>>>>>> traffic level will have some impact on other users. >>>>>>> Therefore, metrics and their measurement methods should be >>>>>>> vetted by the industry SDOs. To make this point clear, we >>>>>>> should cite BMWG RFC (2455 considered harmful on production >>>>>>> networks), which covers the topic in Section 6 >>>>>>> https://urldefense.proofpoint.com/v2/url?u=http- >>>>>>> 3A__tools.ietf.org_html_rfc6815-23section-2D6&d=AAIF- >>>>>>> >>>>>> >>>>> >>>> >>> >> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvd >>>>>>> rphpBsFA&m=N8q- >>>>>>> >>>>>> >>>>> >>>> >>> >> hc4HbRszDQlImZQ_Tenl1mVdgb9ss1bTj9HzKew&s=5fEqW5JnBgSuJYNRNSJS >>>>>>> mwfu04Mp6cQTBkG_aQNT6qU&e= >>>>>>> and says: >>>>>>> >>>>>>> ...There are no specific methods proposed for >>>>>>> activation of a packet transfer service in IPPM at this time. Thus, >>>>>>> individuals who need to conduct capacity tests on >>>>>>> production >>>> networks >>>>>>> should actively participate in standards development to >>>>>>> ensure >> their >>>>>>> methods receive appropriate industry review and >>>>>>> agreement, in >> the >>>>>>> IETF or in alternate standards development organizations. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: OPS-DIR [ops-dir-bounces@ietf.org] On Behalf Of >>>>>>> Romascanu, Dan >>>>>>> (Dan) [dromasca@avaya.com] >>>>>>> Sent: Monday, December 15, 2014 10:27 AM >>>>>>> To: ops-dir@ietf.org; ippm@ietf.org >>>>>>> Cc: draft-ietf-ippm-rate-problem.all@tools.ietf.org >>>>>>> Subject: [OPS-DIR] OPS-DIR review of >>>>>>> draft-ietf-ippm-rate-problem-08 >>>>>>> >>>>>>> I have reviewed this document as part of the Operational >>>>>>> directorate's ongoing effort to review all IETF documents >>>>>>> being processed >>>>> by the IESG. >>>>>>> These comments were written primarily for the benefit of the >>>>>>> operational area directors. >>>>>>> Document editors and WG chairs should treat these comments >>>>>>> just like any other last call comments. >>>>>>> >>>>>>> Ready with one issue >>>>>>> >>>>>>> This I-D is an informational document that does not define a >>>>>>> new protocol or protocol extensions. It does however contain >>>>>>> a problem statement for test protocols conducting access >>>>>>> rate measurement in >>>>>> productions networks. >>>>>>> These protocols can be OWAMP (RFC 4656) or TWAMP (RFC 5357) >>>>>>> but >>>>> also >>>>>>> non-IETF protocols. The following operational considerations >>>>>>> in Appendix A.1 of RFC 5706 apply, I believe, and do not >>>>>>> receive appropriate answers in the >>>>>>> document: >>>>>>> >>>>>>> 5. Has the impact on network operation been discussed? See >>>>>>> Section >>>> 2.5. >>>>>>> * Will the new protocol significantly increase traffic load >>>>>>> on existing networks? >>>>>>> * Will the proposed management for the new protocol >>>>>>> significantly increase traffic load on existing networks? >>>>>>> * How will the new protocol impact the behavior of other >>>>>>> protocols in the network? Will it impact performance (e.g., >>>>>>> jitter) of certain types of applications running in the same network? >>>>>>> >>>>>>> I believe that at least a reference to these aspects need to >>>>>>> be included, especially as the In-Service testing with >>>>>>> injection of active traffic on production network is one of >>>>>>> the methods discussed by >>>>>> the document. >>>>>>> >>>>>>> The following reference to the effects of the high level >>>>>>> traffic is not sufficient >>>>>>> IMO: >>>>>>> >>>>>>> >>>>>>> ? Section 5 of [RFC2680] lists the problems with high >>>>>>> measurement traffic rates, and the most relevant for rate >>>>>>> measurement >>>>>>> >>>>>>> ? is the tendency for measurement traffic to skew the >>>>>>> results, >>> followed >>>>>>> by the possibility of introducing congestion on the access link. In- >>>>>>> Service testing MUST respect these traffic constraints. Obviously, >>>>>>> categories of rate measurement methods that use less active test >>>>>>> traffic than others with similar accuracy are preferred for In- >>>>>>> Service testing. >>>>>>> >>>>>>> Section 5 of RFC2680 does not provide too many details as I >>>>>>> was expecting. It actually deals with traffic injection as >>>>>>> with a security >>>> concern: >>>>>>> >>>>>>> >>>>>>> ? There are two types of security concerns: potential harm >>>>>>> caused by >>>>>>> >>>>>>> ? the measurements, and potential harm to the measurements. >> The >>>>>>> >>>>>>> ? measurements could cause harm because they are active, and >>> inject >>>>>>> >>>>>>> ? packets into the network. The measurement parameters MUST >> be >>>>>>> >>>>>>> ? carefully selected so that the measurements inject trivial >> amounts >>> of >>>>>>> >>>>>>> ? additional traffic into the networks they measure. If they inject >>>>>>> >>>>>>> ? "too much" traffic, they can skew the results of the >> measurement, >>>>> and >>>>>>> >>>>>>> ? in extreme cases cause congestion and denial of service. >>>>>>> >>>>>>> ? >>>>>>> 'trivial amounts of additional traffic' is too vague - I >>>>>>> believe that more clear text that deals with the issue as >>>>>>> with an operational issue, and makes clear that degradation >>>>>>> of service for users is not acceptable if In-Service testing >>>>>>> policies are applied would be >>>>> welcome. >>>>>>> >>>>>>> I hope this helps. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Dan > > _______________________________________________ > 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 > From nobody Thu Jan 8 07:56:20 2015 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 70C671A6F01; Thu, 8 Jan 2015 07:56:15 -0800 (PST) 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 GnKsN_XQtAkc; Thu, 8 Jan 2015 07:56:13 -0800 (PST) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 66BE31A8AA4; Thu, 8 Jan 2015 07:56:12 -0800 (PST) Received: by mx2.eict.de (Postfix, from userid 481) id 5FB5C1FF47; Thu, 8 Jan 2015 16:56:11 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id DD82A1FF44; Thu, 8 Jan 2015 16:56:10 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 6D447378057; Thu, 8 Jan 2015 16:56:10 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Thu, 8 Jan 2015 16:56:10 +0100 From: Kostas Pentikousis To: Joachim Fabini , Steve Baillargeon , "Romascanu, Dan (Dan)" , "MORTON, ALFRED C (AL)" , "ops-dir@ietf.org" , "ippm@ietf.org" Date: Thu, 8 Jan 2015 16:56:09 +0100 Thread-Topic: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 Thread-Index: AdArH9EsdjQrmrAMTr+Wy2xlG8lSdAAOzKtw Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB6078F8@SBS2008.eict.local> References: <9904FB1B0159DA42B0B887B7FA8119CA5C93075A@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA5C93A18C@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493905@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93B6D0@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493907@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CA1B@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493909@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB00@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D8549390D@NJFPSRVEXG0.research.att.com>, <9904FB1B0159DA42B0B887B7FA8119CA5C93CB97@AZ-FFEXMB03.global.avaya.com> <4AF73AA205019A4C8A1DDD32C034631D85493911@NJFPSRVEXG0.research.att.com> <9904FB1B0159DA42B0B887B7FA8119CA5C93CC13@AZ-FFEXMB03.global.avaya.com> <54AE4415.2020509@tuwien.ac.at> In-Reply-To: <54AE4415.2020509@tuwien.ac.at> 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: Cc: "draft-ietf-ippm-rate-problem.all@tools.ietf.org" Subject: Re: [ippm] OPS-DIR review of draft-ietf-ippm-rate-problem-08 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: Thu, 08 Jan 2015 15:56:15 -0000 Happy New Year all! | We had many discussion on the IPPM list and I felt that there was consens= us | that we need this feature. Indeed, that is my recollection as well. | So, my summary: there IS an effective need for asymmetrical packet size | as we have cases that we can not overcome with flow rate. | That's why I request and support the asymmetrical packet size feature. Second that. Best regards, Kostas From nobody Fri Jan 9 15:35:05 2015 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 6EF0A1A1B6D; Fri, 9 Jan 2015 15:34:56 -0800 (PST) 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 3iZTiTPFvWn2; Fri, 9 Jan 2015 15:34:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A26E01A1A94; Fri, 9 Jan 2015 15:34:54 -0800 (PST) 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.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109233454.12936.52050.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 15:34:54 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-rate-problem-09.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: Fri, 09 Jan 2015 23:34:56 -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-09.txt Pages : 13 Date : 2015-01-09 Abstract: This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size. 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-rate-problem-09 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 Jan 9 15:35:10 2015 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 EFDAD1A1A94 for ; Fri, 9 Jan 2015 15:34:57 -0800 (PST) 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 aT3AqHfeU5-O; Fri, 9 Jan 2015 15:34:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3001A1AEC; Fri, 9 Jan 2015 15:34:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: ietf@wjcerveny.com, draft-ietf-ippm-rate-problem.all@tools.ietf.org, ippm-chairs@tools.ietf.org, ippm@ietf.org, spencerdawkins.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150109233454.12936.70666.idtracker@ietfa.amsl.com> Date: Fri, 09 Jan 2015 15:34:54 -0800 Archived-At: Subject: [ippm] New Version Notification - draft-ietf-ippm-rate-problem-09.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: Fri, 09 Jan 2015 23:34:58 -0000 A new version (-09) has been submitted for draft-ietf-ippm-rate-problem: http://www.ietf.org/internet-drafts/draft-ietf-ippm-rate-problem-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-rate-problem-09 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. IETF Secretariat. From nobody Fri Jan 9 15:35:30 2015 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 8346C1A883B; Fri, 9 Jan 2015 15:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 B-MprI5iLXU9; Fri, 9 Jan 2015 15:35:22 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7AD1A875C; Fri, 9 Jan 2015 15:35:20 -0800 (PST) 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 2487312144E; Fri, 9 Jan 2015 18:48:48 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-green.research.att.com (Postfix) with ESMTP id D302FE03AF; Fri, 9 Jan 2015 18:31:48 -0500 (EST) 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, 9 Jan 2015 18:35:20 -0500 From: "MORTON, ALFRED C (AL)" To: "ietf@ietf.org" Date: Fri, 9 Jan 2015 18:33:08 -0500 Thread-Topic: Last Call: (Rate Measurement Test Protocol Problem Statement) to Informational RFC Thread-Index: AdAS9WIrpiIcKydeQDi+WfHVhbLMbgZbz3qR Message-ID: <4AF73AA205019A4C8A1DDD32C034631D8549394D@NJFPSRVEXG0.research.att.com> References: <20141208144319.25925.72497.idtracker@ietfa.amsl.com> In-Reply-To: <20141208144319.25925.72497.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: Cc: "gen-art@ietf.org" , "ops-dir@ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Last Call: (Rate Measurement Test Protocol Problem Statement) to Informational RFC 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, 09 Jan 2015 23:35:28 -0000 Ben, Dan, Greg, Version 09 of -ippm-rate-problem draft addresses your comments to great extent. Although Ben's (GEN-ART) suggestion to clarify the figure in the Intro was adopted, it seems reasonable to leave out the Figure numbers=20 since the two figures are referenced one time each and they are only 3 lines high (so not likely to move far, if at all). Dan's (OPS-DIR) comments have been addressed (following e-mail exchange) by inserting a new section on Operational Considerations where we have compromised on the text. Greg's comments have been addressed to the extent possible without re-visiting the "Toronto compromise" which only involved section 5. Other comments cite WG agreements that have not actually been=20 discussed AFAIK, or refer to purely OPTIONAL features in the memo. regards, Al ________________________________________ From: IETF-Announce [ietf-announce-bounces@ietf.org] On Behalf Of The IESG = [iesg-secretary@ietf.org] Sent: Monday, December 08, 2014 9:43 AM To: IETF-Announce Cc: ippm@ietf.org Subject: Last Call: (Rate Measurement= Test Protocol Problem Statement) to Informational RFC The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'Rate Measurement Test Protocol Problem Statement' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sat Jan 10 03:25:17 2015 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 127411AC3A2; Sat, 10 Jan 2015 03:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Q9sdA8ZUwP38; Sat, 10 Jan 2015 03:25:13 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD641AC3CF; Sat, 10 Jan 2015 03:25:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAFAK4KsVTGmAcV/2dsb2JhbABcgmQiUlgEszkCAQEGkkCFcQKBDUMBAQEBAQF8hAwBAQEBAgESKDQLBQcEAgEIDQQBAwEBCxQFBAcyFAMGCAEBBAENBQgaiAIIAQysD54NAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSGBYlDMQcGgxCBEwWECYovg0SDUIMFgnGCLYgOgzoigjKBPG+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.07,735,1413259200"; d="scan'208";a="102159294" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Jan 2015 06:25:11 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 10 Jan 2015 06:25:10 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Sat, 10 Jan 2015 12:25:09 +0100 From: "Romascanu, Dan (Dan)" To: "MORTON, ALFRED C (AL)" , "ietf@ietf.org" Thread-Topic: Last Call: (Rate Measurement Test Protocol Problem Statement) to Informational RFC Thread-Index: AdAS9WIrpiIcKydeQDi+WfHVhbLMbgZbz3qRABi1nlA= Date: Sat, 10 Jan 2015 11:25:08 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C964E97@AZ-FFEXMB04.global.avaya.com> References: <20141208144319.25925.72497.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8549394D@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D8549394D@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "gen-art@ietf.org" , "ops-dir@ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Last Call: (Rate Measurement Test Protocol Problem Statement) to Informational RFC 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, 10 Jan 2015 11:25:16 -0000 Looks good. Thanks for addressing my concerns.=20 Regards, Dan > -----Original Message----- > From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of MORTON, > ALFRED C (AL) > Sent: Saturday, January 10, 2015 1:33 AM > To: ietf@ietf.org > Cc: gen-art@ietf.org; ops-dir@ietf.org; ippm@ietf.org > Subject: Re: [Gen-art] Last Call: (= Rate > Measurement Test Protocol Problem Statement) to Informational RFC >=20 > Ben, Dan, Greg, >=20 > Version 09 of -ippm-rate-problem draft addresses your comments to great > extent. >=20 > Although Ben's (GEN-ART) suggestion to clarify the figure in the Intro wa= s > adopted, it seems reasonable to leave out the Figure numbers since the tw= o > figures are referenced one time each and they are only 3 lines high (so n= ot > likely to move far, if at all). >=20 > Dan's (OPS-DIR) comments have been addressed (following e-mail > exchange) by inserting a new section on Operational Considerations where > we have compromised on the text. >=20 > Greg's comments have been addressed to the extent possible without re- > visiting the "Toronto compromise" which only involved section 5. > Other comments cite WG agreements that have not actually been discussed > AFAIK, or refer to purely OPTIONAL features in the memo. >=20 > regards, > Al >=20 > ________________________________________ > From: IETF-Announce [ietf-announce-bounces@ietf.org] On Behalf Of The > IESG [iesg-secretary@ietf.org] > Sent: Monday, December 08, 2014 9:43 AM > To: IETF-Announce > Cc: ippm@ietf.org > Subject: Last Call: (Rate Measureme= nt > Test Protocol Problem Statement) to Informational RFC >=20 > The IESG has received a request from the IP Performance Metrics WG (ippm) > to consider the following document: > - 'Rate Measurement Test Protocol Problem Statement' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-12-22. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginnin= g of > the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > 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 >=20 >=20 > The file can be obtained via > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Drate- > 2Dproblem_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNX > CJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DEKLRXCpGDaNYiJ9WjJgA2LRIdn0QDiC > yaT1frtYfg8Y&s=3DTnJHba-sAmj9BdGxYeMgYS-qoQBHT0QgbNSFjZ8snbo&e=3D >=20 > IESG discussion can be tracked via > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Drate- > 2Dproblem_ballot_&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR3 > 1OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DEKLRXCpGDaNYiJ9WjJgA2LRIdn > 0QDiCyaT1frtYfg8Y&s=3D8MzkfnznQ4g4XC4ZfldXKZFpASLAK89Cf4ELdsZWIZ0&e > =3D >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_gen- > 2Dart&d=3DAwICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvl > siLQfucBXRucPvdrphpBsFA&m=3DEKLRXCpGDaNYiJ9WjJgA2LRIdn0QDiCyaT1frt > Yfg8Y&s=3DQ8ccS1OgnV3UQ8TqslGmcf_Dz8hcuFK1jGvVfV6os7c&e=3D From nobody Sun Jan 11 17:52:45 2015 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 CC34C1A89FE for ; Sun, 11 Jan 2015 17:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.611 X-Spam-Level: X-Spam-Status: No, score=0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 uDXvYnMuDQ1V for ; Sun, 11 Jan 2015 17:52:41 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id 24C6D1A89F9 for ; Sun, 11 Jan 2015 17:52:40 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec54b328e7bad-b3058; Mon, 12 Jan 2015 09:52:39 +0800 (CST) X-RM-TRANSID: 2eec54b328e7bad-b3058 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[10.2.52.238]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee554b328e68fe-0b8fe; Mon, 12 Jan 2015 09:52:39 +0800 (CST) X-RM-TRANSID: 2ee554b328e68fe-0b8fe From: =?UTF-8?B?6YKT54G16I6JL0xpbmdsaSBEZW5n?= To: Date: Mon, 12 Jan 2015 09:52:47 +0800 Message-ID: <009101d02e0a$7764f4c0$662ede40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAtTQ0kdtXtGEEuTVabSH44+xmHEQAvSdiw Content-Language: zh-cn Archived-At: Subject: [ippm] FW: New Version Notification for draft-deng-ippm-passive-wireless-usecase-01.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: Mon, 12 Jan 2015 01:52:44 -0000 Hi all, A new version of passive-wireless-usecases draft is uploaded. Your review and comments would be highly appreciated. Regards, Lingli&Vero&Greg&Mike > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, January 11, 2015 11:17 AM > To: Greg Mirsky; Lianshu Zheng; Greg Mirsky; Deng Lingli; Lingli Deng; = Lianshu > Zheng > Subject: New Version Notification for > draft-deng-ippm-passive-wireless-usecase-01.txt >=20 >=20 > A new version of I-D, draft-deng-ippm-passive-wireless-usecase-01.txt > has been successfully submitted by Lingli Deng and posted to the > IETF repository. >=20 > Name: draft-deng-ippm-passive-wireless-usecase > Revision: 01 > Title: Use-cases for Passive Measurement in Wireless Networks > Document date: 2015-01-11 > Group: Individual Submission > Pages: 10 > URL: > = http://www.ietf.org/internet-drafts/draft-deng-ippm-passive-wireless-usec= ase- > 01.txt > Status: > = https://datatracker.ietf.org/doc/draft-deng-ippm-passive-wireless-usecase= / > Htmlized: > http://tools.ietf.org/html/draft-deng-ippm-passive-wireless-usecase-01 > Diff: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-deng-ippm-passive-wireless-useca= se-01 >=20 > Abstract: > This document presents use-cases for passive IP performance > measurements in wireless networks. >=20 >=20 >=20 >=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 > The IETF Secretariat From nobody Mon Jan 12 10:29:57 2015 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 2A77B1ACD18; Mon, 12 Jan 2015 10:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 5NXsvnfdqlm1; Mon, 12 Jan 2015 10:29:55 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C624A1A802F; Mon, 12 Jan 2015 10:29:54 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-db-54b3b4597290 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id A7.B7.25146.954B3B45; Mon, 12 Jan 2015 12:47:38 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 13:29:48 -0500 From: Gregory Mirsky To: "MORTON, ALFRED C (AL)" , "ietf@ietf.org" Thread-Topic: Last Call: (Rate Measurement Test Protocol Problem Statement) to Informational RFC Thread-Index: AdAS9WIrpiIcKydeQDi+WfHVhbLMbgZbz3qRAIwUDZA= Date: Mon, 12 Jan 2015 18:29:47 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8D028A@eusaamb103.ericsson.se> References: <20141208144319.25925.72497.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8549394D@NJFPSRVEXG0.research.att.com> In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D8549394D@NJFPSRVEXG0.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPiG7Uls0hBi9XsFhsPTaR0eLqq88s Fs82zmex6Hnwjtmit2kJswOrx8v+OYweS5b8ZApgiuKySUnNySxLLdK3S+DK2H14J3vBFpmK PWsvszcw7hbvYuTkkBAwkbiwoZ0NwhaTuHBvPZDNxSEkcIRR4uS6FVDOckaJJcsuMoFUsQkY SbzY2MMOYosIBErcfLsFqIiDg1mgWOLGPlWQemGBdkaJRTNfs4M4IgIdjBJzvi1khmiwkrjx bhLYOhYBVYndvb2sIDavgK/EyfXzWCC2dTNKnG3tAEtwCoRIfHh3BKyBEei+76fWgF3BLCAu cevJfCaIuwUkluw5zwxhi0q8fPyPFcJWlNjXP50dol5HYsHuT2wQtrbEsoWvmSEWC0qcnPmE ZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcxAiPpmASb4w7GBZ8sDzEKcDAq8fAa nNgUIsSaWFZcmXuIUZqDRUmcN+LR+hAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjOZ/deSd E1gTXzqHzVt66rhaTaDLgf9pL/ZekbVftPTKz5LdpitZbyYrGPvdleRdsmSa5kuZxfv6Nj36 FZNvW1msOy1lvYF1QsIOp4bEExqP9XwU/ulUr7t8K16v+9mW63XlN97fP7q9/GeltMYVC/bH ZZUasatWND4M9Q2MEyrKTr/wIqf6rxJLcUaioRZzUXEiAMMWMNSFAgAA Archived-At: Cc: "gen-art@ietf.org" , "ops-dir@ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Last Call: (Rate Measurement Test Protocol Problem Statement) to Informational RFC 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, 12 Jan 2015 18:29:57 -0000 Dear Al, et. al, thank you for the detailed explanation of rationale not to address my comme= nts. I see that we have different interpretation of the decision reached by= the IPPM WG in meeting in Toronto. I strongly believe that limiting its sc= ope to the Section 5 only results in technical inconsistencies throughout t= he document that I've pointed out in my comments. Thus, I propose, to apply= WG decision from the meeting in Toronto to the document in its entirety an= d remove statements and assumptions that contradict WG decision reached the= n. Regards, Greg -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of MORTON, ALFRED C (AL= ) Sent: Friday, January 09, 2015 3:33 PM To: ietf@ietf.org Cc: gen-art@ietf.org; ops-dir@ietf.org; ippm@ietf.org Subject: Re: [ippm] Last Call: (Rate = Measurement Test Protocol Problem Statement) to Informational RFC Ben, Dan, Greg, Version 09 of -ippm-rate-problem draft addresses your comments to great ext= ent. Although Ben's (GEN-ART) suggestion to clarify the figure in the Intro was = adopted, it seems reasonable to leave out the Figure numbers since the two = figures are referenced one time each and they are only 3 lines high (so not= likely to move far, if at all). Dan's (OPS-DIR) comments have been addressed (following e-mail exchange) by inserting a new section on Operational Considerations where we= have compromised on the text. Greg's comments have been addressed to the extent possible without re-visit= ing the "Toronto compromise" which only involved section 5. Other comments cite WG agreements that have not actually been discussed AFA= IK, or refer to purely OPTIONAL features in the memo. regards, Al ________________________________________ From: IETF-Announce [ietf-announce-bounces@ietf.org] On Behalf Of The IESG = [iesg-secretary@ietf.org] Sent: Monday, December 08, 2014 9:43 AM To: IETF-Announce Cc: ippm@ietf.org Subject: Last Call: (Rate Measurement= Test Protocol Problem Statement) to Informational RFC The IESG has received a request from the IP Performance Metrics WG (ippm) t= o consider the following document: - 'Rate Measurement Test Protocol Problem Statement' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf= .org mailing lists by 2014-12-22. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Tue Jan 13 14:19:02 2015 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 B082C1B29F7 for ; Tue, 13 Jan 2015 14:18:59 -0800 (PST) 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, TVD_SPACE_RATIO=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 YYHEJ1-aZXFY; Tue, 13 Jan 2015 14:18:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1E81B29E5; Tue, 13 Jan 2015 14:18:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-ippm-ipsec.all@tools.ietf.org, ietf@trammell.ch, ippm-chairs@tools.ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150113221856.31619.62325.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 14:18:56 -0800 From: IETF Secretariat Archived-At: Subject: [ippm] ID Tracker State Update Notice: 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, 13 Jan 2015 22:19:00 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ From nobody Wed Jan 14 08:08:47 2015 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 351E71ACDE7; Mon, 12 Jan 2015 13:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1jPsPdG1_0JY; Mon, 12 Jan 2015 13:46:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CE71ACDB7; Mon, 12 Jan 2015 13:46:56 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0CLkp8f051097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2015 15:46:52 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ben Campbell In-Reply-To: <4AF73AA205019A4C8A1DDD32C034631D8549394D@NJFPSRVEXG0.research.att.com> Date: Mon, 12 Jan 2015 15:46:51 -0600 X-Mao-Original-Outgoing-Id: 442792011.452993-2f20ac4e546f9a449b9b73f9de63ea49 Content-Transfer-Encoding: quoted-printable Message-Id: <874F0905-001A-41FA-AFB6-AA4A6B4FB422@nostrum.com> References: <20141208144319.25925.72497.idtracker@ietfa.amsl.com> <4AF73AA205019A4C8A1DDD32C034631D8549394D@NJFPSRVEXG0.research.att.com> To: "MORTON, ALFRED C (AL)" X-Mailer: Apple Mail (2.1993) Archived-At: X-Mailman-Approved-At: Wed, 14 Jan 2015 08:08:40 -0800 Cc: "gen-art@ietf.org" , "ops-dir@ietf.org" , "ietf@ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] Last Call: (Rate Measurement Test Protocol Problem Statement) to Informational RFC 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, 12 Jan 2015 21:46:59 -0000 Hi, This version addresses the concerns from my GEN-ART review. I agree that = it's reasonable to skip the figure numbers with only two small figures. Thanks! Ben. > On Jan 9, 2015, at 5:33 PM, MORTON, ALFRED C (AL) = wrote: >=20 > Ben, Dan, Greg, >=20 > Version 09 of -ippm-rate-problem draft addresses your comments > to great extent. >=20 > Although Ben's (GEN-ART) suggestion to clarify the figure in the Intro = was > adopted, it seems reasonable to leave out the Figure numbers=20 > since the two figures are referenced one time each and they are > only 3 lines high (so not likely to move far, if at all). >=20 > Dan's (OPS-DIR) comments have been addressed (following e-mail > exchange) by inserting a new section on Operational Considerations > where we have compromised on the text. >=20 > Greg's comments have been addressed to the extent possible without > re-visiting the "Toronto compromise" which only involved section 5. > Other comments cite WG agreements that have not actually been=20 > discussed AFAIK, or refer to purely OPTIONAL features in the memo. >=20 > regards, > Al >=20 > ________________________________________ > From: IETF-Announce [ietf-announce-bounces@ietf.org] On Behalf Of The = IESG [iesg-secretary@ietf.org] > Sent: Monday, December 08, 2014 9:43 AM > To: IETF-Announce > Cc: ippm@ietf.org > Subject: Last Call: (Rate = Measurement Test Protocol Problem Statement) to Informational RFC >=20 > The IESG has received a request from the IP Performance Metrics WG = (ippm) > to consider the following document: > - 'Rate Measurement Test Protocol Problem Statement' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-12-22. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > 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 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 From nobody Fri Jan 16 08:40:25 2015 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 4D2BA1ACEC4; Fri, 16 Jan 2015 08:40:23 -0800 (PST) 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 QuKVk6WwBmIc; Fri, 16 Jan 2015 08:40:20 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6771ACEAD; Fri, 16 Jan 2015 08:40:19 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so19390222lbv.0; Fri, 16 Jan 2015 08:40:18 -0800 (PST) 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=aPshMK+sRM8z/mJbvo5N/Bh5Bnj8lhTJ4W+HUzrc7+E=; b=qM0S4sajA6YIIIeIIYvtNKAwod3yYl1X/ZUuDXHgkX9zHZSRH0UvQyLJK5pq5CwiRK dVEyOYzs5d+FSMAUygQJEq2j9uGKStGw6ea3dM19PJ11dzZLLYgcQ6XGa7Kgh+d9hC7z /TELf6Cto2Gz5liwoZi+hhU8Z9uvqZ5XO4ub9dF/8FptqEZ/8yrKI7jVTXa/7etVGgQe LxsLA2KEU6WxloEfYxSTtvdklAME3n5lYlciK6YgXvjke3Whk0XramYS9zoGo6k7rYDo 2wa2rcpNtigOFfcxMicoN/fu7xVvGa8Pc5eB23cNb9xm5A7tXknk0dAHRuL07h0lCrez LMnw== MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr16370292lbv.21.1421426418369; Fri, 16 Jan 2015 08:40:18 -0800 (PST) Received: by 10.152.108.45 with HTTP; Fri, 16 Jan 2015 08:40:18 -0800 (PST) In-Reply-To: <20150106102440.13588.95602.idtracker@ietfa.amsl.com> References: <20150106102440.13588.95602.idtracker@ietfa.amsl.com> Date: Fri, 16 Jan 2015 10:40:18 -0600 Message-ID: From: Spencer Dawkins at IETF To: Brian Trammell Content-Type: multipart/alternative; boundary=001a11c23d8abdca00050cc7a0ca Archived-At: Cc: draft-ietf-ippm-ipsec.all@tools.ietf.org, "iesg-secretary@ietf.org" , "ippm-chairs@tools.ietf.org Chairs" , ippm@ietf.org Subject: Re: [ippm] Publication has been requested for draft-ietf-ippm-ipsec-07 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, 16 Jan 2015 16:40:23 -0000 --001a11c23d8abdca00050cc7a0ca Content-Type: text/plain; charset=UTF-8 Hi, Brian, On Tue, Jan 6, 2015 at 4:24 AM, Brian Trammell wrote: > Brian Trammell has requested publication of draft-ietf-ippm-ipsec-07 as > Proposed Standard on behalf of the IPPM working group. > > Please verify the document's state at > http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ I've done the AD evaluation for this doc, and am mostly fine with it, but had some suggestions that I wanted to share with you before Last Call. I want to emphasize that these are either nits or close to nits, but found that I didn't understand the draft clearly when I encountered them. If you'd like to do a minor revision, that would be fine, or if you'd like to tell me that smart people can understand the stuff that wasn't clear to me, that would be fine, or if you'd like me to issue Last Call and then post my comments, that would be fine. Just let me know! And thanks, as always ... Spencer -- my notes follow -- In this text, in the Abstract: 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. "discusses the use of keys" probably isn't quite right for a Proposed Standard. In Section 3, you say "describes". That's probably better. While we are in Section 3, this text: 3. Scope and Applicability This document specifies a method for enabling network measurements between a TWAMP client and a TWAMP server which both support IPsec. In short, the shared key used for securing TWAMP traffic is derived using IKEv2 [RFC7296]. This document reserves from the TWAMP-Modes registry the Mode value IKEv2Derived which is equal to 128 (i.e. bit set in position 7) [NOTE to IANA: remove before allocation and final publication] and MUST be used by TWAMP implementations compatible with this specification. Although the control procedures described in this document are applicable to OWAMP per se, the lack of an established IANA registry for OWAMP Mode values technically prevents us from extending OWAMP Mode values. Therefore, independent OWAMP implementations SHOULD be checked for full compatibility with respect to the use of this Mode value. Until an IANA registry for OWAMP Mode values is established, the use this feature in OWAMP implementations MUST be arranged privately among consenting OWAMP users. is the first place I understood clearly what the document is doing. Perhaps the first two sentences could go in the Introduction, so you'd be introducing what the document does in the Introduction? ;-) In this text in 5.1. Shared Key Derivation When the shared secret key is derived from the IKEv2 SA, SK_d must be generated first. SK_d MUST be computed as per [RFC7296]. The shared secret key MUST be generated as follows: Shared secret key = PRF( SK_d, "IPPM" ) ^^^ Wherein the string "IPPM" comprises four ASCII characters and prf is ^^^ a pseudorandom function. Is it common usage to capitalize "PRF" in the algorithm, but not in the definition? Or, and this is equally likely, there's a relationship between "PRF" and "prf" that I don't understand? In this text: 5.2. Server Greeting Message Update To achieve a binding association between the key generated from IKEv2 and the O/TWAMP shared secret key, Server Greeting Message should be updated as in Figure 2. ^^^^^^^ I'm sorry, but I don't understand what it means to "update" a message. Could you help me here? If I was guessing, I'd guess "should include these extensions, as in Figure 2", but that's a guess. --001a11c23d8abdca00050cc7a0ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Brian,
<= div class=3D"gmail_extra">
On Tue, Jan 6,= 2015 at 4:24 AM, Brian Trammell <ietf@trammell.ch> wrote:
Brian Trammell= has requested publication of draft-ietf-ippm-ipsec-07 as Proposed Standard= on behalf of the IPPM working group.

Please verify the document's state at http://datatracker.ietf= .org/doc/draft-ietf-ippm-ipsec/

I've done the AD evaluation for this doc, and am mostly fine with i= t, but had some suggestions that I wanted to share with you before Last Cal= l.=C2=A0

I want to emphasize that these= are either nits or close to nits, but found that I didn't understand t= he draft clearly when I encountered them.

If you'd like to do a minor revision, that= would be fine, or if you'd like to tell me that smart people can under= stand the stuff that wasn't clear to me, that would be fine, or if you&= #39;d like me to issue Last Call and then post my comments, that would be f= ine.

=
Just let me know! And thanks, as a= lways ...

<= /div>
Spencer

-- my notes follow --

In= this text, in the Abstract:

Abstract

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0The O/TWAMP security mechan= ism requires that both the client and
=C2=A0 =C2=A0server endpoints possess a shared secret.=C2= =A0 Since the currently-
=C2=A0 =C2=A0standardized O/TWAMP security mechanism only supports a pre= -shared
=C2=A0 =C2=A0k= ey mode, large scale deployment of O/TWAMP is hindered
=C2=A0 =C2=A0significantly.=C2=A0 At the s= ame time, recent trends point to wider IKEv2
=C2=A0 =C2=A0deployment which, in turn, calls for me= chanisms and methods that
=C2=A0 =C2=A0enable tunnel end-users, as well as operators, to measure = one-way and
=C2=A0 =C2= =A0two-way network performance in a standardized manner.=C2=A0 This documen= t
=C2=A0 =C2=A0discuss= es the use of keys derived from an IKEv2 SA as the shared key
<= div>=C2=A0 =C2=A0^^^^^^^^^
=
=C2=A0 =C2=A0in O/TWAMP.=C2=A0 If = the shared key can be derived from the IKEv2 SA, O/
=C2=A0 =C2=A0TWAMP can support certificate-ba= sed key exchange, which would allow
=C2=A0 =C2=A0for more operational flexibility and efficiency.= =C2=A0 The key derivation
=C2=A0 =C2=A0presented in this document can also facilitate automatic k= ey
=C2=A0 =C2=A0manage= ment.
=C2=A0 =C2=A0
"discusses the use = of keys" probably isn't quite right for a Proposed Standard. In Se= ction 3, you say "describes". That's probably better.<= /div>

While we are in Section 3, this text:

3.=C2=A0 Scope and Applicability

=C2=A0 =C2=A0This document specifies a method for ena= bling network measurements
=C2=A0 =C2=A0between a TWAMP client and a TWAMP server which both supp= ort IPsec.
=C2=A0 =C2= =A0In short, the shared key used for securing TWAMP traffic is derived
=C2=A0 =C2=A0using IKEv2 [= RFC7296].=C2=A0 This document reserves from the TWAMP-Modes
=C2=A0 =C2=A0registry the Mode value = IKEv2Derived which is equal to 128 (i.e. bit
=C2=A0 =C2=A0set in position 7) [NOTE to IANA: remov= e before allocation and final
=C2=A0 =C2=A0publication] and MUST be used by TWAMP implementations= compatible
=C2=A0 =C2= =A0with this specification.

=C2=A0 =C2= =A0Although the control procedures described in this document are
=C2=A0 =C2=A0applicable to OWAM= P per se, the lack of an established IANA registry
=C2=A0 =C2=A0for OWAMP Mode values technically= prevents us from extending OWAMP
=C2=A0 =C2=A0Mode values.=C2=A0 Therefore, independent OWAMP im= plementations SHOULD be
=C2=A0 =C2=A0v= alue.=C2=A0 Until an IANA registry for OWAMP Mode values is established,
=C2=A0 =C2=A0the use thi= s feature in OWAMP implementations MUST be arranged
=C2=A0 =C2=A0privately among consenting OWAMP= users.
=C2=A0 =C2=A0<= /font>
is the first place I u= nderstood clearly what the document is doing. Perhaps the first two sentenc= es could go in the Introduction, so you'd be introducing what the docum= ent does in the Introduction? ;-)

In th= is text in 5.1.=C2=A0 Shared Key Derivation

=C2=A0 =C2=A0When the shared secret key is derived from the IKEv2 SA, = SK_d must be
=C2=A0 = =C2=A0generated first.=C2=A0 SK_d MUST be computed as per [RFC7296].=

=C2=A0 =C2=A0The shared secret key MUST be ge= nerated as follows:
=C2=A0 =C2=A0 =C2= =A0 Shared secret key =3D PRF( SK_d, "IPPM" )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^

=C2=A0 =C2=A0Wherein the string "IPPM" comprises f= our ASCII characters and prf is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0^^^

Is it common usage to capitalize "PRF" in the algorithm, but not= in the definition? Or, and this is equally likely, there's a relations= hip between "PRF" and "prf" that I don't understand= ?

In this text: 5.2.=C2=A0 Server Greet= ing Message Update
=C2=A0 =C2=A0To achi= eve a binding association between the key generated from IKEv2
=
=C2=A0 =C2=A0and the O/TWAMP share= d secret key, Server Greeting Message should be
=C2=A0 =C2=A0updated as in Figure 2.
=
=C2=A0 =C2=A0^^^^^^^
<= div>=C2=A0 =C2=A0
I'm sorry, but I don't understand w= hat it means to "update" a message. Could you help me here? If I = was guessing, I'd guess "should include these extensions, as in Fi= gure 2", but that's a guess.=C2=A0
--001a11c23d8abdca00050cc7a0ca-- From nobody Fri Jan 16 10:37:14 2015 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 682781B2A31 for ; Fri, 16 Jan 2015 10:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 zZVT9uJJWkT9 for ; Fri, 16 Jan 2015 10:37:10 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626371ACE72 for ; Fri, 16 Jan 2015 10:37:10 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-bb-54b9080805c5 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6A.46.03307.80809B45; Fri, 16 Jan 2015 13:46:01 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Fri, 16 Jan 2015 13:37:07 -0500 From: Gregory Mirsky To: "ippm@ietf.org" Thread-Topic: New Version Notification for draft-mirsky-ippm-time-format-00.txt Thread-Index: AQHQMbr9WV6V8+6ulESlAhg19VZTNpzDEpLg Date: Fri, 16 Jan 2015 18:37:06 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8D392E@eusaamb103.ericsson.se> References: <20150116183232.26638.588.idtracker@ietfa.amsl.com> In-Reply-To: <20150116183232.26638.588.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyuXRPuC4nx84Qg017BS16HrxjdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuNne5gLfghWbPz/kKmBcY9gFyMnh4SAicSpK0tZIGwxiQv3 1rN1MXJxCAkcYZToutvJCOEsZ5SYcH4aG0gVm4CRxIuNPewgtoiAskTLtz+MILawQIDE2+Pr mCDigRIP2j+wQthGEne/r2TuYuTgYBFQldj7TQLE5BXwlZh21BykQkjAXqJ70jSwiZwCDhI/ Zv8HsxmB7vl+ag3YRGYBcYlbT+YzQdwpILFkz3lmCFtU4uXjf6wQtqLEvv7p7CDjmQU0Jdbv 0odoVZSY0v0QbCSvgKDEyZlPWCYwis5CMnUWQscsJB2zkHQsYGRZxchRWpxalptuZLCJERjy xyTYdHcw7nlpeYhRgINRiYd3Q92OECHWxLLiytxDjNIcLErivC3v1ocICaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYEyezW/+a+30x+ar1W8lpH7y3KBn41/6/yFnn9AR/TPc97dcr51Vc+nR jKwpszjuBlecu25ds//CiSmBe30PzDjN01oqxtthKbZZN11RYZHYQ9b/K3iPHCv4VHWHP12q s7b4fuIlA1t+/Zq/Hr7buh04nc5Y//r1YNqrvIfiG+QeP/jvv/iz00ElluKMREMt5qLiRABN 6wAXWgIAAA== Archived-At: Subject: [ippm] FW: New Version Notification for draft-mirsky-ippm-time-format-00.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: Fri, 16 Jan 2015 18:37:12 -0000 RGVhciBBbGwsDQp3ZSd2ZSBwdWJsaXNoZWQgdGhlIHByb3Bvc2FsIHRvIGVuaGFuY2UgT1dBTVAv VFdBTVAgcHJvdG9jb2xzIHRvIHVzZSBQVFB2MiB0cnVuY2F0ZWQgNjQtYml0IGxvbmcgdGltZXN0 YW1wIGZvcm1hdCBpbiBPV0FNUCBhbmQgVFdBTVAgdGVzdHMuDQoNCllvdXIgcXVlc3Rpb25zLCBj b21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYWx3YXlzIHdlbGNvbWUgYW5kIGdyZWF0bHkgYXBwcmVj aWF0ZWQuDQoNCglSZWdhcmRzLA0KCQlHcmVnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDE2LCAyMDE1IDEwOjMzIEFNDQpUbzog R3JlZ29yeSBNaXJza3k7IElzcmFlbCBNZWlsaWs7IFN1Y2hpdCBCYW5zYWw7IEdyZWdvcnkgTWly c2t5OyBSYW1hbmF0aGFuIExha3NobWlrYW50aGFuOyBJc3JhZWwgTWVpbGlrOyBTdWNoaXQgQmFu c2FsOyBSYW1hbmF0aGFuIExha3NobWlrYW50aGFuDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LW1pcnNreS1pcHBtLXRpbWUtZm9ybWF0LTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1taXJza3ktaXBwbS10aW1lLWZvcm1hdC0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWlyc2t5LWlwcG0tdGlt ZS1mb3JtYXQNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlTdXBwb3J0IG9mIElFRUUtMTU4OCB0aW1l IHN0YW1wIGZvcm1hdCBpbiBUd28tV2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoVFdB TVApDQpEb2N1bWVudCBkYXRlOgkyMDE1LTAxLTE2DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlz c2lvbg0KUGFnZXM6CQk4DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtbWlyc2t5LWlwcG0tdGltZS1mb3JtYXQtMDAudHh0DQpTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5LWlw cG0tdGltZS1mb3JtYXQvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbWlyc2t5LWlwcG0tdGltZS1mb3JtYXQtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIE9QVElPTkFMIGZlYXR1cmUgZm9yIGFjdGl2ZSBwZXJm b3JtYW5jZQ0KICAgbWVhc3VyZW1lbnQgcHJvdG9jb2xzIGFsbG93aW5nIHVzZSBvZiB0aW1lIHN0 YW1wIGZvcm1hdCBkZWZpbmVkIGluDQogICBJRUVFLTE1ODh2Mi0yMDA4Lg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Jan 16 16:21:04 2015 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 E06AF1A908F; Fri, 16 Jan 2015 16:21:02 -0800 (PST) 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, TVD_SPACE_RATIO=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 xBB2TnuUmvE3; Fri, 16 Jan 2015 16:21:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB241A9083; Fri, 16 Jan 2015 16:21:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-ippm-rate-problem.all@tools.ietf.org, iesg-secretary@ietf.org, iesg@ietf.org, ippm@ietf.org, ietf@wjcerveny.com, ippm-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150117002101.22970.55594.idtracker@ietfa.amsl.com> Date: Fri, 16 Jan 2015 16:21:01 -0800 From: IETF Secretariat Archived-At: Subject: [ippm] Telechat update notice: 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: Sat, 17 Jan 2015 00:21:03 -0000 Placed on agenda for telechat - 2015-02-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ From nobody Thu Jan 22 10:36:54 2015 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 048431AD0F0 for ; Thu, 22 Jan 2015 10:36:53 -0800 (PST) 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 tVhdORnVOm4B; Thu, 22 Jan 2015 10:36:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED831AD0D3; Thu, 22 Jan 2015 10:36:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-ippm-ipsec.all@tools.ietf.org, ietf@trammell.ch, ippm-chairs@tools.ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150122183650.17997.96712.idtracker@ietfa.amsl.com> Date: Thu, 22 Jan 2015 10:36:50 -0800 From: IETF Secretariat Archived-At: Subject: [ippm] ID Tracker State Update Notice: 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, 22 Jan 2015 18:36:53 -0000 IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ From nobody Mon Jan 26 04:00:14 2015 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 D7C211A897A; Mon, 26 Jan 2015 04:00:08 -0800 (PST) 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 7BR-wOk54LAV; Mon, 26 Jan 2015 04:00:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D261A8920; Mon, 26 Jan 2015 04:00:05 -0800 (PST) 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.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126120005.22176.14991.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 04:00:05 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-ipsec-08.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: Mon, 26 Jan 2015 12:00:09 -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 : IKEv2-based Shared Secret Key for O/TWAMP Authors : Kostas Pentikousis Emma Zhang Yang Cui Filename : draft-ietf-ippm-ipsec-08.txt Pages : 13 Date : 2015-01-26 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 describes 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ipsec-08 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 Mon Jan 26 04:00:20 2015 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 3A1DA1A897C for ; Mon, 26 Jan 2015 04:00:15 -0800 (PST) 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 ELneRAXulWeD; Mon, 26 Jan 2015 04:00:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9491B1A8969; Mon, 26 Jan 2015 04:00:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: draft-ietf-ippm-ipsec.all@tools.ietf.org, ietf@trammell.ch, ippm-chairs@tools.ietf.org, ippm@ietf.org, spencerdawkins.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126120006.22176.47843.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 04:00:06 -0800 Archived-At: Subject: [ippm] New Version Notification - draft-ietf-ippm-ipsec-08.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: Mon, 26 Jan 2015 12:00:15 -0000 A new version (-08) has been submitted for draft-ietf-ippm-ipsec: http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipsec-08.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ipsec-08 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. IETF Secretariat. From nobody Mon Jan 26 04:01:45 2015 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 67AE71A8971; Mon, 26 Jan 2015 04:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 NjQlQm-OP-Ts; Mon, 26 Jan 2015 04:01:34 -0800 (PST) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 362CF1A8935; Mon, 26 Jan 2015 04:01:33 -0800 (PST) Received: by mx2.eict.de (Postfix, from userid 481) id 250691FF65; Mon, 26 Jan 2015 13:01:32 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 74D601FF60; Mon, 26 Jan 2015 13:01:30 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id EEB9B3780A2; Mon, 26 Jan 2015 13:01:29 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Mon, 26 Jan 2015 13:01:29 +0100 From: Kostas Pentikousis To: Spencer Dawkins at IETF , Brian Trammell Date: Mon, 26 Jan 2015 13:01:27 +0100 Thread-Topic: Publication has been requested for draft-ietf-ippm-ipsec-07 Thread-Index: AdAxqzoP5zesg7tOTsyyWFNLM2CZrgHtEatw Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB7485D6@SBS2008.eict.local> References: <20150106102440.13588.95602.idtracker@ietfa.amsl.com> In-Reply-To: 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: multipart/alternative; boundary="_000_0C7EDCF89AB9E2478B5D010026CFF4AEB5AB7485D6SBS2008eictlo_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ippm-ipsec.all@tools.ietf.org" , "iesg-secretary@ietf.org" , "ippm-chairs@tools.ietf.org Chairs" , "ippm@ietf.org" Subject: Re: [ippm] Publication has been requested for draft-ietf-ippm-ipsec-07 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, 26 Jan 2015 12:01:39 -0000 --_000_0C7EDCF89AB9E2478B5D010026CFF4AEB5AB7485D6SBS2008eictlo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFueSB0aGFua3MgU3BlbmNlci4gV2UgaGF2ZSBub3cgdXBkYXRlZCB0aGUgZG9jdW1lbnQgYXMg cGVyIHlvdXIgc3VnZ2VzdGlvbnMuDQoNCkJlc3QgcmVnYXJkcywNCg0KS29zdGFzDQoNClZvbjog U3BlbmNlciBEYXdraW5zIGF0IElFVEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWls LmNvbV0NCkdlc2VuZGV0OiBGcmVpdGFnLCAxNi4gSmFudWFyIDIwMTUgMTc6NDANCkFuOiBCcmlh biBUcmFtbWVsbA0KQ2M6IGlwcG0tY2hhaXJzQHRvb2xzLmlldGYub3JnIENoYWlyczsgaWVzZy1z ZWNyZXRhcnlAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaXBwbS1pcHNlYy5hbGxAdG9vbHMuaWV0Zi5v cmc7IGlwcG1AaWV0Zi5vcmcNCkJldHJlZmY6IFJlOiBQdWJsaWNhdGlvbiBoYXMgYmVlbiByZXF1 ZXN0ZWQgZm9yIGRyYWZ0LWlldGYtaXBwbS1pcHNlYy0wNw0KDQpIaSwgQnJpYW4sDQoNCk9uIFR1 ZSwgSmFuIDYsIDIwMTUgYXQgNDoyNCBBTSwgQnJpYW4gVHJhbW1lbGwgPGlldGZAdHJhbW1lbGwu Y2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PiB3cm90ZToNCkJyaWFuIFRyYW1tZWxsIGhhcyBy ZXF1ZXN0ZWQgcHVibGljYXRpb24gb2YgZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLTA3IGFzIFByb3Bv c2VkIFN0YW5kYXJkIG9uIGJlaGFsZiBvZiB0aGUgSVBQTSB3b3JraW5nIGdyb3VwLg0KDQpQbGVh c2UgdmVyaWZ5IHRoZSBkb2N1bWVudCdzIHN0YXRlIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLw0KDQpJJ3ZlIGRvbmUgdGhlIEFEIGV2YWx1 YXRpb24gZm9yIHRoaXMgZG9jLCBhbmQgYW0gbW9zdGx5IGZpbmUgd2l0aCBpdCwgYnV0IGhhZCBz b21lIHN1Z2dlc3Rpb25zIHRoYXQgSSB3YW50ZWQgdG8gc2hhcmUgd2l0aCB5b3UgYmVmb3JlIExh c3QgQ2FsbC4NCg0KSSB3YW50IHRvIGVtcGhhc2l6ZSB0aGF0IHRoZXNlIGFyZSBlaXRoZXIgbml0 cyBvciBjbG9zZSB0byBuaXRzLCBidXQgZm91bmQgdGhhdCBJIGRpZG4ndCB1bmRlcnN0YW5kIHRo ZSBkcmFmdCBjbGVhcmx5IHdoZW4gSSBlbmNvdW50ZXJlZCB0aGVtLg0KDQpJZiB5b3UnZCBsaWtl IHRvIGRvIGEgbWlub3IgcmV2aXNpb24sIHRoYXQgd291bGQgYmUgZmluZSwgb3IgaWYgeW91J2Qg bGlrZSB0byB0ZWxsIG1lIHRoYXQgc21hcnQgcGVvcGxlIGNhbiB1bmRlcnN0YW5kIHRoZSBzdHVm ZiB0aGF0IHdhc24ndCBjbGVhciB0byBtZSwgdGhhdCB3b3VsZCBiZSBmaW5lLCBvciBpZiB5b3Un ZCBsaWtlIG1lIHRvIGlzc3VlIExhc3QgQ2FsbCBhbmQgdGhlbiBwb3N0IG15IGNvbW1lbnRzLCB0 aGF0IHdvdWxkIGJlIGZpbmUuDQoNCkp1c3QgbGV0IG1lIGtub3chIEFuZCB0aGFua3MsIGFzIGFs d2F5cyAuLi4NCg0KU3BlbmNlcg0KDQotLSBteSBub3RlcyBmb2xsb3cgLS0NCg0KSW4gdGhpcyB0 ZXh0LCBpbiB0aGUgQWJzdHJhY3Q6DQoNCkFic3RyYWN0DQoNCiAgIFRoZSBPL1RXQU1QIHNlY3Vy aXR5IG1lY2hhbmlzbSByZXF1aXJlcyB0aGF0IGJvdGggdGhlIGNsaWVudCBhbmQNCiAgIHNlcnZl ciBlbmRwb2ludHMgcG9zc2VzcyBhIHNoYXJlZCBzZWNyZXQuICBTaW5jZSB0aGUgY3VycmVudGx5 LQ0KICAgc3RhbmRhcmRpemVkIE8vVFdBTVAgc2VjdXJpdHkgbWVjaGFuaXNtIG9ubHkgc3VwcG9y dHMgYSBwcmUtc2hhcmVkDQogICBrZXkgbW9kZSwgbGFyZ2Ugc2NhbGUgZGVwbG95bWVudCBvZiBP L1RXQU1QIGlzIGhpbmRlcmVkDQogICBzaWduaWZpY2FudGx5LiAgQXQgdGhlIHNhbWUgdGltZSwg cmVjZW50IHRyZW5kcyBwb2ludCB0byB3aWRlciBJS0V2Mg0KICAgZGVwbG95bWVudCB3aGljaCwg aW4gdHVybiwgY2FsbHMgZm9yIG1lY2hhbmlzbXMgYW5kIG1ldGhvZHMgdGhhdA0KICAgZW5hYmxl IHR1bm5lbCBlbmQtdXNlcnMsIGFzIHdlbGwgYXMgb3BlcmF0b3JzLCB0byBtZWFzdXJlIG9uZS13 YXkgYW5kDQogICB0d28td2F5IG5ldHdvcmsgcGVyZm9ybWFuY2UgaW4gYSBzdGFuZGFyZGl6ZWQg bWFubmVyLiAgVGhpcyBkb2N1bWVudA0KICAgZGlzY3Vzc2VzIHRoZSB1c2Ugb2Yga2V5cyBkZXJp dmVkIGZyb20gYW4gSUtFdjIgU0EgYXMgdGhlIHNoYXJlZCBrZXkNCiAgIF5eXl5eXl5eXg0KICAg aW4gTy9UV0FNUC4gIElmIHRoZSBzaGFyZWQga2V5IGNhbiBiZSBkZXJpdmVkIGZyb20gdGhlIElL RXYyIFNBLCBPLw0KICAgVFdBTVAgY2FuIHN1cHBvcnQgY2VydGlmaWNhdGUtYmFzZWQga2V5IGV4 Y2hhbmdlLCB3aGljaCB3b3VsZCBhbGxvdw0KICAgZm9yIG1vcmUgb3BlcmF0aW9uYWwgZmxleGli aWxpdHkgYW5kIGVmZmljaWVuY3kuICBUaGUga2V5IGRlcml2YXRpb24NCiAgIHByZXNlbnRlZCBp biB0aGlzIGRvY3VtZW50IGNhbiBhbHNvIGZhY2lsaXRhdGUgYXV0b21hdGljIGtleQ0KICAgbWFu YWdlbWVudC4NCg0KImRpc2N1c3NlcyB0aGUgdXNlIG9mIGtleXMiIHByb2JhYmx5IGlzbid0IHF1 aXRlIHJpZ2h0IGZvciBhIFByb3Bvc2VkIFN0YW5kYXJkLiBJbiBTZWN0aW9uIDMsIHlvdSBzYXkg ImRlc2NyaWJlcyIuIFRoYXQncyBwcm9iYWJseSBiZXR0ZXIuDQoNCldoaWxlIHdlIGFyZSBpbiBT ZWN0aW9uIDMsIHRoaXMgdGV4dDoNCg0KMy4gIFNjb3BlIGFuZCBBcHBsaWNhYmlsaXR5DQoNCiAg IFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbWV0aG9kIGZvciBlbmFibGluZyBuZXR3b3JrIG1l YXN1cmVtZW50cw0KICAgYmV0d2VlbiBhIFRXQU1QIGNsaWVudCBhbmQgYSBUV0FNUCBzZXJ2ZXIg d2hpY2ggYm90aCBzdXBwb3J0IElQc2VjLg0KICAgSW4gc2hvcnQsIHRoZSBzaGFyZWQga2V5IHVz ZWQgZm9yIHNlY3VyaW5nIFRXQU1QIHRyYWZmaWMgaXMgZGVyaXZlZA0KICAgdXNpbmcgSUtFdjIg W1JGQzcyOTZdLiAgVGhpcyBkb2N1bWVudCByZXNlcnZlcyBmcm9tIHRoZSBUV0FNUC1Nb2Rlcw0K ICAgcmVnaXN0cnkgdGhlIE1vZGUgdmFsdWUgSUtFdjJEZXJpdmVkIHdoaWNoIGlzIGVxdWFsIHRv IDEyOCAoaS5lLiBiaXQNCiAgIHNldCBpbiBwb3NpdGlvbiA3KSBbTk9URSB0byBJQU5BOiByZW1v dmUgYmVmb3JlIGFsbG9jYXRpb24gYW5kIGZpbmFsDQogICBwdWJsaWNhdGlvbl0gYW5kIE1VU1Qg YmUgdXNlZCBieSBUV0FNUCBpbXBsZW1lbnRhdGlvbnMgY29tcGF0aWJsZQ0KICAgd2l0aCB0aGlz IHNwZWNpZmljYXRpb24uDQoNCiAgIEFsdGhvdWdoIHRoZSBjb250cm9sIHByb2NlZHVyZXMgZGVz Y3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgYXJlDQogICBhcHBsaWNhYmxlIHRvIE9XQU1QIHBlciBz ZSwgdGhlIGxhY2sgb2YgYW4gZXN0YWJsaXNoZWQgSUFOQSByZWdpc3RyeQ0KICAgZm9yIE9XQU1Q IE1vZGUgdmFsdWVzIHRlY2huaWNhbGx5IHByZXZlbnRzIHVzIGZyb20gZXh0ZW5kaW5nIE9XQU1Q DQogICBNb2RlIHZhbHVlcy4gIFRoZXJlZm9yZSwgaW5kZXBlbmRlbnQgT1dBTVAgaW1wbGVtZW50 YXRpb25zIFNIT1VMRCBiZQ0KICAgY2hlY2tlZCBmb3IgZnVsbCBjb21wYXRpYmlsaXR5IHdpdGgg cmVzcGVjdCB0byB0aGUgdXNlIG9mIHRoaXMgTW9kZQ0KICAgdmFsdWUuICBVbnRpbCBhbiBJQU5B IHJlZ2lzdHJ5IGZvciBPV0FNUCBNb2RlIHZhbHVlcyBpcyBlc3RhYmxpc2hlZCwNCiAgIHRoZSB1 c2UgdGhpcyBmZWF0dXJlIGluIE9XQU1QIGltcGxlbWVudGF0aW9ucyBNVVNUIGJlIGFycmFuZ2Vk DQogICBwcml2YXRlbHkgYW1vbmcgY29uc2VudGluZyBPV0FNUCB1c2Vycy4NCg0KaXMgdGhlIGZp cnN0IHBsYWNlIEkgdW5kZXJzdG9vZCBjbGVhcmx5IHdoYXQgdGhlIGRvY3VtZW50IGlzIGRvaW5n LiBQZXJoYXBzIHRoZSBmaXJzdCB0d28gc2VudGVuY2VzIGNvdWxkIGdvIGluIHRoZSBJbnRyb2R1 Y3Rpb24sIHNvIHlvdSdkIGJlIGludHJvZHVjaW5nIHdoYXQgdGhlIGRvY3VtZW50IGRvZXMgaW4g dGhlIEludHJvZHVjdGlvbj8gOy0pDQoNCkluIHRoaXMgdGV4dCBpbiA1LjEuICBTaGFyZWQgS2V5 IERlcml2YXRpb24NCg0KICAgV2hlbiB0aGUgc2hhcmVkIHNlY3JldCBrZXkgaXMgZGVyaXZlZCBm cm9tIHRoZSBJS0V2MiBTQSwgU0tfZCBtdXN0IGJlDQogICBnZW5lcmF0ZWQgZmlyc3QuICBTS19k IE1VU1QgYmUgY29tcHV0ZWQgYXMgcGVyIFtSRkM3Mjk2XS4NCg0KICAgVGhlIHNoYXJlZCBzZWNy ZXQga2V5IE1VU1QgYmUgZ2VuZXJhdGVkIGFzIGZvbGxvd3M6DQoNCiAgICAgIFNoYXJlZCBzZWNy ZXQga2V5ID0gUFJGKCBTS19kLCAiSVBQTSIgKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBe Xl4NCg0KICAgV2hlcmVpbiB0aGUgc3RyaW5nICJJUFBNIiBjb21wcmlzZXMgZm91ciBBU0NJSSBj aGFyYWN0ZXJzIGFuZCBwcmYgaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXl5eDQogICBhIHBzZXVkb3JhbmRvbSBmdW5j dGlvbi4NCg0KSXMgaXQgY29tbW9uIHVzYWdlIHRvIGNhcGl0YWxpemUgIlBSRiIgaW4gdGhlIGFs Z29yaXRobSwgYnV0IG5vdCBpbiB0aGUgZGVmaW5pdGlvbj8gT3IsIGFuZCB0aGlzIGlzIGVxdWFs bHkgbGlrZWx5LCB0aGVyZSdzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4gIlBSRiIgYW5kICJwcmYi IHRoYXQgSSBkb24ndCB1bmRlcnN0YW5kPw0KDQpJbiB0aGlzIHRleHQ6IDUuMi4gIFNlcnZlciBH cmVldGluZyBNZXNzYWdlIFVwZGF0ZQ0KDQogICBUbyBhY2hpZXZlIGEgYmluZGluZyBhc3NvY2lh dGlvbiBiZXR3ZWVuIHRoZSBrZXkgZ2VuZXJhdGVkIGZyb20gSUtFdjINCiAgIGFuZCB0aGUgTy9U V0FNUCBzaGFyZWQgc2VjcmV0IGtleSwgU2VydmVyIEdyZWV0aW5nIE1lc3NhZ2Ugc2hvdWxkIGJl DQogICB1cGRhdGVkIGFzIGluIEZpZ3VyZSAyLg0KICAgXl5eXl5eXg0KDQpJJ20gc29ycnksIGJ1 dCBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCBpdCBtZWFucyB0byAidXBkYXRlIiBhIG1lc3NhZ2Uu IENvdWxkIHlvdSBoZWxwIG1lIGhlcmU/IElmIEkgd2FzIGd1ZXNzaW5nLCBJJ2QgZ3Vlc3MgInNo b3VsZCBpbmNsdWRlIHRoZXNlIGV4dGVuc2lvbnMsIGFzIGluIEZpZ3VyZSAyIiwgYnV0IHRoYXQn cyBhIGd1ZXNzLg0K --_000_0C7EDCF89AB9E2478B5D010026CFF4AEB5AB7485D6SBS2008eictlo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRS1NYWlsRm9ybWF0 dm9ybGFnZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44 NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBsYW5nPURFIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlv bjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5N YW55IHRoYW5rcyBTcGVuY2VyLiBXZSBoYXZlIG5vdyB1cGRhdGVkIHRoZSBkb2N1bWVudCBhcyBw ZXIgeW91ciBzdWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+S29zdGFzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xh c3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Wb246PC9zcGFuPjwvYj48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIFttYWlsdG86c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb21dIDxicj48Yj5HZXNlbmRldDo8L2I+IEZyZWl0YWcsIDE2LiBKYW51 YXIgMjAxPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+NSAxNzo0MDxicj48Yj5Bbjo8L2I+IEJyaWFuIFRyYW1tZWxs PGJyPjxiPkNjOjwvYj4gaXBwbS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcgQ2hhaXJzOyBpZXNnLXNl Y3JldGFyeUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLmFsbEB0b29scy5pZXRmLm9y ZzsgaXBwbUBpZXRmLm9yZzxicj48Yj5CZXRyZWZmOjwvYj4gUmU6IFB1YmxpY2F0aW9uIGhhcyBi ZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLTA3PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+SGksIEJyaWFuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+T24gVHVlLCBKYW4gNiwgMjAxNSBh dCA0OjI0IEFNLCBCcmlhbiBUcmFtbWVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1l bGwuY2giIHRhcmdldD0iX2JsYW5rIj5pZXRmQHRyYW1tZWxsLmNoPC9hPiZndDsgd3JvdGU6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+QnJpYW4gVHJhbW1lbGwgaGFzIHJlcXVlc3RlZCBwdWJsaWNh dGlvbiBvZiBkcmFmdC1pZXRmLWlwcG0taXBzZWMtMDcgYXMgUHJvcG9zZWQgU3RhbmRhcmQgb24g YmVoYWxmIG9mIHRoZSBJUFBNIHdvcmtpbmcgZ3JvdXAuPGJyPjxicj5QbGVhc2UgdmVyaWZ5IHRo ZSBkb2N1bWVudCdzIHN0YXRlIGF0IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLzwvYT48L3NwYW4+PG86 cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPkkndmUgZG9uZSB0aGUgQUQgZXZhbHVhdGlvbiBmb3IgdGhpcyBkb2MsIGFu ZCBhbSBtb3N0bHkgZmluZSB3aXRoIGl0LCBidXQgaGFkIHNvbWUgc3VnZ2VzdGlvbnMgdGhhdCBJ IHdhbnRlZCB0byBzaGFyZSB3aXRoIHlvdSBiZWZvcmUgTGFzdCBDYWxsLiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+SSB3YW50IHRvIGVtcGhhc2l6ZSB0aGF0IHRoZXNlIGFyZSBl aXRoZXIgbml0cyBvciBjbG9zZSB0byBuaXRzLCBidXQgZm91bmQgdGhhdCBJIGRpZG4ndCB1bmRl cnN0YW5kIHRoZSBkcmFmdCBjbGVhcmx5IHdoZW4gSSBlbmNvdW50ZXJlZCB0aGVtLjxicj48YnI+ SWYgeW91J2QgbGlrZSB0byBkbyBhIG1pbm9yIHJldmlzaW9uLCB0aGF0IHdvdWxkIGJlIGZpbmUs IG9yIGlmIHlvdSdkIGxpa2UgdG8gdGVsbCBtZSB0aGF0IHNtYXJ0IHBlb3BsZSBjYW4gdW5kZXJz dGFuZCB0aGUgc3R1ZmYgdGhhdCB3YXNuJ3QgY2xlYXIgdG8gbWUsIHRoYXQgd291bGQgYmUgZmlu ZSwgb3IgaWYgeW91J2QgbGlrZSBtZSB0byBpc3N1ZSBMYXN0IENhbGwgYW5kIHRoZW4gcG9zdCBt eSBjb21tZW50cywgdGhhdCB3b3VsZCBiZSBmaW5lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+SnVzdCBsZXQgbWUga25vdyEgQW5kIHRoYW5rcywgYXMgYWx3YXlzIC4uLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+U3BlbmNlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+LS0g bXkgbm90ZXMgZm9sbG93IC0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz5JbiB0aGlzIHRl eHQsIGluIHRoZSBBYnN0cmFjdDo8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkFic3RyYWN0 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7VGhlIE8vVFdBTVAgc2Vj dXJpdHkgbWVjaGFuaXNtIHJlcXVpcmVzIHRoYXQgYm90aCB0aGUgY2xpZW50IGFuZDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO3NlcnZlciBlbmRwb2ludHMg cG9zc2VzcyBhIHNoYXJlZCBzZWNyZXQuJm5ic3A7IFNpbmNlIHRoZSBjdXJyZW50bHktPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7c3RhbmRhcmRpemVkIE8v VFdBTVAgc2VjdXJpdHkgbWVjaGFuaXNtIG9ubHkgc3VwcG9ydHMgYSBwcmUtc2hhcmVkPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7a2V5IG1vZGUsIGxhcmdl IHNjYWxlIGRlcGxveW1lbnQgb2YgTy9UV0FNUCBpcyBoaW5kZXJlZDwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO3NpZ25pZmljYW50bHkuJm5ic3A7IEF0IHRo ZSBzYW1lIHRpbWUsIHJlY2VudCB0cmVuZHMgcG9pbnQgdG8gd2lkZXIgSUtFdjI8L3NwYW4+PG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDtkZXBsb3ltZW50IHdoaWNoLCBp biB0dXJuLCBjYWxscyBmb3IgbWVjaGFuaXNtcyBhbmQgbWV0aG9kcyB0aGF0PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7ZW5hYmxlIHR1bm5lbCBlbmQtdXNl cnMsIGFzIHdlbGwgYXMgb3BlcmF0b3JzLCB0byBtZWFzdXJlIG9uZS13YXkgYW5kPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7dHdvLXdheSBuZXR3b3JrIHBl cmZvcm1hbmNlIGluIGEgc3RhbmRhcmRpemVkIG1hbm5lci4mbmJzcDsgVGhpcyBkb2N1bWVudDwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO2Rpc2N1c3NlcyB0 aGUgdXNlIG9mIGtleXMgZGVyaXZlZCBmcm9tIGFuIElLRXYyIFNBIGFzIHRoZSBzaGFyZWQga2V5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7Xl5eXl5eXl5e PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7aW4gTy9UV0FN UC4mbmJzcDsgSWYgdGhlIHNoYXJlZCBrZXkgY2FuIGJlIGRlcml2ZWQgZnJvbSB0aGUgSUtFdjIg U0EsIE8vPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7VFdB TVAgY2FuIHN1cHBvcnQgY2VydGlmaWNhdGUtYmFzZWQga2V5IGV4Y2hhbmdlLCB3aGljaCB3b3Vs ZCBhbGxvdzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO2Zv ciBtb3JlIG9wZXJhdGlvbmFsIGZsZXhpYmlsaXR5IGFuZCBlZmZpY2llbmN5LiZuYnNwOyBUaGUg a2V5IGRlcml2YXRpb248L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAm bmJzcDtwcmVzZW50ZWQgaW4gdGhpcyBkb2N1bWVudCBjYW4gYWxzbyBmYWNpbGl0YXRlIGF1dG9t YXRpYyBrZXk8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDtt YW5hZ2VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+JnF1b3Q7ZGlzY3Vzc2VzIHRoZSB1 c2Ugb2Yga2V5cyZxdW90OyBwcm9iYWJseSBpc24ndCBxdWl0ZSByaWdodCBmb3IgYSBQcm9wb3Nl ZCBTdGFuZGFyZC4gSW4gU2VjdGlvbiAzLCB5b3Ugc2F5ICZxdW90O2Rlc2NyaWJlcyZxdW90Oy4g VGhhdCdzIHByb2JhYmx5IGJldHRlci48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPldoaWxl IHdlIGFyZSBpbiBTZWN0aW9uIDMsIHRoaXMgdGV4dDo8L3NwYW4+PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjMuJm5ic3A7IFNjb3BlIGFuZCBBcHBsaWNhYmlsaXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBtZXRob2QgZm9y IGVuYWJsaW5nIG5ldHdvcmsgbWVhc3VyZW1lbnRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mbmJzcDsgJm5ic3A7YmV0d2VlbiBhIFRXQU1QIGNsaWVudCBhbmQgYSBUV0FNUCBz ZXJ2ZXIgd2hpY2ggYm90aCBzdXBwb3J0IElQc2VjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO0luIHNob3J0LCB0aGUgc2hhcmVkIGtleSB1c2VkIGZvciBz ZWN1cmluZyBUV0FNUCB0cmFmZmljIGlzIGRlcml2ZWQ8L3NwYW4+PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZuYnNwOyAmbmJzcDt1c2luZyBJS0V2MiBbUkZDNzI5Nl0uJm5ic3A7IFRoaXMg ZG9jdW1lbnQgcmVzZXJ2ZXMgZnJvbSB0aGUgVFdBTVAtTW9kZXM8L3NwYW4+PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDtyZWdpc3RyeSB0aGUgTW9kZSB2YWx1ZSBJS0V2 MkRlcml2ZWQgd2hpY2ggaXMgZXF1YWwgdG8gMTI4IChpLmUuIGJpdDwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO3NldCBpbiBwb3NpdGlvbiA3KSBbTk9URSB0 byBJQU5BOiByZW1vdmUgYmVmb3JlIGFsbG9jYXRpb24gYW5kIGZpbmFsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7cHVibGljYXRpb25dIGFuZCBNVVNUIGJl IHVzZWQgYnkgVFdBTVAgaW1wbGVtZW50YXRpb25zIGNvbXBhdGlibGU8L3NwYW4+PG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDt3aXRoIHRoaXMgc3BlY2lmaWNhdGlvbi48 L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDtBbHRob3VnaCB0aGUgY29u dHJvbCBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFyZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO2FwcGxpY2FibGUgdG8gT1dBTVAg cGVyIHNlLCB0aGUgbGFjayBvZiBhbiBlc3RhYmxpc2hlZCBJQU5BIHJlZ2lzdHJ5PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7Zm9yIE9XQU1QIE1vZGUgdmFs dWVzIHRlY2huaWNhbGx5IHByZXZlbnRzIHVzIGZyb20gZXh0ZW5kaW5nIE9XQU1QPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7TW9kZSB2YWx1ZXMuJm5ic3A7 IFRoZXJlZm9yZSwgaW5kZXBlbmRlbnQgT1dBTVAgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBiZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7ICZuYnNwO2NoZWNrZWQgZm9y IGZ1bGwgY29tcGF0aWJpbGl0eSB3aXRoIHJlc3BlY3QgdG8gdGhlIHVzZSBvZiB0aGlzIE1vZGU8 L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDt2YWx1ZS4mbmJz cDsgVW50aWwgYW4gSUFOQSByZWdpc3RyeSBmb3IgT1dBTVAgTW9kZSB2YWx1ZXMgaXMgZXN0YWJs aXNoZWQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7dGhl IHVzZSB0aGlzIGZlYXR1cmUgaW4gT1dBTVAgaW1wbGVtZW50YXRpb25zIE1VU1QgYmUgYXJyYW5n ZWQ8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDtwcml2YXRl bHkgYW1vbmcgY29uc2VudGluZyBPV0FNUCB1c2Vycy48L3NwYW4+PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZuYnNwOyAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PmlzIHRoZSBmaXJzdCBwbGFjZSBJIHVuZGVyc3Rvb2QgY2xlYXJseSB3aGF0IHRoZSBkb2N1bWVu dCBpcyBkb2luZy4gUGVyaGFwcyB0aGUgZmlyc3QgdHdvIHNlbnRlbmNlcyBjb3VsZCBnbyBpbiB0 aGUgSW50cm9kdWN0aW9uLCBzbyB5b3UnZCBiZSBpbnRyb2R1Y2luZyB3aGF0IHRoZSBkb2N1bWVu dCBkb2VzIGluIHRoZSBJbnRyb2R1Y3Rpb24/IDstKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+SW4gdGhpcyB0ZXh0IGluIDUuMS4mbmJzcDsgU2hhcmVkIEtleSBEZXJpdmF0aW9uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7V2hlbiB0aGUgc2hhcmVkIHNlY3Jl dCBrZXkgaXMgZGVyaXZlZCBmcm9tIHRoZSBJS0V2MiBTQSwgU0tfZCBtdXN0IGJlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7Z2VuZXJhdGVkIGZpcnN0LiZu YnNwOyBTS19kIE1VU1QgYmUgY29tcHV0ZWQgYXMgcGVyIFtSRkM3Mjk2XS48L3NwYW4+PG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDtUaGUgc2hhcmVkIHNlY3JldCBrZXkgTVVTVCBi ZSBnZW5lcmF0ZWQgYXMgZm9sbG93czo8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNw OyAmbmJzcDsgJm5ic3A7IFNoYXJlZCBzZWNyZXQga2V5ID0gUFJGKCBTS19kLCAmcXVvdDtJUFBN JnF1b3Q7ICk8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBeXl48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNw OyAmbmJzcDtXaGVyZWluIHRoZSBzdHJpbmcgJnF1b3Q7SVBQTSZxdW90OyBjb21wcmlzZXMgZm91 ciBBU0NJSSBjaGFyYWN0ZXJzIGFuZCBwcmYgaXM8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Xl5ePC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5i c3A7YSBwc2V1ZG9yYW5kb20gZnVuY3Rpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz5J cyBpdCBjb21tb24gdXNhZ2UgdG8gY2FwaXRhbGl6ZSAmcXVvdDtQUkYmcXVvdDsgaW4gdGhlIGFs Z29yaXRobSwgYnV0IG5vdCBpbiB0aGUgZGVmaW5pdGlvbj8gT3IsIGFuZCB0aGlzIGlzIGVxdWFs bHkgbGlrZWx5LCB0aGVyZSdzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4gJnF1b3Q7UFJGJnF1b3Q7 IGFuZCAmcXVvdDtwcmYmcXVvdDsgdGhhdCBJIGRvbid0IHVuZGVyc3RhbmQ/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQ291cmllciBOZXciJz5JbiB0aGlzIHRleHQ6IDUuMi4mbmJzcDsgU2VydmVyIEdyZWV0aW5n IE1lc3NhZ2UgVXBkYXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5ic3A7 VG8gYWNoaWV2ZSBhIGJpbmRpbmcgYXNzb2NpYXRpb24gYmV0d2VlbiB0aGUga2V5IGdlbmVyYXRl ZCBmcm9tIElLRXYyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsgJm5i c3A7YW5kIHRoZSBPL1RXQU1QIHNoYXJlZCBzZWNyZXQga2V5LCBTZXJ2ZXIgR3JlZXRpbmcgTWVz c2FnZSBzaG91bGQgYmU8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyAm bmJzcDt1cGRhdGVkIGFzIGluIEZpZ3VyZSAyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jm5ic3A7ICZuYnNwO15eXl5eXl48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZuYnNwOyAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkknbSBz b3JyeSwgYnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IGl0IG1lYW5zIHRvICZxdW90O3VwZGF0 ZSZxdW90OyBhIG1lc3NhZ2UuIENvdWxkIHlvdSBoZWxwIG1lIGhlcmU/IElmIEkgd2FzIGd1ZXNz aW5nLCBJJ2QgZ3Vlc3MgJnF1b3Q7c2hvdWxkIGluY2x1ZGUgdGhlc2UgZXh0ZW5zaW9ucywgYXMg aW4gRmlndXJlIDImcXVvdDssIGJ1dCB0aGF0J3MgYSBndWVzcy4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRt bD4= --_000_0C7EDCF89AB9E2478B5D010026CFF4AEB5AB7485D6SBS2008eictlo_-- From nobody Mon Jan 26 07:05:52 2015 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 9EA741A9025 for ; Mon, 26 Jan 2015 07:05:50 -0800 (PST) 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 kEf9wgGUSvNr; Mon, 26 Jan 2015 07:05:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB1B1A8918; Mon, 26 Jan 2015 07:05:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-ippm-ipsec.all@tools.ietf.org, ietf@trammell.ch, ippm-chairs@tools.ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126150549.19376.94466.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 07:05:49 -0800 From: IETF Secretariat Archived-At: Subject: [ippm] ID Tracker State Update Notice: 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: Mon, 26 Jan 2015 15:05:50 -0000 IESG state changed to Last Call Requested from AD Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ From nobody Mon Jan 26 07:26:20 2015 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 C5C291A906E; Mon, 26 Jan 2015 07:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 U65A19dsX_v2; Mon, 26 Jan 2015 07:26:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D64411A1A5A; Mon, 26 Jan 2015 07:26:09 -0800 (PST) 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.10.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150126152609.24327.45673.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 07:26:09 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] Last Call: (IKEv2-based Shared Secret Key for O/TWAMP) to Proposed Standard X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 15:26:11 -0000 The IESG has received a request from the IP Performance Metrics WG (ippm) to consider the following document: - 'IKEv2-based Shared Secret Key for O/TWAMP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 describes 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jan 26 07:26:22 2015 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 3DF621A8F4A for ; Mon, 26 Jan 2015 07:26:17 -0800 (PST) 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 Py_JyL-fhHIg; Mon, 26 Jan 2015 07:26:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3621A8FD3; Mon, 26 Jan 2015 07:26:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: draft-ietf-ippm-ipsec.all@tools.ietf.org, ietf@trammell.ch, ippm-chairs@tools.ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126152611.24327.94332.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 07:26:11 -0800 From: IETF Secretariat Archived-At: Subject: [ippm] ID Tracker State Update Notice: 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: Mon, 26 Jan 2015 15:26:17 -0000 Last call has been made for draft-ietf-ippm-ipsec and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec/ From nobody Mon Jan 26 13:14:35 2015 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 885911A1B12 for ; Mon, 26 Jan 2015 13:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 EuhqCqgOV675 for ; Mon, 26 Jan 2015 13:14:27 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 785491A6EF1 for ; Mon, 26 Jan 2015 13:14:27 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 7B2AF120B15; Mon, 26 Jan 2015 16:28:44 -0500 (EST) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.240.40]) by mail-blue.research.att.com (Postfix) with ESMTP id DDE12F042B; Mon, 26 Jan 2015 16:14:26 -0500 (EST) Received: from NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea]) by NJFPSRVEXG0.research.att.com ([fe80::c5dd:2310:7197:58ea%17]) with mapi; Mon, 26 Jan 2015 16:14:26 -0500 From: "MORTON, ALFRED C (AL)" To: "Ruediger.Geib@telekom.de" , "ippm@wjcerveny.com" Date: Mon, 26 Jan 2015 16:14:23 -0500 Thread-Topic: [ippm] WGLC for draft-ietf-ippm-2679-bis-00 and draft-ietf-ippm-2680-bis-00 Thread-Index: AdApyLUzOrAm1iNQRqu8LIjps0K7OgAhUu4gA9ebSZA= Message-ID: <4AF73AA205019A4C8A1DDD32C034631D873E25C1@NJFPSRVEXG0.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4AF73AA205019A4C8A1DDD32C034631D873E25C1NJFPSRVEXG0rese_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ippm-2679-bis@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [ippm] WGLC for draft-ietf-ippm-2679-bis-00 and draft-ietf-ippm-2680-bis-00 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, 26 Jan 2015 21:14:32 -0000 --_000_4AF73AA205019A4C8A1DDD32C034631D873E25C1NJFPSRVEXG0rese_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi R=FCdiger, Thanks for your review and comments (again). This is one of several drafts where I'm taking your advice and updating the term "precedence". The WGLC closed last week, so I've updated both drafts, including several comments from original author (and IPPM WG co-chair) Guy Almes, and a few typos/editorial points. regards, Al From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Sent: Wednesday, January 07, 2015 7:41 AM To: ippm@wjcerveny.com; MORTON, ALFRED C (AL) Cc: ippm@ietf.org Subject: AW: [ippm] WGLC for draft-ietf-ippm-2679-bis-00 and draft-ietf-ipp= m-2680-bis-00 Bill, Al thanks. both drafts read good and I hope they will get RFC's soon. I however missed one QoS related point during an earlier review I made: 3.6 Methodologies: As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence). If precedence refers to Type of Service, which has been changed to DSCP mea= nwhile, then precedence should be changed to DSCP (and/or ECN codepoint) or= DS field. There is no IP precedence specified for IPv6. 3.8.1. Type-P . . .The value of Type-P-One-way-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP precedence or RSVP) changes. . . If precedence refers to Type of Service, which has been changed to DSCP mea= nwhile, then precedence should be changed to DSCP (and/or ECN codepoint) or= DS field. There is no IP precedence specified for IPv6. And the same comment also relates to draft-ietf-ippm-2680-bis-00: 2.6 Methodologies: As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence). If precedence refers to Type of Service, which has been changed to DSCP mea= nwhile, then precedence should be changed to DSCP (and/or ECN codepoint) or= DS field. There is no IP precedence specified for IPv6. 2.8.1 Type-P . . The value of Type-P-One-way-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP precedence or RSVP) changes... If precedence refers to Type of Service, which has been changed to DSCP mea= nwhile, then precedence should be changed to DSCP (and/or ECN codepoint) or= DS field. There is no IP precedence specified for IPv6. And one nit: 7. RFC 2680 bis ...9. No content. Otherwise my comment is go ahead with both drafts. Regards, Ruediger Von: ippm [mailto:ippm-bounces@ietf.org] Gesendet: Dienstag, 6. Januar 2015 16:52 An: ippm@ietf.org Betreff: [ippm] WGLC for draft-ietf-ippm-2679-bis-00 and draft-ietf-ippm-26= 80-bis-00 As discussed at the IETF meeting, drafts draft-ietf-ippm-2679-bis-00 (A One= -Way Delay Metric for IPPM) and draft-ietf-ippm-2680-bis-00 (A One-Way Loss= Metric for IPPM) are ready for Working Group Last Call (WGLC). As such, th= ese documents will be in WGLC until Friday, January 23, 2014. Please send comments to ippm@ietf.org, including stat= ements that you've reviewed the document and are okay with sending it up to= the IESG for publication. For those new to IETF process, the WGLC process is discussed at: - https://tools.ietf.org/html/rfc2418#section-7.4 - https://tools.ietf.org/html/rfc6174#section-4.2.7 Basic information on the documents is below. 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 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 Regards, Bill Cerveny IPPM WG Co-chair --_000_4AF73AA205019A4C8A1DDD32C034631D873E25C1NJFPSRVEXG0rese_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi R=FCdiger,<= /p>

 

Thanks for your review and comment= s (again). This is one of

several drafts where I'= m taking your advice and updating the

term "= precedence".

 

=

including several comments from original author (and IPPM WG<= /o:p>

co-chair) Guy Almes, and a few typos/editorial points.=

 

regards,

Al

 

 

Fro= m: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
Sen= t: Wednesday, January 07, 2015 7:41 AM
To: ippm@wjcerveny.com= ; MORTON, ALFRED C (AL)
Cc: ippm@ietf.org
Subject: AW: = [ippm] WGLC for draft-ietf-ippm-2679-bis-00 and draft-ietf-ippm-2680-bis-00=

 

Bill, Al

 

thanks.= both drafts read good and I hope they will get RFC’s soon.

 

I however missed one QoS related point during an earli= er review I made:

&nb= sp;

3.6 Methodologies:=

 

 = ;  As with other Type-P-* metrics, the detailed methodology will depen= d

   on the Type-P (e.g.,= protocol number, UDP/TCP port number, size,

   precedence).

If precedence ref= ers to Type of Service, which has been changed to DSCP meanwhile, then prec= edence should be changed to DSCP (and/or ECN codepoint) or DS field. There = is no IP precedence specified for IPv6.

 

3.8.1. Type-P

 

    . . .The value of Type-P-One-way-Delay could change i= f the

   protocol (UDP or= TCP), port number, size, or arrangement for special

<= p class=3DMsoNormal>   treatment (e.g., IP precedence or RSVP) chan= ges. . .

 

If precedence refers to Type of Service, whic= h has been changed to DSCP meanwhile, then precedence should be changed to = DSCP (and/or ECN codepoint) or DS field. There is no IP precedence specifie= d for IPv6.

 

And the same comment also relates= to draft-ietf-ippm-2680-bis-00:

=  

2.6 Methodologies:

 

   As with other Type-P-* metrics, the detailed method= ology will depend

   on t= he Type-P (e.g., protocol number, UDP/TCP port number, size,

   precedence).

If= precedence refers to Type of Service, which has been changed to DSCP meanw= hile, then precedence should be changed to DSCP (and/or ECN codepoint) or D= S field. There is no IP precedence specified for IPv6.

 

2.8.1 Ty= pe-P

 

   protocol = (UDP or TCP), port number, size, or arrangement for special

   treatment (e.g., IP precedence or RSV= P) changes...

 =

If precedence refers to Type o= f Service, which has been changed to DSCP meanwhile, then precedence should= be changed to DSCP (and/or ECN codepoint) or DS field. There is no IP prec= edence specified for IPv6.

 

And one nit: =

 =

7. RFC 2680 bis

 

…9.

 

No content.

 

Otherwise my com= ment is go ahead with both drafts.

 

Regards,

 

Ruediger

 

 

 

Von: ippm [mailto:ippm-bounces@ietf.org] =

Gesendet: Dienstag, 6. Ja= nuar 2015 16:52
An: ippm@ietf.or= g
Betreff: [ippm] WGLC for draft-ietf-ippm-2679-bis-00 and dr= aft-ietf-ippm-2680-bis-00

 

As discussed at the IETF meeting, drafts draft-ietf-ippm-26= 79-bis-00 (A One-Way Delay Metric for IPPM) and draft-ietf-ippm-2680-bis-00= (A One-Way Loss Metric for IPPM) are ready for Working Group Last Call (WG= LC). As such, these documents will be in WGLC until Friday, January 23, 201= 4.

&nbs= p;

Please s= end comments to ippm@ietf.org, in= cluding statements that you've reviewed the document and are okay with send= ing it up to the IESG for publication. 

 

For those new to IETF process, the = WGLC process is discussed at:

 

Basic information on the documents is below.<= o:p>

&= nbsp;

 = ;      Title         = ;  : A One-Way Delay Metric for IPPM
    &= nbsp;  Authors         : = Guy Almes
          &n= bsp;            = ;  Sunil Kalidindi
       &= nbsp;           &nbs= p;     Matt Zekauskas
    &= nbsp;           &nbs= p;        Al Morton
         &nb= sp;  Filename        : draft= -ietf-ippm-2679-bis-00.txt
  &nbs= p;         Pages   = ;        : 24
          &nbs= p; Date           =  : 2014-10-23

Abstract:
  This memo (RFC 2679 bis)= defines a metric for one-way delay of
  packets across Intern= et paths.  It builds on notions introduced and
  discusse= d in the IPPM Framework document, RFC 2330; the reader is
  as= sumed to be familiar with that document.



The IETF datatracke= r 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

 

<= /div>

       T= itle           : A One-Wa= y Loss Metric for IPPM
       Authors=         : Guy Almes
  = ;            &n= bsp;          Sunil Kalid= indi
           &= nbsp;           &nbs= p; Matt Zekauskas
        &= nbsp;           &nbs= p;    Al Morton
 &= nbsp;          Filename=        : draft-ietf-ippm-2680-bis-00.tx= t
       = ;     Pages       =     : 19
  &n= bsp;         Date  &nbs= p;         : 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 do= cument, RFC 2330; the reader is assumed to be
  familiar with = that document.



The IETF datatracker status page for this dra= ft 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

 

Regards,

 

Bill Cerveny

IPPM WG Co-chair

= --_000_4AF73AA205019A4C8A1DDD32C034631D873E25C1NJFPSRVEXG0rese_-- From nobody Mon Jan 26 13:15:49 2015 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 177711B2A86; Mon, 26 Jan 2015 13:15:17 -0800 (PST) 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 qh5AxUyc_Vra; Mon, 26 Jan 2015 13:15:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E29F41A039D; Mon, 26 Jan 2015 13:14:57 -0800 (PST) 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.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126211457.14483.30462.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 13:14:57 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-2679-bis-01.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: Mon, 26 Jan 2015 21:15:17 -0000 X-List-Received-Date: Mon, 26 Jan 2015 21:15:17 -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-01.txt Pages : 24 Date : 2015-01-26 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-2679-bis-01 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 Mon Jan 26 13:16:06 2015 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 56A1D1A9139; Mon, 26 Jan 2015 13:15:47 -0800 (PST) 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 b54YiwOC9eCb; Mon, 26 Jan 2015 13:15:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED081B29A6; Mon, 26 Jan 2015 13:15:13 -0800 (PST) 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.10.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150126211513.14483.81062.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 13:15:13 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-2680-bis-01.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: Mon, 26 Jan 2015 21:15:48 -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-01.txt Pages : 19 Date : 2015-01-26 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-2680-bis-01 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 Mon Jan 26 18:05:54 2015 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 CD6361A1B3A for ; Mon, 26 Jan 2015 18:05:47 -0800 (PST) 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 Bqj1UtaRPPh2; Mon, 26 Jan 2015 18:05:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 655841A1B29; Mon, 26 Jan 2015 18:05:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf@wjcerveny.com, draft-ietf-ippm-rate-problem.all@tools.ietf.org, ippm-chairs@tools.ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150127020545.32608.6711.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 18:05:45 -0800 From: IETF Secretariat Archived-At: Subject: [ippm] ID Tracker State Update Notice: 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, 27 Jan 2015 02:05:49 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/