From nobody Wed Mar 1 01:37:05 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566761298B5 for ; Wed, 1 Mar 2017 01:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 st9Y-xZHfPSu for ; Wed, 1 Mar 2017 01:37:02 -0800 (PST) Received: from mail2.ficora.fi (mail2.ficora.fi [IPv6:2a00:13f0:0:1002:125:160:0:165]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B2812940C for ; Wed, 1 Mar 2017 01:37:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.35,224,1483999200"; d="scan'208";a="4251294" Received: from LOOTA.laru.local ([::1]) by loota.laru.local ([::1]) with mapi id 14.03.0319.002; Wed, 1 Mar 2017 11:36:58 +0200 From: Nieminen Klaus To: "ippm@ietf.org" Thread-Topic: Net Neutrality Measurements: Regulatory Use Case and Problem Statement Thread-Index: AdKSYq+SFJH/g2F0RqyUJ2PBX7w8sQ== Date: Wed, 1 Mar 2017 09:36:56 +0000 Message-ID: <6AF4522BD5AB86429CFD3948A9AB2F2F44ADA131@loota.laru.local> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.41.200.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [ippm] Net Neutrality Measurements: Regulatory Use Case and Problem Statement X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 09:37:04 -0000 RGVhciBhbGwsDQoNCkkgZ2F2ZSBhIHNob3J0IHByZXNlbnRhdGlvbiBhYm91dCB0aGlzIHRvcGlj IGluIElFVEYjOTcgYW5kIG5vdyBJJ20gaGFwcHkgdG8gaW5mb3JtIHRoYXQgdGhlIElEIGhhcyBi ZWVuIHB1Ymxpc2hlZC4NCi0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt bmllbWluZW4taXBwbS1ubi1tZWFzdXJlbWVudHMvDQoNCkkgaG9wZSB0aGlzIGhlbHBzIHRvIGlu Y3JlYXNlIHRoZSB1bmRlcnN0YW5kaW5nIGFib3V0ICB0aGUgbmV0IG5ldXRyYWxpdHkgbWVhc3Vy ZW1lbnRzIGluY2x1ZGluZyBRb1MgbWVhc3VyZW1lbnRzIHRoZSBFdXJvcGVhbiByZWd1bGF0b3Jz IGFyZSB0YXJnZXRpbmcuIA0KDQpIZXJlIEkgd291bGQgbGlrZSB0byBlbXBoYXNpcyBvbmUgYXNw ZWN0OiBSZWd1bGF0b3JzIGFyZSBtYWlubHkgaW50ZXJlc3RlZCBpbiBjcm93ZHNvdXJjaW5nIHNv bHV0aW9ucyB0aGF0IG1lYW5zIHdlIGhhdmUgdG8gdGFrZSBpbnRvIGFjY291bnQgdGhlIGxpbWl0 YXRpb25zIGZyb20gZGlmZmVyZW50IHdlYiBicm93c2Vycywgb3BlcmF0aW5nIHN5c3RlbXMgYW5k IG90aGVyIGVuZCB1c2VyIGVudmlyb25tZW50IGRlcGVuZGVudCBmYWN0b3JzIHRoYXQgbWF5IGFm ZmVjdCB0aGUgbWVhc3VyZW1lbnQgcmVzdWx0cy4gRm9yIGV4YW1wbGUgd2ViIGJyb3dzZXJzIGFu ZCBhcHBzIGNhbm5vdCBhbHdheXMgdXNlIGFsbCBwcm90b2NvbHMgb3IgbWVjaGFuaXNtcyBsaWtl IHJhdyBzb2NrZXRzLiAgQXMgdGhlIG1lYXN1cmVtZW50IGVudmlyb25tZW50IGlzIHJhdGhlciB1 bmNvbnRyb2xsZWQgd2Ugc2hvdWxkIGJlIGFibGUgZGV0ZWN0IGFuZC9vciBtZWFzdXJlIG1ldGFk YXRhIGFib3V0IHRoZSBlbmQtdXNlciBlbnZpcm9ubWVudCB0byBiZSBhYmxlIHRvIHJlY29nbml6 ZSBpZiB0aGVyZSBhcmUgZW5kIHVzZXIgZW52aXJvbm1lbnQgZGVwZW5kZW50IGZhY3RvcnMgdGhh dCBhZmZlY3QgdGhlIG1lYXN1cmVtZW50IHJlc3VsdHMuIFNvbWUgYXJlIGVhc3kgdG8gZGV0ZWN0 LCBidXQgZS5nLiBjcm9zcyB0cmFmZmljIG9yIGZpcmV3YWxscyBhcmUgbW9yZSBjaGFsbGVuZ2lu Zy4NCg0KU29tZSB0b3BpY3MgbGlrZSBzcGVlZCBtZWFzdXJlbWVudHMgYXJlIGJldHRlciB1bmRl cnN0b29kLCBidXQgZS5nLiBkZXRlY3RpbmcgdGhyb3R0bGluZyBvciBwcmlvcml0aXphdGlvbiBv ZiBzb21lIGFwcGxpY2F0aW9ucyBpcyBtb3JlIGNoYWxsZW5naW5nLg0KDQpBbGwgaW5wdXQgYW5k IGNvbW1lbnRzIGFyZSB3ZWxjb21lLA0KDQpCZXN0LA0KDQotIEtsYXVzDQoNCi0tLS0NCk5hbWU6 CQlkcmFmdC1uaWVtaW5lbi1pcHBtLW5uLW1lYXN1cmVtZW50cw0KUmV2aXNpb246CQkwMA0KVGl0 bGU6CQlOZXQgTmV1dHJhbGl0eSBNZWFzdXJlbWVudHM6IFJlZ3VsYXRvcnkgVXNlIENhc2UgYW5k IFByb2JsZW0gU3RhdGVtZW50DQpEb2N1bWVudCBkYXRlOgkyMDE3LTAyLTI3DQpHcm91cDoJCUlu ZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1uaWVtaW5lbi1pcHBtLW5uLW1lYXN1 cmVtZW50cy0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1uaWVtaW5lbi1pcHBtLW5uLW1lYXN1cmVtZW50cy8NCkh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbmllbWluZW4taXBwbS1ubi1t ZWFzdXJlbWVudHMtMDANCg0KQWJzdHJhY3Q6DQogIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEg cmVndWxhdG9yeSB1c2UgY2FzZSBmb3IgbmV0IG5ldXRyYWxpdHkNCiAgbWVhc3VyZW1lbnRzIGJh c2VkIG9uIHRoZSBuZXcgRXVyb3BlYW4gb3BlbiBpbnRlcm5ldCByZWd1bGF0aW9uDQogIFsxXS4g VGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudCBpcyB0byBnaXZlIHN1ZmZpY2llbnQgZGV0YWls cw0KICBmb3IgZGV2ZWxvcGluZyB0aGUgYWN0dWFsIG5ldCBuZXV0cmFsaXR5IG1lYXN1cmVtZW50 IG1ldHJpY3MuDQoNCiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHByb2JsZW0gc3RhdGVt ZW50LiAgQWNjb3JkaW5nIHRvIHRoZQ0KICBSZWd1bGF0aW9uIEV1cm9wZWFuIHJlZ3VsYXRvcnMg aGFzIHRvIHN1cGVydmlzZSBhbmQgZW5mb3JjZSB0aGUgbmV0DQogIG5ldXRyYWxpdHkgb2JsaWdh dGlvbnMuICBFc3BlY2lhbGx5IHRoZSByZWxpYWJpbGl0eSBvZiBtZWFzdXJlbWVudA0KICByZXN1 bHRzIGlzIGltcG9ydGFudC4gIEhvd2V2ZXIsIG1vbml0b3JpbmcgbmV0IG5ldXRyYWxpdHkgaXMg YQ0KICBjb21wbGV4IHRvcGljIGxhY2tpbmcgc3RhbmRhcmRpemVkIG1lYXN1cmVtZW50cy4NCg0K From nobody Wed Mar 1 03:01:29 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC93B1298A6; Wed, 1 Mar 2017 03:01:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148836608470.6288.1069034109067930297.idtracker@ietfa.amsl.com> Date: Wed, 01 Mar 2017 03:01:24 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-alt-mark-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 11:01:24 -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 of the IETF. Title : Alternate Marking method for passive performance monitoring Authors : Giuseppe Fioccola Alessandro Capello Mauro Cociglio Luca Castaldelli Mach(Guoyi) Chen Lianshu Zheng Greg Mirsky Tal Mizrahi Filename : draft-ietf-ippm-alt-mark-04.txt Pages : 30 Date : 2017-03-01 Abstract: This document describes a passive method to perform packet loss, delay and jitter measurements on live traffic. This method is based on Alternate Marking (Coloring) technique. A report on the operational experiment done at Telecom Italia is explained in order to give an example and show the method applicability. This technique can be applied in various situations as detailed in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-alt-mark-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-alt-mark-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 1 03:14:06 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AA31294F9; Wed, 1 Mar 2017 03:14:04 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EfB3Xktj-g3z; Wed, 1 Mar 2017 03:14:02 -0800 (PST) Received: from TELEDG001RM001.telecomitalia.it (teledg001rm001.telecomitalia.it [217.169.121.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C730129960; Wed, 1 Mar 2017 03:14:02 -0800 (PST) Received: from TELMBXA02RM001.telecomitalia.local (10.14.252.26) by TELEDG001RM001.telecomitalia.it (10.19.3.111) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 1 Mar 2017 12:14:00 +0100 Received: from TELMBXB02RM001.telecomitalia.local (10.14.252.27) by TELMBXA02RM001.telecomitalia.local (10.14.252.26) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 1 Mar 2017 12:13:59 +0100 Received: from TELMBXB02RM001.telecomitalia.local ([fe80::2845:411e:c732:e844]) by TELMBXB02RM001.telecomitalia.local ([fe80::2845:411e:c732:e844%20]) with mapi id 15.00.1263.000; Wed, 1 Mar 2017 12:13:59 +0100 From: Fioccola Giuseppe To: "ippm@ietf.org" , "ippm-chairs@ietf.org" Thread-Topic: [ippm] I-D Action: draft-ietf-ippm-alt-mark-04.txt Thread-Index: AQHSkntA4wxI7axoBE6Jub7o4cAAc6F/0myw Date: Wed, 1 Mar 2017 11:13:59 +0000 Message-ID: References: <148836608470.6288.1069034109067930297.idtracker@ietfa.amsl.com> In-Reply-To: <148836608470.6288.1069034109067930297.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.247] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ippm-alt-mark@ietf.org" , "MORTON, ALFRED C \(AL\) \(acmorton@att.com\)" Subject: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 11:14:04 -0000 Hi All, This new version of draft-ietf-ippm-alt-mark addresses comments received of= fline by Al Morton. Specifically we have added a note in which we suggest to calculate a high p= ercentile of the delay instead of the maximum. The problem with maximum delay is that it is influenced by outliers and cou= ld be misleading. In addition the reference to RFC 5481, particularly section 6.5, has been a= dded. Many Thanks to Al for the precious help, Best Regards, Giuseppe -----Messaggio originale----- Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di internet-drafts@ietf.o= rg Inviato: mercoled=EC 1 marzo 2017 12:01 A: i-d-announce@ietf.org Cc: ippm@ietf.org Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Performance Metrics of the IETF. Title : Alternate Marking method for passive performance = monitoring Authors : Giuseppe Fioccola Alessandro Capello Mauro Cociglio Luca Castaldelli Mach(Guoyi) Chen Lianshu Zheng Greg Mirsky Tal Mizrahi Filename : draft-ietf-ippm-alt-mark-04.txt Pages : 30 Date : 2017-03-01 Abstract: This document describes a passive method to perform packet loss, delay and jitter measurements on live traffic. This method is based on Alternate Marking (Coloring) technique. A report on the operational experiment done at Telecom Italia is explained in order to give an example and show the method applicability. This technique can be applied in various situations as detailed in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-alt-mark-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-alt-mark-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From nobody Wed Mar 1 07:01:59 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DCD129498 for ; Wed, 1 Mar 2017 07:01: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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 60_3yxDHJE-N for ; Wed, 1 Mar 2017 07:01:45 -0800 (PST) Received: from cnet.fi.uba.ar (cnet.fi.uba.ar [157.92.58.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6791294D7 for ; Wed, 1 Mar 2017 07:01:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cnet.fi.uba.ar (Postfix) with ESMTP id 20B71140077 for ; Wed, 1 Mar 2017 11:51:36 -0300 (ART) X-Virus-Scanned: Debian amavisd-new at cnet.fi.uba.ar Received: from cnet.fi.uba.ar ([127.0.0.1]) by localhost (cnet.fi.uba.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4f3qChGHMrF for ; Wed, 1 Mar 2017 11:51:28 -0300 (ART) Received: from MacBook-Pro-de-Esteban.local (www1.lacnog.org [179.0.156.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by cnet.fi.uba.ar (Postfix) with ESMTPSA id 4929F14006C for ; Wed, 1 Mar 2017 11:51:28 -0300 (ART) To: ippm@ietf.org References: <148836608470.6288.1069034109067930297.idtracker@ietfa.amsl.com> From: Esteban Carisimo Message-ID: <108443c6-f41c-f967-0d9b-5f508fdc07d7@cnet.fi.uba.ar> Date: Wed, 1 Mar 2017 12:01:30 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 15:01:53 -0000 Giuseppe, I do support your idea of incluing percentile since maximum values could be misleading. Moreover, it think it is actually a very good idea to include a suggestion instead of saying either one of the other is the right way of doing it. Altough the 99.9th percentile is included in a previous RFC, I was wondering if the 99.9th would be meaningful for every network or link. However, it think it is a nice way to start discussing about less sensitive parameters. Esteban Carisimo PhD student at CoNexDat (UBA-CONICET) http://cnet.fi.uba.ar/esteban_carisimo/en El 1/3/17 a las 8:13, Fioccola Giuseppe escribió: > Hi All, > This new version of draft-ietf-ippm-alt-mark addresses comments received offline by Al Morton. > Specifically we have added a note in which we suggest to calculate a high percentile of the delay instead of the maximum. > The problem with maximum delay is that it is influenced by outliers and could be misleading. > In addition the reference to RFC 5481, particularly section 6.5, has been added. > > Many Thanks to Al for the precious help, > > Best Regards, > > Giuseppe > > -----Messaggio originale----- > Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di internet-drafts@ietf.org > Inviato: mercoledì 1 marzo 2017 12:01 > A: i-d-announce@ietf.org > Cc: ippm@ietf.org > Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Performance Metrics of the IETF. > > Title : Alternate Marking method for passive performance monitoring > Authors : Giuseppe Fioccola > Alessandro Capello > Mauro Cociglio > Luca Castaldelli > Mach(Guoyi) Chen > Lianshu Zheng > Greg Mirsky > Tal Mizrahi > Filename : draft-ietf-ippm-alt-mark-04.txt > Pages : 30 > Date : 2017-03-01 > > Abstract: > This document describes a passive method to perform packet loss, > delay and jitter measurements on live traffic. This method is based > on Alternate Marking (Coloring) technique. A report on the > operational experiment done at Telecom Italia is explained in order > to give an example and show the method applicability. This technique > can be applied in various situations as detailed in this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ippm-alt-mark-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-alt-mark-04 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Wed Mar 1 07:23:55 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385B712953A for ; Wed, 1 Mar 2017 07:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 ENtKBGFIM0Lm for ; Wed, 1 Mar 2017 07:23:53 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 D6495129498 for ; Wed, 1 Mar 2017 07:23:52 -0800 (PST) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v21FFdD7041779; Wed, 1 Mar 2017 10:23:49 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 28wwg4585f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Mar 2017 10:23:49 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v21FNmB5007034; Wed, 1 Mar 2017 10:23:48 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v21FNcQK006830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Mar 2017 10:23:45 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 1 Mar 2017 15:23:24 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v21FNNZn005208; Wed, 1 Mar 2017 09:23:24 -0600 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v21FNH9T004683; Wed, 1 Mar 2017 09:23:18 -0600 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id 6067BE0342; Wed, 1 Mar 2017 10:23:17 -0500 (EST) Received: from njmtexg4.research.att.com ([fe80::8cd:baa3:219e:5bd4]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Wed, 1 Mar 2017 10:23:17 -0500 From: "MORTON, ALFRED C (AL)" To: Esteban Carisimo , "ippm@ietf.org" Thread-Topic: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-04.txt Thread-Index: AQHSkpzMhe96d8Og0k+G15jdKF5spaGAFreg Date: Wed, 1 Mar 2017 15:23:16 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25D30E14@njmtexg4.research.att.com> References: <148836608470.6288.1069034109067930297.idtracker@ietfa.amsl.com> <108443c6-f41c-f967-0d9b-5f508fdc07d7@cnet.fi.uba.ar> In-Reply-To: <108443c6-f41c-f967-0d9b-5f508fdc07d7@cnet.fi.uba.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.234.197] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-01_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1703010141 Archived-At: Subject: Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 15:23:54 -0000 Hi Esteban, If you look through RFC 5481 [0], you'll find that the idea of a "High Percentile" is included, based on the experience that different networks, or applications running on the networks, have different demands. I've used 95, 99, and 99.9 depending on the circumstances, and applying this sort of=20 statistic to packet transfer is fairly well understood=20 (RFC 5481 was approved in 2009 after much discussion in the IPPM WG). I also suggest RFC 2330, section 11.3 [1] which discusses the median and nails-down the definition of percentile for IPPM use (there is not a universally accepted definition of percentile, three interpretations are possible and we narrow down to one). These two references are a good starting point for any further discussions. regards, Al [0] https://tools.ietf.org/html/rfc5481 [1] https://tools.ietf.org/html/rfc2330#section-11.3 > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Esteban Carisimo > Sent: Wednesday, March 01, 2017 10:02 AM > To: ippm@ietf.org > Subject: Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-04.txt >=20 > Giuseppe, >=20 > I do support your idea of incluing percentile since maximum values could > be misleading. Moreover, it think it is actually a very good idea to > include a suggestion instead of saying either one of the other is the > right way of doing it. Altough the 99.9th percentile is included in a > previous RFC, I was wondering if the 99.9th would be meaningful for > every network or link. However, it think it is a nice way to start > discussing about less sensitive parameters. >=20 > Esteban Carisimo > PhD student at CoNexDat (UBA-CONICET) > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__cnet.fi.uba.ar_esteban-5Fcarisimo_en&d=3DDQIF-g&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DksehRnxmKX5kd4QUQA2LrW6Z= jOz > zg7n7QhD2I_6-x1Q&s=3DPPIhAtN3WQfhupyqoUqHuNvJG_MDe-D5EizhWgisivY&e=3D >=20 > El 1/3/17 a las 8:13, Fioccola Giuseppe escribi=F3: > > Hi All, > > This new version of draft-ietf-ippm-alt-mark addresses comments > received offline by Al Morton. > > Specifically we have added a note in which we suggest to calculate a > high percentile of the delay instead of the maximum. > > The problem with maximum delay is that it is influenced by outliers > and could be misleading. > > In addition the reference to RFC 5481, particularly section 6.5, has > been added. > > > > Many Thanks to Al for the precious help, > > > > Best Regards, > > > > Giuseppe > > > > -----Messaggio originale----- > > Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di internet- > drafts@ietf.org > > Inviato: mercoled=EC 1 marzo 2017 12:01 > > A: i-d-announce@ietf.org > > Cc: ippm@ietf.org > > Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-04.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IP Performance Metrics of the IETF. > > > > Title : Alternate Marking method for passive > performance monitoring > > Authors : Giuseppe Fioccola > > Alessandro Capello > > Mauro Cociglio > > Luca Castaldelli > > Mach(Guoyi) Chen > > Lianshu Zheng > > Greg Mirsky > > Tal Mizrahi > > Filename : draft-ietf-ippm-alt-mark-04.txt > > Pages : 30 > > Date : 2017-03-01 > > > > Abstract: > > This document describes a passive method to perform packet loss, > > delay and jitter measurements on live traffic. This method is > based > > on Alternate Marking (Coloring) technique. A report on the > > operational experiment done at Telecom Italia is explained in > order > > to give an example and show the method applicability. This > technique > > can be applied in various situations as detailed in this document. > > > > > > The IETF datatracker status page for this draft is: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-2Dmark_&d=3DDQIF- > g&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DksehRnxmKX5kd4QUQA2LrW6Z= jOz > zg7n7QhD2I_6-x1Q&s=3DNufcoUHHeeBrUi4UwaX45c4POeZnMB_k4AHIARjLfyw&e=3D > > > > There's also a htmlized version available at: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dalt-2Dmark-2D04&d=3DDQIF- > g&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DksehRnxmKX5kd4QUQA2LrW6Z= jOz > zg7n7QhD2I_6-x1Q&s=3D6WqdeohHv1UTz0U7nI6EgiPNiNNbO8lOsAbR9zEkXuM&e=3D > > > > A diff from the previous version is available at: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dippm-2Dalt-2Dmark- > 2D04&d=3DDQIF-g&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DksehRnxmKX5kd4QUQA2LrW6Z= jOz > zg7n7QhD2I_6-x1Q&s=3DYJWiIGFs3NwrQ_3uBbY6wxgIpbS8DhfZ-WRHUVa5bdA&e=3D > > > > > > 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: > > https://urldefense.proofpoint.com/v2/url?u=3Dftp- > 3A__ftp.ietf.org_internet-2Ddrafts_&d=3DDQIF-g&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DksehRnxmKX5kd4QUQA2LrW6Z= jOz > zg7n7QhD2I_6-x1Q&s=3DhQVaU10JwTjqeUKjQTEf-yQChqJ6TBAytiZ9BnRvGRY&e=3D > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDQIF-g&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DksehRnxmKX5kd4QUQA2LrW6Z= jOz > zg7n7QhD2I_6-x1Q&s=3DNI1_8wEhMMMtb01UikJBgRnJOxNN_bJ1obtzRSL3pAs&e=3D > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is unauthorised. > If you are not the intended recipient, please delete this message and > any attachments and advise the sender by return e-mail, Thanks. > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDQIF-g&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DksehRnxmKX5kd4QUQA2LrW6Z= jOz > zg7n7QhD2I_6-x1Q&s=3DNI1_8wEhMMMtb01UikJBgRnJOxNN_bJ1obtzRSL3pAs&e=3D >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_ippm&d=3DDQIF-g&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DOfsSu8kTIltVyD1oL72cBw&m=3DksehRnxmKX5kd4QUQA2LrW6Z= jOz > zg7n7QhD2I_6-x1Q&s=3DNI1_8wEhMMMtb01UikJBgRnJOxNN_bJ1obtzRSL3pAs&e=3D From nobody Wed Mar 1 07:38:37 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD713129572 for ; Wed, 1 Mar 2017 07:38:35 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ZftopcTyhW0c for ; Wed, 1 Mar 2017 07:38:33 -0800 (PST) Received: from cnet.fi.uba.ar (cnet.fi.uba.ar [157.92.58.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13872129570 for ; Wed, 1 Mar 2017 07:38:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cnet.fi.uba.ar (Postfix) with ESMTP id 2D736140077; Wed, 1 Mar 2017 12:28:26 -0300 (ART) X-Virus-Scanned: Debian amavisd-new at cnet.fi.uba.ar Received: from cnet.fi.uba.ar ([127.0.0.1]) by localhost (cnet.fi.uba.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZV1D63kXjIi; Wed, 1 Mar 2017 12:28:16 -0300 (ART) Received: from MacBook-Pro-de-Esteban.local (www1.lacnog.org [179.0.156.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by cnet.fi.uba.ar (Postfix) with ESMTPSA id 3FE2714006C; Wed, 1 Mar 2017 12:28:16 -0300 (ART) To: "MORTON, ALFRED C (AL)" , "ippm@ietf.org" References: <148836608470.6288.1069034109067930297.idtracker@ietfa.amsl.com> <108443c6-f41c-f967-0d9b-5f508fdc07d7@cnet.fi.uba.ar> <4D7F4AD313D3FC43A053B309F97543CF25D30E14@njmtexg4.research.att.com> From: Esteban Carisimo Message-ID: <01a1a99b-5743-f4b5-05d9-4c8b3b20c303@cnet.fi.uba.ar> Date: Wed, 1 Mar 2017 12:38:19 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25D30E14@njmtexg4.research.att.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 15:38:35 -0000 Hi Al, Thank you so much for the references as well as giving me some context about the previous work of those RFCs. You really pointed my question when you said you had used different high percentiles. That is exactly what I was thinking about, some people might be ending up using different percentiles. However, I do not see that as a drawback, I think you could learn from the experience of the operators but it would be necessary feedback from them. I think the discussion included in the draft it is OK. Regards, Esteban Carisimo PhD student at CoNexDat (UBA-CONICET) http://cnet.fi.uba.ar/esteban_carisimo/en El 1/3/17 a las 12:23, MORTON, ALFRED C (AL) escribió: > Hi Esteban, > > If you look through RFC 5481 [0], you'll find that the idea > of a "High Percentile" is included, based on the experience > that different networks, or applications running on the > networks, have different demands. I've used 95, 99, and > 99.9 depending on the circumstances, and applying this sort of > statistic to packet transfer is fairly well understood > (RFC 5481 was approved in 2009 after much discussion in the IPPM WG). > > I also suggest RFC 2330, section 11.3 [1] which discusses the median > and nails-down the definition of percentile for IPPM use > (there is not a universally accepted definition of percentile, > three interpretations are possible and we narrow down to one). > > These two references are a good starting point for any > further discussions. > > regards, > Al > > [0] https://tools.ietf.org/html/rfc5481 > > [1] https://tools.ietf.org/html/rfc2330#section-11.3 > > > >> -----Original Message----- >> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Esteban Carisimo >> Sent: Wednesday, March 01, 2017 10:02 AM >> To: ippm@ietf.org >> Subject: Re: [ippm] I: I-D Action: draft-ietf-ippm-alt-mark-04.txt >> >> Giuseppe, >> >> I do support your idea of incluing percentile since maximum values could >> be misleading. Moreover, it think it is actually a very good idea to >> include a suggestion instead of saying either one of the other is the >> right way of doing it. Altough the 99.9th percentile is included in a >> previous RFC, I was wondering if the 99.9th would be meaningful for >> every network or link. However, it think it is a nice way to start >> discussing about less sensitive parameters. >> >> Esteban Carisimo >> PhD student at CoNexDat (UBA-CONICET) >> https://urldefense.proofpoint.com/v2/url?u=http- >> 3A__cnet.fi.uba.ar_esteban-5Fcarisimo_en&d=DQIF-g&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz >> zg7n7QhD2I_6-x1Q&s=PPIhAtN3WQfhupyqoUqHuNvJG_MDe-D5EizhWgisivY&e= >> >> El 1/3/17 a las 8:13, Fioccola Giuseppe escribió: >>> Hi All, >>> This new version of draft-ietf-ippm-alt-mark addresses comments >> received offline by Al Morton. >>> Specifically we have added a note in which we suggest to calculate a >> high percentile of the delay instead of the maximum. >>> The problem with maximum delay is that it is influenced by outliers >> and could be misleading. >>> In addition the reference to RFC 5481, particularly section 6.5, has >> been added. >>> Many Thanks to Al for the precious help, >>> >>> Best Regards, >>> >>> Giuseppe >>> >>> -----Messaggio originale----- >>> Da: ippm [mailto:ippm-bounces@ietf.org] Per conto di internet- >> drafts@ietf.org >>> Inviato: mercoledì 1 marzo 2017 12:01 >>> A: i-d-announce@ietf.org >>> Cc: ippm@ietf.org >>> Oggetto: [ippm] I-D Action: draft-ietf-ippm-alt-mark-04.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the IP Performance Metrics of the IETF. >>> >>> Title : Alternate Marking method for passive >> performance monitoring >>> Authors : Giuseppe Fioccola >>> Alessandro Capello >>> Mauro Cociglio >>> Luca Castaldelli >>> Mach(Guoyi) Chen >>> Lianshu Zheng >>> Greg Mirsky >>> Tal Mizrahi >>> Filename : draft-ietf-ippm-alt-mark-04.txt >>> Pages : 30 >>> Date : 2017-03-01 >>> >>> Abstract: >>> This document describes a passive method to perform packet loss, >>> delay and jitter measurements on live traffic. This method is >> based >>> on Alternate Marking (Coloring) technique. A report on the >>> operational experiment done at Telecom Italia is explained in >> order >>> to give an example and show the method applicability. This >> technique >>> can be applied in various situations as detailed in this document. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-2Dmark_&d=DQIF- >> g&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz >> zg7n7QhD2I_6-x1Q&s=NufcoUHHeeBrUi4UwaX45c4POeZnMB_k4AHIARjLfyw&e= >>> There's also a htmlized version available at: >>> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dalt-2Dmark-2D04&d=DQIF- >> g&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz >> zg7n7QhD2I_6-x1Q&s=6WqdeohHv1UTz0U7nI6EgiPNiNNbO8lOsAbR9zEkXuM&e= >>> A diff from the previous version is available at: >>> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dippm-2Dalt-2Dmark- >> 2D04&d=DQIF-g&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz >> zg7n7QhD2I_6-x1Q&s=YJWiIGFs3NwrQ_3uBbY6wxgIpbS8DhfZ-WRHUVa5bdA&e= >>> >>> 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: >>> https://urldefense.proofpoint.com/v2/url?u=ftp- >> 3A__ftp.ietf.org_internet-2Ddrafts_&d=DQIF-g&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz >> zg7n7QhD2I_6-x1Q&s=hQVaU10JwTjqeUKjQTEf-yQChqJ6TBAytiZ9BnRvGRY&e= >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_ippm&d=DQIF-g&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz >> zg7n7QhD2I_6-x1Q&s=NI1_8wEhMMMtb01UikJBgRnJOxNN_bJ1obtzRSL3pAs&e= >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente >> alle persone indicate. La diffusione, copia o qualsiasi altra azione >> derivante dalla conoscenza di queste informazioni sono rigorosamente >> vietate. Qualora abbiate ricevuto questo documento per errore siete >> cortesemente pregati di darne immediata comunicazione al mittente e di >> provvedere alla sua distruzione, Grazie. >>> This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. >> Dissemination, copying, printing or use by anybody else is unauthorised. >> If you are not the intended recipient, please delete this message and >> any attachments and advise the sender by return e-mail, Thanks. >>> _______________________________________________ >>> ippm mailing list >>> ippm@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_ippm&d=DQIF-g&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz >> zg7n7QhD2I_6-x1Q&s=NI1_8wEhMMMtb01UikJBgRnJOxNN_bJ1obtzRSL3pAs&e= >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_ippm&d=DQIF-g&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=ksehRnxmKX5kd4QUQA2LrW6ZjOz >> zg7n7QhD2I_6-x1Q&s=NI1_8wEhMMMtb01UikJBgRnJOxNN_bJ1obtzRSL3pAs&e= From nobody Thu Mar 2 16:06:46 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 065C3129438; Thu, 2 Mar 2017 16:06:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148849959702.30955.15303863500758969230.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 16:06:37 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-twamp-time-format-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 00:06:37 -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 of the IETF. Title : Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP) Authors : Greg Mirsky Israel Meilik Filename : draft-ietf-ippm-twamp-time-format-03.txt Pages : 8 Date : 2017-03-02 Abstract: This document describes an OPTIONAL feature for active performance measurement protocols allowing use of the Precision Time Protocol time stamp format defined in IEEE-1588v2-2008, as an alternative to the Network Time Protocol that is currently used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-format/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-twamp-time-format-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-twamp-time-format-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 2 20:45:10 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 002701295D9; Thu, 2 Mar 2017 20:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148851630299.30809.13198180923270314805.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 20:45:02 -0800 Archived-At: Cc: draft-ietf-ippm-twamp-time-format.all@ietf.org, ietf@ietf.org, ippm@ietf.org Subject: [ippm] Review of draft-ietf-ippm-twamp-time-format-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 04:45:03 -0000 Reviewer: Joel Halpern Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ippm-twamp-time-format-?? Reviewer: Joel Halpern Review Date: 2017-03-02 IETF LC End Date: 2017-03-15 IESG Telechat date: Not scheduled for a telechat Summary: Major issues: Minor issues: The wording of the behavioral requirements for signaling in section 2.1 is atypical for IETF documents (and in my view makes it harder for the reader to follow.) The rules are listed as separate rules, but they are actually sequential steps that must be test in order, exiting the process if the condition for each step is met. But it does not actually say that. Nits/editorial comments: Section 2.3 refers to this as a proposal. It is a specification, not a proposal. Please reword. From nobody Fri Mar 3 14:46:47 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074751295C8; Fri, 3 Mar 2017 14:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 suwA9YakIThs; Fri, 3 Mar 2017 14:46:37 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715C4127076; Fri, 3 Mar 2017 14:46:34 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id 126so11415932oig.3; Fri, 03 Mar 2017 14:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mKezgPwA2bhG+GhU2xZiUlem0a0e2rz0W5CD/eUh5Ws=; b=EA1AsieYIhLH/2XSIRgh05a4sjnRFWwFP1eux07Bn9J/09VfrB5u8dXJcKxN8Ejl0k KMkGlqK8a9iw8vNbb84ABBvaNjBzfVRWeQ6mlLpLexQ9bre5gA+puWwXeLkdjDyTK8g2 hjmJJhy896kX5+X3+kHQ58BF99U4Vcza35LLJbwT0HAfd7UxIsMpwJzBQk2Dd2HmnAbK oFAzgcQ28JRX9nAHtWOwY0GBAu374fdB3cNLRCjlnTWz9RIaN5WzM6A1WWsyyHlFiKq8 wjPe0zab7CCGlp20Mr/YhVu06b8b3jkJg9HDEt9j5TGgKMlo5DR6Jrm7Y9E1txXXuCGr 03DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mKezgPwA2bhG+GhU2xZiUlem0a0e2rz0W5CD/eUh5Ws=; b=RcKN58zgeQZSFEVRtWixy+8sT3a5SK5kIovVLps2JhxmtHsios+5slsTU7REEgxugd Sd98JMqiPrEfddQXM2cNzGslRaKysHDvtHiKWceOxkSchbSN4ItdMq9YgghtddbE87P+ dQlqZZwYhZnNGge0jMQO/cb4L4yvz7jyuRGmca/eyj9bUaAr6fIseLTckN0gq81lZySi a4xEgj2Z2OklY/jQH78owwhHc2lnWJ7yIlVNvXzVBoXo0EP8oNlG4rBDcNaNmHxx15+n 55XbgoTaYCebRf6kVSsWZtjfqM1Jq7+nukouCvx66865Ez90dusYHi0gF2MhDc+7ERyR cKzg== X-Gm-Message-State: AMke39nvRefIHCbyRYGbbb2CoTV4Er5IiWihilH0qDLbbEhod0W/jQ39ywUJunMFY6O5ffUCTMlJ88dvAhFb4Q== X-Received: by 10.202.236.140 with SMTP id k134mr2517654oih.123.1488581193726; Fri, 03 Mar 2017 14:46:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Fri, 3 Mar 2017 14:46:33 -0800 (PST) In-Reply-To: <148851630299.30809.13198180923270314805.idtracker@ietfa.amsl.com> References: <148851630299.30809.13198180923270314805.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 3 Mar 2017 14:46:33 -0800 Message-ID: To: Joel Halpern Content-Type: multipart/alternative; boundary=001a1134fc3e4583370549db51c7 Archived-At: Cc: "gen-art@ietf.org" , "ippm@ietf.org" , draft-ietf-ippm-twamp-time-format.all@ietf.org, "ietf@ietf.org" Subject: Re: [ippm] Review of draft-ietf-ippm-twamp-time-format-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 22:46:39 -0000 --001a1134fc3e4583370549db51c7 Content-Type: text/plain; charset=UTF-8 Hi Joel, thank you for your thorough review and the most helpful comments. I've did s/proposal/specification/ through the document. As for the section 2.1 would the following text be clearer: The rules of setting timestamp flags in Modes field in server greeting and Set-Up-Response messages and interpreting them are as follows: o If the Session-Receiver supports this extension, then the Server that establishes test sessions on its behalf MUST set PTPv2 Timestamp flag to 1 in the server greeting message per the requirement listed in Section 2. Otherwise, the PTPv2 Timestamp flag will be set to 0 to indicate that the Session-Reciever interprets only NTP format. o If the Control-Client receives greeting message with the PTPv2 Timestamp flag set to 0, then the Session-Sender MUST use NTP format for timestamp in the test session and Control-Client SHOULD set PTPv2 Timestamp flag to 0 in accordance with [RFC4656]. If the Session-Sender cannot use NTP timestamps, then the Control- Client SHOULD close the TCP connection associated with the OWAMP- Control session. o If the Control-Client receives greeting message with the PTPv2 Timestamp flag set to 1 and the Session-Sender can set timestamp in PTPv2 format, then the Control-Client MUST set the PTPv2 Timestamp flag to 1 in Modes field in the Set-Up-Response message and the Session-Sender MUST use PTPv2 timestamp format. o If the Session-Sender doesn't support this extension and can set timestamp only in NTP format, then the PTPv2 Timestamp flag in Modes field in the Set-Up-Response message will be set to 0 as part of Must Be Zero and the Session-Sender use NTP format. Regards, Greg On Thu, Mar 2, 2017 at 8:45 PM, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ippm-twamp-time-format-?? > Reviewer: Joel Halpern > Review Date: 2017-03-02 > IETF LC End Date: 2017-03-15 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > Major issues: > > Minor issues: > The wording of the behavioral requirements for signaling in > section 2.1 is atypical for IETF documents (and in my view makes it > harder for the reader to follow.) The rules are listed as separate > rules, but they are actually sequential steps that must be test in > order, exiting the process if the condition for each step is met. But > it does not actually say that. > > Nits/editorial comments: > Section 2.3 refers to this as a proposal. It is a specification, > not a proposal. Please reword. > > > --001a1134fc3e4583370549db51c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel,
thank you for your thorough review and the mo= st helpful comments. I've did s/proposal/specification/ through the doc= ument. As for the section 2.1 would the following text be clearer:
The rules of setting timestamp flags in
   Modes field in server greeting and Set-Up-Response messages and
   interpreting them are as follows:

   o  If the Session-Receiver supports this extension, then the Server
      that establishes test sessions on its behalf MUST set PTPv2
      Timestamp flag to 1 in the server greeting message per the
      requirement listed in Section 2.  Otherwise, the PTPv2 Timestamp
      flag will be set to 0 to indicate that the Session-Reciever
      interprets only NTP format.

   o  If the Control-Client receives greeting message with the PTPv2
      Timestamp flag set to 0, then the Session-Sender MUST use NTP
      format for timestamp in the test session and Control-Client SHOULD
      set PTPv2 Timestamp flag to 0 in accordance with [RFC4656].  If
      the Session-Sender cannot use NTP timestamps, then the Control-
      Client SHOULD close the TCP connection associated with the OWAMP-
      Control session.

   o  If the Control-Client receives greeting message with the PTPv2
      Timestamp flag set to 1 and the Session-Sender can set timestamp
      in PTPv2 format, then the Control-Client MUST set the PTPv2
      Timestamp flag to 1 in Modes field in the Set-Up-Response message
      and the Session-Sender MUST use PTPv2 timestamp format.

   o  If the Session-Sender doesn't support this extension and can set
      timestamp only in NTP format, then the PTPv2 Timestamp flag in
      Modes field in the Set-Up-Response message will be set to 0 as
      part of Must Be Zero and the Session-Sender use NTP format.


Regards,
Greg

On Thu, Mar 2, 2017 at 8:= 45 PM, Joel Halpern <jmh@joelhalpern.com> wrote:
Reviewer: Joel Halpern
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq<= /a>>.

Document: draft-ietf-ippm-twamp-time-format-??
Reviewer: Joel Halpern
Review Date: 2017-03-02
IETF LC End Date: 2017-03-15
IESG Telechat date: Not scheduled for a telechat

Summary:

Major issues:

Minor issues:
=C2=A0 =C2=A0 The wording of the behavioral requirements for signaling in section 2.1 is atypical for IETF documents (and in my view makes it
harder for the reader to follow.)=C2=A0 The rules are listed as separate rules, but they are actually sequential steps that must be test in
order, exiting the process if the condition for each step is met.=C2=A0 But=
it does not actually say that.

Nits/editorial comments:
=C2=A0 =C2=A0 Section 2.3 refers to this as a proposal.=C2=A0 It is a speci= fication,
not a proposal.=C2=A0 Please reword.



--001a1134fc3e4583370549db51c7-- From nobody Fri Mar 3 15:13:20 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C914129631; Fri, 3 Mar 2017 15:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 0x2qRqygP8FU; Fri, 3 Mar 2017 15:13:17 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 A770D1293DB; Fri, 3 Mar 2017 15:13:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9036E240367; Fri, 3 Mar 2017 15:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1488582797; bh=4Fk+hOh4pyp+khVzK6zqLOmdAjdqsyL2k8RqQC+iYi4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=U5kJP22xKhjr5QLV4drtMsGqiZAj5Pgqde2dCc3d4bBNgU7rLRdD1892TRbddxXTG oAn/t48wd534Q2PjCg2EZw9X0DxDUawQSfMyOTQb52isMBc1bZnxm3o8TEFr3EJrRJ fgCw9/QinluyxBEJWSo12qUtA54bJpMOKJ6Xmo/I= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 81047243330; Fri, 3 Mar 2017 15:12:46 -0800 (PST) To: Greg Mirsky References: <148851630299.30809.13198180923270314805.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 3 Mar 2017 18:12:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "gen-art@ietf.org" , "ippm@ietf.org" , draft-ietf-ippm-twamp-time-format.all@ietf.org, "ietf@ietf.org" Subject: Re: [ippm] Review of draft-ietf-ippm-twamp-time-format-03 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 23:13:19 -0000 Yes, that makes the relationship of the conditions significantly clearer. Thank you, Joel On 3/3/17 5:46 PM, Greg Mirsky wrote: > Hi Joel, > thank you for your thorough review and the most helpful comments. I've > did s/proposal/specification/ through the document. As for the section > 2.1 would the following text be clearer: > > The rules of setting timestamp flags in > Modes field in server greeting and Set-Up-Response messages and > interpreting them are as follows: > > o If the Session-Receiver supports this extension, then the Server > that establishes test sessions on its behalf MUST set PTPv2 > Timestamp flag to 1 in the server greeting message per the > requirement listed in Section 2. Otherwise, the PTPv2 Timestamp > flag will be set to 0 to indicate that the Session-Reciever > interprets only NTP format. > > o If the Control-Client receives greeting message with the PTPv2 > Timestamp flag set to 0, then the Session-Sender MUST use NTP > format for timestamp in the test session and Control-Client SHOULD > set PTPv2 Timestamp flag to 0 in accordance with [RFC4656]. If > the Session-Sender cannot use NTP timestamps, then the Control- > Client SHOULD close the TCP connection associated with the OWAMP- > Control session. > > o If the Control-Client receives greeting message with the PTPv2 > Timestamp flag set to 1 and the Session-Sender can set timestamp > in PTPv2 format, then the Control-Client MUST set the PTPv2 > Timestamp flag to 1 in Modes field in the Set-Up-Response message > and the Session-Sender MUST use PTPv2 timestamp format. > > o If the Session-Sender doesn't support this extension and can set > timestamp only in NTP format, then the PTPv2 Timestamp flag in > Modes field in the Set-Up-Response message will be set to 0 as > part of Must Be Zero and the Session-Sender use NTP format. > > Regards, > > Greg > > > On Thu, Mar 2, 2017 at 8:45 PM, Joel Halpern > wrote: > > Reviewer: Joel Halpern > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > >. > > Document: draft-ietf-ippm-twamp-time-format-?? > Reviewer: Joel Halpern > Review Date: 2017-03-02 > IETF LC End Date: 2017-03-15 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > Major issues: > > Minor issues: > The wording of the behavioral requirements for signaling in > section 2.1 is atypical for IETF documents (and in my view makes it > harder for the reader to follow.) The rules are listed as separate > rules, but they are actually sequential steps that must be test in > order, exiting the process if the condition for each step is met. But > it does not actually say that. > > Nits/editorial comments: > Section 2.3 refers to this as a proposal. It is a specification, > not a proposal. Please reword. > > > From nobody Fri Mar 3 15:56:04 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC45127071; Fri, 3 Mar 2017 15:55:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532010.15846.60308651493367758.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:20 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] ippm - Requested session has been scheduled for IETF 98 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:20 -0000 Dear Brian Trammell, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ippm Session 1 (2:30:00) Monday, Morning Session I 0900-1130 Room Name: Zurich B size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IP Performance Metrics Area Name: Transport Area Session Requester: Brian Trammell Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm taps bmwg lmap xrblock quic Second Priority: v6ops 6man 6lo sunset4 opsec tcpinc Third Priority: cdni alto People who must be present: Al Morton Spencer Dawkins Brian Trammell Bill Cerveny Kostas Pentikousis Giuseppe Fioccola Resources Requested: Meetecho support in room Special Requests: Please try to schedule Monday/Tuesday, as neither chair will be present after Tuesday. Please try not to schedule opposite irtfopen, iccrg, maprg --------------------------------------------------------- From nobody Fri Mar 3 16:54:39 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFF612706D; Fri, 3 Mar 2017 16:54:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858887483.15874.7091372436147300282.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 16:54:34 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-twamp-time-format-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 00:54:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP) Authors : Greg Mirsky Israel Meilik Filename : draft-ietf-ippm-twamp-time-format-04.txt Pages : 8 Date : 2017-03-03 Abstract: This document describes an OPTIONAL feature for active performance measurement protocols allowing use of the Precision Time Protocol time stamp format defined in IEEE-1588v2-2008, as an alternative to the Network Time Protocol that is currently used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-format/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-twamp-time-format-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-twamp-time-format-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 3 16:57:14 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FA21294AB; Fri, 3 Mar 2017 16:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Lbc3fTUuMbS5; Fri, 3 Mar 2017 16:57:07 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B03212940B; Fri, 3 Mar 2017 16:57:07 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id 126so12371790oig.3; Fri, 03 Mar 2017 16:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=9bIhzpk8dJUmgMLHGCzfQgvrWR2vTtPDX2zSSvOoifs=; b=M+VDp+HwQlWMO2+H6CtBWOhKwVauz28fq9fPMO7v6bRyaMRgfWZGYrvEcdlB5raYk1 9/bBnMfw8UGaxjjRXAIaD0Btda2ibfXg1l7F4jipErm59r/PP3WoG5stteSNMrbZ/HgV UdCxeuAlaN8W9Ejtd76xcZ5nmq97vtHNRZTHCXYDb4DxQ/qlDw6cBZYGWisqaapv8bg+ Rd459pPdSOsDRNCA02zaG84vAWkn4DN19+vHv+6dKjQI40pCMaFfPkhM/T1ovoBLDyrC 4aSWlLj1Aqv38uRspEOy2h7jX9hEwTX3EEZuwa2XiHIXUpf/L0T94ces1xKatlhkR5Z/ yyww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=9bIhzpk8dJUmgMLHGCzfQgvrWR2vTtPDX2zSSvOoifs=; b=lZDNvCwP8Vf+1+S5qqRZzSg3dGfr67diPYdJyFmApleq9KBYWi1n4C1PyocRkwTnYm HFY45V7WeI+/KpQlJWlqgkDUBkCoHRvlMo/tvRVPligABhc9inNdksuKzio+W2F5Y1vv ZBQYXvkv6M/6Ogrq7AuyebzL4otsrvQoElAlDlYahQAQrWVpqgLdRQWpKZHjbWL+YKad QT6C+kBEn8eb037m7KVVpzIAaWN8+8JGadYoyd6NPanRqe7KlwnNClEGmLTYgyY/aRnQ Zp8RxX2tiGN0W1ohJRfTJZ2wrUYs+U/nsKpKvK3oZgOyo3YQdrQMl01LVMqHQ5l+CQ9J /CGw== X-Gm-Message-State: AMke39lnPFOhcUPQc54fX6WNcasOF3g6OIWM8ddDPY/+3v3NaKFYxQPhLM3GjZqeDkUohQ6Or22y3kclAccRTA== X-Received: by 10.202.236.140 with SMTP id k134mr2726190oih.123.1488589026390; Fri, 03 Mar 2017 16:57:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Fri, 3 Mar 2017 16:57:06 -0800 (PST) In-Reply-To: <148858887501.15874.15239074428793785070.idtracker@ietfa.amsl.com> References: <148858887501.15874.15239074428793785070.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 3 Mar 2017 16:57:06 -0800 Message-ID: To: Joel Halpern , "ippm@ietf.org" , "gen-art@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a1134fc3e227b7c0549dd24f8 Archived-At: Subject: [ippm] Fwd: New Version Notification for draft-ietf-ippm-twamp-time-format-04.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 04 Mar 2017 00:57:08 -0000 --001a1134fc3e227b7c0549dd24f8 Content-Type: text/plain; charset=UTF-8 Dear All, changes are to address comments by Joel Halpern. Regards, Greg ---------- Forwarded message ---------- From: Date: Fri, Mar 3, 2017 at 4:54 PM Subject: New Version Notification for draft-ietf-ippm-twamp-time-format-04.txt To: Gregory Mirsky , ippm-chairs@ietf.org, Israel Meilik A new version of I-D, draft-ietf-ippm-twamp-time-format-04.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-ippm-twamp-time-format Revision: 04 Title: Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP) Document date: 2017-03-03 Group: ippm Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp- time-format-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp- time-format/ Htmlized: https://tools.ietf.org/html/draft-ietf-ippm-twamp-time- format-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-twamp- time-format-04 Abstract: This document describes an OPTIONAL feature for active performance measurement protocols allowing use of the Precision Time Protocol time stamp format defined in IEEE-1588v2-2008, as an alternative to the Network Time Protocol that is currently used. 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. The IETF Secretariat --001a1134fc3e227b7c0549dd24f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
changes are to address comments by Joel Halp= ern.

Regards,
Greg
---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Mar 3, 2017 = at 4:54 PM
Subject: New Version Notification for draft-ietf-ippm-twamp-t= ime-format-04.txt
To: Gregory Mirsky <gregimirsky@gmail.com>, ippm-chairs@ietf.org, Israel Meilik <israel@broadcom.com>



A new version of I-D, draft-ietf-ippm-twamp-time-format-04.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-ippm-twamp-time-format
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Support of IEEE-1588 time stamp fo= rmat in Two-Way Active Measurement Protocol (TWAMP)
Document date:=C2=A0 2017-03-03
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ippm
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf= -ippm-twamp-time-format-04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-ti= me-format/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://tools.ietf.org/html/draft-ietf-ippm-twamp-time-format-04<= /a>
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ippm-= twamp-time-format-04

Abstract:
=C2=A0 =C2=A0This document describes an OPTIONAL feature for active perform= ance
=C2=A0 =C2=A0measurement protocols allowing use of the Precision Time Proto= col
=C2=A0 =C2=A0time stamp format defined in IEEE-1588v2-2008, as an alternati= ve to
=C2=A0 =C2=A0the Network Time Protocol that is currently used.




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

The IETF Secretariat


--001a1134fc3e227b7c0549dd24f8-- From nobody Sun Mar 5 01:59:30 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EA6129482; Sun, 5 Mar 2017 01:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 rzlC7JOwcOA5; Sun, 5 Mar 2017 01:59:27 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 CEC52128AC9; Sun, 5 Mar 2017 01:59:27 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v259tDHY002063; Sun, 5 Mar 2017 01:59:25 -0800 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 28yutpbv9x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 05 Mar 2017 01:59:25 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 5 Mar 2017 11:59:21 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1210.000; Sun, 5 Mar 2017 11:59:21 +0200 From: Tal Mizrahi To: "'ippm@ietf.org'" , "mpls@ietf.org" Thread-Topic: Updated version of draft-mizrahi-ippm-multiplexed-alternate-marking-01.txt Thread-Index: AdKVllhO53n533LaTxio1Os1NzpebA== Date: Sun, 5 Mar 2017 09:59:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-04_19:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703050084 Archived-At: Subject: [ippm] Updated version of draft-mizrahi-ippm-multiplexed-alternate-marking-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 09:59:29 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGFuIHVwZGF0ZWQgdmVyc2lvbiBvZiBkcmFmdC1taXpy YWhpLWlwcG0tbXVsdGlwbGV4ZWQtYWx0ZXJuYXRlLW1hcmtpbmcuDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWl6cmFoaS1pcHBtLW11bHRpcGxleGVkLWFsdGVybmF0ZS1tYXJr aW5nLTAxDQoNClRoZSBtYWluIGNoYW5nZSBjb21wYXJlZCB0byB0aGUgcHJldmlvdXMgdmVyc2lv biBpcyB0aGF0IHdlIGhhdmUgYWRkZWQgYSBzZWN0aW9uIHRoYXQgZXh0ZW5kcyB0aGUgYXBwcm9h Y2ggdG8gYSBtYXJraW5nIGZpZWxkIHRoYXQgaXMgbm90IG5lY2Vzc2FyaWx5IGEgc2luZ2xlIGJp dC4gDQpUaGUgbmV3IHNlY3Rpb24gbWVudGlvbnMgTVBMUyBTRkxzIGFzIGFuIGV4YW1wbGUgZm9y IG1hcmtpbmcgZmllbGRzIHRoYXQgYXJlIGxvbmdlciB0aGFuIG9uZSBiaXQgKGFzIGluIGRyYWZ0 LWJyeWFudC1tcGxzLXJmYzYzNzQtc2ZsKSwgYW5kIGNhbiB0aHVzIHVzZSB0aGUgbXVsdGlwbGV4 aW5nIGFwcHJvYWNoLg0KDQpDb21tZW50cyB3aWxsIGJlIHdlbGNvbWUuDQoNClRoYW5rcywNClRh bC4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1p enJhaGktaXBwbS1tdWx0aXBsZXhlZC1hbHRlcm5hdGUtbWFya2luZy0wMS50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGFsIE1penJhaGkgYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWl6cmFoaS1pcHBtLW11bHRpcGxleGVk LWFsdGVybmF0ZS1tYXJraW5nDQpSZXZpc2lvbjoJMDENClRpdGxlOgkJUGFzc2l2ZSBQZXJmb3Jt YW5jZSBNb25pdG9yaW5nIHVzaW5nIGEgTXVsdGlwbGV4ZWQgTWFya2luZyBGaWVsZA0KRG9jdW1l bnQgZGF0ZToJMjAxNy0wMy0wNQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OgkJMTANClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtbWl6cmFoaS1pcHBtLW11bHRpcGxleGVkLWFsdGVybmF0ZS1tYXJraW5nLTAxLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW1penJhaGktaXBwbS1tdWx0aXBsZXhlZC1hbHRlcm5hdGUtbWFya2luZy8NCkh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWl6cmFoaS1pcHBtLW11bHRp cGxleGVkLWFsdGVybmF0ZS1tYXJraW5nLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1penJhaGktaXBwbS1tdWx0aXBsZXhlZC1hbHRl cm5hdGUtbWFya2luZy0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgbWVtbyBpbnRyb2R1Y2VzIGEg bWFya2luZyBtZXRob2QgdGhhdCB1c2VzIGEgc2luZ2xlIG1hcmtpbmcgYml0LA0KICAgb3IgdHdv IG1hcmtpbmcgdmFsdWVzLCBhbmQgYWxsb3dzIGFjY3VyYXRlIGxvc3MgYW5kIGRlbGF5DQogICBt ZWFzdXJlbWVudC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1 Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Mar 6 00:07:04 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2891312711D; Mon, 6 Mar 2017 00:07:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148878762313.14971.5927760069602895039.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 00:07:03 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-2330-ipv6-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 08:07:03 -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 of the IETF. Title : IPv6 Updates for IPPM's Active Metric Framework Authors : Al Morton Joachim Fabini Nalini Elkins Michael S. Ackermann Vinayak Hegde Filename : draft-ietf-ippm-2330-ipv6-01.txt Pages : 13 Date : 2017-03-06 Abstract: This memo updates the IP Performance Metrics (IPPM) Framework RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets in RFC 2330 to include IPv6 packets and augments distinguishing aspects of packets, referred to as Type-P for test packets in RFC 2330. This memo identifies that IPv4-IPv6 co-existence can challenge measurements within the scope of the IPPM Framework. Exemplary use cases include, but are not limited to IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header compression. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-2330-ipv6-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-2330-ipv6-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 Mar 6 00:24:35 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC13912944F for ; Mon, 6 Mar 2017 00:24:34 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 T6rEUUxF87MS for ; Mon, 6 Mar 2017 00:24:32 -0800 (PST) Received: from mail.nt.tuwien.ac.at (mail.nt.tuwien.ac.at [128.131.67.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8140F1270B4 for ; Mon, 6 Mar 2017 00:24:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.nt.tuwien.ac.at (Postfix) with ESMTP id B834D1661DD4; Mon, 6 Mar 2017 09:24:29 +0100 (CET) X-Virus-Scanned: amavisd-new at mydomain = nt.tuwien.ac.at Received: from mail.nt.tuwien.ac.at ([127.0.0.1]) by localhost (mail.nt.tuwien.ac.at [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIl2P_e1LfEa; Mon, 6 Mar 2017 09:24:28 +0100 (CET) Received: from [128.131.67.210] (toothless.nt.tuwien.ac.at [128.131.67.210]) by mail.nt.tuwien.ac.at (Postfix) with ESMTPSA id D77621661DC2; Mon, 6 Mar 2017 09:24:28 +0100 (CET) References: <148878762313.14971.5927760069602895039.idtracker@ietfa.amsl.com> To: ippm@ietf.org From: Joachim Fabini Message-ID: Date: Mon, 6 Mar 2017 09:24:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148878762313.14971.5927760069602895039.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [ippm] I-D Action: draft-ietf-ippm-2330-ipv6-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: joachim.fabini@tuwien.ac.at List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 08:24:35 -0000 Dear ippm, we have submitted a new revision of RFC2330-IPv6 update. This version considers review comments sent by Fred Baker and Marius Georgescu - many thanks again for their valuable input. Main changes include addition of a new section 5 that discusses potential consequences of NAT and IPv4-v6 transitioning technologies onto measurements. Moreover, a paragraph on load balancers has been added in section 3 as we consider this topic to be strongly related to the Type-P definition and class C treatment. Open topics include the handling of large packets in IPv6 (including fragment extension headers, PMTUD, PLMTUD), extent of coverage for 6LO and IPv6 Header Compression, and the continued need to define a "minimal standard-formed packet". Any feedback or input is warmly welcome. best regards Joachim On 2017-03-06 09:07, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Performance Metrics of the IETF. > > Title : IPv6 Updates for IPPM's Active Metric Framework > Authors : Al Morton > Joachim Fabini > Nalini Elkins > Michael S. Ackermann > Vinayak Hegde > Filename : draft-ietf-ippm-2330-ipv6-01.txt > Pages : 13 > Date : 2017-03-06 > > Abstract: > This memo updates the IP Performance Metrics (IPPM) Framework RFC > 2330 with new considerations for measurement methodology and testing. > It updates the definition of standard-formed packets in RFC 2330 to > include IPv6 packets and augments distinguishing aspects of packets, > referred to as Type-P for test packets in RFC 2330. This memo > identifies that IPv4-IPv6 co-existence can challenge measurements > within the scope of the IPPM Framework. Exemplary use cases include, > but are not limited to IPv4-IPv6 translation, NAT, protocol > encapsulation, or IPv6 header compression. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ippm-2330-ipv6-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-2330-ipv6-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/ > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > From nobody Mon Mar 6 00:28:38 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACE312944F for ; Mon, 6 Mar 2017 00:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 NkhPzJmGzskO for ; Mon, 6 Mar 2017 00:28:35 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0105.outbound.protection.outlook.com [104.47.36.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609FB1270B4 for ; Mon, 6 Mar 2017 00:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1YcQO9jzNv5s2oQS86B9dFI1qnT57QnUs02IkxOEW18=; b=i2nb9fYLDaLU/SJavrx06ATAmAsM9s6AkQQ8ElHwZ+XhWKz2hsqhCYpiTP1m90dcdiFHpSBI1R0E5UUn5mLcan2+MjQKwa97cMJ6SDrkIq0tQ6yrqbWKCRXSNvLJpb1rpshTyVMUvGLfuGNB593a8cygHOPuOkJOiROJy5j2O70= Received: from CY1PR0501MB2075.namprd05.prod.outlook.com (10.164.3.25) by CY1PR0501MB2075.namprd05.prod.outlook.com (10.164.3.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Mon, 6 Mar 2017 08:28:33 +0000 Received: from CY1PR0501MB2075.namprd05.prod.outlook.com ([10.164.3.25]) by CY1PR0501MB2075.namprd05.prod.outlook.com ([10.164.3.25]) with mapi id 15.01.0961.012; Mon, 6 Mar 2017 08:28:33 +0000 From: Sudhin Jacob To: "ippm@ietf.org" Thread-Topic: REG: draft-bhaprasud-ippm-pm-02 Thread-Index: AdKWU6KEMsQAXxhzQP+1XKs8OU2xHA== Date: Mon, 6 Mar 2017 08:28:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [116.197.184.12] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB2075; 7:FlQ0onVVSJ6016gW2L9U85hm67UPvqXnSVT/Pqhid1yf0gsDuRDXQXj8uz/HJj8jaIwzl1kFxgzm2JKdd7Aym6EKyHDPnKbYoBHrqkbTXdv22UHkUg3u/k6BGZYMVa0kPhgn8CKs3zwglk/BT7bKHd3D7K34yHLHbPaUaWUk+P6m2E5l59OqiXpWEbMiT8kpauPewAQFO+1X2xFeW/0x9NolUFrcjOGrMnQXwbMKPb3JFUe6JNF+isJ/S/kFzQMvLrRbID02gbIufmG+Si6cKo/RYeu0vMH5LkZPcWH0EIDOpzwRkKxG4I4tvq5OKt4vn2qVAbYCEtar4tD74suBQA== x-ms-office365-filtering-correlation-id: 74a07e26-d7ed-4e1e-ac37-08d4646ac6d2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0501MB2075; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123558025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR0501MB2075; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2075; x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39850400002)(39450400003)(39410400002)(53754006)(92566002)(4326008)(86362001)(6436002)(6306002)(33656002)(74316002)(66066001)(8936002)(122556002)(3846002)(1730700003)(53936002)(5660300001)(2906002)(966004)(102836003)(2351001)(189998001)(305945005)(6116002)(7736002)(6916009)(38730400002)(110136004)(2501003)(39060400002)(2900100001)(54906002)(55016002)(25786008)(3280700002)(99286003)(7696004)(5640700003)(230783001)(9686003)(81166006)(50986999)(3660700001)(6506006)(8676002)(77096006)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2075; H:CY1PR0501MB2075.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB20750145B3CFCC60C218CDFDC22C0CY1PR0501MB2075_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2017 08:28:32.9838 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2075 Archived-At: Subject: [ippm] REG: draft-bhaprasud-ippm-pm-02 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 08:28:37 -0000 --_000_CY1PR0501MB20750145B3CFCC60C218CDFDC22C0CY1PR0501MB2075_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, We have uploaded the latest revision our draft, kindly review it and let us= know the feedback. https://www.ietf.org/id/draft-bhaprasud-ippm-pm-02.txt Regards, Sudhin --_000_CY1PR0501MB20750145B3CFCC60C218CDFDC22C0CY1PR0501MB2075_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
We have uploaded the latest revision our draft, kindly review it and l= et us know the feedback.
 
 
Regards,
Sudhin
 
--_000_CY1PR0501MB20750145B3CFCC60C218CDFDC22C0CY1PR0501MB2075_-- From nobody Tue Mar 7 08:19:42 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFF6129582 for ; Tue, 7 Mar 2017 07:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rT4dcxNCyxm6 for ; Tue, 7 Mar 2017 07:44:28 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3891295F5 for ; Tue, 7 Mar 2017 07:44:15 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Mar 2017 07:44:12 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 7 Mar 2017 07:44:12 -0800 From: Michelle Cotton To: "MORTON, ALFRED C (AL)" Thread-Topic: Follow-up questions for ippm drafts Thread-Index: AQHSl1mrDAU0S7t5ukyBjsF/+SMpsA== Date: Tue, 7 Mar 2017 15:44:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3571717483_716144670" MIME-Version: 1.0 Archived-At: Cc: Sabrina Tanamal , Amanda Baber , "ippm@ietf.org" Subject: [ippm] Follow-up questions for ippm drafts X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 15:44:33 -0000 --B_3571717483_716144670 Content-type: multipart/alternative; boundary="B_3571717483_250687703" --B_3571717483_250687703 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Al, =20 I=E2=80=99m working on a full review of draft-ietf-ippm-initial-registry-02 and d= raft-ietf-ippm-metric-registry-10.=C2=A0 I have some questions that need clarifi= cation before I send the full review.=C2=A0=20 =20 In section 7.1.2 of the initial registry document, it lists multiple names: =20 =C2=A0=C2=A0 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_ =20 =C2=A0=C2=A0 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_95Percen= tile =20 =C2=A0=C2=A0 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Mean =20 =C2=A0=C2=A0 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Min =20 =C2=A0=C2=A0 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Max =20 =C2=A0=C2=A0 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_StdDev =20 How does that work in the registry?=C2=A0 Do we add all of these names with the= same ID number or different ID numbers?=C2=A0 Do they all have identical summar= y information in the table?=C2=A0 Will they all link to the same template?=C2=A0 Can= you clarify? =20 Also, in section 7.1.3 of the metric registry document, it says the followi= ng URN will be created: =20 urn:ietf:metric:perf: =20 In some of our discussions =E2=80=9Cmetric=E2=80=9D was used and also =E2=80=9Cmetrics=E2=80=9D.=C2=A0 = Please confirm which will be used. =20 In section 4.1.3. of the initial registry document, it shows the following = URN: =20 URN: Prefix urn:ietf:params:performance:metric: =20 I had understood these will not be going under =E2=80=9Cparams=E2=80=9D and also in thi= s example =E2=80=9Cperformance=E2=80=9D is expanded.=C2=A0 Please confirm that this should n= ot be under params and wheter =E2=80=9Cperf=E2=80=9D or =E2=80=9Cperformance=E2=80=9D should be used= . =20 This also appears in section 9.1.3. =20 Answers to these questions will contribute to the full review which I hope = to have to you all later today. =20 Thanks! =20 --Michelle =20 --B_3571717483_250687703 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Al,

 

I’m working on a full review of draft-ietf-ippm-initial-registr= y-02 and draft-ietf-ippm-metric-registry-10.=C2=A0 I have some questions that ne= ed clarification before I send the full review.=C2=A0

 

In section 7.1.2 of the init= ial registry document, it lists multiple names:

 

=C2=A0=C2=A0 OWDelay_Active_IP-UDP-Pois= son-Payload250B_RFCXXXXsecY_Seconds_<statistic>

<= p class=3DMsoNormal> 

=C2=A0=C2=A0 OWDelay_Active_IP-UD= P-Poisson-Payload250B_RFCXXXXsecY_Seconds_95Percentile

=

 

=C2=A0=C2=A0 OWDelay_Active_IP-U= DP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Mean

 

=C2=A0=C2=A0 OWDelay_Active_IP-UDP-Pois= son-Payload250B_RFCXXXXsecY_Seconds_Min

 

=C2=A0=C2=A0 OWDelay_Active_IP-UDP-Poisson-Payl= oad250B_RFCXXXXsecY_Seconds_Max

 

=C2=A0=C2=A0 OWDelay_Active_IP-UDP-Poisson-Payload250B_= RFCXXXXsecY_Seconds_StdDev

 

How does that work in the registry?=C2=A0 Do we add all = of these names with the same ID number or different ID numbers?=C2=A0 Do they al= l have identical summary information in the table?=C2=A0 Will they all link to t= he same template?=C2=A0 Can you clarify?

 

Also, in section 7.1.3 of the metric regis= try document, it says the following URN will be created:

 =

urn:ietf:metric:perf:<= o:p>

=  

In = some of our discussions “metric” was used and also “metric= s”.=C2=A0 Please confirm which will be used.

 

In section 4.1.3. of the initial= registry document, it shows the following URN:

 

URN: Prefix urn:ietf:params:per= formance:metric:<name>

 

I had understood these will not be going under = 220;params” and also in this example “performance” is expa= nded.=C2=A0 Please confirm that this should not be under params and wheter ̶= 0;perf” or “performance” should be used.=

 

This also appears in= section 9.1.3.

 

Answers to these questions will contribute to the full review w= hich I hope to have to you all later today.

 

Thanks!

 

--Michelle

 =

--B_3571717483_250687703-- --B_3571717483_716144670 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIISBAYJKoZIhvcNAQcCoIIR9TCCEfECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg+5MIIFqDCCBJCgAwIBAgIQCuvDwxHaHKymSygUiz0IATANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTYx MDAzMDAwMDAwWhcNMTkxMDAzMTIwMDAwWjCBxTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxJDAiBgNVBAMTG01pY2hl bGxlIENvdHRvbiBJQU5BIDNPY3QxNjEnMCUGCSqGSIb3DQEJARYYbWljaGVsbGUuY290dG9u QGlhbmEub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6V4aMB8RQMy4vQOd nvINsoYARWq26DERE228XVCA7SxnxpHKRAgnpV4iBoL5rgjsiJy5utpRlbCZcV7PVaVp6yxM ozNUSzmiSu+O04PyYWjvJRzSLda6W0hc8B766JDK3V8QVX+5Pnt9E2JxyYL6j5zTrD/kZGTB XpaRNBF5DorhvPEwXNuRyWt5yD3m4vMwinCahC+5DB78PlxvbbEgTLenW8ZnSOunflX11Q8W XkYBAHEWLSDEO8MY4t7b7FBTWoDA6arnmiJApfBm+tfJ9VPto6KX1YWWuUMrmg7PVF6jfiuW ncwVZzed6VBW9Sp1oVKWP3GXraq0glyTutf5MQIDAQABo4IB8TCCAe0wHwYDVR0jBBgwFoAU 5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD4OJSm8pR0KSROJ2Te94XiGhEJAMAwG A1UdEwEB/wQCMAAwIwYDVR0RBBwwGoEYbWljaGVsbGUuY290dG9uQGlhbmEub3JnMA4GA1Ud DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4 BgpghkgBhv1sBAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9D UFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EtZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8v Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqG SIb3DQEBCwUAA4IBAQCFn08dbc9474OYmBeeFe4I08uzdP/Glg78Au1o7+IhufO+BN/fqn31 VhE7Q2aYCh28LF99PbdJ2IOBsz+BUGlrz7C0UvrHjmbXBTuR/gHez2Hmk6SOu0o4anLJqVFl xMzQtpBQXWM0K8GlyqDlPtiWQDORtUsMOXnL2+smNqb5xoz1SyK30KEMMeq9ZndDuBpM1Gyh 7JdgiLypKnYfRc1c1INCWiDlvpTA+C60BZSv5e/k1GMW0USd7TZTzphQxKmLNRUXUxRjub3H Yiby5y1hTnUyalL6HHbYVJX8bOgmaaOAjLvsJzX0rHRaMYlFbC4CgNlQNExJd4Xt7c39ghay MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIw MDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEy IEFzc3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q1 78AneRstBYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4i LCv4un7JNTtW8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P 5lB6UB8lRejxia/N/17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqC QQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BP y4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMB Af8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUH MAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDov L2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0 aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGqMIIBpjCCAaIGCmCG SAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAg AEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBj AGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBs AGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y 17yUC9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG 9w0BAQsFAAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61 +uBiGZmmB5p8Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbO kWDj+aBWDEgQzjNoe82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C 2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZV PVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjCC A7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAw MFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyx h/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wx hCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEb w4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0K yEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+ HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYD VR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i 7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfq VsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/ K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9r DDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+l t2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggIPMIICCwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQCuvDwxHaHKym SygUiz0IATANBglghkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCC1p5iVPgFr0RXXizxp wjjWi53rG5FFMAOBOyLkJ0eMAjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMDcxNTQ0NDNaMA0GCSqGSIb3DQEBAQUABIIBAKTRHj6ZtTKxIeMlgMxs +lUHdGtUAvCNaXF9ZifntUvGcArd2NeS1AqJIw2vOsnd/5tjJV0rr8ht3B4SZVFKi5C4PbWN n12ODLCFQIEDPRf/Q1w7wFVZi517Dbs+3HvvZgr+4fF0k4yY/t7fl2EtYMnpZCJYTyRd8Mcx sH3Hg5FnmYpfDanLuVx651/q4hQWJ7wIVOdi5bQIU1IBH9XDNdKQTXTw0e3WdMeqaWb0GGm+ o7/NPAIunUN+iqDIx7pqvDNBmAkO4zFxcyz/lM3m63r9p3A0043IDDa4hc72ybjxEd6r6Ccz HqwVn1NsW2/nuDHl64AYOZuJLZ8rcZftpk4= --B_3571717483_716144670-- From nobody Tue Mar 7 09:26:02 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E96129599 for ; Tue, 7 Mar 2017 09:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 edrsc7exYkY1 for ; Tue, 7 Mar 2017 09:26:00 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 634A7129534 for ; Tue, 7 Mar 2017 09:26:00 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v27HPh16010938; Tue, 7 Mar 2017 12:25:54 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 291xsyg0ug-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Mar 2017 12:25:54 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v27HPrAX009875; Tue, 7 Mar 2017 12:25:53 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v27HPeF0009616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Mar 2017 12:25:47 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 7 Mar 2017 17:25:29 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v27HPQR1010123; Tue, 7 Mar 2017 11:25:29 -0600 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v27HOKFA001812; Tue, 7 Mar 2017 11:24:20 -0600 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id 58B74E0373; Tue, 7 Mar 2017 12:24:19 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Tue, 7 Mar 2017 12:24:19 -0500 From: "MORTON, ALFRED C (AL)" To: Michelle Cotton Thread-Topic: Follow-up questions for ippm drafts Thread-Index: AQHSl1mrDAU0S7t5ukyBjsF/+SMpsKGJnDap Date: Tue, 7 Mar 2017 17:24:18 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F0D069@njmtexg5.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.77.204.217] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-07_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703070138 Archived-At: Cc: Sabrina Tanamal , Amanda Baber , "ippm@ietf.org" Subject: Re: [ippm] Follow-up questions for ippm drafts X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:26:01 -0000 Hi Michelle, You're right, section 7 ( and 8) are different from the earlier ones, in that it specifies 5 separate=20 Registry entries with unique IDs for each one. Section 7.0 says: Note: Each Registry "Name" below specifies a single registry entry, whose output format varies according to a component of the name that specifies one form of statistical summary. IANA is asked to assign a different numeric identifiers to each Name. All column entries beside the Summary and Output categories are the same, thus this section proposes five closely-related registry entries. As a result, IANA is also asked to assign corresponding URIs and URLs. Every section, except section 7.4.2 is the same for all 5 registry entries. 7.4.2 contains subsections that correspond to each metric name, so 7.4.2.1 "95Percentile" will correspond to the metric ending in 95Percent= ile. As I was updating the draft yesterday, I noted that the URN sections were Not consistent. I will enusre that they are before uploading the revised version. =20 The URN we plan to request is urn:ietf:metrics:perf:=20 with two new sub-namespaces. Hope this helps! I'll send the revised text after your complete review later today. Thanks again, Al ________________________________________ From: Michelle Cotton [michelle.cotton@iana.org] Sent: Tuesday, March 07, 2017 10:44 AM To: MORTON, ALFRED C (AL) Cc: ippm@ietf.org; Amanda Baber; Sabrina Tanamal Subject: Follow-up questions for ippm drafts Hi Al, I=92m working on a full review of draft-ietf-ippm-initial-registry-02 and d= raft-ietf-ippm-metric-registry-10. I have some questions that need clarifi= cation before I send the full review. In section 7.1.2 of the initial registry document, it lists multiple names: OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_ OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_95Percenti= le OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Mean OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Min OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Max OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_StdDev How does that work in the registry? Do we add all of these names with the = same ID number or different ID numbers? Do they all have identical summary= information in the table? Will they all link to the same template? Can y= ou clarify? Also, in section 7.1.3 of the metric registry document, it says the followi= ng URN will be created: urn:ietf:metric:perf: In some of our discussions =93metric=94 was used and also =93metrics=94. P= lease confirm which will be used. In section 4.1.3. of the initial registry document, it shows the following = URN: URN: Prefix urn:ietf:params:performance:metric: I had understood these will not be going under =93params=94 and also in thi= s example =93performance=94 is expanded. Please confirm that this should n= ot be under params and wheter =93perf=94 or =93performance=94 should be use= d. This also appears in section 9.1.3. Answers to these questions will contribute to the full review which I hope = to have to you all later today. Thanks! --Michelle From nobody Tue Mar 7 09:59:41 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F048129474 for ; Tue, 7 Mar 2017 09:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 GVbjqI5ABfRY for ; Tue, 7 Mar 2017 09:59:39 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C98612945A for ; Tue, 7 Mar 2017 09:59:39 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Mar 2017 09:59:37 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 7 Mar 2017 09:59:37 -0800 From: Michelle Cotton To: "MORTON, ALFRED C (AL)" Thread-Topic: Review of draft-ietf-ippm-metric-registry-10 and draft-ietf-ippm-initial-registry-02 Thread-Index: AQHSl2yVkxV2Xuoj8kWg/ar2TtEqog== Date: Tue, 7 Mar 2017 17:59:36 +0000 Message-ID: <5E8A1299-746B-4392-902A-E228ABFD691D@iana.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3571725608_2017132018" MIME-Version: 1.0 Archived-At: Cc: Sabrina Tanamal , Amanda Baber , "ippm@ietf.org" Subject: [ippm] Review of draft-ietf-ippm-metric-registry-10 and draft-ietf-ippm-initial-registry-02 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:59:41 -0000 --B_3571725608_2017132018 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Attn: Al Morton and IPPM Working Group At the request of Al Morton, I have re-reviewed the IPPM documents (draft-i= etf-ippm-metric-registry-10 and draft-ietf-ippm-initial-registry-02) with a = focus on the registry actions that are being requested by IANA Services and = making sure we understand what is being requested. Apologies for the long message below. There was lots of registry actions t= o work with. =E2=98=BA NOTE: The registry mock-ups below and initial entries may not perfectly lin= e-up so please ignore spacing. We understand the draft-ietf-ippm-metric-registry-10 document to request th= e following: 1) Registration of a URI prefix called urn:ietf:metrics: in the following r= egistry: http://www.iana.org/assignments/params/params.xhtml#urn-subnamespaces The entry, =E2=80=9Cmetrics=E2=80=9D will look something like this: metrics RFC-ietf-ippm-metric-registry TBD (potentially http://www= .iana.org/assignments/perf-metric-parameters) 2) A new set of registries will be created at TBD (potentially=20 http://www.iana.org/assignments/perf-metric-parameters) IETF URN Sub-namespace for Metrics (urn:ietf:metrics) Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry Registered Metric Identifiers perf RFC-ietf-ippm-metric-registry =20 At a URL TBD (potentially http://www.iana.org/assignments/perf-metric-param= eters) Performance Metric Name Elements - Metric Types Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry MetricType Description Reference =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 RTDelay Round Trip Delay RTDNS Response Time Domain Name Service OWDelay One Way Delay RTLoss Round Trip Loss OWLoss One Way Loss OWPDV One Way Packet Delay Variation OWIPDV One Way Inter-Packet Delay Variation OWReorder One Way Packet Reordering OWDuplic One Way Packet Duplication OWBTC One Way Bulk Transport Capacity OWMBM One Way Model Based Metric SPMonitor Single Point Monitor MPMonitor Multi-Point Monitor Performance Metric Name Elements - Methods Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry Methods Description Reference =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Active depends on a dedicated measurement packet stream and observations = of the stream Passive depends *solely* on observation of one or more existing packet st= reams HybridType1 obervations on one stream that combine both active and passiv= e methods HybridType2 obervations on two or more streams that combine both active a= nd passive methods Spatial Spatial Metric of RFC5644 Performance Metric Name Elements - SubType Methods Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry SubType Methods Description Reference =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94 ICMP Internet Control Message Protocol IP Internet Protocol DSCPxx where xx is replaced by a Diffserv code point UDP User Datagram Protocol TCP Transport Control Protocol Poisson Packet generation using Poisson distribution Periodic Periodic packet generation PayloadxxxxB where xxxx is replaced by an integer, the number of octets i= n the Payload SustainedBurst Capacity test, worst case StandingQueue test of bottleneck queue behavior @@@@ Performance Metric Name Elements - Units Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry Units Description Reference =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Seconds RatioPercent value multiplied by 100 BPS Bits per Second EventTotal for unit-less counts Multiple more than one type of unit Enumerated a list of outcomes Unit-less Performance Metric Name Elements - Output Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry Units Description Reference =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Singleton sometimes called raw data Minimum Maximum Median Mean 95Percentile 95th Percentile 99Percentile 99th Percentile StdDev Standard Deviation Variance PFI Pass, Fail, Inconclusive FlowRecords descriptions of flows observed NOTE: For all the above entries, the reference will be RFC-ietf-ippm-metri= c-registry. Please confirm what the registration procedures should be for a= dding to all the above registries. NOTE: You will notice that I am suggesting breaking up the actual element = registration and description in the above element registries. I think it is= a cleaner approach for the registry fields, however if you feel that they s= hould be listed together with the description in parenthesis, please let us = know. 3) Creation of a new registry called Registered Performance Metrics, popula= ted with the following initial assignments Registered Performance Metrics Registration Procedures: Expert Review Identifier Name URIs Description Reference Change Controller Version 0 Reserved TBD1 RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95percentile (fro= m section 4) TBD2 OWPDV_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile (from = section 5) TBD3 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile (from s= ection 6) TBD4 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_ (from section 7) TBD5 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_95Perc= entile (from section 7) TBD6 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Mean (= from section 7) TBD7 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Min (f= rom section 7) TBD8 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Max (f= rom section 7) TBD9 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_StdDev= (from section 7) 10-64511 Unassigned 64512 to 65536 Reserved for private use NOTE: For the above registrations, the summary information in the table wi= ll be completed using the information from draft-ietf-ippm-initial-registry.= The URI column will link to a template where the complete information abou= t the registration can be found (copied directly from ietf-ippm-initial-regi= stry). NOTE: I suggest re-arranging some of the requests for registry creation so= that they flow in order a bit better. Some wording changes may be needed t= o further clarify and reflect what actions are being requested if what we ou= tlined above is indeed correct. If I missed anything, please do not hesitat= e to let me know. If anything in my review above is not clear please let me= know. We are happy to review new versions of the document. =20 We will also be in Chicago if meeting in person is easier :) Best regards, Michelle Cotton Protocol Parameters Engagement Manager IANA Services =20 --B_3571725608_2017132018 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIISBAYJKoZIhvcNAQcCoIIR9TCCEfECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg+5MIIFqDCCBJCgAwIBAgIQCuvDwxHaHKymSygUiz0IATANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTYx MDAzMDAwMDAwWhcNMTkxMDAzMTIwMDAwWjCBxTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxJDAiBgNVBAMTG01pY2hl bGxlIENvdHRvbiBJQU5BIDNPY3QxNjEnMCUGCSqGSIb3DQEJARYYbWljaGVsbGUuY290dG9u QGlhbmEub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6V4aMB8RQMy4vQOd nvINsoYARWq26DERE228XVCA7SxnxpHKRAgnpV4iBoL5rgjsiJy5utpRlbCZcV7PVaVp6yxM ozNUSzmiSu+O04PyYWjvJRzSLda6W0hc8B766JDK3V8QVX+5Pnt9E2JxyYL6j5zTrD/kZGTB XpaRNBF5DorhvPEwXNuRyWt5yD3m4vMwinCahC+5DB78PlxvbbEgTLenW8ZnSOunflX11Q8W XkYBAHEWLSDEO8MY4t7b7FBTWoDA6arnmiJApfBm+tfJ9VPto6KX1YWWuUMrmg7PVF6jfiuW ncwVZzed6VBW9Sp1oVKWP3GXraq0glyTutf5MQIDAQABo4IB8TCCAe0wHwYDVR0jBBgwFoAU 5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD4OJSm8pR0KSROJ2Te94XiGhEJAMAwG A1UdEwEB/wQCMAAwIwYDVR0RBBwwGoEYbWljaGVsbGUuY290dG9uQGlhbmEub3JnMA4GA1Ud DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4 BgpghkgBhv1sBAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9D UFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EtZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8v Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqG SIb3DQEBCwUAA4IBAQCFn08dbc9474OYmBeeFe4I08uzdP/Glg78Au1o7+IhufO+BN/fqn31 VhE7Q2aYCh28LF99PbdJ2IOBsz+BUGlrz7C0UvrHjmbXBTuR/gHez2Hmk6SOu0o4anLJqVFl xMzQtpBQXWM0K8GlyqDlPtiWQDORtUsMOXnL2+smNqb5xoz1SyK30KEMMeq9ZndDuBpM1Gyh 7JdgiLypKnYfRc1c1INCWiDlvpTA+C60BZSv5e/k1GMW0USd7TZTzphQxKmLNRUXUxRjub3H Yiby5y1hTnUyalL6HHbYVJX8bOgmaaOAjLvsJzX0rHRaMYlFbC4CgNlQNExJd4Xt7c39ghay MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIw MDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEy IEFzc3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q1 78AneRstBYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4i LCv4un7JNTtW8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P 5lB6UB8lRejxia/N/17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqC QQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BP y4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMB Af8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUH MAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDov L2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0 aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGqMIIBpjCCAaIGCmCG SAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAg AEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBj AGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBs AGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y 17yUC9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG 9w0BAQsFAAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61 +uBiGZmmB5p8Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbO kWDj+aBWDEgQzjNoe82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C 2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZV PVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjCC A7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAw MFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyx h/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wx hCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEb w4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0K yEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+ HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYD VR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i 7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfq VsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/ K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9r DDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+l t2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggIPMIICCwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQCuvDwxHaHKym SygUiz0IATANBglghkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCAh1uVpXJYNCWqmRFNp 7n4MOwUdUYoCG/dzwvDLF/j+LjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMDcxODAwMDhaMA0GCSqGSIb3DQEBAQUABIIBAD9zju1RJK163ew76IC/ g+i9bIrHzB+C+RwInidNbAoH8XfHipKWB+92qgacf7rqL//P4XLA89Fj4Pmhp743wjghl/+A lc8eCBvZuplEq8tvuqHQS0zSoPiCGlPvToR/I2OFO+r5PEdbSSElycwY1OUuOySPPZV6QwhN 05kdayza/ttSp3Lle07xp3NFycWHvk2DyOY9x/UdgocAPp/CFq53NcjIgYBdwCEYXfpxVvTv l2TOV1hsXoYGCYHeDx82d8I5FwqkJxBk0n8dbc3qqmcy9FhWBL/1jhXnJYfT25F4DNYTrkQz fYKqJuv/26E2Zg/c8B60VEF0EOzfGbY00Jk= --B_3571725608_2017132018-- From nobody Tue Mar 7 11:06:47 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4009712940F for ; Tue, 7 Mar 2017 11:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 stxZQUldpX8c for ; Tue, 7 Mar 2017 11:06:44 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45067127A91 for ; Tue, 7 Mar 2017 11:06:44 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Mar 2017 11:06:41 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 7 Mar 2017 11:06:41 -0800 From: Michelle Cotton To: "MORTON, ALFRED C (AL)" Thread-Topic: Revised: Review of draft-ietf-ippm-metric-registry-10 and draft-ietf-ippm-initial-registry-02 Thread-Index: AQHSl3X0jAGJzVywTUiuEAeWuI5AGQ== Date: Tue, 7 Mar 2017 19:06:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3571729632_1874246504" MIME-Version: 1.0 Archived-At: Cc: Sabrina Tanamal , Amanda Baber , "ippm@ietf.org" Subject: [ippm] Revised: Review of draft-ietf-ippm-metric-registry-10 and draft-ietf-ippm-initial-registry-02 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 19:06:46 -0000 --B_3571729632_1874246504 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable REVISED: It looks like in my message below that I copied an old version of the revie= w. It did not include the other registrations in the Performance Metrics Regis= try from section 8. Added them below. Thanks, Michelle -----Original Message----- From: Michelle Cotton Date: Tuesday, March 7, 2017 at 10:00 AM To: "MORTON, ALFRED C (AL)" Cc: "ippm@ietf.org" , Amanda Baber , = Sabrina Tanamal Subject: Review of draft-ietf-ippm-metric-registry-10 and draft-ietf-ippm-i= nitial-registry-02 Attn: Al Morton and IPPM Working Group =20 At the request of Al Morton, I have re-reviewed the IPPM documents (dra= ft-ietf-ippm-metric-registry-10 and draft-ietf-ippm-initial-registry-02) wit= h a focus on the registry actions that are being requested by IANA Services = and making sure we understand what is being requested. =20 Apologies for the long message below. There was lots of registry actio= ns to work with. =E2=98=BA =20 NOTE: The registry mock-ups below and initial entries may not perfectly= line-up so please ignore spacing. =20 We understand the draft-ietf-ippm-metric-registry-10 document to reques= t the following: =20 1) Registration of a URI prefix called urn:ietf:metrics: in the followi= ng registry: http://www.iana.org/assignments/params/params.xhtml#urn-subnamespaces =20 The entry, =E2=80=9Cmetrics=E2=80=9D will look something like this: =20 metrics RFC-ietf-ippm-metric-registry TBD (potentially http:/= /www.iana.org/assignments/perf-metric-parameters) =20 2) A new set of registries will be created at TBD (potentially=20 http://www.iana.org/assignments/perf-metric-parameters) =20 =20 IETF URN Sub-namespace for Metrics (urn:ietf:metrics) Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry =20 Registered Metric Identifiers =20 perf RFC-ietf-ippm-metric-registry =20 =20 =20 At a URL TBD (potentially http://www.iana.org/assignments/perf-metric-p= arameters) =20 Performance Metric Name Elements - Metric Types Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry =20 MetricType Description Reference =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 RTDelay Round Trip Delay RTDNS Response Time Domain Name Service OWDelay One Way Delay RTLoss Round Trip Loss OWLoss One Way Loss OWPDV One Way Packet Delay Variation OWIPDV One Way Inter-Packet Delay Variation OWReorder One Way Packet Reordering OWDuplic One Way Packet Duplication OWBTC One Way Bulk Transport Capacity OWMBM One Way Model Based Metric SPMonitor Single Point Monitor MPMonitor Multi-Point Monitor =20 =20 Performance Metric Name Elements - Methods Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry =20 Methods Description Reference =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Active depends on a dedicated measurement packet stream and observati= ons of the stream Passive depends *solely* on observation of one or more existing packe= t streams HybridType1 obervations on one stream that combine both active and pa= ssive methods HybridType2 obervations on two or more streams that combine both acti= ve and passive methods Spatial Spatial Metric of RFC5644 =20 Performance Metric Name Elements - SubType Methods Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry =20 SubType Methods Description Reference =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94 ICMP Internet Control Message Protocol IP Internet Protocol DSCPxx where xx is replaced by a Diffserv code point UDP User Datagram Protocol TCP Transport Control Protocol Poisson Packet generation using Poisson distribution Periodic Periodic packet generation PayloadxxxxB where xxxx is replaced by an integer, the number of octe= ts in the Payload SustainedBurst Capacity test, worst case StandingQueue test of bottleneck queue behavior @@@@ =20 Performance Metric Name Elements - Units Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry =20 Units Description Reference =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Seconds RatioPercent value multiplied by 100 BPS Bits per Second EventTotal for unit-less counts Multiple more than one type of unit Enumerated a list of outcomes Unit-less =20 Performance Metric Name Elements - Output Registration Procedures: ?? Reference: RFC-ietf-ippm-metric-registry =20 Units Description Reference =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Singleton sometimes called raw data Minimum Maximum Median Mean 95Percentile 95th Percentile 99Percentile 99th Percentile StdDev Standard Deviation Variance PFI Pass, Fail, Inconclusive FlowRecords descriptions of flows observed =20 =20 NOTE: For all the above entries, the reference will be RFC-ietf-ippm-m= etric-registry. Please confirm what the registration procedures should be f= or adding to all the above registries. =20 NOTE: You will notice that I am suggesting breaking up the actual elem= ent registration and description in the above element registries. I think i= t is a cleaner approach for the registry fields, however if you feel that th= ey should be listed together with the description in parenthesis, please let= us know. =20 =20 3) Creation of a new registry called Registered Performance Metrics, po= pulated with the following initial assignments =20 Registered Performance Metrics Registration Procedures: Expert Review =20 Identifier Name URIs Description Reference Change Controller Vers= ion 0 Reserved TBD1 RTDelay_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95percentile = (from section 4) TBD2 OWPDV_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile (f= rom section 5) TBD3 RTDNS_Active_IP-UDP-Poisson_RFCXXXXsecY_Seconds_95Percentile (fr= om section 6) TBD4 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_ (from section 7) TBD5 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_95= Percentile (from section 7) TBD6 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Me= an (from section 7) TBD7 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Mi= n (from section 7) TBD8 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_Ma= x (from section 7) TBD9 OWDelay_Active_IP-UDP-Poisson-Payload250B_RFCXXXXsecY_Seconds_St= dDev (from section 7) TBD10 OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_ (from section 8) TBD11 OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_95= Percentile (from section 8) TBD12 OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Me= an (from section 8) TBD13 OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_Mi= n (from section 8) TBD14 OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_M= ax (from section 8) TBD15 OWDelay_Active_IP-UDP-Periodic-Payload142B_RFCXXXXsecY_Seconds_S= tdDev (from section 8) 16-64511 Unassigned 64512 to 65536 Reserved for private use =20 NOTE: For the above registrations, the summary information in the tabl= e will be completed using the information from draft-ietf-ippm-initial-regis= try. The URI column will link to a template where the complete information = about the registration can be found (copied directly from ietf-ippm-initial-= registry). =20 NOTE: I suggest re-arranging some of the requests for registry creatio= n so that they flow in order a bit better. Some wording changes may be need= ed to further clarify and reflect what actions are being requested if what w= e outlined above is indeed correct. If I missed anything, please do not hes= itate to let me know. If anything in my review above is not clear please le= t me know. =20 We are happy to review new versions of the document. =20 We will also be in Chicago if meeting in person is easier :) =20 =20 Best regards, =20 Michelle Cotton Protocol Parameters Engagement Manager IANA Services =20 =20 --B_3571729632_1874246504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIISBAYJKoZIhvcNAQcCoIIR9TCCEfECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg+5MIIFqDCCBJCgAwIBAgIQCuvDwxHaHKymSygUiz0IATANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTYx MDAzMDAwMDAwWhcNMTkxMDAzMTIwMDAwWjCBxTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExFDASBgNVBAcTC0xvcyBBbmdlbGVzMTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jw b3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMgYW5kIE51bWJlcnMxJDAiBgNVBAMTG01pY2hl bGxlIENvdHRvbiBJQU5BIDNPY3QxNjEnMCUGCSqGSIb3DQEJARYYbWljaGVsbGUuY290dG9u QGlhbmEub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6V4aMB8RQMy4vQOd nvINsoYARWq26DERE228XVCA7SxnxpHKRAgnpV4iBoL5rgjsiJy5utpRlbCZcV7PVaVp6yxM ozNUSzmiSu+O04PyYWjvJRzSLda6W0hc8B766JDK3V8QVX+5Pnt9E2JxyYL6j5zTrD/kZGTB XpaRNBF5DorhvPEwXNuRyWt5yD3m4vMwinCahC+5DB78PlxvbbEgTLenW8ZnSOunflX11Q8W XkYBAHEWLSDEO8MY4t7b7FBTWoDA6arnmiJApfBm+tfJ9VPto6KX1YWWuUMrmg7PVF6jfiuW ncwVZzed6VBW9Sp1oVKWP3GXraq0glyTutf5MQIDAQABo4IB8TCCAe0wHwYDVR0jBBgwFoAU 5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFD4OJSm8pR0KSROJ2Te94XiGhEJAMAwG A1UdEwEB/wQCMAAwIwYDVR0RBBwwGoEYbWljaGVsbGUuY290dG9uQGlhbmEub3JnMA4GA1Ud DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4 BgpghkgBhv1sBAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9D UFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EtZzIuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzIuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8v Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqG SIb3DQEBCwUAA4IBAQCFn08dbc9474OYmBeeFe4I08uzdP/Glg78Au1o7+IhufO+BN/fqn31 VhE7Q2aYCh28LF99PbdJ2IOBsz+BUGlrz7C0UvrHjmbXBTuR/gHez2Hmk6SOu0o4anLJqVFl xMzQtpBQXWM0K8GlyqDlPtiWQDORtUsMOXnL2+smNqb5xoz1SyK30KEMMeq9ZndDuBpM1Gyh 7JdgiLypKnYfRc1c1INCWiDlvpTA+C60BZSv5e/k1GMW0USd7TZTzphQxKmLNRUXUxRjub3H Yiby5y1hTnUyalL6HHbYVJX8bOgmaaOAjLvsJzX0rHRaMYlFbC4CgNlQNExJd4Xt7c39ghay MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQu Y29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIw MDAwWhcNMjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEy IEFzc3VyZWQgSUQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q1 78AneRstBYeiEEMx3w7UFRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4i LCv4un7JNTtW8R98Qn4lsCMZxkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P 5lB6UB8lRejxia/N/17/UPPwFxH/vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqC QQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BP y4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMB Af8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUH MAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDov L2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0 aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGqMIIBpjCCAaIGCmCG SAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAg AEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBj AGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABB AGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBs AGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABl AHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y 17yUC9k/dDlJMjyKeTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG 9w0BAQsFAAOCAQEATtSJJ7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61 +uBiGZmmB5p8Eyfb5QKihBLZFfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbO kWDj+aBWDEgQzjNoe82Tq/Bqy09YD7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C 2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZV PVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447fISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjCC A7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAw MFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyx h/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wx hCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEb w4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0K yEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+ HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYD VR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i 7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfq VsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/ K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9r DDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+l t2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggIPMIICCwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQCuvDwxHaHKym SygUiz0IATANBglghkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCDrXyUjAXx56XbUgwkO PcYtgtB7DEuXqc8reBlRGkABbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzAzMDcxOTA3MTJaMA0GCSqGSIb3DQEBAQUABIIBAGnsTd7NncdqJXaSX3wc ik5HSbBdgASpH9DkNWCE6QQzGCEnn4AsvPSLUjNTXKO6y1/dyqBq78LHgKm9ghazzEhc8ymc EURVM1QHmMi+8cfDr85lviG4nPavEfpDy0Wod0E+6YNfK1z9LsR6iI5abVj8fyk9T/i5xGYG GS+JlGbMNZI+gJiNF0Oo7n6rP1KMQe39x4mMz+FzjZeZATOTh6d77RogA0TGxwPaVU7EZJLI CQfoi/6XmjrdQTjSjD3JQ2UeZ6ixKNet6ScsU0DsOEb0HZDEbtcTeKn1urF3YvssY7raTP/Y zX1DmsH8n7ReAfQGcuqYboauLLbhx/V4xUg= --B_3571729632_1874246504-- From nobody Tue Mar 7 16:46:18 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749E41294BB for ; Tue, 7 Mar 2017 16:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 eHnmq47LV75n for ; Tue, 7 Mar 2017 16:46:11 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 8BB12129547 for ; Tue, 7 Mar 2017 16:46:10 -0800 (PST) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v280iZRh015434; Tue, 7 Mar 2017 19:46:06 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 29236tyaf1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Mar 2017 19:46:06 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v280k5qu023059; Tue, 7 Mar 2017 19:46:06 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v280k3VK023053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Mar 2017 19:46:05 -0500 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 8 Mar 2017 00:45:42 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v280jgFY012838; Tue, 7 Mar 2017 18:45:42 -0600 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v280jTFr010956; Tue, 7 Mar 2017 18:45:30 -0600 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id EBA93F042A; Tue, 7 Mar 2017 19:45:16 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Tue, 7 Mar 2017 19:45:16 -0500 From: "MORTON, ALFRED C (AL)" To: Michelle Cotton Thread-Topic: Revised: Review of draft-ietf-ippm-metric-registry-10 and draft-ietf-ippm-initial-registry-02 Thread-Index: AQHSl3X0jAGJzVywTUiuEAeWuI5AGaGKCU4w Date: Wed, 8 Mar 2017 00:45:15 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F0F2D0@njmtexg5.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.251.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-07_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703080004 Archived-At: Cc: Sabrina Tanamal , Amanda Baber , "ippm@ietf.org" Subject: Re: [ippm] Revised: Review of draft-ietf-ippm-metric-registry-10 and draft-ietf-ippm-initial-registry-02 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 00:46:16 -0000 SGkgTWljaGVsbGUsDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgZWFybHkgcmV2aWV3IGFu ZCBjb21tZW50cy4NCkFzIHlvdSBzYWlkLCBpdCdzIGEgbG9uZyBtZXNzYWdlLCBzbyBJJ2xsIHB1 bGwgb3V0IGEgDQpxdWVzdGlvbnMvaXNzdWVzIGFuZCByZXNwb25kIHRvIHRoZW0gaGVyZS4gUmV2 aXNlZCANCnZlcnNpb25zIG9mIHRoZSBkcmFmdHMgd2lsbCBmb2xsb3cgc2hvcnRseS4NCg0KSW4g QWN0aW9uIDEpLCBpbiBhZGRpdGlvbiB0byB0aGUgbmV3IFVSSSBwcmVmaXggDQpjYWxsZWQgdXJu OmlldGY6bWV0cmljczogIA0Kd2UgYXJlIGFsc28gcmVxdWVzdGluZyBuZXcgVVJJIHByZWZpeCAN CmNhbGxlZCB1cm46aWV0ZjptZXRyaWNzOnBlcmYgIA0KVGhlIHJlZ2lzdHJhdGlvbiBwcm9jZWR1 cmVzIGZvciBzdWItbmFtZXNwYWNlcyBvZg0KdXJuOmlldGY6bWV0cmljczogYW5kIHVybjppZXRm Om1ldHJpY3M6cGVyZjoNCmFyZSBzcGVjaWZpZWQgaW4gdGhlIG5ldyB0ZXh0IG9mIFNlY3Rpb24g MTAuMSBpbg0KZHJhZnQtaWV0Zi1pcHBtLW1ldHJpYy1yZWdpc3RyeSAobmV4dCB2ZXJzaW9uLCAx MSkuDQoNClRoZSBhZGRpdGlvbmFsIGFzc2lnbm1lbnQgb2YgdXJuOmlldGY6bWV0cmljczpwZXJm DQpyZXF1aXJlcyBjb3JyZXNwb25kaW5nIGNoYW5nZXMgdG8gQWN0aW9ucyAyKSBhbmQgMykuDQoN CkluIEFjdGlvbiAyKSwgSSB0aGluayBJIHVuZGVyc3RhbmQgdGhhdCBlYWNoIE5hbWUgRWxlbWVu dA0KKHN1Y2ggYXMgTWV0cmljVHlwZSBhbmQgTWV0aG9kKSB3aWxsIGJlIGEgc2VwYXJhdGUgcmVn aXN0cnkuDQpJIGhhdmUgd3JpdHRlbiBhIG5ldyBzZWN0aW9uIDEwLjIgaW4gDQpkcmFmdC1pZXRm LWlwcG0tbWV0cmljLXJlZ2lzdHJ5LTExIHRvIHRha2UgdGhpcyANCm9yZ2FuaXphdGlvbiBvZiB0 aGUgaW5mbyBpbnRvIGFjY291bnQNCmFuZCBwcm92aWRlIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vk dXJlcyAoRXhwZXJ0IFJldmlldykuDQpUaGUgcmVnaXN0cmllcyB5b3UgY3JlYXRlZCBiZWxvdyBs b29rIGZpbmUgdG8gbWUsIGdyZWF0IQ0KQnJlYWtpbmcgdXAgdGhlIE5hbWVzIGFuZCBEZXNjcmlw dGlvbnMgKGFzIHlvdSBkaWQpIGlzIGZpbmUuDQoNCkluIEFjdGlvbiAzKSwgSSBjYXVzZWQgc29t ZSBjb25mdXNpb24gYnkgaW5jbHVkaW5nIHRoZSANCm1ldHJpYyBuYW1lcyB3aXRoIDxzdGF0aXN0 aWM+IGF0IHRoZSBlbmQuICBUaGVzZSB3ZXJlIG1lYW50DQp0byBpbGx1c3RyYXRlIGhvdyB3ZSBh cmUgc3Vic3RpdHV0aW5nIG9uZSBvZiB0aGUgTmFtZSBlbGVtZW50cw0KZm9yIDxzdGF0aXN0aWM+ LCBidXQgb3RoZXJ3aXNlIHRoZSBuYW1lIHN0YXlzIHRoZSBzYW1lLg0KVGhlIG5hbWVzIHdpdGgg dGhlIDxzdGF0aXN0aWM+IGVsZW1lbnQgd2VyZSBub3QgbWVhbnQgdG8gYmUgDQpyZWdpc3RlcmVk Lg0KDQpTbywgdGhlIFBlcmZvcm1hbmNlIE1ldHJpY3MgUmVnaXN0cnkgc2hvdWxkIGxvb2sgbGlr ZSB0aGlzOg0KDQogICAgUmVnaXN0ZXJlZCBQZXJmb3JtYW5jZSBNZXRyaWNzDQogICAgUmVnaXN0 cmF0aW9uIFByb2NlZHVyZXM6IEV4cGVydCBSZXZpZXcNCiAgICANCiAgICBJZGVudGlmaWVyCU5h bWUgIFVSSXMgIERlc2NyaXB0aW9uICBSZWZlcmVuY2UgICBDaGFuZ2UgQ29udHJvbGxlciAgVmVy c2lvbg0KICAgIDAgICAgICBSZXNlcnZlZA0KICAgIFRCRDEgICBSVERlbGF5X0FjdGl2ZV9JUC1V RFAtUG9pc3Nvbl9SRkNYWFhYc2VjWV9TZWNvbmRzXzk1cGVyY2VudGlsZSAgKGZyb20gc2VjdGlv biA0KQ0KICAgIFRCRDIgICBPV1BEVl9BY3RpdmVfSVAtVURQLVBvaXNzb25fUkZDWFhYWHNlY1lf U2Vjb25kc185NVBlcmNlbnRpbGUgIChmcm9tIHNlY3Rpb24gNSkNCiAgICBUQkQzICAgUlRETlNf QWN0aXZlX0lQLVVEUC1Qb2lzc29uX1JGQ1hYWFhzZWNZX1NlY29uZHNfOTVQZXJjZW50aWxlIChm cm9tIHNlY3Rpb24gNikNCiAgICBUQkQ0ICAgT1dEZWxheV9BY3RpdmVfSVAtVURQLVBvaXNzb24t UGF5bG9hZDI1MEJfUkZDWFhYWHNlY1lfU2Vjb25kc185NVBlcmNlbnRpbGUgKGZyb20gc2VjdGlv biA3KQ0KICAgIFRCRDUgICBPV0RlbGF5X0FjdGl2ZV9JUC1VRFAtUG9pc3Nvbi1QYXlsb2FkMjUw Ql9SRkNYWFhYc2VjWV9TZWNvbmRzX01lYW4gKGZyb20gc2VjdGlvbiA3KQ0KICAgIFRCRDYgICBP V0RlbGF5X0FjdGl2ZV9JUC1VRFAtUG9pc3Nvbi1QYXlsb2FkMjUwQl9SRkNYWFhYc2VjWV9TZWNv bmRzX01pbiAoZnJvbSBzZWN0aW9uIDcpDQogICAgVEJENyAgIE9XRGVsYXlfQWN0aXZlX0lQLVVE UC1Qb2lzc29uLVBheWxvYWQyNTBCX1JGQ1hYWFhzZWNZX1NlY29uZHNfTWF4IChmcm9tIHNlY3Rp b24gNykNCiAgICBUQkQ4ICAgT1dEZWxheV9BY3RpdmVfSVAtVURQLVBvaXNzb24tUGF5bG9hZDI1 MEJfUkZDWFhYWHNlY1lfU2Vjb25kc19TdGREZXYgKGZyb20gc2VjdGlvbiA3KQ0KICAgIFRCRDkg ICBPV0RlbGF5X0FjdGl2ZV9JUC1VRFAtUGVyaW9kaWMtUGF5bG9hZDE0MkJfUkZDWFhYWHNlY1lf U2Vjb25kc185NVBlcmNlbnRpbGUgKGZyb20gc2VjdGlvbiA4KQ0KICAgIFRCRDEwIE9XRGVsYXlf QWN0aXZlX0lQLVVEUC1QZXJpb2RpYy1QYXlsb2FkMTQyQl9SRkNYWFhYc2VjWV9TZWNvbmRzX01l YW4gKGZyb20gc2VjdGlvbiA4KQ0KICAgIFRCRDExIE9XRGVsYXlfQWN0aXZlX0lQLVVEUC1QZXJp b2RpYy1QYXlsb2FkMTQyQl9SRkNYWFhYc2VjWV9TZWNvbmRzX01pbiAoZnJvbSBzZWN0aW9uIDgp DQogICAgVEJEMTIgIE9XRGVsYXlfQWN0aXZlX0lQLVVEUC1QZXJpb2RpYy1QYXlsb2FkMTQyQl9S RkNYWFhYc2VjWV9TZWNvbmRzX01heCAoZnJvbSBzZWN0aW9uIDgpDQogICAgVEJEMTMgIE9XRGVs YXlfQWN0aXZlX0lQLVVEUC1QZXJpb2RpYy1QYXlsb2FkMTQyQl9SRkNYWFhYc2VjWV9TZWNvbmRz X1N0ZERldiAoZnJvbSBzZWN0aW9uIDgpDQogICAgMTQtNjQ1MTEgVW5hc3NpZ25lZA0KICAgIDY0 NTEyIHRvIDY1NTM2IFJlc2VydmVkIGZvciBwcml2YXRlIHVzZQ0KICAgIA0KSSdsbCBuZWVkIHRv IGNoYW5nZSB0aGUgdGV4dCBvZiBTZWN0aW9uIDcuMS4yIGFuZCA4LjEuMiBvZiANCmRyYWZ0LWll dGYtaXBwbS1pbml0aWFsLXJlZ2lzdHJ5ICh2ZXJzaW9uIDAzIHdoZW4gdXBkYXRlZCkNCnRvIHRy eSB0byBtYWtlIHRoaXMgbW9yZSBjbGVhci4NCg0KQWxzbywgdGhlcmUgYXJlIHRocmVlIHNlY3Rp b25zIHdoZXJlIHRoZSBtZXRyaWMgZW50cmllcw0KaW4gc2VjdGlvbiA3IGFuZCA4IHdpbGwgY2hh bmdlOg0KDQpOYW1lICAgICAgICAgICAgICAgICAgICAoNy4xLjIpDQpEZXNjcmlwdGlvbiAgICAg ICAgICAgICAoNy4xLjQpDQpPdXRwdXQNCiAtIFJlZmVyZW5jZSBEZWZpbml0aW9uICg3LjQuMikN Cg0KU28sIHdhdGNoIGZvciB0aGUgdXBkYXRlcyBvZiB0aGVzZSB0d28gZHJhZnRzIHNob3J0bHku DQoNCnRoYW5rcyBhZ2FpbiENCkFsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBNaWNoZWxsZSBDb3R0b24gW21haWx0bzptaWNoZWxsZS5jb3R0b25AaWFuYS5vcmdd DQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA3LCAyMDE3IDI6MDcgUE0NCj4gVG86IE1PUlRPTiwg QUxGUkVEIEMgKEFMKQ0KPiBDYzogaXBwbUBpZXRmLm9yZzsgQW1hbmRhIEJhYmVyOyBTYWJyaW5h IFRhbmFtYWwNCj4gU3ViamVjdDogUmV2aXNlZDogUmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBwbS1t ZXRyaWMtcmVnaXN0cnktMTAgYW5kDQo+IGRyYWZ0LWlldGYtaXBwbS1pbml0aWFsLXJlZ2lzdHJ5 LTAyDQo+IA0KPiBSRVZJU0VEOg0KPiBJdCBsb29rcyBsaWtlIGluIG15IG1lc3NhZ2UgYmVsb3cg dGhhdCBJIGNvcGllZCBhbiBvbGQgdmVyc2lvbiBvZiB0aGUNCj4gcmV2aWV3Lg0KPiBJdCBkaWQg bm90IGluY2x1ZGUgdGhlIG90aGVyIHJlZ2lzdHJhdGlvbnMgaW4gdGhlIFBlcmZvcm1hbmNlIE1l dHJpY3MNCj4gUmVnaXN0cnkgZnJvbSBzZWN0aW9uIDguDQo+IEFkZGVkIHRoZW0gYmVsb3cuDQo+ IFRoYW5rcywNCj4gTWljaGVsbGUNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBNaWNoZWxsZSBDb3R0b24gPG1pY2hlbGxlLmNvdHRvbkBpYW5hLm9yZz4NCj4g RGF0ZTogVHVlc2RheSwgTWFyY2ggNywgMjAxNyBhdCAxMDowMCBBTQ0KPiBUbzogIk1PUlRPTiwg QUxGUkVEIEMgKEFMKSIgPGFjbW9ydG9uQGF0dC5jb20+DQo+IENjOiAiaXBwbUBpZXRmLm9yZyIg PGlwcG1AaWV0Zi5vcmc+LCBBbWFuZGEgQmFiZXINCj4gPGFtYW5kYS5iYWJlckBpYW5hLm9yZz4s IFNhYnJpbmEgVGFuYW1hbCA8c2FicmluYS50YW5hbWFsQGlhbmEub3JnPg0KPiBTdWJqZWN0OiBS ZXZpZXcgb2YgZHJhZnQtaWV0Zi1pcHBtLW1ldHJpYy1yZWdpc3RyeS0xMCBhbmQgZHJhZnQtaWV0 Zi0NCj4gaXBwbS1pbml0aWFsLXJlZ2lzdHJ5LTAyDQo+IA0KPiAgICAgQXR0bjogQWwgTW9ydG9u IGFuZCBJUFBNIFdvcmtpbmcgR3JvdXANCj4gDQo+ICAgICBBdCB0aGUgcmVxdWVzdCBvZiBBbCBN b3J0b24sIEkgaGF2ZSByZS1yZXZpZXdlZCB0aGUgSVBQTSBkb2N1bWVudHMNCj4gKGRyYWZ0LWll dGYtaXBwbS1tZXRyaWMtcmVnaXN0cnktMTAgYW5kIGRyYWZ0LWlldGYtaXBwbS1pbml0aWFsLQ0K PiByZWdpc3RyeS0wMikgd2l0aCBhIGZvY3VzIG9uIHRoZSByZWdpc3RyeSBhY3Rpb25zIHRoYXQg YXJlIGJlaW5nDQo+IHJlcXVlc3RlZCBieSBJQU5BIFNlcnZpY2VzIGFuZCBtYWtpbmcgc3VyZSB3 ZSB1bmRlcnN0YW5kIHdoYXQgaXMgYmVpbmcNCj4gcmVxdWVzdGVkLg0KPiANCj4gICAgIEFwb2xv Z2llcyBmb3IgdGhlIGxvbmcgbWVzc2FnZSBiZWxvdy4gIFRoZXJlIHdhcyBsb3RzIG9mIHJlZ2lz dHJ5DQo+IGFjdGlvbnMgdG8gd29yayB3aXRoLiAg4pi6DQo+IA0KPiAgICAgTk9URTogVGhlIHJl Z2lzdHJ5IG1vY2stdXBzIGJlbG93IGFuZCBpbml0aWFsIGVudHJpZXMgbWF5IG5vdA0KPiBwZXJm ZWN0bHkgbGluZS11cCBzbyBwbGVhc2UgaWdub3JlIHNwYWNpbmcuDQo+IA0KPiAgICAgV2UgdW5k ZXJzdGFuZCB0aGUgZHJhZnQtaWV0Zi1pcHBtLW1ldHJpYy1yZWdpc3RyeS0xMCBkb2N1bWVudCB0 bw0KPiByZXF1ZXN0IHRoZSBmb2xsb3dpbmc6DQo+IA0KPiAgICAgMSkgUmVnaXN0cmF0aW9uIG9m IGEgVVJJIHByZWZpeCBjYWxsZWQgdXJuOmlldGY6bWV0cmljczogaW4gdGhlDQo+IGZvbGxvd2lu ZyByZWdpc3RyeToNCj4gICAgIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcGFyYW1z L3BhcmFtcy54aHRtbCN1cm4tDQo+IHN1Ym5hbWVzcGFjZXMNCj4gDQo+ICAgICBUaGUgZW50cnks IOKAnG1ldHJpY3PigJ0gd2lsbCBsb29rIHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+IA0KPiAgICAg bWV0cmljcyAgICAgIFJGQy1pZXRmLWlwcG0tbWV0cmljLXJlZ2lzdHJ5ICAgICAgVEJEIChwb3Rl bnRpYWxseQ0KPiBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3BlcmYtbWV0cmljLXBh cmFtZXRlcnMpDQo+IA0KPiAgICAgMikgQSBuZXcgc2V0IG9mIHJlZ2lzdHJpZXMgd2lsbCBiZSBj cmVhdGVkIGF0IFRCRCAocG90ZW50aWFsbHkNCj4gICAgIGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNz aWdubWVudHMvcGVyZi1tZXRyaWMtcGFyYW1ldGVycykNCj4gDQo+IA0KPiAgICAgSUVURiBVUk4g U3ViLW5hbWVzcGFjZSBmb3IgTWV0cmljcyAodXJuOmlldGY6bWV0cmljcykNCj4gICAgIFJlZ2lz dHJhdGlvbiBQcm9jZWR1cmVzOiA/Pw0KPiAgICAgUmVmZXJlbmNlOiBSRkMtaWV0Zi1pcHBtLW1l dHJpYy1yZWdpc3RyeQ0KPiANCj4gICAgIFJlZ2lzdGVyZWQgTWV0cmljIElkZW50aWZpZXJzDQo+ IA0KPiAgICAgcGVyZiAgICAgIFJGQy1pZXRmLWlwcG0tbWV0cmljLXJlZ2lzdHJ5DQo+IA0KPiAN Cj4gICAgIEF0IGEgVVJMIFRCRCAocG90ZW50aWFsbHkgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9wZXJmLQ0KPiBtZXRyaWMtcGFyYW1ldGVycykNCj4gDQo+ICAgICBQZXJmb3JtYW5j ZSBNZXRyaWMgTmFtZSBFbGVtZW50cyAtIE1ldHJpYyBUeXBlcw0KPiAgICAgUmVnaXN0cmF0aW9u IFByb2NlZHVyZXM6ID8/DQo+ICAgICBSZWZlcmVuY2U6IFJGQy1pZXRmLWlwcG0tbWV0cmljLXJl Z2lzdHJ5DQo+IA0KPiAgICAgTWV0cmljVHlwZSAgIERlc2NyaXB0aW9uICAgICAgICAgICAgICAg ICAgICAgICAgICAJUmVmZXJlbmNlDQo+ICAgICDigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJQNCj4gICAgIFJURGVsYXkgICAgCVJvdW5kIFRyaXAgRGVs YXkNCj4gICAgIFJURE5TICAgICAJIFJlc3BvbnNlIFRpbWUgRG9tYWluIE5hbWUgU2VydmljZQ0K PiAgICAgT1dEZWxheSAgIAkgT25lIFdheSBEZWxheQ0KPiAgICAgUlRMb3NzICAgIAkgUm91bmQg VHJpcCBMb3NzDQo+ICAgICBPV0xvc3MgICAJICBPbmUgV2F5IExvc3MNCj4gICAgIE9XUERWICAg IAkgIE9uZSBXYXkgUGFja2V0IERlbGF5IFZhcmlhdGlvbg0KPiAgICAgT1dJUERWICAgCSAgT25l IFdheSBJbnRlci1QYWNrZXQgRGVsYXkgVmFyaWF0aW9uDQo+ICAgICBPV1Jlb3JkZXIgCSBPbmUg V2F5IFBhY2tldCBSZW9yZGVyaW5nDQo+ICAgICBPV0R1cGxpYyAgIAlPbmUgV2F5IFBhY2tldCBE dXBsaWNhdGlvbg0KPiAgICAgT1dCVEMgICAgIAkgT25lIFdheSBCdWxrIFRyYW5zcG9ydCBDYXBh Y2l0eQ0KPiAgICAgT1dNQk0gICAgIAkgT25lIFdheSBNb2RlbCBCYXNlZCBNZXRyaWMNCj4gICAg IFNQTW9uaXRvciAgCVNpbmdsZSBQb2ludCBNb25pdG9yDQo+ICAgICBNUE1vbml0b3IgCSBNdWx0 aS1Qb2ludCBNb25pdG9yDQo+IA0KPiANCj4gICAgIFBlcmZvcm1hbmNlIE1ldHJpYyBOYW1lIEVs ZW1lbnRzIC0gTWV0aG9kcw0KPiAgICAgUmVnaXN0cmF0aW9uIFByb2NlZHVyZXM6ID8/DQo+ICAg ICBSZWZlcmVuY2U6IFJGQy1pZXRmLWlwcG0tbWV0cmljLXJlZ2lzdHJ5DQo+IA0KPiAgICAgTWV0 aG9kcyAJCURlc2NyaXB0aW9uDQo+IAlSZWZlcmVuY2UNCj4gICAgIOKAlOKAlOKAlOKAlOKAlOKA lOKAlAkJ4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCUDQo+ICAgICBBY3RpdmUgCQlkZXBlbmRzIG9u IGEgZGVkaWNhdGVkIG1lYXN1cmVtZW50IHBhY2tldCBzdHJlYW0NCj4gYW5kIG9ic2VydmF0aW9u cyBvZiB0aGUgc3RyZWFtDQo+ICAgICBQYXNzaXZlIAkJZGVwZW5kcyAqc29sZWx5KiBvbiBvYnNl cnZhdGlvbiBvZiBvbmUgb3IgbW9yZQ0KPiBleGlzdGluZyBwYWNrZXQgc3RyZWFtcw0KPiAgICAg SHlicmlkVHlwZTEgIAlvYmVydmF0aW9ucyBvbiBvbmUgc3RyZWFtIHRoYXQgY29tYmluZSBib3Ro IGFjdGl2ZQ0KPiBhbmQgcGFzc2l2ZSBtZXRob2RzDQo+ICAgICBIeWJyaWRUeXBlMiAgCW9iZXJ2 YXRpb25zIG9uIHR3byBvciBtb3JlIHN0cmVhbXMgdGhhdCBjb21iaW5lDQo+IGJvdGggYWN0aXZl IGFuZCBwYXNzaXZlIG1ldGhvZHMNCj4gICAgIFNwYXRpYWwgICAgICAJU3BhdGlhbCBNZXRyaWMg b2YgUkZDNTY0NA0KPiANCj4gICAgIFBlcmZvcm1hbmNlIE1ldHJpYyBOYW1lIEVsZW1lbnRzIC0g U3ViVHlwZSBNZXRob2RzDQo+ICAgICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlczogPz8NCj4gICAg IFJlZmVyZW5jZTogUkZDLWlldGYtaXBwbS1tZXRyaWMtcmVnaXN0cnkNCj4gDQo+ICAgICBTdWJU eXBlIE1ldGhvZHMgCQlEZXNjcmlwdGlvbg0KPiAJUmVmZXJlbmNlDQo+ICAgICDigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJQJCeKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlA0KPiAgICAgSUNNUCAJCQlJbnRlcm5ldCBDb250cm9sIE1lc3NhZ2Ug UHJvdG9jb2wNCj4gICAgIElQIAkJCUludGVybmV0IFByb3RvY29sDQo+ICAgICBEU0NQeHggCQkJ d2hlcmUgeHggaXMgcmVwbGFjZWQgYnkgYSBEaWZmc2VydiBjb2RlIHBvaW50DQo+ICAgICBVRFAJ CQlVc2VyIERhdGFncmFtIFByb3RvY29sDQo+ICAgICBUQ1AgCQkJVHJhbnNwb3J0IENvbnRyb2wg UHJvdG9jb2wNCj4gICAgIFBvaXNzb24gCQkJUGFja2V0IGdlbmVyYXRpb24gdXNpbmcgUG9pc3Nv biBkaXN0cmlidXRpb24NCj4gICAgIFBlcmlvZGljIAkJUGVyaW9kaWMgcGFja2V0IGdlbmVyYXRp b24NCj4gICAgIFBheWxvYWR4eHh4QiAJCXdoZXJlIHh4eHggaXMgcmVwbGFjZWQgYnkgYW4gaW50 ZWdlciwgdGhlDQo+IG51bWJlciBvZiBvY3RldHMgaW4gdGhlIFBheWxvYWQNCj4gICAgIFN1c3Rh aW5lZEJ1cnN0IAkJQ2FwYWNpdHkgdGVzdCwgd29yc3QgY2FzZQ0KPiAgICAgU3RhbmRpbmdRdWV1 ZSAJCXRlc3Qgb2YgYm90dGxlbmVjayBxdWV1ZSBiZWhhdmlvcg0KPiAgICAgQEBAQCAgCQk8YWRk IG90aGVycyBmcm9tIE1CTSBkcmFmdD8+DQo+IA0KPiAgICAgUGVyZm9ybWFuY2UgTWV0cmljIE5h bWUgRWxlbWVudHMgLSBVbml0cw0KPiAgICAgUmVnaXN0cmF0aW9uIFByb2NlZHVyZXM6ID8/DQo+ ICAgICBSZWZlcmVuY2U6IFJGQy1pZXRmLWlwcG0tbWV0cmljLXJlZ2lzdHJ5DQo+IA0KPiAgICAg VW5pdHMgCQlEZXNjcmlwdGlvbg0KPiAJUmVmZXJlbmNlDQo+ICAgICDigJTigJTigJTigJTigJTi gJTigJTigJTigJQJ4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCUDQo+ICAgICBTZWNvbmRzDQo+ICAgICBSYXRpb1Bl cmNlbnQgCXZhbHVlIG11bHRpcGxpZWQgYnkgMTAwDQo+ICAgICBCUFMgICAgICAgICAgCUJpdHMg cGVyIFNlY29uZA0KPiAgICAgRXZlbnRUb3RhbCAgIAlmb3IgdW5pdC1sZXNzIGNvdW50cw0KPiAg ICAgTXVsdGlwbGUgICAgIAltb3JlIHRoYW4gb25lIHR5cGUgb2YgdW5pdA0KPiAgICAgRW51bWVy YXRlZCAgCSBhIGxpc3Qgb2Ygb3V0Y29tZXMNCj4gICAgIFVuaXQtbGVzcw0KPiANCj4gICAgIFBl cmZvcm1hbmNlIE1ldHJpYyBOYW1lIEVsZW1lbnRzIC0gT3V0cHV0DQo+ICAgICBSZWdpc3RyYXRp b24gUHJvY2VkdXJlczogPz8NCj4gICAgIFJlZmVyZW5jZTogUkZDLWlldGYtaXBwbS1tZXRyaWMt cmVnaXN0cnkNCj4gDQo+ICAgICBVbml0cyAJCURlc2NyaXB0aW9uDQo+IAlSZWZlcmVuY2UNCj4g ICAgIOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlAnigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJQNCj4gICAgIFNp bmdsZXRvbiAgICAJc29tZXRpbWVzIGNhbGxlZCByYXcgZGF0YQ0KPiAgICAgTWluaW11bQ0KPiAg ICAgTWF4aW11bQ0KPiAgICAgTWVkaWFuDQo+ICAgICBNZWFuDQo+ICAgICA5NVBlcmNlbnRpbGUg CTk1dGggUGVyY2VudGlsZQ0KPiAgICAgOTlQZXJjZW50aWxlIAk5OXRoIFBlcmNlbnRpbGUNCj4g ICAgIFN0ZERldiAJCVN0YW5kYXJkIERldmlhdGlvbg0KPiAgICAgVmFyaWFuY2UNCj4gICAgIFBG SSAJCVBhc3MsIEZhaWwsIEluY29uY2x1c2l2ZQ0KPiAgICAgRmxvd1JlY29yZHMgIAlkZXNjcmlw dGlvbnMgb2YgZmxvd3Mgb2JzZXJ2ZWQNCj4gDQo+IA0KPiAgICAgTk9URTogIEZvciBhbGwgdGhl IGFib3ZlIGVudHJpZXMsIHRoZSByZWZlcmVuY2Ugd2lsbCBiZSBSRkMtaWV0Zi0NCj4gaXBwbS1t ZXRyaWMtcmVnaXN0cnkuICBQbGVhc2UgY29uZmlybSB3aGF0IHRoZSByZWdpc3RyYXRpb24gcHJv Y2VkdXJlcw0KPiBzaG91bGQgYmUgZm9yIGFkZGluZyB0byBhbGwgdGhlIGFib3ZlIHJlZ2lzdHJp ZXMuDQo+IA0KPiAgICAgTk9URTogIFlvdSB3aWxsIG5vdGljZSB0aGF0IEkgYW0gc3VnZ2VzdGlu ZyBicmVha2luZyB1cCB0aGUgYWN0dWFsDQo+IGVsZW1lbnQgcmVnaXN0cmF0aW9uIGFuZCBkZXNj cmlwdGlvbiBpbiB0aGUgYWJvdmUgZWxlbWVudCByZWdpc3RyaWVzLiAgSQ0KPiB0aGluayBpdCBp cyBhIGNsZWFuZXIgYXBwcm9hY2ggZm9yIHRoZSByZWdpc3RyeSBmaWVsZHMsIGhvd2V2ZXIgaWYg eW91DQo+IGZlZWwgdGhhdCB0aGV5IHNob3VsZCBiZSBsaXN0ZWQgdG9nZXRoZXIgd2l0aCB0aGUg ZGVzY3JpcHRpb24gaW4NCj4gcGFyZW50aGVzaXMsIHBsZWFzZSBsZXQgdXMga25vdy4NCj4gDQo+ IA0KPiAgICAgMykgQ3JlYXRpb24gb2YgYSBuZXcgcmVnaXN0cnkgY2FsbGVkIFJlZ2lzdGVyZWQg UGVyZm9ybWFuY2UgTWV0cmljcywNCj4gcG9wdWxhdGVkIHdpdGggdGhlIGZvbGxvd2luZyBpbml0 aWFsIGFzc2lnbm1lbnRzDQo+IA0KPiAgICAgUmVnaXN0ZXJlZCBQZXJmb3JtYW5jZSBNZXRyaWNz DQo+ICAgICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlczogRXhwZXJ0IFJldmlldw0KPiANCj4gICAg IElkZW50aWZpZXIJTmFtZSAgVVJJcyAgRGVzY3JpcHRpb24gIFJlZmVyZW5jZSAgIENoYW5nZSBD b250cm9sbGVyDQo+IFZlcnNpb24NCj4gICAgIDAgICAgICBSZXNlcnZlZA0KPiAgICAgVEJEMSAg IFJURGVsYXlfQWN0aXZlX0lQLVVEUC0NCj4gUG9pc3Nvbl9SRkNYWFhYc2VjWV9TZWNvbmRzXzk1 cGVyY2VudGlsZSAgKGZyb20gc2VjdGlvbiA0KQ0KPiAgICAgVEJEMiAgIE9XUERWX0FjdGl2ZV9J UC1VRFAtUG9pc3Nvbl9SRkNYWFhYc2VjWV9TZWNvbmRzXzk1UGVyY2VudGlsZQ0KPiAoZnJvbSBz ZWN0aW9uIDUpDQo+ICAgICBUQkQzICAgUlRETlNfQWN0aXZlX0lQLVVEUC1Qb2lzc29uX1JGQ1hY WFhzZWNZX1NlY29uZHNfOTVQZXJjZW50aWxlDQo+IChmcm9tIHNlY3Rpb24gNikNCj4gICAgIFRC RDQgICBPV0RlbGF5X0FjdGl2ZV9JUC1VRFAtUG9pc3Nvbi0NCj4gUGF5bG9hZDI1MEJfUkZDWFhY WHNlY1lfU2Vjb25kc188c3RhdGlzdGljPiAoZnJvbSBzZWN0aW9uIDcpDQo+ICAgICBUQkQ1ICAg T1dEZWxheV9BY3RpdmVfSVAtVURQLVBvaXNzb24tDQo+IFBheWxvYWQyNTBCX1JGQ1hYWFhzZWNZ X1NlY29uZHNfOTVQZXJjZW50aWxlIChmcm9tIHNlY3Rpb24gNykNCj4gICAgIFRCRDYgICBPV0Rl bGF5X0FjdGl2ZV9JUC1VRFAtUG9pc3Nvbi0NCj4gUGF5bG9hZDI1MEJfUkZDWFhYWHNlY1lfU2Vj b25kc19NZWFuIChmcm9tIHNlY3Rpb24gNykNCj4gICAgIFRCRDcgICBPV0RlbGF5X0FjdGl2ZV9J UC1VRFAtUG9pc3Nvbi0NCj4gUGF5bG9hZDI1MEJfUkZDWFhYWHNlY1lfU2Vjb25kc19NaW4gKGZy b20gc2VjdGlvbiA3KQ0KPiAgICAgVEJEOCAgIE9XRGVsYXlfQWN0aXZlX0lQLVVEUC1Qb2lzc29u LQ0KPiBQYXlsb2FkMjUwQl9SRkNYWFhYc2VjWV9TZWNvbmRzX01heCAoZnJvbSBzZWN0aW9uIDcp DQo+ICAgICBUQkQ5ICAgT1dEZWxheV9BY3RpdmVfSVAtVURQLVBvaXNzb24tDQo+IFBheWxvYWQy NTBCX1JGQ1hYWFhzZWNZX1NlY29uZHNfU3RkRGV2IChmcm9tIHNlY3Rpb24gNykNCj4gICAgIFRC RDEwIE9XRGVsYXlfQWN0aXZlX0lQLVVEUC1QZXJpb2RpYy0NCj4gUGF5bG9hZDE0MkJfUkZDWFhY WHNlY1lfU2Vjb25kc188c3RhdGlzdGljPiAoZnJvbSBzZWN0aW9uIDgpDQo+ICAgICBUQkQxMSBP V0RlbGF5X0FjdGl2ZV9JUC1VRFAtUGVyaW9kaWMtDQo+IFBheWxvYWQxNDJCX1JGQ1hYWFhzZWNZ X1NlY29uZHNfOTVQZXJjZW50aWxlIChmcm9tIHNlY3Rpb24gOCkNCj4gICAgIFRCRDEyIE9XRGVs YXlfQWN0aXZlX0lQLVVEUC1QZXJpb2RpYy0NCj4gUGF5bG9hZDE0MkJfUkZDWFhYWHNlY1lfU2Vj b25kc19NZWFuIChmcm9tIHNlY3Rpb24gOCkNCj4gICAgIFRCRDEzIE9XRGVsYXlfQWN0aXZlX0lQ LVVEUC1QZXJpb2RpYy0NCj4gUGF5bG9hZDE0MkJfUkZDWFhYWHNlY1lfU2Vjb25kc19NaW4gKGZy b20gc2VjdGlvbiA4KQ0KPiAgICAgVEJEMTQgIE9XRGVsYXlfQWN0aXZlX0lQLVVEUC1QZXJpb2Rp Yy0NCj4gUGF5bG9hZDE0MkJfUkZDWFhYWHNlY1lfU2Vjb25kc19NYXggKGZyb20gc2VjdGlvbiA4 KQ0KPiAgICAgVEJEMTUgIE9XRGVsYXlfQWN0aXZlX0lQLVVEUC1QZXJpb2RpYy0NCj4gUGF5bG9h ZDE0MkJfUkZDWFhYWHNlY1lfU2Vjb25kc19TdGREZXYgKGZyb20gc2VjdGlvbiA4KQ0KPiAgICAg MTYtNjQ1MTEgVW5hc3NpZ25lZA0KPiAgICAgNjQ1MTIgdG8gNjU1MzYgUmVzZXJ2ZWQgZm9yIHBy aXZhdGUgdXNlDQo+IA0KPiAgICAgTk9URTogIEZvciB0aGUgYWJvdmUgcmVnaXN0cmF0aW9ucywg dGhlIHN1bW1hcnkgaW5mb3JtYXRpb24gaW4gdGhlDQo+IHRhYmxlIHdpbGwgYmUgY29tcGxldGVk IHVzaW5nIHRoZSBpbmZvcm1hdGlvbiBmcm9tIGRyYWZ0LWlldGYtaXBwbS0NCj4gaW5pdGlhbC1y ZWdpc3RyeS4gIFRoZSBVUkkgY29sdW1uIHdpbGwgbGluayB0byBhIHRlbXBsYXRlIHdoZXJlIHRo ZQ0KPiBjb21wbGV0ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgcmVnaXN0cmF0aW9uIGNhbiBiZSBm b3VuZCAoY29waWVkDQo+IGRpcmVjdGx5IGZyb20gaWV0Zi1pcHBtLWluaXRpYWwtcmVnaXN0cnkp Lg0KPiANCj4gICAgIE5PVEU6ICBJIHN1Z2dlc3QgcmUtYXJyYW5naW5nIHNvbWUgb2YgdGhlIHJl cXVlc3RzIGZvciByZWdpc3RyeQ0KPiBjcmVhdGlvbiBzbyB0aGF0IHRoZXkgZmxvdyBpbiBvcmRl ciBhIGJpdCBiZXR0ZXIuICBTb21lIHdvcmRpbmcgY2hhbmdlcw0KPiBtYXkgYmUgbmVlZGVkIHRv IGZ1cnRoZXIgY2xhcmlmeSBhbmQgcmVmbGVjdCB3aGF0IGFjdGlvbnMgYXJlIGJlaW5nDQo+IHJl cXVlc3RlZCBpZiB3aGF0IHdlIG91dGxpbmVkIGFib3ZlIGlzIGluZGVlZCBjb3JyZWN0LiAgSWYg SSBtaXNzZWQNCj4gYW55dGhpbmcsIHBsZWFzZSBkbyBub3QgaGVzaXRhdGUgdG8gbGV0IG1lIGtu b3cuICBJZiBhbnl0aGluZyBpbiBteQ0KPiByZXZpZXcgYWJvdmUgaXMgbm90IGNsZWFyIHBsZWFz ZSBsZXQgbWUga25vdy4NCj4gDQo+ICAgICBXZSBhcmUgaGFwcHkgdG8gcmV2aWV3IG5ldyB2ZXJz aW9ucyBvZiB0aGUgZG9jdW1lbnQuDQo+ICAgICBXZSB3aWxsIGFsc28gYmUgaW4gQ2hpY2FnbyBp ZiBtZWV0aW5nIGluIHBlcnNvbiBpcyBlYXNpZXIgOikNCj4gDQo+IA0KPiAgICAgQmVzdCByZWdh cmRzLA0KPiANCj4gICAgIE1pY2hlbGxlIENvdHRvbg0KPiAgICAgUHJvdG9jb2wgUGFyYW1ldGVy cyBFbmdhZ2VtZW50IE1hbmFnZXINCj4gICAgIElBTkEgU2VydmljZXMNCj4gDQo+IA0K From nobody Fri Mar 10 09:14:20 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9481295FD; Fri, 10 Mar 2017 09:14:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148916605590.6778.14181761811890656682@ietfa.amsl.com> Date: Fri, 10 Mar 2017 09:14:15 -0800 Archived-At: Cc: draft-ietf-ippm-twamp-time-format.all@ietf.org, ietf@ietf.org, ippm@ietf.org Subject: [ippm] Review of draft-ietf-ippm-twamp-time-format-04 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:14:16 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ippm-twamp-time-format-?? Reviewer: Joel Halpern Review Date: 2017-03-10 IETF LC End Date: 2017-03-15 IESG Telechat date: Not scheduled for a telechat Summary: This revision fully resolves my concerns from -03 Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Fri Mar 10 09:21:15 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB190129987; Fri, 10 Mar 2017 09:21:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148916646874.6947.16981966559308893384@ietfa.amsl.com> Date: Fri, 10 Mar 2017 09:21:08 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-initial-registry-03.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:21: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 of the IETF. Title : Initial Performance Metric Registry Entries Authors : Al Morton Marcelo Bagnulo Philip Eardley Kevin D'Souza Filename : draft-ietf-ippm-initial-registry-03.txt Pages : 67 Date : 2017-03-09 Abstract: This memo defines the Initial Entries for the Performance Metrics Registry. This version includes: * All section 4, 5, 6, 7, and 8 parameters reference YANG types for alternate data formats. * implementation of standard naming format for parameters. * implementation of many IANA early-review comments. Still need: Add MBM metric entry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-initial-registry/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-initial-registry-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-initial-registry-03 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 Mar 10 09:34:46 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0043812706D; Fri, 10 Mar 2017 09:34:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148916728596.6787.2628832757292136302@ietfa.amsl.com> Date: Fri, 10 Mar 2017 09:34:45 -0800 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-metric-registry-11.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 17:34:46 -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 of the IETF. Title : Registry for Performance Metrics Authors : Marcelo Bagnulo Benoit Claise Philip Eardley Al Morton Aamer Akhter Filename : draft-ietf-ippm-metric-registry-11.txt Pages : 33 Date : 2017-03-09 Abstract: This document defines the format for the Performance Metrics registry and defines the IANA Registry for Performance Metrics. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-metric-registry/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-metric-registry-11 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 Sun Mar 12 12:29:27 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E35BB12950A; Sun, 12 Mar 2017 12:29:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148934696190.24730.5180737106045731520@ietfa.amsl.com> Date: Sun, 12 Mar 2017 12:29:21 -0700 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-twamp-time-format-05.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:29:22 -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 of the IETF. Title : Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP) Authors : Greg Mirsky Israel Meilik Filename : draft-ietf-ippm-twamp-time-format-05.txt Pages : 8 Date : 2017-03-12 Abstract: This document describes an OPTIONAL feature for active performance measurement protocols allowing use of the Precision Time Protocol time stamp format defined in IEEE-1588v2-2008, as an alternative to the Network Time Protocol that is currently used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-time-format/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-twamp-time-format-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-twamp-time-format-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 04:48:30 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74084129580; Mon, 13 Mar 2017 04:48:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148940570944.16983.2239124108774522549@ietfa.amsl.com> Date: Mon, 13 Mar 2017 04:48:29 -0700 Archived-At: Cc: ippm@ietf.org Subject: [ippm] I-D Action: draft-ietf-ippm-6man-pdm-option-09.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 11:48:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics of the IETF. Title : IPv6 Performance and Diagnostic Metrics (PDM) Destination Option Authors : Nalini Elkins Robert M. Hamilton Michael S. Ackermann Filename : draft-ietf-ippm-6man-pdm-option-09.txt Pages : 31 Date : 2017-03-13 Abstract: To assess performance problems, measurements based on optional sequence numbers and timing may be embedded in each packet. Such measurements may be interpreted in real-time or after the fact. An implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header as well as the field limits, calculations, and usage of the PDM in measurement are included in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-6man-pdm-option-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 Mon Mar 13 07:14:37 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BBA129678; Mon, 13 Mar 2017 07:14:31 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 G3InRIY0U9I2; Mon, 13 Mar 2017 07:14:29 -0700 (PDT) Received: from TELEDG001RM001.telecomitalia.it (teledg001rm001.telecomitalia.it [217.169.121.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C623B12967D; Mon, 13 Mar 2017 07:14:25 -0700 (PDT) Received: from TELMBXB02RM001.telecomitalia.local (10.14.252.27) by TELEDG001RM001.telecomitalia.it (10.19.3.111) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 15:14:22 +0100 Received: from TELMBXB02RM001.telecomitalia.local (10.14.252.27) by TELMBXB02RM001.telecomitalia.local (10.14.252.27) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Mar 2017 15:14:22 +0100 Received: from TELMBXB02RM001.telecomitalia.local ([fe80::2845:411e:c732:e844]) by TELMBXB02RM001.telecomitalia.local ([fe80::2845:411e:c732:e844%20]) with mapi id 15.00.1263.000; Mon, 13 Mar 2017 15:14:22 +0100 From: Fioccola Giuseppe To: "ippm@ietf.org" Thread-Topic: New Version Notification for draft-fioccola-ippm-alt-mark-active-01.txt Thread-Index: AQHSnAEzkuy+W4Z2WkW1pO8qG8jPMqGSyuCw Date: Mon, 13 Mar 2017 14:14:22 +0000 Message-ID: References: <148941320753.16983.16633773882894026038.idtracker@ietfa.amsl.com> In-Reply-To: <148941320753.16983.16633773882894026038.idtracker@ietfa.amsl.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.245] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-fioccola-ippm-alt-mark-active@ietf.org" Subject: [ippm] I: New Version Notification for draft-fioccola-ippm-alt-mark-active-01.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 14:14:32 -0000 SGkgQWxsLA0KVGhpcyBpcyB0aGUgbmV3IHZlcnNpb24gb2YgdGhlIHJldmlzZWQgZHJhZnQgb24g QWN0aXZlIEFsdGVybmF0ZSBNYXJraW5nLiBJIGhhdmUgYWRkZWQgYSBzaG9ydCBzZWN0aW9uIGFi b3V0IFJGQzYzNzQgVXNlIENhc2UuDQpkcmFmdC1maW9jY29sYS1pcHBtLWFsdC1tYXJrLWFjdGl2 ZSB3YXMgcHJlc2VudGVkIGR1cmluZyBJRVRGOTYgbWVldGluZyBhbmQgd2UgZ290IHNvbWUgY29t bWVudHMgb24gbWFpbGluZyBsaXN0cyBhdCB0aGF0IHRpbWUuDQpJIGhhdmUgcmVmcmVzaGVkIGl0 LCBzZWVuIHRoYXQgd2UgaGF2ZSB0aGUgUkZDNjM3NCBVc2UgQ2FzZSAoc2VlIGRyYWZ0LWJyeWFu dC1tcGxzLXJmYzYzNzQtc2ZsKSBhbmQgd2Ugd2lsbCBhbHNvIHdvcmsgb24gVFdBTVAvT1dBTVAg ZXh0ZW5zaW9uLg0KTXkgaWRlYSBpcyB0byBzdHJvbmdseSB3b3JrIG9uIGl0IG9uY2UgUGFzc2l2 ZSBBbHRlcm5hdGUgTWFya2luZyBkb2N1bWVudCAoZHJhZnQtaWV0Zi1pcHBtLWFsdC1tYXJrKSBo YXMgbW92ZWQgdG8gdGhlIExhc3QgQ2FsbCBwaGFzZS4NCg0KUmV2aWV3cyBhbmQgQ29tbWVudHMg YXJlIHdlbGNvbWUNCg0KVGhhbmtzLA0KDQpHaXVzZXBwZQ0KDQotLS0tLU1lc3NhZ2dpbyBvcmln aW5hbGUtLS0tLQ0KRGE6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10NCkludmlhdG86IGx1bmVkw6wgMTMgbWFyem8gMjAxNyAxNDo1Mw0K QTogTW91bGkgQ2hhbmRyYW1vdWxpOyBGaW9jY29sYSBHaXVzZXBwZTsgQ2FwZWxsbyBBbGVzc2Fu ZHJvOyBTdGV3YXJ0IEJyeWFudDsgQ29jaWdsaW8gTWF1cm87IEFsZXhhbmRlciBDbGVtbQ0KT2dn ZXR0bzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1maW9jY29sYS1pcHBtLWFs dC1tYXJrLWFjdGl2ZS0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZmlv Y2NvbGEtaXBwbS1hbHQtbWFyay1hY3RpdmUtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IEdpdXNlcHBlIEZpb2Njb2xhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWZpb2Njb2xhLWlwcG0tYWx0LW1hcmst YWN0aXZlDQpSZXZpc2lvbjogICAgICAgMDENClRpdGxlOiAgICAgICAgICBBbHRlcm5hdGUgTWFy a2luZyBFeHRlbnNpb24gdG8gQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sDQpEb2N1bWVudCBk YXRlOiAgMjAxNy0wMy0xMw0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K UGFnZXM6ICAgICAgICAgIDEzDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZpb2Njb2xhLWlwcG0tYWx0LW1hcmstYWN0aXZlLTAxLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWZpb2Njb2xhLWlwcG0tYWx0LW1hcmstYWN0aXZlLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1maW9jY29sYS1pcHBtLWFsdC1tYXJrLWFjdGl2ZS0w MQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1maW9jY29sYS1pcHBtLWFsdC1tYXJrLWFjdGl2ZS0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byBleHRlbmQgdGhlIGV4aXN0aW5nIEFjdGl2ZSBNZWFz dXJlbWVudA0KICAgUHJvdG9jb2wsIGluIG9yZGVyIHRvIGltcGxlbWVudCBhbHRlcm5hdGUgbWFy a2luZyBtZXRob2RvbG9neQ0KICAgZGV0YWlsZWQgaW4gW0ktRC5pZXRmLWlwcG0tYWx0LW1hcmtd LiAgVGhlIGV4dGVuc2lvbiBmb3IgVHdvLVdheQ0KICAgQWN0aXZlIE1lYXN1cmVtZW50IFByb3Rv Y29sIChUV0FNUCkgUkZDIDUzNTcgW1JGQzUzNTddIGFuZCBPbmUtd2F5DQogICBBY3RpdmUgTWVh c3VyZW1lbnQgUHJvdG9jb2wgKE9XQU1QKSBSRkMgNDY1NiBbUkZDNDY1Nl0gd2lsbCBiZQ0KICAg Y29uc2lkZXJlZC4gIFJGQzYzNzQgW1JGQzYzNzRdIFVzZSBDYXNlIGlzIGFsc28gcmVwb3J0ZWQu ICBUaGlzDQogICBwcm9wb3NhbCBkZWZpbmVzIGEgc2ltcGxpZmllZCBtZWNoYW5pc20gd2l0aCBi ZW5lZml0cyB0byB0aGUgbWV0cmljDQogICBwcmVjaXNpb24gYW5kIGNvbXB1dGF0aW9uYWwgbG9h ZC4gIEh5YnJpZCBtZWFzdXJlbWVudHMgYXJlIGFsc28NCiAgIGVuYWJsZWQuDQoNCg0KDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQoNClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBl c2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlh IG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBx dWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFi YmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2Vt ZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRl IGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLg0KDQpUaGlzIGUt bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4g cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5 LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNl IGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNl IHRoZSBzZW5kZXIgYnkgcmV0dXJuIGUtbWFpbCwgVGhhbmtzLg0KDQo= From nobody Mon Mar 13 10:58:49 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2433F12996B; Mon, 13 Mar 2017 10:58:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942792412.9303.3309993074767595636@ietfa.amsl.com> Date: Mon, 13 Mar 2017 10:58:44 -0700 Archived-At: Cc: draft-ietf-ippm-model-based-metrics.all@ietf.org, ietf@ietf.org, ippm@ietf.org Subject: [ippm] Review of draft-ietf-ippm-model-based-metrics-10 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:58:44 -0000 Reviewer: Robert Sparks Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ippm-model-based-metrics-10 Reviewer: Robert Sparks Review Date: 2017-03-13 IETF LC End Date: 2017-03-14 IESG Telechat date: Not scheduled for a telechat Status: Almost ready, but has significant issues to address before publication as an Informational RFC I'm guessing the goal for this document changed substantially during its development. The point and tone if the document changes depending on where you are in it. I found it very difficult to read (and I did see the shepherd's report call out that the document has already had a strong editorial pass). It really feels to me that the purpose this document is trying to serve could be better achieved with two much shorter documents. Please consider pulling out the most important observations into its own informational document, and an experimental document that succinctly presents the tests, the framework, and the feedback you want from people wo try these things. Major issues: There are issues with the equations in section 7.2. Please look at the line containing "Xa < defect_count(n) < Xb". Where is Xb defined? Was it supposed to be Xr from further up the page? (or perhaps that Xr should have been Xb? The document starts using 2119 MUSTs in section 7.3. None of the uses are appropriate 2119 keywords - they aren't talking about protocol. Please rewrite the prose without using the 2119 keywords. Section 8.2.4 seems to be missing an actual description/definition of the test it is trying to talk about. Minor issues: The abstract says this document does not define tests. The rest of the document says it does. (See phrases like "The tests described in this note") Where the document claims it is neccessary to "suppress the effects of TCP congestion control", it should say "avoid the effects". The mechanism of using precalculated traffic patterns discussed in the document avoids, but does not suppress. At the end of section 1, you call out "multiple standardized versions of TCP". Please clarify what you're trying to point to? In the definition of "traffic patterns", you note that the goal is to "mimic the range of common patterns". Consider qualifying that to "current common patterns", and add some discussion later in the document when you talk about pregenerating traffic patterns to point out that these change over time. At the next to last paragraph of section 4.1, you say "metrics have entirely thwarted the analytic framework". I don't think that's what you mean. I suspect you mean to say attempts to create metrics have been unsuccessful (I suggest you avoid the word "thwarted"). At the 3rd paragraph on page 19, you say "There is no model". Do you mean no model exists in the world for this, or only that this document does not provide a model. I strongly object to the attempt to use "infinitesimal" to describe the conditions on the test network you are trying to convey. At the very least, you are dealing with a finite (if arbitrarily large) set of states that network can be in, not a continuum. You should be looking to raid terms from discrete mathematics instead, but I don't think even that's the right thing to do. Please replace the infinitesimal concept here with it's definition (which you have to call out anyway). Just _say_ "has the tightest available constraints that allow the tests to pass." Consider providing some rational for the numbers you came up with in the strawman in the second paragraph on page 33. 1mS seems pretty arbitrary otherwise. I'm not asking for you to _defend_ the choice as the right number - just talk about why you picked it instead of something else. Nits: - Consider pointing to the models you are actually using in the first sentence of the first paragraph on page 9 - The third paragraph of the abstract is particularly hard to read. Please consider breaking the compound sentences into simpler ones. - You use "engineering test" before you say what you mean by that (see sections 8.2.4 and 8.3.2 for examples) - There are several places where you talk about tests being inconclusive because the precomputed traffic was not accurately generated. Are you trying to say "if you have an inconclusive test and can't otherwise figure out why, look closely at your precomputed traffic", or "Double-check your precomputed traffic before you run your test or risk garbage-in/garbage out"? From nobody Mon Mar 13 18:19:54 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6B9129979; Mon, 13 Mar 2017 18:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 m11femwU47Vw; Mon, 13 Mar 2017 18:19:52 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345F612978B; Mon, 13 Mar 2017 18:19:52 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id 2so85793634oif.0; Mon, 13 Mar 2017 18:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oDUKd1fNcsDF8ADAU2Jxqdsx4hjZmM77L4197kSWtm0=; b=kCHUsCG01qb4xpArzdhYebwljBpypTJvDMW77Mya3ubH4++j16pqUNaQXs4+8+Y59X vROvbfQQ6LD27MJrl/Y17dM3FliJ5S57ciBMCoreFyt1dl1BIlAsW9s2zxPpnSaxPSuj nhpn0bgncCe0kU5HxLRHuF+KgBlUn5NIqLNVaqqZ1LmrYH3m+/Sn4S7Q4wGUopF1adhq lpW8HRCLjRhSCiL7khlAi4YnrEl6fI0r6upYmSrGvLpIpy484WV1FGbAQzWlZQSRcep0 MaHxvjWNhSqetjjkebYU89Mse+cy0uTFK4SiLDSXf8HIHVj3GiFRM6d1tcvULlh0mW0H 6h8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oDUKd1fNcsDF8ADAU2Jxqdsx4hjZmM77L4197kSWtm0=; b=gIE6IVF6R5GaLmGvcspsEje+aruW25Y/ciGY5DMytIL3nwQSsVR9AO+Gq1NKeKkIZw GseXnSvCyzRuzyb0ohtHNT6BOgkt8bpqjGJclO/N8Ft6THFJVwqIXIe+tqa52uqFf4qR kpn83kr3u0/6s4NyccRAst8+1FPi3og0PbmhmCSTSSqpF/98mNT4IPIGyLzWV9RE4ypd EP23N7yiEAAGL7v9/N2stEiqCGsQgcSOt20rMK0w5kLGIke5ywcJ78a6lHfAf9FzlI9e JRfoZ4dvsyYmijGYWCwrQ2qJYRbjm4eW0Q7Pg66PVfPVdjpV+0VK24vfZ2bxvgvTGmdO JL0Q== X-Gm-Message-State: AMke39meJEzwtFX3OWwmQtDWn9vCrV7srrbMeJsXi2+YKqSAEFMlfmrbhJdW6DK5W+Gywj0vn2lTmlqfTQKqhw== X-Received: by 10.202.181.135 with SMTP id e129mr19406167oif.124.1489454391448; Mon, 13 Mar 2017 18:19:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Mon, 13 Mar 2017 18:19:51 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Mon, 13 Mar 2017 18:19:51 -0700 Message-ID: To: IPPM Chairs Content-Type: multipart/alternative; boundary=001a113cbe4ce95a66054aa69f49 Archived-At: Cc: IETF IPPM WG Subject: Re: [ippm] IETF98 IPPM meeting call for agenda items X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 01:19:53 -0000 --001a113cbe4ce95a66054aa69f49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bill and Brian, we've had updates to draft-mirsky-ippm-twamp-light-yang and appreciate opportunity to present them to the IPPM WG. Hence the request for the presentation slo in Chicagot: draft-mirsky-ippm-twamp-light-yang Greg Mirsky 15 min Regards, Greg On Thu, Feb 16, 2017 at 8:04 PM, Bill Cerveny wrote: > Dear IPPMers, > > I am working on the agenda for the upcoming IPPM meeting at IETF98 in > Chicago and need to have presenters and presentations confirmed and > identified. > > Unless I=E2=80=99m wrong, we have 4 IPPM WG documents to discuss: > > draft-ietf-ippm-alt-mark-03 > draft-ietf-ippm-initial-registry-02 > draft-ietf-ippm-metric-registry-10 > draft-ietf-ippm-twamp-yang-02 > > We will talk about draft-brockners-inband-oam-data-02 ( > https://tools.ietf.org/html/draft-brockners-inband-oam-data-02) > > From my review of the mailing group list, it would appear that other than > draft-brockners-inband-oam-data, the only other individual draft > discussed was draft-bhaprasud-ippm-pm-01. This being the case, other > presenters who wish to present their individual drafts for IPPM > consideration will be able to do so during =E2=80=9Clightning talks=E2=80= =9D, which will be > five minutes per topic (strict), with available time at the end of the ma= in > agenda. > > Authors: Please respond to this e-mail with the amount of time that you > are requesting and who will be presenting. > > Thanks, > > Bill Cerveny > IPPM WG co-chair > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --001a113cbe4ce95a66054aa69f49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Bill and Brian,
we've had updates to=C2=A0draft= -mirsky-ippm-twamp-light-yang and appreciate opportunity to present them to= the IPPM WG.
Hence the request for the presentation slo in Chica= got:
<= div>draft-mirsky-ippm-twamp-light-yang =C2=A0 Greg Mirsky =C2=A0 15 min

Regards,
Greg

On Thu, Feb 16, 2017 at 8:04 PM, = Bill Cerveny <ippm@wjcerveny.com> wrote:
Dear IPPMers,

<= /div>
I am working on the agenda for the upcoming IPPM meeting at IETF9= 8 in Chicago and need to have presenters and presentations confirmed and id= entified.

Unless I=E2=80=99m wrong, we have 4 IPPM= WG documents to discuss:

draft-ietf-ippm-alt-mark-03
draft-ietf-ippm-initial-registry-02=C2=A0
draft-ietf-ippm= -metric-registry-10=C2=A0
draft-ietf-ippm-twamp-yang-02=C2= =A0

We will talk about draft-brockners-inband-oam-= data-02 (https://tools.ietf.org/html/draft-broc= kners-inband-oam-data-02)

From my review = of the mailing group list, it would appear that other than draft-brockners-= inband-oam-data, the only other individual draft discussed was draft-b= haprasud-ippm-pm-01. This being the case, other presenters who wish to pres= ent their individual drafts for IPPM consideration will be able to do so du= ring =E2=80=9Clightning talks=E2=80=9D, which will be five minutes per topi= c (strict), with available time at the end of the main agenda.
Authors: Please respond to this e-mail with the amount of time= that you are requesting and who will be presenting.

Thanks,

Bill Cerveny
IPPM WG co-chair=

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


--001a113cbe4ce95a66054aa69f49-- From nobody Fri Mar 17 12:01:02 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D6C1294E6; Fri, 17 Mar 2017 12:01:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jon Mitchell To: Cc: draft-ietf-ippm-twamp-time-format.all@ietf.org, ietf@ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148977726052.13049.17633302885192133866@ietfa.amsl.com> Date: Fri, 17 Mar 2017 12:01:00 -0700 Archived-At: Subject: [ippm] Review of draft-ietf-ippm-twamp-time-format-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2017 19:01:01 -0000 Reviewer: Jon Mitchell Review result: Has Nits 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 with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Ready with Nits - this draft adds the ability to use PTP timestamps as an alternative to NTP timestamps for active performance measurement protocols OWAMP and TWAMP. Although this draft does a good job of discussing interoperability for both sides of the session having or not having support for this operational capability, in several places it states that if a send/receiver support this capability it must be set to 1 in the flags. However, only for TWAMP Light mode, this seems configurable. This may just be my interpretation, but it probably should state that local implementations MAY provide a configurable knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2 even if the capability is supported by the implementation. From nobody Sun Mar 19 08:13:25 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FD31294D0 for ; Sun, 19 Mar 2017 08:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.695 X-Spam-Level: X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 qvjKsHmsqFdA for ; Sun, 19 Mar 2017 08:13:21 -0700 (PDT) Received: from nm5-vm4.bullet.mail.gq1.yahoo.com (nm5-vm4.bullet.mail.gq1.yahoo.com [98.136.218.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65441294CF for ; Sun, 19 Mar 2017 08:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1489936400; bh=pHL1CL3bMD/aJpyVEjSeQAEmZKY9/frecLkIjuuoNbA=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=rhmZFHTEZVA29kWAzmhinlBZGn6O+2FPd5QjBTCQVJVvnVtGJuPP12yrqoppjDqKXDY9JYT96EbYdrD74qf0y9Tub0H6nhTawPBIT+qvVY79BTKc5aYnjH7Gm5p34p82+bgBO9T8rj3RqpGHyTPulkfhExTdMz9e5tH742nLiYHMaFHh8cXLGpP8r+0GjUVIMgCGVFShmJjwA4mclT2XsPHxNXzpfyqLaeeejBlI3HPtMrm4U3cSEv6sgnQuGbJJlFHSNVdzKrFLUgXcQ3f2vn8BNQQL0iUNlwHDnlKKdivyUBmEetd+MaXe6uGmPooDORg6NfxWoP6HDACXl7dhfg== Received: from [98.137.12.61] by nm5.bullet.mail.gq1.yahoo.com with NNFMP; 19 Mar 2017 15:13:20 -0000 Received: from [98.137.12.205] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 19 Mar 2017 15:13:20 -0000 Received: from [127.0.0.1] by omp1013.mail.gq1.yahoo.com with NNFMP; 19 Mar 2017 15:13:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 328600.54371.bm@omp1013.mail.gq1.yahoo.com X-YMail-OSG: pnTJmhsVM1nFygSrzLYk.o6w0Wod3z4Y6zAOjdEkHnlE90f8l4bAXSxnWYLVgy8 XMqoTrpp3cTkNfgEHdxWTIL8t.PHfTzW9qBq6GW1PPlx6veoqpP1dse_yA_RJbN9KS7St3OZp1lA ksX1jqB4t9CUPkWIpnoTLUibATTYsFxtqRT4L9I8c1mHUImYYg0AcrYsfQbMpvyWZCdWRRGKEd_X 10sjlNWdbjzF8Qrf3l3oyfWhqrS3m9.X0OHriFfmYrIE.6hJ1nkLeul35rsHD9z0sFbWL_rQWKBS QzMOjnKlKf3gbAda9uLDdamE5LRNVlfQx4QAx09wj.dEbQYDSBAxD8hBDnEgmNJN6K.oiAm7QYS0 03GLql50iwhGSiWGqj8Dk80Ii3XkbkSkq_2V_Xt7FuE1YjXljHa.MgL2iDIbZyT3ah8_EeCN.1oy 4qKAT58zSoRuYftJxhfIZJ7UAkCjYggxFiEpJq6CNymeWr5MzZXsGN_jNT4nJdGybKCoXPsmqB99 R1PleH5LGVftI1BHlr9.2eWodJC..b33vxJ30l8FQOmJwRYjzhz9l.XBAKTgUic99L5bm5ISSodp .Onh0.U5WL7rT4BqdylKLUSs- Received: from jws300001b.mail.gq1.yahoo.com by sendmailws142.mail.gq1.yahoo.com; Sun, 19 Mar 2017 15:13:19 +0000; 1489936399.946 Date: Sun, 19 Mar 2017 15:13:19 +0000 (UTC) From: Reply-To: To: IPPM IETF Message-ID: <2011967308.571957.1489936399775@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_571956_307196473.1489936399775" References: <2011967308.571957.1489936399775.ref@mail.yahoo.com> Archived-At: Subject: Re: [ippm] draft-nieminen-ippm-nn-measurements-00 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 15:13:24 -0000 ------=_Part_571956_307196473.1489936399775 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit IPPM, Draft-nieminen-ippm-nn-measurements-00 "Net Neutrality Measurements: Regulatory Use Case and Problem Statement" outlines the requirements and use case for measuring Net Neutrality. We have attached a draft showing how using PDM (https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/) can be used to monitor Net Neutrality and how it meets the requirements outlined in the draft above. Since we are in the blackout period for draft submission, I am attaching the draft to this email. We will submit it officially once the submission process opens again. We look forward to an informal, offline discussion of this draft in Chicago with any interested parties. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 ------=_Part_571956_307196473.1489936399775 Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-elkins-ippm-pdm-nn-00.txt" Content-ID: IA0KDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTi4gRWxraW5zDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCLiBKb3VyaXMNCkludGVuZGVkIFN0YXR1 czogSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgIEluc2lkZSBQcm9kdWN0 cw0KRXhwaXJlczogU2VwdGVtYmVyIDIwLCAyMDE3ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE1hcmNoIDE5LCAyMDE3DQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgIFVzaW5nIFBETSB0 byBNb25pdG9yIE5ldCBOZXV0cmFsaXR5DQogICAgICAgICAgICAgICAgICAgICAgZHJhZnQtZWxr aW5zLWlwcG0tcGRtLW5uLTAwDQoNCkFic3RyYWN0DQoNCiAgIE1vbml0b3Jpbmcgb2YgbmV0IG5l dXRyYWxpdHkgaXMgb2YgaW50ZXJlc3QgdG8gcmVndWxhdG9ycyBhcyB3ZWxsIGFzDQogICB1c2Vy cyB0aHJvdWdob3V0IHRoZSB3b3JsZC4gIFN0YW5kYXJkaXplZCBtZXRyaWNzIGFyZSBsYWNraW5n Lg0KICAgTWVhc3VyZW1lbnRzIG5lZWQgdG8gYmUgYXQgdGhlIGVuZCB1c2VyIGNsaWVudCwgYmUg YWJsZSB0byBhY2N1cmF0ZWx5DQogICBzZXBhcmF0ZSB3aXJlIGFuZCBob3N0IHRpbWUsIGRldGVj dCBxdWFsaXR5IG9mIHNlcnZpY2UgcHJvdmlkZWQgdG8NCiAgIGluZGl2aWR1YWwgYXBwbGljYXRp b25zIGFuZCBiZSBsaWdodHdlaWdodC4gIFRoZSBJUHY2IFBlcmZvcm1hbmNlIGFuZA0KICAgRGlh Z25vc3RpYyBNZXRyaWNzIChQRE0pIERlc3RpbmF0aW9uIE9wdGlvbiBtZWV0cyBhbGwgdGhlc2Ug Y3JpdGVyaWEuDQogICBXZSBwcm9wb3NlIHRoYXQgUERNIGJlIHVzZWQgZm9yIHN1Y2ggbWVhc3Vy ZW1lbnRzLiAgQSBnYXAgYW5hbHlzaXMNCiAgIHNob3dzIHRoYXQgUERNIGlzIGF2YWlsYWJsZSBm b3IgSVB2NiBvbmx5IGFuZCBub3QgZm9yIElQdjQgb3IgbG93DQogICBwb3dlcmVkIGRldmljZXMu ICANCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1 Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUNCiAgIHByb3Zpc2lv bnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJ RVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcw0KICAg SW50ZXJuZXQtRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50 cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRl ZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0 aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVy ZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4g cHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4g YmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvMWlkLWFic3RyYWN0cy5odG1s DQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4g YmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCg0KDQoN Cg0KDQogDQoNCg0KRWxraW5zICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMCwg MjAxNyAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAg ZWxraW5zLWlwcG0tcGRtLW5uLTAwICAgICAgICAgICAgTWFyY2ggMTksIDIwMTcNCg0KDQpDb3B5 cmlnaHQgYW5kIExpY2Vuc2UgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAxNyBJRVRGIFRy dXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9y cy4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgSUVURiBUcnVzdCBMZWdhbCBQcm92aXNpb25z IG9mIDI4LWRlYy0yMDA5LCBTZWN0aW9uIDYuYihpKSwgcGFyYWdyYXBoDQogICAzOiBUaGlzIGRv Y3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQog ICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzDQogICAoaHR0cDovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNCiAgIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50 cw0KICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmlj dGlvbnMgd2l0aCByZXNwZWN0DQogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRz IGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdA0KICAgaW5jbHVkZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mDQogICB0aGUg VHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkg YXMNCiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4gICAgIA0KDQpU YWJsZSBvZiBDb250ZW50cw0KDQogICAxIEJhY2tncm91bmQgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgICAgMS4xIFdoYXQgTWVhc3Vy ZW1lbnRzIERvZXMgUERNIFByb3ZpZGU/ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAg ICAxLjIgSG93IERvZXMgUERNIFByb3ZpZGUgVGhpcyBJbmZvcm1hdGlvbj8gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAzDQogICAgIDEuMyBEZWZpbml0aW9ucyBvZiBSb3VuZC1UcmlwIERlbGF5IGFu ZCBTZXJ2ZXIgRGVsYXkgLiAuIC4gLiAuIC4gIDQNCiAgICAgMS40IEhvdyBXaWxsIFBETSBCZSBV c2VkIHRvIE1lYXN1cmUgTmV0IE5ldXRyYWxpdHk/ICAuIC4gLiAuIC4gLiAgNA0KICAgMiBBZHZh bnRhZ2VzIG9mIFBETSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA0DQogICAgIDIuMSBBZHZhbnRhZ2VzIG9mIFBETSBmb3IgTWVhc3VyZW1lbnQgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgICAgMi4yIEFkdmFudGFnZSBvZiBQRE0gZm9yIFNj YWxlYWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAyLjMgSXNvbGF0 aW5nIFdpcmUgVGltZSBBY2N1cmF0ZWx5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1 DQogICAgIDIuNCBNZWFzdXJlbWVudCBvZiB0aGUgQXBwbGljYXRpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgMi41IENhbGN1bGF0aW9uIG9mIHNwZWVkIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgICAyLjYgTGlnaHR3ZWlnaHQg bWVhc3VyZW1lbnQgdGVjaG5pcXVlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAg IDIuNyBVbml2ZXJzYWwgTWVhc3VyZW1lbnQgVGVjaG5pcXVlICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDYNCiAgIDMgR2FwIEFuYWx5c2lzIG9mIFBETSBpbiBOZXQgTmV1dHJhbGl0eSBN ZWFzdXJlbWVudHMgLiAuIC4gLiAuIC4gLiAgNw0KICAgICAzLjEgUERNIGZvciBJUHY0IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICAgIDMuMiBQ RE0gZm9yIExvdyBQb3dlcmVkIERldmljZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDcNCiAgIDQgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgNSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICA2IFJlZmVyZW5jZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcN CiAgICAgNi4xIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNw0KICAgICA2LjIgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICBBY2tub3dsZWRnbWVudHMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgIEF1 dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgOA0KDQoNCg0KDQoNCg0KDQogDQoNCg0KRWxraW5zICAgICAgICAgICAgICAgICBF eHBpcmVzIFNlcHRlbWJlciAyMCwgMjAxNyAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJTlRF Uk5FVCBEUkFGVCAgICAgICAgICAgZWxraW5zLWlwcG0tcGRtLW5uLTAwICAgICAgICAgICAgTWFy Y2ggMTksIDIwMTcNCg0KDQoxIEJhY2tncm91bmQNCg0KICAgVGhlIHF1ZXN0aW9uIG9mIHdoZXRo ZXIgb25lIGlzIGFjdHVhbGx5IGdldHRpbmcgdGhlIHdpcmUgc3BlZWQgdGhhdA0KICAgb25lIGlz IHBheWluZyBmb3IgaXMgY29tcGxleC4gICBJbiBbTk5SZXF1aXJlXSwgRXVyb3BlYW4gcmVndWxh dG9ycw0KICAgbWFrZSB0aGUgdXNlIGNhc2U6ICJUaGUgRXVyb3BlYW4gUmVndWxhdGlvbiByZXF1 aXJlcyBpbnRlcm5ldCBzZXJ2aWNlDQogICBwcm92aWRlcnMgKElTUHMpIHRvIHNwZWNpZnkgbmV3 IHNwZWVkIHZhbHVlcyBmb3IgZXhhbXBsZSBtaW5pbXVtLA0KICAgbWF4aW11bSwgYW5kIG5vcm1h bGx5IGF2YWlsYWJsZSBzcGVlZHMgaW4gZml4ZWQgbmV0d29yay4gIFRoZQ0KICAgbWVhc3VyZW1l bnQgdXNlIGNhc2UgaXMgdG8gYXNzZXNzIGlmIHRoZXNlIGNvbnRyYWN0dWFsIHNwZWVkIHZhbHVl cw0KICAgYXJlIG1ldC4gIFRoZSBwcm9ibGVtIGlzIHRvIGRlZmluZSBtZWFzdXJlbWVudHMgdGhh dCBjYW4gYmUgcnVuIGJ5DQogICBlbmQtdXNlcnMgYW5kIGlzIGFjY3VyYXRlIGVub3VnaCB0byBo YXZlIGxlZ2FsIHZhbHVlLiINCg0KICAgQSBudW1iZXIgb2YgZmFjdG9ycyBlbnRlciBpbnRvIG1l YXN1cmluZyBzdWNoIHRpbWU6DQoNCiAgIDEuICAgTWVhc3VyZW1lbnQgd2hpY2ggcmVzaWRlcyBh dCB0aGUgZW5kLXVzZXIgY2xpZW50DQoNCiAgIDIuICAgU2VwYXJhdGluZyB3aXJlIHRpbWUgZnJv bSB0aGUgYXBwbGljYXRpb24gLyBzdGFjayB0aW1lIA0KDQogICAzLiAgIEFjY3VyYWN5IG9mIG1l YXN1cmVtZW50DQoNCiAgIFRoZSBoeWJyaWQgbWVhc3VyZW1lbnQgdGVjaG5pcXVlLCBJUHY2IFBE TSBkZWZpbmVkIGluIFtQRE1dIGVtYmVkcw0KICAgdGltaW5nIGluZm9ybWF0aW9uIGluIGVhY2gg cGFja2V0LiAgU3VjaCB2YWx1ZXMgbWF5IGJlIHVzZWQgdG8NCiAgIGVzdGltYXRlIFFvUyBhcyBl eHBlcmllbmNlZCBieSBhbiBlbmQgdXNlciBkZXZpY2UuICBQRE0gYWxzbyBwcm92aWRlcw0KICAg dGhlIGFiaWxpdHkgdG8gZGV0ZXJtaW5lIHF1aWNrbHkgaWYgdGhlIChsYXRlbmN5KSBwcm9ibGVt IGlzIGluIHRoZQ0KICAgbmV0d29yayBvciBpbiB0aGUgc2VydmVyIChhcHBsaWNhdGlvbikuDQoN CjEuMSBXaGF0IE1lYXN1cmVtZW50cyBEb2VzIFBETSBQcm92aWRlPw0KDQogICBQRE0gcHJvdmlk ZXM6DQoNCiAgIDEuICBSb3VuZC10cmlwIGRlbGF5ICh3aXJlIHRpbWUpDQogICAyLiAgU2VydmVy IGRlbGF5IChob3N0IHRpbWUpDQoNCjEuMiBIb3cgRG9lcyBQRE0gUHJvdmlkZSBUaGlzIEluZm9y bWF0aW9uPw0KDQogICBGcm9tIFtQRE1dLCBTZWN0aW9uIDI6IE1lYXN1cmVtZW50IEluZm9ybWF0 aW9uIERlcml2ZWQgZnJvbSBQRE0NCg0KICAgIkVhY2ggcGFja2V0IGNvbnRhaW5zIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyLiBJbg0KICAgSVAgcHJvdG9jb2wsICB0 aGUgaWRlbnRpZnlpbmcgaW5mb3JtYXRpb24gaXMgY2FsbGVkIGEgIjUtdHVwbGUiLiAgDQoNCiAg IFRoZSA1LXR1cGxlIGNvbnNpc3RzIG9mOg0KDQogICAgICAgICBTQUREUiA6IElQIGFkZHJlc3Mg b2YgdGhlIHNlbmRlcg0KICAgICAgICAgU1BPUlQgOiBQb3J0IGZvciBzZW5kZXINCiAgICAgICAg IERBRERSIDogSVAgYWRkcmVzcyBvZiB0aGUgZGVzdGluYXRpb24NCiAgICAgICAgIERQT1JUIDog UG9ydCBmb3IgZGVzdGluYXRpb24NCiAgICAgICAgIFBST1RDIDogUHJvdG9jb2wgZm9yIHVwcGVy IGxheWVyIChleC4gVENQLCBVRFAsIElDTVAsIGV0Yy4pDQoNCiAgIFRoZSBQRE0gY29udGFpbnMg dGhlIGZvbGxvd2luZyBiYXNlIGZpZWxkczoNCiANCg0KDQpFbGtpbnMgICAgICAgICAgICAgICAg IEV4cGlyZXMgU2VwdGVtYmVyIDIwLCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCklO VEVSTkVUIERSQUZUICAgICAgICAgICBlbGtpbnMtaXBwbS1wZG0tbm4tMDAgICAgICAgICAgICBN YXJjaCAxOSwgMjAxNw0KDQoNCiAgICAgICAgIFBTTlRQICAgIDogUGFja2V0IFNlcXVlbmNlIE51 bWJlciBUaGlzIFBhY2tldA0KICAgICAgICAgUFNOTFIgICAgOiBQYWNrZXQgU2VxdWVuY2UgTnVt YmVyIExhc3QgUmVjZWl2ZWQNCiAgICAgICAgIERFTFRBVExSIDogRGVsdGEgVGltZSBMYXN0IFJl Y2VpdmVkDQogICAgICAgICBERUxUQVRMUyA6IERlbHRhIFRpbWUgTGFzdCBTZW50Ig0KDQogICBU aGlzIGluZm9ybWF0aW9uLCBjb21iaW5lZCB3aXRoIHRoZSA1LXR1cGxlLCBhbGxvd3MgdGhlIG1l YXN1cmVtZW50DQogICBvZiByb3VuZC10cmlwIGRlbGF5ICh3aXJlIHRpbWUpIGFuZCBzZXJ2ZXIg ZGVsYXkgKGhvc3QgdGltZSkuDQoNCjEuMyBEZWZpbml0aW9ucyBvZiBSb3VuZC1UcmlwIERlbGF5 IGFuZCBTZXJ2ZXIgRGVsYXkNCg0KICAgVGhlIFBETSBkZXNjcmlwdGlvbiBkZWZpbmVzIHRoZSBt ZWFzdXJlbWVudCBmaWVsZHMgb2YgaW50ZXJlc3QuDQoNCiAgIEZyb20gUERNIFtQRE1dOg0KDQog ICAiUm91bmQtdHJpcCAqTmV0d29yayogZGVsYXkgaXMgdGhlIGRlbGF5IGZvciBwYWNrZXQgdHJh bnNmZXIgZnJvbSBhDQogICBzb3VyY2UgaG9zdCB0byBhIGRlc3RpbmF0aW9uIGhvc3QgYW5kIHRo ZW4gYmFjayB0byB0aGUgc291cmNlIGhvc3QuDQogICBUaGlzIG1lYXN1cmVtZW50IGhhcyBiZWVu IGRlZmluZWQsIGFuZCB0aGUgYWR2YW50YWdlcyBhbmQNCiAgIGRpc2FkdmFudGFnZXMgZGlzY3Vz c2VkIGluICJBIFJvdW5kLXRyaXAgRGVsYXkgTWV0cmljIGZvciBJUFBNIg0KICAgW1JGQzI2ODFd LiINCg0KICAgIlNlcnZlciBkZWxheSBpcyB0aGUgaW50ZXJ2YWwgYmV0d2VlbiB3aGVuIGEgcGFj a2V0IGlzIHJlY2VpdmVkIGJ5IGENCiAgIGRldmljZSBhbmQgdGhlIGZpcnN0IGNvcnJlc3BvbmRp bmcgcGFja2V0IGlzIHNlbnQgYmFjayBpbiByZXNwb25zZS4NCiAgIFRoaXMgbWF5IGJlICJTZXJ2 ZXIgUHJvY2Vzc2luZyBUaW1lIi4gIEl0IG1heSBhbHNvIGJlIGEgZGVsYXkgY2F1c2VkDQogICBi eSBhY2tub3dsZWRnZW1lbnRzLiAgU2VydmVyIHByb2Nlc3NpbmcgdGltZSBpbmNsdWRlcyB0aGUg dGltZSB0YWtlbg0KICAgYnkgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBzdGFjayBhbmQgYXBwbGlj YXRpb24gdG8gcmV0dXJuIHRoZQ0KICAgcmVzcG9uc2UuIFRoZSBzdGFjayBkZWxheSBtYXkgYmUg cmVsYXRlZCB0byBuZXR3b3JrIHBlcmZvcm1hbmNlLiAgIElmDQogICB0aGlzIGFnZ3JlZ2F0ZSB0 aW1lIGlzIHNlZW4gYXMgYSBwcm9ibGVtLCBhbmQgdGhlcmUgaXMgYSBuZWVkIHRvIG1ha2UNCiAg IGEgY2xlYXIgZGlzdGluY3Rpb24gYmV0d2VlbiBhcHBsaWNhdGlvbiBwcm9jZXNzaW5nIHRpbWUg YW5kIHN0YWNrDQogICBkZWxheSwgaW5jbHVkaW5nIHRoYXQgY2F1c2VkIGJ5IHRoZSBuZXR3b3Jr LCB0aGVuIG1vcmUgY2xpZW50IGJhc2VkDQogICBtZWFzdXJlbWVudHMgYXJlIG5lZWRlZC4iDQoN CjEuNCBIb3cgV2lsbCBQRE0gQmUgVXNlZCB0byBNZWFzdXJlIE5ldCBOZXV0cmFsaXR5Pw0KDQog ICBTaW5jZSBQRE0gaXMgZW1iZWRkZWQgaW4gdGhlIHBhY2tldCwgYW55IG1lYXN1cmluZyB0b29s IHRoYXQgaXMgYWJsZQ0KICAgdG8gY2FwdHVyZSBwYWNrZXRzIG1heSBzZXJ2ZSBhcyBhIGNhcHR1 cmUgcG9pbnQuIFN1Y2ggZGV2aWNlcyByYW5nZQ0KICAgZnJvbSBhIHNpbXBsZSBXaXJlc2hhcmsg cGFja2V0IGNhcHR1cmUgdG8gYSBsYXJnZSBuZXR3b3JrIG9mIGFnZW50cw0KICAgYW5kIGNvbnRy b2xsZXJzIHVzaW5nIHRoZSBMTUFQIFtSRkM3NTk0XSBwcm90b2NvbC4NCg0KDQoyIEFkdmFudGFn ZXMgb2YgUERNDQoNCjIuMSBBZHZhbnRhZ2VzIG9mIFBETSBmb3IgTWVhc3VyZW1lbnQNCg0KICAg RnJvbSBbUERNXQ0KDQogICAiQWR2YW50YWdlcyBpbmNsdWRlOiANCg0KICAgMS4gUmVhbCBtZWFz dXJlIG9mIGFjdHVhbCB0cmFuc2FjdGlvbnMuIA0KIA0KDQoNCkVsa2lucyAgICAgICAgICAgICAg ICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjAsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0K SU5URVJORVQgRFJBRlQgICAgICAgICAgIGVsa2lucy1pcHBtLXBkbS1ubi0wMCAgICAgICAgICAg IE1hcmNoIDE5LCAyMDE3DQoNCg0KICAgMi4gSW5kZXBlbmRlbmNlIGZyb20gdHJhbnNwb3J0IGxh eWVyIHByb3RvY29scy4gDQoNCiAgIDMuIEFiaWxpdHkgdG8gc3BhbiBvcmdhbml6YXRpb25hbCBi b3VuZGFyaWVzIHdpdGggY29uc2lzdGVudA0KICAgaW5zdHJ1bWVudGF0aW9uLg0KDQogICA0LiBO byB0aW1lIHN5bmNocm9uaXphdGlvbiBuZWVkZWQgYmV0d2VlbiBzZXNzaW9uIHBhcnRuZXJzIA0K DQogICA1LiBBYmlsaXR5IHRvIGhhbmRsZSBhbGwgdHJhbnNwb3J0IHByb3RvY29scyAoVENQLCBV RFAsIFNDVFAsIGV0YykgaW4NCiAgIGEgdW5pZm9ybSB3YXkgIg0KDQoyLjIgQWR2YW50YWdlIG9m IFBETSBmb3IgU2NhbGVhYmlsaXR5DQoNCiAgIFRoZSBhZHZhbnRhZ2Ugb2YgUERNIGluIHNjYWxl YWJpbGl0eSBmb3IgbWVhc3VyaW5nIG5ldCBuZXV0cmFsaXR5IGlzDQogICB0aGF0IG5vIGFkZGl0 aW9uYWwgY2xpZW50IHNvZnR3YXJlIG5lZWRzIHRvIGJlIGltcGxlbWVudGVkLiAgVGhlIHRhc2sN CiAgIG9mIGhhdmluZyBzb21lIGFnZW50IGF0IGVhY2ggY2xpZW50IHRoYXQgb25lIHdpc2hlcyB0 byBtZWFzdXJlDQogICB0aHJvdWdob3V0IHRoZSB3b3JsZCBpcyBub3RoaW5nIGxlc3MgdGhhbiBk YXVudGluZy4gICBIYXZpbmcgc2FpZA0KICAgdGhhdCwgc29tZSBvcmdhbml6YXRpb25zLCBmb3Ig ZXhhbXBsZSwgd2l0aCB0aGUgUklQRSBwcm9iZXMsIGhhdmUNCiAgIHVuZGVydGFrZW4gdGhpcyB0 YXNrIHdpdGggcXVpdGUgYSBiaXQgb2Ygc3VjY2Vzcy4NCg0KICAgSW1hZ2luZSBob3cgbXVjaCBz aW1wbGVyIHRoaXMgbWlnaHQgYmUgaWYgbm90aGluZyBuZWVkZWQgdG8gYmUNCiAgIGluc3RhbGxl ZCBhdCB0aGUgY2xpZW50IC0tIGlmIHRoZSBhY3R1YWwgZGF0YSBuZWVkZWQgZm9yIGFjY3VyYXRl DQogICBtZWFzdXJlbWVudCB3YXMgaW4gdGhlIHBhY2tldCBpdHNlbGYuICBUaGlzIGlzIHdoYXQg UERNIHByb3ZpZGVzLg0KDQoyLjMgSXNvbGF0aW5nIFdpcmUgVGltZSBBY2N1cmF0ZWx5DQoNCiAg IEZyb20gW05OUmVxdWlyZV0sIG9uZSBvZiB0aGUgcmVxdWlyZW1lbnRzIG9mIG5ldCBuZXV0cmFs aXR5IGlzIHRvDQogICBpc29sYXRlIHRoZSB3aXJlIHRpbWUgZnJvbSBvdGhlciBmYWN0b3JzOg0K DQogICAiV2hlbiBtZWFzdXJlbWVudCB0YXNrcyBhcmUgcnVuIGJ5IGFuIGVuZC11c2VyLCBlbmQt dXNlciBlbnZpcm9ubWVudCANCiAgIHNwZWNpZmljIGZhY3RvcnMgbGlrZSBjcm9zcy10cmFmZmlj LCBtZWFzdXJlbWVudCBpbnRlcmZhY2UgDQogICAoZml4ZWQvd2lyZWxlc3MpLCBmaXJld2FsbHMs IGNsaWVudCBvcGVyYXRpbmcgc3lzdGVtIGFuZCBoYXJkd2FyZSANCiAgIGNhbiBpbmZsdWVuY2Ug dGhlIG1lYXN1cmVtZW50IHJlc3VsdC4gIFRoZXNlIGZhY3RvcnMgaGF2ZSB0byBiZSANCiAgIGRl dGVjdGVkIGFuZCB0YWtlbiBpbnRvIGFjY291bnQgd2hlbiBhc3Nlc3NpbmcgbWVhc3VyZW1lbnRz IA0KICAgcGVyZm9ybWVkIGJ5IGVuZC11c2Vycy4iDQoNCiAgIFBETSBpcyBpbXBsZW1lbnRlZCBh cyBjbG9zZSB0byB0aGUgbmV0d29yayBpbnRlcmZhY2UgYXMgcG9zc2libGUgc28NCiAgIHRoZSBp c29sYXRpb24gb2Ygd2lyZSB0aW1lIGlzIGV4cGVjdGVkIHRvIGJlIHF1aXRlIGFjY3VyYXRlLg0K DQoyLjQgTWVhc3VyZW1lbnQgb2YgdGhlIEFwcGxpY2F0aW9uDQoNCiAgIFBETSBpcyBlbWJlZGRl ZCBpbiBlYWNoIHBhY2tldC4gIEVhY2ggcGFja2V0IGluaGVyZW50bHkgaGFzIGEgNS0NCiAgIHR1 cGxlLiAgIFNvLCBhcyB0aGUgcGFja2V0IGlzIGNhcHR1cmVkIGFuZCBhbmFseXplZCB2aWEgYW5h bHlzaXMNCiAgIHRvb2xzLCBkYXRhIG9uIGFwcGxpY2F0aW9uIHVzYWdlIGlzIGF2YWlsYWJsZS4N Cg0KDQoNCg0KDQogDQoNCg0KRWxraW5zICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciAyMCwgMjAxNyAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAg ICAgICAgZWxraW5zLWlwcG0tcGRtLW5uLTAwICAgICAgICAgICAgTWFyY2ggMTksIDIwMTcNCg0K DQoyLjUgQ2FsY3VsYXRpb24gb2Ygc3BlZWQNCg0KICAgT25lIG9mIHRoZSByZXF1aXJlbWVudHMg ZnJvbSBbTk5SZXF1aXJlXSBzdGF0ZXMgdGhhdCAic3BlZWQgc2hvdWxkIGJlDQogICBjYWxjdWxh dGVkIGJhc2VkIG9uIElQIHBhY2tldCBwYXlsb2FkIi4gU2luY2UgUERNIGlzIGVtYmVkZGVkIGlu IHRoZQ0KICAgcGFja2V0LCBhbmQgcGFja2V0cyBhcmUgYmVpbmcgY2FwdHVyZWQgYnkgdGhlIG1l YXN1cmVtZW50IGRldmljZSwgdGhlDQogICBsZW5ndGggb2YgdGhlIElQIGFuZCB1cHBlciBsYXll ciBoZWFkZXJzIGFyZSByZWFkaWx5IGRpZmZlcmVudGlhdGVkDQogICBmcm9tIHRoZSBzaXplIG9m IHRoZSBhY3R1YWwgcGF5bG9hZC4NCg0KMi42IExpZ2h0d2VpZ2h0IG1lYXN1cmVtZW50IHRlY2hu aXF1ZQ0KDQogICBBbm90aGVyIG9mIHRoZSByZXF1aXJlbWVudHMgb2YgW05OUmVxdWlyZV0gc3Rh dGVzIHRoYXQgIm1lYXN1cmVtZW50DQogICBkb2VzIG5vdCBibG9jayB0aGUgaW50ZXJuZXQgYWNj ZXNzIHVzYWdlIGZvciB3aG9sZSBkYXkgYW5kIGRvZXMgbm90DQogICBnZW5lcmF0ZSBleGNlc3Np dmUgbmV0d29yayBsb2FkLiINCg0KICAgUERNIGlzIGVtYmVkZGVkIGluIHRoZSBwYWNrZXQgYW5k IHNvIGNsZWFybHkgZG9lcyBub3QgYmxvY2sgdXNhZ2Ugb2YNCiAgIHRoZSBJbnRlcm5ldCBmb3Ig dGhlIGVuZC11c2VyIGZvciBhbnkgdGFzayByZXF1aXJlZC4NCg0KICAgQXMgZmFyIGFzIGxvYWQs IGZyb20gW1BETV0sIEFwcGVuZGl4IEM6IFBvdGVudGlhbCBPdmVyaGVhZA0KICAgQ29uc2lkZXJh dGlvbnMsIGRpc2N1c3NlcyB0aGUgYWRkaXRpb25hbCBvdmVyaGVhZCBjcmVhdGVkIGJ5IGFkZGlu Zw0KICAgUERNIHRvIGEgcGFja2V0Lg0KDQogICAiQmVsb3cgaXMgYSB0YWJsZSBvdXRsaW5pbmcg dGhlIHBvdGVudGlhbCBvdmVyaGVhZCBpbiB0ZXJtcyBvZg0KICAgYWRkaXRpb25hbCB0aW1lIHRv IGRlbGl2ZXIgdGhlIHJlc3BvbnNlIHRvIHRoZSBlbmQgdXNlciBmb3IgdmFyaW91cw0KICAgYXNz dW1lZCBSVFRzLg0KDQogICBCeXRlcyAgICAgICAgIFJUVCAgICAgICAgIEJ5dGVzICAgICAgIEJ5 dGVzICAgICAgTmV3ICAgICAgT3ZlcmhlYWQNCiAgIGluIFBhY2tldCAgICAgICAgICAgICAgICBQ ZXIgTWlsbGlzZWMgaW4gUERNICAgICBSVFQgICAgICAgIA0KICAgPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogICAx MDAwICAgICAgIDEwMDAgbWlsbGkgICAgICAgICAxICAgICAgIDE2ICAgICAxMDE2LjAwMCAgMTYu MDAwIG1pbGxpDQogICAxMDAwICAgICAgICAxMDAgbWlsbGkgICAgICAgIDEwICAgICAgIDE2ICAg ICAgMTAxLjYwMCAgIDEuNjAwIG1pbGxpDQogICAxMDAwICAgICAgICAgMTAgbWlsbGkgICAgICAg MTAwICAgICAgIDE2ICAgICAgIDEwLjE2MCAgICAuMTYwIG1pbGxpDQogICAxMDAwICAgICAgICAg IDEgbWlsbGkgICAgICAxMDAwICAgICAgIDE2ICAgICAgICAxLjAxNiAgICAuMDE2IG1pbGxpDQoN CiAgIEJlbG93IGFyZSBzb21lIGV4YW1wbGVzIG9mIGFjdHVhbCBSVFRzIGZvciBwYWNrZXRzIHRy YXZlcnNpbmcgbGFyZ2UNCiAgIGVudGVycHJpc2UgbmV0d29ya3MuICAgIA0KDQogICBCeXRlcyAg ICAgICAgIFJUVCAgICAgICAgQnl0ZXMgICAgICAgQnl0ZXMgICAgICBOZXcgICAgIE92ZXJoZWFk DQogICBpbiBQYWNrZXQgICAgICAgICAgICAgICAgUGVyIE1pbGxpc2VjIGluIFBETSAgICAgUlRU DQogICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCiAgIDEwMDAgICAgICAgMTcgbWlsbGkgICAgICAgICA1OCAgICAg ICAgMTYgICAgICAgMTcuMzYwICAgLjM2MCBtaWxsaQ0KDQoNCjIuNyBVbml2ZXJzYWwgTWVhc3Vy ZW1lbnQgVGVjaG5pcXVlDQoNCiAgIFtOTlJlcXVpcmVdIHdvdWxkIGxpa2UgdGVjaG5pcXVlIHdo aWNoIGlzIHVuaXZlcnNhbC4gIFRoYXQgaXM6DQoNCiAgICJJbiBwcmluY2lwbGUsIGFueSBzb2x1 dGlvbiBzaG91bGQgYmUgZXF1YWxseSBhcHBsaWNhYmxlIHRvIGJvdGgNCiAgIGZpeGVkIGFuZCBt b2JpbGUgSW50ZXJuZXQgYWNjZXNzIHNlcnZpY2VzIGZyb20gbmFycm93IGJhbmQgdG8gbXVsdGkt DQogDQoNCg0KRWxraW5zICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMCwgMjAx NyAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAgZWxr aW5zLWlwcG0tcGRtLW5uLTAwICAgICAgICAgICAgTWFyY2ggMTksIDIwMTcNCg0KDQogICBnaWdh Yml0IGNvbm5lY3Rpb25zLiINCg0KICAgUERNIGlzIGVtYmVkZGVkIGluIHRoZSBJUCBwYWNrZXQu ICBUaGUgb3BlcmF0aW5nIHN5c3RlbSBtZXJlbHkgbmVlZHMNCiAgIHRvIGltcGxlbWVudCBpdC4g IFBETSBoYXMgbm8gZmF2b3JpdGVzOiBmaXhlZCBvciBtb2JpbGUgYXJlIGFzIG9uZSB0bw0KICAg aXQuDQoNCjMgR2FwIEFuYWx5c2lzIG9mIFBETSBpbiBOZXQgTmV1dHJhbGl0eSBNZWFzdXJlbWVu dHMNCg0KMy4xIFBETSBmb3IgSVB2NA0KDQogICBNdWNoIGFzIHdlIG1pZ2h0IHdhbnQgdGhlIHdv cmxkIHRvIHVzZSBJUHY2IGV4Y2x1c2l2ZWx5LCB0aGUgdGhvcm55DQogICBpc3N1ZSBvZiBhIHdv cmxkIHdpZGUgYmFzZSBvZiBJUHY0IG9uIHRoZSBJbnRlcm5ldCB3aGljaCByZWZ1c2VzIHRvDQog ICBkaWUgcXVpZXRseSByZW1haW5zLiAgVG9kYXksIFBETSBpcyBhYmxlIHRvIG1lYXN1cmUgSVB2 NiBvbmx5LiAgIFBETQ0KICAgbmVlZHMgdG8gYmUgZXh0ZW5kZWQgdG8gbWVhc3VyZSBJUHY0Lg0K DQozLjIgUERNIGZvciBMb3cgUG93ZXJlZCBEZXZpY2VzDQoNCiAgIFRoZSB3b3JsZCBpcyBiZWNv bWluZyBmaWxsZWQgd2l0aCBzbWFsbCwgc29tZXdoYXQgaW50ZWxsaWdlbnQgZGV2aWNlcw0KICAg d2hpY2ggY29tbXVuaWNhdGUgYWNyb3NzIG5ldHdvcmtzLiAgIFNob3VsZCBuZXQgbmV1dHJhbGl0 eSBiZQ0KICAgZXh0ZW5kZWQgdG8gc3VjaCBkZXZpY2VzLCB0aGVuIFBETSB3aWxsIG5lZWQgdG8g YmUgZGVmaW5lZCBmb3IgbG93DQogICBwb3dlcmVkIGRldmljZXMuICAgSGF2aW5nIHNhaWQgdGhh dCwgdGhlIG92ZXJoZWFkIGNyZWF0ZWQgYnkgUERNLA0KICAgdGhvdWdoIGluY29uc2VxdWVudGlh bCBmb3IgbGFwdG9wcyBhbmQgY2VsbCBwaG9uZXMsIG1heSBiZSB0b28gbXVjaA0KICAgZm9yIHZl cnkgc21hbGwgZGV2aWNlcy4NCg0KNCBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZXJlIGFy ZSBubyBJQU5BIGNvbnNpZGVyYXRpb25zLg0KDQo1IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoN CiAgIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBQRE0gYXJlIGRldGFpbGVkIGluIHRoZSBQ RE0gW1BETV0NCiAgIGRlc2NyaXB0aW9uLg0KDQoNCjYgUmVmZXJlbmNlcw0KDQo2LjEgTm9ybWF0 aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzI2ODFdICBBbG1lcywgRy4sIEthbGlkaW5kaSwgUy4s IGFuZCBNLiBaZWthdXNrYXMsICJBIFJvdW5kLXRyaXANCiAgIERlbGF5IE1ldHJpYyBmb3IgSVBQ TSIsIFJGQyAyNjgxLCBTZXB0ZW1iZXIgMTk5OS4NCg0KICAgW1JGQzc1OTRdIEVhcmRsZXksIFAu LCAiQSBGcmFtZXdvcmsgZm9yIExhcmdlLVNjYWxlIE1lYXN1cmVtZW50IG9mDQogICBCcm9hZGJh bmQgUGVyZm9ybWFuY2UgKExNQVApIiwgUkZDIDc1OTQsIE9jdG9iZXIsIDIwMTUuDQoNCjYuMiBJ bmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCg0KICAgW1BETV0gRWxraW5zLCBOLiAiSVB2NiBQZXJm b3JtYW5jZSBhbmQgRGlhZ25vc3RpYyBNZXRyaWNzIChQRE0pDQogDQoNCg0KRWxraW5zICAgICAg ICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMCwgMjAxNyAgICAgICAgICAgICAgIFtQYWdl IDddDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAgZWxraW5zLWlwcG0tcGRtLW5uLTAwICAg ICAgICAgICAgTWFyY2ggMTksIDIwMTcNCg0KDQogICBEZXN0aW5hdGlvbiBPcHRpb24iLCBkcmFm dC1pZXRmLWlwcG0tNm1hbi1wZG0tb3B0aW9uLTA5LCBNYXJjaCwgMjAxNw0KICAgW1dvcmsgaW4g UHJvZ3Jlc3NdDQoNCiAgIFtOTlJlcXVpcmVdIE5pZW1pbmVuLCBLLiwgIk5ldCBOZXV0cmFsaXR5 IE1lYXN1cmVtZW50czogUmVndWxhdG9yeQ0KICAgVXNlIENhc2UgYW5kIFByb2JsZW0gU3RhdGVt ZW50IiwgZHJhZnQtbmllbWluZW4taXBwbS1ubi1tZWFzdXJlbWVudHMtDQogICAwMCwgRmVicnVh cnksIDIwMTcgW1dvcmsgaW4gUHJvZ3Jlc3NdDQoNCkFja25vd2xlZGdtZW50cw0KDQpBdXRob3Jz JyBBZGRyZXNzZXMNCg0KICAgTmFsaW5pIEVsa2lucw0KICAgSW5zaWRlIFByb2R1Y3RzLCBJbmMu DQogICAzNkEgVXBwZXIgQ2lyY2xlDQogICBDYXJtZWwgVmFsbGV5LCBDQSA5MzkyNA0KICAgVW5p dGVkIFN0YXRlcw0KICAgUGhvbmU6ICsxIDgzMSA2NTkgODM2MA0KICAgRW1haWw6IG5hbGluaS5l bGtpbnNAaW5zaWRldGhlc3RhY2suY29tDQogICBodHRwOi8vd3d3Lmluc2lkZXRoZXN0YWNrLmNv bQ0KDQoNCiAgIFdpbGxpYW0gSm91cmlzDQogICBJbnNpZGUgUHJvZHVjdHMsIEluYy4NCiAgIDM2 QSBVcHBlciBDaXJjbGUNCiAgIENhcm1lbCBWYWxsZXksIENBIDkzOTI0DQogICBVbml0ZWQgU3Rh dGVzDQogICBQaG9uZTogKzEgODMxIDY1OSA4MzYwDQogICBFbWFpbDogYmlsbC5qb3VyaXNAaW5z aWRldGhlc3RhY2suY29tDQogICBodHRwOi8vd3d3Lmluc2lkZXRoZXN0YWNrLmNvbQ0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpFbGtpbnMgICAgICAgICAgICAg ICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIwLCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgOF0NCg== ------=_Part_571956_307196473.1489936399775-- From nobody Mon Mar 20 10:17:22 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3415E13154D for ; Mon, 20 Mar 2017 10:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 54ESN9gFqTdD for ; Mon, 20 Mar 2017 10:17:15 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48698131507 for ; Mon, 20 Mar 2017 10:15:38 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id i1so136715572ota.3 for ; Mon, 20 Mar 2017 10:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HOZvd5ViYHRMst/45mwjb+XKWzRnzJ2HVtuNb7w815Y=; b=QbMpbSP4mjXmi5p1rNs9yqPVzTgMm2jcPf1Z9idNsgu8zmgbi/ildgyIbD7GjjjBOj 3RMZsZzuwLDoGwgmGmOQfVQxMy8CvC/88mbzVoM0MGVcbBvsJxYvwJRWMwqa1u+D3f6c M/BOXbBKhkLaz3vLzSNDG1ER34fnk3di/wshePpnrDBV20/up7cZRvZ8sNfjPm4+qgO9 WsTiKpRnd7vvkYFk0J6lI/vHLCPBdnNtxyE1rMOJEap9ycktCifBMIjcqZRGI8A4JW1B +jAmdp6eydhglfNzW0Vec1KyITuaCqO1CoR0jWvfqS78QFuLtXVlE5kJFAaiUaW3KdXl Mobw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HOZvd5ViYHRMst/45mwjb+XKWzRnzJ2HVtuNb7w815Y=; b=Nm9K+H5G0C90Uf84G1FaK3qlSTurgtnseFIEqO6Djsw0oaOSc15bXEIGth5mMrWEvd U3XHNgQPzK50hzcMUuHOGD48v2yNzOZeKSt8CvNJPjTsCATg2xJ+brurNw705BOz4DHC z4g6FYcrvGNztPUUCNFnxBoZ1QMxRUT8we9Ir8RSYRK4jvr/52rsHKoy63hCWDV1XsFX //O2kxdGCRPkbasPyfFYMXLaDtHspAIYAc7zEmLpnQRuHLwMmf7EDUS1oxdBjdVouVlN E9dHAxe9d12mQAjEQguAFisUFrjK3LcfEz/WyKu6/HtZjrwo84nW6KBUG6nUN5CSjvNT GELg== X-Gm-Message-State: AFeK/H2av6ZUB6z5nHXKb7ZBgUZ7//S5lYqAMruc6goKLipLmJT/SZSnFEgm1Bop33zxs7uH0a441yrdQ79UbA== X-Received: by 10.157.1.247 with SMTP id e110mr14621281ote.40.1490030137630; Mon, 20 Mar 2017 10:15:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Mon, 20 Mar 2017 10:15:37 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Mon, 20 Mar 2017 12:15:37 -0500 Message-ID: To: Wei Luo S Cc: "ippm@ietf.org" , "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03b82a0ee907054b2cadcd Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 17:17:19 -0000 --94eb2c03b82a0ee907054b2cadcd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Wei Luo, many thanks for your thorough review and the most helpful comments to the TWAMP Light(Test) model. Please find my answers, notes in-line tagged GIM>>= . Regards, Greg On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S wrote: > Hi Greg & Adrian, > > > > This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. Th= e > current TWAMP Light YANG model is well defined. Thanks for your great job= . > > But by working closely with our customers, we got some new user cases on > TWAMP light. I believe these user cases are valuable and popular enough t= o > be modeled in TWAMP Light YANG. I hope I can be a contributor and co-wor= k > with you move this draft forward. > > I drafted a new version of the TWAMP light YANG model based on version > ietf-twamp-light@2017-02-13.yang. Could you please comments on it? Any > discussion is welcome. > > The draft yang model and tree is attached. To make you find the updates > quickly, I highlighted all the updates in file > ietf-twamp-light-weiluo.pdf. > > > > The following are the list of main updates: > > *1. Add a new typedef: percent. This is a new type defined for packet los= s > ratio.* > > Consideration: > > 1). From the customer perspective, packet loss ratio is a more meaningful > data. In most of the time, the absolute number is meaningless to user, > especially they do the TWAMP test continuously. They are more care about > the ratio than the absolute number. So adding it makes this model more > friendly to customer; > > 2). From the service layer assurance(SLA) perspective, the packet loss > ratio is a major measures. So with adding packet loss ratio in model, the > TWAMP can work in SLA framework more smoothly. > > 3). It seems some similar protocol=E2=80=99s YANG model has the same defi= nition, > e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99, > https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf. > GIM>> Indeed, packet loss more often expressed as packet loss ratio rather than as the absolute number. It would be most helpful to hear from network operators if they see introduction of Packet Loss Ratio into the TWAMP model helpful. *2. Add a new typedef: state-mode. It defines a common type for > stateful/stateless reflector. This type will be used in both sender sessi= on > and reflector session.* > > Consideration: > > If the reflector is stateful, the TWAMP light can measure more items, e.g= . > one way packet loss. So for sender, the stats calculation and show is > different. When the reflector is stateless, it doesn=E2=80=99t need to ca= lculate > the one way packet loss. The one way packet loss is invalid and shouldn= =E2=80=99t > be presented to customer. When the reflector is stateless, the sender nee= ds > to calculate the one way packet loss. And the data should be present to > customer. So this is used as a =E2=80=98when=E2=80=99 condition in the mo= del=E2=80=99s RO tree. > GIM>> Yes, if Session-Sender is aware of the mode corresponding Session-Reflector operates, the sender may avoid calculation of some performance metrics, e.g., one-way packet loss. On the other hand, the orchestrator is aware of the state-mode and should be capable to properly use metrics reported by the Session-Sender. > *3. Add a new typedef: send-mode. This is a new type for sender session. > It makes the sender session can send packet continuously and monitor the > network all the time.* > > Consideration: > > The user case is that: the user runs TWAMP light sessions to watch links > quality continuously. The session number could be very big. These TWAMP > sessions are managed by SLA framework or similar. SLA retrieves the stats > from TWAMP periodically, e.g. 15mins. In other words, all the performance > metrics are calculated based on the packets sent/received within 15mins. > This makes the calculation become possible. With the periodical stats dat= a, > the Network Management software can do further actions if some abnormal > stats observed. This is a more general user case in customer site. While > the non-continuous TWAMP sender session is generally used for debugging > purpose on a link. > GIM>> I think that support of continuous measurement is in LMAP domain, not for TWAMP Test data model. To conduct continuous measurement he LMAP Controller, in my opinion, programs the Measurement Agent to perform TWAMP Test session with certain set of parameters and repeat it without any interval (interval =3D 0). > *4. Add a new group: packet-loss-statistics. It grouping two packet loss > statistics: loss-count and loss-ratio. This group will be used in RO stat= s > tree.* > GIM>> I'd like to continue discussion. > *5. Move leaf dscp out from grouping session-light-parameters. The leaf > dscp is only valid when the dscp-handling-mode is use-configured-value. A > when condition shall be added to it. So it can=E2=80=99t be in this group= .* > GIM>> I'm concerned that then the model will not be able to support concurrent TWAMP Test sessions between the same pair of Test Points (IP address+port number) at different CoS markings. > *6. Add leaf 'session-packet-send-mode' to > /twamp-light/twamp-light-session-sender/test-session*. This leaf specifie= s > the sender session's packet send mode: continuous or non-continuous.* > GIM>> As discussed in #3, I think that it is already part of LMAP YANG model. > *7. Add leaf 'reflector-light-mode-state' to > /twamp-light/twamp-light-session-sender/test-session*. This leaf indicate= s > the the reflector's mode: stateful or stateless. If the reflector's mode = is > stateful. Two one way packet loss statistics can be got: > one-way-packet-loss-far-end, one-way-packet-loss-near-end.* > > Consideration: > > Only valid data should be presented to user. Otherwise it could misleadin= g > user in some cases. > GIM>> A in response to #2. > *8. Modify leaf > /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. > Add a 'when' condition to this leaf. When send-mode is 'continuous', the > leaf number-of-packets is meaningless. So add a 'when' condition to limit > it. Besides, added a default value =E2=80=9810=E2=80=99 to it. When the = send-mode is > 'non-continuous', the session can't work with an empty number-of-packets.= * > GIM>> As I've noted in #3. Will add default. > *9. Add leaf time out to > /twamp-light/twamp-light-session-sender/test-session*. A timeout mechanis= m > is needed when the sender session can't get all the reply packets for a > long time.* > GIM>> Thank you, will add in the next update. > *10. Modify leaf > /twamp-light/twamp-light-session-sender/test-session*/interval. Change th= e > units from =E2=80=98microseconds=E2=80=99 to =E2=80=98milliseconds=E2=80= =99. Add a default value 1000. * > > Consideration: > > 1). The aim of TWAMP is to measure network quality, but not fast > failure detection. So a millisecond packet interval is enough. > > 2). Interval is a necessary parameter for a session. A sender session > can't work with an empty packet send interval. So added a default value t= o > it. > GIM>> Thank you. We've made units of interval microseconds in the last update already. I think that changing to milliseconds may be too restrictive, limit use cases for TWAMP Test. Will add default value with the next update. > *11. Add leaf 'dscp' to > /twamp-light/twamp-light-session-sender/test-session*. This is the leaf > moved out from grouping session-light-parameters.* > GIM>> As noted in response #5, the change may limit ability to run concurrent TWAMP Test sessions per CoS. I consider that to be valuable mode but would like to hear from network operators if that is indeed useful information. > *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and > 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to > /twamp-light/twamp-light-session-reflector/test-session*. These three > attributes should be session specific. Different session could have > different values. They are not common attributes.* > GIM>> Agree, will make it in the next update. > *13. Add leaf 'dscp' to > /twamp-light/twamp-light-session-reflector/test-session*. This is the lea= f > moved out from grouping session-light-parameters. Besides the movement, > added a 'when' condition to the leaf 'dscp'. This leaf is only valid when > the dscp-handling-mode is 'use-configured-value'.* > GIM>> As response to #5. > *14. Modify leaf > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/number-of-packets. > Add a 'when' condition to this leaf. When send-mode is 'continuous', the > leaf number-of-packets is meaningless.* > GIM>> Similar to #3. > *15. Modify leaf > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/interval. > Change the units from microseconds to milliseconds.* > GIM>> I think that microseconds is reasonable. > *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and > 'one-way-packet-loss-near-end' to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/. > These are the new statistics for stateful reflector.* > GIM>> Thank you, will be coming in the next update. > *17. Remove leaf loss-packet in > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats. > The loss packeted is replaced with 'two-way-packet-loss' stated above.* > GIM>> Agree. > *18. Modify leaf to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/h= istory-stats*/interval. > Change the units from microseconds to milliseconds.* > GIM>> I think that will limit applicability of TWAMP Test. > *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and > 'one-way-packet-loss-near-end' to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/h= istory-stats*/. > These are the new statistics for stateful reflector.* > GIM>> Agree. > Thanks, > > Wei Luo > --94eb2c03b82a0ee907054b2cadcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Wei Luo,
many thanks for your thorough review and t= he most helpful comments to the TWAMP Light(Test) model. Please find my ans= wers, notes in-line tagged GIM>>.

Regards,
Greg

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <wei.s.luo@ericsson.com= > wrote:

Hi Greg & Adrian,

=C2=A0

This is Wei Luo from Ericsson. I work on TWAMP light= area in Ericsson. The current TWAMP Light YANG model is well defined. Than= ks for your great job.

But by working closely with our customers, we got so= me new user cases on TWAMP light. I believe these user cases are valuable a= nd popular enough to be modeled in TWAMP Light YANG. I hope I can be a contributor =C2=A0and co-work with you move this draft f= orward.=C2=A0

I =C2=A0drafted a new version of the TWAMP light YAN= G model based on version ietf-= twamp-light@2017-02-13.yang. Could you please comments on it? Any = discussion is welcome.

The draft yang model and tree is attached. To make y= ou find the updates quickly, I highlighted all the updates in fil= e ietf-twamp-light-weiluo.pdf.

=C2=A0

The following are the list of main updates:

1. Add a new typedef: percent. This is a new type= defined for packet loss ratio.

Consideration:

1). From the customer perspective, packet loss ratio is a more meaningful d= ata. In most of the time, the absolute number is meaningless to user, espec= ially they do the TWAMP test continuously. They are more care about the rat= io than the absolute number. So adding it makes this model more friendly to customer;

2). From the service layer assurance(SLA) perspective, the packet loss rati= o is a major measures. So with adding packet loss ratio in model, the TWAMP= can work in SLA framework more smoothly.

3). It seems some similar protocol=E2=80=99s YANG model has the same defini= tion, e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99= , https://www.mef.net/Assets/Technical_= Specifications/PDF/MEF_39.pdf.

=
GIM>> Indeed, packet loss more often expressed as packet loss ra= tio rather than as the absolute number. It would be most helpful to hear fr= om network operators if they see introduction of Packet Loss Ratio into the= TWAMP model helpful.

2. Add a new typedef: state-mode. It defines a co= mmon type for stateful/stateless reflector. This type will be used in both = sender session and reflector session.

Consideration:

If the reflector is stateful, the TWAMP light can me= asure more items, e.g. one way packet loss. So for sender, the stats calcul= ation and show is different. When the reflector is stateless, it doesn=E2=80=99t need to calculate the one way packet loss. T= he one way packet loss is invalid and shouldn=E2=80=99t be presented to cus= tomer. When the reflector is stateless, the sender needs to calculate the o= ne way packet loss. And the data should be present to customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree.

GIM>> Yes, = if Session-Sender is aware of the mode corresponding Session-Reflector oper= ates, the sender may avoid calculation of some performance metrics, e.g., o= ne-way packet loss. On the other hand, the orchestrator is aware of the sta= te-mode and should be capable to properly use metrics reported by the Sessi= on-Sender.

3. Add a new typedef: send-mode. This is a new ty= pe for sender session. It makes the sender session can send packet continuo= usly and monitor the network all the time.

Consideration:

The user case is that: the user runs TWAMP light ses= sions to watch links quality continuously. The session number could be very= big. These TWAMP sessions are managed by SLA framework or similar. SLA retrieves the stats from TWAMP periodically, e.g. 15mins. = In other words, all the performance metrics are calculated based on the pac= kets sent/received within 15mins. This makes the calculation become possibl= e. With the periodical stats data, the Network Management software can do further actions if some abnormal st= ats observed.=C2=A0 This is a more general user case in customer site. Whil= e the non-continuous TWAMP sender session is generally used for debugging p= urpose on a link. =C2=A0

GIM>> I thi= nk that support of continuous measurement is in LMAP domain, not for TWAMP = Test data model. To conduct continuous measurement he LMAP Controller, in m= y opinion, programs the Measurement Agent to perform TWAMP Test session wit= h certain set of parameters and repeat it without any interval (interval = =3D 0).

4. Add a new group: packet-loss-statistics. It gr= ouping two packet loss statistics: loss-count and loss-ratio. This group wi= ll be used in RO stats tree.

GIM>&g= t; I'd like to continue discussion.=C2=A0

5. Move leaf dscp out from grouping session-light= -parameters. The leaf dscp is only valid when the dscp-handling-mode is use= -configured-value. A when condition shall be added to it. So it can=E2=80=99t be in this group.

GIM>> I'm concerned that then the model will not be able = to support concurrent TWAMP Test sessions between the same pair of Test Poi= nts (IP address+port number) at different CoS markings.=C2=A0

=

6. Add leaf 'session-packet-send-mode' to= /twamp-light/twamp-light-session-sender/test-session*. This leaf spec= ifies the sender session's packet send mode: continuous or non-continuo= us.

GIM>> As discussed in #3, I = think that it is already part of LMAP YANG model.=C2=A0

=

7. Add leaf 'reflector-light-mode-state' = to /twamp-light/twamp-light-session-sender/test-session*. This leaf in= dicates the the reflector's mode: stateful or stateless. If the reflector's mode is stateful. Two one way packet loss statistics can b= e got: one-way-packet-loss-far-end, one-way-packet-loss-near-end.=

Consideration: =C2=A0

Only valid data should be presented to user. Otherwi= se it could misleading user in some cases.

GIM>> A in response to #2.=C2=A0

8. Modify leaf /twamp-light/twamp-light-sess= ion-sender/test-session*/number-of-packets. Add a 'when' condi= tion to this leaf. When send-mode is 'continuous', the leaf number-= of-packets is meaningless. So add a 'when' condition to limit it.=C2=A0 Besid= es, added a default value =E2=80=9810=E2=80=99 to it. When the send-mode is= 'non-continuous', the session can't work with an empty number-= of-packets.

GIM>> As I've no= ted in #3. Will add default.=C2=A0

9. Add leaf time out to /twamp-light/twamp-light-= session-sender/test-session*. A timeout mechanism is needed when the s= ender session can't get all the reply packets for a long time.

GIM>> Thank you, will add= in the next update.=C2=A0

10. Modify leaf /twamp-light/twamp-light-ses= sion-sender/test-session*/interval. Change the units from =E2=80=98mic= roseconds=E2=80=99 to =E2=80=98milliseconds=E2=80=99. Add a default value 1= 000.

Consideration:

=C2=A0=C2=A0=C2=A0 1). The aim of TWAMP is to measur= e network quality, but not fast failure detection. So a millisecond packet = interval is enough.

=C2=A0=C2=A0=C2=A0 2). Interval is a necessary param= eter for a session. A sender session can't work with an empty packet se= nd interval. So added a default value to it.

GIM>> Thank you. We've made units of interval microseconds in = the last update already. I think that changing to milliseconds may be too r= estrictive, limit use cases for TWAMP Test. Will add default value with the= next update.

11. Add leaf 'dscp' to /twamp-light/twamp= -light-session-sender/test-session*. This is the leaf moved out from g= rouping session-light-parameters.

GIM&= gt;> As noted in response #5, the change may limit ability to run concur= rent TWAMP Test sessions per CoS. I consider that to be valuable mode but w= ould like to hear from network operators if that is indeed useful informati= on.=C2=A0
=

12. Move leaves 'ref-wait', 'reflecto= r-light-mode-state' and 'dscp-handling-mode' from /twamp-light/= twamp-light-session-reflector to /twamp-light/twamp-light-session= -reflector/test-session*. These three attributes should be session specific. Different session could= have different values. They are not common attributes.

=
GIM>> Agree, will make it in the next update.=C2=A0=

13. Add leaf 'dscp' to /twamp-light/twamp= -light-session-reflector/test-session*. This is the leaf moved ou= t from grouping session-light-parameters. Besides the movement, added a 'when' condition to the leaf 'dscp'. This leaf is only v= alid when the dscp-handling-mode is 'use-configured-value'.

=
GIM>> As response to #5.=C2=A0

14. Modify leaf /twamp-light-state/twamp-lig= ht-session-sender-state/test-session-state*/current-stats/number-= of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless.

GIM>> Similar to #3.=C2=A0

<= b>

15. Modify leaf /twamp-light-state/twamp-lig= ht-session-sender-state/test-session-state*/current-stats/interva= l. Change the units from microseconds to milliseconds.

<= /blockquote>
GIM>> I think that microseconds is reasonable.=C2=A0=

16. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/current-stats/. These are the new statistics for stateful reflector.

GIM>> Thank you, will be coming in the next update.= =C2=A0

17. Remove leaf loss-packet in /twamp-light-state= /twamp-light-session-sender-state/test-session-state*/current-stats. The loss packeted is replaced with 'two-way-packet-loss' stated above.

GIM>> Agree.=C2= =A0

18. Modify leaf to /twamp-light-state/twamp-= light-session-sender-state/test-session-state*/history-stats*/int= erval. Change the units from microseconds to milliseconds.

GIM>> I think that will limit applicability of T= WAMP Test.=C2=A0

19. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/history-stats*/. These are the new statistics for stateful reflector.

GIM>> Agree.
=C2=A0

Thanks,

Wei Luo


--94eb2c03b82a0ee907054b2cadcd-- From nobody Mon Mar 20 10:34:49 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15376128796; Mon, 20 Mar 2017 10:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 00O3YpLDvO9C; Mon, 20 Mar 2017 10:34:35 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C585113151A; Mon, 20 Mar 2017 10:34:32 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id x37so137184493ota.2; Mon, 20 Mar 2017 10:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I3ThuwvUgMr7itw4Scto8NgiHSTbKyyBrrt+/rTojgA=; b=lwZOWK6lMvsYIGtdKSq3DCSa5lYPAuBpQTB2T/xOloiyUqL0ofyCrNLPvsjPeAr1YM apsJAfnsgd7eHSjqIlFXRwTmTkpidEG6YYlT4oLaDO0hlG6xipdFDx/rAuIwQBydVfPO M8rBwH/mae74z6kfasP8dbH9vNlDJjNr+na7DV27Tt3UmokjDuQ7sfFDhrCaSVNiyPGq yLRG+Z2YzKamMV4sTuQ+4+f1IedKQhddhJr30gyHGO4X78iuDA6sdKRp1ttHVQJ8auvH Ji7vDWeowO/vxUQhMcEazLmhX20TGMgjTpOn91n6CROmM2AbjdknFQx+i/RSf8ep8tQm MQ+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I3ThuwvUgMr7itw4Scto8NgiHSTbKyyBrrt+/rTojgA=; b=DJ7nGM3Y9s1ncgdXpDWXp0WImF9uFyH8rwqDXhsDJnJmmM33UnwnDqBVgFobVzdwq1 T09MRQ9ThZlNIvkC13wqNqriXnlDm0O8Xm0EbJJQPc74N9Fr3ewlbRaYe623mb3xkgVu vu9tRY0IfV2rN+X+5ub0gCtGTh/gry5enLZolfRzuZnMNgmXIXkfEJ3HQyUzM7a0G3Mk u/0BKvqZCpDUqwJdLBXXKRjLcSaGgWh8G9hJlH5Smbw88zms3yJQ0SyXm3KdvKj1vU/8 +XPxIMIRbyrTUfI/EpGUir04ixrwapxNJAYqaubbZ3NI8gZKd2UeCuhRFFaaCAzq0D+4 8XjQ== X-Gm-Message-State: AFeK/H272nMioSgHHRP6u3v7mUg9eBRtutrtqo7y28JCC5w7VtvyvSnH70t66MF1V+Ew4ffUCgJYt+Lxk2MI3g== X-Received: by 10.157.1.247 with SMTP id e110mr14679849ote.40.1490031272239; Mon, 20 Mar 2017 10:34:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Mon, 20 Mar 2017 10:34:31 -0700 (PDT) In-Reply-To: <148977726052.13049.17633302885192133866@ietfa.amsl.com> References: <148977726052.13049.17633302885192133866@ietfa.amsl.com> From: Greg Mirsky Date: Mon, 20 Mar 2017 12:34:31 -0500 Message-ID: To: Jon Mitchell Cc: ops-dir@ietf.org, draft-ietf-ippm-twamp-time-format.all@ietf.org, "ietf@ietf.org" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03b82aafa92f054b2cf057 Archived-At: Subject: Re: [ippm] Review of draft-ietf-ippm-twamp-time-format-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 20 Mar 2017 17:34:37 -0000 --94eb2c03b82aafa92f054b2cf057 Content-Type: text/plain; charset=UTF-8 Hi Jon, thank you for kind consideration of the draft and thoughtful comment. Indeed, TWAMP Test, and the time stamp format to be used, may be controlled by means other than TWAMP Control, e.g., local configurable knob exposed via data model or CLI. I'll work on text updates for the next version. Regards, Greg On Fri, Mar 17, 2017 at 2:01 PM, Jon Mitchell wrote: > Reviewer: Jon Mitchell > Review result: Has Nits > > 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 with the intent of improving the operational > aspects of the > IETF drafts. Comments that are not addressed in last call may be > included in AD reviews > during the IESG review. Document editors and WG chairs should treat > these comments > just like any other last call comments. > > Ready with Nits - this draft adds the ability to use PTP timestamps as > an alternative to NTP timestamps for active performance measurement > protocols OWAMP and TWAMP. Although this draft does a good job of > discussing interoperability for both sides of the session having or > not having support for this operational capability, in several places > it states that if a send/receiver support this capability it must be > set to 1 in the flags. However, only for TWAMP Light mode, this seems > configurable. This may just be my interpretation, but it probably > should state that local implementations MAY provide a configurable > knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2 even if > the capability is supported by the implementation. > > > --94eb2c03b82aafa92f054b2cf057 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jon,
thank you for kind consideration of the draft = and thoughtful comment. Indeed, TWAMP Test, and the time stamp format to be= used, may be controlled by means other than TWAMP Control, e.g., local con= figurable knob exposed via data model or CLI. I'll work on text updates= for the next version.

Regards,
Greg

On Fri, M= ar 17, 2017 at 2:01 PM, Jon Mitchell <jrmitche@puck.nether.net&= gt; wrote:
Reviewer: Jon Mitchell<= br> Review result: Has Nits

I have reviewed this document as part of the Operational directorate's<= br>
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These
comments were written with the intent of improving the operational
aspects of the
IETF drafts. Comments that are not addressed in last call may be
included in AD reviews
during the IESG review.=C2=A0 Document editors and WG chairs should treat these comments
just like any other last call comments.

Ready with Nits - this draft adds the ability to use PTP timestamps as
an alternative to NTP timestamps for active performance measurement
protocols OWAMP and TWAMP.=C2=A0 Although this draft does a good job of
discussing interoperability for both sides of the session having or
not having support for this operational capability, in several places
it states that if a send/receiver support this capability it must be
set to 1 in the flags.=C2=A0 However, only for TWAMP Light mode, this seems=
configurable.=C2=A0 This may just be my interpretation, but it probably
should state that local implementations MAY provide a configurable
knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2 even if
the capability is supported by the implementation.



--94eb2c03b82aafa92f054b2cf057-- From nobody Tue Mar 21 03:52:52 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BBB1296D8 for ; Tue, 21 Mar 2017 03:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 A1RmvB1-TX5C for ; Tue, 21 Mar 2017 03:52:46 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 7251D1293F3 for ; Tue, 21 Mar 2017 03:52:45 -0700 (PDT) X-AuditID: c1b4fb30-7db199800000628e-c7-58d105fb9ddc Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 6A.24.25230.BF501D85; Tue, 21 Mar 2017 11:52:43 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 21 Mar 2017 11:52:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+F+1xNNUP+Qin2QmQ7gWg+AG7JkavC+w3N96wC986/A=; b=EyN5eZ8mHp7h4xmjUWnszU6KrVzZUxTFKc9IcMTxO1LWAj6wnMm2T34T5VN3AfWHCaCItPzQ/U7buauG9qFag7bJQYIMtMVqaFA+mGnjhIuuV+z18uHz/7oUlhxR2mcPtbDxW6oTm0Wp55RPFegGFRpDXizJdecBFwepdgwONUQ= Received: from HE1PR0701MB2890.eurprd07.prod.outlook.com (10.168.92.139) by HE1PR0701MB2889.eurprd07.prod.outlook.com (10.168.92.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Tue, 21 Mar 2017 10:52:36 +0000 Received: from HE1PR0701MB2890.eurprd07.prod.outlook.com ([10.168.92.139]) by HE1PR0701MB2890.eurprd07.prod.outlook.com ([10.168.92.139]) with mapi id 15.01.0991.011; Tue, 21 Mar 2017 10:52:36 +0000 From: Wei Luo S To: "ippm@ietf.org" CC: "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" Thread-Topic: Some though on draft-mirsky-ippm-twamp-light-yang-07 Thread-Index: AdKfjbtnL0qaxZ/BTSW5iz4J/5svIACD9wOAACJTwJA= Date: Tue, 21 Mar 2017 10:52:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [106.38.5.8] x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2889; 7:ycqeQ4ocNRJVFhUcWlhuK6V9th1buTaIUYRV71WWM1dKZVAP1ufFE/KpNeooe2f5vT4N4OHNLwd07tOwy/azJw/DsQyUm7zp6Iniq5gy34Zj4WkU7Gqi9OMacANlUxRV7FTBERyLPIIScTtT5D7tPbkIm6WLXBrM+zjZaHAs/kmrDmoAbVoiOIIR8+ydEmaa8IPSx1PWKQQV7Ob//vE/TWkPZ9cDqt46aYbfKUxFBWLr4IJ3TBrmNHkPDu991J4BVhR4rYmGFolZt0qfUK5cojzitQDmQ8oRXD9LYY8nG6803DpuwUeyp7cFqrBs6oWF/P2T0SDAprdKWfDnPQ7x9A== x-ms-office365-filtering-correlation-id: 4456778e-da82-452a-ffaf-08d4704862c0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:HE1PR0701MB2889; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(72170088055959)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(20161123555025)(6072148); SRVR:HE1PR0701MB2889; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2889; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(199003)(24454002)(189002)(66654002)(51444003)(377454003)(50986999)(54356999)(76176999)(8936002)(7736002)(189998001)(74316002)(8676002)(1730700003)(81166006)(4326008)(2501003)(25786008)(6436002)(77096006)(606005)(9686003)(53546009)(236005)(5890100001)(230783001)(54896002)(38730400002)(3660700001)(110136004)(5640700003)(6306002)(6246003)(19609705001)(6506006)(55016002)(99286003)(3280700002)(790700001)(6116002)(3846002)(122556002)(102836003)(86362001)(229853002)(7696004)(5660300001)(53936002)(9326002)(7906003)(5630700001)(33656002)(6916009)(2950100002)(2351001)(66066001)(2906002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2889; H:HE1PR0701MB2890.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB28907DC3A4482E290DE00E5AD73D0HE1PR0701MB2890_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2017 10:52:35.9401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2889 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsUyM2K7ru5v1osRBmf3KlvM+/+KxaLnwTtm ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugStjXWs/W8GXRuaKxgkvGBsY33xn6mLk5JAQ MJHY2tbK2sXIxSEksI5RYtfCqewQzglGiS873jOBOCwCvcwSF059Z4bIzGSSmPbyG1TZKUaJ J73T2UGGsQloSLRuOwo2WERAWaLl2x9GEJtZIFdi7Y7PrCC2sICjxNqzS9m6GDmAapwkzt/J hSi3kjg9uR2slUVAVeLQ96tgI3kFEiTWNt9ggdi1nFHiwPf3LCAJToFAiSuXGsEaGAXEJL6f WsMEsUtc4taT+VDPCUgs2XOeGcIWlXj5+B/Yo4wC3YwSH+ZdgyqSk3ixbjLYaxICfcwSy/6c hurwlVjZOocVwo6TOHPuGFRDvsSCU7ug7CiJZa8Ws0E0z2OSmN97jh0iISOxfeosFojEajaJ t5v/MkL8LyVx90onlC0j8eLOXtYJjBqzkJwOYedLPPu3mHkWOAwEJU7OfMIyCxhkzAKaEut3 6UOUKEpM6X7IDmEDQ37OXHZk8QWM7KsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAhPRwS2/ DXYwvnzueIhRgINRiYe34N35CCHWxLLiytxDjBIczEoivKbMFyOEeFMSK6tSi/Lji0pzUosP MUpzsCiJ8zruuxAhJJCeWJKanZpakFoEk2Xi4JRqYAy/Hht1jqH0GEOyMaf08awEl1pzbpHK LTzc08scLx/umabCkf4oNSt2wvFp+0/mz+LPSmpfMFs4S5t1ZsGE314b45e/XrcoPHFXhkLq rOdVVsXt3147XvbKT1+hs1w5pURD3sR3vqFl3rJ1LtLcN8J2Zj74beXdr3GCs++VZ+cnvbBF B0JvKLEUZyQaajEXFScCAP2SAiBAAwAA Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 10:52:50 -0000 --_000_HE1PR0701MB28907DC3A4482E290DE00E5AD73D0HE1PR0701MB2890_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIHJlc3BvbnNlLiBQbGVhc2Ugc2VlIG15 IHJlcGx5IGlubGluZSB0YWdnZWQgW1dFST4+XS4NCg0KUmVnYXJkcywNCldlaSBMdW8NCg0KRnJv bTogR3JlZyBNaXJza3kgW21haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb21dDQpTZW50OiBUdWVz ZGF5LCBNYXJjaCAyMSwgMjAxNyAxOjE2IEFNDQpUbzogV2VpIEx1byBTIDx3ZWkucy5sdW9AZXJp Y3Nzb24uY29tPg0KQ2M6IGlwcG1AaWV0Zi5vcmc7IGRyYWZ0LW1pcnNreS1pcHBtLXR3YW1wLWxp Z2h0LXlhbmdAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBTb21lIHRob3VnaCBvbiBkcmFm dC1taXJza3ktaXBwbS10d2FtcC1saWdodC15YW5nLTA3DQoNCkhpIFdlaSBMdW8sDQptYW55IHRo YW5rcyBmb3IgeW91ciB0aG9yb3VnaCByZXZpZXcgYW5kIHRoZSBtb3N0IGhlbHBmdWwgY29tbWVu dHMgdG8gdGhlIFRXQU1QIExpZ2h0KFRlc3QpIG1vZGVsLiBQbGVhc2UgZmluZCBteSBhbnN3ZXJz LCBub3RlcyBpbi1saW5lIHRhZ2dlZCBHSU0+Pi4NCg0KUmVnYXJkcywNCkdyZWcNCg0KT24gU2F0 LCBNYXIgMTgsIDIwMTcgYXQgNDoyNyBBTSwgV2VpIEx1byBTIDx3ZWkucy5sdW9AZXJpY3Nzb24u Y29tPG1haWx0bzp3ZWkucy5sdW9AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBHcmVnICYgQWRy aWFuLA0KDQpUaGlzIGlzIFdlaSBMdW8gZnJvbSBFcmljc3Nvbi4gSSB3b3JrIG9uIFRXQU1QIGxp Z2h0IGFyZWEgaW4gRXJpY3Nzb24uIFRoZSBjdXJyZW50IFRXQU1QIExpZ2h0IFlBTkcgbW9kZWwg aXMgd2VsbCBkZWZpbmVkLiBUaGFua3MgZm9yIHlvdXIgZ3JlYXQgam9iLg0KQnV0IGJ5IHdvcmtp bmcgY2xvc2VseSB3aXRoIG91ciBjdXN0b21lcnMsIHdlIGdvdCBzb21lIG5ldyB1c2VyIGNhc2Vz IG9uIFRXQU1QIGxpZ2h0LiBJIGJlbGlldmUgdGhlc2UgdXNlciBjYXNlcyBhcmUgdmFsdWFibGUg YW5kIHBvcHVsYXIgZW5vdWdoIHRvIGJlIG1vZGVsZWQgaW4gVFdBTVAgTGlnaHQgWUFORy4gSSBo b3BlIEkgY2FuIGJlIGEgY29udHJpYnV0b3IgIGFuZCBjby13b3JrIHdpdGggeW91IG1vdmUgdGhp cyBkcmFmdCBmb3J3YXJkLg0KSSAgZHJhZnRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBUV0FNUCBs aWdodCBZQU5HIG1vZGVsIGJhc2VkIG9uIHZlcnNpb24gaWV0Zi10d2FtcC1saWdodEAyMDE3LTAy LTEzLnlhbmc8bWFpbHRvOmlldGYtdHdhbXAtbGlnaHRAMjAxNy0wMi0xMy55YW5nPi4gQ291bGQg eW91IHBsZWFzZSBjb21tZW50cyBvbiBpdD8gQW55IGRpc2N1c3Npb24gaXMgd2VsY29tZS4NClRo ZSBkcmFmdCB5YW5nIG1vZGVsIGFuZCB0cmVlIGlzIGF0dGFjaGVkLiBUbyBtYWtlIHlvdSBmaW5k IHRoZSB1cGRhdGVzIHF1aWNrbHksIEkgaGlnaGxpZ2h0ZWQgYWxsIHRoZSB1cGRhdGVzIGluIGZp bGUgaWV0Zi10d2FtcC1saWdodC13ZWlsdW8ucGRmLg0KDQpUaGUgZm9sbG93aW5nIGFyZSB0aGUg bGlzdCBvZiBtYWluIHVwZGF0ZXM6DQoxLiBBZGQgYSBuZXcgdHlwZWRlZjogcGVyY2VudC4gVGhp cyBpcyBhIG5ldyB0eXBlIGRlZmluZWQgZm9yIHBhY2tldCBsb3NzIHJhdGlvLg0KQ29uc2lkZXJh dGlvbjoNCjEpLiBGcm9tIHRoZSBjdXN0b21lciBwZXJzcGVjdGl2ZSwgcGFja2V0IGxvc3MgcmF0 aW8gaXMgYSBtb3JlIG1lYW5pbmdmdWwgZGF0YS4gSW4gbW9zdCBvZiB0aGUgdGltZSwgdGhlIGFi c29sdXRlIG51bWJlciBpcyBtZWFuaW5nbGVzcyB0byB1c2VyLCBlc3BlY2lhbGx5IHRoZXkgZG8g dGhlIFRXQU1QIHRlc3QgY29udGludW91c2x5LiBUaGV5IGFyZSBtb3JlIGNhcmUgYWJvdXQgdGhl IHJhdGlvIHRoYW4gdGhlIGFic29sdXRlIG51bWJlci4gU28gYWRkaW5nIGl0IG1ha2VzIHRoaXMg bW9kZWwgbW9yZSBmcmllbmRseSB0byBjdXN0b21lcjsNCjIpLiBGcm9tIHRoZSBzZXJ2aWNlIGxh eWVyIGFzc3VyYW5jZShTTEEpIHBlcnNwZWN0aXZlLCB0aGUgcGFja2V0IGxvc3MgcmF0aW8gaXMg YSBtYWpvciBtZWFzdXJlcy4gU28gd2l0aCBhZGRpbmcgcGFja2V0IGxvc3MgcmF0aW8gaW4gbW9k ZWwsIHRoZSBUV0FNUCBjYW4gd29yayBpbiBTTEEgZnJhbWV3b3JrIG1vcmUgc21vb3RobHkuDQoz KS4gSXQgc2VlbXMgc29tZSBzaW1pbGFyIHByb3RvY29s4oCZcyBZQU5HIG1vZGVsIGhhcyB0aGUg c2FtZSBkZWZpbml0aW9uLCBlLmcuIOKAmFNlcnZpY2UgT0FNIFBlcmZvcm1hbmNlIE1vbml0b3Jp bmcgWUFORyBNb2R1bGXigJksIGh0dHBzOi8vd3d3Lm1lZi5uZXQvQXNzZXRzL1RlY2huaWNhbF9T cGVjaWZpY2F0aW9ucy9QREYvTUVGXzM5LnBkZi4NCkdJTT4+IEluZGVlZCwgcGFja2V0IGxvc3Mg bW9yZSBvZnRlbiBleHByZXNzZWQgYXMgcGFja2V0IGxvc3MgcmF0aW8gcmF0aGVyIHRoYW4gYXMg dGhlIGFic29sdXRlIG51bWJlci4gSXQgd291bGQgYmUgbW9zdCBoZWxwZnVsIHRvIGhlYXIgZnJv bSBuZXR3b3JrIG9wZXJhdG9ycyBpZiB0aGV5IHNlZSBpbnRyb2R1Y3Rpb24gb2YgUGFja2V0IExv c3MgUmF0aW8gaW50byB0aGUgVFdBTVAgbW9kZWwgaGVscGZ1bC4NCjIuIEFkZCBhIG5ldyB0eXBl ZGVmOiBzdGF0ZS1tb2RlLiBJdCBkZWZpbmVzIGEgY29tbW9uIHR5cGUgZm9yIHN0YXRlZnVsL3N0 YXRlbGVzcyByZWZsZWN0b3IuIFRoaXMgdHlwZSB3aWxsIGJlIHVzZWQgaW4gYm90aCBzZW5kZXIg c2Vzc2lvbiBhbmQgcmVmbGVjdG9yIHNlc3Npb24uDQpDb25zaWRlcmF0aW9uOg0KSWYgdGhlIHJl ZmxlY3RvciBpcyBzdGF0ZWZ1bCwgdGhlIFRXQU1QIGxpZ2h0IGNhbiBtZWFzdXJlIG1vcmUgaXRl bXMsIGUuZy4gb25lIHdheSBwYWNrZXQgbG9zcy4gU28gZm9yIHNlbmRlciwgdGhlIHN0YXRzIGNh bGN1bGF0aW9uIGFuZCBzaG93IGlzIGRpZmZlcmVudC4gV2hlbiB0aGUgcmVmbGVjdG9yIGlzIHN0 YXRlbGVzcywgaXQgZG9lc27igJl0IG5lZWQgdG8gY2FsY3VsYXRlIHRoZSBvbmUgd2F5IHBhY2tl dCBsb3NzLiBUaGUgb25lIHdheSBwYWNrZXQgbG9zcyBpcyBpbnZhbGlkIGFuZCBzaG91bGRu4oCZ dCBiZSBwcmVzZW50ZWQgdG8gY3VzdG9tZXIuIFdoZW4gdGhlIHJlZmxlY3RvciBpcyBzdGF0ZWxl c3MsIHRoZSBzZW5kZXIgbmVlZHMgdG8gY2FsY3VsYXRlIHRoZSBvbmUgd2F5IHBhY2tldCBsb3Nz LiBBbmQgdGhlIGRhdGEgc2hvdWxkIGJlIHByZXNlbnQgdG8gY3VzdG9tZXIuIFNvIHRoaXMgaXMg dXNlZCBhcyBhIOKAmHdoZW7igJkgY29uZGl0aW9uIGluIHRoZSBtb2RlbOKAmXMgUk8gdHJlZS4N CkdJTT4+IFllcywgaWYgU2Vzc2lvbi1TZW5kZXIgaXMgYXdhcmUgb2YgdGhlIG1vZGUgY29ycmVz cG9uZGluZyBTZXNzaW9uLVJlZmxlY3RvciBvcGVyYXRlcywgdGhlIHNlbmRlciBtYXkgYXZvaWQg Y2FsY3VsYXRpb24gb2Ygc29tZSBwZXJmb3JtYW5jZSBtZXRyaWNzLCBlLmcuLCBvbmUtd2F5IHBh Y2tldCBsb3NzLiBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlIG9yY2hlc3RyYXRvciBpcyBhd2FyZSBv ZiB0aGUgc3RhdGUtbW9kZSBhbmQgc2hvdWxkIGJlIGNhcGFibGUgdG8gcHJvcGVybHkgdXNlIG1l dHJpY3MgcmVwb3J0ZWQgYnkgdGhlIFNlc3Npb24tU2VuZGVyLg0KW1dFST4+XSBZZXMsIHRoZSBv cmNoZXN0cmF0b3IgY291bGQga25vdyB0aGF0LiBCdXQgZnJvbSB0aGUgbW9kZWwgc2lkZSwgdGhp cyBpcyBub3QgY29ycmVjdC4gIFRoZSBtb2RlbCBzaG91bGQgcmVwcmVzZW50IHRoZSByaWdodCBi ZWhhdmlvciBhbmQgc2hvdWxkbuKAmXQgZG8gYXNzdW1wdGlvbiBvbiBvcmNoZXN0cmF0b3IuDQoz LiBBZGQgYSBuZXcgdHlwZWRlZjogc2VuZC1tb2RlLiBUaGlzIGlzIGEgbmV3IHR5cGUgZm9yIHNl bmRlciBzZXNzaW9uLiBJdCBtYWtlcyB0aGUgc2VuZGVyIHNlc3Npb24gY2FuIHNlbmQgcGFja2V0 IGNvbnRpbnVvdXNseSBhbmQgbW9uaXRvciB0aGUgbmV0d29yayBhbGwgdGhlIHRpbWUuDQpDb25z aWRlcmF0aW9uOg0KVGhlIHVzZXIgY2FzZSBpcyB0aGF0OiB0aGUgdXNlciBydW5zIFRXQU1QIGxp Z2h0IHNlc3Npb25zIHRvIHdhdGNoIGxpbmtzIHF1YWxpdHkgY29udGludW91c2x5LiBUaGUgc2Vz c2lvbiBudW1iZXIgY291bGQgYmUgdmVyeSBiaWcuIFRoZXNlIFRXQU1QIHNlc3Npb25zIGFyZSBt YW5hZ2VkIGJ5IFNMQSBmcmFtZXdvcmsgb3Igc2ltaWxhci4gU0xBIHJldHJpZXZlcyB0aGUgc3Rh dHMgZnJvbSBUV0FNUCBwZXJpb2RpY2FsbHksIGUuZy4gMTVtaW5zLiBJbiBvdGhlciB3b3Jkcywg YWxsIHRoZSBwZXJmb3JtYW5jZSBtZXRyaWNzIGFyZSBjYWxjdWxhdGVkIGJhc2VkIG9uIHRoZSBw YWNrZXRzIHNlbnQvcmVjZWl2ZWQgd2l0aGluIDE1bWlucy4gVGhpcyBtYWtlcyB0aGUgY2FsY3Vs YXRpb24gYmVjb21lIHBvc3NpYmxlLiBXaXRoIHRoZSBwZXJpb2RpY2FsIHN0YXRzIGRhdGEsIHRo ZSBOZXR3b3JrIE1hbmFnZW1lbnQgc29mdHdhcmUgY2FuIGRvIGZ1cnRoZXIgYWN0aW9ucyBpZiBz b21lIGFibm9ybWFsIHN0YXRzIG9ic2VydmVkLiAgVGhpcyBpcyBhIG1vcmUgZ2VuZXJhbCB1c2Vy IGNhc2UgaW4gY3VzdG9tZXIgc2l0ZS4gV2hpbGUgdGhlIG5vbi1jb250aW51b3VzIFRXQU1QIHNl bmRlciBzZXNzaW9uIGlzIGdlbmVyYWxseSB1c2VkIGZvciBkZWJ1Z2dpbmcgcHVycG9zZSBvbiBh IGxpbmsuDQpHSU0+PiBJIHRoaW5rIHRoYXQgc3VwcG9ydCBvZiBjb250aW51b3VzIG1lYXN1cmVt ZW50IGlzIGluIExNQVAgZG9tYWluLCBub3QgZm9yIFRXQU1QIFRlc3QgZGF0YSBtb2RlbC4gVG8g Y29uZHVjdCBjb250aW51b3VzIG1lYXN1cmVtZW50IGhlIExNQVAgQ29udHJvbGxlciwgaW4gbXkg b3BpbmlvbiwgcHJvZ3JhbXMgdGhlIE1lYXN1cmVtZW50IEFnZW50IHRvIHBlcmZvcm0gVFdBTVAg VGVzdCBzZXNzaW9uIHdpdGggY2VydGFpbiBzZXQgb2YgcGFyYW1ldGVycyBhbmQgcmVwZWF0IGl0 IHdpdGhvdXQgYW55IGludGVydmFsIChpbnRlcnZhbCA9IDApLg0KNC4gQWRkIGEgbmV3IGdyb3Vw OiBwYWNrZXQtbG9zcy1zdGF0aXN0aWNzLiBJdCBncm91cGluZyB0d28gcGFja2V0IGxvc3Mgc3Rh dGlzdGljczogbG9zcy1jb3VudCBhbmQgbG9zcy1yYXRpby4gVGhpcyBncm91cCB3aWxsIGJlIHVz ZWQgaW4gUk8gc3RhdHMgdHJlZS4NCkdJTT4+IEknZCBsaWtlIHRvIGNvbnRpbnVlIGRpc2N1c3Np b24uDQpbV0VJPj5dIE9LLg0KNS4gTW92ZSBsZWFmIGRzY3Agb3V0IGZyb20gZ3JvdXBpbmcgc2Vz c2lvbi1saWdodC1wYXJhbWV0ZXJzLiBUaGUgbGVhZiBkc2NwIGlzIG9ubHkgdmFsaWQgd2hlbiB0 aGUgZHNjcC1oYW5kbGluZy1tb2RlIGlzIHVzZS1jb25maWd1cmVkLXZhbHVlLiBBIHdoZW4gY29u ZGl0aW9uIHNoYWxsIGJlIGFkZGVkIHRvIGl0LiBTbyBpdCBjYW7igJl0IGJlIGluIHRoaXMgZ3Jv dXAuDQpHSU0+PiBJJ20gY29uY2VybmVkIHRoYXQgdGhlbiB0aGUgbW9kZWwgd2lsbCBub3QgYmUg YWJsZSB0byBzdXBwb3J0IGNvbmN1cnJlbnQgVFdBTVAgVGVzdCBzZXNzaW9ucyBiZXR3ZWVuIHRo ZSBzYW1lIHBhaXIgb2YgVGVzdCBQb2ludHMgKElQIGFkZHJlc3MrcG9ydCBudW1iZXIpIGF0IGRp ZmZlcmVudCBDb1MgbWFya2luZ3MuDQpbV0VJPj5dIEFjdHVhbGx5LCBJIGhhdmUgY29uY2VybiBv biB1c2luZyBmaXZlIHR1cGxlKElQIGFkZHJlc3MrcG9ydCBudW1iZXIrZHNjcCkgdG8gaWRlbnRp ZnkgYSBUV0FNUCB0ZXN0IHNlc3Npb24uIFRoZSBEU0NQIGlzIG5vdCBhIGNvbnN0YW50IHZhbHVl IGluIHBhY2tldC4gSXQgY291bGQgYmUgbW9kaWZpZWQgYnkgdGhlIHJvdXRlcnMgaW4gdGhlIHBh dGguIEZvciBleGFtcGxlLCB0aGUgc2VuZGVyIGhhcyB0d28gc2Vzc2lvbnM6IHNlc3Npb24gQeKA mXMgZml2ZSB0dXBsZSBpczogU2lwPTEuMS4xLjEsIERpcD0yLjIuMi4yLCBTcG9ydD01MDAwMCwg RHBvcnQ9NTAwMDEsIERTQ1A9Y3MyLiBTZXNzaW9uIELigJlzIGZpdmUgdHVwbGUgaXM6IFNpcD0x LjEuMS4xLCBEaXA9Mi4yLjIuMiwgU3BvcnQ9NTAwMDAsIERwb3J0PTUwMDAxLCBEU0NQPWNzMy4g VGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIHNlc3Npb24gQSBhbmQgc2Vzc2lvbiBCIGlzIERT Q1AuIElmIHRoZSB0ZXN0IHBhY2tldOKAmXMgRFNDUCBvZiBzZXNzaW9uIEIgaXMgbW9kaWZpZWQg dG8gY3MyIGJ5IGEgcm91dGVyIGluIHRoZSBwYXRoLiBUaGUgZml2ZSB0dXBsZXMgYXJlIGV4YWN0 bHkgdGhlIHNhbWUgZm9yIHJlZmxlY3Rvci4gSXQgY2Fu4oCZdCBkaWZmZXJlbnRpYXRlIHdoaWNo IHBhY2tldCBpcyBmcm9tIHNlc3Npb24gQSwgd2hpY2ggcGFja2V0IGlzIGZyb20gc2Vzc2lvbiBC LiBJdCBjb3VsZCBtZXNzIHRoZSByZWZsZWN0b3LigJlzIHNlc3Npb24gc2VxdWVuY2UgbnVtYmVy LiBBbmQgYWxzbywgdGhlIHNlbmRlciB3aWxsIGJlIG1lc3NlZCBiZWNhdXNlIHRoZSByZWNlaXZl ZCByZXBseSBwYWNrZXTigJlzIGZpdmUgdHVwbGUgYXJlIGV4YWN0bHkgdGhlIHNhbWUuDQpTbyBJ IHRoaW5rIGl04oCZcyBtb3JlIHJlYXNvbmFibGUgdG8gdXNlIGZvdXIgdHVwbGUgdG8gaWRlbnRp ZnkgYSBzZXNzaW9uLg0KNi4gQWRkIGxlYWYgJ3Nlc3Npb24tcGFja2V0LXNlbmQtbW9kZScgdG8g L3R3YW1wLWxpZ2h0L3R3YW1wLWxpZ2h0LXNlc3Npb24tc2VuZGVyL3Rlc3Qtc2Vzc2lvbiouIFRo aXMgbGVhZiBzcGVjaWZpZXMgdGhlIHNlbmRlciBzZXNzaW9uJ3MgcGFja2V0IHNlbmQgbW9kZTog Y29udGludW91cyBvciBub24tY29udGludW91cy4NCkdJTT4+IEFzIGRpc2N1c3NlZCBpbiAjMywg SSB0aGluayB0aGF0IGl0IGlzIGFscmVhZHkgcGFydCBvZiBMTUFQIFlBTkcgbW9kZWwuDQo3LiBB ZGQgbGVhZiAncmVmbGVjdG9yLWxpZ2h0LW1vZGUtc3RhdGUnIHRvIC90d2FtcC1saWdodC90d2Ft cC1saWdodC1zZXNzaW9uLXNlbmRlci90ZXN0LXNlc3Npb24qLiBUaGlzIGxlYWYgaW5kaWNhdGVz IHRoZSB0aGUgcmVmbGVjdG9yJ3MgbW9kZTogc3RhdGVmdWwgb3Igc3RhdGVsZXNzLiBJZiB0aGUg cmVmbGVjdG9yJ3MgbW9kZSBpcyBzdGF0ZWZ1bC4gVHdvIG9uZSB3YXkgcGFja2V0IGxvc3Mgc3Rh dGlzdGljcyBjYW4gYmUgZ290OiBvbmUtd2F5LXBhY2tldC1sb3NzLWZhci1lbmQsIG9uZS13YXkt cGFja2V0LWxvc3MtbmVhci1lbmQuDQpDb25zaWRlcmF0aW9uOg0KT25seSB2YWxpZCBkYXRhIHNo b3VsZCBiZSBwcmVzZW50ZWQgdG8gdXNlci4gT3RoZXJ3aXNlIGl0IGNvdWxkIG1pc2xlYWRpbmcg dXNlciBpbiBzb21lIGNhc2VzLg0KR0lNPj4gQSBpbiByZXNwb25zZSB0byAjMi4NCjguIE1vZGlm eSBsZWFmIC90d2FtcC1saWdodC90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci90ZXN0LXNlc3Np b24qL251bWJlci1vZi1wYWNrZXRzLiBBZGQgYSAnd2hlbicgY29uZGl0aW9uIHRvIHRoaXMgbGVh Zi4gV2hlbiBzZW5kLW1vZGUgaXMgJ2NvbnRpbnVvdXMnLCB0aGUgbGVhZiBudW1iZXItb2YtcGFj a2V0cyBpcyBtZWFuaW5nbGVzcy4gU28gYWRkIGEgJ3doZW4nIGNvbmRpdGlvbiB0byBsaW1pdCBp dC4gIEJlc2lkZXMsIGFkZGVkIGEgZGVmYXVsdCB2YWx1ZSDigJgxMOKAmSB0byBpdC4gV2hlbiB0 aGUgc2VuZC1tb2RlIGlzICdub24tY29udGludW91cycsIHRoZSBzZXNzaW9uIGNhbid0IHdvcmsg d2l0aCBhbiBlbXB0eSBudW1iZXItb2YtcGFja2V0cy4NCkdJTT4+IEFzIEkndmUgbm90ZWQgaW4g IzMuIFdpbGwgYWRkIGRlZmF1bHQuDQo5LiBBZGQgbGVhZiB0aW1lIG91dCB0byAvdHdhbXAtbGln aHQvdHdhbXAtbGlnaHQtc2Vzc2lvbi1zZW5kZXIvdGVzdC1zZXNzaW9uKi4gQSB0aW1lb3V0IG1l Y2hhbmlzbSBpcyBuZWVkZWQgd2hlbiB0aGUgc2VuZGVyIHNlc3Npb24gY2FuJ3QgZ2V0IGFsbCB0 aGUgcmVwbHkgcGFja2V0cyBmb3IgYSBsb25nIHRpbWUuDQpHSU0+PiBUaGFuayB5b3UsIHdpbGwg YWRkIGluIHRoZSBuZXh0IHVwZGF0ZS4NCjEwLiBNb2RpZnkgbGVhZiAvdHdhbXAtbGlnaHQvdHdh bXAtbGlnaHQtc2Vzc2lvbi1zZW5kZXIvdGVzdC1zZXNzaW9uKi9pbnRlcnZhbC4gQ2hhbmdlIHRo ZSB1bml0cyBmcm9tIOKAmG1pY3Jvc2Vjb25kc+KAmSB0byDigJhtaWxsaXNlY29uZHPigJkuIEFk ZCBhIGRlZmF1bHQgdmFsdWUgMTAwMC4NCkNvbnNpZGVyYXRpb246DQogICAgMSkuIFRoZSBhaW0g b2YgVFdBTVAgaXMgdG8gbWVhc3VyZSBuZXR3b3JrIHF1YWxpdHksIGJ1dCBub3QgZmFzdCBmYWls dXJlIGRldGVjdGlvbi4gU28gYSBtaWxsaXNlY29uZCBwYWNrZXQgaW50ZXJ2YWwgaXMgZW5vdWdo Lg0KICAgIDIpLiBJbnRlcnZhbCBpcyBhIG5lY2Vzc2FyeSBwYXJhbWV0ZXIgZm9yIGEgc2Vzc2lv bi4gQSBzZW5kZXIgc2Vzc2lvbiBjYW4ndCB3b3JrIHdpdGggYW4gZW1wdHkgcGFja2V0IHNlbmQg aW50ZXJ2YWwuIFNvIGFkZGVkIGEgZGVmYXVsdCB2YWx1ZSB0byBpdC4NCkdJTT4+IFRoYW5rIHlv dS4gV2UndmUgbWFkZSB1bml0cyBvZiBpbnRlcnZhbCBtaWNyb3NlY29uZHMgaW4gdGhlIGxhc3Qg dXBkYXRlIGFscmVhZHkuIEkgdGhpbmsgdGhhdCBjaGFuZ2luZyB0byBtaWxsaXNlY29uZHMgbWF5 IGJlIHRvbyByZXN0cmljdGl2ZSwgbGltaXQgdXNlIGNhc2VzIGZvciBUV0FNUCBUZXN0LiBXaWxs IGFkZCBkZWZhdWx0IHZhbHVlIHdpdGggdGhlIG5leHQgdXBkYXRlLg0KW1dFST4+XSBTb3JyeSwg SSBkbyBub3Qgc2VlIHRoZSByZWFzb24uIEFyZSB0aGVyZSBhbnkgdXNlciBjYXNlcyB0byB1c2Ug bWljcm9zZWNvbmRzPw0KMTEuIEFkZCBsZWFmICdkc2NwJyB0byAvdHdhbXAtbGlnaHQvdHdhbXAt bGlnaHQtc2Vzc2lvbi1zZW5kZXIvdGVzdC1zZXNzaW9uKi4gVGhpcyBpcyB0aGUgbGVhZiBtb3Zl ZCBvdXQgZnJvbSBncm91cGluZyBzZXNzaW9uLWxpZ2h0LXBhcmFtZXRlcnMuDQpHSU0+PiBBcyBu b3RlZCBpbiByZXNwb25zZSAjNSwgdGhlIGNoYW5nZSBtYXkgbGltaXQgYWJpbGl0eSB0byBydW4g Y29uY3VycmVudCBUV0FNUCBUZXN0IHNlc3Npb25zIHBlciBDb1MuIEkgY29uc2lkZXIgdGhhdCB0 byBiZSB2YWx1YWJsZSBtb2RlIGJ1dCB3b3VsZCBsaWtlIHRvIGhlYXIgZnJvbSBuZXR3b3JrIG9w ZXJhdG9ycyBpZiB0aGF0IGlzIGluZGVlZCB1c2VmdWwgaW5mb3JtYXRpb24uDQoxMi4gTW92ZSBs ZWF2ZXMgJ3JlZi13YWl0JywgJ3JlZmxlY3Rvci1saWdodC1tb2RlLXN0YXRlJyBhbmQgJ2RzY3At aGFuZGxpbmctbW9kZScgZnJvbSAvdHdhbXAtbGlnaHQvdHdhbXAtbGlnaHQtc2Vzc2lvbi1yZWZs ZWN0b3IgdG8gL3R3YW1wLWxpZ2h0L3R3YW1wLWxpZ2h0LXNlc3Npb24tcmVmbGVjdG9yL3Rlc3Qt c2Vzc2lvbiouIFRoZXNlIHRocmVlIGF0dHJpYnV0ZXMgc2hvdWxkIGJlIHNlc3Npb24gc3BlY2lm aWMuIERpZmZlcmVudCBzZXNzaW9uIGNvdWxkIGhhdmUgZGlmZmVyZW50IHZhbHVlcy4gVGhleSBh cmUgbm90IGNvbW1vbiBhdHRyaWJ1dGVzLg0KR0lNPj4gQWdyZWUsIHdpbGwgbWFrZSBpdCBpbiB0 aGUgbmV4dCB1cGRhdGUuDQoxMy4gQWRkIGxlYWYgJ2RzY3AnIHRvIC90d2FtcC1saWdodC90d2Ft cC1saWdodC1zZXNzaW9uLXJlZmxlY3Rvci90ZXN0LXNlc3Npb24qLiBUaGlzIGlzIHRoZSBsZWFm IG1vdmVkIG91dCBmcm9tIGdyb3VwaW5nIHNlc3Npb24tbGlnaHQtcGFyYW1ldGVycy4gQmVzaWRl cyB0aGUgbW92ZW1lbnQsIGFkZGVkIGEgJ3doZW4nIGNvbmRpdGlvbiB0byB0aGUgbGVhZiAnZHNj cCcuIFRoaXMgbGVhZiBpcyBvbmx5IHZhbGlkIHdoZW4gdGhlIGRzY3AtaGFuZGxpbmctbW9kZSBp cyAndXNlLWNvbmZpZ3VyZWQtdmFsdWUnLg0KR0lNPj4gQXMgcmVzcG9uc2UgdG8gIzUuDQoxNC4g TW9kaWZ5IGxlYWYgL3R3YW1wLWxpZ2h0LXN0YXRlL3R3YW1wLWxpZ2h0LXNlc3Npb24tc2VuZGVy LXN0YXRlL3Rlc3Qtc2Vzc2lvbi1zdGF0ZSovY3VycmVudC1zdGF0cy9udW1iZXItb2YtcGFja2V0 cy4gQWRkIGEgJ3doZW4nIGNvbmRpdGlvbiB0byB0aGlzIGxlYWYuIFdoZW4gc2VuZC1tb2RlIGlz ICdjb250aW51b3VzJywgdGhlIGxlYWYgbnVtYmVyLW9mLXBhY2tldHMgaXMgbWVhbmluZ2xlc3Mu DQpHSU0+PiBTaW1pbGFyIHRvICMzLg0KMTUuIE1vZGlmeSBsZWFmIC90d2FtcC1saWdodC1zdGF0 ZS90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci1zdGF0ZS90ZXN0LXNlc3Npb24tc3RhdGUqL2N1 cnJlbnQtc3RhdHMvaW50ZXJ2YWwuIENoYW5nZSB0aGUgdW5pdHMgZnJvbSBtaWNyb3NlY29uZHMg dG8gbWlsbGlzZWNvbmRzLg0KR0lNPj4gSSB0aGluayB0aGF0IG1pY3Jvc2Vjb25kcyBpcyByZWFz b25hYmxlLg0KMTYuIEFkZCBsZWF2ZXMgJ3R3by13YXktcGFja2V0LWxvc3MnLCAnb25lLXdheS1w YWNrZXQtbG9zcy1mYXItZW5kJyBhbmQgJ29uZS13YXktcGFja2V0LWxvc3MtbmVhci1lbmQnIHRv IC90d2FtcC1saWdodC1zdGF0ZS90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci1zdGF0ZS90ZXN0 LXNlc3Npb24tc3RhdGUqL2N1cnJlbnQtc3RhdHMvLiBUaGVzZSBhcmUgdGhlIG5ldyBzdGF0aXN0 aWNzIGZvciBzdGF0ZWZ1bCByZWZsZWN0b3IuDQpHSU0+PiBUaGFuayB5b3UsIHdpbGwgYmUgY29t aW5nIGluIHRoZSBuZXh0IHVwZGF0ZS4NCjE3LiBSZW1vdmUgbGVhZiBsb3NzLXBhY2tldCBpbiAv dHdhbXAtbGlnaHQtc3RhdGUvdHdhbXAtbGlnaHQtc2Vzc2lvbi1zZW5kZXItc3RhdGUvdGVzdC1z ZXNzaW9uLXN0YXRlKi9jdXJyZW50LXN0YXRzLiBUaGUgbG9zcyBwYWNrZXRlZCBpcyByZXBsYWNl ZCB3aXRoICd0d28td2F5LXBhY2tldC1sb3NzJyBzdGF0ZWQgYWJvdmUuDQpHSU0+PiBBZ3JlZS4N CjE4LiBNb2RpZnkgbGVhZiB0byAvdHdhbXAtbGlnaHQtc3RhdGUvdHdhbXAtbGlnaHQtc2Vzc2lv bi1zZW5kZXItc3RhdGUvdGVzdC1zZXNzaW9uLXN0YXRlKi9oaXN0b3J5LXN0YXRzKi9pbnRlcnZh bC4gQ2hhbmdlIHRoZSB1bml0cyBmcm9tIG1pY3Jvc2Vjb25kcyB0byBtaWxsaXNlY29uZHMuDQpH SU0+PiBJIHRoaW5rIHRoYXQgd2lsbCBsaW1pdCBhcHBsaWNhYmlsaXR5IG9mIFRXQU1QIFRlc3Qu DQoxOS4gQWRkIGxlYXZlcyAndHdvLXdheS1wYWNrZXQtbG9zcycsICdvbmUtd2F5LXBhY2tldC1s b3NzLWZhci1lbmQnIGFuZCAnb25lLXdheS1wYWNrZXQtbG9zcy1uZWFyLWVuZCcgdG8gL3R3YW1w LWxpZ2h0LXN0YXRlL3R3YW1wLWxpZ2h0LXNlc3Npb24tc2VuZGVyLXN0YXRlL3Rlc3Qtc2Vzc2lv bi1zdGF0ZSovaGlzdG9yeS1zdGF0cyovLiBUaGVzZSBhcmUgdGhlIG5ldyBzdGF0aXN0aWNzIGZv ciBzdGF0ZWZ1bCByZWZsZWN0b3IuDQpHSU0+PiBBZ3JlZS4NCg0KVGhhbmtzLA0KV2VpIEx1bw0K DQo= --_000_HE1PR0701MB28907DC3A4482E290DE00E5AD73D0HE1PR0701MB2890_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIEdy ZWcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXNwb25zZS4gUGxlYXNl IHNlZSBteSByZXBseSBpbmxpbmUgdGFnZ2VkIFtXRUkmZ3Q7Jmd0O10uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5XZWkgTHVvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBHcmVnIE1pcnNreSBbbWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAyMSwgMjAxNyAxOjE2IEFNPGJy Pg0KPGI+VG86PC9iPiBXZWkgTHVvIFMgJmx0O3dlaS5zLmx1b0Blcmljc3Nvbi5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBpcHBtQGlldGYub3JnOyBkcmFmdC1taXJza3ktaXBwbS10d2FtcC1saWdo dC15YW5nQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBTb21lIHRob3Vn aCBvbiBkcmFmdC1taXJza3ktaXBwbS10d2FtcC1saWdodC15YW5nLTA3PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgV2VpIEx1byw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tYW55IHRoYW5rcyBmb3IgeW91ciB0aG9yb3VnaCByZXZp ZXcgYW5kIHRoZSBtb3N0IGhlbHBmdWwgY29tbWVudHMgdG8gdGhlIFRXQU1QIExpZ2h0KFRlc3Qp IG1vZGVsLiBQbGVhc2UgZmluZCBteSBhbnN3ZXJzLCBub3RlcyBpbi1saW5lIHRhZ2dlZCBHSU0m Z3Q7Jmd0Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFNhdCwgTWFyIDE4LCAyMDE3IGF0IDQ6MjcgQU0sIFdlaSBMdW8gUyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOndlaS5zLmx1b0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj53ZWkucy5s dW9AZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEdyZWcgJmFtcDsgQWRy aWFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBpcyBXZWkgTHVvIGZyb20gRXJp Y3Nzb24uIEkgd29yayBvbiBUV0FNUCBsaWdodCBhcmVhIGluIEVyaWNzc29uLiBUaGUgY3VycmVu dCBUV0FNUCBMaWdodCBZQU5HIG1vZGVsIGlzIHdlbGwgZGVmaW5lZC4gVGhhbmtzIGZvciB5b3Vy IGdyZWF0IGpvYi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CdXQg Ynkgd29ya2luZyBjbG9zZWx5IHdpdGggb3VyIGN1c3RvbWVycywgd2UgZ290IHNvbWUgbmV3IHVz ZXIgY2FzZXMgb24gVFdBTVAgbGlnaHQuIEkgYmVsaWV2ZSB0aGVzZSB1c2VyIGNhc2VzIGFyZSB2 YWx1YWJsZSBhbmQgcG9wdWxhciBlbm91Z2ggdG8gYmUgbW9kZWxlZCBpbiBUV0FNUCBMaWdodCBZ QU5HLg0KIEkgaG9wZSBJIGNhbiBiZSBhIGNvbnRyaWJ1dG9yICZuYnNwO2FuZCBjby13b3JrIHdp dGggeW91IG1vdmUgdGhpcyBkcmFmdCBmb3J3YXJkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JICZuYnNwO2RyYWZ0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUg VFdBTVAgbGlnaHQgWUFORyBtb2RlbCBiYXNlZCBvbiB2ZXJzaW9uDQo8YSBocmVmPSJtYWlsdG86 aWV0Zi10d2FtcC1saWdodEAyMDE3LTAyLTEzLnlhbmciIHRhcmdldD0iX2JsYW5rIj5pZXRmLXR3 YW1wLWxpZ2h0QDIwMTctMDItMTMueWFuZzwvYT4uIENvdWxkIHlvdSBwbGVhc2UgY29tbWVudHMg b24gaXQ/IEFueSBkaXNjdXNzaW9uIGlzIHdlbGNvbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoZSBkcmFmdCB5YW5nIG1vZGVsIGFuZCB0cmVlIGlzIGF0dGFjaGVk LiBUbyBtYWtlIHlvdSBmaW5kIHRoZSB1cGRhdGVzIHF1aWNrbHksIEkNCjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kOnllbGxvdyI+aGlnaGxpZ2h0ZWQ8L3NwYW4+IGFsbCB0aGUgdXBkYXRlcyBpbiBm aWxlIGlldGYtdHdhbXAtbGlnaHQtd2VpbHVvLnBkZi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoZSBmb2xsb3dpbmcgYXJlIHRoZSBsaXN0IG9mIG1haW4gdXBkYXRlczo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MS4gQWRkIGEgbmV3IHR5cGVkZWY6IHBl cmNlbnQuIFRoaXMgaXMgYSBuZXcgdHlwZSBkZWZpbmVkIGZvciBwYWNrZXQgbG9zcyByYXRpby48 L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbnNpZGVyYXRpb246 DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDo5Ljc1 cHQiPg0KMSkuIEZyb20gdGhlIGN1c3RvbWVyIHBlcnNwZWN0aXZlLCBwYWNrZXQgbG9zcyByYXRp byBpcyBhIG1vcmUgbWVhbmluZ2Z1bCBkYXRhLiBJbiBtb3N0IG9mIHRoZSB0aW1lLCB0aGUgYWJz b2x1dGUgbnVtYmVyIGlzIG1lYW5pbmdsZXNzIHRvIHVzZXIsIGVzcGVjaWFsbHkgdGhleSBkbyB0 aGUgVFdBTVAgdGVzdCBjb250aW51b3VzbHkuIFRoZXkgYXJlIG1vcmUgY2FyZSBhYm91dCB0aGUg cmF0aW8gdGhhbiB0aGUgYWJzb2x1dGUgbnVtYmVyLiBTbw0KIGFkZGluZyBpdCBtYWtlcyB0aGlz IG1vZGVsIG1vcmUgZnJpZW5kbHkgdG8gY3VzdG9tZXI7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50OjkuNzVwdCI+DQoyKS4gRnJvbSB0aGUgc2Vydmlj ZSBsYXllciBhc3N1cmFuY2UoU0xBKSBwZXJzcGVjdGl2ZSwgdGhlIHBhY2tldCBsb3NzIHJhdGlv IGlzIGEgbWFqb3IgbWVhc3VyZXMuIFNvIHdpdGggYWRkaW5nIHBhY2tldCBsb3NzIHJhdGlvIGlu IG1vZGVsLCB0aGUgVFdBTVAgY2FuIHdvcmsgaW4gU0xBIGZyYW1ld29yayBtb3JlIHNtb290aGx5 Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6OS43 NXB0Ij4NCjMpLiBJdCBzZWVtcyBzb21lIHNpbWlsYXIgcHJvdG9jb2zigJlzIFlBTkcgbW9kZWwg aGFzIHRoZSBzYW1lIGRlZmluaXRpb24sIGUuZy4g4oCYU2VydmljZSBPQU0gUGVyZm9ybWFuY2Ug TW9uaXRvcmluZyBZQU5HIE1vZHVsZeKAmSwNCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lm1lZi5uZXQv QXNzZXRzL1RlY2huaWNhbF9TcGVjaWZpY2F0aW9ucy9QREYvTUVGXzM5LnBkZiIgdGFyZ2V0PSJf YmxhbmsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPmh0dHBzOi8vd3d3Lm1lZi5u ZXQvQXNzZXRzL1RlY2huaWNhbF9TcGVjaWZpY2F0aW9ucy9QREYvTUVGXzM5LnBkZjwvc3Bhbj48 L2E+LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU0mZ3Q7Jmd0OyBJbmRlZWQsIHBhY2tldCBsb3NzIG1v cmUgb2Z0ZW4gZXhwcmVzc2VkIGFzIHBhY2tldCBsb3NzIHJhdGlvIHJhdGhlciB0aGFuIGFzIHRo ZSBhYnNvbHV0ZSBudW1iZXIuIEl0IHdvdWxkIGJlIG1vc3QgaGVscGZ1bCB0byBoZWFyIGZyb20g bmV0d29yayBvcGVyYXRvcnMgaWYgdGhleSBzZWUgaW50cm9kdWN0aW9uIG9mIFBhY2tldCBMb3Nz IFJhdGlvIGludG8gdGhlIFRXQU1QIG1vZGVsIGhlbHBmdWwuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ Mi4gQWRkIGEgbmV3IHR5cGVkZWY6IHN0YXRlLW1vZGUuIEl0IGRlZmluZXMgYSBjb21tb24gdHlw ZSBmb3Igc3RhdGVmdWwvc3RhdGVsZXNzIHJlZmxlY3Rvci4gVGhpcyB0eXBlIHdpbGwgYmUgdXNl ZCBpbiBib3RoIHNlbmRlciBzZXNzaW9uIGFuZCByZWZsZWN0b3Igc2Vzc2lvbi48L2I+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbnNpZGVyYXRpb246DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgdGhlIHJlZmxlY3RvciBpcyBzdGF0 ZWZ1bCwgdGhlIFRXQU1QIGxpZ2h0IGNhbiBtZWFzdXJlIG1vcmUgaXRlbXMsIGUuZy4gb25lIHdh eSBwYWNrZXQgbG9zcy4gU28gZm9yIHNlbmRlciwgdGhlIHN0YXRzIGNhbGN1bGF0aW9uIGFuZCBz aG93IGlzIGRpZmZlcmVudC4gV2hlbiB0aGUgcmVmbGVjdG9yIGlzDQogc3RhdGVsZXNzLCBpdCBk b2VzbuKAmXQgbmVlZCB0byBjYWxjdWxhdGUgdGhlIG9uZSB3YXkgcGFja2V0IGxvc3MuIFRoZSBv bmUgd2F5IHBhY2tldCBsb3NzIGlzIGludmFsaWQgYW5kIHNob3VsZG7igJl0IGJlIHByZXNlbnRl ZCB0byBjdXN0b21lci4gV2hlbiB0aGUgcmVmbGVjdG9yIGlzIHN0YXRlbGVzcywgdGhlIHNlbmRl ciBuZWVkcyB0byBjYWxjdWxhdGUgdGhlIG9uZSB3YXkgcGFja2V0IGxvc3MuIEFuZCB0aGUgZGF0 YSBzaG91bGQgYmUgcHJlc2VudA0KIHRvIGN1c3RvbWVyLiBTbyB0aGlzIGlzIHVzZWQgYXMgYSDi gJh3aGVu4oCZIGNvbmRpdGlvbiBpbiB0aGUgbW9kZWzigJlzIFJPIHRyZWUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkdJTSZndDsmZ3Q7IFllcywgaWYgU2Vzc2lvbi1TZW5kZXIgaXMgYXdhcmUgb2YgdGhl IG1vZGUgY29ycmVzcG9uZGluZyBTZXNzaW9uLVJlZmxlY3RvciBvcGVyYXRlcywgdGhlIHNlbmRl ciBtYXkgYXZvaWQgY2FsY3VsYXRpb24gb2Ygc29tZSBwZXJmb3JtYW5jZSBtZXRyaWNzLCBlLmcu LCBvbmUtd2F5IHBhY2tldCBsb3NzLiBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlIG9yY2hlc3RyYXRv ciBpcyBhd2FyZSBvZiB0aGUgc3RhdGUtbW9kZQ0KIGFuZCBzaG91bGQgYmUgY2FwYWJsZSB0byBw cm9wZXJseSB1c2UgbWV0cmljcyByZXBvcnRlZCBieSB0aGUgU2Vzc2lvbi1TZW5kZXIuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bV0VJJmd0OyZndDtdIFllcywgdGhlIG9y Y2hlc3RyYXRvciBjb3VsZCBrbm93IHRoYXQuIEJ1dCBmcm9tIHRoZSBtb2RlbCBzaWRlLCB0aGlz IGlzIG5vdCBjb3JyZWN0LiAmbmJzcDtUaGUgbW9kZWwgc2hvdWxkIHJlcHJlc2VudCB0aGUgcmln aHQgYmVoYXZpb3IgYW5kIHNob3VsZG7igJl0IGRvIGFzc3VtcHRpb24gb24gb3JjaGVzdHJhdG9y Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjMuIEFkZCBhIG5ldyB0eXBlZGVmOiBzZW5k LW1vZGUuIFRoaXMgaXMgYSBuZXcgdHlwZSBmb3Igc2VuZGVyIHNlc3Npb24uIEl0IG1ha2VzIHRo ZSBzZW5kZXIgc2Vzc2lvbiBjYW4gc2VuZCBwYWNrZXQgY29udGludW91c2x5IGFuZCBtb25pdG9y IHRoZSBuZXR3b3JrIGFsbCB0aGUgdGltZS48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkNvbnNpZGVyYXRpb246DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhlIHVzZXIgY2FzZSBpcyB0aGF0OiB0aGUgdXNlciBydW5zIFRXQU1QIGxp Z2h0IHNlc3Npb25zIHRvIHdhdGNoIGxpbmtzIHF1YWxpdHkgY29udGludW91c2x5LiBUaGUgc2Vz c2lvbiBudW1iZXIgY291bGQgYmUgdmVyeSBiaWcuIFRoZXNlIFRXQU1QIHNlc3Npb25zIGFyZSBt YW5hZ2VkIGJ5IFNMQSBmcmFtZXdvcmsNCiBvciBzaW1pbGFyLiBTTEEgcmV0cmlldmVzIHRoZSBz dGF0cyBmcm9tIFRXQU1QIHBlcmlvZGljYWxseSwgZS5nLiAxNW1pbnMuIEluIG90aGVyIHdvcmRz LCBhbGwgdGhlIHBlcmZvcm1hbmNlIG1ldHJpY3MgYXJlIGNhbGN1bGF0ZWQgYmFzZWQgb24gdGhl IHBhY2tldHMgc2VudC9yZWNlaXZlZCB3aXRoaW4gMTVtaW5zLiBUaGlzIG1ha2VzIHRoZSBjYWxj dWxhdGlvbiBiZWNvbWUgcG9zc2libGUuIFdpdGggdGhlIHBlcmlvZGljYWwgc3RhdHMgZGF0YSwN CiB0aGUgTmV0d29yayBNYW5hZ2VtZW50IHNvZnR3YXJlIGNhbiBkbyBmdXJ0aGVyIGFjdGlvbnMg aWYgc29tZSBhYm5vcm1hbCBzdGF0cyBvYnNlcnZlZC4mbmJzcDsgVGhpcyBpcyBhIG1vcmUgZ2Vu ZXJhbCB1c2VyIGNhc2UgaW4gY3VzdG9tZXIgc2l0ZS4gV2hpbGUgdGhlIG5vbi1jb250aW51b3Vz IFRXQU1QIHNlbmRlciBzZXNzaW9uIGlzIGdlbmVyYWxseSB1c2VkIGZvciBkZWJ1Z2dpbmcgcHVy cG9zZSBvbiBhIGxpbmsuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU0mZ3Q7Jmd0OyBJIHRo aW5rIHRoYXQgc3VwcG9ydCBvZiBjb250aW51b3VzIG1lYXN1cmVtZW50IGlzIGluIExNQVAgZG9t YWluLCBub3QgZm9yIFRXQU1QIFRlc3QgZGF0YSBtb2RlbC4gVG8gY29uZHVjdCBjb250aW51b3Vz IG1lYXN1cmVtZW50IGhlIExNQVAgQ29udHJvbGxlciwgaW4gbXkgb3BpbmlvbiwgcHJvZ3JhbXMg dGhlIE1lYXN1cmVtZW50IEFnZW50IHRvIHBlcmZvcm0gVFdBTVAgVGVzdCBzZXNzaW9uIHdpdGgN CiBjZXJ0YWluIHNldCBvZiBwYXJhbWV0ZXJzIGFuZCByZXBlYXQgaXQgd2l0aG91dCBhbnkgaW50 ZXJ2YWwgKGludGVydmFsID0gMCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+NC4gQWRkIGEgbmV3IGdy b3VwOiBwYWNrZXQtbG9zcy1zdGF0aXN0aWNzLiBJdCBncm91cGluZyB0d28gcGFja2V0IGxvc3Mg c3RhdGlzdGljczogbG9zcy1jb3VudCBhbmQgbG9zcy1yYXRpby4gVGhpcyBncm91cCB3aWxsIGJl IHVzZWQgaW4gUk8gc3RhdHMgdHJlZS48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdJTSZndDsmZ3Q7 IEknZCBsaWtlIHRvIGNvbnRpbnVlIGRpc2N1c3Npb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltXRUkmZ3Q7Jmd0O10gT0suPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjUuIE1vdmUgbGVhZiBkc2NwIG91dCBmcm9tIGdyb3Vw aW5nIHNlc3Npb24tbGlnaHQtcGFyYW1ldGVycy4gVGhlIGxlYWYgZHNjcCBpcyBvbmx5IHZhbGlk IHdoZW4gdGhlIGRzY3AtaGFuZGxpbmctbW9kZSBpcyB1c2UtY29uZmlndXJlZC12YWx1ZS4gQSB3 aGVuIGNvbmRpdGlvbiBzaGFsbCBiZSBhZGRlZA0KIHRvIGl0LiBTbyBpdCBjYW7igJl0IGJlIGlu IHRoaXMgZ3JvdXAuPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU0mZ3Q7Jmd0OyBJJ20gY29uY2Vy bmVkIHRoYXQgdGhlbiB0aGUgbW9kZWwgd2lsbCBub3QgYmUgYWJsZSB0byBzdXBwb3J0IGNvbmN1 cnJlbnQgVFdBTVAgVGVzdCBzZXNzaW9ucyBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2YgVGVzdCBQ b2ludHMgKElQIGFkZHJlc3MmIzQzO3BvcnQgbnVtYmVyKSBhdCBkaWZmZXJlbnQgQ29TIG1hcmtp bmdzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1dFSSZndDsm Z3Q7XSBBY3R1YWxseSwgSSBoYXZlIGNvbmNlcm4gb24gdXNpbmcgZml2ZSB0dXBsZShJUCBhZGRy ZXNzJiM0Mztwb3J0IG51bWJlciYjNDM7ZHNjcCkgdG8gaWRlbnRpZnkgYSBUV0FNUCB0ZXN0IHNl c3Npb24uIFRoZSBEU0NQIGlzIG5vdCBhIGNvbnN0YW50IHZhbHVlIGluIHBhY2tldC4gSXQgY291 bGQgYmUgbW9kaWZpZWQgYnkgdGhlIHJvdXRlcnMNCiBpbiB0aGUgcGF0aC4gRm9yIGV4YW1wbGUs IHRoZSBzZW5kZXIgaGFzIHR3byBzZXNzaW9uczogc2Vzc2lvbiBB4oCZcyBmaXZlIHR1cGxlIGlz OiBTaXA9MS4xLjEuMSwgRGlwPTIuMi4yLjIsIFNwb3J0PTUwMDAwLCBEcG9ydD01MDAwMSwgRFND UD1jczIuIFNlc3Npb24gQuKAmXMgZml2ZSB0dXBsZSBpczogU2lwPTEuMS4xLjEsIERpcD0yLjIu Mi4yLCBTcG9ydD01MDAwMCwgRHBvcnQ9NTAwMDEsIERTQ1A9Y3MzLiBUaGUgb25seSBkaWZmZXJl bmNlIGJldHdlZW4NCiBzZXNzaW9uIEEgYW5kIHNlc3Npb24gQiBpcyBEU0NQLiBJZiB0aGUgdGVz dCBwYWNrZXTigJlzIERTQ1Agb2Ygc2Vzc2lvbiBCIGlzIG1vZGlmaWVkIHRvIGNzMiBieSBhIHJv dXRlciBpbiB0aGUgcGF0aC4gVGhlIGZpdmUgdHVwbGVzIGFyZSBleGFjdGx5IHRoZSBzYW1lIGZv ciByZWZsZWN0b3IuIEl0IGNhbuKAmXQgZGlmZmVyZW50aWF0ZSB3aGljaCBwYWNrZXQgaXMgZnJv bSBzZXNzaW9uIEEsIHdoaWNoIHBhY2tldCBpcyBmcm9tIHNlc3Npb24gQi4gSXQNCiBjb3VsZCBt ZXNzIHRoZSByZWZsZWN0b3LigJlzIHNlc3Npb24gc2VxdWVuY2UgbnVtYmVyLiBBbmQgYWxzbywg dGhlIHNlbmRlciB3aWxsIGJlIG1lc3NlZCBiZWNhdXNlIHRoZSByZWNlaXZlZCByZXBseSBwYWNr ZXTigJlzIGZpdmUgdHVwbGUgYXJlIGV4YWN0bHkgdGhlIHNhbWUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U28gSSB0aGluayBpdOKAmXMgbW9yZSByZWFzb25h YmxlIHRvIHVzZSBmb3VyIHR1cGxlIHRvIGlkZW50aWZ5IGEgc2Vzc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+Ni4gQWRkIGxlYWYgJ3Nlc3Npb24tcGFja2V0LXNlbmQtbW9kZScgdG8g L3R3YW1wLWxpZ2h0L3R3YW1wLWxpZ2h0LXNlc3Npb24tc2VuZGVyL3Rlc3Qtc2Vzc2lvbiouIFRo aXMgbGVhZiBzcGVjaWZpZXMgdGhlIHNlbmRlciBzZXNzaW9uJ3MgcGFja2V0IHNlbmQgbW9kZTog Y29udGludW91cyBvciBub24tY29udGludW91cy48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdJTSZn dDsmZ3Q7IEFzIGRpc2N1c3NlZCBpbiAjMywgSSB0aGluayB0aGF0IGl0IGlzIGFscmVhZHkgcGFy dCBvZiBMTUFQIFlBTkcgbW9kZWwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+Ny4gQWRkIGxl YWYgJ3JlZmxlY3Rvci1saWdodC1tb2RlLXN0YXRlJyB0byAvdHdhbXAtbGlnaHQvdHdhbXAtbGln aHQtc2Vzc2lvbi1zZW5kZXIvdGVzdC1zZXNzaW9uKi4gVGhpcyBsZWFmIGluZGljYXRlcyB0aGUg dGhlIHJlZmxlY3RvcidzIG1vZGU6IHN0YXRlZnVsIG9yIHN0YXRlbGVzcy4gSWYgdGhlDQogcmVm bGVjdG9yJ3MgbW9kZSBpcyBzdGF0ZWZ1bC4gVHdvIG9uZSB3YXkgcGFja2V0IGxvc3Mgc3RhdGlz dGljcyBjYW4gYmUgZ290OiBvbmUtd2F5LXBhY2tldC1sb3NzLWZhci1lbmQsIG9uZS13YXktcGFj a2V0LWxvc3MtbmVhci1lbmQuPC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Db25zaWRlcmF0aW9uOg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T25seSB2YWxpZCBk YXRhIHNob3VsZCBiZSBwcmVzZW50ZWQgdG8gdXNlci4gT3RoZXJ3aXNlIGl0IGNvdWxkIG1pc2xl YWRpbmcgdXNlciBpbiBzb21lIGNhc2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU0mZ3Q7Jmd0OyBB IGluIHJlc3BvbnNlIHRvICMyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjguIE1vZGlmeSBs ZWFmIC90d2FtcC1saWdodC90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci90ZXN0LXNlc3Npb24q L251bWJlci1vZi1wYWNrZXRzLiBBZGQgYSAnd2hlbicgY29uZGl0aW9uIHRvIHRoaXMgbGVhZi4g V2hlbiBzZW5kLW1vZGUgaXMgJ2NvbnRpbnVvdXMnLCB0aGUgbGVhZiBudW1iZXItb2YtcGFja2V0 cw0KIGlzIG1lYW5pbmdsZXNzLiBTbyBhZGQgYSAnd2hlbicgY29uZGl0aW9uIHRvIGxpbWl0IGl0 LiZuYnNwOyBCZXNpZGVzLCBhZGRlZCBhIGRlZmF1bHQgdmFsdWUg4oCYMTDigJkgdG8gaXQuIFdo ZW4gdGhlIHNlbmQtbW9kZSBpcyAnbm9uLWNvbnRpbnVvdXMnLCB0aGUgc2Vzc2lvbiBjYW4ndCB3 b3JrIHdpdGggYW4gZW1wdHkgbnVtYmVyLW9mLXBhY2tldHMuPC9iPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5HSU0mZ3Q7Jmd0OyBBcyBJJ3ZlIG5vdGVkIGluICMzLiBXaWxsIGFkZCBkZWZhdWx0LiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjkuIEFkZCBsZWFmIHRpbWUgb3V0IHRvIC90d2FtcC1saWdo dC90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci90ZXN0LXNlc3Npb24qLiBBIHRpbWVvdXQgbWVj aGFuaXNtIGlzIG5lZWRlZCB3aGVuIHRoZSBzZW5kZXIgc2Vzc2lvbiBjYW4ndCBnZXQgYWxsIHRo ZSByZXBseSBwYWNrZXRzIGZvciBhIGxvbmcNCiB0aW1lLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ R0lNJmd0OyZndDsgVGhhbmsgeW91LCB3aWxsIGFkZCBpbiB0aGUgbmV4dCB1cGRhdGUuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+MTAuIE1vZGlmeSBsZWFmIC90d2FtcC1saWdodC90d2FtcC1s aWdodC1zZXNzaW9uLXNlbmRlci90ZXN0LXNlc3Npb24qL2ludGVydmFsLiBDaGFuZ2UgdGhlIHVu aXRzIGZyb20g4oCYbWljcm9zZWNvbmRz4oCZIHRvIOKAmG1pbGxpc2Vjb25kc+KAmS4gQWRkIGEg ZGVmYXVsdCB2YWx1ZSAxMDAwLg0KPC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Db25zaWRlcmF0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsgMSkuIFRoZSBhaW0gb2YgVFdBTVAgaXMgdG8gbWVhc3Vy ZSBuZXR3b3JrIHF1YWxpdHksIGJ1dCBub3QgZmFzdCBmYWlsdXJlIGRldGVjdGlvbi4gU28gYSBt aWxsaXNlY29uZCBwYWNrZXQgaW50ZXJ2YWwgaXMgZW5vdWdoLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsgMikuIEludGVydmFsIGlzIGEg bmVjZXNzYXJ5IHBhcmFtZXRlciBmb3IgYSBzZXNzaW9uLiBBIHNlbmRlciBzZXNzaW9uIGNhbid0 IHdvcmsgd2l0aCBhbiBlbXB0eSBwYWNrZXQgc2VuZCBpbnRlcnZhbC4gU28gYWRkZWQgYSBkZWZh dWx0IHZhbHVlIHRvIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU0mZ3Q7Jmd0OyBUaGFuayB5b3Uu IFdlJ3ZlIG1hZGUgdW5pdHMgb2YgaW50ZXJ2YWwgbWljcm9zZWNvbmRzIGluIHRoZSBsYXN0IHVw ZGF0ZSBhbHJlYWR5LiBJIHRoaW5rIHRoYXQgY2hhbmdpbmcgdG8gbWlsbGlzZWNvbmRzIG1heSBi ZSB0b28gcmVzdHJpY3RpdmUsIGxpbWl0IHVzZSBjYXNlcyBmb3IgVFdBTVAgVGVzdC4gV2lsbCBh ZGQgZGVmYXVsdCB2YWx1ZSB3aXRoIHRoZSBuZXh0IHVwZGF0ZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPltXRUkmZ3Q7Jmd0O10gU29ycnksIEkgZG8gbm90IHNlZSB0aGUg cmVhc29uLiBBcmUgdGhlcmUgYW55IHVzZXIgY2FzZXMgdG8gdXNlIG1pY3Jvc2Vjb25kcz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MTEuIEFkZCBsZWFmICdkc2NwJyB0byAvdHdhbXAtbGln aHQvdHdhbXAtbGlnaHQtc2Vzc2lvbi1zZW5kZXIvdGVzdC1zZXNzaW9uKi4gVGhpcyBpcyB0aGUg bGVhZiBtb3ZlZCBvdXQgZnJvbSBncm91cGluZyBzZXNzaW9uLWxpZ2h0LXBhcmFtZXRlcnMuPC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU0mZ3Q7Jmd0OyBBcyBub3RlZCBpbiByZXNwb25zZSAjNSwg dGhlIGNoYW5nZSBtYXkgbGltaXQgYWJpbGl0eSB0byBydW4gY29uY3VycmVudCBUV0FNUCBUZXN0 IHNlc3Npb25zIHBlciBDb1MuIEkgY29uc2lkZXIgdGhhdCB0byBiZSB2YWx1YWJsZSBtb2RlIGJ1 dCB3b3VsZCBsaWtlIHRvIGhlYXIgZnJvbSBuZXR3b3JrIG9wZXJhdG9ycyBpZiB0aGF0IGlzIGlu ZGVlZCB1c2VmdWwgaW5mb3JtYXRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MTIuIE1v dmUgbGVhdmVzICdyZWYtd2FpdCcsICdyZWZsZWN0b3ItbGlnaHQtbW9kZS1zdGF0ZScgYW5kICdk c2NwLWhhbmRsaW5nLW1vZGUnIGZyb20gL3R3YW1wLWxpZ2h0L3R3YW1wLWxpZ2h0LXNlc3Npb24t cmVmbGVjdG9yIHRvIC90d2FtcC1saWdodC90d2FtcC1saWdodC1zZXNzaW9uLXJlZmxlY3Rvci90 ZXN0LXNlc3Npb24qLg0KIFRoZXNlIHRocmVlIGF0dHJpYnV0ZXMgc2hvdWxkIGJlIHNlc3Npb24g c3BlY2lmaWMuIERpZmZlcmVudCBzZXNzaW9uIGNvdWxkIGhhdmUgZGlmZmVyZW50IHZhbHVlcy4g VGhleSBhcmUgbm90IGNvbW1vbiBhdHRyaWJ1dGVzLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R0lN Jmd0OyZndDsgQWdyZWUsIHdpbGwgbWFrZSBpdCBpbiB0aGUgbmV4dCB1cGRhdGUuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+MTMuIEFkZCBsZWFmICdkc2NwJyB0byAvdHdhbXAtbGlnaHQvdHdh bXAtbGlnaHQtc2Vzc2lvbi1yZWZsZWN0b3IvdGVzdC1zZXNzaW9uKi4gVGhpcyBpcyB0aGUgbGVh ZiBtb3ZlZCBvdXQgZnJvbSBncm91cGluZyBzZXNzaW9uLWxpZ2h0LXBhcmFtZXRlcnMuIEJlc2lk ZXMgdGhlIG1vdmVtZW50LCBhZGRlZA0KIGEgJ3doZW4nIGNvbmRpdGlvbiB0byB0aGUgbGVhZiAn ZHNjcCcuIFRoaXMgbGVhZiBpcyBvbmx5IHZhbGlkIHdoZW4gdGhlIGRzY3AtaGFuZGxpbmctbW9k ZSBpcyAndXNlLWNvbmZpZ3VyZWQtdmFsdWUnLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R0lNJmd0 OyZndDsgQXMgcmVzcG9uc2UgdG8gIzUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MTQuIE1v ZGlmeSBsZWFmIC90d2FtcC1saWdodC1zdGF0ZS90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci1z dGF0ZS90ZXN0LXNlc3Npb24tc3RhdGUqL2N1cnJlbnQtc3RhdHMvbnVtYmVyLW9mLXBhY2tldHMu IEFkZCBhICd3aGVuJyBjb25kaXRpb24gdG8gdGhpcyBsZWFmLiBXaGVuIHNlbmQtbW9kZSBpcw0K ICdjb250aW51b3VzJywgdGhlIGxlYWYgbnVtYmVyLW9mLXBhY2tldHMgaXMgbWVhbmluZ2xlc3Mu PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU0mZ3Q7Jmd0OyBTaW1pbGFyIHRvICMzLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjE1LiBNb2RpZnkgbGVhZiAvdHdhbXAtbGlnaHQtc3RhdGUvdHdh bXAtbGlnaHQtc2Vzc2lvbi1zZW5kZXItc3RhdGUvdGVzdC1zZXNzaW9uLXN0YXRlKi9jdXJyZW50 LXN0YXRzL2ludGVydmFsLiBDaGFuZ2UgdGhlIHVuaXRzIGZyb20gbWljcm9zZWNvbmRzIHRvIG1p bGxpc2Vjb25kcy48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdJTSZndDsmZ3Q7IEkgdGhpbmsgdGhh dCBtaWNyb3NlY29uZHMgaXMgcmVhc29uYWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj4x Ni4gQWRkIGxlYXZlcyAndHdvLXdheS1wYWNrZXQtbG9zcycsICdvbmUtd2F5LXBhY2tldC1sb3Nz LWZhci1lbmQnIGFuZCAnb25lLXdheS1wYWNrZXQtbG9zcy1uZWFyLWVuZCcgdG8gL3R3YW1wLWxp Z2h0LXN0YXRlL3R3YW1wLWxpZ2h0LXNlc3Npb24tc2VuZGVyLXN0YXRlL3Rlc3Qtc2Vzc2lvbi1z dGF0ZSovY3VycmVudC1zdGF0cy8uDQogVGhlc2UgYXJlIHRoZSBuZXcgc3RhdGlzdGljcyBmb3Ig c3RhdGVmdWwgcmVmbGVjdG9yLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R0lNJmd0OyZndDsgVGhh bmsgeW91LCB3aWxsIGJlIGNvbWluZyBpbiB0aGUgbmV4dCB1cGRhdGUuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+MTcuIFJlbW92ZSBsZWFmIGxvc3MtcGFja2V0IGluIC90d2FtcC1saWdodC1z dGF0ZS90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci1zdGF0ZS90ZXN0LXNlc3Npb24tc3RhdGUq L2N1cnJlbnQtc3RhdHMuIFRoZSBsb3NzIHBhY2tldGVkIGlzIHJlcGxhY2VkIHdpdGggJ3R3by13 YXktcGFja2V0LWxvc3MnDQogc3RhdGVkIGFib3ZlLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R0lN Jmd0OyZndDsgQWdyZWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MTguIE1vZGlmeSBsZWFm IHRvIC90d2FtcC1saWdodC1zdGF0ZS90d2FtcC1saWdodC1zZXNzaW9uLXNlbmRlci1zdGF0ZS90 ZXN0LXNlc3Npb24tc3RhdGUqL2hpc3Rvcnktc3RhdHMqL2ludGVydmFsLiBDaGFuZ2UgdGhlIHVu aXRzIGZyb20gbWljcm9zZWNvbmRzIHRvIG1pbGxpc2Vjb25kcy48L2I+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkdJTSZndDsmZ3Q7IEkgdGhpbmsgdGhhdCB3aWxsIGxpbWl0IGFwcGxpY2FiaWxpdHkgb2Yg VFdBTVAgVGVzdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj4xOS4gQWRkIGxlYXZlcyAndHdv LXdheS1wYWNrZXQtbG9zcycsICdvbmUtd2F5LXBhY2tldC1sb3NzLWZhci1lbmQnIGFuZCAnb25l LXdheS1wYWNrZXQtbG9zcy1uZWFyLWVuZCcgdG8gL3R3YW1wLWxpZ2h0LXN0YXRlL3R3YW1wLWxp Z2h0LXNlc3Npb24tc2VuZGVyLXN0YXRlL3Rlc3Qtc2Vzc2lvbi1zdGF0ZSovaGlzdG9yeS1zdGF0 cyovLg0KIFRoZXNlIGFyZSB0aGUgbmV3IHN0YXRpc3RpY3MgZm9yIHN0YXRlZnVsIHJlZmxlY3Rv ci48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdJTSZndDsmZ3Q7IEFncmVlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZWkg THVvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_HE1PR0701MB28907DC3A4482E290DE00E5AD73D0HE1PR0701MB2890_-- From nobody Tue Mar 21 05:21:44 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373761297CB for ; Tue, 21 Mar 2017 05:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian-com.20150623.gappssmtp.com 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 fEYXNwXEd4pZ for ; Tue, 21 Mar 2017 05:21:38 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EEC1297C4 for ; Tue, 21 Mar 2017 05:21:38 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id x37so150591252ota.2 for ; Tue, 21 Mar 2017 05:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8k6VFIIITISHNIqySE0hV0nra6Va1+4OJBVy1CfBs1E=; b=EleZLEoUWgET3o/gIdGl+7LkRzSUh1IfDFKjShX4e6zVknuILxpDgz//arsWrsKBT/ SwCji4M9RiA2RoKCUP5RLWZ89TbOKO4V8rMNj3PIdZwIVkXJRwJ/JGfhZ7f6Y5uTZxjQ s1AOaNuYf6n4JqfyzV+Npp0COkZFlFZ+a3FBWOcxygGctQcUrckmQyKtNr7nQlLggW7Y abV4tyk3mqueJ7KZsyyFZla+RTTaMQZqvKHF0hi0t2zM73ku3L1VUuBmmfSvebCvpmv4 hsARIH8H5XnVrRprlGd3OwXQqePi+FTINjJ4isQx3PlEgJ7d+7GbygSQlNGgU5w57C3+ FaFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8k6VFIIITISHNIqySE0hV0nra6Va1+4OJBVy1CfBs1E=; b=J3yXDrTVBg4ZNE933zXeTcueJmz4YuE5Sq0Yms/4ZT2rI7EkAbele9dL2t4rX5LjL8 T3fpupN/R6oOwjvUuo0OeXbZ2Zm+oMlijYOl1i6LyLgXfO8gJAI7GvdgnCkNmUw8e9Da UwfGnaX8I0PS3ifnUf/PIpPjQjxvC9dU5eQ4H+BrL8iaGGlQcXb3Gc19aGkQhBcVVZ6x gK6viPqPAsAlxYzVD6ITD7S7kN+6/tiyBwOg6wrhOmUUa8edxNGiGdiBuPaKkbP2NzeO AcOfXKIuC8FaMqxQidYLWKgfDV0r5CbKh4pe9BbyUbOjtr1FHcP1FjAnREbnNdvlKhIh DJpA== X-Gm-Message-State: AFeK/H0RngD66600Ztla98QD6RmsnT1chg9jYIsvJ11rSKKI89hL8STsGzJnPDTyYmFpVBPD9Z7jHn0c/uzZfdsB5Jw6o26kv11YRUqaatYUoE8+tC7OPiIpjbIjoHQAd69S X-Received: by 10.157.5.8 with SMTP id 8mr16534903otw.170.1490098897769; Tue, 21 Mar 2017 05:21:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.14.11 with HTTP; Tue, 21 Mar 2017 05:21:37 -0700 (PDT) In-Reply-To: References: From: Henrik Nydell Date: Tue, 21 Mar 2017 13:21:37 +0100 Message-ID: To: Wei Luo S Cc: "ippm@ietf.org" , "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" Content-Type: multipart/alternative; boundary=94eb2c046b287b68e7054b3caf35 Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 12:21:42 -0000 --94eb2c046b287b68e7054b3caf35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some comments from the "field" as Accedian has several hundred thousand TWAMP sessions running (continously) at numerous Tier one mobile/fixed operators globally. On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S wrote: > Hi Greg, > > > > Thanks a lot for your response. Please see my reply inline tagged [WEI>>]= . > > > > Regards, > > Wei Luo > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Tuesday, March 21, 2017 1:16 AM > *To:* Wei Luo S > *Cc:* ippm@ietf.org; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org > *Subject:* Re: Some though on draft-mirsky-ippm-twamp-light-yang-07 > > > > Hi Wei Luo, > > many thanks for your thorough review and the most helpful comments to the > TWAMP Light(Test) model. Please find my answers, notes in-line tagged GIM= >>. > > > > Regards, > > Greg > > > > On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S wrote= : > > Hi Greg & Adrian, > > > > This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. Th= e > current TWAMP Light YANG model is well defined. Thanks for your great job= . > > But by working closely with our customers, we got some new user cases on > TWAMP light. I believe these user cases are valuable and popular enough t= o > be modeled in TWAMP Light YANG. I hope I can be a contributor and co-wor= k > with you move this draft forward. > > I drafted a new version of the TWAMP light YANG model based on version > ietf-twamp-light@2017-02-13.yang. Could you please comments on it? Any > discussion is welcome. > > The draft yang model and tree is attached. To make you find the updates > quickly, I highlighted all the updates in file > ietf-twamp-light-weiluo.pdf. > > > > The following are the list of main updates: > > *1. Add a new typedef: percent. This is a new type defined for packet los= s > ratio.* > > Consideration: > > 1). From the customer perspective, packet loss ratio is a more meaningful > data. In most of the time, the absolute number is meaningless to user, > especially they do the TWAMP test continuously. They are more care about > the ratio than the absolute number. So adding it makes this model more > friendly to customer; > > 2). From the service layer assurance(SLA) perspective, the packet loss > ratio is a major measures. So with adding packet loss ratio in model, the > TWAMP can work in SLA framework more smoothly. > > 3). It seems some similar protocol=E2=80=99s YANG model has the same defi= nition, > e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99, > https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf. > > Agreed packet loss is important, however another important loss metric is loss burst size (max/min) and number of loss bursts. A loss burst of 10 consecutive TWAMP-test packets can be deemed more serious than 10 lost packets spread evenly over the report interval. > GIM>> Indeed, packet loss more often expressed as packet loss ratio rathe= r > than as the absolute number. It would be most helpful to hear from networ= k > operators if they see introduction of Packet Loss Ratio into the TWAMP > model helpful. > > *2. Add a new typedef: state-mode. It defines a common type for > stateful/stateless reflector. This type will be used in both sender sessi= on > and reflector session.* > > Consideration: > > If the reflector is stateful, the TWAMP light can measure more items, e.g= . > one way packet loss. So for sender, the stats calculation and show is > different. When the reflector is stateless, it doesn=E2=80=99t need to ca= lculate > the one way packet loss. The one way packet loss is invalid and shouldn= =E2=80=99t > be presented to customer. When the reflector is stateless, the sender nee= ds > to calculate the one way packet loss. And the data should be present to > customer. So this is used as a =E2=80=98when=E2=80=99 condition in the mo= del=E2=80=99s RO tree. > > GIM>> Yes, if Session-Sender is aware of the mode corresponding > Session-Reflector operates, the sender may avoid calculation of some > performance metrics, e.g., one-way packet loss. On the other hand, the > orchestrator is aware of the state-mode and should be capable to properly > use metrics reported by the Session-Sender. > > [WEI>>] Yes, the orchestrator could know that. But from the model side, > this is not correct. The model should represent the right behavior and > shouldn=E2=80=99t do assumption on orchestrator. > I agree the model should describe both one-way loss metrics and roundtrip loss metrics, and the sender should be able to use either mode when calculating, potentially also populating the roundtrip delay values with proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that would indicate buffer load/CPU load in the TWAMP responders processing time= . > *3. Add a new typedef: send-mode. This is a new type for sender session. > It makes the sender session can send packet continuously and monitor the > network all the time.* > > Consideration: > > The user case is that: the user runs TWAMP light sessions to watch links > quality continuously. The session number could be very big. These TWAMP > sessions are managed by SLA framework or similar. SLA retrieves the stats > from TWAMP periodically, e.g. 15mins. In other words, all the performance > metrics are calculated based on the packets sent/received within 15mins. > This makes the calculation become possible. With the periodical stats dat= a, > the Network Management software can do further actions if some abnormal > stats observed. This is a more general user case in customer site. While > the non-continuous TWAMP sender session is generally used for debugging > purpose on a link. > > GIM>> I think that support of continuous measurement is in LMAP domain, > not for TWAMP Test data model. To conduct continuous measurement he LMAP > Controller, in my opinion, programs the Measurement Agent to perform TWAM= P > Test session with certain set of parameters and repeat it without any > interval (interval =3D 0). > Many operators use TWAMP in continous mode, not only with Accedian test points and report at fixed intervals, typically ranging from 5s to 5 or 15 minutes, with 1-minute being the most popular granularity currently. The advantage is that the result calculation can be handled separately from the TWAMP-test sending/recieving, so that there is no parallelism required to monitor 24/7. If a start-stop-based methodology is used, the sender needs to start up the new test session even before the previous one has ended, since the previous session needs to wait X seconds (or at least Y 100s of milliseconds) before it stops waiting for packets to come back. And this new session needs to have a different signature in order for the sender to discern which packets belong to the previous interval and which belong to the current. In a continous test-model, the sender can just simply record the sequence number of the last packet transmitted in the interval to be reported, wait for it to come back, or a MAXTIME, then report that result, while continuing to transmit for the next interval. If the "interval=3D=3D0" parameter is intended to be used for continous typ= e tests, then what parameter should indicate to the sender at what intervals to produce results? > *4. Add a new group: packet-loss-statistics. It grouping two packet loss > statistics: loss-count and loss-ratio. This group will be used in RO stat= s > tree.* > > GIM>> I'd like to continue discussion. > > [WEI>>] OK. > > *5. Move leaf dscp out from grouping session-light-parameters. The leaf > dscp is only valid when the dscp-handling-mode is use-configured-value. A > when condition shall be added to it. So it can=E2=80=99t be in this group= .* > > GIM>> I'm concerned that then the model will not be able to support > concurrent TWAMP Test sessions between the same pair of Test Points (IP > address+port number) at different CoS markings. > > [WEI>>] Actually, I have concern on using five tuple(IP address+port > number+dscp) to identify a TWAMP test session. The DSCP is not a constant > value in packet. It could be modified by the routers in the path. For > example, the sender has two sessions: session A=E2=80=99s five tuple is: > Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2. S= ession B=E2=80=99s > five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001= , > DSCP=3Dcs3. The only difference between session A and session B is DSCP. = If > the test packet=E2=80=99s DSCP of session B is modified to cs2 by a route= r in the > path. The five tuples are exactly the same for reflector. It can=E2=80=99= t > differentiate which packet is from session A, which packet is from sessio= n > B. It could mess the reflector=E2=80=99s session sequence number. And als= o, the > sender will be messed because the received reply packet=E2=80=99s five tu= ple are > exactly the same. > > So I think it=E2=80=99s more reasonable to use four tuple to identify a s= ession. > Yes, this would be appreciated by users. Changes in DSCP is a reasonably common network error that users can detect with continous TWAMP monitoring, thus it is good to not include the DSCP value as part of the "session identifiier" but instead use 4-tuple with UDP source port to identify several parallel flows between the same sender and responder. > *6. Add leaf 'session-packet-send-mode' to > /twamp-light/twamp-light-session-sender/test-session*. This leaf specifie= s > the sender session's packet send mode: continuous or non-continuous.* > > GIM>> As discussed in #3, I think that it is already part of LMAP YANG > model. > > *7. Add leaf 'reflector-light-mode-state' to > /twamp-light/twamp-light-session-sender/test-session*. This leaf indicate= s > the the reflector's mode: stateful or stateless. If the reflector's mode = is > stateful. Two one way packet loss statistics can be got: > one-way-packet-loss-far-end, one-way-packet-loss-near-end.* > > Consideration: > > Only valid data should be presented to user. Otherwise it could misleadin= g > user in some cases. > > GIM>> A in response to #2. > > *8. Modify leaf > /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. > Add a 'when' condition to this leaf. When send-mode is 'continuous', the > leaf number-of-packets is meaningless. So add a 'when' condition to limit > it. Besides, added a default value =E2=80=9810=E2=80=99 to it. When the = send-mode is > 'non-continuous', the session can't work with an empty number-of-packets.= * > > GIM>> As I've noted in #3. Will add default. > > *9. Add leaf time out to > /twamp-light/twamp-light-session-sender/test-session*. A timeout mechanis= m > is needed when the sender session can't get all the reply packets for a > long time.* > > GIM>> Thank you, will add in the next update. > > *10. Modify leaf > /twamp-light/twamp-light-session-sender/test-session*/interval. Change th= e > units from =E2=80=98microseconds=E2=80=99 to =E2=80=98milliseconds=E2=80= =99. Add a default value 1000. * > > Consideration: > > 1). The aim of TWAMP is to measure network quality, but not fast > failure detection. So a millisecond packet interval is enough. > > 2). Interval is a necessary parameter for a session. A sender session > can't work with an empty packet send interval. So added a default value t= o > it. > > GIM>> Thank you. We've made units of interval microseconds in the last > update already. I think that changing to milliseconds may be too > restrictive, limit use cases for TWAMP Test. Will add default value with > the next update. > > [WEI>>] Sorry, I do not see the reason. Are there any user cases to use > microseconds? > > *11. Add leaf 'dscp' to > /twamp-light/twamp-light-session-sender/test-session*. This is the leaf > moved out from grouping session-light-parameters.* > > GIM>> As noted in response #5, the change may limit ability to run > concurrent TWAMP Test sessions per CoS. I consider that to be valuable mo= de > but would like to hear from network operators if that is indeed useful > information. > See my comment above. I argue that it is useful to keep track of changing DSCP values, and treating DSCP as a metric of the TWAMP Session just like loss and delay > *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and > 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to > /twamp-light/twamp-light-session-reflector/test-session*. These three > attributes should be session specific. Different session could have > different values. They are not common attributes.* > > GIM>> Agree, will make it in the next update. > > *13. Add leaf 'dscp' to > /twamp-light/twamp-light-session-reflector/test-session*. This is the lea= f > moved out from grouping session-light-parameters. Besides the movement, > added a 'when' condition to the leaf 'dscp'. This leaf is only valid when > the dscp-handling-mode is 'use-configured-value'.* > > GIM>> As response to #5. > > *14. Modify leaf > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/number-of-packets. > Add a 'when' condition to this leaf. When send-mode is 'continuous', the > leaf number-of-packets is meaningless.* > > GIM>> Similar to #3. > > *15. Modify leaf > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/interval. > Change the units from microseconds to milliseconds.* > > GIM>> I think that microseconds is reasonable. > > *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and > 'one-way-packet-loss-near-end' to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/. > These are the new statistics for stateful reflector.* > > GIM>> Thank you, will be coming in the next update. > > *17. Remove leaf loss-packet in > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats. > The loss packeted is replaced with 'two-way-packet-loss' stated above.* > > GIM>> Agree. > > *18. Modify leaf to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/h= istory-stats*/interval. > Change the units from microseconds to milliseconds.* > > GIM>> I think that will limit applicability of TWAMP Test. > > *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and > 'one-way-packet-loss-near-end' to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/h= istory-stats*/. > These are the new statistics for stateful reflector.* > > GIM>> Agree. > > > > Thanks, > > Wei Luo > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --=20 [image: Accedian.com] Henrik Nydell Sr Manager Global Strategy & Solutions Cell Email Skype +46 709845992 hnydell@accedian.com h nydell --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3= =A8ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le secret=20 professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de son= ou de ses=20 destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99il= vous=20 plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en d= =C3=A9truire tout=20 exemplaire. De plus, il vous est strictement interdit de le divulguer, de= =20 le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99= exp=C3=A9diteur.=20 Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the exclusive= =20 use of its addressee(s). If you receive this message in error, please=20 inform sender immediately and destroy any copy thereof. Furthermore, any=20 disclosure, distribution or copying of this message and/or any attachment= =20 hereto without the consent of the sender is strictly prohibited. Thank you. --94eb2c046b287b68e7054b3caf35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some comments from the "field" as Accedian has s= everal hundred thousand TWAMP sessions running (continously) at numerous Ti= er one mobile/fixed operators globally.

On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S <we= i.s.luo@ericsson.com> wrote:

Hi Greg,

=C2=A0

Thanks a lot for your response. Please see my reply= inline tagged [WEI>>].

=C2=A0

Regards,

Wei Luo

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, March 21, 2017 1:16 AM
To: Wei Luo S <wei.s.luo@ericsson.com>
Cc: ippm@ietf.org= ; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org
Subject: Re: Some though on draft-mirsky-ippm-twamp-light-yang-= 07

=C2=A0

Hi Wei Luo,

many thanks for your thorough review and the most he= lpful comments to the TWAMP Light(Test) model. Please find my answers, note= s in-line tagged GIM>>.

=C2=A0

Regards,

Greg

=C2=A0

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <wei.s.luo@ericsson.c= om> wrote:

Hi Greg & Adrian,

=C2=A0

This is Wei Luo from Ericsson. I work on TWAMP light= area in Ericsson. The current TWAMP Light YANG model is well defined. Than= ks for your great job.

But by working closely with our customers, we got so= me new user cases on TWAMP light. I believe these user cases are valuable a= nd popular enough to be modeled in TWAMP Light YANG. I hope I can be a contributor =C2=A0and co-work with you move this draft f= orward.=C2=A0

I =C2=A0drafted a new version of the TWAMP light YAN= G model based on version ietf-= twamp-light@2017-02-13.yang. Could you please comments on it? Any = discussion is welcome.

The draft yang model and tree is attached. To make y= ou find the updates quickly, I highlighted all the updates in fil= e ietf-twamp-light-weiluo.pdf.

=C2=A0

The following are the list of main updates:

1. Add a new typedef: percent. This is a new type= defined for packet loss ratio.

Consideration:

1). From the customer perspective, packet loss ratio is a more meaningful d= ata. In most of the time, the absolute number is meaningless to user, espec= ially they do the TWAMP test continuously. They are more care about the rat= io than the absolute number. So adding it makes this model more friendly to customer;

2). From the service layer assurance(SLA) perspective, the packet loss rati= o is a major measures. So with adding packet loss ratio in model, the TWAMP= can work in SLA framework more smoothly.

3). It seems some similar protocol=E2=80=99s YANG model has the same defini= tion, e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99= , https://www.mef.net/Assets/Technical_= Specifications/PDF/MEF_39.pdf.

=
Agreed packet loss i= s important, however another important loss metric is loss burst size (max/= min) and number of loss bursts. A loss burst of 10 consecutive TWAMP-test p= ackets can be deemed more serious than 10 lost packets spread evenly over t= he report interval.

GIM>> Indeed, packet loss more often expressed= as packet loss ratio rather than as the absolute number. It would be most = helpful to hear from network operators if they see introduction of Packet L= oss Ratio into the TWAMP model helpful.

2. Add a new typedef: state-mode. It defines a co= mmon type for stateful/stateless reflector. This type will be used in both = sender session and reflector session.

Consideration:

If the reflector is stateful, the TWAMP light can me= asure more items, e.g. one way packet loss. So for sender, the stats calcul= ation and show is different. When the reflector is stateless, it doesn=E2=80=99t need to calculate the one way packet loss. T= he one way packet loss is invalid and shouldn=E2=80=99t be presented to cus= tomer. When the reflector is stateless, the sender needs to calculate the o= ne way packet loss. And the data should be present to customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree.

GIM>> Yes, if Session-Sender is aware of the m= ode corresponding Session-Reflector operates, the sender may avoid calculat= ion of some performance metrics, e.g., one-way packet loss. On the other ha= nd, the orchestrator is aware of the state-mode and should be capable to properly use metrics reported by the Session-Send= er.

[WEI>>] Yes, the orchestrator could know that. But from= the model side, this is not correct.=C2=A0 The model should represent the = right behavior and shouldn=E2=80=99t do assumption on orchestrator.<= /p>

I agree the model = should describe both one-way loss metrics and roundtrip loss metrics, and t= he sender should be able to use either mode when calculating, potentially a= lso populating the roundtrip delay values with proper t1-t0 + t3-t2 values,= as well as reporting the t2-t1 values that would indicate buffer load/CPU = load in the TWAMP responders processing time.

3. Add a new typedef: send-mode. This is a new ty= pe for sender session. It makes the sender session can send packet continuo= usly and monitor the network all the time.

Consideration:

The user case is that: the user runs TWAMP light ses= sions to watch links quality continuously. The session number could be very= big. These TWAMP sessions are managed by SLA framework or similar. SLA retrieves the stats from TWAMP periodically, e.g. 15mins. = In other words, all the performance metrics are calculated based on the pac= kets sent/received within 15mins. This makes the calculation become possibl= e. With the periodical stats data, the Network Management software can do further actions if some abnormal st= ats observed.=C2=A0 This is a more general user case in customer site. Whil= e the non-continuous TWAMP sender session is generally used for debugging p= urpose on a link. =C2=A0

GIM>> I think that support of continuous measu= rement is in LMAP domain, not for TWAMP Test data model. To conduct continu= ous measurement he LMAP Controller, in my opinion, programs the Measurement= Agent to perform TWAMP Test session with certain set of parameters and repeat it without any interval (interval =3D= 0).


Many operators use TWAMP in continous mode, not only with Accedian= test points and report at fixed intervals, typically ranging from 5s to 5 = or 15 minutes, with 1-minute being the most popular granularity currently. = The advantage is that the result calculation can be handled separately from= the TWAMP-test sending/recieving, so that there is no parallelism required= to monitor 24/7. If a start-stop-based methodology is used, the sender nee= ds to start up the new test session even before the previous one has ended,= since the previous session needs to wait X seconds (or at least Y 100s of = milliseconds) before it stops waiting for packets to come back. And this ne= w session needs to have a different signature in order for the sender to di= scern which packets belong to the previous interval and which belong to the= current.

In a continous test-model, the sender ca= n just simply record the sequence number of the last packet transmitted in = the interval to be reported, wait for it to come back, or a MAXTIME, then r= eport that result, while continuing to transmit for the next interval.

If the "interval=3D=3D0" parameter is intend= ed to be used for continous type tests, then what parameter should indicate= to the sender at what intervals to produce results? =C2=A0

4. Add a new group: packet-loss-statistics. It gr= ouping two packet loss statistics: loss-count and loss-ratio. This group wi= ll be used in RO stats tree.

GIM>> I'd like to continue discussion.=C2= =A0

[WEI>>] OK.

5. Move leaf dscp out from grouping session-light= -parameters. The leaf dscp is only valid when the dscp-handling-mode is use= -configured-value. A when condition shall be added to it. So it can=E2=80=99t be in this group.

GIM>> I'm concerned that then the model wi= ll not be able to support concurrent TWAMP Test sessions between the same p= air of Test Points (IP address+port number) at different CoS markings.=C2= =A0

[WEI>>] Actually, I have concern on using five tuple(IP= address+port number+dscp) to identify a TWAMP test session. The DSCP is no= t a constant value in packet. It could be modified by the routers in the path. For example, the sender has two sessions: session A=E2=80=99s= five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001,= DSCP=3Dcs2. Session B=E2=80=99s five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.= 2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs3. The only difference between session A and session B is DSCP. If the test packet=E2=80=99s DSCP of sess= ion B is modified to cs2 by a router in the path. The five tuples are exact= ly the same for reflector. It can=E2=80=99t differentiate which packet is f= rom session A, which packet is from session B. It could mess the reflector=E2=80=99s session sequence number. And also, the = sender will be messed because the received reply packet=E2=80=99s five tupl= e are exactly the same.

So I think it=E2=80=99s more reasonable to use four tuple to identif= y a session.


Yes, this would be appreciated by users. Changes in DSCP i= s a reasonably common network error that users can detect with continous TW= AMP monitoring, thus it is good to not include the DSCP value as part of th= e "session identifiier" but instead use 4-tuple with UDP source p= ort to identify several parallel flows between the same sender and responde= r.=C2=A0

6. Add leaf 'session-packet-send-mode' to= /twamp-light/twamp-light-session-sender/test-session*. This leaf spec= ifies the sender session's packet send mode: continuous or non-continuo= us.

GIM>> As discussed in #3, I think that it is a= lready part of LMAP YANG model.=C2=A0

7. Add leaf 'reflector-light-mode-state' = to /twamp-light/twamp-light-session-sender/test-session*. This leaf in= dicates the the reflector's mode: stateful or stateless. If the reflector's mode is stateful. Two one way packet loss statistics can b= e got: one-way-packet-loss-far-end, one-way-packet-loss-near-end.

Consideration: =C2=A0

Only valid data should be presented to user. Otherwi= se it could misleading user in some cases.

GIM>> A in response to #2.=C2=A0=

8. Modify leaf /twamp-light/twamp-light-sess= ion-sender/test-session*/number-of-packets. Add a 'when' condi= tion to this leaf. When send-mode is 'continuous', the leaf number-= of-packets is meaningless. So add a 'when' condition to limit it.=C2=A0 Besid= es, added a default value =E2=80=9810=E2=80=99 to it. When the send-mode is= 'non-continuous', the session can't work with an empty number-= of-packets.

GIM>> As I've noted in #3. Will add defaul= t.=C2=A0

9. Add leaf time out to /twamp-light/twamp-light-= session-sender/test-session*. A timeout mechanism is needed when the s= ender session can't get all the reply packets for a long time.

GIM>> Thank you, will add in the next update.= =C2=A0

10. Modify leaf /twamp-light/twamp-light-ses= sion-sender/test-session*/interval. Change the units from =E2=80=98mic= roseconds=E2=80=99 to =E2=80=98milliseconds=E2=80=99. Add a default value 1= 000.

Consideration:

=C2=A0=C2=A0=C2=A0 1). The aim of TWAMP is to measur= e network quality, but not fast failure detection. So a millisecond packet = interval is enough.

=C2=A0=C2=A0=C2=A0 2). Interval is a necessary param= eter for a session. A sender session can't work with an empty packet se= nd interval. So added a default value to it.

GIM>> Thank you. We've made units of inter= val microseconds in the last update already. I think that changing to milli= seconds may be too restrictive, limit use cases for TWAMP Test. Will add de= fault value with the next update.

[WEI>>] Sorry, I do not see the reason. Are there any u= ser cases to use microseconds?

11. Add leaf 'dscp' to /twamp-light/twamp= -light-session-sender/test-session*. This is the leaf moved out from g= rouping session-light-parameters.

GIM>> As noted in response #5, the change may = limit ability to run concurrent TWAMP Test sessions per CoS. I consider tha= t to be valuable mode but would like to hear from network operators if that= is indeed useful information.=C2=A0


See my comment above. I argue that= it is useful to keep track of changing DSCP values, and treating DSCP as a= metric of the TWAMP Session just like loss and delay=C2=A0

12. Move leaves 'ref-wait', 'reflecto= r-light-mode-state' and 'dscp-handling-mode' from /twamp-light/= twamp-light-session-reflector to /twamp-light/twamp-light-session= -reflector/test-session*. These three attributes should be session specific. Different session could= have different values. They are not common attributes.

GIM>> Agree, will make it in the next update.= =C2=A0

13. Add leaf 'dscp' to /twamp-light/twamp= -light-session-reflector/test-session*. This is the leaf moved ou= t from grouping session-light-parameters. Besides the movement, added a 'when' condition to the leaf 'dscp'. This leaf is only v= alid when the dscp-handling-mode is 'use-configured-value'.<= /u>

GIM>> As response to #5.=C2=A0

14. Modify leaf /twamp-light-state/twamp-lig= ht-session-sender-state/test-session-state*/current-stats/number-= of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless.

GIM>> Similar to #3.=C2=A0

15. Modify leaf /twamp-light-state/twamp-lig= ht-session-sender-state/test-session-state*/current-stats/interva= l. Change the units from microseconds to milliseconds.

GIM>> I think that microseconds is reasonable.= =C2=A0

16. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/current-stats/. These are the new statistics for stateful reflector.

GIM>> Thank you, will be coming in the next up= date.=C2=A0

17. Remove leaf loss-packet in /twamp-light-state= /twamp-light-session-sender-state/test-session-state*/current-stats. The loss packeted is replaced with 'two-way-packet-loss' stated above.

GIM>> Agree.=C2=A0

18. Modify leaf to /twamp-light-state/twamp-= light-session-sender-state/test-session-state*/history-stats*/int= erval. Change the units from microseconds to milliseconds.

GIM>> I think that will limit applicability of= TWAMP Test.=C2=A0

19. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/history-stats*/. These are the new statistics for stateful reflector.

GIM>> Agree.

=C2=A0

Thanks,

Wei Luo

=C2=A0


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




--
=


=

3D"Accedian.com"

Henrik Nydell

Sr Ma= nager Global Strategy & Solutions

<= /div>

+46 709845992

hnydell@accedian.com

hnydell

= Cell

Email

Skype



= =C2=A0 =C2=A0 =C2=A0 =C2=A0


=

Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

--94eb2c046b287b68e7054b3caf35-- From nobody Tue Mar 21 06:31:32 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846C0120727 for ; Tue, 21 Mar 2017 06:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yN5QhYPrnFuJ for ; Tue, 21 Mar 2017 06:31:26 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B427129871 for ; Tue, 21 Mar 2017 06:31:26 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id a94so36815151oic.2 for ; Tue, 21 Mar 2017 06:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QeJVEaqukXJ+gPMwg1FcH3m9DOiuYoibbV8Rj5m2vu0=; b=dtZhyta1hw4HR8q5Mv+TCiAljh4ySGbzl3+6KCdLSyXSRCUnv08JUA60aFgRtnNgIH WIJiQ8rnA5VZN5MJCY+CjUSQ0VRKX9ZHIL1YgiF/lL/gwmOGfExmm1sVAS7XtUJDxl0X rXaO1MNWvB0GgALuH925XvtEeL/0mK9kikgdYkEvB+1FhQH2JZW9ha7sdjV98MOcj4nA GudDgDKTz9oomKgKHVWZGNSnoxA3SF+NG4R5WMyEiSkSz3OmeOpMgt9BkI6VMH7Pwf5M oo+mTd3keC1GcmZqqCvpYiSUpPDOMd2l0nn3xaRQNSaqfLrz3t8kenmJxE0bUI+9QOa8 ZeqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QeJVEaqukXJ+gPMwg1FcH3m9DOiuYoibbV8Rj5m2vu0=; b=uZYYXd5D9qfsOnLDIu7oXDOQd3rmjkL593E/rXYa+d2xFqEEvvPAhlR1X6304I810+ V+EvG0BiYtjX8qYpuVJ2PjWEseSYGydPgsqZdVPeHZVGZ/OTes1+E7Wcr3MYXrwYtQWl WE0vdhSo98FxglmQ7SszhXZh3CYA40ga6qYTHypn1tpNj6riYJSnPX1MtwtlzyaPu3Ju 80Z9UBaJWZDyQGM2tqwggx7naJvR0BVRM8EyXqroKHkDx33SFBG5dzIOWSzFjVbLfKk0 9KQG/UIgH8bw1Zq85+gCcVnOpLOjhB9oY1P83m+Fm50A9jfSbQqwA9SM512gi5IBdUMa EqTg== X-Gm-Message-State: AFeK/H1amwjwcOf09g0KLYDZx/C2vcaF8Wg6HpJU1nPTLhUPLe56Yr7U2oH7WPRMBYE/UM4C5P31CQs3kBoxSQ== X-Received: by 10.202.196.79 with SMTP id u76mr2551463oif.44.1490103085573; Tue, 21 Mar 2017 06:31:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Tue, 21 Mar 2017 06:31:25 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Tue, 21 Mar 2017 08:31:25 -0500 Message-ID: To: Wei Luo S Cc: "ippm@ietf.org" , "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a11c17b32182daf054b3da982 Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 13:31:31 -0000 --001a11c17b32182daf054b3da982 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Wei, thank you for your very detailed comments, most helpful. Would like to explain my choice of microseconds as units for interval. Intervals measured in microseconds required to enable synthetic loss measurement with TWAMP. You may argue that that is not what TWAMP intended for but, on the other hand, TWAMP is fully capable to perform SLM. Regards, Greg On Tue, Mar 21, 2017 at 5:52 AM, Wei Luo S wrote: > Hi Greg, > > > > Thanks a lot for your response. Please see my reply inline tagged [WEI>>]= . > > > > Regards, > > Wei Luo > > > > *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] > *Sent:* Tuesday, March 21, 2017 1:16 AM > *To:* Wei Luo S > *Cc:* ippm@ietf.org; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org > *Subject:* Re: Some though on draft-mirsky-ippm-twamp-light-yang-07 > > > > Hi Wei Luo, > > many thanks for your thorough review and the most helpful comments to the > TWAMP Light(Test) model. Please find my answers, notes in-line tagged GIM= >>. > > > > Regards, > > Greg > > > > On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S wrote= : > > Hi Greg & Adrian, > > > > This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. Th= e > current TWAMP Light YANG model is well defined. Thanks for your great job= . > > But by working closely with our customers, we got some new user cases on > TWAMP light. I believe these user cases are valuable and popular enough t= o > be modeled in TWAMP Light YANG. I hope I can be a contributor and co-wor= k > with you move this draft forward. > > I drafted a new version of the TWAMP light YANG model based on version > ietf-twamp-light@2017-02-13.yang. Could you please comments on it? Any > discussion is welcome. > > The draft yang model and tree is attached. To make you find the updates > quickly, I highlighted all the updates in file > ietf-twamp-light-weiluo.pdf. > > > > The following are the list of main updates: > > *1. Add a new typedef: percent. This is a new type defined for packet los= s > ratio.* > > Consideration: > > 1). From the customer perspective, packet loss ratio is a more meaningful > data. In most of the time, the absolute number is meaningless to user, > especially they do the TWAMP test continuously. They are more care about > the ratio than the absolute number. So adding it makes this model more > friendly to customer; > > 2). From the service layer assurance(SLA) perspective, the packet loss > ratio is a major measures. So with adding packet loss ratio in model, the > TWAMP can work in SLA framework more smoothly. > > 3). It seems some similar protocol=E2=80=99s YANG model has the same defi= nition, > e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99, > https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf. > > GIM>> Indeed, packet loss more often expressed as packet loss ratio rathe= r > than as the absolute number. It would be most helpful to hear from networ= k > operators if they see introduction of Packet Loss Ratio into the TWAMP > model helpful. > > *2. Add a new typedef: state-mode. It defines a common type for > stateful/stateless reflector. This type will be used in both sender sessi= on > and reflector session.* > > Consideration: > > If the reflector is stateful, the TWAMP light can measure more items, e.g= . > one way packet loss. So for sender, the stats calculation and show is > different. When the reflector is stateless, it doesn=E2=80=99t need to ca= lculate > the one way packet loss. The one way packet loss is invalid and shouldn= =E2=80=99t > be presented to customer. When the reflector is stateless, the sender nee= ds > to calculate the one way packet loss. And the data should be present to > customer. So this is used as a =E2=80=98when=E2=80=99 condition in the mo= del=E2=80=99s RO tree. > > GIM>> Yes, if Session-Sender is aware of the mode corresponding > Session-Reflector operates, the sender may avoid calculation of some > performance metrics, e.g., one-way packet loss. On the other hand, the > orchestrator is aware of the state-mode and should be capable to properly > use metrics reported by the Session-Sender. > > [WEI>>] Yes, the orchestrator could know that. But from the model side, > this is not correct. The model should represent the right behavior and > shouldn=E2=80=99t do assumption on orchestrator. > > *3. Add a new typedef: send-mode. This is a new type for sender session. > It makes the sender session can send packet continuously and monitor the > network all the time.* > > Consideration: > > The user case is that: the user runs TWAMP light sessions to watch links > quality continuously. The session number could be very big. These TWAMP > sessions are managed by SLA framework or similar. SLA retrieves the stats > from TWAMP periodically, e.g. 15mins. In other words, all the performance > metrics are calculated based on the packets sent/received within 15mins. > This makes the calculation become possible. With the periodical stats dat= a, > the Network Management software can do further actions if some abnormal > stats observed. This is a more general user case in customer site. While > the non-continuous TWAMP sender session is generally used for debugging > purpose on a link. > > GIM>> I think that support of continuous measurement is in LMAP domain, > not for TWAMP Test data model. To conduct continuous measurement he LMAP > Controller, in my opinion, programs the Measurement Agent to perform TWAM= P > Test session with certain set of parameters and repeat it without any > interval (interval =3D 0). > > *4. Add a new group: packet-loss-statistics. It grouping two packet loss > statistics: loss-count and loss-ratio. This group will be used in RO stat= s > tree.* > > GIM>> I'd like to continue discussion. > > [WEI>>] OK. > > *5. Move leaf dscp out from grouping session-light-parameters. The leaf > dscp is only valid when the dscp-handling-mode is use-configured-value. A > when condition shall be added to it. So it can=E2=80=99t be in this group= .* > > GIM>> I'm concerned that then the model will not be able to support > concurrent TWAMP Test sessions between the same pair of Test Points (IP > address+port number) at different CoS markings. > > [WEI>>] Actually, I have concern on using five tuple(IP address+port > number+dscp) to identify a TWAMP test session. The DSCP is not a constant > value in packet. It could be modified by the routers in the path. For > example, the sender has two sessions: session A=E2=80=99s five tuple is: > Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2. S= ession B=E2=80=99s > five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001= , > DSCP=3Dcs3. The only difference between session A and session B is DSCP. = If > the test packet=E2=80=99s DSCP of session B is modified to cs2 by a route= r in the > path. The five tuples are exactly the same for reflector. It can=E2=80=99= t > differentiate which packet is from session A, which packet is from sessio= n > B. It could mess the reflector=E2=80=99s session sequence number. And als= o, the > sender will be messed because the received reply packet=E2=80=99s five tu= ple are > exactly the same. > > So I think it=E2=80=99s more reasonable to use four tuple to identify a s= ession. > > *6. Add leaf 'session-packet-send-mode' to > /twamp-light/twamp-light-session-sender/test-session*. This leaf specifie= s > the sender session's packet send mode: continuous or non-continuous.* > > GIM>> As discussed in #3, I think that it is already part of LMAP YANG > model. > > *7. Add leaf 'reflector-light-mode-state' to > /twamp-light/twamp-light-session-sender/test-session*. This leaf indicate= s > the the reflector's mode: stateful or stateless. If the reflector's mode = is > stateful. Two one way packet loss statistics can be got: > one-way-packet-loss-far-end, one-way-packet-loss-near-end.* > > Consideration: > > Only valid data should be presented to user. Otherwise it could misleadin= g > user in some cases. > > GIM>> A in response to #2. > > *8. Modify leaf > /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. > Add a 'when' condition to this leaf. When send-mode is 'continuous', the > leaf number-of-packets is meaningless. So add a 'when' condition to limit > it. Besides, added a default value =E2=80=9810=E2=80=99 to it. When the = send-mode is > 'non-continuous', the session can't work with an empty number-of-packets.= * > > GIM>> As I've noted in #3. Will add default. > > *9. Add leaf time out to > /twamp-light/twamp-light-session-sender/test-session*. A timeout mechanis= m > is needed when the sender session can't get all the reply packets for a > long time.* > > GIM>> Thank you, will add in the next update. > > *10. Modify leaf > /twamp-light/twamp-light-session-sender/test-session*/interval. Change th= e > units from =E2=80=98microseconds=E2=80=99 to =E2=80=98milliseconds=E2=80= =99. Add a default value 1000. * > > Consideration: > > 1). The aim of TWAMP is to measure network quality, but not fast > failure detection. So a millisecond packet interval is enough. > > 2). Interval is a necessary parameter for a session. A sender session > can't work with an empty packet send interval. So added a default value t= o > it. > > GIM>> Thank you. We've made units of interval microseconds in the last > update already. I think that changing to milliseconds may be too > restrictive, limit use cases for TWAMP Test. Will add default value with > the next update. > > [WEI>>] Sorry, I do not see the reason. Are there any user cases to use > microseconds? > > *11. Add leaf 'dscp' to > /twamp-light/twamp-light-session-sender/test-session*. This is the leaf > moved out from grouping session-light-parameters.* > > GIM>> As noted in response #5, the change may limit ability to run > concurrent TWAMP Test sessions per CoS. I consider that to be valuable mo= de > but would like to hear from network operators if that is indeed useful > information. > > *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and > 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to > /twamp-light/twamp-light-session-reflector/test-session*. These three > attributes should be session specific. Different session could have > different values. They are not common attributes.* > > GIM>> Agree, will make it in the next update. > > *13. Add leaf 'dscp' to > /twamp-light/twamp-light-session-reflector/test-session*. This is the lea= f > moved out from grouping session-light-parameters. Besides the movement, > added a 'when' condition to the leaf 'dscp'. This leaf is only valid when > the dscp-handling-mode is 'use-configured-value'.* > > GIM>> As response to #5. > > *14. Modify leaf > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/number-of-packets. > Add a 'when' condition to this leaf. When send-mode is 'continuous', the > leaf number-of-packets is meaningless.* > > GIM>> Similar to #3. > > *15. Modify leaf > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/interval. > Change the units from microseconds to milliseconds.* > > GIM>> I think that microseconds is reasonable. > > *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and > 'one-way-packet-loss-near-end' to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats/. > These are the new statistics for stateful reflector.* > > GIM>> Thank you, will be coming in the next update. > > *17. Remove leaf loss-packet in > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/c= urrent-stats. > The loss packeted is replaced with 'two-way-packet-loss' stated above.* > > GIM>> Agree. > > *18. Modify leaf to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/h= istory-stats*/interval. > Change the units from microseconds to milliseconds.* > > GIM>> I think that will limit applicability of TWAMP Test. > > *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and > 'one-way-packet-loss-near-end' to > /twamp-light-state/twamp-light-session-sender-state/test-session-state*/h= istory-stats*/. > These are the new statistics for stateful reflector.* > > GIM>> Agree. > > > > Thanks, > > Wei Luo > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --001a11c17b32182daf054b3da982 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Wei,
thank you for your very detailed comments, mos= t helpful.
Would like to explain my choice of microseconds as uni= ts for interval. Intervals measured in microseconds required to enable synt= hetic loss measurement with TWAMP. You may argue that that is not what TWAM= P intended for but, on the other hand, TWAMP is fully capable to perform SL= M.

Regards,
Greg

On Tue, Mar 21, 2017 at 5:5= 2 AM, Wei Luo S <wei.s.luo@ericsson.com> wrote:

Hi Greg,

=C2=A0

Thanks a lot for your response. Please see my reply= inline tagged [WEI>>].

=C2=A0

Regards,

Wei Luo

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, March 21, 2017 1:16 AM
To: Wei Luo S <wei.s.luo@ericsson.com>
Cc: ippm@ietf.org= ; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org
Subject: Re: Some though on draft-mirsky-ippm-twamp-light-yang-= 07

=C2=A0

Hi Wei Luo,

many thanks for your thorough review and the most he= lpful comments to the TWAMP Light(Test) model. Please find my answers, note= s in-line tagged GIM>>.

=C2=A0

Regards,

Greg

=C2=A0

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <wei.s.luo@ericsson.c= om> wrote:

Hi Greg & Adrian,

=C2=A0

This is Wei Luo from Ericsson. I work on TWAMP light= area in Ericsson. The current TWAMP Light YANG model is well defined. Than= ks for your great job.

But by working closely with our customers, we got so= me new user cases on TWAMP light. I believe these user cases are valuable a= nd popular enough to be modeled in TWAMP Light YANG. I hope I can be a contributor =C2=A0and co-work with you move this draft f= orward.=C2=A0

I =C2=A0drafted a new version of the TWAMP light YAN= G model based on version ietf-= twamp-light@2017-02-13.yang. Could you please comments on it? Any = discussion is welcome.

The draft yang model and tree is attached. To make y= ou find the updates quickly, I highlighted all the updates in fil= e ietf-twamp-light-weiluo.pdf.

=C2=A0

The following are the list of main updates:

1. Add a new typedef: percent. This is a new type= defined for packet loss ratio.

Consideration:

1). From the customer perspective, packet loss ratio is a more meaningful d= ata. In most of the time, the absolute number is meaningless to user, espec= ially they do the TWAMP test continuously. They are more care about the rat= io than the absolute number. So adding it makes this model more friendly to customer;

2). From the service layer assurance(SLA) perspective, the packet loss rati= o is a major measures. So with adding packet loss ratio in model, the TWAMP= can work in SLA framework more smoothly.

3). It seems some similar protocol=E2=80=99s YANG model has the same defini= tion, e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99= , https://www.mef.net/Assets/Technical_= Specifications/PDF/MEF_39.pdf.

GIM>> Indeed, packet loss more often expressed= as packet loss ratio rather than as the absolute number. It would be most = helpful to hear from network operators if they see introduction of Packet L= oss Ratio into the TWAMP model helpful.

2. Add a new typedef: state-mode. It defines a co= mmon type for stateful/stateless reflector. This type will be used in both = sender session and reflector session.

Consideration:

If the reflector is stateful, the TWAMP light can me= asure more items, e.g. one way packet loss. So for sender, the stats calcul= ation and show is different. When the reflector is stateless, it doesn=E2=80=99t need to calculate the one way packet loss. T= he one way packet loss is invalid and shouldn=E2=80=99t be presented to cus= tomer. When the reflector is stateless, the sender needs to calculate the o= ne way packet loss. And the data should be present to customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree.

GIM>> Yes, if Session-Sender is aware of the m= ode corresponding Session-Reflector operates, the sender may avoid calculat= ion of some performance metrics, e.g., one-way packet loss. On the other ha= nd, the orchestrator is aware of the state-mode and should be capable to properly use metrics reported by the Session-Send= er.

[WEI>>] Yes, the orchestrator could know that. But from= the model side, this is not correct.=C2=A0 The model should represent the = right behavior and shouldn=E2=80=99t do assumption on orchestrator.

3. Add a new typedef: send-mode. This is a new ty= pe for sender session. It makes the sender session can send packet continuo= usly and monitor the network all the time.

Consideration:

The user case is that: the user runs TWAMP light ses= sions to watch links quality continuously. The session number could be very= big. These TWAMP sessions are managed by SLA framework or similar. SLA retrieves the stats from TWAMP periodically, e.g. 15mins. = In other words, all the performance metrics are calculated based on the pac= kets sent/received within 15mins. This makes the calculation become possibl= e. With the periodical stats data, the Network Management software can do further actions if some abnormal st= ats observed.=C2=A0 This is a more general user case in customer site. Whil= e the non-continuous TWAMP sender session is generally used for debugging p= urpose on a link. =C2=A0

GIM>> I think that support of continuous measu= rement is in LMAP domain, not for TWAMP Test data model. To conduct continu= ous measurement he LMAP Controller, in my opinion, programs the Measurement= Agent to perform TWAMP Test session with certain set of parameters and repeat it without any interval (interval =3D= 0).

4. Add a new group: packet-loss-statistics. It gr= ouping two packet loss statistics: loss-count and loss-ratio. This group wi= ll be used in RO stats tree.

GIM>> I'd like to continue discussion.=C2= =A0

[WEI>>] OK.

5. Move leaf dscp out from grouping session-light= -parameters. The leaf dscp is only valid when the dscp-handling-mode is use= -configured-value. A when condition shall be added to it. So it can=E2=80=99t be in this group.

GIM>> I'm concerned that then the model wi= ll not be able to support concurrent TWAMP Test sessions between the same p= air of Test Points (IP address+port number) at different CoS markings.=C2= =A0

[WEI>>] Actually, I have concern on using five tuple(IP= address+port number+dscp) to identify a TWAMP test session. The DSCP is no= t a constant value in packet. It could be modified by the routers in the path. For example, the sender has two sessions: session A=E2=80=99s= five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001,= DSCP=3Dcs2. Session B=E2=80=99s five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.= 2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs3. The only difference between session A and session B is DSCP. If the test packet=E2=80=99s DSCP of sess= ion B is modified to cs2 by a router in the path. The five tuples are exact= ly the same for reflector. It can=E2=80=99t differentiate which packet is f= rom session A, which packet is from session B. It could mess the reflector=E2=80=99s session sequence number. And also, the = sender will be messed because the received reply packet=E2=80=99s five tupl= e are exactly the same.

So I think it=E2=80=99s more reasonable to use four tuple to identif= y a session.

6. Add leaf 'session-packet-send-mode' to= /twamp-light/twamp-light-session-sender/test-session*. This leaf spec= ifies the sender session's packet send mode: continuous or non-continuo= us.

GIM>> As discussed in #3, I think that it is a= lready part of LMAP YANG model.=C2=A0

7. Add leaf 'reflector-light-mode-state' = to /twamp-light/twamp-light-session-sender/test-session*. This leaf in= dicates the the reflector's mode: stateful or stateless. If the reflector's mode is stateful. Two one way packet loss statistics can b= e got: one-way-packet-loss-far-end, one-way-packet-loss-near-end.

Consideration: =C2=A0

Only valid data should be presented to user. Otherwi= se it could misleading user in some cases.

GIM>> A in response to #2.=C2=A0=

8. Modify leaf /twamp-light/twamp-light-sess= ion-sender/test-session*/number-of-packets. Add a 'when' condi= tion to this leaf. When send-mode is 'continuous', the leaf number-= of-packets is meaningless. So add a 'when' condition to limit it.=C2=A0 Besid= es, added a default value =E2=80=9810=E2=80=99 to it. When the send-mode is= 'non-continuous', the session can't work with an empty number-= of-packets.

GIM>> As I've noted in #3. Will add defaul= t.=C2=A0

9. Add leaf time out to /twamp-light/twamp-light-= session-sender/test-session*. A timeout mechanism is needed when the s= ender session can't get all the reply packets for a long time.

GIM>> Thank you, will add in the next update.= =C2=A0

10. Modify leaf /twamp-light/twamp-light-ses= sion-sender/test-session*/interval. Change the units from =E2=80=98mic= roseconds=E2=80=99 to =E2=80=98milliseconds=E2=80=99. Add a default value 1= 000.

Consideration:

=C2=A0=C2=A0=C2=A0 1). The aim of TWAMP is to measur= e network quality, but not fast failure detection. So a millisecond packet = interval is enough.

=C2=A0=C2=A0=C2=A0 2). Interval is a necessary param= eter for a session. A sender session can't work with an empty packet se= nd interval. So added a default value to it.

GIM>> Thank you. We've made units of inter= val microseconds in the last update already. I think that changing to milli= seconds may be too restrictive, limit use cases for TWAMP Test. Will add de= fault value with the next update.

[WEI>>] Sorry, I do not see the reason. Are there any u= ser cases to use microseconds?

11. Add leaf 'dscp' to /twamp-light/twamp= -light-session-sender/test-session*. This is the leaf moved out from g= rouping session-light-parameters.

GIM>> As noted in response #5, the change may = limit ability to run concurrent TWAMP Test sessions per CoS. I consider tha= t to be valuable mode but would like to hear from network operators if that= is indeed useful information.=C2=A0

12. Move leaves 'ref-wait', 'reflecto= r-light-mode-state' and 'dscp-handling-mode' from /twamp-light/= twamp-light-session-reflector to /twamp-light/twamp-light-session= -reflector/test-session*. These three attributes should be session specific. Different session could= have different values. They are not common attributes.

GIM>> Agree, will make it in the next update.= =C2=A0

13. Add leaf 'dscp' to /twamp-light/twamp= -light-session-reflector/test-session*. This is the leaf moved ou= t from grouping session-light-parameters. Besides the movement, added a 'when' condition to the leaf 'dscp'. This leaf is only v= alid when the dscp-handling-mode is 'use-configured-value'.<= /u>

GIM>> As response to #5.=C2=A0

14. Modify leaf /twamp-light-state/twamp-lig= ht-session-sender-state/test-session-state*/current-stats/number-= of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless.

GIM>> Similar to #3.=C2=A0

15. Modify leaf /twamp-light-state/twamp-lig= ht-session-sender-state/test-session-state*/current-stats/interva= l. Change the units from microseconds to milliseconds.

GIM>> I think that microseconds is reasonable.= =C2=A0

16. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/current-stats/. These are the new statistics for stateful reflector.

GIM>> Thank you, will be coming in the next up= date.=C2=A0

17. Remove leaf loss-packet in /twamp-light-state= /twamp-light-session-sender-state/test-session-state*/current-stats. The loss packeted is replaced with 'two-way-packet-loss' stated above.

GIM>> Agree.=C2=A0

18. Modify leaf to /twamp-light-state/twamp-= light-session-sender-state/test-session-state*/history-stats*/int= erval. Change the units from microseconds to milliseconds.

GIM>> I think that will limit applicability of= TWAMP Test.=C2=A0

19. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/history-stats*/. These are the new statistics for stateful reflector.

GIM>> Agree.

=C2=A0

Thanks,

Wei Luo

=C2=A0


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


--001a11c17b32182daf054b3da982-- From nobody Tue Mar 21 06:38:31 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E401298B7 for ; Tue, 21 Mar 2017 06:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 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, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5iboWP7OLNCu for ; Tue, 21 Mar 2017 06:38:25 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F61D129871 for ; Tue, 21 Mar 2017 06:38:24 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id x37so151821148ota.2 for ; Tue, 21 Mar 2017 06:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3VAMsg6FpZHqD8L7Gn94TaSoNMcvM+c6BEmX2KtQ/PI=; b=KxWxpwUyxob7uJBp0PodQrSvMKiKG+hbreuSPz8rMEOLupSLG/satAv+HsorVxJwZ9 j9irsof0RnvAOcQxxPWNQ1DemxmQ0i9nGmccss773Uon+P7SGrqxI5gfaPcm2P9Lzfkv fdlRCBf48pfC5N0KYWkxAO0N4f5cFFeRorayneSxDzDrcoYXyI4N3E6YftcodYuj6zSI eyytBJxPgGcQq2qEnMkCj5O3GRdyA3dJzf36hqr7qhE4Hq8V49L1WvoTjh2JxruNjz+v UPW0WMuc0EdNC4pQ3Wb/4eUD6mgNsuGE9gdX3bB1ExWw9rREY63YpHEWR1lFZ0AwZnvz Bjrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3VAMsg6FpZHqD8L7Gn94TaSoNMcvM+c6BEmX2KtQ/PI=; b=sOpwIGO2LbNx2Mz8mn5ULJP2ZB3sJaqXNUFu5V0X2/T4uu20fw2A+5ti6SljZ73LIa MnZ63SSkC9DhAtREWzpHPTDOvYFWi3NWEwcMToVz4kjGHZSodxwF5nL5T7WjBzRl+29x ydW9ZnttLp3GdgwzvUsjqP1QGVbO0hFqgK/N6eVnNS6eZh0rrSnz02Qz0WcPV/dxDBTE XWZxCSr9vozOeB09jgN46kETwcXhfLbPdu/4RlrwavOIZt+y6nspGE7+hZEXQOzwBcXU HWJTitjld669Sh3NEg3fYAcPYHazAbIu7cCYCApVwBgn36o+a7Ndsg6d1zuq7YrehNk9 BTPA== X-Gm-Message-State: AFeK/H2ESXfjdqd2FYB5UGXvhSXwDsUc7ITq0wEa4woPtDAGMvZMUSLbXLTIepINvUGFYAM7jvgDx8FgQRwsrg== X-Received: by 10.157.1.247 with SMTP id e110mr17214622ote.40.1490103504269; Tue, 21 Mar 2017 06:38:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Tue, 21 Mar 2017 06:38:23 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Tue, 21 Mar 2017 08:38:23 -0500 Message-ID: To: Henrik Nydell Cc: Wei Luo S , "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03b82a0cf8e6054b3dc261 Archived-At: Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 13:38:30 -0000 --94eb2c03b82a0cf8e6054b3dc261 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Henrik, many thanks for sharing your field, from the trenches experience. I'll send more detailed notes bit later but just wanted to take up on DSCP monitoring topic. I'd refer to RFC 7750 that defined extension to TWAMP to monitor DSCP far- and near-end. And in draft-bailmir-ippm-twamp-dscp-ctrl-mon we took the idea further to support DSCP testing in controlled manner. Greatly appreciate your comments on these documents, ideas. Kind regards, Greg On Tue, Mar 21, 2017 at 7:21 AM, Henrik Nydell wrote= : > Some comments from the "field" as Accedian has several hundred thousand > TWAMP sessions running (continously) at numerous Tier one mobile/fixed > operators globally. > > On Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S > wrote: > >> Hi Greg, >> >> >> >> Thanks a lot for your response. Please see my reply inline tagged [WEI>>= ]. >> >> >> >> Regards, >> >> Wei Luo >> >> >> >> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com] >> *Sent:* Tuesday, March 21, 2017 1:16 AM >> *To:* Wei Luo S >> *Cc:* ippm@ietf.org; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org >> *Subject:* Re: Some though on draft-mirsky-ippm-twamp-light-yang-07 >> >> >> >> Hi Wei Luo, >> >> many thanks for your thorough review and the most helpful comments to th= e >> TWAMP Light(Test) model. Please find my answers, notes in-line tagged GI= M>>. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S >> wrote: >> >> Hi Greg & Adrian, >> >> >> >> This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. >> The current TWAMP Light YANG model is well defined. Thanks for your grea= t >> job. >> >> But by working closely with our customers, we got some new user cases on >> TWAMP light. I believe these user cases are valuable and popular enough = to >> be modeled in TWAMP Light YANG. I hope I can be a contributor and co-wo= rk >> with you move this draft forward. >> >> I drafted a new version of the TWAMP light YANG model based on version >> ietf-twamp-light@2017-02-13.yang. Could you please comments on it? Any >> discussion is welcome. >> >> The draft yang model and tree is attached. To make you find the updates >> quickly, I highlighted all the updates in file >> ietf-twamp-light-weiluo.pdf. >> >> >> >> The following are the list of main updates: >> >> *1. Add a new typedef: percent. This is a new type defined for packet >> loss ratio.* >> >> Consideration: >> >> 1). From the customer perspective, packet loss ratio is a more meaningfu= l >> data. In most of the time, the absolute number is meaningless to user, >> especially they do the TWAMP test continuously. They are more care about >> the ratio than the absolute number. So adding it makes this model more >> friendly to customer; >> >> 2). From the service layer assurance(SLA) perspective, the packet loss >> ratio is a major measures. So with adding packet loss ratio in model, th= e >> TWAMP can work in SLA framework more smoothly. >> >> 3). It seems some similar protocol=E2=80=99s YANG model has the same def= inition, >> e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99, >> https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf. >> >> Agreed packet loss is important, however another important loss metric i= s > loss burst size (max/min) and number of loss bursts. A loss burst of 10 > consecutive TWAMP-test packets can be deemed more serious than 10 lost > packets spread evenly over the report interval. > >> GIM>> Indeed, packet loss more often expressed as packet loss ratio >> rather than as the absolute number. It would be most helpful to hear fro= m >> network operators if they see introduction of Packet Loss Ratio into the >> TWAMP model helpful. >> >> *2. Add a new typedef: state-mode. It defines a common type for >> stateful/stateless reflector. This type will be used in both sender sess= ion >> and reflector session.* >> >> Consideration: >> >> If the reflector is stateful, the TWAMP light can measure more items, >> e.g. one way packet loss. So for sender, the stats calculation and show = is >> different. When the reflector is stateless, it doesn=E2=80=99t need to c= alculate >> the one way packet loss. The one way packet loss is invalid and shouldn= =E2=80=99t >> be presented to customer. When the reflector is stateless, the sender ne= eds >> to calculate the one way packet loss. And the data should be present to >> customer. So this is used as a =E2=80=98when=E2=80=99 condition in the m= odel=E2=80=99s RO tree. >> >> GIM>> Yes, if Session-Sender is aware of the mode corresponding >> Session-Reflector operates, the sender may avoid calculation of some >> performance metrics, e.g., one-way packet loss. On the other hand, the >> orchestrator is aware of the state-mode and should be capable to properl= y >> use metrics reported by the Session-Sender. >> >> [WEI>>] Yes, the orchestrator could know that. But from the model side, >> this is not correct. The model should represent the right behavior and >> shouldn=E2=80=99t do assumption on orchestrator. >> > I agree the model should describe both one-way loss metrics and roundtrip > loss metrics, and the sender should be able to use either mode when > calculating, potentially also populating the roundtrip delay values with > proper t1-t0 + t3-t2 values, as well as reporting the t2-t1 values that > would indicate buffer load/CPU load in the TWAMP responders processing ti= me. > >> *3. Add a new typedef: send-mode. This is a new type for sender session. >> It makes the sender session can send packet continuously and monitor the >> network all the time.* >> >> Consideration: >> >> The user case is that: the user runs TWAMP light sessions to watch links >> quality continuously. The session number could be very big. These TWAMP >> sessions are managed by SLA framework or similar. SLA retrieves the stat= s >> from TWAMP periodically, e.g. 15mins. In other words, all the performanc= e >> metrics are calculated based on the packets sent/received within 15mins. >> This makes the calculation become possible. With the periodical stats da= ta, >> the Network Management software can do further actions if some abnormal >> stats observed. This is a more general user case in customer site. Whil= e >> the non-continuous TWAMP sender session is generally used for debugging >> purpose on a link. >> >> GIM>> I think that support of continuous measurement is in LMAP domain, >> not for TWAMP Test data model. To conduct continuous measurement he LMAP >> Controller, in my opinion, programs the Measurement Agent to perform TWA= MP >> Test session with certain set of parameters and repeat it without any >> interval (interval =3D 0). >> > > Many operators use TWAMP in continous mode, not only with Accedian test > points and report at fixed intervals, typically ranging from 5s to 5 or 1= 5 > minutes, with 1-minute being the most popular granularity currently. The > advantage is that the result calculation can be handled separately from t= he > TWAMP-test sending/recieving, so that there is no parallelism required to > monitor 24/7. If a start-stop-based methodology is used, the sender needs > to start up the new test session even before the previous one has ended, > since the previous session needs to wait X seconds (or at least Y 100s of > milliseconds) before it stops waiting for packets to come back. And this > new session needs to have a different signature in order for the sender t= o > discern which packets belong to the previous interval and which belong to > the current. > > In a continous test-model, the sender can just simply record the sequence > number of the last packet transmitted in the interval to be reported, wai= t > for it to come back, or a MAXTIME, then report that result, while > continuing to transmit for the next interval. > > If the "interval=3D=3D0" parameter is intended to be used for continous t= ype > tests, then what parameter should indicate to the sender at what interval= s > to produce results? > >> *4. Add a new group: packet-loss-statistics. It grouping two packet loss >> statistics: loss-count and loss-ratio. This group will be used in RO sta= ts >> tree.* >> >> GIM>> I'd like to continue discussion. >> >> [WEI>>] OK. >> >> *5. Move leaf dscp out from grouping session-light-parameters. The leaf >> dscp is only valid when the dscp-handling-mode is use-configured-value. = A >> when condition shall be added to it. So it can=E2=80=99t be in this grou= p.* >> >> GIM>> I'm concerned that then the model will not be able to support >> concurrent TWAMP Test sessions between the same pair of Test Points (IP >> address+port number) at different CoS markings. >> >> [WEI>>] Actually, I have concern on using five tuple(IP address+port >> number+dscp) to identify a TWAMP test session. The DSCP is not a constan= t >> value in packet. It could be modified by the routers in the path. For >> example, the sender has two sessions: session A=E2=80=99s five tuple is: >> Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs2. = Session B=E2=80=99s >> five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D5000= 1, >> DSCP=3Dcs3. The only difference between session A and session B is DSCP.= If >> the test packet=E2=80=99s DSCP of session B is modified to cs2 by a rout= er in the >> path. The five tuples are exactly the same for reflector. It can=E2=80= =99t >> differentiate which packet is from session A, which packet is from sessi= on >> B. It could mess the reflector=E2=80=99s session sequence number. And al= so, the >> sender will be messed because the received reply packet=E2=80=99s five t= uple are >> exactly the same. >> >> So I think it=E2=80=99s more reasonable to use four tuple to identify a = session. >> > > Yes, this would be appreciated by users. Changes in DSCP is a reasonably > common network error that users can detect with continous TWAMP monitorin= g, > thus it is good to not include the DSCP value as part of the "session > identifiier" but instead use 4-tuple with UDP source port to identify > several parallel flows between the same sender and responder. > >> *6. Add leaf 'session-packet-send-mode' to >> /twamp-light/twamp-light-session-sender/test-session*. This leaf specifi= es >> the sender session's packet send mode: continuous or non-continuous.* >> >> GIM>> As discussed in #3, I think that it is already part of LMAP YANG >> model. >> >> *7. Add leaf 'reflector-light-mode-state' to >> /twamp-light/twamp-light-session-sender/test-session*. This leaf indicat= es >> the the reflector's mode: stateful or stateless. If the reflector's mode= is >> stateful. Two one way packet loss statistics can be got: >> one-way-packet-loss-far-end, one-way-packet-loss-near-end.* >> >> Consideration: >> >> Only valid data should be presented to user. Otherwise it could >> misleading user in some cases. >> >> GIM>> A in response to #2. >> >> *8. Modify leaf >> /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. >> Add a 'when' condition to this leaf. When send-mode is 'continuous', the >> leaf number-of-packets is meaningless. So add a 'when' condition to limi= t >> it. Besides, added a default value =E2=80=9810=E2=80=99 to it. When the= send-mode is >> 'non-continuous', the session can't work with an empty number-of-packets= .* >> >> GIM>> As I've noted in #3. Will add default. >> >> *9. Add leaf time out to >> /twamp-light/twamp-light-session-sender/test-session*. A timeout mechani= sm >> is needed when the sender session can't get all the reply packets for a >> long time.* >> >> GIM>> Thank you, will add in the next update. >> >> *10. Modify leaf >> /twamp-light/twamp-light-session-sender/test-session*/interval. Change t= he >> units from =E2=80=98microseconds=E2=80=99 to =E2=80=98milliseconds=E2=80= =99. Add a default value 1000. * >> >> Consideration: >> >> 1). The aim of TWAMP is to measure network quality, but not fast >> failure detection. So a millisecond packet interval is enough. >> >> 2). Interval is a necessary parameter for a session. A sender sessio= n >> can't work with an empty packet send interval. So added a default value = to >> it. >> >> GIM>> Thank you. We've made units of interval microseconds in the last >> update already. I think that changing to milliseconds may be too >> restrictive, limit use cases for TWAMP Test. Will add default value with >> the next update. >> >> [WEI>>] Sorry, I do not see the reason. Are there any user cases to use >> microseconds? >> >> *11. Add leaf 'dscp' to >> /twamp-light/twamp-light-session-sender/test-session*. This is the leaf >> moved out from grouping session-light-parameters.* >> >> GIM>> As noted in response #5, the change may limit ability to run >> concurrent TWAMP Test sessions per CoS. I consider that to be valuable m= ode >> but would like to hear from network operators if that is indeed useful >> information. >> > > See my comment above. I argue that it is useful to keep track of changing > DSCP values, and treating DSCP as a metric of the TWAMP Session just like > loss and delay > >> *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and >> 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to >> /twamp-light/twamp-light-session-reflector/test-session*. These three >> attributes should be session specific. Different session could have >> different values. They are not common attributes.* >> >> GIM>> Agree, will make it in the next update. >> >> *13. Add leaf 'dscp' to >> /twamp-light/twamp-light-session-reflector/test-session*. This is the le= af >> moved out from grouping session-light-parameters. Besides the movement, >> added a 'when' condition to the leaf 'dscp'. This leaf is only valid whe= n >> the dscp-handling-mode is 'use-configured-value'.* >> >> GIM>> As response to #5. >> >> *14. Modify leaf >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats/number-of-packets. >> Add a 'when' condition to this leaf. When send-mode is 'continuous', the >> leaf number-of-packets is meaningless.* >> >> GIM>> Similar to #3. >> >> *15. Modify leaf >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats/interval. >> Change the units from microseconds to milliseconds.* >> >> GIM>> I think that microseconds is reasonable. >> >> *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and >> 'one-way-packet-loss-near-end' to >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats/. >> These are the new statistics for stateful reflector.* >> >> GIM>> Thank you, will be coming in the next update. >> >> *17. Remove leaf loss-packet in >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= current-stats. >> The loss packeted is replaced with 'two-way-packet-loss' stated above.* >> >> GIM>> Agree. >> >> *18. Modify leaf to >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= history-stats*/interval. >> Change the units from microseconds to milliseconds.* >> >> GIM>> I think that will limit applicability of TWAMP Test. >> >> *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and >> 'one-way-packet-loss-near-end' to >> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/= history-stats*/. >> These are the new statistics for stateful reflector.* >> >> GIM>> Agree. >> >> >> >> Thanks, >> >> Wei Luo >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> > > > -- > > > [image: Accedian.com] > > Henrik Nydell > > Sr Manager Global Strategy & Solutions > > Cell > > Email > > Skype > > +46 709845992 <+46%2070%20984%2059%2092> > > hnydell@accedian.com > > h nydell > > > > > > > > > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --94eb2c03b82a0cf8e6054b3dc261 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Henrik,
many thanks for sharing your field, from th= e trenches experience. I'll send more detailed notes bit later but just= wanted to take up on DSCP monitoring topic. I'd refer to RFC 7750 that= defined extension to TWAMP to monitor DSCP far- and near-end. And in=C2=A0= draft-bailmir-ippm-twamp-dscp-c= trl-mon we took the idea further to support DSCP testing in controlled mann= er. Greatly appreciate your comments on these documents, ideas.

Kind regards,
Greg

On Tue, Mar 21, 2017 at 7:2= 1 AM, Henrik Nydell <hnydell@accedian.com> wrote:
Some comments from the "fi= eld" as Accedian has several hundred thousand TWAMP sessions running (= continously) at numerous Tier one mobile/fixed operators globally.

On = Tue, Mar 21, 2017 at 11:52 AM, Wei Luo S <wei.s.luo@ericsson.com&= gt; wrote:

Hi Greg,

=C2=A0

Thanks a lot for your response. Please see my reply= inline tagged [WEI>>].

=C2=A0

Regards,

Wei Luo

=C2=A0

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, March 21, 2017 1:16 AM
To: Wei Luo S <wei.s.luo@ericsson.com>
Cc: ippm@ietf.org= ; draft-mirsky-ippm-twamp-light-yang@tools.ietf.org
Subject: Re: Some though on draft-mirsky-ippm-twamp-light-yang-= 07

=C2=A0

Hi Wei Luo,

many thanks for your thorough review and the most he= lpful comments to the TWAMP Light(Test) model. Please find my answers, note= s in-line tagged GIM>>.

=C2=A0

Regards,

Greg

=C2=A0

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <wei.s.luo@ericsson.c= om> wrote:

Hi Greg & Adrian,

=C2=A0

This is Wei Luo from Ericsson. I work on TWAMP light= area in Ericsson. The current TWAMP Light YANG model is well defined. Than= ks for your great job.

But by working closely with our customers, we got so= me new user cases on TWAMP light. I believe these user cases are valuable a= nd popular enough to be modeled in TWAMP Light YANG. I hope I can be a contributor =C2=A0and co-work with you move this draft f= orward.=C2=A0

I =C2=A0drafted a new version of the TWAMP light YAN= G model based on version ietf-= twamp-light@2017-02-13.yang. Could you please comments on it? Any = discussion is welcome.

The draft yang model and tree is attached. To make y= ou find the updates quickly, I highlighted all the updates in fil= e ietf-twamp-light-weiluo.pdf.

=C2=A0

The following are the list of main updates:

1. Add a new typedef: percent. This is a new type= defined for packet loss ratio.

Consideration:

1). From the customer perspective, packet loss ratio is a more meaningful d= ata. In most of the time, the absolute number is meaningless to user, espec= ially they do the TWAMP test continuously. They are more care about the rat= io than the absolute number. So adding it makes this model more friendly to customer;

2). From the service layer assurance(SLA) perspective, the packet loss rati= o is a major measures. So with adding packet loss ratio in model, the TWAMP= can work in SLA framework more smoothly.

3). It seems some similar protocol=E2=80=99s YANG model has the same defini= tion, e.g. =E2=80=98Service OAM Performance Monitoring YANG Module=E2=80=99= , https://www.mef.net/Assets/Technical_= Specifications/PDF/MEF_39.pdf.

=
Agreed p= acket loss is important, however another important loss metric is loss burs= t size (max/min) and number of loss bursts. A loss burst of 10 consecutive = TWAMP-test packets can be deemed more serious than 10 lost packets spread e= venly over the report interval.

GIM>> Indeed, packet loss more often expressed= as packet loss ratio rather than as the absolute number. It would be most = helpful to hear from network operators if they see introduction of Packet L= oss Ratio into the TWAMP model helpful.

2. Add a new typedef: state-mode. It defines a co= mmon type for stateful/stateless reflector. This type will be used in both = sender session and reflector session.

Consideration:

If the reflector is stateful, the TWAMP light can me= asure more items, e.g. one way packet loss. So for sender, the stats calcul= ation and show is different. When the reflector is stateless, it doesn=E2=80=99t need to calculate the one way packet loss. T= he one way packet loss is invalid and shouldn=E2=80=99t be presented to cus= tomer. When the reflector is stateless, the sender needs to calculate the o= ne way packet loss. And the data should be present to customer. So this is used as a =E2=80=98when=E2=80=99 condition in the = model=E2=80=99s RO tree.

GIM>> Yes, if Session-Sender is aware of the m= ode corresponding Session-Reflector operates, the sender may avoid calculat= ion of some performance metrics, e.g., one-way packet loss. On the other ha= nd, the orchestrator is aware of the state-mode and should be capable to properly use metrics reported by the Session-Send= er.

[WEI>>] Yes, the orchestrator could know that. But from= the model side, this is not correct.=C2=A0 The model should represent the = right behavior and shouldn=E2=80=99t do assumption on orchestrator.<= /p>

I agree the= model should describe both one-way loss metrics and roundtrip loss metrics= , and the sender should be able to use either mode when calculating, potent= ially also populating the roundtrip delay values with proper t1-t0 + t3-t2 = values, as well as reporting the t2-t1 values that would indicate buffer lo= ad/CPU load in the TWAMP responders processing time.
=

3. Add a new typedef: send-mode. This is a new ty= pe for sender session. It makes the sender session can send packet continuo= usly and monitor the network all the time.

Consideration:

The user case is that: the user runs TWAMP light ses= sions to watch links quality continuously. The session number could be very= big. These TWAMP sessions are managed by SLA framework or similar. SLA retrieves the stats from TWAMP periodically, e.g. 15mins. = In other words, all the performance metrics are calculated based on the pac= kets sent/received within 15mins. This makes the calculation become possibl= e. With the periodical stats data, the Network Management software can do further actions if some abnormal st= ats observed.=C2=A0 This is a more general user case in customer site. Whil= e the non-continuous TWAMP sender session is generally used for debugging p= urpose on a link. =C2=A0

GIM>> I think that support of continuous measu= rement is in LMAP domain, not for TWAMP Test data model. To conduct continu= ous measurement he LMAP Controller, in my opinion, programs the Measurement= Agent to perform TWAMP Test session with certain set of parameters and repeat it without any interval (interval =3D= 0).


Many operators use TWAMP in continous mode, not only with A= ccedian test points and report at fixed intervals, typically ranging from 5= s to 5 or 15 minutes, with 1-minute being the most popular granularity curr= ently. The advantage is that the result calculation can be handled separate= ly from the TWAMP-test sending/recieving, so that there is no parallelism r= equired to monitor 24/7. If a start-stop-based methodology is used, the sen= der needs to start up the new test session even before the previous one has= ended, since the previous session needs to wait X seconds (or at least Y 1= 00s of milliseconds) before it stops waiting for packets to come back. And = this new session needs to have a different signature in order for the sende= r to discern which packets belong to the previous interval and which belong= to the current.

In a continous test-model, the se= nder can just simply record the sequence number of the last packet transmit= ted in the interval to be reported, wait for it to come back, or a MAXTIME,= then report that result, while continuing to transmit for the next interva= l.

If the "interval=3D=3D0" parameter is= intended to be used for continous type tests, then what parameter should i= ndicate to the sender at what intervals to produce results? =C2=A0

<= u>

4. Add a new group: packet-loss-statistics. It gr= ouping two packet loss statistics: loss-count and loss-ratio. This group wi= ll be used in RO stats tree.

GIM>> I'd like to continue discussion.=C2= =A0

[WEI>>] OK.

5. Move leaf dscp out from grouping session-light= -parameters. The leaf dscp is only valid when the dscp-handling-mode is use= -configured-value. A when condition shall be added to it. So it can=E2=80=99t be in this group.

GIM>> I'm concerned that then the model wi= ll not be able to support concurrent TWAMP Test sessions between the same p= air of Test Points (IP address+port number) at different CoS markings.=C2= =A0

[WEI>>] Actually, I have concern on using five tuple(IP= address+port number+dscp) to identify a TWAMP test session. The DSCP is no= t a constant value in packet. It could be modified by the routers in the path. For example, the sender has two sessions: session A=E2=80=99s= five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.2, Sport=3D50000, Dport=3D50001,= DSCP=3Dcs2. Session B=E2=80=99s five tuple is: Sip=3D1.1.1.1, Dip=3D2.2.2.= 2, Sport=3D50000, Dport=3D50001, DSCP=3Dcs3. The only difference between session A and session B is DSCP. If the test packet=E2=80=99s DSCP of sess= ion B is modified to cs2 by a router in the path. The five tuples are exact= ly the same for reflector. It can=E2=80=99t differentiate which packet is f= rom session A, which packet is from session B. It could mess the reflector=E2=80=99s session sequence number. And also, the = sender will be messed because the received reply packet=E2=80=99s five tupl= e are exactly the same.

So I think it=E2=80=99s more reasonable to use four tuple to identif= y a session.


Yes, this would be appreciated by users. Changes in= DSCP is a reasonably common network error that users can detect with conti= nous TWAMP monitoring, thus it is good to not include the DSCP value as par= t of the "session identifiier" but instead use 4-tuple with UDP s= ource port to identify several parallel flows between the same sender and r= esponder.=C2=A0

6. Add leaf 'session-packet-send-mode' to= /twamp-light/twamp-light-session-sender/test-session*. This leaf spec= ifies the sender session's packet send mode: continuous or non-continuo= us.

GIM>> As discussed in #3, I think that it is a= lready part of LMAP YANG model.=C2=A0

7. Add leaf 'reflector-light-mode-state' = to /twamp-light/twamp-light-session-sender/test-session*. This leaf in= dicates the the reflector's mode: stateful or stateless. If the reflector's mode is stateful. Two one way packet loss statistics can b= e got: one-way-packet-loss-far-end, one-way-packet-loss-near-end.

Consideration: =C2=A0

Only valid data should be presented to user. Otherwi= se it could misleading user in some cases.

GIM>> A in response to #2.=C2=A0=

8. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/number-of-packets. Add a 'when' condi= tion to this leaf. When send-mode is 'continuous', the leaf number-= of-packets is meaningless. So add a 'when' condition to limit it.=C2=A0 Besid= es, added a default value =E2=80=9810=E2=80=99 to it. When the send-mode is= 'non-continuous', the session can't work with an empty number-= of-packets.

GIM>> As I've noted in #3. Will add defaul= t.=C2=A0

9. Add leaf time out to /twamp-light/twamp-light-= session-sender/test-session*. A timeout mechanism is needed when the s= ender session can't get all the reply packets for a long time.

GIM>> Thank you, will add in the next update.= =C2=A0

10. Modify leaf /twamp-light/twamp-light-session-sender/test-session*/interval. Change the units from =E2=80=98mic= roseconds=E2=80=99 to =E2=80=98milliseconds=E2=80=99. Add a default value 1= 000.

Consideration:

=C2=A0=C2=A0=C2=A0 1). The aim of TWAMP is to measur= e network quality, but not fast failure detection. So a millisecond packet = interval is enough.

=C2=A0=C2=A0=C2=A0 2). Interval is a necessary param= eter for a session. A sender session can't work with an empty packet se= nd interval. So added a default value to it.

GIM>> Thank you. We've made units of inter= val microseconds in the last update already. I think that changing to milli= seconds may be too restrictive, limit use cases for TWAMP Test. Will add de= fault value with the next update.

[WEI>>] Sorry, I do not see the reason. Are there any u= ser cases to use microseconds?

11. Add leaf 'dscp' to /twamp-light/twamp= -light-session-sender/test-session*. This is the leaf moved out from g= rouping session-light-parameters.

GIM>> As noted in response #5, the change may = limit ability to run concurrent TWAMP Test sessions per CoS. I consider tha= t to be valuable mode but would like to hear from network operators if that= is indeed useful information.=C2=A0


See my comment above. I arg= ue that it is useful to keep track of changing DSCP values, and treating DS= CP as a metric of the TWAMP Session just like loss and delay=C2=A0

<= u>

12. Move leaves 'ref-wait', 'reflecto= r-light-mode-state' and 'dscp-handling-mode' from /twamp-light/= twamp-light-session-reflector to /twamp-light/twamp-light-session= -reflector/test-session*. These three attributes should be session specific. Different session could= have different values. They are not common attributes.

GIM>> Agree, will make it in the next update.= =C2=A0

13. Add leaf 'dscp' to /twamp-light/twamp= -light-session-reflector/test-session*. This is the leaf moved out fro= m grouping session-light-parameters. Besides the movement, added a 'when' condition to the leaf 'dscp'. This leaf is only v= alid when the dscp-handling-mode is 'use-configured-value'.<= /u>

GIM>> As response to #5.=C2=A0

14. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/number-= of-packets. Add a 'when' condition to this leaf. When send-mode is 'continuous', the leaf number-of-packets is meaningless.

GIM>> Similar to #3.=C2=A0

15. Modify leaf /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/interva= l. Change the units from microseconds to milliseconds.

GIM>> I think that microseconds is reasonable.= =C2=A0

16. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/current-stats/. These are the new statistics for stateful reflector.

GIM>> Thank you, will be coming in the next up= date.=C2=A0

17. Remove leaf loss-packet in /twamp-light-state= /twamp-light-session-sender-state/test-session-state*/current-sta= ts. The loss packeted is replaced with 'two-way-packet-loss' stated above.

GIM>> Agree.=C2=A0

18. Modify leaf to /twamp-light-state/twamp-light= -session-sender-state/test-session-state*/history-stats*/int= erval. Change the units from microseconds to milliseconds.

GIM>> I think that will limit applicability of= TWAMP Test.=C2=A0

19. Add leaves 'two-way-packet-loss', = 9;one-way-packet-loss-far-end' and 'one-way-packet-loss-near-end= 9; to /twamp-light-state/twamp-light-session-sender-state/test-se= ssion-state*/history-stats*/. These are the new statistics for stateful reflector.

GIM>> Agree.

=C2=A0

Thanks,

Wei Luo

=C2=A0


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




--

<= /p>


3D"Acced=

Henrik N= ydell

Sr Manager Global Strategy & Solutions


Cell

Email

Skype=

+46 709845992

hnydell@accedian.com

hnydell

<= /table>


= =C2= =A0 =C2=A0 =C2=A0 =C2=A0



<= /div>

Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.


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


--94eb2c03b82a0cf8e6054b3dc261-- From nobody Tue Mar 21 09:07:24 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C50129A99 for ; Tue, 21 Mar 2017 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HCzNmyFf_DHm for ; Tue, 21 Mar 2017 09:07:21 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6152C129AC9 for ; Tue, 21 Mar 2017 09:07:21 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id y193so68878757lfd.3 for ; Tue, 21 Mar 2017 09:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KezDg9e86ymp8oVcqBVWwHhA6/lPJncVOKF+x47KlaI=; b=pN52H7ZETSD3BfEgSDQmHPrQX5ino1XlM7V9mxvlYUmWPIAn+xSnJM2BMMmywKyO5j ELcw9XG0jxRLP93xvUXDikfPZ9XTm9KI61TToyRgndmshpkIyo/9FrnZZ+7CJr9nF+sW FI+fbjxraKL3AiGc2PGnWQAADtFW1EqBEpn1yVSPBsYfVI4O1kOjcst/fcoCdV2WccXs olkunD85z2Py4Xi0hJTfz/gHSOVY1t8rpRMmibZasFyrklheTCgCYKB5sEnTGB12XG6m W8fqm5GrPEUR88J+QxYTQysq4NNde7wydV/HXgQdNKkZyb7uMhRTKXMGapNvytia+ueN 3LzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KezDg9e86ymp8oVcqBVWwHhA6/lPJncVOKF+x47KlaI=; b=W+nTOwUW0hFRa0jNFn1LofFtGk9WoXcO+GSytyZf4rV8T+UeTPU7NBqsTUE5v5g8AW 8SdvgSdc0dZLHqvVr1ER7DoToPEF0NgpaaiS5K5dI8W9TEghWLSAm46XBTzrxU0EBLnV qgua9DJVP2oOqrlyde3NbYJXCVYtLSpKOnr+Zjk7VZ+T0ubF9ak8PRPTpHhtKv7r3/VL Y2kSuWzBNtcJRlIBrYYVegZIwOjVVb5uKFINQ7Z/nWhV7EL9fKU7pZp5naDHTNArfIRu KDEYjkk0noIG2Z/T54ggATVaks3awaTnr5jO/dR4xl2nlIwzTemcvd1SHIprBgGv1tyY 8N+Q== X-Gm-Message-State: AFeK/H0bz6FPPDh/23rvSM9zV9dA0a0pgETAGZoYJS5lJau3HBVCiLs1QRqHZhXaY6w0FIm5zgYx2+HSZhiAZw== X-Received: by 10.46.77.150 with SMTP id c22mr11659424ljd.114.1490112439275; Tue, 21 Mar 2017 09:07:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.86 with HTTP; Tue, 21 Mar 2017 09:07:18 -0700 (PDT) From: Ron Even Date: Tue, 21 Mar 2017 11:07:18 -0500 Message-ID: To: ippm@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1abc029e5c0b054b3fd6ab Archived-At: Subject: [ippm] review of draft-mirsky-ippm-twamp-refl-registered-port-01 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 16:07:23 -0000 --94eb2c1abc029e5c0b054b3fd6ab Content-Type: text/plain; charset=UTF-8 Hi, I reviewed the document and support the allocation of well known port for the described case. I agree that such port will allow a better deplyoment of TWAMP light Thanks Roni Even --94eb2c1abc029e5c0b054b3fd6ab Content-Type: text/html; charset=UTF-8
Hi,
I reviewed the document and support the allocation of well known port for the described case.
I agree that such port will allow a better deplyoment of TWAMP light
Thanks
Roni Even
--94eb2c1abc029e5c0b054b3fd6ab-- From guiu.fabregas@nokia.com Wed Mar 22 11:34:20 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CCD12986E for ; Wed, 22 Mar 2017 11:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 Jog4Pu_E9EKm for ; Wed, 22 Mar 2017 11:34:16 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10111.outbound.protection.outlook.com [40.107.1.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD451294E1 for ; Wed, 22 Mar 2017 11:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=64ot+/KB4aPu6H6SN2rDAyYLU2c4xo8cuuvidJcMI9E=; b=Azzg4gq5CJQN4DbkkAVUmJ9Rm+KjUWFuEIrvHxx8ibhA09uByOydyUhPQak5zfGakHkQsslDS5B02Pvyt4OjuitdJVb6KF5lSbGrH+4IORGKiJs2X1jHc/byHFcDAFxmwT3MKrfFVco6wWBzUG4RzYM72wDeiO9WiFCzfk18E+s= Received: from VI1PR0701MB2509.eurprd07.prod.outlook.com (10.168.139.22) by VI1PR0701MB2510.eurprd07.prod.outlook.com (10.168.139.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Wed, 22 Mar 2017 18:34:13 +0000 Received: from VI1PR0701MB2509.eurprd07.prod.outlook.com ([10.168.139.22]) by VI1PR0701MB2509.eurprd07.prod.outlook.com ([10.168.139.22]) with mapi id 15.01.0991.013; Wed, 22 Mar 2017 18:34:13 +0000 From: "Fabregas, Guiu (Nokia - ES/Madrid)" To: "ippm@ietf.org" Thread-Topic: Support for draft-mirsky-ippm-twamp-refl-registered-port Thread-Index: AQHSozrnbBlLjOaXgk65WPMhErBCnQ== Date: Wed, 22 Mar 2017 18:34:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [208.184.163.248] x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2510; 7:iJoYg62w8k7z5BAptG3N0KC8GKm1inNfPAUlwy7Jk83UoGTrF/UV82hhHbcWEAMyuNKA55zWvGXmFJCnICQWQX4q4ov+bKHtQiPbUZDUaJ+HGUEJY83npjQRXbxI6g8vHVinGQwktsooKba2ZIWDmqA7ragRC/fB3+ab4jV+cv9vdbXuVo4EWlnWItb7sBVnFbRXaekRobz2mIaZRZ1j3Pmk1egXW889Yy7OEykwuLz6Aoi3FnMe2bA+jS8vAJ494RRkcOCnk70wcRITpTE+dRlc+5bKZtsCpd0+i/zG66pu8fw3+2h6LOlOBmjShmLTY0pRiKC3aLyqC7wtfFyLrQ== x-ms-office365-filtering-correlation-id: f38a5a5e-aed0-4ded-7c8d-08d4715209d9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:VI1PR0701MB2510; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:VI1PR0701MB2510; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2510; x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(53754006)(8936002)(83716003)(122556002)(50226002)(82746002)(8676002)(3846002)(102836003)(7736002)(305945005)(66066001)(86362001)(81166006)(110136004)(38730400002)(1730700003)(189998001)(6116002)(77096006)(558084003)(50986999)(36756003)(6916009)(2351001)(5660300001)(2906002)(3660700001)(33656002)(3280700002)(53936002)(6436002)(230783001)(2501003)(6506006)(5640700003)(6512007)(6486002)(99286003)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2510; H:VI1PR0701MB2509.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 18:34:13.1706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2510 Archived-At: Subject: [ippm] Support for draft-mirsky-ippm-twamp-refl-registered-port X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 18:35:25 -0000 Hi all, I've gone through this draft and agree with the authors on the need of a we= ll known port for TWAMP, so I wanted to expres my support this work. It will considerably simplify a number of deployment scenarios related to T= WAMP light. Looking forward to seeing this draft progress. Thanks, Guiu From nobody Wed Mar 22 12:14:56 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A2A126BF6 for ; Wed, 22 Mar 2017 12:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian-com.20150623.gappssmtp.com 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 08kH57_Jt3fN for ; Wed, 22 Mar 2017 12:14:53 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F7E129501 for ; Wed, 22 Mar 2017 12:14:53 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id r203so50228978oib.3 for ; Wed, 22 Mar 2017 12:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mv6MhfhLmAYv0n25C/tj6DZU+47doqakTTzJXPiKF88=; b=dOSqhlCo6+W6xzrfF6DBEp7q1zM1Q5699TwKKwurYfLPiqYEfNhZiRRqP51+mgXcNe 3pDAjNY2ys0PPeDHANVinB+tqnqnLO0x6F4u9pQSyUcMLUNNN2dDfENnz8YHSeWyAT31 kblRKSVO0P6zscld19f7BSWt1Djl35oniPrlTlXNo+Zwqo4IxDeMVWcFwcrkT+KaaTrF R7gowifcDgN3qlSk2FDO+FM3ry1UZlvqpi7hCqfC+o6vhMOO6I06rdFwJeppXh7eW5dB Vl1viBgxVZTT+axO6wZvlg+IEXDqBmfCEMYDAMCRL0bmKRdIk/SfRM9PxwNqffi1rS9v R8CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mv6MhfhLmAYv0n25C/tj6DZU+47doqakTTzJXPiKF88=; b=uWuWQRYdzGhqfP3s1tO0NVymjrAlikuWKP876zWaKZSm73EM0D1qSAjpff674ZE9QM tynvJiOzZokMS5MEXljuRlagv4oGs+is2SPTaxHjD+HiOWiQKkhgo4/P6Pmut3fERKEa hFWlI4mubarvXOfHy5xoWs97ryf0AcZ9gcGJooczXmYBk9Y5woAuY/EBM6vKB0FAcTBa sxVV/5fbV+Wz6ZrFW91j2GglobTPJFi/jORdulSxSrMSEk1Jb/RMYsV8betJpUwSpMAW g9UAl0pkceCTsP0eppRP7lf29ugkCtqsgFsiEc3sukluZxjkf3KUE7xKnFp9HFIvot4z b4og== X-Gm-Message-State: AFeK/H2/oQpFWs7OwX3vp7qzYrhWZ6U9XydeVwJrPBDiyhbdPA4JferG5D47Aa0M7l4l1M3yho2/YpjZZ70VZzsxJ0Efr/I+eBnY/S2Y4j+V6VP99TmJ4VcXrzZA47uZW/h0 X-Received: by 10.202.252.1 with SMTP id a1mr20762083oii.40.1490210092426; Wed, 22 Mar 2017 12:14:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.51.153 with HTTP; Wed, 22 Mar 2017 12:14:51 -0700 (PDT) Received: by 10.157.51.153 with HTTP; Wed, 22 Mar 2017 12:14:51 -0700 (PDT) In-Reply-To: References: From: Henrik Nydell Date: Wed, 22 Mar 2017 20:14:51 +0100 Message-ID: To: "Fabregas, Guiu (Nokia - ES/Madrid)" Cc: ippm@ietf.org Content-Type: multipart/alternative; boundary=001a113b00c8337299054b5693ff Archived-At: Subject: Re: [ippm] Support for draft-mirsky-ippm-twamp-refl-registered-port X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 19:14:55 -0000 --001a113b00c8337299054b5693ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have seen that some vendors of TWAMP senders (I believe EXFO and possibly Spirent) use port UDP/862 as default port despite being defined only for the TCP portion of TWAMP-control. Has consideration within ippm been done on opting for that port to be used also for TWAMP-test or is there a preference for a higher (>1024) port number? On 22 Mar 2017 7:35 PM, "Fabregas, Guiu (Nokia - ES/Madrid)" < guiu.fabregas@nokia.com> wrote: > Hi all, > > I've gone through this draft and agree with the authors on the need of a > well known port for TWAMP, so I wanted to expres my support this work. > > It will considerably simplify a number of deployment scenarios related to > TWAMP light. > > Looking forward to seeing this draft progress. > > Thanks, > Guiu > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3= =A8ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le secret=20 professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de son= ou de ses=20 destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99il= vous=20 plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en d= =C3=A9truire tout=20 exemplaire. De plus, il vous est strictement interdit de le divulguer, de= =20 le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99= exp=C3=A9diteur.=20 Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the exclusive= =20 use of its addressee(s). If you receive this message in error, please=20 inform sender immediately and destroy any copy thereof. Furthermore, any=20 disclosure, distribution or copying of this message and/or any attachment= =20 hereto without the consent of the sender is strictly prohibited. Thank you. --001a113b00c8337299054b5693ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have seen that some vendors of TWAMP senders (I believe= EXFO and possibly Spirent) use port UDP/862 as default port despite being = defined only for the TCP portion of TWAMP-control. Has consideration within= ippm been done on opting for that port to be used also for TWAMP-test or i= s there a preference for a higher (>1024) port number?
=


=
On 22 Mar 2017 7:35 PM, "Fabregas, Guiu (No= kia - ES/Madrid)" <guiu.= fabregas@nokia.com> wrote:
Hi all,

I've gone through this draft and agree with the authors on the need of = a well known port for TWAMP, so I wanted to expres my support this work.
It will considerably simplify a number of deployment scenarios related to T= WAMP light.

Looking forward to seeing this draft progress.

Thanks,
Guiu

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

Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

--001a113b00c8337299054b5693ff-- From nobody Wed Mar 22 13:22:59 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E21B128BB6 for ; Wed, 22 Mar 2017 13:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 o4aY2rDVb72E for ; Wed, 22 Mar 2017 13:22:56 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47AC6128B4E for ; Wed, 22 Mar 2017 13:22:56 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id r203so50931083oib.3 for ; Wed, 22 Mar 2017 13:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YdWOCiEPUv+gZ/E7b5ftXSUVQ0lukRlVewQAeiy29ow=; b=itwJcc6LgHUMOt0I6AQ6038AzlGkUplwDKLEmxK2urMk4SGGdnNDlW+aXZBnSxwN0O 1VgNctEJaGslLIFj4zt8ab5mrsNGxq5lte6soREsJ98wAhPLUCo7tWbysYM0uwADHWrk ZFQw9ByJI4ayo8f2K9J40cki4j9KHqyi85s8WH5P/Q9P5VgzQV9O9XWKvpsja9Q7F4yg rUZ6SwmIEb712UtVsImHEnlx0rvuR16UJ/qZlWYOL9xGAw2cD2lUzaXxbyhupPpiWQgB /XMRNdGTpr/AHCtZbNE1WhDIX1MZV8cD09Fd47MV5J0eQVuVpLjY5HBeyUgDnCdmBBmc t7eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YdWOCiEPUv+gZ/E7b5ftXSUVQ0lukRlVewQAeiy29ow=; b=IssFyuzT+ZekbRRp4sGL73YinwIZpzg8nwkusVudGAy2OqvAjI/Zqx5vL/yIz/CmsV WvkoOUKWMsvZhOQmEXDULBW/BjKVgx2hao0gfudll43aeChnVSydTg2Io5AP0x8498nR nGFcSyGWWWWgjpvxuCRSZsrXQWdPIiusSnLz6ZcDFraaZ9P5Vv5Khs4OUvIojbh0f+o2 n4KdgCVl7skFRrdjx5QXzZjtUQ8GtbpvknEccI3Z383YPVOHOcUA9FR0dT6hOAaKfc7W OhzYQAtI7WHwegHX/pdS69ct0eIV127e0D2s2K28TdjNScaHttmHB2PdTDVaNX6l377L 0X2A== X-Gm-Message-State: AFeK/H387TX6AR9e+Hn4n4VnDe5AulAvoIfkc2As5MFDgOjYE1wLJVV9nOQ7KKJVEKRfsTRAsQGpAPqGFLiQZA== X-Received: by 10.202.181.7 with SMTP id e7mr7619424oif.60.1490214175659; Wed, 22 Mar 2017 13:22:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Wed, 22 Mar 2017 13:22:55 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Wed, 22 Mar 2017 15:22:55 -0500 Message-ID: To: Henrik Nydell Cc: "Fabregas, Guiu (Nokia - ES/Madrid)" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a113ce460945c72054b5786e3 Archived-At: Subject: Re: [ippm] Support for draft-mirsky-ippm-twamp-refl-registered-port X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:22:58 -0000 --001a113ce460945c72054b5786e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Henrik, thank you for very helpful insight into one of implementations. I know of other implementations that use proprietary, self-picked reflector port or ranges of port numbers. I hope that through discussion of this draft we can arrive to the standardized solution to ensure interoperability among confirming implementations. Regards, Greg On Wed, Mar 22, 2017 at 2:14 PM, Henrik Nydell wrote= : > I have seen that some vendors of TWAMP senders (I believe EXFO and > possibly Spirent) use port UDP/862 as default port despite being defined > only for the TCP portion of TWAMP-control. Has consideration within ippm > been done on opting for that port to be used also for TWAMP-test or is > there a preference for a higher (>1024) port number? > > > > On 22 Mar 2017 7:35 PM, "Fabregas, Guiu (Nokia - ES/Madrid)" < > guiu.fabregas@nokia.com> wrote: > >> Hi all, >> >> I've gone through this draft and agree with the authors on the need of a >> well known port for TWAMP, so I wanted to expres my support this work. >> >> It will considerably simplify a number of deployment scenarios related t= o >> TWAMP light. >> >> Looking forward to seeing this draft progress. >> >> Thanks, >> Guiu >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> > > Avis de confidentialit=C3=A9 > > Les informations contenues dans le pr=C3=A9sent message et dans toute pi= =C3=A8ce qui > lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3= =A9es par le secret > professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de s= on ou de ses > destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99= il vous > plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en= d=C3=A9truire tout > exemplaire. De plus, il vous est strictement interdit de le divulguer, de > le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80= =99exp=C3=A9diteur. > Merci. > > Confidentiality notice > > This e-mail message and any attachment hereto contain confidential > information which may be privileged and which is intended for the exclusi= ve > use of its addressee(s). If you receive this message in error, please > inform sender immediately and destroy any copy thereof. Furthermore, any > disclosure, distribution or copying of this message and/or any attachment > hereto without the consent of the sender is strictly prohibited. Thank yo= u. > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --001a113ce460945c72054b5786e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Henrik,
thank you for very helpful insight into one= of implementations. I know of other implementations that use proprietary, = self-picked reflector port or ranges of port numbers. I hope that through d= iscussion of this draft we can arrive to the standardized solution to ensur= e interoperability among confirming implementations.

Regards,
Greg

On Wed, Mar 22, 2017 at 2:14 PM, Henrik Nydell <hn= ydell@accedian.com> wrote:
=
I have seen that some vendors of TWAMP senders (I believe= EXFO and possibly Spirent) use port UDP/862 as default port despite being = defined only for the TCP portion of TWAMP-control. Has consideration within= ippm been done on opting for that port to be used also for TWAMP-test or i= s there a preference for a higher (>1024) port number?
=


On 22 Mar 2017 7:35 PM, &= quot;Fabregas, Guiu (Nokia - ES/Madrid)" <guiu.fabregas@nokia.com> wrote:<= br type=3D"attribution">
Hi all,

I've gone through this draft and agree with the authors on the need of = a well known port for TWAMP, so I wanted to expres my support this work.
It will considerably simplify a number of deployment scenarios related to T= WAMP light.

Looking forward to seeing this draft progress.

Thanks,
Guiu

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

Avis de confidentialit= =C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.


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


--001a113ce460945c72054b5786e3-- From nobody Mon Mar 27 05:26:22 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CE9129501 for ; Mon, 27 Mar 2017 05:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lY6WJjxx9MaJ for ; Mon, 27 Mar 2017 05:26:18 -0700 (PDT) Received: from ironport2.ficora.fi (mail2.ficora.fi [IPv6:2a00:13f0:0:1002:125:160:0:165]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3A8127449 for ; Mon, 27 Mar 2017 05:26:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,231,1486418400"; d="scan'208";a="4307306" Received: from ex16mbx2.laru.local (10.120.3.152) by ex16mbx1.laru.local (10.120.3.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id 15.1.669.32; Mon, 27 Mar 2017 15:26:14 +0300 Received: from LOOTA.laru.local (10.101.0.10) by ex16mbx2.laru.local (10.120.3.152) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.669.32 via Frontend Transport; Mon, 27 Mar 2017 15:26:14 +0300 Received: from LOOTA.laru.local ([::1]) by loota.laru.local ([::1]) with mapi id 14.03.0319.002; Mon, 27 Mar 2017 15:26:14 +0300 From: Nieminen Klaus To: "ippm@ietf.org" Thread-Topic: [ippm] draft-nieminen-ippm-nn-measurements-00 Thread-Index: AdKm9H38SzXpyW6XQvalR4AjheJVXg== Date: Mon, 27 Mar 2017 12:26:14 +0000 Message-ID: <6AF4522BD5AB86429CFD3948A9AB2F2F44B15623@loota.laru.local> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.41.200.30] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] draft-nieminen-ippm-nn-measurements-00 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 12:26:21 -0000 Hi, Thanks Nalini for this proposal.=20 One of the main challenges for measurements is that regulators are mainly t= argeting for crowdsourcing tools.=20 How do you get this information e.g. to a browser or mobile app based measu= rement client and I did not yet understand how consumers would be able to c= aptured and analyzed this information via analysis tools as presented in S= ection 2.4. See you in IPPM meeting soon. Best, Klaus ---------------------------------------------------------------------- Message: 1 Date: Sun, 19 Mar 2017 15:13:19 +0000 (UTC) From: To: IPPM IETF Subject: Re: [ippm] draft-nieminen-ippm-nn-measurements-00 Message-ID: <2011967308.571957.1489936399775@mail.yahoo.com> Content-Type: text/plain; charset=3D"utf-8" IPPM, Draft-nieminen-ippm-nn-measurements-00 "Net Neutrality Measurements: Regula= tory Use Case and Problem Statement" outlines the requirements and use case= for measuring Net Neutrality. We have attached a draft showing how using PDM (https://datatracker.ietf.or= g/doc/draft-ietf-ippm-6man-pdm-option/) can be used to monitor Net Neutrali= ty and how it meets the requirements outlined in the draft above. =20 Since we are in the blackout period for draft submission, I am attaching th= e draft to this email. We will submit it officially once the submission p= rocess opens again. We look forward to an informal, offline discussion of this draft in Chicago= with any interested parties. Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 From nobody Mon Mar 27 09:28:51 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF66124B0A for ; Mon, 27 Mar 2017 09:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6ESQ035P-5UP for ; Mon, 27 Mar 2017 09:28:48 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA351127B57 for ; Mon, 27 Mar 2017 09:28:48 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id t8so29685776otf.3 for ; Mon, 27 Mar 2017 09:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GV9cck9eMG4gE+9uv9b9hgO7ZWPW3LQv/gStm5/LXMI=; b=FmF9muUBNdfvZLYK+PLirg6AFn7HUOoE7mzVZgAUCHXkZRLncK811eSGqYGHiYcleM 876RISoeYVLLYTFJw6X8XMT7Koc3sQfCD9u9XVu+ZL4io1V7NIgIDWJyw1mMlPcWB05K 9c/3Y+iLb9v+B/kl3uK1Ws0K2gp2jYj1dWoqsIcpWqxoKUD1vy+PbnyhXgrHEMH5D1Nl FPXYWdxvAXjHlE+JaTRjetUBmkw+OqAFSDE9Ruohh/CriCjNWiEiP5VKLwls4/HhLcMb OdMyXzvY+vG6g/fysS6OXjjgY4fe1aKrbZLIHIqwmNxRlxDKRVDxEiMoV91oZz/eblSH Siew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GV9cck9eMG4gE+9uv9b9hgO7ZWPW3LQv/gStm5/LXMI=; b=Sd7M1OlgeIh7bE+ZzlQpP9ZHtF+mmMctIUB3HTZPUl8KtPMxrPDdSw9mnHUBaiRopW KLtwFcQNVwZsDv3qm5r1l7PdzhKgKBvPVF9MmUcLtPgTAy2sEyW+lddkRyU4QR+IR5RZ 1b3AV3xtRQ89x2r6VjwRNxfcYD8ana7nYXxoizOnLGD87fW0UCd8jHYXTcWPAw92dLlA YQxAmkH07EcXzWxE3AFpKfG/LrnxUL9a7nlRdwnDtQ8ACA8OOB5Oy7EfJ+aMWcqsBEqu fcGLhORHVt0cEGlfH7On7SJOg3c7K37VPHUISuqOxzm8IiUiAVXRZfj6c3AAQR2WTWWl I+7w== X-Gm-Message-State: AFeK/H2DmHGqxsvC97lL3bf0MPuxQCGFzVqXTnenjDqMkHFshhTWN8zVDScbh/VtgCtMJwdQ1yjJh47GYZGpNg== X-Received: by 10.157.14.110 with SMTP id n43mr10823656otd.35.1490632128041; Mon, 27 Mar 2017 09:28:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Mon, 27 Mar 2017 09:28:47 -0700 (PDT) From: Greg Mirsky Date: Mon, 27 Mar 2017 11:28:47 -0500 Message-ID: To: "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a113edf547b9a96054bb8d62f Archived-At: Subject: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 16:28:50 -0000 --001a113edf547b9a96054bb8d62f Content-Type: text/plain; charset=UTF-8 Dear All, the second paragraph in section 1.1 of RFC 4656 states the following: Although OWAMP-Test may be used in conjunction with a control protocol other than OWAMP-Control, the authors have deliberately chosen to include both protocols in the same RFC to encourage the implementation and deployment of OWAMP-Control as a common denominator control protocol for one-way active measurements. I interpret "may be used" as MAY per RFC 2119. Please let me know if this should not be the case. Regards, Greg --001a113edf547b9a96054bb8d62f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
the second paragraph in section 1.1 of RFC 4= 656 states the following:
   Al=
though OWAMP-Test may be used in conjunction with a control
   protocol other than OWAMP-Control, the authors have deliberately
   chosen to include both protocols in the same RFC to encourage the
   implementation and deployment of OWAMP-Control as a common
   denominator control protocol for one-way active measurements.

=
I interpret "may be used" as MAY per RFC 2119. Please let me know=
 if this should not be the case.
Regards,
Greg
--001a113edf547b9a96054bb8d62f-- From nobody Mon Mar 27 10:25:12 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E5C129404 for ; Mon, 27 Mar 2017 10:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.395 X-Spam-Level: X-Spam-Status: No, score=-5.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xu2Rdorn1nzc for ; Mon, 27 Mar 2017 10:25:06 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 72EE81200A0 for ; Mon, 27 Mar 2017 10:25:06 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v2RHFUF8014135; Mon, 27 Mar 2017 13:25:05 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 29f6kfh7yb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Mar 2017 13:25:04 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2RHP3EK001807; Mon, 27 Mar 2017 13:25:04 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2RHOsWf001593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Mar 2017 13:25:00 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 27 Mar 2017 17:24:43 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2RHOgJY032427; Mon, 27 Mar 2017 12:24:43 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2RHOYCG031871; Mon, 27 Mar 2017 12:24:34 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id 1C7BBF0567; Mon, 27 Mar 2017 13:24:34 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Mon, 27 Mar 2017 13:24:34 -0400 From: "MORTON, ALFRED C (AL)" To: Greg Mirsky , "ippm@ietf.org" Thread-Topic: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test Thread-Index: AQHSpxc8BtKwqovJekeye+fp0718nKGo7kpA Date: Mon, 27 Mar 2017 17:24:32 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.194.153] Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF25F3B699njmtexg5researc_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703270144 Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 17:25:10 -0000 --_000_4D7F4AD313D3FC43A053B309F97543CF25F3B699njmtexg5researc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KSWYgd2UgaGFkIG1lYW50IFJGQyAyMTE5IOKAnE1BWeKAnSBvciDigJxPUFRJT05B TOKAnSAodGhlIHRlcm0NCnlvdSB1c2VkIHRvZGF5IHdoZW4gcHJlc2VudGluZykgd2Ugd291bGQg aGF2ZSB1c2VkIHRoZQ0KUkZDIDIxMTkgdGVybSBpbiB0aGUgdGV4dC4NCg0KVGhlcmUgYXJlIHBs ZW50eSBvZiBvdGhlciBleGFtcGxlcyB3aGVyZSBib3RoIENvbnRyb2wNCmFuZCBUZXN0IHByb3Rv Y29scyBhcmUgdGFrZW4gYXMg4oCcdGhlIGZ1bGwgVFdBTVDigJ0uDQoNCkFsDQoNCg0KRnJvbTog aXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWcgTWly c2t5DQpTZW50OiBNb25kYXksIE1hcmNoIDI3LCAyMDE3IDEyOjI5IFBNDQpUbzogaXBwbUBpZXRm Lm9yZw0KU3ViamVjdDogW2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250cm9sIGFu ZCByZWxhdGlvbnNoaXAgd2l0aCBPV0FNUC1UZXN0DQoNCkRlYXIgQWxsLA0KdGhlIHNlY29uZCBw YXJhZ3JhcGggaW4gc2VjdGlvbiAxLjEgb2YgUkZDIDQ2NTYgc3RhdGVzIHRoZSBmb2xsb3dpbmc6 DQoNCiAgIEFsdGhvdWdoIE9XQU1QLVRlc3QgbWF5IGJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0 aCBhIGNvbnRyb2wNCg0KICAgcHJvdG9jb2wgb3RoZXIgdGhhbiBPV0FNUC1Db250cm9sLCB0aGUg YXV0aG9ycyBoYXZlIGRlbGliZXJhdGVseQ0KDQogICBjaG9zZW4gdG8gaW5jbHVkZSBib3RoIHBy b3RvY29scyBpbiB0aGUgc2FtZSBSRkMgdG8gZW5jb3VyYWdlIHRoZQ0KDQogICBpbXBsZW1lbnRh dGlvbiBhbmQgZGVwbG95bWVudCBvZiBPV0FNUC1Db250cm9sIGFzIGEgY29tbW9uDQoNCiAgIGRl bm9taW5hdG9yIGNvbnRyb2wgcHJvdG9jb2wgZm9yIG9uZS13YXkgYWN0aXZlIG1lYXN1cmVtZW50 cy4NCg0KDQoNCkkgaW50ZXJwcmV0ICJtYXkgYmUgdXNlZCIgYXMgTUFZIHBlciBSRkMgMjExOS4g UGxlYXNlIGxldCBtZSBrbm93IGlmIHRoaXMgc2hvdWxkIG5vdCBiZSB0aGUgY2FzZS4NCg0KDQoN ClJlZ2FyZHMsDQoNCkdyZWcNCg== --_000_4D7F4AD313D3FC43A053B309F97543CF25F3B699njmtexg5researc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJY29sb3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5HcmVnLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SWYgd2UgaGFkIG1l YW50IFJGQyAyMTE5IOKAnE1BWeKAnSBvciDigJxPUFRJT05BTOKAnSAodGhlIHRlcm08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+eW91IHVzZWQgdG9kYXkgd2hlbiBwcmVzZW50aW5nKSB3ZSB3b3VsZCBoYXZlIHVzZWQgdGhl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPlJGQyAyMTE5IHRlcm0gaW4gdGhlIHRleHQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5UaGVyZSBhcmUgcGxlbnR5IG9mIG90aGVyIGV4YW1wbGVzIHdoZXJlIGJvdGggQ29udHJv bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5hbmQgVGVzdCBwcm90b2NvbHMgYXJlIHRha2VuIGFzIOKAnHRoZSBmdWxsIFRX QU1Q4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+QWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IGlwcG0gW21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkdyZWcgTWlyc2t5PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg TWFyY2ggMjcsIDIwMTcgMTI6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IGlwcG1AaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250cm9s IGFuZCByZWxhdGlvbnNoaXAgd2l0aCBPV0FNUC1UZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgQWxsLDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHNlY3Rp b24gMS4xIG9mIFJGQyA0NjU2IHN0YXRlcyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBBbHRob3VnaCBPV0FNUC1UZXN0IG1heSBiZSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggYSBj b250cm9sPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+ICZuYnNwOyZuYnNwO3Byb3RvY29sIG90aGVyIHRoYW4gT1dBTVAtQ29udHJvbCwgdGhl IGF1dGhvcnMgaGF2ZSBkZWxpYmVyYXRlbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY2hvc2VuIHRvIGluY2x1ZGUg Ym90aCBwcm90b2NvbHMgaW4gdGhlIHNhbWUgUkZDIHRvIGVuY291cmFnZSB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgb2YgT1dBTVAtQ29udHJvbCBhcyBhIGNv bW1vbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBkZW5vbWluYXRvciBjb250cm9sIHByb3RvY29sIGZvciBvbmUtd2F5 IGFjdGl2ZSBtZWFzdXJlbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBpbnRlcnByZXQgJnF1b3Q7bWF5IGJlIHVzZWQm cXVvdDsgYXMgTUFZIHBlciBSRkMgMjExOS4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHRoaXMgc2hv dWxkIG5vdCBiZSB0aGUgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4D7F4AD313D3FC43A053B309F97543CF25F3B699njmtexg5researc_-- From nobody Mon Mar 27 12:16:13 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B13129571 for ; Mon, 27 Mar 2017 12:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OvEPeloAF1uu for ; Mon, 27 Mar 2017 12:16:08 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C15912704B for ; Mon, 27 Mar 2017 12:16:07 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id g83so21292322oia.0 for ; Mon, 27 Mar 2017 12:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E1s3G8VSNvjRInMFO7PVE6K09wx8w1eWJPDUNUGzXl8=; b=kMNYB6efccsVyC2MgDn0jRsceKepRPO/U2iVewdtqZLiVM8F3UloSNwLAcEDkOB4E3 X39vZZiw3GZ2RT+dlNfxJtkatYTZrm5D17ohWgW6CzkJy5wecYjhHN1mtWfwOobKDh3m 1PjTsJExcKXPEeYeqBuIQ650AOpdENL/iFke8U0hgFCwYmG6f2tpfNeHvCOx/ZGVQn7n OLmQ+E7NU1VLiwZfpw/HUg4iLbd4yH3IRfCpCeHQLzCi/ya3Pv4viA3q9n7VN31/56IN Bu2O4hyHpCSNqfGuYdii0iBu1uWrb+rmFXOorDeHxsVpmBVHYiFhMq83egHB6uN+bh9K 8pXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E1s3G8VSNvjRInMFO7PVE6K09wx8w1eWJPDUNUGzXl8=; b=jPdmPXRcXnzgbPExU8bWWYlOTYrYrGJf8WkjA+iZoCe6YRZaOmD5QFBETesbUi/sEq KhOP4yvIEnNciVEeA4e+a0Hm4on+ke5Cfg3Ruh34OFuHkNb1oH0U5yfFK4OaW4HUeycP xov8QLJhQ/G8phPvqzikbN3R49u/3Lmc0CTfLuHdG3Dusohr55f8IzWoxhnXnrDyVurC TlfQbrfVLVrDW4OHHoscnGsJukUOT9+ewuQWWxDHO1/6kkEnK3W3JIn8QBkLD0a7H/NN d0JRH34IXahL+e/QYn4oe/9VRUm3oysoPjWJQ6xegnpfl5fEFf+2EBkE/SbO5/1aWrnv AlSg== X-Gm-Message-State: AFeK/H3l6C5g35aR6TTbtarP2QyM2OBwHS47jYQYGljW4d7w/9QPOkczYRGQO0uT1dnZ9PP16DFXuT82SsG9KQ== X-Received: by 10.202.62.4 with SMTP id l4mr11225055oia.75.1490642166804; Mon, 27 Mar 2017 12:16:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Mon, 27 Mar 2017 12:16:06 -0700 (PDT) In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> From: Greg Mirsky Date: Mon, 27 Mar 2017 14:16:06 -0500 Message-ID: To: "MORTON, ALFRED C (AL)" Cc: "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a113cbdd8d70300054bbb2ca8 Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:16:11 -0000 --001a113cbdd8d70300054bbb2ca8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Al, then, in my opinion, there's certain ambiguity in the text of RFC 4656 and in RFC 5357 as well because of the following statement in the very first sentence of section 1.1 RFC 5357: Similar to OWAMP [RFC4656 ], TWAMP consists of two inter-related protocols: TWAMP-Control and TWAMP-Test. The relationship of these protocols is as defined in Section 1.1 of OWAMP [RFC4656 ]. Regards, Greg On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) wrote: > Greg, > > > > If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80= =9D (the term > > you used today when presenting) we would have used the > > RFC 2119 term in the text. > > > > There are plenty of other examples where both Control > > and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D. > > > > Al > > > > > > *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Monday, March 27, 2017 12:29 PM > *To:* ippm@ietf.org > *Subject:* [ippm] RFC 4656 on use of OWAMP-Control and relationship with > OWAMP-Test > > > > Dear All, > > the second paragraph in section 1.1 of RFC 4656 states the following: > > Although OWAMP-Test may be used in conjunction with a control > > protocol other than OWAMP-Control, the authors have deliberately > > chosen to include both protocols in the same RFC to encourage the > > implementation and deployment of OWAMP-Control as a common > > denominator control protocol for one-way active measurements. > > > > I interpret "may be used" as MAY per RFC 2119. Please let me know if this= should not be the case. > > > > Regards, > > Greg > > --001a113cbdd8d70300054bbb2ca8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Al,
then, in my opinion, there's certain ambigu= ity in the text of RFC 4656 and in RFC 5357 as well because of the followin= g statement in the very first sentence of section 1.1 RFC 5357:
<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;color:rgb(0,0,0)"> Similar to OWAMP [RFC4656], TWAMP consists of two inter-related protocols: TWAMP-Control and TWAMP-Test. The relationship of these protocols is as defined in Section 1.1 of OWAMP [RFC4656].

Regards,
Greg

On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) <acmorton= @att.com> wrote:

Greg,

=C2=A0

If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D= or =E2=80=9COPTIONAL=E2=80=9D (the term

you used today when presenting) we would have = used the

RFC 2119 term in the text.

=C2=A0

There are plenty of other examples where both = Control

and Test protocols are taken as =E2=80=9Cthe f= ull TWAMP=E2=80=9D.

=C2=A0

Al

=C2=A0

=C2=A0

From: ippm [ma= ilto:ippm-bounce= s@ietf.org] On Behalf Of Greg Mirsky
Sent: Monday, March 27, 2017 12:29 PM
To: ippm@ietf.org=
Subject: [ippm] RFC 4656 on use of OWAMP-Control and relationship wi= th OWAMP-Test

=C2=A0

Dear All,

the second paragraph in section 1.1 of RFC 4656 stat= es the following:

=C2=A0=C2=A0 Although OWAMP-Test may be us=
ed in conjunction with a control
 =C2=A0=C2=A0protocol other than OWAMP-Con=
trol, the authors have deliberately
=C2=A0=C2=A0 chosen to include both protoc=
ols in the same RFC to encourage the
=C2=A0=C2=A0 implementation and deployment=
 of OWAMP-Control as a common
=C2=A0=C2=A0 denominator control protocol =
for one-way active measurements.
=C2=A0
I interpret "may be used" as MAY=
 per RFC 2119. Please let me know if this should not be the case.=

=C2=A0
Regards,
Greg

--001a113cbdd8d70300054bbb2ca8-- From nobody Mon Mar 27 14:08:42 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424DE12967A for ; Mon, 27 Mar 2017 14:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7YdIg7YQN5j6 for ; Mon, 27 Mar 2017 14:08:38 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 05EF0129674 for ; Mon, 27 Mar 2017 14:08:38 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v2RL50Ng025235; Mon, 27 Mar 2017 17:08:35 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 29f8kdv4y0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Mar 2017 17:08:35 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2RL8YFF028903; Mon, 27 Mar 2017 17:08:34 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2RL8KK6028568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Mar 2017 17:08:26 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 27 Mar 2017 21:08:16 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2RL8Fna018017; Mon, 27 Mar 2017 16:08:15 -0500 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2RL8BST017731; Mon, 27 Mar 2017 16:08:11 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id E54A0E0A55; Mon, 27 Mar 2017 17:08:10 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Mon, 27 Mar 2017 17:08:10 -0400 From: "MORTON, ALFRED C (AL)" To: Greg Mirsky CC: "ippm@ietf.org" Thread-Topic: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test Thread-Index: AQHSpxc8BtKwqovJekeye+fp0718nKGo7kpAgABjvwD//9sasA== Date: Mon, 27 Mar 2017 21:08:10 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.130.6] Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF25F3B98Anjmtexg5researc_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703270173 Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 21:08:40 -0000 --_000_4D7F4AD313D3FC43A053B309F97543CF25F3B98Anjmtexg5researc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KQWxsIGFtYmlndWl0eSBmYWxscyBhd2F5IGluIHRoZSBjb250ZXh0IG9mDQp0aGUg Y29tcGxldGUgVFdBTVAgZG9jdW1lbnQsIHdoaWNoIHNheXM6DQoNCiAgIFRoaXMgZXhhbXBsZSBl bGltaW5hdGVzIHRoZSBuZWVkIGZvciB0aGUgVFdBTVAtQ29udHJvbCBwcm90b2NvbCwgYW5kDQog ICBhc3N1bWVzIHRoYXQgdGhlIFNlc3Npb24tUmVmbGVjdG9yIGlzIGNvbmZpZ3VyZWQgYW5kIGNv bW11bmljYXRlcyBpdHMNCiAgIGNvbmZpZ3VyYXRpb24gd2l0aCB0aGUgU2VydmVyIHRocm91Z2gg bm9uLXN0YW5kYXJkIG1lYW5zLg0KDQpUaGUgZXhhbXBsZSByZWZlcnJlZCB0byBhYm92ZSBpcyBu b3QgVFdBTVA7DQppdCBpcyB0aGUgb3B0aW9uIHlvdSBkZXNjcmliZSwgYnV0IGl0IGlzDQpjYWxs ZWQgKlRXQU1QIGxpZ2h0Ki4NCg0KQWwNCg0KRnJvbTogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWcgTWlyc2t5DQpTZW50OiBNb25kYXksIE1hcmNo IDI3LCAyMDE3IDM6MTYgUE0NClRvOiBNT1JUT04sIEFMRlJFRCBDIChBTCkNCkNjOiBpcHBtQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250 cm9sIGFuZCByZWxhdGlvbnNoaXAgd2l0aCBPV0FNUC1UZXN0DQoNCkhpIEFsLA0KdGhlbiwgaW4g bXkgb3BpbmlvbiwgdGhlcmUncyBjZXJ0YWluIGFtYmlndWl0eSBpbiB0aGUgdGV4dCBvZiBSRkMg NDY1NiBhbmQgaW4gUkZDIDUzNTcgYXMgd2VsbCBiZWNhdXNlIG9mIHRoZSBmb2xsb3dpbmcgc3Rh dGVtZW50IGluIHRoZSB2ZXJ5IGZpcnN0IHNlbnRlbmNlIG9mIHNlY3Rpb24gMS4xIFJGQyA1MzU3 Og0KDQogICBTaW1pbGFyIHRvIE9XQU1QIFtSRkM0NjU2PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM0NjU2 JmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtUSWx0VnlEMW9MNzJj QncmbT1HWU15MV9zcWY5bWo2UzBaSDNCOHZObXFlMERoam83ZGU2MVFiMFJfUEVrJnM9eFNrZkZX NWpqNllQYnFwY2ZuQWxhaHJvRzdEWGRJMHhmaUZBU1dZcFF6VSZlPT5dLCBUV0FNUCBjb25zaXN0 cyBvZiB0d28gaW50ZXItcmVsYXRlZA0KDQogICBwcm90b2NvbHM6IFRXQU1QLUNvbnRyb2wgYW5k IFRXQU1QLVRlc3QuICBUaGUgcmVsYXRpb25zaGlwIG9mIHRoZXNlDQoNCiAgIHByb3RvY29scyBp cyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMS4xPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1MzU3LTIzc2Vj dGlvbi0yRDEuMSZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThrVEls dFZ5RDFvTDcyY0J3Jm09R1lNeTFfc3FmOW1qNlMwWkgzQjh2Tm1xZTBEaGpvN2RlNjFRYjBSX1BF ayZzPUxsMGg1WDRvU3dYWGw0R19GWTJjUlMtRXVRdE9sVzdVQmllWnV1VVZHbm8mZT0+IG9mIE9X QU1QIFtSRkM0NjU2PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM0NjU2JmQ9RHdNRmFRJmM9TEZZWi1vOV9I VU1lTVRTUWljdmpJZyZyPU9mc1N1OGtUSWx0VnlEMW9MNzJjQncmbT1HWU15MV9zcWY5bWo2UzBa SDNCOHZObXFlMERoam83ZGU2MVFiMFJfUEVrJnM9eFNrZkZXNWpqNllQYnFwY2ZuQWxhaHJvRzdE WGRJMHhmaUZBU1dZcFF6VSZlPT5dLg0KDQoNCg0KUmVnYXJkcywNCg0KR3JlZw0KDQpPbiBNb24s IE1hciAyNywgMjAxNyBhdCAxMjoyNCBQTSwgTU9SVE9OLCBBTEZSRUQgQyAoQUwpIDxhY21vcnRv bkBhdHQuY29tPG1haWx0bzphY21vcnRvbkBhdHQuY29tPj4gd3JvdGU6DQpHcmVnLA0KDQpJZiB3 ZSBoYWQgbWVhbnQgUkZDIDIxMTkg4oCcTUFZ4oCdIG9yIOKAnE9QVElPTkFM4oCdICh0aGUgdGVy bQ0KeW91IHVzZWQgdG9kYXkgd2hlbiBwcmVzZW50aW5nKSB3ZSB3b3VsZCBoYXZlIHVzZWQgdGhl DQpSRkMgMjExOSB0ZXJtIGluIHRoZSB0ZXh0Lg0KDQpUaGVyZSBhcmUgcGxlbnR5IG9mIG90aGVy IGV4YW1wbGVzIHdoZXJlIGJvdGggQ29udHJvbA0KYW5kIFRlc3QgcHJvdG9jb2xzIGFyZSB0YWtl biBhcyDigJx0aGUgZnVsbCBUV0FNUOKAnS4NCg0KQWwNCg0KDQpGcm9tOiBpcHBtIFttYWlsdG86 aXBwbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgR3JlZyBNaXJza3kNClNlbnQ6IE1vbmRheSwgTWFyY2ggMjcsIDIwMTcgMTI6Mjkg UE0NClRvOiBpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KU3ViamVjdDogW2lw cG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250cm9sIGFuZCByZWxhdGlvbnNoaXAgd2l0 aCBPV0FNUC1UZXN0DQoNCkRlYXIgQWxsLA0KdGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gc2VjdGlv biAxLjEgb2YgUkZDIDQ2NTYgc3RhdGVzIHRoZSBmb2xsb3dpbmc6DQoNCiAgIEFsdGhvdWdoIE9X QU1QLVRlc3QgbWF5IGJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBhIGNvbnRyb2wNCg0KICAg cHJvdG9jb2wgb3RoZXIgdGhhbiBPV0FNUC1Db250cm9sLCB0aGUgYXV0aG9ycyBoYXZlIGRlbGli ZXJhdGVseQ0KDQogICBjaG9zZW4gdG8gaW5jbHVkZSBib3RoIHByb3RvY29scyBpbiB0aGUgc2Ft ZSBSRkMgdG8gZW5jb3VyYWdlIHRoZQ0KDQogICBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVu dCBvZiBPV0FNUC1Db250cm9sIGFzIGEgY29tbW9uDQoNCiAgIGRlbm9taW5hdG9yIGNvbnRyb2wg cHJvdG9jb2wgZm9yIG9uZS13YXkgYWN0aXZlIG1lYXN1cmVtZW50cy4NCg0KDQoNCkkgaW50ZXJw cmV0ICJtYXkgYmUgdXNlZCIgYXMgTUFZIHBlciBSRkMgMjExOS4gUGxlYXNlIGxldCBtZSBrbm93 IGlmIHRoaXMgc2hvdWxkIG5vdCBiZSB0aGUgY2FzZS4NCg0KDQoNClJlZ2FyZHMsDQoNCkdyZWcN Cg0K --_000_4D7F4AD313D3FC43A053B309F97543CF25F3B98Anjmtexg5researc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkdyZWcsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5BbGwgYW1iaWd1aXR5IGZhbGxzIGF3YXkgaW4gdGhlIGNvbnRleHQg b2YNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj50aGUgY29tcGxldGUgVFdBTVAgZG9jdW1lbnQsIHdoaWNoIHNheXM6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGhpcyBleGFtcGxlIGVsaW1pbmF0 ZXMgdGhlIG5lZWQgZm9yIHRoZSBUV0FNUC1Db250cm9sIHByb3RvY29sLCBhbmQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IGFzc3VtZXMgdGhhdCB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IgaXMgY29uZmln dXJlZCBhbmQgY29tbXVuaWNhdGVzIGl0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY29uZmlndXJh dGlvbiB3aXRoIHRoZSBTZXJ2ZXIgdGhyb3VnaCBub24tc3RhbmRhcmQgbWVhbnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5UaGUgZXhhbXBsZSByZWZlcnJlZCB0byBhYm92ZSBpcyBub3QgVFdB TVA7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPml0IGlzIHRoZSBvcHRpb24geW91IGRlc2NyaWJlLCBidXQgaXQgaXMNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5jYWxsZWQgKjxiPlRXQU1QIGxpZ2h0PC9iPiouPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5BbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5HcmVnIE1pcnNreTxicj4NCjxiPlNlbnQ6 PC9iPiBNb25kYXksIE1hcmNoIDI3LCAyMDE3IDM6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IE1PUlRP TiwgQUxGUkVEIEMgKEFMKTxicj4NCjxiPkNjOjwvYj4gaXBwbUBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250cm9sIGFu ZCByZWxhdGlvbnNoaXAgd2l0aCBPV0FNUC1UZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZW4sIGluIG15IG9waW5pb24sIHRoZXJlJ3MgY2VydGFp biBhbWJpZ3VpdHkgaW4gdGhlIHRleHQgb2YgUkZDIDQ2NTYgYW5kIGluIFJGQyA1MzU3IGFzIHdl bGwgYmVjYXVzZSBvZiB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiB0aGUgdmVyeSBmaXJzdCBz ZW50ZW5jZSBvZiBzZWN0aW9uIDEuMSBSRkMgNTM1Nzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgU2ltaWxh ciB0byBPV0FNUCBbPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzQ2NTYmYW1wO2Q9RHdNRmFR JmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9T2ZzU3U4a1RJbHRWeUQxb0w3MmNC dyZhbXA7bT1HWU15MV9zcWY5bWo2UzBaSDNCOHZObXFlMERoam83ZGU2MVFiMFJfUEVrJmFtcDtz PXhTa2ZGVzVqajZZUGJxcGNmbkFsYWhyb0c3RFhkSTB4ZmlGQVNXWXBRelUmYW1wO2U9IiB0aXRs ZT0iJnF1b3Q7QSBPbmUtd2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoT1dBTVApJnF1 b3Q7Ij5SRkM0NjU2PC9hPl0sIFRXQU1QIGNvbnNpc3RzIG9mIHR3byBpbnRlci1yZWxhdGVkPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IHByb3RvY29sczogVFdBTVAtQ29udHJvbCBhbmQgVFdBTVAtVGVzdC4mbmJzcDsg VGhlIHJlbGF0aW9uc2hpcCBvZiB0aGVzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwcm90b2NvbHMgaXMgYXMgZGVm aW5lZCBpbiA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNTM1Ny0yM3NlY3Rpb24tMkQxLjEm YW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9T2ZzU3U4a1RJ bHRWeUQxb0w3MmNCdyZhbXA7bT1HWU15MV9zcWY5bWo2UzBaSDNCOHZObXFlMERoam83ZGU2MVFi MFJfUEVrJmFtcDtzPUxsMGg1WDRvU3dYWGw0R19GWTJjUlMtRXVRdE9sVzdVQmllWnV1VVZHbm8m YW1wO2U9Ij5TZWN0aW9uIDEuMTwvYT4gb2YgT1dBTVAgWzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRt bF9yZmM0NjU2JmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDty PU9mc1N1OGtUSWx0VnlEMW9MNzJjQncmYW1wO209R1lNeTFfc3FmOW1qNlMwWkgzQjh2Tm1xZTBE aGpvN2RlNjFRYjBSX1BFayZhbXA7cz14U2tmRlc1amo2WVBicXBjZm5BbGFocm9HN0RYZEkweGZp RkFTV1lwUXpVJmFtcDtlPSIgdGl0bGU9IiZxdW90O0EgT25lLXdheSBBY3RpdmUgTWVhc3VyZW1l bnQgUHJvdG9jb2wgKE9XQU1QKSZxdW90OyI+UkZDNDY1NjwvYT5dLiA8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdy ZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLCBNYXIgMjcsIDIwMTcgYXQgMTI6MjQgUE0sIE1PUlRPTiwgQUxGUkVE IEMgKEFMKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFjbW9ydG9uQGF0dC5jb20iIHRhcmdldD0iX2Js YW5rIj5hY21vcnRvbkBhdHQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkdy ZWcsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SWYgd2UgaGFkIG1lYW50IFJGQyAyMTE5 IOKAnE1BWeKAnSBvciDigJxPUFRJT05BTOKAnSAodGhlIHRlcm08L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj55b3UgdXNl ZCB0b2RheSB3aGVuIHByZXNlbnRpbmcpIHdlIHdvdWxkIGhhdmUgdXNlZCB0aGU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5SRkMgMjExOSB0ZXJtIGluIHRoZSB0ZXh0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PlRoZXJlIGFyZSBwbGVudHkgb2Ygb3RoZXIgZXhhbXBsZXMgd2hlcmUgYm90aCBDb250cm9sPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+YW5kIFRlc3QgcHJvdG9jb2xzIGFyZSB0YWtlbiBhcyDigJx0aGUgZnVsbCBUV0FN UOKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BbDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaXBwbSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpp cHBtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pcHBtLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5HcmVnIE1pcnNreTxicj4NCjxiPlNlbnQ6PC9i PiBNb25kYXksIE1hcmNoIDI3LCAyMDE3IDEyOjI5IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVm PSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwcG1AaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtpcHBtXSBSRkMgNDY1NiBvbiB1c2Ugb2YgT1dBTVAtQ29u dHJvbCBhbmQgcmVsYXRpb25zaGlwIHdpdGggT1dBTVAtVGVzdDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EZWFy IEFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoZSBz ZWNvbmQgcGFyYWdyYXBoIGluIHNlY3Rpb24gMS4xIG9mIFJGQyA0NjU2IHN0YXRlcyB0aGUgZm9s bG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBBbHRob3VnaCBPV0FNUC1UZXN0IG1heSBiZSB1c2Vk IGluIGNvbmp1bmN0aW9uIHdpdGggYSBjb250cm9sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ICZuYnNwOyZuYnNwO3Byb3RvY29sIG90aGVy IHRoYW4gT1dBTVAtQ29udHJvbCwgdGhlIGF1dGhvcnMgaGF2ZSBkZWxpYmVyYXRlbHk8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgY2hvc2VuIHRvIGluY2x1ZGUgYm90aCBwcm90b2NvbHMgaW4gdGhlIHNhbWUgUkZDIHRv IGVuY291cmFnZSB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQg b2YgT1dBTVAtQ29udHJvbCBhcyBhIGNvbW1vbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBkZW5vbWluYXRvciBjb250 cm9sIHByb3RvY29sIGZvciBvbmUtd2F5IGFjdGl2ZSBtZWFzdXJlbWVudHMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSBpbnRl cnByZXQgJnF1b3Q7bWF5IGJlIHVzZWQmcXVvdDsgYXMgTUFZIHBlciBSRkMgMjExOS4gUGxlYXNl IGxldCBtZSBrbm93IGlmIHRoaXMgc2hvdWxkIG5vdCBiZSB0aGUgY2FzZS48L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkdyZWc8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_4D7F4AD313D3FC43A053B309F97543CF25F3B98Anjmtexg5researc_-- From nobody Mon Mar 27 14:21:04 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ACF12966F for ; Mon, 27 Mar 2017 14:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zpvwOwVxlJ-K for ; Mon, 27 Mar 2017 14:20:58 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6745912955A for ; Mon, 27 Mar 2017 14:20:58 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id 21so51937486pgg.1 for ; Mon, 27 Mar 2017 14:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=WdE9BrTExLIyqcgz+6mcbnlWB1GQuLiwdSYKO6nFOyk=; b=szxmLpZTbDQ6QrFigvvXOkVnnl86jCOPzJcBz8eB5eEEfv0E4Z/1O4PneoG9KngcoQ iC5L6CbGZ9x42gdiN80XGqGfhp0qkcRK/KL85LaT2BbC4pif6SFJ3h5N+EbnC96TOLFq 2silpZQpUKRs26ygshY8avD6hfv9kvfhTABIRX/beGehcYrv1tbYuI9vQ/vDkD/IKMW2 b/tUBESMSY3nPLfeKcWN8eXao0qrSTQTjuhfXRfbtg3TVsO1hhFMlpRyESsyWs9dXK5F oLNNW3RPOP1wtFnFhGXqp0RwKU+Kdxvyf61lCBnnpo8L/gG9ATjmYEPzddd5BMh0SnA6 Mo/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=WdE9BrTExLIyqcgz+6mcbnlWB1GQuLiwdSYKO6nFOyk=; b=nAE8mV5uYGa52PiLoI7WKr6qw17stCTg4dOub9e6hpTyulMTSN9Drh2TXM6CFgz0OV FBWNCrnU917E1w7+oCCWdo6NdBQyq3bG4PfgYjFoJ4Rd8iirhQJDeQrMuJG8b/1AqNja wW+P9lMimwA1NEaCmFkMjgJtxBgFJeMLvCbZwwJw3dYPyggUGTTN5W1WQy0vfacwrDIT 1VL2fAYlgWvrsnJrJ+9va/ve3fI6wJWjGWEs1qiJBBnd67kvEI8PonDtv+ZI8f95C3BD 1oJ2iY3+MrrEdh6PAzfsB3wKaFGGXgT7L6Yds/me9IczZgF50yLHHSjCid2xBxwnhH6u w6qg== X-Gm-Message-State: AFeK/H2v/KoVzQhnjxK19P+dlBDnuo7EZ+1kJobG7f7+7j07BUePjbZ2Cft+VmLPJAmdJA== X-Received: by 10.98.192.151 with SMTP id g23mr27455553pfk.254.1490649657954; Mon, 27 Mar 2017 14:20:57 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1001::584? ([2001:420:c0c8:1001::584]) by smtp.gmail.com with ESMTPSA id s27sm2951692pfk.39.2017.03.27.14.20.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Mar 2017 14:20:57 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5B1C6FC8-32E6-4987-95DF-1990B4B2E731" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> Date: Mon, 27 Mar 2017 16:20:55 -0500 Cc: Greg Mirsky , "ippm@ietf.org" Message-Id: <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> To: "ALFRED C MORTON (AL)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 21:21:02 -0000 --Apple-Mail=_5B1C6FC8-32E6-4987-95DF-1990B4B2E731 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greg, And the part that you forgot to quote that followed in Section 1.1 is: TWAMP- Control is used to initiate, start, and stop test sessions, whereas TWAMP-Test is used to exchange test packets between two TWAMP entities. There is clearly a precedence for TWAMP-Control to be a entity by itself = and very much part of the TWAMP protocol. If this is this rational for your comments on the YANG model, then I = fail to see RFC 5357 backing your claim that TWAMP-control is optional. Cheers. > On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) = wrote: >=20 > Greg, > =20 > All ambiguity falls away in the context of > the complete TWAMP document, which says: > =20 > This example eliminates the need for the TWAMP-Control protocol, = and > assumes that the Session-Reflector is configured and communicates = its > configuration with the Server through non-standard means. > =20 > The example referred to above is not TWAMP; > it is the option you describe, but it is > called *TWAMP light*. > =20 > Al > =20 > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky > Sent: Monday, March 27, 2017 3:16 PM > To: MORTON, ALFRED C (AL) > Cc: ippm@ietf.org > Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship = with OWAMP-Test > =20 > Hi Al, > then, in my opinion, there's certain ambiguity in the text of RFC 4656 = and in RFC 5357 as well because of the following statement in the very = first sentence of section 1.1 RFC 5357: > Similar to OWAMP [RFC4656 = ], TWAMP consists of two inter-related > protocols: TWAMP-Control and TWAMP-Test. The relationship of these > protocols is as defined in Section 1.1 = of OWAMP [RFC4656 = ].=20 > =20 > Regards, > Greg > =20 > On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) = > wrote: > Greg, > =20 > If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80= =9D (the term > you used today when presenting) we would have used the > RFC 2119 term in the text. > =20 > There are plenty of other examples where both Control > and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D. > =20 > Al > =20 > =20 > From: ippm [mailto:ippm-bounces@ietf.org = ] On Behalf Of Greg Mirsky > Sent: Monday, March 27, 2017 12:29 PM > To: ippm@ietf.org > Subject: [ippm] RFC 4656 on use of OWAMP-Control and relationship with = OWAMP-Test > =20 > Dear All, > the second paragraph in section 1.1 of RFC 4656 states the following: > Although OWAMP-Test may be used in conjunction with a control > protocol other than OWAMP-Control, the authors have deliberately > chosen to include both protocols in the same RFC to encourage the > implementation and deployment of OWAMP-Control as a common > denominator control protocol for one-way active measurements. > =20 > I interpret "may be used" as MAY per RFC 2119. Please let me know if = this should not be the case. > =20 > Regards, > Greg > =20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_5B1C6FC8-32E6-4987-95DF-1990B4B2E731 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Greg,

And = the part that you forgot to quote that followed in Section 1.1 = is:

TWAMP-
   Control is used to initiate, start, and stop test sessions, whereas
   TWAMP-Test is used to exchange test packets between two TWAMP
   entities.

There is clearly a precedence for TWAMP-Control to be a = entity by itself and very much part of the TWAMP protocol.

If this is this rational = for your comments on the YANG model, then I fail to see RFC 5357 backing = your claim that TWAMP-control is optional.

Cheers.

On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) <acmorton@att.com> = wrote:

Greg,
 
All ambiguity falls away in the = context of
the complete TWAMP document, which says:
 
   This example eliminates the need for the = TWAMP-Control protocol, and
   assumes that the = Session-Reflector is configured and communicates its
   configuration with the Server through = non-standard means.
 
The example referred to above is not TWAMP;
it is = the option you describe, but it is
called *TWAMP = light*.
 
Al
 
From: ippm [mailto:ippm-bounces@ietf.org] On Behalf = Of Greg Mirsky
Sent: Monday, March 27, 2017 3:16 = PM
To: MORTON, ALFRED C (AL)
Cc: ippm@ietf.org
Subject: Re: [ippm] RFC 4656 on use = of OWAMP-Control and relationship with OWAMP-Test
 
Hi Al,
then, in my opinion, = there's certain ambiguity in the text of RFC 4656 and in RFC 5357 as = well because of the following statement in the very first sentence of = section 1.1 RFC 5357:
   Similar to OWAMP [RFC4656], TWAMP consists of two inter-related
   protocols: TWAMP-Control and TWAMP-Test.  =
The relationship of these
   =
protocols is as defined in Section =
1.1 of OWAMP [RFC4656]. 
 
Regards,
Greg
 
On Mon, Mar 27, 2017 = at 12:24 PM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:
Greg,
 
If we had meant RFC 2119 = =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80=9D (the term
you = used today when presenting) we would have used the
RFC = 2119 term in the text.
 
There = are plenty of other examples where both Control
and = Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D.
 
Al
 
 
From: ippm [mailto:ippm-bounces@ietf.org] On Behalf = Of Greg Mirsky
Sent: Monday, March 27, 2017 = 12:29 PM
To: ippm@ietf.org
Subject: [ippm] RFC 4656 on use of = OWAMP-Control and relationship with OWAMP-Test
 
Dear All,
the second paragraph in section 1.1 of RFC 4656 states the = following:
   =
Although OWAMP-Test may be used in conjunction with a control
   protocol other than OWAMP-Control, the authors =
have deliberately
   chosen to include =
both protocols in the same RFC to encourage the
   implementation and deployment of OWAMP-Control =
as a common
   denominator control =
protocol for one-way active measurements.
 
I interpret "may be used" as MAY =
per RFC 2119. Please let me know if this should not be the =
case.
 
Regards,
Greg
 
_______________________________________________
ippm mailing = list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_5B1C6FC8-32E6-4987-95DF-1990B4B2E731-- From nobody Mon Mar 27 14:54:03 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D95127076 for ; Mon, 27 Mar 2017 14:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tUb6XQDz1gUI for ; Mon, 27 Mar 2017 14:54:00 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DC3127011 for ; Mon, 27 Mar 2017 14:53:59 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id z15so29297159lfd.1 for ; Mon, 27 Mar 2017 14:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9j+U7/mwyOSkPQA3wi912qXeGvE8tFySV4pmh1polZg=; b=kN1eqbA/UnvR2rR4qPekwFvjB8iDs9TSAeFtils7IpnLo3ReLdhm3AYJ6Rij/VCEuO KqI7QqlFtexZvOXlhFE3KnQUAxDhWIiujBtImSQPHFKVXfFTM5E0AHkrJatDMwDAMmRP CwtwgcpYWuXQHMe574o4Swin0z8AT1BvcyE05WOO3kucYNp019l+S3C2Z5ZFDRjv1BPC oL+u2Y5Fgdr15vWegAglbYlPV/99HuB/2wOYtK41C83q/5YY7byB4WIosliSSadFdJPx fYk7XrxkL4XCmQ8aNLP7RXI2mctnaI2NC7xW/slDj49NG7VcFJmIMw/9s9wpsWsmzmrX h4TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9j+U7/mwyOSkPQA3wi912qXeGvE8tFySV4pmh1polZg=; b=OevWioCKkQCwNkI7T0rSN+GwqjcxQRfosiTFVyKLtcm0XezgKtf+RnuOG+bhAUzFuD 4Kv2lgOwOwybYzDWpUQEe50Ne/txcOFX6Ngad2E5Qmsps10AhVykI0EZoJwoF9Jswr1W kL/pWbew+AD0X/Z99JydWck1cooeiezqgFvlypFrUJ0hR4eg+iaa2taAACCvmA8PlYmA nl7l10rwziOZrs+3FJNSOL0iKnU0QCWH6kaPhvLWzIGMFBHEBrXjqNXbAHO3ashOENbq w61GTYSfjnlqiOm6f8rOh5rWvZ9xWfdSwjUvnRi/oyJpwzjb3f5X7j8mp7mh7DaOvf0C 9uWQ== X-Gm-Message-State: AFeK/H1YZoM4eNPWFvwb3UDLn/KID//EDdew2BoY9uLKuDToJ+khdn6eW5IuEguXmfCIcu4utbjl4yIjH3F9jg== X-Received: by 10.25.215.89 with SMTP id o86mr12639207lfg.92.1490651637880; Mon, 27 Mar 2017 14:53:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.195.18 with HTTP; Mon, 27 Mar 2017 14:53:57 -0700 (PDT) In-Reply-To: <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> From: Ron Even Date: Mon, 27 Mar 2017 16:53:57 -0500 Message-ID: To: Mahesh Jethanandani Cc: "ALFRED C MORTON (AL)" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a11412c4e5c1dd2054bbd61f9 Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 21:54:03 -0000 --001a11412c4e5c1dd2054bbd61f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I read both RFC5357 and RFC 4656 and even though they say that TWAMP consist of two protocol it never says that both MUST be used anywhere in the document. The document does not have a lot of normative text. Section 5 of RFC5357 is an example and not a requirement and even the text that was mentioned in the IPPM session "Appendix I provides an example for purely informational purposes. It suggests an incremental path to adopting TWAMP, by implementing the TWAMP-Test protocol first." Does not say that using TWAMP-Test without the control protocol SHOULD NOT be used. Roni Even On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > Greg, > > And the part that you forgot to quote that followed in Section 1.1 is: > > TWAMP- > Control is used to initiate, start, and stop test sessions, whereas > TWAMP-Test is used to exchange test packets between two TWAMP > entities. > > > There is clearly a precedence for TWAMP-Control to be a entity by itself > and very much part of the TWAMP protocol. > > If this is this rational for your comments on the YANG model, then I fail > to see RFC 5357 backing your claim that TWAMP-control is optional. > > Cheers. > > On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) > wrote: > > Greg, > > All ambiguity falls away in the context of > the complete TWAMP document, which says: > > This example eliminates the need for the TWAMP-Control protocol, and > assumes that the Session-Reflector is configured and communicates its > configuration with the Server through non-standard means. > > The example referred to above is not TWAMP; > it is the option you describe, but it is > called **TWAMP light**. > > Al > > *From:* ippm [mailto:ippm-bounces@ietf.org ] *On > Behalf Of *Greg Mirsky > *Sent:* Monday, March 27, 2017 3:16 PM > *To:* MORTON, ALFRED C (AL) > *Cc:* ippm@ietf.org > *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship > with OWAMP-Test > > Hi Al, > then, in my opinion, there's certain ambiguity in the text of RFC 4656 an= d > in RFC 5357 as well because of the following statement in the very first > sentence of section 1.1 RFC 5357: > > Similar to OWAMP [RFC4656 ], TWAMP consists = of two inter-related > > protocols: TWAMP-Control and TWAMP-Test. The relationship of these > > protocols is as defined in Section 1.1 of OWAMP [RFC4656 ]. > > > > Regards, > > Greg > > > On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) > wrote: > Greg, > > If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80= =9D (the term > you used today when presenting) we would have used the > RFC 2119 term in the text. > > There are plenty of other examples where both Control > and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D. > > Al > > > *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Monday, March 27, 2017 12:29 PM > *To:* ippm@ietf.org > *Subject:* [ippm] RFC 4656 on use of OWAMP-Control and relationship with > OWAMP-Test > > Dear All, > the second paragraph in section 1.1 of RFC 4656 states the following: > > Although OWAMP-Test may be used in conjunction with a control > > protocol other than OWAMP-Control, the authors have deliberately > > chosen to include both protocols in the same RFC to encourage the > > implementation and deployment of OWAMP-Control as a common > > denominator control protocol for one-way active measurements. > > > > I interpret "may be used" as MAY per RFC 2119. Please let me know if this= should not be the case. > > > > Regards, > > Greg > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --001a11412c4e5c1dd2054bbd61f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
I read both RFC5357 and RFC 4656 and even though t= hey say that TWAMP consist of two protocol it never says that =C2=A0both MU= ST be used anywhere in the document. The document does not have a lot of no= rmative text.

Section 5 of RFC5357 is an example a= nd not a requirement and even the text that was mentioned in the IPPM sessi= on

"Appendix I provides an example for purely i= nformational purposes. It
=
   suggests an incremental path to adopting TWAMP, by implementing the
   TWAMP-Test protocol first."
=

Does not say that using TWAMP-T=
est without the control protocol SHOULD NOT be used.

Roni Even





On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Greg,

And th= e part that you forgot to quote that followed in Section 1.1 is:
= 
On Mar 27, 2017, at=
 4:08 PM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:

Greg,=

=C2=A0
All ambiguity falls away in the context of
the complete TWAMP document, which says:
=C2=A0
=C2=A0=C2=A0 T=
his example eliminates the need for the TWAMP-Control protocol, and<=
u>
=C2=A0=C2=A0 assumes that the Session-Refle=
ctor is configured and communicates its
=C2=A0=C2=A0 configuration with the Server through non-standard means.<=
u>
=C2=A0
The example referred to above is not TWAMP;<=
/div>
it is the option you describe, but it is
called *TWAMP light*.
=C2=A0
Al<=
/u>
=C2=A0
From:=C2=A0ippm [mailto:ippm-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Greg Mirsky
Sent:=C2=A0=
Monday, March 27, 2017 3:16 PM
To:=C2=A0MORTON, ALFRED C (AL)
Cc:=C2=A0ippm@ietf.orgSubject:=C2=A0Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship =
with OWAMP-Test
Hi Al,
then, in my opinion, there's certain=
 ambiguity in the text of RFC 4656 and in RFC 5357 as well because of the f=
ollowing statement in the very first sentence of section 1.1 RFC 5357:
=C2=A0=C2=A0 Similar to OWAMP =
[RFC4656], TWAMP consists =
of two inter-related
=C2=A0=C2=
=A0 protocols: TWAMP-Control and TWAMP-Test.=C2=A0 The relationship of thes=
e
=C2=A0=C2=A0 protocols is as=
 defined in Section 1.1 of OWAMP [RFC4656]. 
=C2=A0<=
u>
Regards,
Greg
=C2=A0
On Mon, = Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:
Greg,
=C2=A0
If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2= =80=9COPTIONAL=E2=80=9D (the term
yo= u used today when presenting) we would have used the
RFC 2119 term in the text.
=C2=A0
There are plenty of o= ther examples where both Control
and= Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D.
=C2=A0
Al=
=C2=A0
=C2=A0
From:=C2=A0ippm [mailto:ippm-bounces@ietf.org]=C2=A0= On Behalf Of= =C2=A0Greg Mirsky
Sent:=C2=A0Monday, March 27, 2017 12:29 PMTo:=C2= =A0ippm@ietf.org
Subject:=C2=A0[ippm] = RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test=
=C2=A0=
Dear All,
=
the second paragraph in section 1.1 of RFC 4656 stat= es the following:
=C2=A0=
=C2=A0 Although OWAMP-Test may be used in conjunction with a control=

 =C2=A0=C2=A0protocol other than OWA=
MP-Control, the authors have deliberately
=C2=A0=C2=A0 chosen to include both protocols in the same RFC t=
o encourage the
=C2=A0=C2=A0 i=
mplementation and deployment of OWAMP-Control as a common<=
/u>
=C2=A0=C2=A0 denominator control protocol for o=
ne-way active measurements.
=
=C2=A0
I interpret "may b=
e used" as MAY per RFC 2119. Please let me know if this should not be =
the case.
=C2=A0=

Regards,
Greg
=C2=A0
___________________= ____________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm=
Mahesh Jethanandani




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


--001a11412c4e5c1dd2054bbd61f9-- From nobody Mon Mar 27 15:40:37 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77CF126BFD for ; Mon, 27 Mar 2017 15:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 eNSJvHxX2r24 for ; Mon, 27 Mar 2017 15:40:32 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 A620E12968F for ; Mon, 27 Mar 2017 15:40:32 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v2RMdD35043358; Mon, 27 Mar 2017 18:40:29 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 29fbqfg2cq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Mar 2017 18:40:28 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2RMeQ65023022; Mon, 27 Mar 2017 18:40:27 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2RMeF7H022846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Mar 2017 18:40:20 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 27 Mar 2017 22:39:54 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2RMds1G024944; Mon, 27 Mar 2017 17:39:54 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2RMdl9M024723; Mon, 27 Mar 2017 17:39:47 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-green.research.att.com (Postfix) with ESMTP id 4C1C9E127E; Mon, 27 Mar 2017 18:39:33 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Mon, 27 Mar 2017 18:39:46 -0400 From: "MORTON, ALFRED C (AL)" To: Ron Even , Mahesh Jethanandani CC: "ippm@ietf.org" Thread-Topic: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test Thread-Index: AQHSpxc8BtKwqovJekeye+fp0718nKGo7kpAgABjvwD//9sasIAAR8aAgAAJO4D//8YCMA== Date: Mon, 27 Mar 2017 22:39:45 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F3BAAD@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.130.6] Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF25F3BAADnjmtexg5researc_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_21:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703270185 Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:40:36 -0000 --_000_4D7F4AD313D3FC43A053B309F97543CF25F3BAADnjmtexg5researc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9uaSwgaW4tbGluZToNCg0KRnJvbTogUm9uIEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21h aWwuY29tXQ0KU2VudDogTW9uZGF5LCBNYXJjaCAyNywgMjAxNyA1OjU0IFBNDQpUbzogTWFoZXNo IEpldGhhbmFuZGFuaQ0KQ2M6IE1PUlRPTiwgQUxGUkVEIEMgKEFMKTsgaXBwbUBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtpcHBtXSBSRkMgNDY1NiBvbiB1c2Ugb2YgT1dBTVAtQ29udHJvbCBhbmQg cmVsYXRpb25zaGlwIHdpdGggT1dBTVAtVGVzdA0KDQpIaSwNCkkgcmVhZCBib3RoIFJGQzUzNTcg YW5kIFJGQyA0NjU2IGFuZCBldmVuIHRob3VnaCB0aGV5IHNheSB0aGF0IFRXQU1QIGNvbnNpc3Qg b2YgdHdvIHByb3RvY29sIGl0IG5ldmVyIHNheXMgdGhhdCAgYm90aCBNVVNUIGJlIHVzZWQgYW55 d2hlcmUgaW4gdGhlIGRvY3VtZW50LiBUaGUgZG9jdW1lbnQgZG9lcyBub3QgaGF2ZSBhIGxvdCBv ZiBub3JtYXRpdmUgdGV4dC4NCg0KU2VjdGlvbiA1IG9mIFJGQzUzNTcgaXMgYW4gZXhhbXBsZSBh bmQgbm90IGEgcmVxdWlyZW1lbnQgYW5kIGV2ZW4gdGhlIHRleHQgdGhhdCB3YXMgbWVudGlvbmVk IGluIHRoZSBJUFBNIHNlc3Npb24NCg0KIkFwcGVuZGl4IEk8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzUz NTctMjNhcHBlbmRpeC0yREkmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9T2Zz U3U4a1RJbHRWeUQxb0w3MmNCdyZtPThyekVxWEo5dUZadmgzdU9BNXlINFNBeThiYnRpSVdXa2tD NkU2dTlHeEUmcz1odXpTVHppQ09hM2hjWTJvX0MwN0pxWm5XTE0tT2xVdlJzV2p5OXZFWnZ3JmU9 PiBwcm92aWRlcyBhbiBleGFtcGxlIGZvciBwdXJlbHkgaW5mb3JtYXRpb25hbCBwdXJwb3Nlcy4g SXQNCg0KICAgc3VnZ2VzdHMgYW4gaW5jcmVtZW50YWwgcGF0aCB0byBhZG9wdGluZyBUV0FNUCwg YnkgaW1wbGVtZW50aW5nIHRoZQ0KDQogICBUV0FNUC1UZXN0IHByb3RvY29sIGZpcnN0LiINCg0K DQoNCkRvZXMgbm90IHNheSB0aGF0IHVzaW5nIFRXQU1QLVRlc3Qgd2l0aG91dCB0aGUgY29udHJv bCBwcm90b2NvbCBTSE9VTEQgTk9UIGJlIHVzZWQuDQoNCltBQ01dDQoNCk9mIGNvdXJzZSBpdCBk b2VzbuKAmXQhIEl0IHNheXMgQXBwZW5kaXggSSBkZXNjcmliZXMgYQ0KDQp0aGUgZmlyc3Qgc3Rl cCBvZiBvbmUgcHJvY2VzcyBvZiBzdGFuZGFyZHMtdHJhY2sgVFdBTVANCg0KaW1wbGVtZW50YXRp b24sIGJ5IHN0YXJ0aW5nIHdpdGggVFdBTVAtbGlnaHQsIHRoZW4NCg0KaW1wbGVtZW50aW5nIHRo ZSByZXN0IG9mIFRXQU1QIChUV0FNUC1Db250cm9sKS4NCg0KDQoNCkFsDQoNCg0KDQoNCg0KDQoN Cg0KDQpSb25pIEV2ZW4NCg0KDQoNCg0KDQoNCg0KDQoNCk9uIE1vbiwgTWFyIDI3LCAyMDE3IGF0 IDQ6MjAgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1h aWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyb3RlOg0KR3JlZywNCg0KQW5kIHRoZSBw YXJ0IHRoYXQgeW91IGZvcmdvdCB0byBxdW90ZSB0aGF0IGZvbGxvd2VkIGluIFNlY3Rpb24gMS4x IGlzOg0KDQoNClRXQU1QLQ0KDQogICBDb250cm9sIGlzIHVzZWQgdG8gaW5pdGlhdGUsIHN0YXJ0 LCBhbmQgc3RvcCB0ZXN0IHNlc3Npb25zLCB3aGVyZWFzDQoNCiAgIFRXQU1QLVRlc3QgaXMgdXNl ZCB0byBleGNoYW5nZSB0ZXN0IHBhY2tldHMgYmV0d2VlbiB0d28gVFdBTVANCg0KICAgZW50aXRp ZXMuDQoNClRoZXJlIGlzIGNsZWFybHkgYSBwcmVjZWRlbmNlIGZvciBUV0FNUC1Db250cm9sIHRv IGJlIGEgZW50aXR5IGJ5IGl0c2VsZiBhbmQgdmVyeSBtdWNoIHBhcnQgb2YgdGhlIFRXQU1QIHBy b3RvY29sLg0KDQpJZiB0aGlzIGlzIHRoaXMgcmF0aW9uYWwgZm9yIHlvdXIgY29tbWVudHMgb24g dGhlIFlBTkcgbW9kZWwsIHRoZW4gSSBmYWlsIHRvIHNlZSBSRkMgNTM1NyBiYWNraW5nIHlvdXIg Y2xhaW0gdGhhdCBUV0FNUC1jb250cm9sIGlzIG9wdGlvbmFsLg0KDQpDaGVlcnMuDQoNCk9uIE1h ciAyNywgMjAxNywgYXQgNDowOCBQTSwgTU9SVE9OLCBBTEZSRUQgQyAoQUwpIDxhY21vcnRvbkBh dHQuY29tPG1haWx0bzphY21vcnRvbkBhdHQuY29tPj4gd3JvdGU6DQoNCkdyZWcsDQoNCkFsbCBh bWJpZ3VpdHkgZmFsbHMgYXdheSBpbiB0aGUgY29udGV4dCBvZg0KdGhlIGNvbXBsZXRlIFRXQU1Q IGRvY3VtZW50LCB3aGljaCBzYXlzOg0KDQogICBUaGlzIGV4YW1wbGUgZWxpbWluYXRlcyB0aGUg bmVlZCBmb3IgdGhlIFRXQU1QLUNvbnRyb2wgcHJvdG9jb2wsIGFuZA0KICAgYXNzdW1lcyB0aGF0 IHRoZSBTZXNzaW9uLVJlZmxlY3RvciBpcyBjb25maWd1cmVkIGFuZCBjb21tdW5pY2F0ZXMgaXRz DQogICBjb25maWd1cmF0aW9uIHdpdGggdGhlIFNlcnZlciB0aHJvdWdoIG5vbi1zdGFuZGFyZCBt ZWFucy4NCg0KVGhlIGV4YW1wbGUgcmVmZXJyZWQgdG8gYWJvdmUgaXMgbm90IFRXQU1QOw0KaXQg aXMgdGhlIG9wdGlvbiB5b3UgZGVzY3JpYmUsIGJ1dCBpdCBpcw0KY2FsbGVkICpUV0FNUCBsaWdo dCouDQoNCkFsDQoNCkZyb206IGlwcG0gW21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBHcmVnIE1pcnNreQ0KU2VudDogTW9uZGF5LCBNYXJjaCAyNywgMjAxNyAzOjE2 IFBNDQpUbzogTU9SVE9OLCBBTEZSRUQgQyAoQUwpDQpDYzogaXBwbUBpZXRmLm9yZzxtYWlsdG86 aXBwbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbaXBwbV0gUkZDIDQ2NTYgb24gdXNlIG9mIE9X QU1QLUNvbnRyb2wgYW5kIHJlbGF0aW9uc2hpcCB3aXRoIE9XQU1QLVRlc3QNCg0KSGkgQWwsDQp0 aGVuLCBpbiBteSBvcGluaW9uLCB0aGVyZSdzIGNlcnRhaW4gYW1iaWd1aXR5IGluIHRoZSB0ZXh0 IG9mIFJGQyA0NjU2IGFuZCBpbiBSRkMgNTM1NyBhcyB3ZWxsIGJlY2F1c2Ugb2YgdGhlIGZvbGxv d2luZyBzdGF0ZW1lbnQgaW4gdGhlIHZlcnkgZmlyc3Qgc2VudGVuY2Ugb2Ygc2VjdGlvbiAxLjEg UkZDIDUzNTc6DQoNCiAgIFNpbWlsYXIgdG8gT1dBTVAgW1JGQzQ2NTY8aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1s X3JmYzQ2NTYmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9T2ZzU3U4a1RJbHRW eUQxb0w3MmNCdyZtPUdZTXkxX3NxZjltajZTMFpIM0I4dk5tcWUwRGhqbzdkZTYxUWIwUl9QRWsm cz14U2tmRlc1amo2WVBicXBjZm5BbGFocm9HN0RYZEkweGZpRkFTV1lwUXpVJmU9Pl0sIFRXQU1Q IGNvbnNpc3RzIG9mIHR3byBpbnRlci1yZWxhdGVkDQoNCiAgIHByb3RvY29sczogVFdBTVAtQ29u dHJvbCBhbmQgVFdBTVAtVGVzdC4gIFRoZSByZWxhdGlvbnNoaXAgb2YgdGhlc2UNCg0KICAgcHJv dG9jb2xzIGlzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAxLjE8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzUz NTctMjNzZWN0aW9uLTJEMS4xJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPU9m c1N1OGtUSWx0VnlEMW9MNzJjQncmbT1HWU15MV9zcWY5bWo2UzBaSDNCOHZObXFlMERoam83ZGU2 MVFiMFJfUEVrJnM9TGwwaDVYNG9Td1hYbDRHX0ZZMmNSUy1FdVF0T2xXN1VCaWVadXVVVkdubyZl PT4gb2YgT1dBTVAgW1JGQzQ2NTY8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzQ2NTYmZD1Ed01GYVEmYz1M RllaLW85X0hVTWVNVFNRaWN2aklnJnI9T2ZzU3U4a1RJbHRWeUQxb0w3MmNCdyZtPUdZTXkxX3Nx ZjltajZTMFpIM0I4dk5tcWUwRGhqbzdkZTYxUWIwUl9QRWsmcz14U2tmRlc1amo2WVBicXBjZm5B bGFocm9HN0RYZEkweGZpRkFTV1lwUXpVJmU9Pl0uDQoNCg0KDQpSZWdhcmRzLA0KDQpHcmVnDQoN Ck9uIE1vbiwgTWFyIDI3LCAyMDE3IGF0IDEyOjI0IFBNLCBNT1JUT04sIEFMRlJFRCBDIChBTCkg PGFjbW9ydG9uQGF0dC5jb208bWFpbHRvOmFjbW9ydG9uQGF0dC5jb20+PiB3cm90ZToNCkdyZWcs DQoNCklmIHdlIGhhZCBtZWFudCBSRkMgMjExOSDigJxNQVnigJ0gb3Ig4oCcT1BUSU9OQUzigJ0g KHRoZSB0ZXJtDQp5b3UgdXNlZCB0b2RheSB3aGVuIHByZXNlbnRpbmcpIHdlIHdvdWxkIGhhdmUg dXNlZCB0aGUNClJGQyAyMTE5IHRlcm0gaW4gdGhlIHRleHQuDQoNClRoZXJlIGFyZSBwbGVudHkg b2Ygb3RoZXIgZXhhbXBsZXMgd2hlcmUgYm90aCBDb250cm9sDQphbmQgVGVzdCBwcm90b2NvbHMg YXJlIHRha2VuIGFzIOKAnHRoZSBmdWxsIFRXQU1Q4oCdLg0KDQpBbA0KDQoNCkZyb206IGlwcG0g W21haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9y Zz5dIE9uIEJlaGFsZiBPZiBHcmVnIE1pcnNreQ0KU2VudDogTW9uZGF5LCBNYXJjaCAyNywgMjAx NyAxMjoyOSBQTQ0KVG86IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbaXBwbV0gUkZDIDQ2NTYgb24gdXNlIG9mIE9XQU1QLUNvbnRyb2wgYW5kIHJlbGF0aW9u c2hpcCB3aXRoIE9XQU1QLVRlc3QNCg0KRGVhciBBbGwsDQp0aGUgc2Vjb25kIHBhcmFncmFwaCBp biBzZWN0aW9uIDEuMSBvZiBSRkMgNDY1NiBzdGF0ZXMgdGhlIGZvbGxvd2luZzoNCg0KICAgQWx0 aG91Z2ggT1dBTVAtVGVzdCBtYXkgYmUgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIGEgY29udHJv bA0KDQogICBwcm90b2NvbCBvdGhlciB0aGFuIE9XQU1QLUNvbnRyb2wsIHRoZSBhdXRob3JzIGhh dmUgZGVsaWJlcmF0ZWx5DQoNCiAgIGNob3NlbiB0byBpbmNsdWRlIGJvdGggcHJvdG9jb2xzIGlu IHRoZSBzYW1lIFJGQyB0byBlbmNvdXJhZ2UgdGhlDQoNCiAgIGltcGxlbWVudGF0aW9uIGFuZCBk ZXBsb3ltZW50IG9mIE9XQU1QLUNvbnRyb2wgYXMgYSBjb21tb24NCg0KICAgZGVub21pbmF0b3Ig Y29udHJvbCBwcm90b2NvbCBmb3Igb25lLXdheSBhY3RpdmUgbWVhc3VyZW1lbnRzLg0KDQoNCg0K SSBpbnRlcnByZXQgIm1heSBiZSB1c2VkIiBhcyBNQVkgcGVyIFJGQyAyMTE5LiBQbGVhc2UgbGV0 IG1lIGtub3cgaWYgdGhpcyBzaG91bGQgbm90IGJlIHRoZSBjYXNlLg0KDQoNCg0KUmVnYXJkcywN Cg0KR3JlZw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pcHBtJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPU9m c1N1OGtUSWx0VnlEMW9MNzJjQncmbT04cnpFcVhKOXVGWnZoM3VPQTV5SDRTQXk4YmJ0aUlXV2tr QzZFNnU5R3hFJnM9Wk10UnRRZjdfdUV2QldUSThGSF95eHpuLUhPMVdoS3p6ZjA4bjg5a3F4cyZl PT4NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5v cmc8bWFpbHRvOmlwcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwcG08aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pcHBtJmQ9RHdNRmFRJmM9TEZZ Wi1vOV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtUSWx0VnlEMW9MNzJjQncmbT04cnpFcVhKOXVG WnZoM3VPQTV5SDRTQXk4YmJ0aUlXV2trQzZFNnU5R3hFJnM9Wk10UnRRZjdfdUV2QldUSThGSF95 eHpuLUhPMVdoS3p6ZjA4bjg5a3F4cyZlPT4NCg0K --_000_4D7F4AD313D3FC43A053B309F97543CF25F3BAADnjmtexg5researc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4ubTMxNTU1NTc3MzMzMDk0NTQ1 MzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6bV8zMTU1NTU3NzMzMzA5 NDU0NTM3YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1u YW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJvbmksIGluLWxpbmU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IFJvbiBFdmVuIFttYWlsdG86cm9uLmV2ZW4udGx2QGdtYWlsLmNvbV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDI3LCAyMDE3IDU6NTQgUE08YnI+DQo8 Yj5Ubzo8L2I+IE1haGVzaCBKZXRoYW5hbmRhbmk8YnI+DQo8Yj5DYzo8L2I+IE1PUlRPTiwgQUxG UkVEIEMgKEFMKTsgaXBwbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2lwcG1d IFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250cm9sIGFuZCByZWxhdGlvbnNoaXAgd2l0aCBP V0FNUC1UZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg cmVhZCBib3RoIFJGQzUzNTcgYW5kIFJGQyA0NjU2IGFuZCBldmVuIHRob3VnaCB0aGV5IHNheSB0 aGF0IFRXQU1QIGNvbnNpc3Qgb2YgdHdvIHByb3RvY29sIGl0IG5ldmVyIHNheXMgdGhhdCAmbmJz cDtib3RoIE1VU1QgYmUgdXNlZCBhbnl3aGVyZSBpbiB0aGUgZG9jdW1lbnQuIFRoZSBkb2N1bWVu dCBkb2VzIG5vdCBoYXZlIGEgbG90IG9mIG5vcm1hdGl2ZSB0ZXh0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDUgb2YgUkZDNTM1 NyBpcyBhbiBleGFtcGxlIGFuZCBub3QgYSByZXF1aXJlbWVudCBhbmQgZXZlbiB0aGUgdGV4dCB0 aGF0IHdhcyBtZW50aW9uZWQgaW4gdGhlIElQUE0gc2Vzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDs8YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYu b3JnX2h0bWxfcmZjNTM1Ny0yM2FwcGVuZGl4LTJESSZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1v OV9IVU1lTVRTUWljdmpJZyZhbXA7cj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3JmFtcDttPThyekVx WEo5dUZadmgzdU9BNXlINFNBeThiYnRpSVdXa2tDNkU2dTlHeEUmYW1wO3M9aHV6U1R6aUNPYTNo Y1kyb19DMDdKcVpuV0xNLU9sVXZSc1dqeTl2RVp2dyZhbXA7ZT0iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij5BcHBlbmRpeA0KIEk8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmJsYWNrIj4gcHJvdmlkZXMgYW4gZXhhbXBsZSBmb3IgcHVyZWx5IGlu Zm9ybWF0aW9uYWwgcHVycG9zZXMuIEl0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN1Z2dlc3RzIGFuIGlu Y3JlbWVudGFsIHBhdGggdG8gYWRvcHRpbmcgVFdBTVAsIGJ5IGltcGxlbWVudGluZyB0aGU8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgVFdBTVAtVGVzdCBwcm90b2NvbCBmaXJzdC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Eb2VzIG5vdCBz YXkgdGhhdCB1c2luZyBUV0FNUC1UZXN0IHdpdGhvdXQgdGhlIGNvbnRyb2wgcHJvdG9jb2wgU0hP VUxEIE5PVCBiZSB1c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+W0FDTV0gPC9zcGFuPjwvaT48 L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvYj48L3ByZT4NCjxwcmU+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6YmxhY2siPk9mIGNvdXJzZSBpdCBkb2VzbuKAmXQhIEl0IHNheXMgQXBwZW5kaXgg SSBkZXNjcmliZXMgYSA8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wcmU+DQo8cHJlPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj50aGUgZmlyc3Qgc3RlcCBvZiBv bmUgcHJvY2VzcyBvZiBzdGFuZGFyZHMtdHJhY2sgVFdBTVAgPG86cD48L286cD48L3NwYW4+PC9i PjwvcHJlPg0KPHByZT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFj ayI+aW1wbGVtZW50YXRpb24sIGJ5IHN0YXJ0aW5nIHdpdGggVFdBTVAtbGlnaHQsIHRoZW4gPG86 cD48L286cD48L3NwYW4+PC9iPjwvcHJlPg0KPHByZT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjpibGFjayI+aW1wbGVtZW50aW5nIHRoZSByZXN0IG9mIFRXQU1QIChUV0FN UC1Db250cm9sKS48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkFsPG86cD48L286cD48L3NwYW4+ PC9pPjwvYj48L3ByZT4NCjxwcmU+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wcmU+DQo8cHJl PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcHJlPg0KPHByZT48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9p PjwvYj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlJvbmkgRXZlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXIgMjcs IDIwMTcgYXQgNDoyMCBQTSwgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWpldGhhbmFuZGFuaUBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5HcmVnLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW5kIHRoZSBwYXJ0IHRoYXQgeW91IGZvcmdvdCB0byBxdW90ZSB0aGF0IGZvbGxvd2Vk IGluIFNlY3Rpb24gMS4xIGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJl IHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbCI+VFdBTVAtPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IENvbnRyb2wgaXMgdXNlZCB0byBpbml0aWF0ZSwgc3Rh cnQsIGFuZCBzdG9wIHRlc3Qgc2Vzc2lvbnMsIHdoZXJlYXM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgVFdBTVAtVGVzdCBpcyB1c2VkIHRvIGV4Y2hhbmdlIHRlc3QgcGFja2V0 cyBiZXR3ZWVuIHR3byBUV0FNUDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBl bnRpdGllcy48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlcmUgaXMgY2xlYXJseSBhIHByZWNlZGVuY2UgZm9yIFRXQU1QLUNvbnRyb2wgdG8gYmUgYSBl bnRpdHkgYnkgaXRzZWxmIGFuZCB2ZXJ5IG11Y2ggcGFydCBvZiB0aGUgVFdBTVAgcHJvdG9jb2wu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklm IHRoaXMgaXMgdGhpcyByYXRpb25hbCBmb3IgeW91ciBjb21tZW50cyBvbiB0aGUgWUFORyBtb2Rl bCwgdGhlbiBJIGZhaWwgdG8gc2VlIFJGQyA1MzU3IGJhY2tpbmcgeW91ciBjbGFpbSB0aGF0IFRX QU1QLWNvbnRyb2wgaXMgb3B0aW9uYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIg MjcsIDIwMTcsIGF0IDQ6MDggUE0sIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmFjbW9ydG9uQGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj5hY21vcnRvbkBhdHQuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkdyZWcs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BbGwgYW1iaWd1aXR5IGZhbGxzIGF3YXkg aW4gdGhlIGNvbnRleHQgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+dGhlIGNvbXBsZXRlIFRXQU1QIGRvY3VtZW50 LCB3aGljaCBzYXlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IFRoaXMgZXhhbXBsZSBlbGltaW5hdGVzIHRoZSBuZWVkIGZvciB0aGUgVFdBTVAtQ29udHJvbCBw cm90b2NvbCwgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBhc3N1bWVzIHRoYXQgdGhlIFNl c3Npb24tUmVmbGVjdG9yIGlzIGNvbmZpZ3VyZWQgYW5kIGNvbW11bmljYXRlcyBpdHM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24gd2l0aCB0aGUgU2VydmVyIHRocm91Z2gg bm9uLXN0YW5kYXJkIG1lYW5zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIGV4 YW1wbGUgcmVmZXJyZWQgdG8gYWJvdmUgaXMgbm90IFRXQU1QOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5pdCBpcyB0 aGUgb3B0aW9uIHlvdSBkZXNjcmliZSwgYnV0IGl0IGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmNhbGxlZCAqPGI+ VFdBTVAgbGlnaHQ8L2I+Ki48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBjbGFzcz0ibTMxNTU1NTc3MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5pcHBtDQogWzxhIGhyZWY9Im1haWx0bzppcHBtLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86aXBwbS1ib3VuY2VzQGlldGYu b3JnPC9hPl08c3BhbiBjbGFzcz0ibTMxNTU1NTc3MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0ibTMxNTU1NTc3 MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+R3JlZyBN aXJza3k8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0ibTMxNTU1NTc3MzMzMDk0NTQ1Mzdh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIE1hcmNoIDI3LCAyMDE3 IDM6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9Im0zMTU1NTU3NzMzMzA5NDU0NTM3 YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TU9SVE9OLCBBTEZSRUQgQyAoQUwp PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJtMzE1NTU1NzczMzMwOTQ1NDUzN2FwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aXBwbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48 c3BhbiBjbGFzcz0ibTMxNTU1NTc3MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5SZTogW2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250cm9sIGFu ZCByZWxhdGlvbnNoaXAgd2l0aCBPV0FNUC1UZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIEFsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnRoZW4sIGluIG15IG9waW5pb24sIHRoZXJlJ3MgY2VydGFpbiBhbWJpZ3VpdHkg aW4gdGhlIHRleHQgb2YgUkZDIDQ2NTYgYW5kIGluIFJGQyA1MzU3IGFzIHdlbGwgYmVjYXVzZSBv ZiB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiB0aGUgdmVyeSBmaXJzdCBzZW50ZW5jZSBvZiBz ZWN0aW9uIDEuMSBSRkMgNTM1Nzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZT4mbmJzcDsmbmJzcDsgU2ltaWxhciB0byBPV0FNUCBbPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9y Z19odG1sX3JmYzQ2NTYmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcm YW1wO3I9T2ZzU3U4a1RJbHRWeUQxb0w3MmNCdyZhbXA7bT1HWU15MV9zcWY5bWo2UzBaSDNCOHZO bXFlMERoam83ZGU2MVFiMFJfUEVrJmFtcDtzPXhTa2ZGVzVqajZZUGJxcGNmbkFsYWhyb0c3RFhk STB4ZmlGQVNXWXBRelUmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O0EgT25l LXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgKE9XQU1QKSZxdW90OyI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+UkZDNDY1Njwvc3Bhbj48L2E+XSwgVFdBTVAgY29uc2lzdHMgb2Yg dHdvIGludGVyLXJlbGF0ZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcHJv dG9jb2xzOiBUV0FNUC1Db250cm9sIGFuZCBUV0FNUC1UZXN0LiZuYnNwOyBUaGUgcmVsYXRpb25z aGlwIG9mIHRoZXNlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHByb3RvY29s cyBpcyBhcyBkZWZpbmVkIGluIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1MzU3LTIzc2Vj dGlvbi0yRDEuMSZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7 cj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3JmFtcDttPUdZTXkxX3NxZjltajZTMFpIM0I4dk5tcWUw RGhqbzdkZTYxUWIwUl9QRWsmYW1wO3M9TGwwaDVYNG9Td1hYbDRHX0ZZMmNSUy1FdVF0T2xXN1VC aWVadXVVVkdubyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5TZWN0aW9uIDEuMTwvc3Bhbj48L2E+IG9mIE9XQU1QIFs8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3Jn X2h0bWxfcmZjNDY1NiZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZh bXA7cj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3JmFtcDttPUdZTXkxX3NxZjltajZTMFpIM0I4dk5t cWUwRGhqbzdkZTYxUWIwUl9QRWsmYW1wO3M9eFNrZkZXNWpqNllQYnFwY2ZuQWxhaHJvRzdEWGRJ MHhmaUZBU1dZcFF6VSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7QSBPbmUt d2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoT1dBTVApJnF1b3Q7Ij48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5SRkM0NjU2PC9zcGFuPjwvYT5dLiA8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPkdyZWc8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXIgMjcsIDIwMTcg YXQgMTI6MjQgUE0sIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFj bW9ydG9uQGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5hY21vcnRvbkBhdHQuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+R3JlZyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPklmIHdlIGhhZCBtZWFudCBS RkMgMjExOSDigJxNQVnigJ0gb3Ig4oCcT1BUSU9OQUzigJ0gKHRoZSB0ZXJtPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PnlvdSB1c2VkIHRvZGF5IHdoZW4gcHJlc2VudGluZykgd2Ugd291bGQgaGF2ZSB1c2VkIHRoZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5SRkMgMjExOSB0ZXJtIGluIHRoZSB0ZXh0Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+VGhlcmUgYXJlIHBsZW50eSBvZiBvdGhlciBleGFtcGxlcyB3aGVyZSBib3Ro IENvbnRyb2w8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+YW5kIFRlc3QgcHJvdG9jb2xzIGFyZSB0YWtlbiBhcyDigJx0 aGUgZnVsbCBUV0FNUOKAnS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9Im0zMTU1NTU3NzMzMzA5NDU0 NTM3YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aXBwbQ0KIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlwcG0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+XTxzcGFuIGNsYXNzPSJtMzE1NTU1NzczMzMwOTQ1NDUzN2FwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJtMzE1NTU1NzczMzMw OTQ1NDUzN2FwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5HcmVnDQogTWly c2t5PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9Im0zMTU1NTU3NzMzMzA5NDU0NTM3YXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBNYXJjaCAyNywgMjAxNyAx MjoyOSBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0ibTMxNTU1NTc3MzMzMDk0NTQ1Mzdh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aXBwbUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlwcG1A aWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJtMzE1 NTU1NzczMzMwOTQ1NDUzN2FwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltpcHBt XSBSRkMgNDY1NiBvbiB1c2Ugb2YgT1dBTVAtQ29udHJvbCBhbmQgcmVsYXRpb25zaGlwIHdpdGgg T1dBTVAtVGVzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIg QWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHNlY3Rpb24gMS4xIG9mIFJGQyA0NjU2IHN0 YXRlcyB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cHJlPiZuYnNwOyZuYnNwOyBBbHRob3VnaCBPV0FNUC1UZXN0IG1heSBiZSB1c2VkIGluIGNv bmp1bmN0aW9uIHdpdGggYSBjb250cm9sPG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZu YnNwO3Byb3RvY29sIG90aGVyIHRoYW4gT1dBTVAtQ29udHJvbCwgdGhlIGF1dGhvcnMgaGF2ZSBk ZWxpYmVyYXRlbHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY2hvc2VuIHRv IGluY2x1ZGUgYm90aCBwcm90b2NvbHMgaW4gdGhlIHNhbWUgUkZDIHRvIGVuY291cmFnZSB0aGU8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb24gYW5kIGRl cGxveW1lbnQgb2YgT1dBTVAtQ29udHJvbCBhcyBhIGNvbW1vbjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBkZW5vbWluYXRvciBjb250cm9sIHByb3RvY29sIGZvciBvbmUtd2F5 IGFjdGl2ZSBtZWFzdXJlbWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwcmU+SSBpbnRlcnByZXQgJnF1b3Q7bWF5IGJlIHVzZWQmcXVvdDsgYXMg TUFZIHBlciBSRkMgMjExOS4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHRoaXMgc2hvdWxkIG5vdCBi ZSB0aGUgY2FzZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkdyZWc8bzpwPjwvbzpwPjwv cHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KaXBwbSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmlwcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19pcHBtJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPU9m c1N1OGtUSWx0VnlEMW9MNzJjQncmYW1wO209OHJ6RXFYSjl1Rlp2aDN1T0E1eUg0U0F5OGJidGlJ V1dra0M2RTZ1OUd4RSZhbXA7cz1aTXRSdFFmN191RXZCV1RJOEZIX3l4em4tSE8xV2hLenpmMDhu ODlrcXhzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBwbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImhvZW56 YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojODg4ODg4Ij5NYWhlc2ggSmV0aGFuYW5kYW5pPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM4ODg4ODgiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQppcHBtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzppcHBtQGlldGYub3JnIj5pcHBtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9faXBwbSZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRT UWljdmpJZyZhbXA7cj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3JmFtcDttPThyekVxWEo5dUZadmgz dU9BNXlINFNBeThiYnRpSVdXa2tDNkU2dTlHeEUmYW1wO3M9Wk10UnRRZjdfdUV2QldUSThGSF95 eHpuLUhPMVdoS3p6ZjA4bjg5a3F4cyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4D7F4AD313D3FC43A053B309F97543CF25F3BAADnjmtexg5researc_-- From nobody Mon Mar 27 15:53:55 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F0B1296A4 for ; Mon, 27 Mar 2017 15:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CnDF9YpooQ-B for ; Mon, 27 Mar 2017 15:53:50 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F391204DA for ; Mon, 27 Mar 2017 15:53:49 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id z15so29737480lfd.1 for ; Mon, 27 Mar 2017 15:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C8UEc5w72XuPHp+JpAeu2MUgsloZY5E/2RKxZhEHxkM=; b=m4ht6uSsbZ2mfoBLLAHeR1LxvG+HekTYKsAVsvON6J0rxWYoHwRyVlZlQejrqr3HQ6 MsogShkiyzunhZNzVk3YbuM++pYK3lDkoQQ5wojTRab5Gw16CYOSuNohD9aRu7QWsizV Ui3ixgFzMLxYzQz4+aa8qeOOWj/hYQq4Hvbo5XBsK401WNYHJPQOsYSNP1LzIzBrEQMo ke7BUK+wDVcfBuLnMGqx1ymjLqJF65YEw1kKxrM3ceIevX9RyvE9LBqhqX1vewxfx3pi 2IgUUNSvWS2HNgnGbtQzlnIr9DMzpBjbYJOWG9+yRt563x/2lz43RcvU/Y/sixEy6pke kadA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C8UEc5w72XuPHp+JpAeu2MUgsloZY5E/2RKxZhEHxkM=; b=I+a9aFRQND9ClVBmkxK/H+Cq6i4FqEUFQ2tVs+3iZv1j65Rx+fX2QN8Axa9qIXtmbg xAuoxQQwe/TuvsMUhvQx72rSyXwspirrHS3yRsOHfbNqbDp69dQ/fWrpJu31R8XP2nNf WKLFZIZLBnwpdxlNl6YThSMrIfW112uFSxg/Xo6in9RfhJX18jIzza3YRQpuJekKniVh nOdsrSt8OlgUAIOiI8R74+A0FWNjhpDZERepgrStSJ/cGslN90owZMD8KfYQA3OdGh0Q xXORCuW3E8HqwueqZpJx8FHY/syxvGdXWFncSUTmovirYIId5HdDLyPERyRxDYLZ/c4x x41g== X-Gm-Message-State: AFeK/H3DT6qdJNQNWfzM93DbjuTf8BLxZU9UeN6xStA1RqKWZS0IbcMi5NXJIvPJeidTUTeL/2SY0CBKx6dXbg== X-Received: by 10.46.83.25 with SMTP id h25mr532044ljb.28.1490655227803; Mon, 27 Mar 2017 15:53:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.195.18 with HTTP; Mon, 27 Mar 2017 15:53:47 -0700 (PDT) In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F3BAAD@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAAD@njmtexg5.research.att.com> From: Ron Even Date: Mon, 27 Mar 2017 17:53:47 -0500 Message-ID: To: "MORTON, ALFRED C (AL)" Cc: Mahesh Jethanandani , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=f4030436014255fcdd054bbe37a7 Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 22:53:53 -0000 --f4030436014255fcdd054bbe37a7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Al, The last part of your response "* then **implementing the rest of TWAMP (TWAMP-Control)." is not there. This is why I said that it does not say that you SHOULD implement the control protocol, you can stop after implmenting the test protocol.* *Roni* On Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALFRED C (AL) wrote: > Roni, in-line: > > > > *From:* Ron Even [mailto:ron.even.tlv@gmail.com] > *Sent:* Monday, March 27, 2017 5:54 PM > *To:* Mahesh Jethanandani > *Cc:* MORTON, ALFRED C (AL); ippm@ietf.org > *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship > with OWAMP-Test > > > > Hi, > > I read both RFC5357 and RFC 4656 and even though they say that TWAMP > consist of two protocol it never says that both MUST be used anywhere in > the document. The document does not have a lot of normative text. > > > > Section 5 of RFC5357 is an example and not a requirement and even the tex= t > that was mentioned in the IPPM session > > > > "Appendix I > > provides an example for purely informational purposes. It > > suggests an incremental path to adopting TWAMP, by implementing the > > TWAMP-Test protocol first." > > > > Does not say that using TWAMP-Test without the control protocol SHOULD NO= T be used. > > *[ACM] * > > *Of course it doesn=E2=80=99t! It says Appendix I describes a * > > *the first step of one process of standards-track TWAMP * > > *implementation, by starting with TWAMP-light, then * > > *implementing the rest of TWAMP (TWAMP-Control).* > > > > *Al* > > > > > > > > > > Roni Even > > > > > > > > > > > > On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > > Greg, > > > > And the part that you forgot to quote that followed in Section 1.1 is: > > > > TWAMP- > > Control is used to initiate, start, and stop test sessions, whereas > > TWAMP-Test is used to exchange test packets between two TWAMP > > entities. > > > > There is clearly a precedence for TWAMP-Control to be a entity by itself > and very much part of the TWAMP protocol. > > > > If this is this rational for your comments on the YANG model, then I fail > to see RFC 5357 backing your claim that TWAMP-control is optional. > > > > Cheers. > > > > On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) > wrote: > > > > Greg, > > > > All ambiguity falls away in the context of > > the complete TWAMP document, which says: > > > > This example eliminates the need for the TWAMP-Control protocol, and > > assumes that the Session-Reflector is configured and communicates its > > configuration with the Server through non-standard means. > > > > The example referred to above is not TWAMP; > > it is the option you describe, but it is > > called **TWAMP light**. > > > > Al > > > > *From:* ippm [mailto:ippm-bounces@ietf.org ] *On > Behalf Of *Greg Mirsky > *Sent:* Monday, March 27, 2017 3:16 PM > *To:* MORTON, ALFRED C (AL) > *Cc:* ippm@ietf.org > *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship > with OWAMP-Test > > > > Hi Al, > > then, in my opinion, there's certain ambiguity in the text of RFC 4656 an= d > in RFC 5357 as well because of the following statement in the very first > sentence of section 1.1 RFC 5357: > > Similar to OWAMP [RFC4656 ], TWAMP consists = of two inter-related > > protocols: TWAMP-Control and TWAMP-Test. The relationship of these > > protocols is as defined in Section 1.1 of OWAMP [RFC4656 ]. > > > > Regards, > > Greg > > > > On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) > wrote: > > Greg, > > > > If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80= =9D (the term > > you used today when presenting) we would have used the > > RFC 2119 term in the text. > > > > There are plenty of other examples where both Control > > and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D. > > > > Al > > > > > > *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Monday, March 27, 2017 12:29 PM > *To:* ippm@ietf.org > *Subject:* [ippm] RFC 4656 on use of OWAMP-Control and relationship with > OWAMP-Test > > > > Dear All, > > the second paragraph in section 1.1 of RFC 4656 states the following: > > Although OWAMP-Test may be used in conjunction with a control > > protocol other than OWAMP-Control, the authors have deliberately > > chosen to include both protocols in the same RFC to encourage the > > implementation and deployment of OWAMP-Control as a common > > denominator control protocol for one-way active measurements. > > > > I interpret "may be used" as MAY per RFC 2119. Please let me know if this= should not be the case. > > > > Regards, > > Greg > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > --f4030436014255fcdd054bbe37a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Al,
The last part of your response =C2=A0" then implementing the rest of TWAMP (TW= AMP-Control)." is not there. This is why I said that it does not say t= hat you SHOULD implement the control protocol, you can stop after implmenti= ng the test protocol.
Roni
=
On Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALF= RED C (AL) <acmorton@att.com> wrote:

Roni, in-line:

=C2=A0

From: Ron Even= [mailto:ron.ev= en.tlv@gmail.com]
Sent: Monday, March 27, 2017 5:54 PM
To: Mahesh Jethanandani
Cc: MORTON, ALFRED C (AL); ippm@ietf.org
Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationshi= p with OWAMP-Test

=C2=A0

Hi,

I read both RFC5357 and RFC 4656 and even though the= y say that TWAMP consist of two protocol it never says that =C2=A0both MUST= be used anywhere in the document. The document does not have a lot of norm= ative text.

=C2=A0

Section 5 of RFC5357 is an example and not a require= ment and even the text that was mentioned in the IPPM session=

=C2=A0

"Appendix I provides an exam= ple for purely informational purposes. It

=C2=A0=C2=A0 suggests an incremental path =
to adopting TWAMP, by implementing the
=C2=A0=C2=A0 TWAMP-Test protocol first.&qu=
ot;
=C2=A0
Does not say that using TWAMP-Test without=
 the control protocol SHOULD NOT be used.
[ACM] 
Of course it doesn=E2=
=80=99t! It says Appendix I describes a 
the first step of one =
process of standards-track TWAMP 
implementation, by sta=
rting with TWAMP-light, then 
implementing the rest =
of TWAMP (TWAMP-Control).
=C2=A0
Al
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Roni Even
=C2=A0
=C2=A0
=C2=A0
=C2=A0

=C2=A0

On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani= <mjethanan= dani@gmail.com> wrote:

Greg,

=C2=A0

And the part that you forgot to quote that followed = in Section 1.1 is:

=C2=A0

TWAMP-
=C2=A0=C2=A0 Control is used to initiate, start, and stop test session=
s, whereas
=C2=A0=C2=A0 TWAMP-Test is used to exchange test packets between two T=
WAMP
=C2=A0=C2=A0 entities.

=C2=A0

There is clearly a precedence for TWAMP-Control to b= e a entity by itself and very much part of the TWAMP protocol.

=C2=A0

If this is this rational for your comments on the YA= NG model, then I fail to see RFC 5357 backing your claim that TWAMP-control= is optional.

=C2=A0

Cheers.

=C2=A0

On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) &= lt;acmorton@att.com> wrote:

=C2=A0

Greg,

=C2=A0

All ambiguity falls away in the context of

the complete TWAMP document, which says:<= /u>

=C2=A0

=C2=A0=C2=A0 This example eliminates the need for the TWAM= P-Control protocol, and

=C2=A0=C2=A0 assumes that the Session-Reflector is configu= red and communicates its

=C2=A0=C2=A0 configuration with the Server through non-sta= ndard means.

=C2=A0

The example referred to above is not TWAMP;<= u>

it is the option you describe, but it is<= /u>

called *TWAMP light*.

=C2=A0

Al

=C2=A0

=C2=A0

Hi Al,

then, in my opinion, there's certain ambiguity i= n the text of RFC 4656 and in RFC 5357 as well because of the following sta= tement in the very first sentence of section 1.1 RFC 5357: 

=C2=A0=C2=A0 Similar to OWAMP [RFC4656=
], TWAMP consists of two inter-related
=C2=A0=C2=A0 protocols: TWAMP-Control and TWAMP-Test.=C2=A0 The relati=
onship of these
=C2=A0=C2=A0 protocols is as defined in Section 1.1 of OWAMP [RFC4656]. 
=C2=A0
Regards,
Greg

=C2=A0

On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (= AL) <acmorton@att.com> wrote:

Greg,

=C2=A0

If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80= =9COPTIONAL=E2=80=9D (the term

you used today when presenting) we would have used the

RFC 2119 term in the text.

=C2=A0

There are plenty of other examples where both Control

and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2= =80=9D.

=C2=A0

Al

=C2=A0

=C2=A0

From:=C2= =A0ippm [mailto:ippm-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Greg Mirsky
Sent:=C2=A0Monday, March 27, 2017 12:29 PM
To:=C2=A0ippm@ietf.org
Subject:=C2=A0[ippm] RFC 4656 on use of OWAMP-Control and= relationship with OWAMP-Test

=C2=A0

Dear All,

the second paragraph in section 1.1 of RFC 4656 stat= es the following:

=C2=A0=C2=A0 Although OWAMP-Test may be used in conjunction with a con=
trol
 =C2=A0=C2=A0protocol other than OWAMP-Control, the authors have delib=
erately
=C2=A0=C2=A0 chosen to include both protocols in the same RFC to encou=
rage the
=C2=A0=C2=A0 implementation and deployment of OWAMP-Control as a commo=
n
=C2=A0=C2=A0 denominator control protocol for one-way active measureme=
nts.
=C2=A0
I interpret "may be used" as MAY per RFC 2119. Please let me=
 know if this should not be the case.
=C2=A0
Regards,
Greg

=C2=A0

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

=C2=A0

Mahesh Jethanandani

=C2=A0

=C2=A0

=C2=A0


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

=C2=A0


--f4030436014255fcdd054bbe37a7-- From nobody Mon Mar 27 16:08:06 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E23A1296C2 for ; Mon, 27 Mar 2017 16:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pJXHXjejes_g for ; Mon, 27 Mar 2017 16:07:59 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B8FCE1296C3 for ; Mon, 27 Mar 2017 16:07:59 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v2RMwhNv019928; Mon, 27 Mar 2017 19:07:57 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 29fc0kr996-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Mar 2017 19:07:56 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2RN7srY023463; Mon, 27 Mar 2017 19:07:55 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2RN7fhx023253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Mar 2017 19:07:46 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 27 Mar 2017 23:07:31 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2RN7VLh004338; Mon, 27 Mar 2017 18:07:31 -0500 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2RN7RW0004217; Mon, 27 Mar 2017 18:07:28 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-azure.research.att.com (Postfix) with ESMTP id F14CBE0AA4; Mon, 27 Mar 2017 19:07:26 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Mon, 27 Mar 2017 19:07:26 -0400 From: "MORTON, ALFRED C (AL)" To: Ron Even CC: Mahesh Jethanandani , "ippm@ietf.org" Thread-Topic: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test Thread-Index: AQHSpxc8BtKwqovJekeye+fp0718nKGo7kpAgABjvwD//9sasIAAR8aAgAAJO4D//8YCMIAASrWA//+9eUA= Date: Mon, 27 Mar 2017 23:07:25 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F3BAF0@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAAD@njmtexg5.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.130.6] Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF25F3BAF0njmtexg5researc_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-27_21:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703270186 Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 23:08:02 -0000 --_000_4D7F4AD313D3FC43A053B309F97543CF25F3BAF0njmtexg5researc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gc29ycnkgUm9uaSwgYnV0IHRoYXTigJlzIGV4YWN0bHkgd2hhdCB0aGlzIHBocmFzZSwN CuKAnC4uLmFuIGluY3JlbWVudGFsIHBhdGggdG8gYWRvcHRpbmcgVFdBTVDigKbigJ0gIG1lYW5z LA0Kc3VnZ2VzdGluZyBhIG11bHRpLXN0ZXAgcHJvY2VzcyB0byBhY2hpZXZlIGEgZnVsbCBUV0FN UA0KaW1wbGVtZW50YXRpb24uDQoNClRoZSBzZW50ZW5jZSBpbiB0aGUgYm9keSBzZXRzIHRoZSBj b250ZXh0IGZvciBBcHBlbmRpeCBJLg0KSXQgc2F5cyB0aGUgQXBwZW5kaXggZGVzY3JpYmVzIGJ1 aWxkaW5nIFRXQU1QLVRlc3QgKmZpcnN0Ki4NCkNsZWFybHksIFRXQU1QLVRlc3QgaXMgbm90IHRo ZSBmaW5hbCBzdGVwIQ0KDQpBbA0KDQpGcm9tOiBSb24gRXZlbiBbbWFpbHRvOnJvbi5ldmVuLnRs dkBnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIE1hcmNoIDI3LCAyMDE3IDY6NTQgUE0NClRvOiBN T1JUT04sIEFMRlJFRCBDIChBTCkNCkNjOiBNYWhlc2ggSmV0aGFuYW5kYW5pOyBpcHBtQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250cm9s IGFuZCByZWxhdGlvbnNoaXAgd2l0aCBPV0FNUC1UZXN0DQoNCkFsLA0KVGhlIGxhc3QgcGFydCBv ZiB5b3VyIHJlc3BvbnNlICAiIHRoZW4gaW1wbGVtZW50aW5nIHRoZSByZXN0IG9mIFRXQU1QIChU V0FNUC1Db250cm9sKS4iIGlzIG5vdCB0aGVyZS4gVGhpcyBpcyB3aHkgSSBzYWlkIHRoYXQgaXQg ZG9lcyBub3Qgc2F5IHRoYXQgeW91IFNIT1VMRCBpbXBsZW1lbnQgdGhlIGNvbnRyb2wgcHJvdG9j b2wsIHlvdSBjYW4gc3RvcCBhZnRlciBpbXBsbWVudGluZyB0aGUgdGVzdCBwcm90b2NvbC4NClJv bmkNCg0KT24gTW9uLCBNYXIgMjcsIDIwMTcgYXQgNTozOSBQTSwgTU9SVE9OLCBBTEZSRUQgQyAo QUwpIDxhY21vcnRvbkBhdHQuY29tPG1haWx0bzphY21vcnRvbkBhdHQuY29tPj4gd3JvdGU6DQpS b25pLCBpbi1saW5lOg0KDQpGcm9tOiBSb24gRXZlbiBbbWFpbHRvOnJvbi5ldmVuLnRsdkBnbWFp bC5jb208bWFpbHRvOnJvbi5ldmVuLnRsdkBnbWFpbC5jb20+XQ0KU2VudDogTW9uZGF5LCBNYXJj aCAyNywgMjAxNyA1OjU0IFBNDQpUbzogTWFoZXNoIEpldGhhbmFuZGFuaQ0KQ2M6IE1PUlRPTiwg QUxGUkVEIEMgKEFMKTsgaXBwbUBpZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbaXBwbV0gUkZDIDQ2NTYgb24gdXNlIG9mIE9XQU1QLUNvbnRyb2wgYW5kIHJlbGF0 aW9uc2hpcCB3aXRoIE9XQU1QLVRlc3QNCg0KSGksDQpJIHJlYWQgYm90aCBSRkM1MzU3IGFuZCBS RkMgNDY1NiBhbmQgZXZlbiB0aG91Z2ggdGhleSBzYXkgdGhhdCBUV0FNUCBjb25zaXN0IG9mIHR3 byBwcm90b2NvbCBpdCBuZXZlciBzYXlzIHRoYXQgIGJvdGggTVVTVCBiZSB1c2VkIGFueXdoZXJl IGluIHRoZSBkb2N1bWVudC4gVGhlIGRvY3VtZW50IGRvZXMgbm90IGhhdmUgYSBsb3Qgb2Ygbm9y bWF0aXZlIHRleHQuDQoNClNlY3Rpb24gNSBvZiBSRkM1MzU3IGlzIGFuIGV4YW1wbGUgYW5kIG5v dCBhIHJlcXVpcmVtZW50IGFuZCBldmVuIHRoZSB0ZXh0IHRoYXQgd2FzIG1lbnRpb25lZCBpbiB0 aGUgSVBQTSBzZXNzaW9uDQoNCiJBcHBlbmRpeCBJPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1MzU3LTIz YXBwZW5kaXgtMkRJJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtU SWx0VnlEMW9MNzJjQncmbT04cnpFcVhKOXVGWnZoM3VPQTV5SDRTQXk4YmJ0aUlXV2trQzZFNnU5 R3hFJnM9aHV6U1R6aUNPYTNoY1kyb19DMDdKcVpuV0xNLU9sVXZSc1dqeTl2RVp2dyZlPT4gcHJv dmlkZXMgYW4gZXhhbXBsZSBmb3IgcHVyZWx5IGluZm9ybWF0aW9uYWwgcHVycG9zZXMuIEl0DQoN CiAgIHN1Z2dlc3RzIGFuIGluY3JlbWVudGFsIHBhdGggdG8gYWRvcHRpbmcgVFdBTVAsIGJ5IGlt cGxlbWVudGluZyB0aGUNCg0KICAgVFdBTVAtVGVzdCBwcm90b2NvbCBmaXJzdC4iDQoNCg0KDQpE b2VzIG5vdCBzYXkgdGhhdCB1c2luZyBUV0FNUC1UZXN0IHdpdGhvdXQgdGhlIGNvbnRyb2wgcHJv dG9jb2wgU0hPVUxEIE5PVCBiZSB1c2VkLg0KDQpbQUNNXQ0KDQpPZiBjb3Vyc2UgaXQgZG9lc27i gJl0ISBJdCBzYXlzIEFwcGVuZGl4IEkgZGVzY3JpYmVzIGENCg0KdGhlIGZpcnN0IHN0ZXAgb2Yg b25lIHByb2Nlc3Mgb2Ygc3RhbmRhcmRzLXRyYWNrIFRXQU1QDQoNCmltcGxlbWVudGF0aW9uLCBi eSBzdGFydGluZyB3aXRoIFRXQU1QLWxpZ2h0LCB0aGVuDQoNCmltcGxlbWVudGluZyB0aGUgcmVz dCBvZiBUV0FNUCAoVFdBTVAtQ29udHJvbCkuDQoNCg0KDQpBbA0KDQoNCg0KDQoNCg0KDQoNCg0K Um9uaSBFdmVuDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiBNb24sIE1hciAyNywgMjAxNyBhdCA0OjIw IFBNLCBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86 bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+PiB3cm90ZToNCkdyZWcsDQoNCkFuZCB0aGUgcGFydCB0 aGF0IHlvdSBmb3Jnb3QgdG8gcXVvdGUgdGhhdCBmb2xsb3dlZCBpbiBTZWN0aW9uIDEuMSBpczoN Cg0KDQpUV0FNUC0NCg0KICAgQ29udHJvbCBpcyB1c2VkIHRvIGluaXRpYXRlLCBzdGFydCwgYW5k IHN0b3AgdGVzdCBzZXNzaW9ucywgd2hlcmVhcw0KDQogICBUV0FNUC1UZXN0IGlzIHVzZWQgdG8g ZXhjaGFuZ2UgdGVzdCBwYWNrZXRzIGJldHdlZW4gdHdvIFRXQU1QDQoNCiAgIGVudGl0aWVzLg0K DQpUaGVyZSBpcyBjbGVhcmx5IGEgcHJlY2VkZW5jZSBmb3IgVFdBTVAtQ29udHJvbCB0byBiZSBh IGVudGl0eSBieSBpdHNlbGYgYW5kIHZlcnkgbXVjaCBwYXJ0IG9mIHRoZSBUV0FNUCBwcm90b2Nv bC4NCg0KSWYgdGhpcyBpcyB0aGlzIHJhdGlvbmFsIGZvciB5b3VyIGNvbW1lbnRzIG9uIHRoZSBZ QU5HIG1vZGVsLCB0aGVuIEkgZmFpbCB0byBzZWUgUkZDIDUzNTcgYmFja2luZyB5b3VyIGNsYWlt IHRoYXQgVFdBTVAtY29udHJvbCBpcyBvcHRpb25hbC4NCg0KQ2hlZXJzLg0KDQpPbiBNYXIgMjcs IDIwMTcsIGF0IDQ6MDggUE0sIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSA8YWNtb3J0b25AYXR0LmNv bTxtYWlsdG86YWNtb3J0b25AYXR0LmNvbT4+IHdyb3RlOg0KDQpHcmVnLA0KDQpBbGwgYW1iaWd1 aXR5IGZhbGxzIGF3YXkgaW4gdGhlIGNvbnRleHQgb2YNCnRoZSBjb21wbGV0ZSBUV0FNUCBkb2N1 bWVudCwgd2hpY2ggc2F5czoNCg0KICAgVGhpcyBleGFtcGxlIGVsaW1pbmF0ZXMgdGhlIG5lZWQg Zm9yIHRoZSBUV0FNUC1Db250cm9sIHByb3RvY29sLCBhbmQNCiAgIGFzc3VtZXMgdGhhdCB0aGUg U2Vzc2lvbi1SZWZsZWN0b3IgaXMgY29uZmlndXJlZCBhbmQgY29tbXVuaWNhdGVzIGl0cw0KICAg Y29uZmlndXJhdGlvbiB3aXRoIHRoZSBTZXJ2ZXIgdGhyb3VnaCBub24tc3RhbmRhcmQgbWVhbnMu DQoNClRoZSBleGFtcGxlIHJlZmVycmVkIHRvIGFib3ZlIGlzIG5vdCBUV0FNUDsNCml0IGlzIHRo ZSBvcHRpb24geW91IGRlc2NyaWJlLCBidXQgaXQgaXMNCmNhbGxlZCAqVFdBTVAgbGlnaHQqLg0K DQpBbA0KDQpGcm9tOiBpcHBtIFttYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgR3JlZyBNaXJza3kNClNlbnQ6IE1vbmRheSwgTWFyY2ggMjcsIDIwMTcgMzoxNiBQTQ0K VG86IE1PUlRPTiwgQUxGUkVEIEMgKEFMKQ0KQ2M6IGlwcG1AaWV0Zi5vcmc8bWFpbHRvOmlwcG1A aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1D b250cm9sIGFuZCByZWxhdGlvbnNoaXAgd2l0aCBPV0FNUC1UZXN0DQoNCkhpIEFsLA0KdGhlbiwg aW4gbXkgb3BpbmlvbiwgdGhlcmUncyBjZXJ0YWluIGFtYmlndWl0eSBpbiB0aGUgdGV4dCBvZiBS RkMgNDY1NiBhbmQgaW4gUkZDIDUzNTcgYXMgd2VsbCBiZWNhdXNlIG9mIHRoZSBmb2xsb3dpbmcg c3RhdGVtZW50IGluIHRoZSB2ZXJ5IGZpcnN0IHNlbnRlbmNlIG9mIHNlY3Rpb24gMS4xIFJGQyA1 MzU3Og0KDQogICBTaW1pbGFyIHRvIE9XQU1QIFtSRkM0NjU2PGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM0 NjU2JmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtUSWx0VnlEMW9M NzJjQncmbT1HWU15MV9zcWY5bWo2UzBaSDNCOHZObXFlMERoam83ZGU2MVFiMFJfUEVrJnM9eFNr ZkZXNWpqNllQYnFwY2ZuQWxhaHJvRzdEWGRJMHhmaUZBU1dZcFF6VSZlPT5dLCBUV0FNUCBjb25z aXN0cyBvZiB0d28gaW50ZXItcmVsYXRlZA0KDQogICBwcm90b2NvbHM6IFRXQU1QLUNvbnRyb2wg YW5kIFRXQU1QLVRlc3QuICBUaGUgcmVsYXRpb25zaGlwIG9mIHRoZXNlDQoNCiAgIHByb3RvY29s cyBpcyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMS4xPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1MzU3LTIz c2VjdGlvbi0yRDEuMSZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThr VElsdFZ5RDFvTDcyY0J3Jm09R1lNeTFfc3FmOW1qNlMwWkgzQjh2Tm1xZTBEaGpvN2RlNjFRYjBS X1BFayZzPUxsMGg1WDRvU3dYWGw0R19GWTJjUlMtRXVRdE9sVzdVQmllWnV1VVZHbm8mZT0+IG9m IE9XQU1QIFtSRkM0NjU2PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM0NjU2JmQ9RHdNRmFRJmM9TEZZWi1v OV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtUSWx0VnlEMW9MNzJjQncmbT1HWU15MV9zcWY5bWo2 UzBaSDNCOHZObXFlMERoam83ZGU2MVFiMFJfUEVrJnM9eFNrZkZXNWpqNllQYnFwY2ZuQWxhaHJv RzdEWGRJMHhmaUZBU1dZcFF6VSZlPT5dLg0KDQoNCg0KUmVnYXJkcywNCg0KR3JlZw0KDQpPbiBN b24sIE1hciAyNywgMjAxNyBhdCAxMjoyNCBQTSwgTU9SVE9OLCBBTEZSRUQgQyAoQUwpIDxhY21v cnRvbkBhdHQuY29tPG1haWx0bzphY21vcnRvbkBhdHQuY29tPj4gd3JvdGU6DQpHcmVnLA0KDQpJ ZiB3ZSBoYWQgbWVhbnQgUkZDIDIxMTkg4oCcTUFZ4oCdIG9yIOKAnE9QVElPTkFM4oCdICh0aGUg dGVybQ0KeW91IHVzZWQgdG9kYXkgd2hlbiBwcmVzZW50aW5nKSB3ZSB3b3VsZCBoYXZlIHVzZWQg dGhlDQpSRkMgMjExOSB0ZXJtIGluIHRoZSB0ZXh0Lg0KDQpUaGVyZSBhcmUgcGxlbnR5IG9mIG90 aGVyIGV4YW1wbGVzIHdoZXJlIGJvdGggQ29udHJvbA0KYW5kIFRlc3QgcHJvdG9jb2xzIGFyZSB0 YWtlbiBhcyDigJx0aGUgZnVsbCBUV0FNUOKAnS4NCg0KQWwNCg0KDQpGcm9tOiBpcHBtIFttYWls dG86aXBwbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppcHBtLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgR3JlZyBNaXJza3kNClNlbnQ6IE1vbmRheSwgTWFyY2ggMjcsIDIwMTcgMTI6 MjkgUE0NClRvOiBpcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KU3ViamVjdDog W2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250cm9sIGFuZCByZWxhdGlvbnNoaXAg d2l0aCBPV0FNUC1UZXN0DQoNCkRlYXIgQWxsLA0KdGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gc2Vj dGlvbiAxLjEgb2YgUkZDIDQ2NTYgc3RhdGVzIHRoZSBmb2xsb3dpbmc6DQoNCiAgIEFsdGhvdWdo IE9XQU1QLVRlc3QgbWF5IGJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBhIGNvbnRyb2wNCg0K ICAgcHJvdG9jb2wgb3RoZXIgdGhhbiBPV0FNUC1Db250cm9sLCB0aGUgYXV0aG9ycyBoYXZlIGRl bGliZXJhdGVseQ0KDQogICBjaG9zZW4gdG8gaW5jbHVkZSBib3RoIHByb3RvY29scyBpbiB0aGUg c2FtZSBSRkMgdG8gZW5jb3VyYWdlIHRoZQ0KDQogICBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95 bWVudCBvZiBPV0FNUC1Db250cm9sIGFzIGEgY29tbW9uDQoNCiAgIGRlbm9taW5hdG9yIGNvbnRy b2wgcHJvdG9jb2wgZm9yIG9uZS13YXkgYWN0aXZlIG1lYXN1cmVtZW50cy4NCg0KDQoNCkkgaW50 ZXJwcmV0ICJtYXkgYmUgdXNlZCIgYXMgTUFZIHBlciBSRkMgMjExOS4gUGxlYXNlIGxldCBtZSBr bm93IGlmIHRoaXMgc2hvdWxkIG5vdCBiZSB0aGUgY2FzZS4NCg0KDQoNClJlZ2FyZHMsDQoNCkdy ZWcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlw cG0gbWFpbGluZyBsaXN0DQppcHBtQGlldGYub3JnPG1haWx0bzppcHBtQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9faXBwbSZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThr VElsdFZ5RDFvTDcyY0J3Jm09OHJ6RXFYSjl1Rlp2aDN1T0E1eUg0U0F5OGJidGlJV1dra0M2RTZ1 OUd4RSZzPVpNdFJ0UWY3X3VFdkJXVEk4RkhfeXh6bi1ITzFXaEt6emYwOG44OWtxeHMmZT0+DQoN Ck1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBsaXN0DQppcHBtQGlldGYub3JnPG1h aWx0bzppcHBtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHBtPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faXBwbSZkPUR3TUZhUSZjPUxGWVotbzlf SFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3Jm09OHJ6RXFYSjl1Rlp2aDN1 T0E1eUg0U0F5OGJidGlJV1dra0M2RTZ1OUd4RSZzPVpNdFJ0UWY3X3VFdkJXVEk4RkhfeXh6bi1I TzFXaEt6emYwOG44OWtxeHMmZT0+DQoNCg0K --_000_4D7F4AD313D3FC43A053B309F97543CF25F3BAF0njmtexg5researc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4ubTMyMjM2Njk4MDQ2MzA0NzU4 OTltMzE1NTU1NzczMzMwOTQ1NDUzN2FwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUt bmFtZTptXzMyMjM2Njk4MDQ2MzA0NzU4OTltMzE1NTU1NzczMzMwOTQ1NDUzN2FwcGxlLWNvbnZl cnRlZC1zcGFjZTt9DQpzcGFuLm0zMjIzNjY5ODA0NjMwNDc1ODk5aG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOm1fMzIyMzY2OTgwNDYzMDQ3NTg5OWhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PknigJltIHNvcnJ5IFJvbmksIGJ1dCB0aGF04oCZcyBleGFjdGx5IHdoYXQgdGhpcyBwaHJhc2Us PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPuKAnC4uLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmFuIGluY3Jl bWVudGFsIHBhdGggdG8gYWRvcHRpbmcgVFdBTVDigKbigJ0NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7bWVhbnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPnN1Z2dlc3RpbmcgYSBtdWx0aS1zdGVwIHBy b2Nlc3MgdG8gYWNoaWV2ZSBhIGZ1bGwgVFdBTVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+aW1wbGVtZW50YXRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgc2VudGVuY2UgaW4gdGhlIGJvZHkgc2V0cyB0aGUg Y29udGV4dCBmb3IgQXBwZW5kaXggSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SXQgc2F5cyB0aGUgQXBwZW5kaXggZGVz Y3JpYmVzIGJ1aWxkaW5nIFRXQU1QLVRlc3QgKjxiPmZpcnN0PC9iPiouPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNsZWFy bHksIFRXQU1QLVRlc3QgaXMgbm90IHRoZSBmaW5hbCBzdGVwITxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+QWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9uIEV2ZW4gW21haWx0bzpyb24uZXZl bi50bHZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMjcsIDIw MTcgNjo1NCBQTTxicj4NCjxiPlRvOjwvYj4gTU9SVE9OLCBBTEZSRUQgQyAoQUwpPGJyPg0KPGI+ Q2M6PC9iPiBNYWhlc2ggSmV0aGFuYW5kYW5pOyBpcHBtQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbaXBwbV0gUkZDIDQ2NTYgb24gdXNlIG9mIE9XQU1QLUNvbnRyb2wgYW5kIHJl bGF0aW9uc2hpcCB3aXRoIE9XQU1QLVRlc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIGxhc3QgcGFydCBvZiB5b3VyIHJlc3BvbnNlICZuYnNwOyZxdW90 OzxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4gdGhlbiBpbXBsZW1lbnRpbmcgdGhlIHJlc3Qgb2Yg VFdBTVAgKFRXQU1QLUNvbnRyb2wpLiZxdW90OyBpcyBub3QgdGhlcmUuIFRoaXMgaXMgd2h5IEkg c2FpZCB0aGF0IGl0IGRvZXMgbm90IHNheSB0aGF0IHlvdSBTSE9VTEQgaW1wbGVtZW50DQogdGhl IGNvbnRyb2wgcHJvdG9jb2wsIHlvdSBjYW4gc3RvcCBhZnRlciBpbXBsbWVudGluZyB0aGUgdGVz dCBwcm90b2NvbC48L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlJvbmk8L3NwYW4+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBNb24sIE1hciAyNywgMjAxNyBhdCA1OjM5IFBNLCBNT1JUT04sIEFMRlJFRCBDIChBTCkgJmx0 OzxhIGhyZWY9Im1haWx0bzphY21vcnRvbkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWNtb3J0 b25AYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5Sb25pLCBpbi1saW5l Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9uIEV2ZW4gW21haWx0bzo8YSBocmVmPSJt YWlsdG86cm9uLmV2ZW4udGx2QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbi5ldmVuLnRs dkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMjcsIDIw MTcgNTo1NCBQTTxicj4NCjxiPlRvOjwvYj4gTWFoZXNoIEpldGhhbmFuZGFuaTxicj4NCjxiPkNj OjwvYj4gTU9SVE9OLCBBTEZSRUQgQyAoQUwpOyA8YSBocmVmPSJtYWlsdG86aXBwbUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaXBwbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtpcHBtXSBSRkMgNDY1NiBvbiB1c2Ugb2YgT1dBTVAtQ29udHJvbCBhbmQgcmVsYXRp b25zaGlwIHdpdGggT1dBTVAtVGVzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JIHJlYWQgYm90aCBSRkM1MzU3IGFuZCBSRkMgNDY1NiBhbmQgZXZl biB0aG91Z2ggdGhleSBzYXkgdGhhdCBUV0FNUCBjb25zaXN0IG9mIHR3byBwcm90b2NvbCBpdCBu ZXZlciBzYXlzIHRoYXQgJm5ic3A7Ym90aCBNVVNUIGJlIHVzZWQgYW55d2hlcmUgaW4gdGhlIGRv Y3VtZW50LiBUaGUgZG9jdW1lbnQgZG9lcyBub3QNCiBoYXZlIGEgbG90IG9mIG5vcm1hdGl2ZSB0 ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+U2VjdGlvbiA1IG9mIFJGQzUzNTcgaXMgYW4gZXhhbXBsZSBhbmQgbm90IGEgcmVxdWly ZW1lbnQgYW5kIGV2ZW4gdGhlIHRleHQgdGhhdCB3YXMgbWVudGlvbmVkIGluIHRoZSBJUFBNIHNl c3Npb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZxdW90OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1MzU3LTIzYXBwZW5kaXgt MkRJJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPU9mc1N1 OGtUSWx0VnlEMW9MNzJjQncmYW1wO209OHJ6RXFYSjl1Rlp2aDN1T0E1eUg0U0F5OGJidGlJV1dr a0M2RTZ1OUd4RSZhbXA7cz1odXpTVHppQ09hM2hjWTJvX0MwN0pxWm5XTE0tT2xVdlJzV2p5OXZF WnZ3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5BcHBlbmRpeA0KIEk8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj4gcHJvdmlkZXMgYW4gZXhhbXBsZSBmb3IgcHVyZWx5IGluZm9ybWF0aW9uYWwg cHVycG9zZXMuIEl0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN1Z2dlc3RzIGFuIGluY3JlbWVudGFsIHBh dGggdG8gYWRvcHRpbmcgVFdBTVAsIGJ5IGltcGxlbWVudGluZyB0aGU8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVFdB TVAtVGVzdCBwcm90b2NvbCBmaXJzdC4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Eb2VzIG5vdCBzYXkgdGhhdCB1c2lu ZyBUV0FNUC1UZXN0IHdpdGhvdXQgdGhlIGNvbnRyb2wgcHJvdG9jb2wgU0hPVUxEIE5PVCBiZSB1 c2VkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+W0FDTV0gPC9zcGFuPjwvaT48L2I+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPk9mIGNvdXJzZSBpdCBkb2VzbuKAmXQhIEl0IHNheXMgQXBwZW5kaXggSSBkZXNjcmliZXMg YSA8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj50aGUgZmlyc3Qgc3RlcCBvZiBvbmUgcHJvY2VzcyBv ZiBzdGFuZGFyZHMtdHJhY2sgVFdBTVAgPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+aW1wbGVtZW50 YXRpb24sIGJ5IHN0YXJ0aW5nIHdpdGggVFdBTVAtbGlnaHQsIHRoZW4gPC9zcGFuPjwvYj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjpibGFjayI+aW1wbGVtZW50aW5nIHRoZSByZXN0IG9mIFRXQU1QIChUV0FNUC1Db250cm9sKS48 L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5BbDwvc3Bhbj48L2k+PC9iPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjwvaT48L2I+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5Sb25pIEV2ZW48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IE1vbiwgTWFyIDI3LCAyMDE3IGF0IDQ6MjAgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgJmx0Ozxh IGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1q ZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5HcmVnLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCB0aGUgcGFydCB0aGF0IHlvdSBmb3Jnb3QgdG8g cXVvdGUgdGhhdCBmb2xsb3dlZCBpbiBTZWN0aW9uIDEuMSBpczo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1h bCI+VFdBTVAtPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IENvbnRyb2wgaXMg dXNlZCB0byBpbml0aWF0ZSwgc3RhcnQsIGFuZCBzdG9wIHRlc3Qgc2Vzc2lvbnMsIHdoZXJlYXM8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVFdBTVAtVGVzdCBpcyB1c2VkIHRv IGV4Y2hhbmdlIHRlc3QgcGFja2V0cyBiZXR3ZWVuIHR3byBUV0FNUDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBlbnRpdGllcy48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJlIGlzIGNsZWFybHkgYSBwcmVjZWRlbmNlIGZv ciBUV0FNUC1Db250cm9sIHRvIGJlIGEgZW50aXR5IGJ5IGl0c2VsZiBhbmQgdmVyeSBtdWNoIHBh cnQgb2YgdGhlIFRXQU1QIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgdGhpcyBpcyB0aGlzIHJhdGlvbmFsIGZvciB5 b3VyIGNvbW1lbnRzIG9uIHRoZSBZQU5HIG1vZGVsLCB0aGVuIEkgZmFpbCB0byBzZWUgUkZDIDUz NTcgYmFja2luZyB5b3VyIGNsYWltIHRoYXQgVFdBTVAtY29udHJvbCBpcyBvcHRpb25hbC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNo ZWVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTWFyIDI3LCAyMDE3LCBhdCA0OjA4IFBN LCBNT1JUT04sIEFMRlJFRCBDIChBTCkgJmx0OzxhIGhyZWY9Im1haWx0bzphY21vcnRvbkBhdHQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+YWNtb3J0b25AYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+R3JlZyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BbGwgYW1iaWd1aXR5IGZhbGxzIGF3YXkgaW4gdGhlIGNvbnRl eHQgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij50aGUgY29tcGxldGUgVFdBTVAgZG9jdW1lbnQsIHdoaWNoIHNh eXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoaXMg ZXhhbXBsZSBlbGltaW5hdGVzIHRoZSBuZWVkIGZvciB0aGUgVFdBTVAtQ29udHJvbCBwcm90b2Nv bCwgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGFzc3VtZXMgdGhhdCB0aGUgU2Vzc2lv bi1SZWZsZWN0b3IgaXMgY29uZmlndXJlZCBhbmQgY29tbXVuaWNhdGVzIGl0czwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBjb25maWd1cmF0aW9uIHdpdGggdGhlIFNlcnZlciB0aHJvdWdoIG5v bi1zdGFuZGFyZCBtZWFucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUg ZXhhbXBsZSByZWZlcnJlZCB0byBhYm92ZSBpcyBub3QgVFdBTVA7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aXQg aXMgdGhlIG9wdGlvbiB5b3UgZGVzY3JpYmUsIGJ1dCBpdCBpczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmNhbGxl ZCAqPGI+VFdBTVAgbGlnaHQ8L2I+Ki48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5BbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJtMzIyMzY2OTgwNDYzMDQ3NTg5OW0z MTU1NTU3NzMzMzA5NDU0NTM3YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+aXBwbQ0KIFs8YSBocmVmPSJtYWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9Im0z MjIzNjY5ODA0NjMwNDc1ODk5bTMxNTU1NTc3MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0ibTMyMjM2Njk4MDQ2 MzA0NzU4OTltMzE1NTU1NzczMzMwOTQ1NDUzN2FwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5HcmVnDQogTWlyc2t5PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9Im0z MjIzNjY5ODA0NjMwNDc1ODk5bTMxNTU1NTc3MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIE1hcmNoIDI3LCAyMDE3IDM6MTYgUE08YnI+DQo8Yj5U bzo8L2I+PHNwYW4gY2xhc3M9Im0zMjIzNjY5ODA0NjMwNDc1ODk5bTMxNTU1NTc3MzMzMDk0NTQ1 MzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NT1JUT04sIEFMRlJFRCBDIChB TCk8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9Im0zMjIzNjY5ODA0NjMwNDc1ODk5bTMxNTU1 NTc3MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86aXBwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwcG1AaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9Im0zMjIzNjY5ODA0NjMwNDc1ODk5bTMx NTU1NTc3MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTog W2lwcG1dIFJGQyA0NjU2IG9uIHVzZSBvZiBPV0FNUC1Db250cm9sIGFuZCByZWxhdGlvbnNoaXAg d2l0aCBPV0FNUC1UZXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBBbCw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PnRoZW4sIGluIG15IG9waW5pb24sIHRoZXJlJ3MgY2VydGFpbiBhbWJpZ3VpdHkgaW4gdGhlIHRl eHQgb2YgUkZDIDQ2NTYgYW5kIGluIFJGQyA1MzU3IGFzIHdlbGwgYmVjYXVzZSBvZiB0aGUgZm9s bG93aW5nIHN0YXRlbWVudCBpbiB0aGUgdmVyeSBmaXJzdCBzZW50ZW5jZSBvZiBzZWN0aW9uIDEu MSBSRkMgNTM1Nzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT4m bmJzcDsmbmJzcDsgU2ltaWxhciB0byBPV0FNUCBbPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3Jm YzQ2NTYmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9T2Zz U3U4a1RJbHRWeUQxb0w3MmNCdyZhbXA7bT1HWU15MV9zcWY5bWo2UzBaSDNCOHZObXFlMERoam83 ZGU2MVFiMFJfUEVrJmFtcDtzPXhTa2ZGVzVqajZZUGJxcGNmbkFsYWhyb0c3RFhkSTB4ZmlGQVNX WXBRelUmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayIgdGl0bGU9IiZxdW90O0EgT25lLXdheSBBY3Rp dmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgKE9XQU1QKSZxdW90OyI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+UkZDNDY1Njwvc3Bhbj48L2E+XSwgVFdBTVAgY29uc2lzdHMgb2YgdHdvIGludGVy LXJlbGF0ZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcHJvdG9jb2xzOiBU V0FNUC1Db250cm9sIGFuZCBUV0FNUC1UZXN0LiZuYnNwOyBUaGUgcmVsYXRpb25zaGlwIG9mIHRo ZXNlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHByb3RvY29scyBpcyBhcyBk ZWZpbmVkIGluIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1MzU3LTIzc2VjdGlvbi0yRDEu MSZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1PZnNTdThr VElsdFZ5RDFvTDcyY0J3JmFtcDttPUdZTXkxX3NxZjltajZTMFpIM0I4dk5tcWUwRGhqbzdkZTYx UWIwUl9QRWsmYW1wO3M9TGwwaDVYNG9Td1hYbDRHX0ZZMmNSUy1FdVF0T2xXN1VCaWVadXVVVkdu byZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5TZWN0 aW9uIDEuMTwvc3Bhbj48L2E+IG9mIE9XQU1QIFs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZj NDY1NiZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1PZnNT dThrVElsdFZ5RDFvTDcyY0J3JmFtcDttPUdZTXkxX3NxZjltajZTMFpIM0I4dk5tcWUwRGhqbzdk ZTYxUWIwUl9QRWsmYW1wO3M9eFNrZkZXNWpqNllQYnFwY2ZuQWxhaHJvRzdEWGRJMHhmaUZBU1dZ cFF6VSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7QSBPbmUtd2F5IEFjdGl2 ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoT1dBTVApJnF1b3Q7Ij48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5SRkM0NjU2PC9zcGFuPjwvYT5dLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PkdyZWc8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgTWFyIDI3LCAyMDE3IGF0IDEy OjI0IFBNLCBNT1JUT04sIEFMRlJFRCBDIChBTCkgJmx0OzxhIGhyZWY9Im1haWx0bzphY21vcnRv bkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWNt b3J0b25AYXR0LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ R3JlZyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB3ZSBoYWQgbWVhbnQg UkZDIDIxMTkg4oCcTUFZ4oCdIG9yIOKAnE9QVElPTkFM4oCdICh0aGUgdGVybTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnlvdSB1c2VkIHRvZGF5IHdoZW4gcHJlc2VudGluZykgd2Ugd291bGQgaGF2ZSB1c2VkIHRo ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPlJGQyAyMTE5IHRlcm0gaW4gdGhlIHRleHQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlcmUgYXJlIHBsZW50eSBvZiBvdGhlciBleGFtcGxlcyB3 aGVyZSBib3RoIENvbnRyb2w8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hbmQgVGVzdCBwcm90b2NvbHMgYXJlIHRh a2VuIGFzIOKAnHRoZSBmdWxsIFRXQU1Q4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPkFsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xh c3M9Im0zMjIzNjY5ODA0NjMwNDc1ODk5bTMxNTU1NTc3MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5pcHBtDQogW21haWx0bzo8YSBocmVmPSJtYWls dG86aXBwbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aXBwbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9 Im0zMjIzNjY5ODA0NjMwNDc1ODk5bTMxNTU1NTc3MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0ibTMyMjM2Njk4 MDQ2MzA0NzU4OTltMzE1NTU1NzczMzMwOTQ1NDUzN2FwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvYj5HcmVnDQogTWlyc2t5PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9 Im0zMjIzNjY5ODA0NjMwNDc1ODk5bTMxNTU1NTc3MzMzMDk0NTQ1MzdhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIE1hcmNoIDI3LCAyMDE3IDEyOjI5IFBNPGJyPg0K PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJtMzIyMzY2OTgwNDYzMDQ3NTg5OW0zMTU1NTU3NzMzMzA5 NDU0NTM3YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OmlwcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5pcHBtQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFz cz0ibTMyMjM2Njk4MDQ2MzA0NzU4OTltMzE1NTU1NzczMzMwOTQ1NDUzN2FwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltpcHBtXSBSRkMgNDY1NiBvbiB1c2Ugb2YgT1dBTVAtQ29u dHJvbCBhbmQgcmVsYXRpb25zaGlwIHdpdGggT1dBTVAtVGVzdDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EZWFyIEFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoZSBzZWNvbmQgcGFyYWdy YXBoIGluIHNlY3Rpb24gMS4xIG9mIFJGQyA0NjU2IHN0YXRlcyB0aGUgZm9sbG93aW5nOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyBBbHRo b3VnaCBPV0FNUC1UZXN0IG1heSBiZSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggYSBjb250cm9s PG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwO3Byb3RvY29sIG90aGVyIHRoYW4g T1dBTVAtQ29udHJvbCwgdGhlIGF1dGhvcnMgaGF2ZSBkZWxpYmVyYXRlbHk8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY2hvc2VuIHRvIGluY2x1ZGUgYm90aCBwcm90b2NvbHMg aW4gdGhlIHNhbWUgUkZDIHRvIGVuY291cmFnZSB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgb2YgT1dBTVAtQ29udHJv bCBhcyBhIGNvbW1vbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBkZW5vbWlu YXRvciBjb250cm9sIHByb3RvY29sIGZvciBvbmUtd2F5IGFjdGl2ZSBtZWFzdXJlbWVudHMuPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SSBpbnRl cnByZXQgJnF1b3Q7bWF5IGJlIHVzZWQmcXVvdDsgYXMgTUFZIHBlciBSRkMgMjExOS4gUGxlYXNl IGxldCBtZSBrbm93IGlmIHRoaXMgc2hvdWxkIG5vdCBiZSB0aGUgY2FzZS48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPkdyZWc8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCmlwcG0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOmlwcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pcHBtQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faXBwbSZhbXA7ZD1Ed01GYVEm YW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1PZnNTdThrVElsdFZ5RDFvTDcyY0J3 JmFtcDttPThyekVxWEo5dUZadmgzdU9BNXlINFNBeThiYnRpSVdXa2tDNkU2dTlHeEUmYW1wO3M9 Wk10UnRRZjdfdUV2QldUSThGSF95eHpuLUhPMVdoS3p6ZjA4bjg5a3F4cyZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG08L2E+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gY2xhc3M9Im0zMjIzNjY5ODA0NjMwNDc1ODk5aG9l bnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+TWFoZXNoIEpldGhhbmFuZGFuaTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiM4ODg4ODgiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpp cHBtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+aXBwbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lwcG0mYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3Zq SWcmYW1wO3I9T2ZzU3U4a1RJbHRWeUQxb0w3MmNCdyZhbXA7bT04cnpFcVhKOXVGWnZoM3VPQTV5 SDRTQXk4YmJ0aUlXV2trQzZFNnU5R3hFJmFtcDtzPVpNdFJ0UWY3X3VFdkJXVEk4RkhfeXh6bi1I TzFXaEt6emYwOG44OWtxeHMmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHBtPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_4D7F4AD313D3FC43A053B309F97543CF25F3BAF0njmtexg5researc_-- From nobody Mon Mar 27 16:56:11 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3236312966F for ; Mon, 27 Mar 2017 16:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.991 X-Spam-Level: X-Spam-Status: No, score=0.991 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 H4L0v9MXG_0B for ; Mon, 27 Mar 2017 16:56:06 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6331294BF for ; Mon, 27 Mar 2017 16:56:06 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id 102so31697016otv.0 for ; Mon, 27 Mar 2017 16:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hF1B/Rxc+RJPN0WegYd6ZiBHsUQsf8FwnC7rY4+kEDQ=; b=ROrEnIxjsYC7IGsfIUDy7X6NW4uNth1alojGJDy66yu+S+6QUJiEz0DA0wuGsB3spI ge5RUBTRoCgI7pX54dx6NM6EnE/Pm6fBVpuasmyaQ2VpSXFW3q/nv7GyGUXCDaNYw8Ou WLAEWrcDEvnkONtJ/rlzAoMUr97M1rca4QtW38e/WEbDfwRf2ofwfO3zlJ8MES9hANaB qvdtN0P+Riz9iOnQhocdjsiJzLQ7TYcHOj7slwjhzLZxky+KMRulFYw1iWxKVqE6Q6CH WfgNP64TzHX/c0EF58VzOR9Wt+NuOKOVolS1ygcWI6M//LFsnluKVlvcLw+8JK+w67Ke ZXdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hF1B/Rxc+RJPN0WegYd6ZiBHsUQsf8FwnC7rY4+kEDQ=; b=LWyflfkTiBbLR5qsOTy5ZE0oShBRnUvaIDngzYXIvtuJbSL0LS/2ty+CDW3IJVUM0x VqfdXbNgZm48TGPVYgBA0cHt2Y9UMn1edTgtML9FkRyy17aAKs5X0yGtVIaLWU/nplkz ibWYaNDgH8AWS9PjegI7ebYAdV2ycAhZnYHMNLIOZT43Hxu1JVHkzKqByrKEx9CiYI8b BYIobEsW91eq4RWov/3GOQtOWZ3ZRPQCl5HIT3Ky8hWaxHQpIfUG8o7frvVAWHQweDnO U1NWsdbWjoAJ3CbPZJRPpBvN2wQxuo3Pr34ljgRPRn0QoxNaqLuhfp5P1GK8HFO2sEBn 5vpQ== X-Gm-Message-State: AFeK/H10q5w90oiXi9JaD42IL4BKJdrpHZCfpvQc7BpVEdRbOhllo65wfq67ulcprWZtIRAEu+wg+w6b08v7AQ== X-Received: by 10.157.1.201 with SMTP id e67mr5832687ote.40.1490658965456; Mon, 27 Mar 2017 16:56:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Mon, 27 Mar 2017 16:56:04 -0700 (PDT) In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F3BAF0@njmtexg5.research.att.com> References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAAD@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAF0@njmtexg5.research.att.com> From: Greg Mirsky Date: Mon, 27 Mar 2017 18:56:04 -0500 Message-ID: To: "MORTON, ALFRED C (AL)" Cc: Ron Even , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c03c5a61e0f01054bbf16af Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 23:56:09 -0000 --94eb2c03c5a61e0f01054bbf16af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear All, in the first paragraph of already mentioned section 1.1 of RFC 4656 characterizes OWAMP-Control and OWAMP-Test as two inter-related but not inter-dependent protocols. I believe that the same is true for TWAMP-Control and TWAMP-Test. Control protocols may be used to initiate, start and stop test sessions but the OWAMP/TWAMP-control protocol is not the only way to achieve that in the same way as co-location of Control-Client and Session-Sender, on one side, and Server and Session-Reflector, on another side, is not the only way these functions may be instantiated in participating nodes. In fact, RFC 5357 does envision separation, though physical, between TWAMP-Control and TWAMP-Test in the following figure: +----------------+ +-------------------+ | Session-Sender |<-TWAMP-Test-->| Session-Reflector | +----------------+ +-------------------+ ^ ^ | | | | | | | +----------------+<----------------+ | | Server | | +----------------+ | ^ | | | TWAMP-Control | | v v +----------------+ | Control-Client | +----------------+ Regards, Greg On Mon, Mar 27, 2017 at 6:07 PM, MORTON, ALFRED C (AL) wrote: > I=E2=80=99m sorry Roni, but that=E2=80=99s exactly what this phrase, > > =E2=80=9C...an incremental path to adopting TWAMP=E2=80=A6=E2=80=9D mean= s, > > suggesting a multi-step process to achieve a full TWAMP > > implementation. > > > > The sentence in the body sets the context for Appendix I. > > It says the Appendix describes building TWAMP-Test **first**. > > Clearly, TWAMP-Test is not the final step! > > > > Al > > > > *From:* Ron Even [mailto:ron.even.tlv@gmail.com] > *Sent:* Monday, March 27, 2017 6:54 PM > *To:* MORTON, ALFRED C (AL) > *Cc:* Mahesh Jethanandani; ippm@ietf.org > > *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship > with OWAMP-Test > > > > Al, > > The last part of your response "* then implementing the rest of TWAMP > (TWAMP-Control)." is not there. This is why I said that it does not say > that you SHOULD implement the control protocol, you can stop after > implmenting the test protocol.* > > *Roni* > > > > On Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALFRED C (AL) > wrote: > > Roni, in-line: > > > > *From:* Ron Even [mailto:ron.even.tlv@gmail.com] > *Sent:* Monday, March 27, 2017 5:54 PM > *To:* Mahesh Jethanandani > *Cc:* MORTON, ALFRED C (AL); ippm@ietf.org > *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship > with OWAMP-Test > > > > Hi, > > I read both RFC5357 and RFC 4656 and even though they say that TWAMP > consist of two protocol it never says that both MUST be used anywhere in > the document. The document does not have a lot of normative text. > > > > Section 5 of RFC5357 is an example and not a requirement and even the tex= t > that was mentioned in the IPPM session > > > > "Appendix I > > provides an example for purely informational purposes. It > > suggests an incremental path to adopting TWAMP, by implementing the > > TWAMP-Test protocol first." > > > > Does not say that using TWAMP-Test without the control protocol SHOULD NO= T be used. > > *[ACM] * > > *Of course it doesn=E2=80=99t! It says Appendix I describes a * > > *the first step of one process of standards-track TWAMP * > > *implementation, by starting with TWAMP-light, then * > > *implementing the rest of TWAMP (TWAMP-Control).* > > > > *Al* > > > > > > > > > > Roni Even > > > > > > > > > > > > On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > > Greg, > > > > And the part that you forgot to quote that followed in Section 1.1 is: > > > > TWAMP- > > Control is used to initiate, start, and stop test sessions, whereas > > TWAMP-Test is used to exchange test packets between two TWAMP > > entities. > > > > There is clearly a precedence for TWAMP-Control to be a entity by itself > and very much part of the TWAMP protocol. > > > > If this is this rational for your comments on the YANG model, then I fail > to see RFC 5357 backing your claim that TWAMP-control is optional. > > > > Cheers. > > > > On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) > wrote: > > > > Greg, > > > > All ambiguity falls away in the context of > > the complete TWAMP document, which says: > > > > This example eliminates the need for the TWAMP-Control protocol, and > > assumes that the Session-Reflector is configured and communicates its > > configuration with the Server through non-standard means. > > > > The example referred to above is not TWAMP; > > it is the option you describe, but it is > > called **TWAMP light**. > > > > Al > > > > *From:* ippm [mailto:ippm-bounces@ietf.org ] *On > Behalf Of *Greg Mirsky > *Sent:* Monday, March 27, 2017 3:16 PM > *To:* MORTON, ALFRED C (AL) > *Cc:* ippm@ietf.org > *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship > with OWAMP-Test > > > > Hi Al, > > then, in my opinion, there's certain ambiguity in the text of RFC 4656 an= d > in RFC 5357 as well because of the following statement in the very first > sentence of section 1.1 RFC 5357: > > Similar to OWAMP [RFC4656 ], TWAMP consists = of two inter-related > > protocols: TWAMP-Control and TWAMP-Test. The relationship of these > > protocols is as defined in Section 1.1 of OWAMP [RFC4656 ]. > > > > Regards, > > Greg > > > > On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) > wrote: > > Greg, > > > > If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2=80= =9D (the term > > you used today when presenting) we would have used the > > RFC 2119 term in the text. > > > > There are plenty of other examples where both Control > > and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D. > > > > Al > > > > > > *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* Monday, March 27, 2017 12:29 PM > *To:* ippm@ietf.org > *Subject:* [ippm] RFC 4656 on use of OWAMP-Control and relationship with > OWAMP-Test > > > > Dear All, > > the second paragraph in section 1.1 of RFC 4656 states the following: > > Although OWAMP-Test may be used in conjunction with a control > > protocol other than OWAMP-Control, the authors have deliberately > > chosen to include both protocols in the same RFC to encourage the > > implementation and deployment of OWAMP-Control as a common > > denominator control protocol for one-way active measurements. > > > > I interpret "may be used" as MAY per RFC 2119. Please let me know if this= should not be the case. > > > > Regards, > > Greg > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > _______________________________________________ > 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 > > --94eb2c03c5a61e0f01054bbf16af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,
in the first paragraph of already mentioned = section 1.1 of RFC 4656 characterizes OWAMP-Control and OWAMP-Test as two i= nter-related but not inter-dependent protocols. I believe that the same is = true for TWAMP-Control and TWAMP-Test. Control protocols may be used to ini= tiate, start and stop test sessions but the OWAMP/TWAMP-control protocol is= not the only way to achieve that in the same way as co-location of Control= -Client and Session-Sender, on one side, and Server and Session-Reflector, = on another side, is not the only way these functions may be instantiated in= participating nodes. In fact, RFC 5357 does envision separation, though ph= ysical, between TWAMP-Control and TWAMP-Test in the following figure:
= 
         +----------------+         =
      +-------------------+
         | Session-Sender |<-TWAMP-Test-->| Session-Reflector |
         +----------------+               +-------------------+
           ^                                     ^
           |                                     |
           |                                     |
           |                                     |
           |  +----------------+<----------------+
           |  |     Server     |
           |  +----------------+
           |    ^
           |    |
           | TWAMP-Control
           |    |
           v    v
         +----------------+
         | Control-Client |
         +----------------+

Regards,
Greg

On Mon, Mar 27, 2017 at 6:07 PM, MORTON, ALFRED C (AL) <acmor= ton@att.com> wrote:

I=E2=80=99m sorry Roni, but that=E2=80=99s exa= ctly what this phrase,

=E2=80=9C...an incremental path to adopting TWAMP=E2=80=A6=E2=80=9D =C2=A0means,

suggesting a multi-step process to achieve a f= ull TWAMP

implementation.

=C2=A0

The sentence in the body sets the context for = Appendix I.

It says the Appendix describes building TWAMP-= Test *first*.

Clearly, TWAMP-Test is not the final step!<= /u>

=C2=A0

Al

=C2=A0

From: Ron Even= [mailto:ron.ev= en.tlv@gmail.com]
Sent: Monday, March 27, 2017 6:54 PM
To: MORTON, ALFRED C (AL)
Cc: Mahesh Jethanandani; ippm@ietf.org


Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationshi= p with OWAMP-Test

=C2=A0

Al,

The last part of your response =C2=A0"= then implementing the rest of TWAMP (TWAMP-Control)." is not there. T= his is why I said that it does not say that you SHOULD implement the control protocol, you can stop after implmenting the test protocol.

Roni

=C2=A0

On Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALFRED C (A= L) <acmorton@att.c= om> wrote:

Roni, in-line:

=C2=A0

From: Ron Even= [mailto:ron.ev= en.tlv@gmail.com]
Sent: Monday, March 27, 2017 5:54 PM
To: Mahesh Jethanandani
Cc: MORTON, ALFRED C (AL); ippm@ietf.org
Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationshi= p with OWAMP-Test

=C2=A0

Hi,

I read both RFC5357 and RFC 4656 and even though the= y say that TWAMP consist of two protocol it never says that =C2=A0both MUST= be used anywhere in the document. The document does not have a lot of normative text.

=C2=A0

Section 5 of RFC5357 is an example and not a require= ment and even the text that was mentioned in the IPPM session=

=C2=A0

"Appendix I provides an exam= ple for purely informational purposes. It

=C2=A0=C2=A0 suggests an incremental path =
to adopting TWAMP, by implementing the
=C2=A0=C2=A0 TWAMP-Test protocol first.&qu=
ot;
=C2=A0
Does not say that using TWAMP-Test without=
 the control protocol SHOULD NOT be used.
[ACM] 
Of course it doesn=E2=
=80=99t! It says Appendix I describes a 
the first step of one =
process of standards-track TWAMP 
implementation, by sta=
rting with TWAMP-light, then 
implementing the rest =
of TWAMP (TWAMP-Control).
=C2=A0
Al
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Roni Even
=C2=A0
=C2=A0
=C2=A0
=C2=A0

=C2=A0

On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani= <mjethanan= dani@gmail.com> wrote:

Greg,

=C2=A0

And the part that you forgot to quote that followed = in Section 1.1 is:

=C2=A0

TWAMP-
=C2=A0=C2=A0 Control is used to initiate, start, and stop test session=
s, whereas
=C2=A0=C2=A0 TWAMP-Test is used to exchange test packets between two T=
WAMP
=C2=A0=C2=A0 entities.

=C2=A0

There is clearly a precedence for TWAMP-Control to b= e a entity by itself and very much part of the TWAMP protocol.

=C2=A0

If this is this rational for your comments on the YA= NG model, then I fail to see RFC 5357 backing your claim that TWAMP-control= is optional.

=C2=A0

Cheers.

=C2=A0

On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) &= lt;acmorton@att.com> wrote:

=C2=A0

Greg,

=C2=A0

All ambiguity falls away in the context of

the complete TWAMP document, which says:<= /u>

=C2=A0

=C2=A0=C2=A0 This example eliminates the need for the TWAM= P-Control protocol, and

=C2=A0=C2=A0 assumes that the Session-Reflector is configu= red and communicates its

=C2=A0=C2=A0 configuration with the Server through non-sta= ndard means.

=C2=A0

The example referred to above is not TWAMP;<= u>

it is the option you describe, but it is<= /u>

called *TWAMP light*.

=C2=A0

Al

=C2=A0

=C2=A0

Hi Al,

then, in my opinion, there's certain ambiguity i= n the text of RFC 4656 and in RFC 5357 as well because of the following sta= tement in the very first sentence of section 1.1 RFC 5357: 

=C2=A0=C2=A0 Similar to OWAMP [RFC4656=
], TWAMP consists of two inter-related
=C2=A0=C2=A0 protocols: TWAMP-Control and TWAMP-Test.=C2=A0 The relati=
onship of these
=C2=A0=C2=A0 protocols is as defined in Section 1.1 of OWAMP [RFC4656]. 
=C2=A0
Regards,
Greg

=C2=A0

On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (= AL) <acmorton@att.com> wrote:

Greg,

=C2=A0

If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80= =9COPTIONAL=E2=80=9D (the term

you used today when presenting) we would have used the

RFC 2119 term in the text.

=C2=A0

There are plenty of other examples where both Control

and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2= =80=9D.

=C2=A0

Al

=C2=A0

=C2=A0

From:=C2=A0ippm [mailto:ippm-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0<= /b>Greg Mirsky
Sent:=C2=A0Monday, March 27, 2017 12:= 29 PM
To:=C2=A0ippm@ietf.org
Subject:=C2=A0[ippm] RFC 4656 on use = of OWAMP-Control and relationship with OWAMP-Test

=C2=A0

Dear All,

the second paragraph in section 1.1 of RFC 4656 stat= es the following:

=C2=A0=C2=A0 Although OWAMP-Test may be used in conjunction with a con=
trol
 =C2=A0=C2=A0protocol other than OWAMP-Control, the authors have delib=
erately
=C2=A0=C2=A0 chosen to include both protocols in the same RFC to encou=
rage the
=C2=A0=C2=A0 implementation and deployment of OWAMP-Control as a commo=
n
=C2=A0=C2=A0 denominator control protocol for one-way active measureme=
nts.
=C2=A0
I interpret "may be used" as MAY per RFC 2119. Please let me=
 know if this should not be the case.
=C2=A0
Regards,
Greg

=C2=A0

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

=C2=A0

Mahesh Jethanandani

=C2=A0

=C2=A0

=C2=A0


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

=C2=A0

=C2=A0


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


--94eb2c03c5a61e0f01054bbf16af-- From nobody Mon Mar 27 23:55:33 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C883C1297D4 for ; Mon, 27 Mar 2017 23:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 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, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian-com.20150623.gappssmtp.com 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 IxtF52mbt_uu for ; Mon, 27 Mar 2017 23:55:27 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A68126C89 for ; Mon, 27 Mar 2017 23:55:27 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id f193so35110006oib.2 for ; Mon, 27 Mar 2017 23:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UzW+G4CXAaLLBQuVBzkdBC8CCEGHtP9XRsQ/0XU6B2Y=; b=XGa/9hykrU6IpWeena69sg2ub5+pHMiUGeSJ4NFxIFnQQgzsupE0pBsEF3KaHNKHIr 5zWmQn7LIQxB9HR45kgKa6coVkNk5FS3wIQU6TL7jGvi/b7gT4F4f5HsB+rAq9Y+mNZ1 eVghmRdV5+f/4Xn4mCKqEsQHbPexnlGAizpkMOoTwBFOxu8C1LXCmKRJSlejiO8aAvQT rbVWoREjJEQtkt8SM8Jw4X55Cw6rPe80Txz128lK0V14L4q48b+bo8Kn+/ct1dIjfJXC MPx+IsaAq25OwuYXHiCOVSzF3AbfetTRFi9nP4F3JiLcFkWACg7/pxFAhMOe3B8MrzeE IPzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UzW+G4CXAaLLBQuVBzkdBC8CCEGHtP9XRsQ/0XU6B2Y=; b=MqHT8icoFElWL5+KxehOThyhWmxDybXjPy8q7OebYSj5XL6oDpT7aC7gVJxTRAp3/W 6R5AxXQG6DHEiU+3tTE9OTI0VMxsq11fs2IdCCB51ni5WiN0YKbMezO0bKdJybpjLiKM pQnf1v9Fh5wZZfNOuJSt3dCexACaF2hj+xV+v3ft1oRSnaZzuvJp2wyNF+/7YXP9zyOB Mb4bYabKo5wLM3HVZ4jxbzzty1d0oncU4nkFHHxWRyCDcw9lxdkKDGwzXbVAlCYVj2Tf 6kvk2RaqE8+CFUwN4V88x6j0lZkLfiYs53j91g+f2NAO/N5TWLmZYaxsMb1jbUeUmIgU 7g9A== X-Gm-Message-State: AFeK/H07HilfWXAXoLldA101LMGgUWNvBMUGqA9mTyRQ4MCuq5EWKC6/YCR4szfqHnodt0HH/7zQQ1EZqSL4ZsMjvAOrFGRsomBBHnj6BZHwgIeBZxOfb2TOwsZJtPdyCXyI X-Received: by 10.202.89.3 with SMTP id n3mr14726293oib.26.1490684126637; Mon, 27 Mar 2017 23:55:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.174 with HTTP; Mon, 27 Mar 2017 23:55:26 -0700 (PDT) In-Reply-To: References: <4D7F4AD313D3FC43A053B309F97543CF25F3B699@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3B98A@njmtexg5.research.att.com> <2331844A-BD9C-4BE3-8928-83C8E3333D5F@gmail.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAAD@njmtexg5.research.att.com> <4D7F4AD313D3FC43A053B309F97543CF25F3BAF0@njmtexg5.research.att.com> From: Henrik Nydell Date: Tue, 28 Mar 2017 08:55:26 +0200 Message-ID: To: Greg Mirsky Cc: "MORTON, ALFRED C (AL)" , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a113d5008d75441054bc4f1eb Archived-At: Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 06:55:32 -0000 --001a113d5008d75441054bc4f1eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is also plenty of de-facto standardization on TWAMP-light in the field. As far as I know, these vendors support TWAMP-light in their Session-reflectors; Ericsson radios, Nokia radios (Except ALU who use Control), MRV OS9x, Accedian and probably several others. Adopting TWAMP can mean many things, depending on if you see it from the vendors perspective or the users. From a vendors perspective TWAMP-light is a path to adopting full TWAMP (with control) but how long this path is depends of course on the vendor roadmap, and they may end up never implementing the RFC version of TWAMP-control. >From a users perspective it may seem easier to start with TWAMP-light with fixed configuration of reflector ports to ease firewall configuration, then possibly adopting full TWAMP further down the line. I argue that the meaning with TWAMP is to obtain metrics (TWAMP-test), and thus the setup portion is a different function which may or may not use a standardized method. As things evolve it may prove more useful to implement a REST-type API or a NetConf API for the control of the session-reflector to easier interwork in ETSI-NFV type orchestrated environments. On Tue, Mar 28, 2017 at 1:56 AM, Greg Mirsky wrote: > Dear All, > in the first paragraph of already mentioned section 1.1 of RFC 4656 > characterizes OWAMP-Control and OWAMP-Test as two inter-related but not > inter-dependent protocols. I believe that the same is true for > TWAMP-Control and TWAMP-Test. Control protocols may be used to initiate, > start and stop test sessions but the OWAMP/TWAMP-control protocol is not > the only way to achieve that in the same way as co-location of > Control-Client and Session-Sender, on one side, and Server and > Session-Reflector, on another side, is not the only way these functions m= ay > be instantiated in participating nodes. In fact, RFC 5357 does envision > separation, though physical, between TWAMP-Control and TWAMP-Test in the > following figure: > > +----------------+ +-------------------+ > | Session-Sender |<-TWAMP-Test-->| Session-Reflector | > +----------------+ +-------------------+ > ^ ^ > | | > | | > | | > | +----------------+<----------------+ > | | Server | > | +----------------+ > | ^ > | | > | TWAMP-Control > | | > v v > +----------------+ > | Control-Client | > +----------------+ > > > Regards, > > Greg > > > On Mon, Mar 27, 2017 at 6:07 PM, MORTON, ALFRED C (AL) > wrote: > >> I=E2=80=99m sorry Roni, but that=E2=80=99s exactly what this phrase, >> >> =E2=80=9C...an incremental path to adopting TWAMP=E2=80=A6=E2=80=9D mea= ns, >> >> suggesting a multi-step process to achieve a full TWAMP >> >> implementation. >> >> >> >> The sentence in the body sets the context for Appendix I. >> >> It says the Appendix describes building TWAMP-Test **first**. >> >> Clearly, TWAMP-Test is not the final step! >> >> >> >> Al >> >> >> >> *From:* Ron Even [mailto:ron.even.tlv@gmail.com] >> *Sent:* Monday, March 27, 2017 6:54 PM >> *To:* MORTON, ALFRED C (AL) >> *Cc:* Mahesh Jethanandani; ippm@ietf.org >> >> *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship >> with OWAMP-Test >> >> >> >> Al, >> >> The last part of your response "* then implementing the rest of TWAMP >> (TWAMP-Control)." is not there. This is why I said that it does not say >> that you SHOULD implement the control protocol, you can stop after >> implmenting the test protocol.* >> >> *Roni* >> >> >> >> On Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALFRED C (AL) >> wrote: >> >> Roni, in-line: >> >> >> >> *From:* Ron Even [mailto:ron.even.tlv@gmail.com] >> *Sent:* Monday, March 27, 2017 5:54 PM >> *To:* Mahesh Jethanandani >> *Cc:* MORTON, ALFRED C (AL); ippm@ietf.org >> *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship >> with OWAMP-Test >> >> >> >> Hi, >> >> I read both RFC5357 and RFC 4656 and even though they say that TWAMP >> consist of two protocol it never says that both MUST be used anywhere i= n >> the document. The document does not have a lot of normative text. >> >> >> >> Section 5 of RFC5357 is an example and not a requirement and even the >> text that was mentioned in the IPPM session >> >> >> >> "Appendix I >> >> provides an example for purely informational purposes. It >> >> suggests an incremental path to adopting TWAMP, by implementing the >> >> TWAMP-Test protocol first." >> >> >> >> Does not say that using TWAMP-Test without the control protocol SHOULD N= OT be used. >> >> *[ACM] * >> >> *Of course it doesn=E2=80=99t! It says Appendix I describes a * >> >> *the first step of one process of standards-track TWAMP * >> >> *implementation, by starting with TWAMP-light, then * >> >> *implementing the rest of TWAMP (TWAMP-Control).* >> >> >> >> *Al* >> >> >> >> >> >> >> >> >> >> Roni Even >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani < >> mjethanandani@gmail.com> wrote: >> >> Greg, >> >> >> >> And the part that you forgot to quote that followed in Section 1.1 is: >> >> >> >> TWAMP- >> >> Control is used to initiate, start, and stop test sessions, whereas >> >> TWAMP-Test is used to exchange test packets between two TWAMP >> >> entities. >> >> >> >> There is clearly a precedence for TWAMP-Control to be a entity by itself >> and very much part of the TWAMP protocol. >> >> >> >> If this is this rational for your comments on the YANG model, then I fai= l >> to see RFC 5357 backing your claim that TWAMP-control is optional. >> >> >> >> Cheers. >> >> >> >> On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) >> wrote: >> >> >> >> Greg, >> >> >> >> All ambiguity falls away in the context of >> >> the complete TWAMP document, which says: >> >> >> >> This example eliminates the need for the TWAMP-Control protocol, and >> >> assumes that the Session-Reflector is configured and communicates its >> >> configuration with the Server through non-standard means. >> >> >> >> The example referred to above is not TWAMP; >> >> it is the option you describe, but it is >> >> called **TWAMP light**. >> >> >> >> Al >> >> >> >> *From:* ippm [mailto:ippm-bounces@ietf.org ] *On >> Behalf Of *Greg Mirsky >> *Sent:* Monday, March 27, 2017 3:16 PM >> *To:* MORTON, ALFRED C (AL) >> *Cc:* ippm@ietf.org >> *Subject:* Re: [ippm] RFC 4656 on use of OWAMP-Control and relationship >> with OWAMP-Test >> >> >> >> Hi Al, >> >> then, in my opinion, there's certain ambiguity in the text of RFC 4656 >> and in RFC 5357 as well because of the following statement in the very >> first sentence of section 1.1 RFC 5357: >> >> Similar to OWAMP [RFC4656 ], TWAMP consists = of two inter-related >> >> protocols: TWAMP-Control and TWAMP-Test. The relationship of these >> >> protocols is as defined in Section 1.1 of OWAMP [RFC4656 ]. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (AL) >> wrote: >> >> Greg, >> >> >> >> If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80=9COPTIONAL=E2= =80=9D (the term >> >> you used today when presenting) we would have used the >> >> RFC 2119 term in the text. >> >> >> >> There are plenty of other examples where both Control >> >> and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2=80=9D. >> >> >> >> Al >> >> >> >> >> >> *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky >> *Sent:* Monday, March 27, 2017 12:29 PM >> *To:* ippm@ietf.org >> *Subject:* [ippm] RFC 4656 on use of OWAMP-Control and relationship with >> OWAMP-Test >> >> >> >> Dear All, >> >> the second paragraph in section 1.1 of RFC 4656 states the following: >> >> Although OWAMP-Test may be used in conjunction with a control >> >> protocol other than OWAMP-Control, the authors have deliberately >> >> chosen to include both protocols in the same RFC to encourage the >> >> implementation and deployment of OWAMP-Control as a common >> >> denominator control protocol for one-way active measurements. >> >> >> >> I interpret "may be used" as MAY per RFC 2119. Please let me know if thi= s should not be the case. >> >> >> >> Regards, >> >> Greg >> >> >> >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> >> >> >> Mahesh Jethanandani >> >> mjethanandani@gmail.com >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 >> >> > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > --=20 [image: Accedian.com] Henrik Nydell Sr Manager Global Strategy & Solutions Cell Email Skype +46 709845992 hnydell@accedian.com h nydell --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3= =A8ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le secret=20 professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif de son= ou de ses=20 destinataires. Si vous recevez ce message par erreur, veuillez s=E2=80=99il= vous=20 plait communiquer imm=C3=A9diatement avec l=E2=80=99exp=C3=A9diteur et en d= =C3=A9truire tout=20 exemplaire. De plus, il vous est strictement interdit de le divulguer, de= =20 le distribuer ou de le reproduire sans l=E2=80=99autorisation de l=E2=80=99= exp=C3=A9diteur.=20 Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the exclusive= =20 use of its addressee(s). If you receive this message in error, please=20 inform sender immediately and destroy any copy thereof. Furthermore, any=20 disclosure, distribution or copying of this message and/or any attachment= =20 hereto without the consent of the sender is strictly prohibited. Thank you. --001a113d5008d75441054bc4f1eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is also plenty of de-facto standardization on TWAMP-= light in the field. As far as I know, these vendors support TWAMP-light in = their Session-reflectors;
Ericsson radios, Nokia radios (Except ALU who= use Control), MRV OS9x, Accedian and probably several others. Adopting TWA= MP can mean many things, depending on if you see it from the vendors perspe= ctive or the users. From a vendors perspective TWAMP-light is a path to ado= pting full TWAMP (with control) but how long this path is depends of course= on the vendor roadmap, and they may end up never implementing the RFC vers= ion of TWAMP-control. From a users perspective it may seem easier to start = with TWAMP-light with fixed configuration of reflector ports to ease firewa= ll configuration, then possibly adopting full TWAMP further down the line. = I argue that the meaning with TWAMP is to obtain metrics (TWAMP-test), and = thus the setup portion is a different function which may or may not use a s= tandardized method. As things evolve it may prove more useful to implement = a REST-type API or a NetConf API for the control of the session-reflector t= o easier interwork in ETSI-NFV type orchestrated environments.=C2=A0
<= div>


On Tue, Mar 28, 2017 at 1:56 AM, Greg Mirsky <gregim= irsky@gmail.com> wrote:
Dear All,
in the first paragraph of already mentioned sec= tion 1.1 of RFC 4656 characterizes OWAMP-Control and OWAMP-Test as two inte= r-related but not inter-dependent protocols. I believe that the same is tru= e for TWAMP-Control and TWAMP-Test. Control protocols may be used to initia= te, start and stop test sessions but the OWAMP/TWAMP-control protocol is no= t the only way to achieve that in the same way as co-location of Control-Cl= ient and Session-Sender, on one side, and Server and Session-Reflector, on = another side, is not the only way these functions may be instantiated in pa= rticipating nodes. In fact, RFC 5357 does envision separation, though physi= cal, between TWAMP-Control and TWAMP-Test in the following figure:
         +--------=
--------+               +-------------------+
         | Session-Sender |<-TWAMP-Test-->| Session-Reflector |
         +----------------+               +-------------------+
           ^                                     ^
           |                                     |
           |                                     |
           |                                     |
           |  +----------------+<----------------+
           |  |     Server     |
           |  +----------------+
           |    ^
           |    |
           | TWAMP-Control
           |    |
           v    v
         +----------------+
         | Control-Client |
         +----------------+

Regards,
Gre=
g

On Mon, Mar 27, 2017 at 6:07 PM, = MORTON, ALFRED C (AL) <acmorton@att.com> wrote:

I=E2=80=99m sorry Roni, but that=E2=80=99s exa= ctly what this phrase,

=E2=80=9C...an incremental path to adopting TWAMP=E2=80=A6=E2=80=9D =C2=A0means,

suggesting a multi-step process to achieve a f= ull TWAMP

implementation.

=C2=A0

The sentence in the body sets the context for = Appendix I.

It says the Appendix describes building TWAMP-= Test *first*.

Clearly, TWAMP-Test is not the final step!<= /u>

=C2=A0

Al

=C2=A0

From: Ron Even= [mailto:ron.ev= en.tlv@gmail.com]
Sent: Monday, March 27, 2017 6:54 PM
To: MORTON, ALFRED C (AL)
Cc: Mahesh Jethanandani; ippm@ietf.org


Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationshi= p with OWAMP-Test

=C2=A0

Al,

The last part of your response =C2=A0"= then implementing the rest of TWAMP (TWAMP-Control)." is not there. T= his is why I said that it does not say that you SHOULD implement the control protocol, you can stop after implmenting the test protocol.

Roni

=C2=A0

On Mon, Mar 27, 2017 at 5:39 PM, MORTON, ALFRED C (A= L) <acmorton@att.c= om> wrote:

Roni, in-line:

=C2=A0

From: Ron Even= [mailto:ron.ev= en.tlv@gmail.com]
Sent: Monday, March 27, 2017 5:54 PM
To: Mahesh Jethanandani
Cc: MORTON, ALFRED C (AL); ippm@ietf.org
Subject: Re: [ippm] RFC 4656 on use of OWAMP-Control and relationshi= p with OWAMP-Test

=C2=A0

Hi,

I read both RFC5357 and RFC 4656 and even though the= y say that TWAMP consist of two protocol it never says that =C2=A0both MUST= be used anywhere in the document. The document does not have a lot of normative text.

=C2=A0

Section 5 of RFC5357 is an example and not a require= ment and even the text that was mentioned in the IPPM session=

=C2=A0

"Appendix I provides an exam= ple for purely informational purposes. It

=C2=A0=C2=A0 suggests an incremental path =
to adopting TWAMP, by implementing the
=C2=A0=C2=A0 TWAMP-Test protocol first.&qu=
ot;
=C2=A0
Does not say that using TWAMP-Test without=
 the control protocol SHOULD NOT be used.
[ACM] 
Of course it doesn=E2=
=80=99t! It says Appendix I describes a 
the first step of one =
process of standards-track TWAMP 
implementation, by sta=
rting with TWAMP-light, then 
implementing the rest =
of TWAMP (TWAMP-Control).
=C2=A0
Al
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Roni Even
=C2=A0
=C2=A0
=C2=A0
=C2=A0

=C2=A0

On Mon, Mar 27, 2017 at 4:20 PM, Mahesh Jethanandani= <mjethanan= dani@gmail.com> wrote:

Greg,

=C2=A0

And the part that you forgot to quote that followed = in Section 1.1 is:

=C2=A0

TWAMP-
=C2=A0=C2=A0 Control is used to initiate, start, and stop test session=
s, whereas
=C2=A0=C2=A0 TWAMP-Test is used to exchange test packets between two T=
WAMP
=C2=A0=C2=A0 entities.

=C2=A0

There is clearly a precedence for TWAMP-Control to b= e a entity by itself and very much part of the TWAMP protocol.

=C2=A0

If this is this rational for your comments on the YA= NG model, then I fail to see RFC 5357 backing your claim that TWAMP-control= is optional.

=C2=A0

Cheers.

=C2=A0

On Mar 27, 2017, at 4:08 PM, MORTON, ALFRED C (AL) &= lt;acmorton@att.com> wrote:

=C2=A0

Greg,

=C2=A0

All ambiguity falls away in the context of

the complete TWAMP document, which says:<= /u>

=C2=A0

=C2=A0=C2=A0 This example eliminates the need for the TWAM= P-Control protocol, and

=C2=A0=C2=A0 assumes that the Session-Reflector is configu= red and communicates its

=C2=A0=C2=A0 configuration with the Server through non-sta= ndard means.

=C2=A0

The example referred to above is not TWAMP;<= u>

it is the option you describe, but it is<= /u>

called *TWAMP light*.

=C2=A0

Al

=C2=A0

=C2=A0

Hi Al,

then, in my opinion, there's certain ambiguity i= n the text of RFC 4656 and in RFC 5357 as well because of the following sta= tement in the very first sentence of section 1.1 RFC 5357: 

=C2=A0=C2=A0 Similar to OWAMP [RFC4656=
], TWAMP consists of two inter-related
=C2=A0=C2=A0 protocols: TWAMP-Control and TWAMP-Test.=C2=A0 The relati=
onship of these
=C2=A0=C2=A0 protocols is as defined in Section 1.1 of OWAMP [RFC4656]. 
=C2=A0
Regards,
Greg

=C2=A0

On Mon, Mar 27, 2017 at 12:24 PM, MORTON, ALFRED C (= AL) <acmorton@att.com> wrote:

Greg,

=C2=A0

If we had meant RFC 2119 =E2=80=9CMAY=E2=80=9D or =E2=80= =9COPTIONAL=E2=80=9D (the term

you used today when presenting) we would have used the

RFC 2119 term in the text.

=C2=A0

There are plenty of other examples where both Control

and Test protocols are taken as =E2=80=9Cthe full TWAMP=E2= =80=9D.

=C2=A0

Al

=C2=A0

=C2=A0

From:=C2=A0ippm [mailto:ippm-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Greg Mirsky
Sent:=C2=A0Monda= y, March 27, 2017 12:29 PM
To:=C2=A0ip= pm@ietf.org
Subject:=C2=A0[i= ppm] RFC 4656 on use of OWAMP-Control and relationship with OWAMP-Test

=C2=A0

Dear All,

the second paragraph in section 1.1 of RFC 4656 stat= es the following:

=C2=A0=C2=A0 Although OWAMP-Test may be used in conjunction with a con=
trol
 =C2=A0=C2=A0protocol other than OWAMP-Control, the authors have delib=
erately
=C2=A0=C2=A0 chosen to include both protocols in the same RFC to encou=
rage the
=C2=A0=C2=A0 implementation and deployment of OWAMP-Control as a commo=
n
=C2=A0=C2=A0 denominator control protocol for one-way active measureme=
nts.
=C2=A0
I interpret "may be used" as MAY per RFC 2119. Please let me=
 know if this should not be the case.
=C2=A0
Regards,
Greg

=C2=A0

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

=C2=A0

Mahesh Jethanandani

=C2=A0

=C2=A0

=C2=A0


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

=C2=A0

=C2=A0


_______________________________________________
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




--
=


=

3D"Accedian.com"

Henrik Nydell

Sr Ma= nager Global Strategy & Solutions

<= /div>

+46 709845992

hnydell@accedian.com

hnydell

= Cell

Email

Skype



= =C2=A0 =C2=A0 =C2=A0 =C2=A0


=

Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

--001a113d5008d75441054bc4f1eb-- From nobody Tue Mar 28 09:25:33 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339591294FF; Tue, 28 Mar 2017 09:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DAwp1dgo-lUG; Tue, 28 Mar 2017 09:25:16 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE3A126DFB; Tue, 28 Mar 2017 09:25:16 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id f193so42579855oib.2; Tue, 28 Mar 2017 09:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5ET2DWmY4h4wpr3nSNPXvwEpmnSeWaMM4xHxs+Wa1rs=; b=BS9VV08VhBuLLBgCz/xVuNXcefsTEzOkl7p0yNFvNXvlY91UffHWURbJkBLJ3g0QhP AkxraXy0N0FlzIOKsbTPPm4MPTOk5pVNXplRSfpkF1ksbqMQ/hfhu3bHlNtTg/DO6bCY o/BsTWSu4ZRSwelhNmKQ2FkE11Q51YKHNiDy2wcBKHL8ZpvcwMw83DXFlG/cXFTw5Fjb /UJxoX3J6aCu4ok6TXNOpU/+GdR03Bkz5x1/dNEtkz0y8pBBgY1ZBPz427tjJdxKUnB8 EFPYocuqeVxni+O+5yDYjhnmz9dhvxvwz4PJ25Pf5vw00ik6matRoq8UjjrMuTH/t+YV hTEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5ET2DWmY4h4wpr3nSNPXvwEpmnSeWaMM4xHxs+Wa1rs=; b=L77bE/BsYN7Po2oFjJNyyWjeAI4ba3mlgSDuUBDyUo0KkStsvraIjmD84qrEIA7QPI NOtHsuFx+uSLsY41B42j1lj01veOCCou1mATriLXJLu4V9DLCESr0s1JeQvY5NHbkrT0 +VAw2S61IAJnyVtAtrN80jg+a6YvDGBMFB/6JbfGJkW6pGm7u7jvgxFIxF7lAk2wqyAi f+QWPEaame7UJly32akMbFS2+mRl7E9yjWxoep0hfm2L3D8ltKazezvLcJnS0M0YnE/c 8uW4AftHrGxtbklmXdAXPVU6yS2uCWNj0Duu2NemB6rLpdEFEVD09Z3UFVqMmWpzt2+T KaPw== X-Gm-Message-State: AFeK/H1TfAQNp/PFH0UTvLKHiY8HN+AvWRTZaTEQEVqIGBGj5r4n1IoQGzXktiS6GfJQLUBQmT2x7SHLf8Bh+w== X-Received: by 10.202.195.141 with SMTP id t135mr9234831oif.157.1490718316006; Tue, 28 Mar 2017 09:25:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Tue, 28 Mar 2017 09:25:15 -0700 (PDT) From: Greg Mirsky Date: Tue, 28 Mar 2017 11:25:15 -0500 Message-ID: To: IPPM Chairs , Spencer Dawkins , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a1137db86af925d054bcce7dd Archived-At: Subject: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:25:19 -0000 --001a1137db86af925d054bcce7dd Content-Type: text/plain; charset=UTF-8 Dear Spencer, Brian and Bill, I apologize but I've missed the exact question that all present at the IPPM meeting were asked to vote on. Could you please kindly re-state it? Regards, Greg --001a1137db86af925d054bcce7dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Spencer, Brian and Bill,
I apologize but I've= missed the exact question that all present at the IPPM meeting were asked = to vote on. Could you please kindly re-state it?

R= egards,
Greg
--001a1137db86af925d054bcce7dd-- From nobody Tue Mar 28 09:49:34 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1112A12944B; Tue, 28 Mar 2017 09:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 cA6bK27CFAE7; Tue, 28 Mar 2017 09:49:31 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF15E129436; Tue, 28 Mar 2017 09:49:30 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2BCA5340768; Tue, 28 Mar 2017 18:49:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.25459); Tue, 28 Mar 2017 18:49:28 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Tue, 28 Mar 2017 18:49:28 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 12856496; Tue, 28 Mar 2017 18:49:28 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F176C127-CC47-4FD9-907C-B96552C9A06B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Tue, 28 Mar 2017 18:49:27 +0200 Cc: IPPM Chairs , Spencer Dawkins , "ippm@ietf.org" Message-Id: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> References: To: Greg Mirsky X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:49:33 -0000 --Apple-Mail=_F176C127-CC47-4FD9-907C-B96552C9A06B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Greg, The hum we took was: Do you think that the IOAM draft(s) (in some form) = should be brought into IPPM, regardless of charter (i.e., with the = intention that the WG would recharter as necessary in order to allow the = IOAM work to go forward in IPPM); second, we'd appreciate those who have = concerns that caused them to hum against to bring those to the list for = discussion. Thanks, cheers, Brian > On 28 Mar 2017, at 18:25, Greg Mirsky wrote: >=20 > Dear Spencer, Brian and Bill, > I apologize but I've missed the exact question that all present at the = IPPM meeting were asked to vote on. Could you please kindly re-state it? >=20 > Regards, > Greg > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm --Apple-Mail=_F176C127-CC47-4FD9-907C-B96552C9A06B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY2pQYAAoJEIoSt78L6kajXEsP/Ag/D1W05VlvJgA/RQzeid6P LRvoQAFkKH0N6m/8CYhi4tKsDL1oQw3imHyCXkJeHfeSk/oYZKdFlIwbvd/+HJwz +KgFNmO8UQhx2i28bZpP+3tp6glPx+7YGoVzC9Mk8sXMocD6DAJOuSCGvF+oTttg hs6fNi3Vyf9J85f4oa7DIMv/i+gI483IRXYia+zlAyJyBJi+aTOCdLiYw0Fr5r3f iIJcDtdkRl2EsCfwmFQj6JsH+LWqKkes4deZrYTHrfyciArALxQFOTBcQt5o6KJx xQ2SJ1Rwo+/+hHfp0DSwSOiQfpS7gGHvZXk0pm2NwpAXa5JNWRcWL8/VvRogRGUO 5Zvl5HZqadQ5FLUkGAM8p4AvPnydBwi3HPPx5ibKbVIxrKJt1UKCwdHYTElZ8/by L9vOL3rA9rd1JIiT1gdO6jKmp06hpaKTh42R+DUQr5T0JZXLh2WRitJqrSUuIkQb F7xcPGrvP+2mSWwReKbmblbADpB+b2jeP0HHxEpTcT/O3l/04LqqJyY2fBeol+// 9XZYA80sAQbEdr/m32KiHU8qzeAwJ6N6g5LOADSDPpEt9QILJAeqUgmcuJfqBxFg VN5i6YSkhS2dRXgT1EzuiqSopmfyC0s9/QmrSMHbQOX2bu4INpThQeUtGJPi2Jhf l1gS+wDuclOYVHrEiCWP =371t -----END PGP SIGNATURE----- --Apple-Mail=_F176C127-CC47-4FD9-907C-B96552C9A06B-- From nobody Tue Mar 28 10:03:30 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8DD1296B0; Tue, 28 Mar 2017 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 p72k6svU_8JH; Tue, 28 Mar 2017 10:03:26 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D01E12963F; Tue, 28 Mar 2017 10:03:17 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id o67so32527291oib.1; Tue, 28 Mar 2017 10:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JQX/wbH/2xY2s9QuZOzxZCDmkXqNROGGTqlDqDN0jCk=; b=ZqVQRKMr6X9QGCK8Bp8hFDk9GCcXuj0v1o7X1qhsPET34qea5qMjrlScNcaqRT11l9 r4/kNP8TFyWuJuQuy3N6Cv06spNBts8JvENeKg1zCH/w8yceT+1h50kxL+AcHjPb9EUR rvtr9bKeeofGQvGjHsczRM5hn0x4TcaBxgKDBRtDPxDFbbE9oGk9tKXE9J4uz4jNeEjH mL6p6Thwx5dIXQsf1mDedHR78i05oDhG8LjjQXp4OwJ7mmcfGyMhLyZRFIXfri7I8sKq CRxuDHFJClNwADVaCxd0vnS/Scc+SZGm5GzLMUqcLUc1yvgn/kY3MpoWqvBp3TwziFh7 6LZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JQX/wbH/2xY2s9QuZOzxZCDmkXqNROGGTqlDqDN0jCk=; b=XybEl7rhn/ThSMCj/oBLAo1qnb6MFzWJUJDqVw2RmLFe5ZoZvUYqH7vkfMLu8Vlumc Q0SxHUlY781ldlS2kPmT7C8VqpTN9fFqiEsnuYSszVPZVhzr3hCa9q01A7YwyRv7rouM 3RI+gduIDCRfEcSHPysa+LYjTIcgq6I8VxD4k/bTUOi0yvEOmVFLA6X6i9B2GeTr/xmX yAclPEr+4FgtItCFEW796UE/YSpc41u2WsN58ok/WuExsQpW61DrCO+/bVrXnNsLZCHq ZQ0BKCYUUF9iUsh2fUPSXpgPVOXV92zeBbPDJ7x83l65X12jC1pe4Hx7nhDjMcT+mmmG +WZQ== X-Gm-Message-State: AFeK/H18mll7R3zRhR2K62z6baNC/fv7US9hdiGtnzW0RJPnlZC4dm+orZDJUsYk/o1yvIJndM/apYCHzmD1/Q== X-Received: by 10.202.195.141 with SMTP id t135mr9395313oif.157.1490720596697; Tue, 28 Mar 2017 10:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Tue, 28 Mar 2017 10:03:16 -0700 (PDT) In-Reply-To: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> From: Greg Mirsky Date: Tue, 28 Mar 2017 12:03:16 -0500 Message-ID: To: "Brian Trammell (IETF)" Cc: IPPM Chairs , Spencer Dawkins , "ippm@ietf.org" Content-Type: multipart/alternative; boundary=001a1137db86a02963054bcd6fb7 Archived-At: Subject: Re: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:03:29 -0000 --001a1137db86a02963054bcd6fb7 Content-Type: text/plain; charset=UTF-8 Hi Brian, thank you for the most detailed clarification. My first concern is with the scope of the question set to those present at the meeting. I find four drafts related to iOAM: - draft-brockners-inband-oam-requirements - draft-brockners-inband-oam-transport - draft-brockners-inband-oam-data - draft-brockners-proof-of-transit Out of these four drafts I see only draft-brockners-inband-oam-data as being reasonably close to scope of IPPM WG, with or without re-chartering. Other drafts, in my view, are too closely related to particular networking, in fact, overlay networking, technologies so that their discussion is more appropriate in respective WGs of the Routing Area (or in one of them taking on that role). Thus my hum vote was out of concern with the question being formulated too broadly and without, in my view, sufficient discussion by the WG of relevance of each draft, not all of them as a package to IPPM WG. Regards, Greg On Tue, Mar 28, 2017 at 11:49 AM, Brian Trammell (IETF) wrote: > hi Greg, > > The hum we took was: Do you think that the IOAM draft(s) (in some form) > should be brought into IPPM, regardless of charter (i.e., with the > intention that the WG would recharter as necessary in order to allow the > IOAM work to go forward in IPPM); second, we'd appreciate those who have > concerns that caused them to hum against to bring those to the list for > discussion. > > Thanks, cheers, > > Brian > > > > On 28 Mar 2017, at 18:25, Greg Mirsky wrote: > > > > Dear Spencer, Brian and Bill, > > I apologize but I've missed the exact question that all present at the > IPPM meeting were asked to vote on. Could you please kindly re-state it? > > > > Regards, > > Greg > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > --001a1137db86a02963054bcd6fb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,
thank you for the most detailed clarificatio= n. My first concern is with the scope of the question set to those present = at the meeting. I find four drafts related to iOAM:
  • draft= -brockners-inband-oam-requirements
  • draft-brockners-inband-oam-t= ransport
  • draft-brockners-inband-oam-data
  • draft-broc= kners-proof-of-transit
Out of these four drafts I see only dra= ft-brockners-inband-oam-data as being reasonably close to scope of IPPM WG,= with or without re-chartering. Other drafts, in my view, are too closely r= elated to particular networking, in fact, overlay networking, technologies = so that their discussion is more appropriate in respective WGs of the Routi= ng Area (or in one of them taking on that role). Thus my hum vote was out o= f concern with the question being formulated too broadly and without, in my= view, sufficient discussion by the WG of relevance of each draft, not all = of them as a package to IPPM WG.

Regards,
Greg

On Tue, Mar 28, 2017 at 11:49 AM, Brian Trammell (IETF) = <ietf@trammell.ch<= /a>> wrote:
hi Greg,

The hum we took was: Do you think that the IOAM draft(s) (in some form) sho= uld be brought into IPPM, regardless of charter (i.e., with the intention t= hat the WG would recharter as necessary in order to allow the IOAM work to = go forward in IPPM); second, we'd appreciate those who have concerns th= at caused them to hum against to bring those to the list for discussion.
Thanks, cheers,

Brian


> On 28 Mar 2017, at 18:25, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Dear Spencer, Brian and Bill,
> I apologize but I've missed the exact question that all present at= the IPPM meeting were asked to vote on. Could you please kindly re-state i= t?
>
> Regards,
> Greg
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm

--001a1137db86a02963054bcd6fb7-- From nobody Tue Mar 28 10:31:28 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C517129717; Tue, 28 Mar 2017 10:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 WtyYbwQKyRxR; Tue, 28 Mar 2017 10:31:23 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4859129686; Tue, 28 Mar 2017 10:31:22 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2SHVJZX005122; Tue, 28 Mar 2017 18:31:19 +0100 Received: from 950129200 (dhcp-8535.meeting.ietf.org [31.133.133.53]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2SHVGe5005081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Mar 2017 18:31:17 +0100 Reply-To: From: "Adrian Farrel" To: "'Greg Mirsky'" , "'Brian Trammell \(IETF\)'" Cc: "'IPPM Chairs'" , References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> In-Reply-To: Date: Tue, 28 Mar 2017 18:31:16 +0100 Message-ID: <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FB_01D2A7F1.7E2E5BD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3Ooq+i0V2uDTKsntzdbDryWnJDQIGbTuQAhzFMcOgwDyngA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22970.007 X-TM-AS-Result: No--26.996-10.0-31-10 X-imss-scan-details: No--26.996-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkD/L1OmfjpS5txajlW+zwxCy42ZowMzkpnjud2x7TPVtwQt 4bBDXhiJXKdjrSp48nyK46Tg39O8CsPlDt/vDJ7Eh4Ce12gzEFopWss5kPUFdBRZ/9wBMhGsjhI gHZ5KseR4v6tTP35WD50/yG7jSHA4ZvEjxsowzZVff2PxVyknEfT+ANO7JYDkyPRAwD/3abZqSo EI1gbBDZLBO0Bj6OndwZAiLOTSi9Z5tPehT2kk420PWqD0pliRI5K4Cd+0ao+rzPs85fwUk1qvN 5EPDXKQd5hC/r1Knl+CvCHvcTIr1dWKNmKtnvU1lVHM/F6YkvTA8jzXpPXv2gAheUymmndfo8As EqzaHYfYsc1N6c+Lo8RomTvKwzxgcAcy2KepxYMmtTGirqG/D978NWlYojkrMMn1rcqKQahoPnU By5rqayJXjq1vsVD+EfkV1pDwoYA5pL1TtnjZ/lWeeIqHthMLC/ExpXrHizwbIszkLg3+MSDtE0 GKeTYtmOxlxZB6xk7RssSdd19BsgUJ2rQm9htlnVTWWiNp+v9BldmDYjwlppuSv4SfxhK37/+9s wuISRVYVA2Tj4cKiER2ooafExxgMaCTQC8f3+Gd27eF5UDFow/i8FY2vTOBIDp4740OYDElncPT Mo+HsfXTJA26jU4ll+5wwvuICnpzUF5L8npo310yuDrT1H0Eo7heNWkyUV2f6WkmZi4Ro3uW2rI m8eCn8k6NRrEpcqoZIoMiCNT2eTLj310JtDLwiguiJuCNURfVY9jEIdWup2AfN+t90cS3hzQHk5 Qv+7UzmpYx+UKjh3C2KyYp/H7vWYqLLUX2mAueAiCmPx4NwGmRqNBHmBve1B0Hk1Q1KyIzqx6Dt fVZtimgiU7DnN2w6Ft0wiS6vTFsgofGP782g7s/W+xwjslsbyFP6Ixa8Zs= Archived-At: Subject: Re: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 17:31:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01FB_01D2A7F1.7E2E5BD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I also found the question a bit problematic and found myself inclined to = hum both for and against. =20 My point (sadly I have made this point a couple of times now) is that = the data format we work on, the encapsulations we define for different = transports, and the whole proof of concept thing are all dependent on = the scope of the problem we are trying to solve. =20 While we can all sort of agree roughly on the sort of problem we might = be working on, there are some pretty large elephants on which we have = yet to shed light. The example I gave at the mic was a case raised by Mirja in the meeting, = viz. if this a technique that is applied only at the start of some form = of tunnel? That is, is the addition of OAM "overhead" *only* happening = at the same time as addition of encapsulation overhead? As I recall (but = I am old and prone to misremembering) the answer delivered to Mirja was = "Yes, you could apply iOAM to tunnels" which, IMHO, was not an answer to = her question. =20 So, I would really, really, like to see some WG somewhere adopt = draft-brockners-inband-oam-requirements so that we can build consensus = on the scope of the project. That will allow later work to move much = more smoothly. I think Frank suggested that the IESG statement on = requirements RFCs meant that we didn't need to do this and could either = abandon the requirements work or progress the two in parallel. But I = find that the potential variation in the solutions is so wide that = without knowing what we are trying to achieve it is hard to say that = adopting a particular draft as "a good starting point for future work in = the working group" would be a good idea.=20 =20 To be clear, I am not saying that we have to publish a requirements RFC = before we can start solutions work. I am saying that we must have = consensus on scope before we progress solutions work. =20 Thanks, Adrian =20 From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: 28 March 2017 18:03 To: Brian Trammell (IETF) Cc: IPPM Chairs; ippm@ietf.org Subject: Re: [ippm] Vote at IPPM session =20 Hi Brian, thank you for the most detailed clarification. My first concern is with = the scope of the question set to those present at the meeting. I find = four drafts related to iOAM: * draft-brockners-inband-oam-requirements * draft-brockners-inband-oam-transport * draft-brockners-inband-oam-data * draft-brockners-proof-of-transit Out of these four drafts I see only draft-brockners-inband-oam-data as = being reasonably close to scope of IPPM WG, with or without = re-chartering. Other drafts, in my view, are too closely related to = particular networking, in fact, overlay networking, technologies so that = their discussion is more appropriate in respective WGs of the Routing = Area (or in one of them taking on that role). Thus my hum vote was out = of concern with the question being formulated too broadly and without, = in my view, sufficient discussion by the WG of relevance of each draft, = not all of them as a package to IPPM WG. =20 Regards, Greg =20 On Tue, Mar 28, 2017 at 11:49 AM, Brian Trammell (IETF) = wrote: hi Greg, The hum we took was: Do you think that the IOAM draft(s) (in some form) = should be brought into IPPM, regardless of charter (i.e., with the = intention that the WG would recharter as necessary in order to allow the = IOAM work to go forward in IPPM); second, we'd appreciate those who have = concerns that caused them to hum against to bring those to the list for = discussion. Thanks, cheers, Brian > On 28 Mar 2017, at 18:25, Greg Mirsky wrote: > > Dear Spencer, Brian and Bill, > I apologize but I've missed the exact question that all present at the = IPPM meeting were asked to vote on. Could you please kindly re-state it? > > Regards, > Greg > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm =20 ------=_NextPart_000_01FB_01D2A7F1.7E2E5BD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I also found the question a = bit problematic and found myself inclined to hum both for and = against.

 

My point (sadly I have made = this point a couple of times now) is that the data format we work on, = the encapsulations we define for different transports, and the whole = proof of concept thing are all dependent on the scope of the problem we = are trying to solve.

 

While we can all sort of agree = roughly on the sort of problem we might be working on, there are some = pretty large elephants on which we have yet to shed = light.

The example I gave at the mic = was a case raised by Mirja in the meeting, = viz. if this a technique that is applied only at the start of some form = of tunnel? That is, is the addition of OAM "overhead" *only* = happening at the same time as addition of encapsulation overhead? As I = recall (but I am old and prone to misremembering) the answer delivered = to Mirja was "Yes, you could apply = iOAM to tunnels" which, IMHO, was not = an answer to her question.

 

So, I would really, really, = like to see some WG somewhere adopt draft-brockners-inband-oam-requirements so that we can build consensus on = the scope of the project. That will allow later work to move much more = smoothly. I think Frank suggested that the IESG statement on = requirements RFCs meant that we didn't need to do this and could either = abandon the requirements work or progress the two in parallel. But I = find that the potential variation in the solutions is so wide that = without knowing what we are trying to achieve it is hard to say that = adopting a particular draft as "a good starting point for future = work in the working group" would be a good idea. =

 

To be clear, I am not saying = that we have to publish a requirements RFC before we can start solutions = work. I am saying that we must have consensus on scope before we = progress solutions work.

 

Thanks,

Adrian

 

From: ippm = [mailto:ippm-bounces@ietf.org] On Behalf Of Greg = Mirsky
Sent: 28 March 2017 18:03
To: Brian Trammell = (IETF)
Cc: IPPM Chairs; ippm@ietf.org
Subject: Re: = [ippm] Vote at IPPM session

 

Hi = Brian,

thank you for the most = detailed clarification. My first concern is with the scope of the = question set to those present at the meeting. I find four drafts related = to iOAM:

  • draft-brockners-inband-oam-requirements
  • draft-brockners-inband-oam-transport
  • draft-brockners-inband-oam-data
  • draft-brockners-proof-of-transit

Out of these four drafts I see only = draft-brockners-inband-oam-data as being reasonably close to scope of = IPPM WG, with or without re-chartering. Other drafts, in my view, are = too closely related to particular networking, in fact, overlay = networking, technologies so that their discussion is more appropriate in = respective WGs of the Routing Area (or in one of them taking on that = role). Thus my hum vote was out of concern with the question being = formulated too broadly and without, in my view, sufficient discussion by = the WG of relevance of each draft, not all of them as a package to IPPM = WG.

 

Regards,

Greg

 

On Tue, = Mar 28, 2017 at 11:49 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:

hi Greg,

The hum we took was: Do you think that = the IOAM draft(s) (in some form) should be brought into IPPM, regardless = of charter (i.e., with the intention that the WG would recharter as = necessary in order to allow the IOAM work to go forward in IPPM); = second, we'd appreciate those who have concerns that caused them to hum = against to bring those to the list for discussion.

Thanks, = cheers,

Brian



> On 28 Mar 2017, at 18:25, Greg Mirsky = <gregimirsky@gmail.com> = wrote:
>
> Dear Spencer, Brian and Bill,
> I apologize = but I've missed the exact question that all present at the IPPM meeting = were asked to vote on. Could you please kindly re-state = it?
>
> Regards,
> Greg

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

 

------=_NextPart_000_01FB_01D2A7F1.7E2E5BD0-- From nobody Tue Mar 28 12:37:08 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CC5129A02; Tue, 28 Mar 2017 12:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 u1byxEDoBOcQ; Tue, 28 Mar 2017 12:37:03 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81BA129564; Tue, 28 Mar 2017 12:36:59 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8BB1A340DA5; Tue, 28 Mar 2017 21:36:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.11119); Tue, 28 Mar 2017 21:36:58 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Tue, 28 Mar 2017 21:36:58 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.6]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 12867309; Tue, 28 Mar 2017 21:36:58 +0200 To: adrian@olddog.co.uk, 'Greg Mirsky' References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> Cc: 'IPPM Chairs' , ippm@ietf.org From: "Brian Trammell (IETF)" Message-ID: <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> Date: Tue, 28 Mar 2017 21:36:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KKAq3uXxO7FEBPRXFJDQVUJWvN8MIWPch" Archived-At: Subject: Re: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 19:37:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KKAq3uXxO7FEBPRXFJDQVUJWvN8MIWPch Content-Type: multipart/mixed; boundary="uEKS3kLg838MsMtPhr5CTNlfiT282mqm4"; protected-headers="v1" From: "Brian Trammell (IETF)" To: adrian@olddog.co.uk, 'Greg Mirsky' Cc: 'IPPM Chairs' , ippm@ietf.org Message-ID: <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> Subject: Re: [ippm] Vote at IPPM session References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> In-Reply-To: <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> --uEKS3kLg838MsMtPhr5CTNlfiT282mqm4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable hi Adrian, Greg, all, As chair... Indeed, we could (should) have asked a more precise question, but given that we didn't really have a more precise intention, beyond to determine the sense of the room about "does IOAM (in some guise) fit in IPPM", this is precisely the discussion we were hoping to start. :) As an individual... What I'm hearing from Greg: The information elements (and presumably, how they can be used by devices on path to perform hybrid measurements) is/may be in scope for IPPM, anything binding this to particular overlay technologies is only in scope for the working groups with responsibility for those technologies. This seems reasonable to me. I will note that one reason that this set of drafts has had a hard time finding a home is that it cuts across areas in a way that it's pretty easy for each area to look at it and say "interesting, maybe, related, maybe, but definitely not our problem". Picking up a core *somewhere* then delegating more finely scoped work to other WGs is one way to make this work. What I'm hearing from Adrian: It's too early to talk about data models, we don't know what the problem is yet. Let's define the problem (i.e., the metrics we want to define methodologies for, in IPPM terms) first, so a good first step would be adopting the requirements document in IPPM.= This seems reasonable to me, as well. Whether or not publishing a requirements document happens, adopting it to work on it seems like a good way for the WG to determine if it'd like to bring other documents later. Cheers, Brian P.S. I'm about to head out on the travel that's the reason I'm not in Chicago, so I'll return to this discussion in mid-April. On 03/28/2017 07:31 PM, Adrian Farrel wrote: > I also found the question a bit problematic and found myself inclined t= o > hum both for and against. >=20 > =20 >=20 > My point (sadly I have made this point a couple of times now) is that > the data format we work on, the encapsulations we define for different > transports, and the whole proof of concept thing are all dependent on > the scope of the problem we are trying to solve. >=20 > =20 >=20 > While we can all sort of agree roughly on the sort of problem we might > be working on, there are some pretty large elephants on which we have > yet to shed light. >=20 > The example I gave at the mic was a case raised by Mirja in the meeting= , > viz. if this a technique that is applied only at the start of some form= > of tunnel? That is, is the addition of OAM "overhead" *only* happening > at the same time as addition of encapsulation overhead? As I recall (bu= t > I am old and prone to misremembering) the answer delivered to Mirja was= > "Yes, you could apply iOAM to tunnels" which, IMHO, was not an answer t= o > her question. >=20 > =20 >=20 > So, I would really, really, like to see some WG somewhere adopt > draft-brockners-inband-oam-requirements so that we can build consensus > on the scope of the project. That will allow later work to move much > more smoothly. I think Frank suggested that the IESG statement on > requirements RFCs meant that we didn't need to do this and could either= > abandon the requirements work or progress the two in parallel. But I > find that the potential variation in the solutions is so wide that > without knowing what we are trying to achieve it is hard to say that > adopting a particular draft as "a good starting point for future work i= n > the working group" would be a good idea. >=20 > =20 >=20 > To be clear, I am not saying that we have to publish a requirements RFC= > before we can start solutions work. I am saying that we must have > consensus on scope before we progress solutions work. >=20 > =20 >=20 > Thanks, >=20 > Adrian >=20 > =20 >=20 > *From:*ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky > *Sent:* 28 March 2017 18:03 > *To:* Brian Trammell (IETF) > *Cc:* IPPM Chairs; ippm@ietf.org > *Subject:* Re: [ippm] Vote at IPPM session >=20 > =20 >=20 > Hi Brian, >=20 > thank you for the most detailed clarification. My first concern is with= > the scope of the question set to those present at the meeting. I find > four drafts related to iOAM: >=20 > * draft-brockners-inband-oam-requirements > * draft-brockners-inband-oam-transport > * draft-brockners-inband-oam-data > * draft-brockners-proof-of-transit >=20 > Out of these four drafts I see only draft-brockners-inband-oam-data as > being reasonably close to scope of IPPM WG, with or without > re-chartering. Other drafts, in my view, are too closely related to > particular networking, in fact, overlay networking, technologies so tha= t > their discussion is more appropriate in respective WGs of the Routing > Area (or in one of them taking on that role). Thus my hum vote was out > of concern with the question being formulated too broadly and without, > in my view, sufficient discussion by the WG of relevance of each draft,= > not all of them as a package to IPPM WG. >=20 > =20 >=20 > Regards, >=20 > Greg >=20 > =20 >=20 > On Tue, Mar 28, 2017 at 11:49 AM, Brian Trammell (IETF) > > wrote: >=20 > hi Greg, >=20 > The hum we took was: Do you think that the IOAM draft(s) (in some form)= > should be brought into IPPM, regardless of charter (i.e., with the > intention that the WG would recharter as necessary in order to allow th= e > IOAM work to go forward in IPPM); second, we'd appreciate those who hav= e > concerns that caused them to hum against to bring those to the list for= > discussion. >=20 > Thanks, cheers, >=20 > Brian >=20 >=20 >=20 >> On 28 Mar 2017, at 18:25, Greg Mirsky > wrote: >> >> Dear Spencer, Brian and Bill, >> I apologize but I've missed the exact question that all present at the= > IPPM meeting were asked to vote on. Could you please kindly re-state it= ? >> >> Regards, >> Greg >=20 >> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >=20 > =20 >=20 --uEKS3kLg838MsMtPhr5CTNlfiT282mqm4-- --KKAq3uXxO7FEBPRXFJDQVUJWvN8MIWPch Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAljau1kACgkQihK3vwvq RqO5bxAAozEaD+0GKEf1UhbeTP5oFfdene5LGZRHTHbve82U7A9U8ZwA3PE/OAW2 TAH4mFW0qERNLqFFEdB4OIcR2cRoUjCU7o3FiSCsK7WtbiHUNvP4+DvvCFX4vgV9 rC8BUlRuXbbkNtx8ERzacPmLiTRjQ/QlFKm2+AQFJ+Vn9al2msG2Tc3oaoIYOYkL o+t6oiA5/pauWKMOPCh0xCYEp+nZayF9js+6Nutw5dxqwWHtABxSGPYVbbYeBKz6 /3OFG1DIMr74oBNKHTWk/NQWSDbIHVt6YY2EvTQBpjkxUu40O2Nptfos62ZhNZQ8 GmrNslNvfH7j4dz+6wXPOCG1xY3gwp/oGhCUeDPn4N2U9Sc2baE3re8l+6H1K6XL l3kXSC1OdY4aq+OYPQVr7OzcdvJfw3KMp/ky7OEOshxiZMd1X6c580Ll1PLEXBZT BB2YNwxQNJOlcE+SViOkKMUCjRSgaAtu1ZVZfaSMkv9i9yCtl7klCr14Qce9obN5 jbfF6Hx2tryd3SDTXs1/fFX2HN+48wv10pCjjBX5XhAryMTpOL8h51gy5vJFhuen ic3CrRd++9iLLQXOM0fzBf8JjvMz291si9xmt2jq56YsEL0TYpDPwGSfsRCQz/+O lhoym7GYhUcyoGE5uwKlyarTNRyAjn9yt8ogLJPpQLU166l3Eig= =9OHs -----END PGP SIGNATURE----- --KKAq3uXxO7FEBPRXFJDQVUJWvN8MIWPch-- From nobody Tue Mar 28 15:52:11 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F002A127B73; Tue, 28 Mar 2017 15:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rDlbMhYfqG9l; Tue, 28 Mar 2017 15:52:07 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6D11271DF; Tue, 28 Mar 2017 15:52:07 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id d191so63966443ywe.2; Tue, 28 Mar 2017 15:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6bLAON3Snl086lWGX1x/rToDcKmNaN7PwMoGHL6kHVQ=; b=obt2SCQNxEl/iIw23mTkK6/eDgkZwwCx22Cj6QNTpguPRgH+yZ0tjuWjGUOagk0Rb6 73vgkKJ7UvYiRcTlE1ou2mZyQiTeepSOAIfkDSrehZPO2x5w1cdamidE6nutIJRBCVID rsD3aZEe2VhFC8JVyLMbLeSKkkr1Hlve7+JzN8f1y/F3CzaiaweSMnBY7fspMirCU4ZO kmYIQi/aFv9YZ3xo8jhVE0KXhXFyRPjgM+D6uhJ2IqBNitQBi7bLdIf1DFhMKvjYZWx6 L8LKD24u89AWZmhjuXd2gZ5DEX8UCbwMdS4tKLJaBlrnjVpdKE+yfq4DhXyCJoyiH+Dg UUQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6bLAON3Snl086lWGX1x/rToDcKmNaN7PwMoGHL6kHVQ=; b=c8nVcK7rxhijgrtts/cKgcg79C90xtCZeXsPQslc2hxTw0QOGmDM13+5bZXzBPQpGx ep0tXeKS+QUMobTxX1lvUl8LW75tICFS/nVfdOWQdMDEzQkemt/xKSgAVnDrEh+8VTRu uJ7gAbHHk7B5cx67y6Rgfleojuf88WwyZNGk/m/wjCEeo/hQMzjcCKXpLLtb3WC/7Sw4 qXWED915zs+bfozLA2eRHNVtd7jr4e3+lWKgiEWiE5ILje/8085nzF4H5/6I+Pvhs/eP wD/Gh0ctc/GQn8/n2HBP5lPtwUi3o/mZUexf+9vVMrA3UJ5r+F5h821qnVq03r5krYrh 94Fg== X-Gm-Message-State: AFeK/H0C5UnGgyI2xjEsY9t+1qxfO3f1Oe0X/TGduY5FRkbwzocSVvRxFEB6j1j60MsRdpKJ77nAwySiDmkbTw== X-Received: by 10.37.176.165 with SMTP id f37mr13379745ybj.182.1490741526781; Tue, 28 Mar 2017 15:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Tue, 28 Mar 2017 15:52:06 -0700 (PDT) In-Reply-To: <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> From: Spencer Dawkins at IETF Date: Tue, 28 Mar 2017 17:52:06 -0500 Message-ID: To: "Brian Trammell (IETF)" Cc: "adrian@olddog.co.uk" , Greg Mirsky , IPPM Chairs , ippm@ietf.org Content-Type: multipart/alternative; boundary=94eb2c1c4f2a281299054bd24f65 Archived-At: Subject: Re: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 22:52:10 -0000 --94eb2c1c4f2a281299054bd24f65 Content-Type: text/plain; charset=UTF-8 Dear All, On Tue, Mar 28, 2017 at 2:36 PM, Brian Trammell (IETF) wrote: > hi Adrian, Greg, all, > > As chair... Indeed, we could (should) have asked a more precise > question, but given that we didn't really have a more precise intention, > beyond to determine the sense of the room about "does IOAM (in some > guise) fit in IPPM", this is precisely the discussion we were hoping to > start. :) That's what I was hoping for, and I haven't seen much mailing list traffic on IOAM, so I'm assuming this was close to the first time many folks had seen it. So, all is proceeding according to plan. See comments below. > As an individual... > > What I'm hearing from Greg: The information elements (and presumably, > how they can be used by devices on path to perform hybrid measurements) > is/may be in scope for IPPM, anything binding this to particular overlay > technologies is only in scope for the working groups with responsibility > for those technologies. > > This seems reasonable to me. I will note that one reason that this set > of drafts has had a hard time finding a home is that it cuts across > areas in a way that it's pretty easy for each area to look at it and say > "interesting, maybe, related, maybe, but definitely not our problem". > Picking up a core *somewhere* then delegating more finely scoped work to > other WGs is one way to make this work. > > What I'm hearing from Adrian: It's too early to talk about data models, > we don't know what the problem is yet. Let's define the problem (i.e., > the metrics we want to define methodologies for, in IPPM terms) first, > so a good first step would be adopting the requirements document in IPPM. > > This seems reasonable to me, as well. Whether or not publishing a > requirements document happens, adopting it to work on it seems like a > good way for the WG to determine if it'd like to bring other documents > later. Even though Brian said "as an individual", I would defer to him and to Bill on the path forward, but (now I'M speaking as an individual), I think the question Mirja asked is critical to answer. I'd have to check the tape, but I thought I remembered Frank saying that this could be added by a host, and that would open up a lot of security questions, so understanding the scope would be an excellent thing. I expect that if Frank could say "added by tunnel encapsulators at encapsulation time with scope within a managed domain" (or not), that's what the working group would what to know. It's certainly what I was curious about ... Now, back to speaking as the responsible AD .... Please recognize that people aren't asking how IOAM could be used in theory, but how the IESG should evaluate the draft for publication. The various ADs would need to know where IOAM should be used, in order to evaluate transport considerations, security considerations, and (likely) operation considerations. Does that make sense? Thanks, Spencer > Cheers, > > Brian --94eb2c1c4f2a281299054bd24f65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,

On Tue, Mar 28, 2017 at 2:36 PM, Brian Trammell (IETF) <ietf@tra= mmell.ch> wrote:
hi Adria= n, Greg, all,

As chair... Indeed, we could (should) have asked a more precise
question, but given that we didn't really have a more precise intention= ,
beyond to determine the sense of the room about "does IOAM (in some guise) fit in IPPM", this is precisely the discussion we were hoping t= o
start. :)

That's what I was hoping for,= and I haven't seen much mailing list traffic on IOAM, so I'm assum= ing this was close to the first time many folks had seen it. So, all is pro= ceeding according to plan. See comments below.
=C2=A0
As an individual...

What I'm hearing from Greg: The information elements (and presumably, how they can be used by devices on path to perform hybrid measurements)
is/may be in scope for IPPM, anything binding this to particular overlay technologies is only in scope for the working groups with responsibility for those technologies.

This seems reasonable to me. I will note that one reason that this set
of drafts has had a hard time finding a home is that it cuts across
areas in a way that it's pretty easy for each area to look at it and sa= y
"interesting, maybe, related, maybe, but definitely not our problem&qu= ot;.
Picking up a core *somewhere* then delegating more finely scoped work to other WGs is one way to make this work.

What I'm hearing from Adrian: It's too early to talk about data mod= els,
we don't know what the problem is yet. Let's define the problem (i.= e.,
the metrics we want to define methodologies for, in IPPM terms) first,
so a good first step would be adopting the requirements document in IPPM.
This seems reasonable to me, as well. Whether or not publishing a
requirements document happens, adopting it to work on it seems like a
good way for the WG to determine if it'd like to bring other documents<= br> later.

Even though Brian said "as an i= ndividual", I would defer to him and to Bill on the path forward, but = (now I'M speaking as an individual), I think the question Mirja asked i= s critical to answer. I'd have to check the tape, but I thought I remem= bered Frank saying that this could be added by a host, and that would open = up a lot of security questions, so understanding the scope would be an exce= llent thing.

I expect that if Frank could say &quo= t;added by tunnel encapsulators at encapsulation time with scope within a m= anaged domain" (or not), that's what the working group would what = to know.

It's certainly what I was curious abo= ut ...

Now, back to speaking as the responsible AD= ....=C2=A0

Please recognize that people aren'= t asking how IOAM could be used in theory, but how the IESG should evaluate= the draft for publication.=C2=A0

The various ADs = would need to know where IOAM should be used, in order to evaluate transpor= t considerations, security considerations, and (likely) operation considera= tions.

Does that make sense?

<= div>Thanks,

Spencer
=C2=A0
Cheers,

Brian
--94eb2c1c4f2a281299054bd24f65-- From nobody Tue Mar 28 16:07:26 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C10E129456 for ; Tue, 28 Mar 2017 16:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 blfCoCA54-rc for ; Tue, 28 Mar 2017 16:07:23 -0700 (PDT) Received: from aws.hosed.org (aws.hosed.org [50.16.104.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF09128959 for ; Tue, 28 Mar 2017 16:07:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by aws.hosed.org (Postfix) with ESMTP id B3BCA80384 for ; Tue, 28 Mar 2017 19:07:20 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at aws.hosed.org Received: from aws.hosed.org ([127.0.0.1]) by localhost (aws.hosed.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwzoVUVg3GV2 for ; Tue, 28 Mar 2017 19:07:20 -0400 (EDT) Received: from [10.20.60.165] (ip-64-134-160-180.public.wayport.net [64.134.160.180]) by aws.hosed.org (Postfix) with ESMTPSA id 82D3580383 for ; Tue, 28 Mar 2017 19:07:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sarah B In-Reply-To: Date: Tue, 28 Mar 2017 16:07:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <04AC2BA0-6855-499C-B0F6-3E65CCBD1F28@encrypted.net> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> To: ippm@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [ippm] IOAM in IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:07:25 -0000 Given the lack of conversation on this, I thought I'd ask here, rather = than in the room at the time. I was a bit surprised at how many people were in favor of IOAM coming = into IPPM. I wanted to ask the authors this: the in-room presentation = started with the pitch that today, it's difficult to get a real read on = your true speed, because some SPs prioritize websites like = speedtest.net, and so you get false results (and often ludicrously = favorable results, I might add :)). If SPs are willing to prioritize the = probe traffic today, what makes us so sure they won't prioritize the = IOAM traffic? Or, not enable this information at each hop (as an option, = I realize) in the first place? Would that relegate the use(s) to tunnels = only, where the tunnels are effectively host originated/terminated? Thanks Sarah From nobody Tue Mar 28 16:38:47 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE7812708C for ; Tue, 28 Mar 2017 16:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 nn_uEvK7iTR9 for ; Tue, 28 Mar 2017 16:38:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45997126CE8 for ; Tue, 28 Mar 2017 16:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2507; q=dns/txt; s=iport; t=1490743803; x=1491953403; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KHTfIt3t4UeqICBLMPIKh1ZPypLS3Pthj6gXh2KDGBA=; b=kg80aKgKt3FfRqPzYVmt3NO4AHIQCe7z9Al4/SlijThu82oqBAngGajP e59N+Kd5CZBkINo2jyMiQAry5S1uLdlzu1f4/E/ZR/RhTZbSh63cmTAwa X/ppO+dnBhDdYQyTQOanCS0pEvxS8e0O8bwNL0UizjAAhTtkF8Ejm9b1v M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCp8NpY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjWqRUZVMgg4fC4V4AoMlPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQMBAWUHFwQCAQgRBAEBKAcnCxQJCAIEARIIiX8OsBGKTQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhk6Eb4o5BZAijD4BkkWCBYkBhjaTaQEfOIEEWRVBhlh1iEW?= =?us-ascii?q?BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,238,1486425600"; d="scan'208";a="225999660" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2017 23:30:02 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2SNU2gw006121 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 23:30:02 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Mar 2017 18:30:01 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Tue, 28 Mar 2017 18:30:01 -0500 From: "Frank Brockners (fbrockne)" To: Sarah B , "ippm@ietf.org" Thread-Topic: [ippm] IOAM in IPPM Thread-Index: AQHSqBgVDYtt1iWFLE2uT/eHVsz+j6Gq4V4A Date: Tue, 28 Mar 2017 23:30:01 +0000 Message-ID: <908d62c9c1bc4a06b13fe7ba5c9c7334@XCH-RCD-008.cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <04AC2BA0-6855-499C-B0F6-3E65CCBD1F28@encrypted.net> In-Reply-To: <04AC2BA0-6855-499C-B0F6-3E65CCBD1F28@encrypted.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.240.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] IOAM in IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:38:45 -0000 Hi Sarah, the whole point is that IOAM isn't probe traffic, but IOAM are data-fields = that are carried within your live user traffic. We could consider adding IO= AM meta-data to *all* your user traffic. If the SP would choose to prioriti= ze IOAM tagged traffic, then all traffic would be prioritized.=20 IOAM is a domain-focused feature, with "domain" being a set of network devi= ces under a single administration, e.g. an Enterprise campus using physical= connections between devices or an overlay network using virtual connection= s / tunnels for connectivity between devices. In the latter case the state= ment about tunneling applies. As a consequence, you could consider IOAM be = added at domain ingress and be removed at domain egress - so that it gives = you visibility into the QoE that your live user traffic observes. Note that= IOAM isn't exclusively focused on being added by tunnel endpoints. The ope= rator of a domain could also choose to have hosts insert the IOAM data-fiel= ds into the traffic. The draft-brockners-inband-oam-transport sketches out = a couple of ideas how IOAM data-fields could be transported by a variety of= transport protocols - though those should be considered examples only, bec= ause the definition would need to happen in the WGs which define those tran= sports. Frank -----Original Message----- From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Sarah B Sent: Dienstag, 28. M=E4rz 2017 18:07 To: ippm@ietf.org Subject: [ippm] IOAM in IPPM Given the lack of conversation on this, I thought I'd ask here, rather than= in the room at the time. I was a bit surprised at how many people were in favor of IOAM coming into = IPPM. I wanted to ask the authors this: the in-room presentation started wi= th the pitch that today, it's difficult to get a real read on your true spe= ed, because some SPs prioritize websites like speedtest.net, and so you get= false results (and often ludicrously favorable results, I might add :)). I= f SPs are willing to prioritize the probe traffic today, what makes us so s= ure they won't prioritize the IOAM traffic? Or, not enable this information= at each hop (as an option, I realize) in the first place? Would that releg= ate the use(s) to tunnels only, where the tunnels are effectively host orig= inated/terminated? Thanks Sarah _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From nobody Tue Mar 28 16:42:43 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6A2126579 for ; Tue, 28 Mar 2017 16:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 FAOsbe9ETDae for ; Tue, 28 Mar 2017 16:42:39 -0700 (PDT) Received: from aws.hosed.org (aws.hosed.org [50.16.104.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0431112708C for ; Tue, 28 Mar 2017 16:42:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by aws.hosed.org (Postfix) with ESMTP id 55AF180384; Tue, 28 Mar 2017 19:42:38 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at aws.hosed.org Received: from aws.hosed.org ([127.0.0.1]) by localhost (aws.hosed.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVUaDhviEHAb; Tue, 28 Mar 2017 19:42:38 -0400 (EDT) Received: from [10.20.60.165] (ip-64-134-160-180.public.wayport.net [64.134.160.180]) by aws.hosed.org (Postfix) with ESMTPSA id 1F71A80383; Tue, 28 Mar 2017 19:42:38 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sarah B In-Reply-To: <908d62c9c1bc4a06b13fe7ba5c9c7334@XCH-RCD-008.cisco.com> Date: Tue, 28 Mar 2017 16:42:37 -0700 Cc: "ippm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <04AC2BA0-6855-499C-B0F6-3E65CCBD1F28@encrypted.net> <908d62c9c1bc4a06b13fe7ba5c9c7334@XCH-RCD-008.cisco.com> To: "Frank Brockners (fbrockne)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] IOAM in IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:42:42 -0000 Hi Frank, > On Mar 28, 2017, at 4:30 PM, Frank Brockners (fbrockne) = wrote: >=20 > Hi Sarah, >=20 > the whole point is that IOAM isn't probe traffic, but IOAM are = data-fields that are carried within your live user traffic. We could = consider adding IOAM meta-data to *all* your user traffic. If the SP = would choose to prioritize IOAM tagged traffic, then all traffic would = be prioritized.=20 >=20 I totally understand your point, you don't consider this probe traffic, = thanks for clarifying. I do privately share the concern of exactly how = much data you're adding to *all* of my user traffic though, and I do = recall that you had a couple of options that didn't require that traffic = be added to each packet, which I'd encourage you to explore. > IOAM is a domain-focused feature, with "domain" being a set of network = devices under a single administration, e.g. an Enterprise campus using = physical connections between devices or an overlay network using virtual = connections / tunnels for connectivity between devices. In the latter = case the statement about tunneling applies. As a consequence, you could = consider IOAM be added at domain ingress and be removed at domain egress = - so that it gives you visibility into the QoE that your live user = traffic observes. Note that IOAM isn't exclusively focused on being = added by tunnel endpoints. The operator of a domain could also choose to = have hosts insert the IOAM data-fields into the traffic. The = draft-brockners-inband-oam-transport sketches out a couple of ideas how = IOAM data-fields could be transported by a variety of transport = protocols - though those should be considered examples only, because the = definition would need to happen in the WGs which define those = transports. >=20 I appreciate this point the more I read it; having it be domain = specific, rather than Internet-wide (which, honestly, I had inferred = from your presentation all the way to the end, when Brian actually asked = about this :)) Thanks for calling that out here, perhaps that'll help = folks who were uncomfortable with this work coming in. Finally, thanks for the quick replies, Frank. i appreciate them. Thanks, Sarah >=20 >=20 > -----Original Message----- > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Sarah B > Sent: Dienstag, 28. M=E4rz 2017 18:07 > To: ippm@ietf.org > Subject: [ippm] IOAM in IPPM >=20 > Given the lack of conversation on this, I thought I'd ask here, rather = than in the room at the time. >=20 > I was a bit surprised at how many people were in favor of IOAM coming = into IPPM. I wanted to ask the authors this: the in-room presentation = started with the pitch that today, it's difficult to get a real read on = your true speed, because some SPs prioritize websites like = speedtest.net, and so you get false results (and often ludicrously = favorable results, I might add :)). If SPs are willing to prioritize the = probe traffic today, what makes us so sure they won't prioritize the = IOAM traffic? Or, not enable this information at each hop (as an option, = I realize) in the first place? Would that relegate the use(s) to tunnels = only, where the tunnels are effectively host originated/terminated? >=20 > Thanks > Sarah >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm From nobody Wed Mar 29 06:37:43 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A8812951B; Wed, 29 Mar 2017 06:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 5zVpwhIq3UQf; Wed, 29 Mar 2017 06:37:39 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AF4129506; Wed, 29 Mar 2017 06:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24194; q=dns/txt; s=iport; t=1490794659; x=1492004259; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SFYHbe4AdwjxFOIX2O79F3bVYm+7NPs5zODhnVOSqOQ=; b=UOLiQqwqrz0Ws7pzGgGsRmrDKladqK5mJd01qmMA8Nfq1IVQQNvATpUu Satz8+BTUo8SW1jFGWuc02RMXAnq9gk9Z2oB9As5wf74qyurDugByJInM 8xOku5TNBtDqH2VQkltwOrXiBl0ZSM+5Xl3pA2xOLhb9otTJ4SHPonYHG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AQBLuNtY/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm48K2GBCweDW4oRkVCQHYMigg+CDoYiAhqDHz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQEDIwpBCxACAQgRBAEBKAMCAgIwFAkIAgQBDQUIigKtYIImikgBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdhk6Eb4UKglCCXwWcYAGKJoggggWFKooNk2k?= =?us-ascii?q?BHziBBFkVQYRYHYFjdYgpgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,241,1486425600"; d="scan'208,217";a="400761158" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 13:37:37 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2TDbbLM019237 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 13:37:37 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 08:37:37 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 08:37:37 -0500 From: "Frank Brockners (fbrockne)" To: Spencer Dawkins at IETF , "Brian Trammell (IETF)" CC: IPPM Chairs , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ALTeVSHHK04UeHAEB7HUBtbKGqypeAgAAD3ACAAAfTAIAAIx6AgAA2hgCAAJuA4A== Date: Wed, 29 Mar 2017 13:37:36 +0000 Message-ID: <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.219.95] Content-Type: multipart/alternative; boundary="_000_7e592d5c42d44db594dfdfbc76233e29XCHRCD008ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 13:37:42 -0000 --_000_7e592d5c42d44db594dfdfbc76233e29XCHRCD008ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpUaGUgZGlzY3Vzc2lvbiBsZWF2ZXMgbWUgYSBsaXR0bGUgY29uZnVzZWQuIFBlciBTcGVuY2Vy 4oCZcyBub3RlLCBpdCB3b3VsZCBpbmRlZWQgYmUgZ29vZCBpZiBCcmlhbiBhbmQgQmlsbCBjb3Vs ZCBwcm92aWRlIGd1aWRhbmNlIG9uIHRoZSBwYXRoIGZvcndhcmQuDQoNCk15IHJlY29sbGVjdGlv biBvZiB0aGUgZGlzY3Vzc2lvbiB3YXMgcHJldHR5IHN0cmFpZ2h0IGZvcndhcmQ6IFBlciB0aGUg bWVldGluZyBhZ2VuZGEsIHRoZSBwcmVzZW50YXRpb24gYW5kIHRoZSBkaXNjdXNzaW9uIGZvY3Vz ZWQgb24gZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YSwgZm9sbG93ZWQgYnkgYW4gYXNr IGZvciBhZG9wdGlvbi4gQXQgdGhlIGVuZCBvZiB0aGUgZGlzY3Vzc2lvbiB3ZSBoYWQgYSDigJxp biBmYXZvcuKAnSBodW0gZm9yIGFkb3B0aW9uLiBIZW5jZSBJTUhPIGFsbCB3ZeKAmWQgbmVlZCB0 byBkbyBpcyBjb25maXJtIHRoZSBkZWNpc2lvbiBvbiB0aGUgbGlzdC4NClRoZXJlIHdlcmUgc2V2 ZXJhbCBxdWVzdGlvbnMgcmVsYXRlZCB0byBzY29wZSBhbmQgYXBwbGljYWJpbGl0eSBpbiB0aGUg V0cgZGlzY3Vzc2lvbiDigJMgYW5kIGV2ZW4gbW9yZSByZWNlbnRseSBvbiB0aGUgbGlzdC4gVGhv c2UgY2FuIGVhc2lseSBiZSBhZGRyZXNzZWQgYnkgYWRkaW5nIHBhcmFncmFwaCBvbiBhcHBsaWNh YmlsaXR5IHRvIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEg4oCTIHRoZXJlIGlzbuKA mXQgYSBuZWVkIGZvciBhIGRlZGljYXRlZCByZXF1aXJlbWVudHMgZG9jdW1lbnQuIFRoaXMgcGFy YWdyYXBoIGNvdWxkIGxvYW4gZnJvbSBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1yZXF1aXJl bWVudHMg4oCTIGFuZCBjbGFyaWZ5IHRoaW5ncyBsaWtlIGZvciBleGFtcGxlIHRoZSBkb21haW4t c2NvcGUgb2YgSU9BTS4gU3RhcnRpbmcgb2ZmIHdpdGggZXhjbHVzaXZlbHkgd29ya2luZyBvbiBh IHJlcXVpcmVtZW50cyBkb2N1bWVudCB3b3VsZCBiZSBjb3VudGVyLXByb2R1Y3RpdmUuIEFzIHN0 YXRlZCBkdXJpbmcgdGhlIFdHIG1lZXRpbmcsIGNoaXAgbWFrZXJzIHB1dCBJT0FNIGludG8gc2ls aWNvbiBhcyB3ZSBzcGVhayDigJMgaGVuY2Ugbm93IGlzIHRoZSB0aW1lIHRvIHByb3ZpZGUgYXBw cm9wcmlhdGUgaW1wbGVtZW50YXRpb24gZ3VpZGFuY2UuDQoNCkFuZCBhbm90aGVyIG5vdGUgb24g dGhlIOKAnHdoZXJlIGNvdWxkIElPQU0gYmUgYXBwbGllZOKAnSBxdWVzdGlvbiBkaXNjdXNzZWQg ZnVydGhlciBiZWxvdzogUGVyIHdoYXQgSSBtZW50aW9uZWQgdG8gU2FyYWggb24gdGhlIG90aGVy IHRocmVhZDogSU9BTSBpcyBhIGRvbWFpbi1mb2N1c2VkIGZlYXR1cmUsIHdpdGggImRvbWFpbiIg YmVpbmcgYSBzZXQgb2YgbmV0d29yayBkZXZpY2VzIHVuZGVyIGEgc2luZ2xlIGFkbWluaXN0cmF0 aW9uLCBlLmcuIGFuIEVudGVycHJpc2UgY2FtcHVzIHVzaW5nIHBoeXNpY2FsIGNvbm5lY3Rpb25z IGJldHdlZW4gZGV2aWNlcyBvciBhbiBvdmVybGF5IG5ldHdvcmsgdXNpbmcgdmlydHVhbCBjb25u ZWN0aW9ucyAvIHR1bm5lbHMgZm9yIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGRldmljZXMuICBJbiB0 aGUgbGF0dGVyIGNhc2UgdGhlIHN0YXRlbWVudCBhYm91dCB0dW5uZWxpbmcgYXBwbGllcy4gQXMg YSBjb25zZXF1ZW5jZSwgeW91IGNvdWxkIGNvbnNpZGVyIElPQU0gYmUgYWRkZWQgYXQgZG9tYWlu IGluZ3Jlc3MgYW5kIGJlIHJlbW92ZWQgYXQgZG9tYWluIGVncmVzcyAtIHNvIHRoYXQgaXQgZ2l2 ZXMgeW91IHZpc2liaWxpdHkgaW50byB0aGUgUW9FIHRoYXQgeW91ciBsaXZlIHVzZXIgdHJhZmZp YyBvYnNlcnZlcy4gSU9BTSBpc24ndCBleGNsdXNpdmVseSBmb2N1c2VkIG9uIGJlaW5nIGFkZGVk IGJ5IHR1bm5lbCBlbmRwb2ludHMuIFRoZSBvcGVyYXRvciBvZiBhIGRvbWFpbiBjb3VsZCBhbHNv IGNob29zZSB0byBoYXZlIGhvc3RzIGluc2VydCB0aGUgSU9BTSBkYXRhLWZpZWxkcyBpbnRvIHRo ZSB0cmFmZmljLiBUaGUgZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tdHJhbnNwb3J0IHNrZXRj aGVzIG91dCBhIGNvdXBsZSBvZiBpZGVhcyBob3cgSU9BTSBkYXRhLWZpZWxkcyBjb3VsZCBiZSB0 cmFuc3BvcnRlZCBieSBhIHZhcmlldHkgb2YgdHJhbnNwb3J0IHByb3RvY29scyAtIHRob3VnaCB0 aG9zZSBzaG91bGQgYmUgY29uc2lkZXJlZCBleGFtcGxlcyBvbmx5LCBiZWNhdXNlIHRoZSBkZWZp bml0aW9uIHdvdWxkIG5lZWQgdG8gaGFwcGVuIGluIHRoZSBXR3Mgd2hpY2ggZGVmaW5lIHRob3Nl IHRyYW5zcG9ydHMuIFBlciB3aGF0IEkgc2FpZCBhYm92ZSwgd2XigJlkIG9idmlvdXNseSBpbmNs dWRlIHRob3NlIG5vdGVzIGludG8gdGhlIGFmb3JlIG1lbnRpb25lZCBwYXJhZ3JhcGggb24gYXBw bGljYWJpbGl0eS4NCg0KVGhvdWdodHM/DQoNClRoYW5rcywgRnJhbmsNCg0KRnJvbTogaXBwbSBb bWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNwZW5jZXIgRGF3a2lu cyBhdCBJRVRGDQpTZW50OiBEaWVuc3RhZywgMjguIE3DpHJ6IDIwMTcgMTc6NTINClRvOiBCcmlh biBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+DQpDYzogSVBQTSBDaGFpcnMgPGlw cG0tY2hhaXJzQGlldGYub3JnPjsgaXBwbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtpcHBtXSBW b3RlIGF0IElQUE0gc2Vzc2lvbg0KDQpEZWFyIEFsbCwNCg0KT24gVHVlLCBNYXIgMjgsIDIwMTcg YXQgMjozNiBQTSwgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPG1haWx0 bzppZXRmQHRyYW1tZWxsLmNoPj4gd3JvdGU6DQpoaSBBZHJpYW4sIEdyZWcsIGFsbCwNCg0KQXMg Y2hhaXIuLi4gSW5kZWVkLCB3ZSBjb3VsZCAoc2hvdWxkKSBoYXZlIGFza2VkIGEgbW9yZSBwcmVj aXNlDQpxdWVzdGlvbiwgYnV0IGdpdmVuIHRoYXQgd2UgZGlkbid0IHJlYWxseSBoYXZlIGEgbW9y ZSBwcmVjaXNlIGludGVudGlvbiwNCmJleW9uZCB0byBkZXRlcm1pbmUgdGhlIHNlbnNlIG9mIHRo ZSByb29tIGFib3V0ICJkb2VzIElPQU0gKGluIHNvbWUNCmd1aXNlKSBmaXQgaW4gSVBQTSIsIHRo aXMgaXMgcHJlY2lzZWx5IHRoZSBkaXNjdXNzaW9uIHdlIHdlcmUgaG9waW5nIHRvDQpzdGFydC4g OikNCg0KVGhhdCdzIHdoYXQgSSB3YXMgaG9waW5nIGZvciwgYW5kIEkgaGF2ZW4ndCBzZWVuIG11 Y2ggbWFpbGluZyBsaXN0IHRyYWZmaWMgb24gSU9BTSwgc28gSSdtIGFzc3VtaW5nIHRoaXMgd2Fz IGNsb3NlIHRvIHRoZSBmaXJzdCB0aW1lIG1hbnkgZm9sa3MgaGFkIHNlZW4gaXQuIFNvLCBhbGwg aXMgcHJvY2VlZGluZyBhY2NvcmRpbmcgdG8gcGxhbi4gU2VlIGNvbW1lbnRzIGJlbG93Lg0KDQpB cyBhbiBpbmRpdmlkdWFsLi4uDQoNCldoYXQgSSdtIGhlYXJpbmcgZnJvbSBHcmVnOiBUaGUgaW5m b3JtYXRpb24gZWxlbWVudHMgKGFuZCBwcmVzdW1hYmx5LA0KaG93IHRoZXkgY2FuIGJlIHVzZWQg YnkgZGV2aWNlcyBvbiBwYXRoIHRvIHBlcmZvcm0gaHlicmlkIG1lYXN1cmVtZW50cykNCmlzL21h eSBiZSBpbiBzY29wZSBmb3IgSVBQTSwgYW55dGhpbmcgYmluZGluZyB0aGlzIHRvIHBhcnRpY3Vs YXIgb3ZlcmxheQ0KdGVjaG5vbG9naWVzIGlzIG9ubHkgaW4gc2NvcGUgZm9yIHRoZSB3b3JraW5n IGdyb3VwcyB3aXRoIHJlc3BvbnNpYmlsaXR5DQpmb3IgdGhvc2UgdGVjaG5vbG9naWVzLg0KDQpU aGlzIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUuIEkgd2lsbCBub3RlIHRoYXQgb25lIHJlYXNvbiB0 aGF0IHRoaXMgc2V0DQpvZiBkcmFmdHMgaGFzIGhhZCBhIGhhcmQgdGltZSBmaW5kaW5nIGEgaG9t ZSBpcyB0aGF0IGl0IGN1dHMgYWNyb3NzDQphcmVhcyBpbiBhIHdheSB0aGF0IGl0J3MgcHJldHR5 IGVhc3kgZm9yIGVhY2ggYXJlYSB0byBsb29rIGF0IGl0IGFuZCBzYXkNCiJpbnRlcmVzdGluZywg bWF5YmUsIHJlbGF0ZWQsIG1heWJlLCBidXQgZGVmaW5pdGVseSBub3Qgb3VyIHByb2JsZW0iLg0K UGlja2luZyB1cCBhIGNvcmUgKnNvbWV3aGVyZSogdGhlbiBkZWxlZ2F0aW5nIG1vcmUgZmluZWx5 IHNjb3BlZCB3b3JrIHRvDQpvdGhlciBXR3MgaXMgb25lIHdheSB0byBtYWtlIHRoaXMgd29yay4N Cg0KV2hhdCBJJ20gaGVhcmluZyBmcm9tIEFkcmlhbjogSXQncyB0b28gZWFybHkgdG8gdGFsayBh Ym91dCBkYXRhIG1vZGVscywNCndlIGRvbid0IGtub3cgd2hhdCB0aGUgcHJvYmxlbSBpcyB5ZXQu IExldCdzIGRlZmluZSB0aGUgcHJvYmxlbSAoaS5lLiwNCnRoZSBtZXRyaWNzIHdlIHdhbnQgdG8g ZGVmaW5lIG1ldGhvZG9sb2dpZXMgZm9yLCBpbiBJUFBNIHRlcm1zKSBmaXJzdCwNCnNvIGEgZ29v ZCBmaXJzdCBzdGVwIHdvdWxkIGJlIGFkb3B0aW5nIHRoZSByZXF1aXJlbWVudHMgZG9jdW1lbnQg aW4gSVBQTS4NCg0KVGhpcyBzZWVtcyByZWFzb25hYmxlIHRvIG1lLCBhcyB3ZWxsLiBXaGV0aGVy IG9yIG5vdCBwdWJsaXNoaW5nIGENCnJlcXVpcmVtZW50cyBkb2N1bWVudCBoYXBwZW5zLCBhZG9w dGluZyBpdCB0byB3b3JrIG9uIGl0IHNlZW1zIGxpa2UgYQ0KZ29vZCB3YXkgZm9yIHRoZSBXRyB0 byBkZXRlcm1pbmUgaWYgaXQnZCBsaWtlIHRvIGJyaW5nIG90aGVyIGRvY3VtZW50cw0KbGF0ZXIu DQoNCkV2ZW4gdGhvdWdoIEJyaWFuIHNhaWQgImFzIGFuIGluZGl2aWR1YWwiLCBJIHdvdWxkIGRl ZmVyIHRvIGhpbSBhbmQgdG8gQmlsbCBvbiB0aGUgcGF0aCBmb3J3YXJkLCBidXQgKG5vdyBJJ00g c3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVhbCksIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIE1pcmphIGFz a2VkIGlzIGNyaXRpY2FsIHRvIGFuc3dlci4gSSdkIGhhdmUgdG8gY2hlY2sgdGhlIHRhcGUsIGJ1 dCBJIHRob3VnaHQgSSByZW1lbWJlcmVkIEZyYW5rIHNheWluZyB0aGF0IHRoaXMgY291bGQgYmUg YWRkZWQgYnkgYSBob3N0LCBhbmQgdGhhdCB3b3VsZCBvcGVuIHVwIGEgbG90IG9mIHNlY3VyaXR5 IHF1ZXN0aW9ucywgc28gdW5kZXJzdGFuZGluZyB0aGUgc2NvcGUgd291bGQgYmUgYW4gZXhjZWxs ZW50IHRoaW5nLg0KDQpJIGV4cGVjdCB0aGF0IGlmIEZyYW5rIGNvdWxkIHNheSAiYWRkZWQgYnkg dHVubmVsIGVuY2Fwc3VsYXRvcnMgYXQgZW5jYXBzdWxhdGlvbiB0aW1lIHdpdGggc2NvcGUgd2l0 aGluIGEgbWFuYWdlZCBkb21haW4iIChvciBub3QpLCB0aGF0J3Mgd2hhdCB0aGUgd29ya2luZyBn cm91cCB3b3VsZCB3aGF0IHRvIGtub3cuDQoNCkl0J3MgY2VydGFpbmx5IHdoYXQgSSB3YXMgY3Vy aW91cyBhYm91dCAuLi4NCg0KTm93LCBiYWNrIHRvIHNwZWFraW5nIGFzIHRoZSByZXNwb25zaWJs ZSBBRCAuLi4uDQoNClBsZWFzZSByZWNvZ25pemUgdGhhdCBwZW9wbGUgYXJlbid0IGFza2luZyBo b3cgSU9BTSBjb3VsZCBiZSB1c2VkIGluIHRoZW9yeSwgYnV0IGhvdyB0aGUgSUVTRyBzaG91bGQg ZXZhbHVhdGUgdGhlIGRyYWZ0IGZvciBwdWJsaWNhdGlvbi4NCg0KVGhlIHZhcmlvdXMgQURzIHdv dWxkIG5lZWQgdG8ga25vdyB3aGVyZSBJT0FNIHNob3VsZCBiZSB1c2VkLCBpbiBvcmRlciB0byBl dmFsdWF0ZSB0cmFuc3BvcnQgY29uc2lkZXJhdGlvbnMsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z LCBhbmQgKGxpa2VseSkgb3BlcmF0aW9uIGNvbnNpZGVyYXRpb25zLg0KDQpEb2VzIHRoYXQgbWFr ZSBzZW5zZT8NCg0KVGhhbmtzLA0KDQpTcGVuY2VyDQoNCkNoZWVycywNCg0KQnJpYW4NCg== --_000_7e592d5c42d44db594dfdfbc76233e29XCHRCD008ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5UaGUgZGlzY3Vzc2lvbiBsZWF2ZXMgbWUgYSBsaXR0bGUgY29uZnVzZWQuIFBl ciBTcGVuY2Vy4oCZcyBub3RlLCBpdCB3b3VsZCBpbmRlZWQgYmUgZ29vZCBpZiBCcmlhbiBhbmQg QmlsbCBjb3VsZCBwcm92aWRlDQogZ3VpZGFuY2Ugb24gdGhlIHBhdGggZm9yd2FyZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxicj4N Ck15IHJlY29sbGVjdGlvbiBvZiB0aGUgZGlzY3Vzc2lvbiB3YXMgcHJldHR5IHN0cmFpZ2h0IGZv cndhcmQ6IFBlciB0aGUgbWVldGluZyBhZ2VuZGEsIHRoZSBwcmVzZW50YXRpb24gYW5kIHRoZSBk aXNjdXNzaW9uIGZvY3VzZWQgb24gZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YSwgZm9s bG93ZWQgYnkgYW4gYXNrIGZvciBhZG9wdGlvbi4gQXQgdGhlIGVuZCBvZiB0aGUgZGlzY3Vzc2lv biB3ZSBoYWQgYSDigJxpbiBmYXZvcuKAnSBodW0gZm9yDQogYWRvcHRpb24uIEhlbmNlIElNSE8g YWxsIHdl4oCZZCBuZWVkIHRvIGRvIGlzIGNvbmZpcm0gdGhlIGRlY2lzaW9uIG9uIHRoZSBsaXN0 Ljxicj4NClRoZXJlIHdlcmUgc2V2ZXJhbCBxdWVzdGlvbnMgcmVsYXRlZCB0byBzY29wZSBhbmQg YXBwbGljYWJpbGl0eSBpbiB0aGUgV0cgZGlzY3Vzc2lvbiDigJMgYW5kIGV2ZW4gbW9yZSByZWNl bnRseSBvbiB0aGUgbGlzdC4gVGhvc2UgY2FuIGVhc2lseSBiZSBhZGRyZXNzZWQgYnkgYWRkaW5n IHBhcmFncmFwaCBvbiBhcHBsaWNhYmlsaXR5IHRvIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2Ft LWRhdGEg4oCTIHRoZXJlIGlzbuKAmXQgYSBuZWVkIGZvciBhIGRlZGljYXRlZA0KIHJlcXVpcmVt ZW50cyBkb2N1bWVudC4gVGhpcyBwYXJhZ3JhcGggY291bGQgbG9hbiBmcm9tIGRyYWZ0LWJyb2Nr bmVycy1pbmJhbmQtb2FtLXJlcXVpcmVtZW50cyDigJMgYW5kIGNsYXJpZnkgdGhpbmdzIGxpa2Ug Zm9yIGV4YW1wbGUgdGhlIGRvbWFpbi1zY29wZSBvZiBJT0FNLiBTdGFydGluZyBvZmYgd2l0aCBl eGNsdXNpdmVseSB3b3JraW5nIG9uIGEgcmVxdWlyZW1lbnRzIGRvY3VtZW50IHdvdWxkIGJlIGNv dW50ZXItcHJvZHVjdGl2ZS4gQXMgc3RhdGVkDQogZHVyaW5nIHRoZSBXRyBtZWV0aW5nLCBjaGlw IG1ha2VycyBwdXQgSU9BTSBpbnRvIHNpbGljb24gYXMgd2Ugc3BlYWsg4oCTIGhlbmNlIG5vdyBp cyB0aGUgdGltZSB0byBwcm92aWRlIGFwcHJvcHJpYXRlIGltcGxlbWVudGF0aW9uIGd1aWRhbmNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5BbmQgYW5vdGhlciBub3RlIG9uIHRoZSDigJx3aGVyZSBjb3VsZCBJT0FNIGJl IGFwcGxpZWTigJ0gcXVlc3Rpb24gZGlzY3Vzc2VkIGZ1cnRoZXIgYmVsb3c6IFBlciB3aGF0IEkg bWVudGlvbmVkIHRvIFNhcmFoDQogb24gdGhlIG90aGVyIHRocmVhZDogSU9BTSBpcyBhIGRvbWFp bi1mb2N1c2VkIGZlYXR1cmUsIHdpdGggJnF1b3Q7ZG9tYWluJnF1b3Q7IGJlaW5nIGEgc2V0IG9m IG5ldHdvcmsgZGV2aWNlcyB1bmRlciBhIHNpbmdsZSBhZG1pbmlzdHJhdGlvbiwgZS5nLiBhbiBF bnRlcnByaXNlIGNhbXB1cyB1c2luZyBwaHlzaWNhbCBjb25uZWN0aW9ucyBiZXR3ZWVuIGRldmlj ZXMgb3IgYW4gb3ZlcmxheSBuZXR3b3JrIHVzaW5nIHZpcnR1YWwgY29ubmVjdGlvbnMgLyB0dW5u ZWxzDQogZm9yIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGRldmljZXMuJm5ic3A7IEluIHRoZSBsYXR0 ZXIgY2FzZSB0aGUgc3RhdGVtZW50IGFib3V0IHR1bm5lbGluZyBhcHBsaWVzLiBBcyBhIGNvbnNl cXVlbmNlLCB5b3UgY291bGQgY29uc2lkZXIgSU9BTSBiZSBhZGRlZCBhdCBkb21haW4gaW5ncmVz cyBhbmQgYmUgcmVtb3ZlZCBhdCBkb21haW4gZWdyZXNzIC0gc28gdGhhdCBpdCBnaXZlcyB5b3Ug dmlzaWJpbGl0eSBpbnRvIHRoZSBRb0UgdGhhdCB5b3VyIGxpdmUNCiB1c2VyIHRyYWZmaWMgb2Jz ZXJ2ZXMuIElPQU0gaXNuJ3QgZXhjbHVzaXZlbHkgZm9jdXNlZCBvbiBiZWluZyBhZGRlZCBieSB0 dW5uZWwgZW5kcG9pbnRzLiBUaGUgb3BlcmF0b3Igb2YgYSBkb21haW4gY291bGQgYWxzbyBjaG9v c2UgdG8gaGF2ZSBob3N0cyBpbnNlcnQgdGhlIElPQU0gZGF0YS1maWVsZHMgaW50byB0aGUgdHJh ZmZpYy4gVGhlIGRyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLXRyYW5zcG9ydCBza2V0Y2hlcyBv dXQgYSBjb3VwbGUNCiBvZiBpZGVhcyBob3cgSU9BTSBkYXRhLWZpZWxkcyBjb3VsZCBiZSB0cmFu c3BvcnRlZCBieSBhIHZhcmlldHkgb2YgdHJhbnNwb3J0IHByb3RvY29scyAtIHRob3VnaCB0aG9z ZSBzaG91bGQgYmUgY29uc2lkZXJlZCBleGFtcGxlcyBvbmx5LCBiZWNhdXNlIHRoZSBkZWZpbml0 aW9uIHdvdWxkIG5lZWQgdG8gaGFwcGVuIGluIHRoZSBXR3Mgd2hpY2ggZGVmaW5lIHRob3NlIHRy YW5zcG9ydHMuIFBlciB3aGF0IEkgc2FpZCBhYm92ZSwgd2XigJlkIG9idmlvdXNseQ0KIGluY2x1 ZGUgdGhvc2Ugbm90ZXMgaW50byB0aGUgYWZvcmUgbWVudGlvbmVkIHBhcmFncmFwaCBvbiBhcHBs aWNhYmlsaXR5LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhvdWdodHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcywgRnJhbms8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u IEJlaGFsZiBPZiA8L2I+U3BlbmNlciBEYXdraW5zIGF0IElFVEY8YnI+DQo8Yj5TZW50OjwvYj4g RGllbnN0YWcsIDI4LiBNw6RyeiAyMDE3IDE3OjUyPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBUcmFt bWVsbCAoSUVURikgJmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJUFBN IENoYWlycyAmbHQ7aXBwbS1jaGFpcnNAaWV0Zi5vcmcmZ3Q7OyBpcHBtQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbaXBwbV0gVm90ZSBhdCBJUFBNIHNlc3Npb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIEFsbCw8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciAyOCwgMjAxNyBhdCAyOjM2IFBNLCBCcmlh biBUcmFtbWVsbCAoSUVURikgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQHRyYW1tZWxsLmNoIiB0 YXJnZXQ9Il9ibGFuayI+aWV0ZkB0cmFtbWVsbC5jaDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmhpIEFkcmlhbiwgR3JlZywg YWxsLDxicj4NCjxicj4NCkFzIGNoYWlyLi4uIEluZGVlZCwgd2UgY291bGQgKHNob3VsZCkgaGF2 ZSBhc2tlZCBhIG1vcmUgcHJlY2lzZTxicj4NCnF1ZXN0aW9uLCBidXQgZ2l2ZW4gdGhhdCB3ZSBk aWRuJ3QgcmVhbGx5IGhhdmUgYSBtb3JlIHByZWNpc2UgaW50ZW50aW9uLDxicj4NCmJleW9uZCB0 byBkZXRlcm1pbmUgdGhlIHNlbnNlIG9mIHRoZSByb29tIGFib3V0ICZxdW90O2RvZXMgSU9BTSAo aW4gc29tZTxicj4NCmd1aXNlKSBmaXQgaW4gSVBQTSZxdW90OywgdGhpcyBpcyBwcmVjaXNlbHkg dGhlIGRpc2N1c3Npb24gd2Ugd2VyZSBob3BpbmcgdG88YnI+DQpzdGFydC4gOik8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQn cyB3aGF0IEkgd2FzIGhvcGluZyBmb3IsIGFuZCBJIGhhdmVuJ3Qgc2VlbiBtdWNoIG1haWxpbmcg bGlzdCB0cmFmZmljIG9uIElPQU0sIHNvIEknbSBhc3N1bWluZyB0aGlzIHdhcyBjbG9zZSB0byB0 aGUgZmlyc3QgdGltZSBtYW55IGZvbGtzIGhhZCBzZWVuIGl0LiBTbywgYWxsIGlzIHByb2NlZWRp bmcgYWNjb3JkaW5nIHRvIHBsYW4uIFNlZSBjb21tZW50cyBiZWxvdy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYW4gaW5kaXZp ZHVhbC4uLjxicj4NCjxicj4NCldoYXQgSSdtIGhlYXJpbmcgZnJvbSBHcmVnOiBUaGUgaW5mb3Jt YXRpb24gZWxlbWVudHMgKGFuZCBwcmVzdW1hYmx5LDxicj4NCmhvdyB0aGV5IGNhbiBiZSB1c2Vk IGJ5IGRldmljZXMgb24gcGF0aCB0byBwZXJmb3JtIGh5YnJpZCBtZWFzdXJlbWVudHMpPGJyPg0K aXMvbWF5IGJlIGluIHNjb3BlIGZvciBJUFBNLCBhbnl0aGluZyBiaW5kaW5nIHRoaXMgdG8gcGFy dGljdWxhciBvdmVybGF5PGJyPg0KdGVjaG5vbG9naWVzIGlzIG9ubHkgaW4gc2NvcGUgZm9yIHRo ZSB3b3JraW5nIGdyb3VwcyB3aXRoIHJlc3BvbnNpYmlsaXR5PGJyPg0KZm9yIHRob3NlIHRlY2hu b2xvZ2llcy48YnI+DQo8YnI+DQpUaGlzIHNlZW1zIHJlYXNvbmFibGUgdG8gbWUuIEkgd2lsbCBu b3RlIHRoYXQgb25lIHJlYXNvbiB0aGF0IHRoaXMgc2V0PGJyPg0Kb2YgZHJhZnRzIGhhcyBoYWQg YSBoYXJkIHRpbWUgZmluZGluZyBhIGhvbWUgaXMgdGhhdCBpdCBjdXRzIGFjcm9zczxicj4NCmFy ZWFzIGluIGEgd2F5IHRoYXQgaXQncyBwcmV0dHkgZWFzeSBmb3IgZWFjaCBhcmVhIHRvIGxvb2sg YXQgaXQgYW5kIHNheTxicj4NCiZxdW90O2ludGVyZXN0aW5nLCBtYXliZSwgcmVsYXRlZCwgbWF5 YmUsIGJ1dCBkZWZpbml0ZWx5IG5vdCBvdXIgcHJvYmxlbSZxdW90Oy48YnI+DQpQaWNraW5nIHVw IGEgY29yZSAqc29tZXdoZXJlKiB0aGVuIGRlbGVnYXRpbmcgbW9yZSBmaW5lbHkgc2NvcGVkIHdv cmsgdG88YnI+DQpvdGhlciBXR3MgaXMgb25lIHdheSB0byBtYWtlIHRoaXMgd29yay48YnI+DQo8 YnI+DQpXaGF0IEknbSBoZWFyaW5nIGZyb20gQWRyaWFuOiBJdCdzIHRvbyBlYXJseSB0byB0YWxr IGFib3V0IGRhdGEgbW9kZWxzLDxicj4NCndlIGRvbid0IGtub3cgd2hhdCB0aGUgcHJvYmxlbSBp cyB5ZXQuIExldCdzIGRlZmluZSB0aGUgcHJvYmxlbSAoaS5lLiw8YnI+DQp0aGUgbWV0cmljcyB3 ZSB3YW50IHRvIGRlZmluZSBtZXRob2RvbG9naWVzIGZvciwgaW4gSVBQTSB0ZXJtcykgZmlyc3Qs PGJyPg0Kc28gYSBnb29kIGZpcnN0IHN0ZXAgd291bGQgYmUgYWRvcHRpbmcgdGhlIHJlcXVpcmVt ZW50cyBkb2N1bWVudCBpbiBJUFBNLjxicj4NCjxicj4NClRoaXMgc2VlbXMgcmVhc29uYWJsZSB0 byBtZSwgYXMgd2VsbC4gV2hldGhlciBvciBub3QgcHVibGlzaGluZyBhPGJyPg0KcmVxdWlyZW1l bnRzIGRvY3VtZW50IGhhcHBlbnMsIGFkb3B0aW5nIGl0IHRvIHdvcmsgb24gaXQgc2VlbXMgbGlr ZSBhPGJyPg0KZ29vZCB3YXkgZm9yIHRoZSBXRyB0byBkZXRlcm1pbmUgaWYgaXQnZCBsaWtlIHRv IGJyaW5nIG90aGVyIGRvY3VtZW50czxicj4NCmxhdGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlbiB0aG91Z2ggQnJpYW4g c2FpZCAmcXVvdDthcyBhbiBpbmRpdmlkdWFsJnF1b3Q7LCBJIHdvdWxkIGRlZmVyIHRvIGhpbSBh bmQgdG8gQmlsbCBvbiB0aGUgcGF0aCBmb3J3YXJkLCBidXQgKG5vdyBJJ00gc3BlYWtpbmcgYXMg YW4gaW5kaXZpZHVhbCksIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIE1pcmphIGFza2VkIGlzIGNyaXRp Y2FsIHRvIGFuc3dlci4gSSdkIGhhdmUgdG8gY2hlY2sgdGhlIHRhcGUsIGJ1dCBJIHRob3VnaHQN CiBJIHJlbWVtYmVyZWQgRnJhbmsgc2F5aW5nIHRoYXQgdGhpcyBjb3VsZCBiZSBhZGRlZCBieSBh IGhvc3QsIGFuZCB0aGF0IHdvdWxkIG9wZW4gdXAgYSBsb3Qgb2Ygc2VjdXJpdHkgcXVlc3Rpb25z LCBzbyB1bmRlcnN0YW5kaW5nIHRoZSBzY29wZSB3b3VsZCBiZSBhbiBleGNlbGxlbnQgdGhpbmcu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg ZXhwZWN0IHRoYXQgaWYgRnJhbmsgY291bGQgc2F5ICZxdW90O2FkZGVkIGJ5IHR1bm5lbCBlbmNh cHN1bGF0b3JzIGF0IGVuY2Fwc3VsYXRpb24gdGltZSB3aXRoIHNjb3BlIHdpdGhpbiBhIG1hbmFn ZWQgZG9tYWluJnF1b3Q7IChvciBub3QpLCB0aGF0J3Mgd2hhdCB0aGUgd29ya2luZyBncm91cCB3 b3VsZCB3aGF0IHRvIGtub3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0J3MgY2VydGFpbmx5IHdoYXQgSSB3YXMgY3VyaW91cyBhYm91dCAu Li48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Tm93LCBiYWNrIHRvIHNwZWFraW5nIGFzIHRoZSByZXNwb25zaWJsZSBBRCAuLi4uJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFz ZSByZWNvZ25pemUgdGhhdCBwZW9wbGUgYXJlbid0IGFza2luZyBob3cgSU9BTSBjb3VsZCBiZSB1 c2VkIGluIHRoZW9yeSwgYnV0IGhvdyB0aGUgSUVTRyBzaG91bGQgZXZhbHVhdGUgdGhlIGRyYWZ0 IGZvciBwdWJsaWNhdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHZhcmlvdXMgQURzIHdvdWxkIG5lZWQgdG8ga25vdyB3 aGVyZSBJT0FNIHNob3VsZCBiZSB1c2VkLCBpbiBvcmRlciB0byBldmFsdWF0ZSB0cmFuc3BvcnQg Y29uc2lkZXJhdGlvbnMsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBhbmQgKGxpa2VseSkgb3Bl cmF0aW9uIGNvbnNpZGVyYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIHRoYXQgbWFrZSBzZW5zZT88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVuY2VyPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNo ZWVycyw8YnI+DQo8YnI+DQpCcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7e592d5c42d44db594dfdfbc76233e29XCHRCD008ciscocom_-- From nobody Wed Mar 29 11:53:47 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34574129476 for ; Wed, 29 Mar 2017 11:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 M04m5pHCh4vn for ; Wed, 29 Mar 2017 11:53:43 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0041128708 for ; Wed, 29 Mar 2017 11:47:33 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id d191so17159845ywe.2 for ; Wed, 29 Mar 2017 11:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i0qYE8VLNFOw1gpPDrscbmlQV7WFhSegxPxNcflt4DY=; b=dk9DYMR8ri72PjPWO8VLKMTXwR+q88gj/OF//aFdXlAO/9xcVlaVsRsXdSqnevNxC5 3M6PhLgno+nxsTLFQOjkLMJ5rIhF+LvZg+H4KFgiscrL2dYweBnYTx65ZfCix9QR7b1W 9p3cARVvVCFEo0N8tHuNoIZJksKXWXob0BPESNITW6pty7fn/KppWqoRrYnKtxMXNB3A ZXuKI4mzQ8u6ExMQuHudOXMSnnanOEsy05bkHIM4bj2Ds7ycXHY536tGrnopGwE8pBNy 7hjQGpDocoAbGf4YR+24FBHcWl+XatjfppiVTUpbYzbpWd1Azk0BCoL4+c/KcT/Uw6/3 ptKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i0qYE8VLNFOw1gpPDrscbmlQV7WFhSegxPxNcflt4DY=; b=MxDdDSkG+5uW8uIYA7DIm2hEGJHWgT8A5ZqIbxS7V3Z88E9GmbOFr3z07Z+iGsUoN3 BE7bl1OzFqVsjt2KAcfjr7k5ntkoTHzGW0BfbtPtu+UwGcGkVJDkKAy6Lt2NgBA1JlFP 6J07eXMrsVtSnFJNeTH1PEMxduVzfioa891useiZlPLRIYXSrDPBp10HMOSzAs6qbGGg ZBBaknK37VwVXQsr3eWsRDgIPPedckLV7mXaJfeqUZPhYIcZYcTnZquhKGjo8/aRJYy4 tDnBziwBPz6Nw2LHDvMXus9AcNuayz4uKgBexyGlimoNwQDRTJLcXOlmzEARfjcxdzEF xjPw== X-Gm-Message-State: AFeK/H0HQ5xO6p4uy2ttZyiFXfygbB+xHlhMNS9W5S+naU2brkrHhEkOYuvM7NU6p3vdY5lzP72d61BswrzQUw== X-Received: by 10.37.176.165 with SMTP id f37mr1629146ybj.182.1490813253023; Wed, 29 Mar 2017 11:47:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Wed, 29 Mar 2017 11:47:32 -0700 (PDT) Received: by 10.37.73.129 with HTTP; Wed, 29 Mar 2017 11:47:32 -0700 (PDT) In-Reply-To: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <04AC2BA0-6855-499C-B0F6-3E65CCBD1F28@encrypted.net> <908d62c9c1bc4a06b13fe7ba5c9c7334@XCH-RCD-008.cisco.com> From: Spencer Dawkins at IETF Date: Wed, 29 Mar 2017 13:47:32 -0500 Message-ID: To: Sarah B Cc: ippm@ietf.org, "Frank Brockners (fbrockne)" Content-Type: multipart/alternative; boundary=94eb2c1c4f2a5f8253054be30272 Archived-At: Subject: Re: [ippm] IOAM in IPPM X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:53:45 -0000 --94eb2c1c4f2a5f8253054be30272 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll go back to "let the chairs chair IPPM" mode, but I do want to thank Frank for clarifying the scope for IOAM, and for quick responses. I expect that's a critical point for people who are looking at IOAM. Spencer On Mar 28, 2017 6:42 PM, "Sarah B" wrote: > Hi Frank, > > > On Mar 28, 2017, at 4:30 PM, Frank Brockners (fbrockne) < > fbrockne@cisco.com> wrote: > > > > Hi Sarah, > > > > the whole point is that IOAM isn't probe traffic, but IOAM are > data-fields that are carried within your live user traffic. We could > consider adding IOAM meta-data to *all* your user traffic. If the SP woul= d > choose to prioritize IOAM tagged traffic, then all traffic would be > prioritized. > > > > I totally understand your point, you don't consider this probe traffic, > thanks for clarifying. I do privately share the concern of exactly how mu= ch > data you're adding to *all* of my user traffic though, and I do recall th= at > you had a couple of options that didn't require that traffic be added to > each packet, which I'd encourage you to explore. > > > IOAM is a domain-focused feature, with "domain" being a set of network > devices under a single administration, e.g. an Enterprise campus using > physical connections between devices or an overlay network using virtual > connections / tunnels for connectivity between devices. In the latter ca= se > the statement about tunneling applies. As a consequence, you could consid= er > IOAM be added at domain ingress and be removed at domain egress - so that > it gives you visibility into the QoE that your live user traffic observes= . > Note that IOAM isn't exclusively focused on being added by tunnel > endpoints. The operator of a domain could also choose to have hosts inser= t > the IOAM data-fields into the traffic. The draft-brockners-inband-oam-tra= nsport > sketches out a couple of ideas how IOAM data-fields could be transported = by > a variety of transport protocols - though those should be considered > examples only, because the definition would need to happen in the WGs whi= ch > define those transports. > > > > I appreciate this point the more I read it; having it be domain specific, > rather than Internet-wide (which, honestly, I had inferred from your > presentation all the way to the end, when Brian actually asked about this > :)) Thanks for calling that out here, perhaps that'll help folks who were > uncomfortable with this work coming in. > > Finally, thanks for the quick replies, Frank. i appreciate them. > > Thanks, > Sarah > > > > > > > -----Original Message----- > > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Sarah B > > Sent: Dienstag, 28. M=C3=A4rz 2017 18:07 > > To: ippm@ietf.org > > Subject: [ippm] IOAM in IPPM > > > > Given the lack of conversation on this, I thought I'd ask here, rather > than in the room at the time. > > > > I was a bit surprised at how many people were in favor of IOAM coming > into IPPM. I wanted to ask the authors this: the in-room presentation > started with the pitch that today, it's difficult to get a real read on > your true speed, because some SPs prioritize websites like speedtest.net, > and so you get false results (and often ludicrously favorable results, I > might add :)). If SPs are willing to prioritize the probe traffic today, > what makes us so sure they won't prioritize the IOAM traffic? Or, not > enable this information at each hop (as an option, I realize) in the firs= t > place? Would that relegate the use(s) to tunnels only, where the tunnels > are effectively host originated/terminated? > > > > Thanks > > Sarah > > > > _______________________________________________ > > 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 > --94eb2c1c4f2a5f8253054be30272 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'll go back to "let the chairs chair IPPM"= mode, but I do want to thank Frank for clarifying the scope for IOAM, and = for quick responses.

I expect = that's a critical point for people who are looking at IOAM.

Spencer

On Mar 28, 2017 6:42 PM, &q= uot;Sarah B" <sbanks@encryp= ted.net> wrote:
Hi Frank,

> On Mar 28, 2017, at 4:30 PM, Frank Brockners (fbrockne) <fbrockne@cisco.com> wrote:
>
> Hi Sarah,
>
> the whole point is that IOAM isn't probe traffic, but IOAM are dat= a-fields that are carried within your live user traffic. We could consider = adding IOAM meta-data to *all* your user traffic. If the SP would choose to= prioritize IOAM tagged traffic, then all traffic would be prioritized.
>

I totally understand your point, you don't consider this probe traffic,= thanks for clarifying. I do privately share the concern of exactly how muc= h data you're adding to *all* of my user traffic though, and I do recal= l that you had a couple of options that didn't require that traffic be = added to each packet, which I'd encourage you to explore.

> IOAM is a domain-focused feature, with "domain" being a set = of network devices under a single administration, e.g. an Enterprise campus= using physical connections between devices or an overlay network using vir= tual connections / tunnels for connectivity between devices.=C2=A0 In the l= atter case the statement about tunneling applies. As a consequence, you cou= ld consider IOAM be added at domain ingress and be removed at domain egress= - so that it gives you visibility into the QoE that your live user traffic= observes. Note that IOAM isn't exclusively focused on being added by t= unnel endpoints. The operator of a domain could also choose to have hosts i= nsert the IOAM data-fields into the traffic. The draft-brockners-inband-oam= -transport sketches out a couple of ideas how IOAM data-fields could b= e transported by a variety of transport protocols - though those should be = considered examples only, because the definition would need to happen in th= e WGs which define those transports.
>

I appreciate this point the more I read it; having it be domain specific, r= ather than Internet-wide (which, honestly, I had inferred from your present= ation all the way to the end, when Brian actually asked about this :)) Than= ks for calling that out here, perhaps that'll help folks who were uncom= fortable with this work coming in.

Finally, thanks for the quick replies, Frank. i appreciate them.

Thanks,
Sarah

>
>
> -----Original Message-----
> From: ippm [mailto:ippm-bounc= es@ietf.org] On Behalf Of Sarah B
> Sent: Dienstag, 28. M=C3=A4rz 2017 18:07
> To: ippm@ietf.org
> Subject: [ippm] IOAM in IPPM
>
> Given the lack of conversation on this, I thought I'd ask here, ra= ther than in the room at the time.
>
> I was a bit surprised at how many people were in favor of IOAM coming = into IPPM. I wanted to ask the authors this: the in-room presentation start= ed with the pitch that today, it's difficult to get a real read on your= true speed, because some SPs prioritize websites like speedtest.net, and so= you get false results (and often ludicrously favorable results, I might ad= d :)). If SPs are willing to prioritize the probe traffic today, what makes= us so sure they won't prioritize the IOAM traffic? Or, not enable this= information at each hop (as an option, I realize) in the first place? Woul= d that relegate the use(s) to tunnels only, where the tunnels are effective= ly host originated/terminated?
>
> Thanks
> Sarah
>
> _______________________________________________
> 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
--94eb2c1c4f2a5f8253054be30272-- From nobody Wed Mar 29 12:51:10 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAC51297A5; Wed, 29 Mar 2017 12:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 yAEOuskQNET8; Wed, 29 Mar 2017 12:51:05 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02472129771; Wed, 29 Mar 2017 12:51:05 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B10AE340ECD; Wed, 29 Mar 2017 21:51:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/22542.21385); Wed, 29 Mar 2017 21:51:02 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 29 Mar 2017 21:51:02 +0200 (CEST) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 12990467; Wed, 29 Mar 2017 21:51:02 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5729EA4A-83D2-4CBB-B477-7CE588615BD6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> Date: Wed, 29 Mar 2017 21:51:01 +0200 Cc: Spencer Dawkins at IETF , IPPM Chairs , "ippm@ietf.org" Message-Id: <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> To: "Frank Brockners (fbrockne)" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 19:51:08 -0000 --Apple-Mail=_5729EA4A-83D2-4CBB-B477-7CE588615BD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Frank, all, Briefly -- I'm off for zero email vacation through mid-April in a few = hours... > On 29 Mar 2017, at 15:37, Frank Brockners (fbrockne) = wrote: >=20 >=20 > The discussion leaves me a little confused. Per Spencer=E2=80=99s = note, it would indeed be good if Brian and Bill could provide guidance = on the path forward. >=20 > My recollection of the discussion was pretty straight forward: Per the = meeting agenda, the presentation and the discussion focused on = draft-brockners-inband-oam-data, followed by an ask for adoption. At the = end of the discussion we had a =E2=80=9Cin favor=E2=80=9D hum for = adoption. Hence IMHO all we=E2=80=99d need to do is confirm the decision = on the list. =46rom what was reported to me -- audio wasn't great -- there was more = "opposed" hum than we generally like to hear in IPPM, which is why Bill = asked for the discussion on the dissent to move to the list. > There were several questions related to scope and applicability in the = WG discussion =E2=80=93 and even more recently on the list. Those can = easily be addressed by adding paragraph on applicability to = draft-brockners-inband-oam-data =E2=80=93 there isn=E2=80=99t a need for = a dedicated requirements document. I tend to agree with this, although "a paragraph" seems a little thin to = me. I think there were some valid points made in that discussion about = the scope of the proposal that should be addressed: is IOAM meant for = use tunnel-end-to-tunnel-end environment, end-host-to-end-host, within = a single network and/or across the Internet. What I would suggest is = adding a section to the data model draft on applicability and = assumptions about the environment -- both about the devices adding IOAM = signals to traffic as well as those consuming these signals from the = wire and analyzing them (possibly with the cooperation of devices not on = the wire) -- submitting a new revision, and we can run a more formal = adoption call on that. Cheers, Brian > This paragraph could loan from draft-brockners-inband-oam-requirements = =E2=80=93 and clarify things like for example the domain-scope of IOAM. = Starting off with exclusively working on a requirements document would = be counter-productive. As stated during the WG meeting, chip makers put = IOAM into silicon as we speak =E2=80=93 hence now is the time to provide = appropriate implementation guidance. >=20 > And another note on the =E2=80=9Cwhere could IOAM be applied=E2=80=9D = question discussed further below: Per what I mentioned to Sarah on the = other thread: IOAM is a domain-focused feature, with "domain" being a = set of network devices under a single administration, e.g. an Enterprise = campus using physical connections between devices or an overlay network = using virtual connections / tunnels for connectivity between devices. = In the latter case the statement about tunneling applies. As a = consequence, you could consider IOAM be added at domain ingress and be = removed at domain egress - so that it gives you visibility into the QoE = that your live user traffic observes. IOAM isn't exclusively focused on = being added by tunnel endpoints. The operator of a domain could also = choose to have hosts insert the IOAM data-fields into the traffic. The = draft-brockners-inband-oam-transport sketches out a couple of ideas how = IOAM data-fields could be transported by a variety of transport = protocols - though those should be considered examples only, because the = definition would need to happen in the WGs which define those = transports. Per what I said above, we=E2=80=99d obviously include those = notes into the afore mentioned paragraph on applicability. >=20 > Thoughts? >=20 > Thanks, Frank >=20 > From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Spencer Dawkins = at IETF > Sent: Dienstag, 28. M=C3=A4rz 2017 17:52 > To: Brian Trammell (IETF) > Cc: IPPM Chairs ; ippm@ietf.org > Subject: Re: [ippm] Vote at IPPM session >=20 > Dear All, >=20 > On Tue, Mar 28, 2017 at 2:36 PM, Brian Trammell (IETF) = wrote: > hi Adrian, Greg, all, >=20 > As chair... Indeed, we could (should) have asked a more precise > question, but given that we didn't really have a more precise = intention, > beyond to determine the sense of the room about "does IOAM (in some > guise) fit in IPPM", this is precisely the discussion we were hoping = to > start. :) >=20 > That's what I was hoping for, and I haven't seen much mailing list = traffic on IOAM, so I'm assuming this was close to the first time many = folks had seen it. So, all is proceeding according to plan. See comments = below. >=20 > As an individual... >=20 > What I'm hearing from Greg: The information elements (and presumably, > how they can be used by devices on path to perform hybrid = measurements) > is/may be in scope for IPPM, anything binding this to particular = overlay > technologies is only in scope for the working groups with = responsibility > for those technologies. >=20 > This seems reasonable to me. I will note that one reason that this set > of drafts has had a hard time finding a home is that it cuts across > areas in a way that it's pretty easy for each area to look at it and = say > "interesting, maybe, related, maybe, but definitely not our problem". > Picking up a core *somewhere* then delegating more finely scoped work = to > other WGs is one way to make this work. >=20 > What I'm hearing from Adrian: It's too early to talk about data = models, > we don't know what the problem is yet. Let's define the problem (i.e., > the metrics we want to define methodologies for, in IPPM terms) first, > so a good first step would be adopting the requirements document in = IPPM. >=20 > This seems reasonable to me, as well. Whether or not publishing a > requirements document happens, adopting it to work on it seems like a > good way for the WG to determine if it'd like to bring other documents > later. >=20 > Even though Brian said "as an individual", I would defer to him and to = Bill on the path forward, but (now I'M speaking as an individual), I = think the question Mirja asked is critical to answer. I'd have to check = the tape, but I thought I remembered Frank saying that this could be = added by a host, and that would open up a lot of security questions, so = understanding the scope would be an excellent thing. >=20 > I expect that if Frank could say "added by tunnel encapsulators at = encapsulation time with scope within a managed domain" (or not), that's = what the working group would what to know. >=20 > It's certainly what I was curious about ... >=20 > Now, back to speaking as the responsible AD .... >=20 > Please recognize that people aren't asking how IOAM could be used in = theory, but how the IESG should evaluate the draft for publication. >=20 > The various ADs would need to know where IOAM should be used, in order = to evaluate transport considerations, security considerations, and = (likely) operation considerations. >=20 > Does that make sense? >=20 > Thanks, >=20 > Spencer >=20 > Cheers, >=20 > Brian --Apple-Mail=_5729EA4A-83D2-4CBB-B477-7CE588615BD6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY3BAmAAoJEIoSt78L6kajvzwP/i/Gqi3rzmKTSzb1jbt6cnte SFyn6fV3rbgavyv4CrF7KcICm6kBR/gYB/3LE7E7hIYfPIq2k2wgDlJGXpaHBChx ePrRyyLqVMdYfvjWo6FwsCLbV1MacMuln/EmQvtPMYu2EvZdWPGr1raHZnm4HWk/ 0b+/31IagDFqcQHq54mytbtFmBeOOBP18C43DuVVh+ERLkgswnZFaDrZpjXhhrVA rWhrrPRBRCxjhsQGOCnA1ng7ZDyLpWpadDhAepD5CcKBCh+aACYGIjogokezFba9 EaOCwT1AR8KN7jnJlxn79vB4JzcB0BJM5eg8ZXkohYmyY58Vr83rcNyfBKB0Gq6P XoH2OqDyGlhlo2hqYcASzRo0v/wPW5p6Vr12mWSWRkArGno0LjS7IzJEg8DI7cjx 2ELUQHOzZtwjs9u3yC59m5TNeSTBKtZ5RbrMt5Ik724UKEgjBXkSprlRj2NYKFB/ pR4a1xDFif+wwK3YNYnQnh4E88QTGq5AHv5WfdHBWC2H5IEetp5uXC8foWFsDRyZ 9CEF7aNBcFxG3QRWlofLW3N3x1KXV5sJ/iaLWotIbgtU5tNiG5vcWprPyAbpIMtF BsBT3B/WaOLMtQLfHks6FXrl7OqsvCeBjcqVQho6Rvv/1NBU5bABf6dxskDXCOlD HeDiYBWK+yF30qk9Mu4D =DndR -----END PGP SIGNATURE----- --Apple-Mail=_5729EA4A-83D2-4CBB-B477-7CE588615BD6-- From nobody Wed Mar 29 14:32:22 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B1012958B; Wed, 29 Mar 2017 14:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 FiRvOgEXQg_C; Wed, 29 Mar 2017 14:32:18 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B47F1250B8; Wed, 29 Mar 2017 14:32:16 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2TLWB0s013903; Wed, 29 Mar 2017 22:32:11 +0100 Received: from 950129200 (dhcp-8535.meeting.ietf.org [31.133.133.53]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2TLW1NP013795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2017 22:32:02 +0100 Reply-To: From: "Adrian Farrel" To: "'Brian Trammell \(IETF\)'" , "'Frank Brockners \(fbrockne\)'" Cc: "'IPPM Chairs'" , References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> In-Reply-To: <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> Date: Wed, 29 Mar 2017 22:32:00 +0100 Message-ID: <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3Ooq+i0V2uDTKsntzdbDryWnJDQIGbTuQAhzFMcMCAqiNpgJZUHRiAczg8HQCom8n2QGF54TAoG91gnA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22974.003 X-TM-AS-Result: No--11.581-10.0-31-10 X-imss-scan-details: No--11.581-10.0-31-10 X-TMASE-MatchedRID: VfovoVrt/oYn2WEbWzq9rUhEDfw/93BuxOOHiw0XgcvSgap63qByoW+W 1KbirlTb1oyFfXes1rZEQfoWZDUvaCVqTewNlt0eBEfU2vugRF1QCOsAlaxN722/j5pTTlX7nng bQsJIxoLfdIm/DvzgaqfYiXYgUNX3XBtnhjLNB/q4jAucHcCqnS3S35ohUu37tRXhV8npIHR4gn vHVaEF6HZkGgTvfibxIueRwZyQ+Q+hmMaez4U1AMu00lnG8+PWGSqdEmeD/nVUvqB5o/LqczCiN p+GjrnSlpVgGejXNtQpT6x9CMQdU+VHGbcDbAq6gxsfzkNRlfLdB/CxWTRRu25FeHtsUoHugr+I EVKt5PpNqm9gFAgeYaE8VsxoPl44HEnYvifG4jcchXTZ3Wukbw== Archived-At: Subject: Re: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:32:21 -0000 > > There were several questions related to scope and applicability in = the WG > discussion =E2=80=93 and even more recently on the list. Those can = easily be addressed by > adding paragraph on applicability to draft-brockners-inband-oam-data = =E2=80=93 there > isn=E2=80=99t a need for a dedicated requirements document. >=20 > I tend to agree with this, although "a paragraph" seems a little thin = to me. I think > there were some valid points made in that discussion about the scope = of the > proposal that should be addressed: is IOAM meant for use = tunnel-end-to-tunnel- > end environment, end-host-to-end-host, within a single network and/or = across > the Internet. What I would suggest is adding a section to the data = model draft on > applicability and assumptions about the environment -- both about the = devices > adding IOAM signals to traffic as well as those consuming these = signals from the > wire and analyzing them (possibly with the cooperation of devices not = on the > wire) -- submitting a new revision, and we can run a more formal = adoption call on > that. Although I was one of the people raising the "need" for the scope and = requirements, I don't have a strong leading on whether this needs to be = in a separate document on folded into the data format document. So = Brian's proposal would work for me. Thus, I'd love to see this scoping text drafted and floated to the list = as an email or in a revision of the data format document. Cheers, Adrian From nobody Wed Mar 29 16:11:37 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694931296BF; Wed, 29 Mar 2017 16:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.396 X-Spam-Level: X-Spam-Status: No, score=-5.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 CwZko1TWB4lP; Wed, 29 Mar 2017 16:11:33 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 4155C129674; Wed, 29 Mar 2017 16:11:33 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v2TN5txo038963; Wed, 29 Mar 2017 19:11:30 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 29gjwpx7ah-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Mar 2017 19:11:29 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2TNBS3u019476; Wed, 29 Mar 2017 19:11:29 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v2TNBEI8019300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Mar 2017 19:11:22 -0400 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 29 Mar 2017 23:10:57 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2TNAvSl011955; Wed, 29 Mar 2017 18:10:57 -0500 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id v2TNAqZW011720; Wed, 29 Mar 2017 18:10:53 -0500 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id 450F6F059B; Wed, 29 Mar 2017 19:10:52 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0319.002; Wed, 29 Mar 2017 19:10:52 -0400 From: "MORTON, ALFRED C (AL)" To: "adrian@olddog.co.uk" , "'Brian Trammell (IETF)'" , "'Frank Brockners (fbrockne)'" CC: "'IPPM Chairs'" , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ANywb7w7Y7CUWYR5PjBqbNA6GqudOAgAAD3QCAAAfSAIAAIx6AgAA2hgCAAPdoAIAAaFWAgAAcNwD//8lsgA== Date: Wed, 29 Mar 2017 23:10:51 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> In-Reply-To: <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.130.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-29_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703290193 Archived-At: Subject: Re: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 23:11:35 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHBtIFttYWlsdG86aXBwbS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbA0KPiBTZW50OiBXZWRu ZXNkYXksIE1hcmNoIDI5LCAyMDE3IDU6MzIgUE0NCj4gVG86ICdCcmlhbiBUcmFtbWVsbCAoSUVU RiknOyAnRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSknDQo+IENjOiAnSVBQTSBDaGFpcnMnOyBp cHBtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbaXBwbV0gVm90ZSBhdCBJUFBNIHNlc3Npb24N Cj4gDQo+ID4gPiBUaGVyZSB3ZXJlIHNldmVyYWwgcXVlc3Rpb25zIHJlbGF0ZWQgdG8gc2NvcGUg YW5kIGFwcGxpY2FiaWxpdHkgaW4gdGhlIFdHDQo+ID4gZGlzY3Vzc2lvbiDigJMgYW5kIGV2ZW4g bW9yZSByZWNlbnRseSBvbiB0aGUgbGlzdC4gVGhvc2UgY2FuIGVhc2lseSBiZSBhZGRyZXNzZWQg YnkNCj4gPiBhZGRpbmcgcGFyYWdyYXBoIG9uIGFwcGxpY2FiaWxpdHkgdG8gZHJhZnQtYnJvY2tu ZXJzLWluYmFuZC1vYW0tZGF0YSDigJMgdGhlcmUNCj4gPiBpc27igJl0IGEgbmVlZCBmb3IgYSBk ZWRpY2F0ZWQgcmVxdWlyZW1lbnRzIGRvY3VtZW50Lg0KPiA+DQo+ID4gSSB0ZW5kIHRvIGFncmVl IHdpdGggdGhpcywgYWx0aG91Z2ggImEgcGFyYWdyYXBoIiBzZWVtcyBhIGxpdHRsZSB0aGluIHRv IG1lLiBJIHRoaW5rDQo+ID4gdGhlcmUgd2VyZSBzb21lIHZhbGlkIHBvaW50cyBtYWRlIGluIHRo YXQgZGlzY3Vzc2lvbiBhYm91dCB0aGUgc2NvcGUgb2YgdGhlDQo+ID4gcHJvcG9zYWwgdGhhdCBz aG91bGQgYmUgYWRkcmVzc2VkOiBpcyBJT0FNIG1lYW50IGZvciB1c2UgdHVubmVsLWVuZC0gdG8t dHVubmVsLQ0KPiA+IGVuZCBlbnZpcm9ubWVudCwgIGVuZC1ob3N0LXRvLWVuZC1ob3N0LCB3aXRo aW4gYSBzaW5nbGUgbmV0d29yayBhbmQvb3IgYWNyb3NzDQo+ID4gdGhlIEludGVybmV0LiAgV2hh dCBJIHdvdWxkIHN1Z2dlc3QgaXMgYWRkaW5nIGEgc2VjdGlvbiB0byB0aGUgZGF0YSBtb2RlbCBk cmFmdCBvbg0KPiA+IGFwcGxpY2FiaWxpdHkgYW5kIGFzc3VtcHRpb25zIGFib3V0IHRoZSBlbnZp cm9ubWVudCAtLSBib3RoIGFib3V0IHRoZSBkZXZpY2VzDQo+ID4gYWRkaW5nIElPQU0gc2lnbmFs cyB0byB0cmFmZmljIGFzIHdlbGwgYXMgdGhvc2UgY29uc3VtaW5nIHRoZXNlIHNpZ25hbHMgZnJv bSB0aGUNCj4gPiB3aXJlIGFuZCBhbmFseXppbmcgdGhlbSAocG9zc2libHkgd2l0aCB0aGUgY29v cGVyYXRpb24gb2YgZGV2aWNlcyBub3Qgb24gdGhlDQo+ID4gd2lyZSkgLS0gc3VibWl0dGluZyBh IG5ldyByZXZpc2lvbiwgYW5kIHdlIGNhbiBydW4gYSBtb3JlIGZvcm1hbCBhZG9wdGlvbiBjYWxs IG9uDQo+ID4gdGhhdC4NCj4gDQo+IEFsdGhvdWdoIEkgd2FzIG9uZSBvZiB0aGUgcGVvcGxlIHJh aXNpbmcgdGhlICJuZWVkIiBmb3IgdGhlIHNjb3BlIGFuZA0KPiByZXF1aXJlbWVudHMsIEkgZG9u J3QgaGF2ZSBhIHN0cm9uZyBsZWFkaW5nIG9uIHdoZXRoZXIgdGhpcyBuZWVkcyB0byBiZQ0KPiBp biBhIHNlcGFyYXRlIGRvY3VtZW50IG9uIGZvbGRlZCBpbnRvIHRoZSBkYXRhIGZvcm1hdCBkb2N1 bWVudC4gU28NCj4gQnJpYW4ncyBwcm9wb3NhbCB3b3VsZCB3b3JrIGZvciBtZS4NCj4gDQo+IFRo dXMsIEknZCBsb3ZlIHRvIHNlZSB0aGlzIHNjb3BpbmcgdGV4dCBkcmFmdGVkIGFuZCBmbG9hdGVk IHRvIHRoZSBsaXN0DQo+IGFzIGFuIGVtYWlsIG9yIGluIGEgcmV2aXNpb24gb2YgdGhlIGRhdGEg Zm9ybWF0IGRvY3VtZW50Lg0KPiANCj4gQ2hlZXJzLA0KPiBBZHJpYW4NCltBQ01dIA0KDQorMSBm b3IgYWRkaW5nIGEgU2NvcGUgc2VjdGlvbiB0bw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDINCg0KSSBmZWx0IHRoYXQgSSB1bmRl cnN0b29kIHRoZSBzY29wZSBnb2luZyBpbnRvIHRoZSBkaXNjdXNzaW9uIE1vbmRheQ0KYW5kIHRo ZSBhcHBsaWNhYmxlIChyZXN0cmljdGVkKSBkb21haW4gKEkgZGlkIHRoZSBob21ld29yaywgDQp0 aGUgc2luZ2xlIGRyYWZ0IEZyYW5rIGludHJvZHVjZWQgb24gdGhlIG1haWxpbmcgbGlzdCB3YXMg WzBdICkuDQoNClNvbWUgYWRkaXRpb25hbCBxdWVzdGlvbnMgaGF2ZSBiZWVuIHJhaXNlZCAoZS5n LiwgIndoZXJlIHdpbGwgDQpPQU0gYmUgaW5zZXJ0ZWQgYW5kIHJlbW92ZWQ/IikgYW5kIEknZCBs aWtlIHRvIHNlZSB0aG9zZSBpdGVtcyANCnNvcnRlZC1vdXQgYmVmb3JlIHdlIGdvIHZlcnkgZmFy ICh0aGUgYWR2YW50YWdlIG9mIHdpZGVyIHJldmlldykuDQoNClRoZSByZXF1aXJlbWVudHMgZHJh ZnQgb25seSBjYW1lLXVwIHdoZW4gSSBhc2tlZCBzb21lIHF1ZXN0aW9ucw0Kb24gdGhlIGxpc3Qu IEZyYW5rIG1lbnRpb25lZCB0aGF0IHRoZSBvdXIgbGlzdCBkaXNjdXNzaW9uIG9uIGVxdWl2YWxl bnQgDQp0cmVhdG1lbnQgb2YgT0FNICYgbm9uLU9BTSBwYWNrZXRzICgiY2xhc3MgQyIpIHdhcyBh ZGRlZCB0byB0aGUNCnJlcXVpcmVtZW50cyBkb2N1bWVudCwgYW5kIHRoYXQgc2hvdWxkIG1vdmUg dG8gLW9hbS1kYXRhLSB0b28uDQogDQpJdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYSB2ZXJzaW9u IG9mIHRoZSBzY29wZSB0byByZXZpZXcgQVNBUC4NCg0KdGhhbmtzIGFuZCByZWdhcmRzLA0KQWwN Cg0KWzBdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icm9ja25lcnMtaW5iYW5k LW9hbS1kYXRhLTAyDQoNCg0KDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBpcHBtIG1haWxpbmcgbGlzdA0KPiBpcHBtQGlldGYub3JnDQo+ IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lwcG0mZD1Ed0lHYVEmYz1MRllaLQ0KPiBv OV9IVU1lTVRTUWljdmpJZyZyPU9mc1N1OGtUSWx0VnlEMW9MNzJjQncmbT1HYXF1Y3p0SzU3ZlRq M3Z5WWNNbkhHOVlLTDENCj4gdFZrQVNRNUMzS2g2M29vQSZzPU1lc002QkZaeUVrVlBxc0dxMkhv NExLU19BNG50ZjVYNWhMMFN4MFJzZGMmZT0NCg== From nobody Fri Mar 31 06:46:18 2017 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA03712984A; Fri, 31 Mar 2017 06:46:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jouni Korhonen To: Cc: draft-ietf-ippm-6man-pdm-option.all@ietf.org, ietf@ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149096796486.21620.15409836640558971168@ietfa.amsl.com> Date: Fri, 31 Mar 2017 06:46:04 -0700 Archived-At: Subject: [ippm] Genart telechat review of draft-ietf-ippm-6man-pdm-option-09 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 13:46:05 -0000 Reviewer: Jouni Korhonen Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-ippm-6man-pdm-option-?? Reviewer: Jouni Korhonen Review Date: 2017-03-31 IETF LC End Date: 2016-09-28 IESG Telechat date: 2017-04-13 Summary: Ready for publication. I did review earlier version of the document and the comments I raised back them have now been addressed to an adequate level. Major issues: None. Minor issues: None. Nits/editorial comments: None. From nobody Fri Mar 31 07:27:53 2017 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E67B12986E; Fri, 31 Mar 2017 07:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 L3_vgC8zocfx; Fri, 31 Mar 2017 07:27:49 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2076129876; Fri, 31 Mar 2017 07:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9742; q=dns/txt; s=iport; t=1490970469; x=1492180069; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=amATrgHWAxuLxNikGHDrclrss29r2Hqtpb2ExnzlE/k=; b=ev443+eeWoalvW1eP6pCDnENqG96bKjyk0fR9PerTSwuHLJmWle4aNdb c91MXNywU2OUmcBP1zt4xzcc+ZyL+yemQ8Woh4O3kHQjXsteiTSRJfsQq JRRQza7hyDosAcEyr0dll0v7AQNBpEdI+rSlshhGmN3qK85G2Tyl+aK+r 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAQCbZt5Y/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgykrYYELB4NbihKRVZNBgg+CDiqCQoM2AhqDLD8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQEDIxEzBwsMBAIBCBEEAQEDAhESAwICAjAUAQgIAgQBDQUIigUOr?= =?us-ascii?q?WOCJopcAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VDhG+DF4EPEQFbgkeCXwW?= =?us-ascii?q?JJ4xbhmgBhnyLSoIGiiGFHIhcixQBHzh9CFsVQYRZHYFjdQGHLIEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,252,1486425600"; d="scan'208";a="401823953" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Mar 2017 14:27:48 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2VERmp9020456 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 14:27:48 GMT Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 09:27:47 -0500 Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 09:27:47 -0500 From: "Frank Brockners (fbrockne)" To: "MORTON, ALFRED C (AL)" , "adrian@olddog.co.uk" , "'Brian Trammell (IETF)'" CC: "'IPPM Chairs'" , "ippm@ietf.org" Thread-Topic: [ippm] Vote at IPPM session Thread-Index: AQHSp+ALTeVSHHK04UeHAEB7HUBtbKGqypeAgAAD3ACAAAfTAIAAIx6AgAA2hgCAAJuA4IAAxDyAgAAcNwCAABufgIAA1nmg Date: Fri, 31 Mar 2017 14:27:47 +0000 Message-ID: References: <830D269B-62A1-4782-8AFE-C2910F908BFF@trammell.ch> <01fa01d2a7e9$1c65d520$55317f60$@olddog.co.uk> <8168bd84-88f4-c40b-7150-844b463f6612@trammell.ch> <7e592d5c42d44db594dfdfbc76233e29@XCH-RCD-008.cisco.com> <3E70CF9A-5A09-419B-B330-F9B854E01539@trammell.ch> <01c801d2a8d3$eb6d2450$c2476cf0$@olddog.co.uk> <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF25F3D4C0@njmtexg5.research.att.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.226.89] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [ippm] Vote at IPPM session X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 14:27:52 -0000 VGhhbmtzIGZvciB0aGUgc3VnZ2VzdGlvbnMgYW5kIGNvbW1lbnRzLiBXZSd2ZSBwb3N0ZWQgYSBu ZXcgcmV2aXNpb24gb2YgZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS4NCmh0dHBzOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LWJyb2NrbmVycy1pbmJhbmQtb2FtLWRhdGEtMDQudHh0IGlu Y2x1ZGVzIHNlY3Rpb24gMyBvbiBTY29wZSwgQXBwbGljYWJpbGl0eSwgYW5kIEFzc3VtcHRpb25z LCBjYXB0dXJpbmcgdGhlIGRpc2N1c3Npb24gd2UgaGFkIGluIHRoZSBXRyBtZWV0aW5nIGFuZCBv biB0aGUgbGlzdC4gV2UndmUgYWxzbyB1cGRhdGVkIHRoZSBpbnRyb2R1Y3Rpb24gdG8gcmVmZXIg dG8gUkZDNzc5OSBhbmQgY2xhc3NpZnkgaW4tc2l0dSBPQU0gYXBwcm9wcmlhdGVseSBhcyBoeWJy aWQsIHR5cGUtMSBPQU0uDQoNCkZvciBldmVyeW9uZSdzIGJlbmVmaXQsIGhlcmUgaXMgYSBxdW90 ZSBvZiB0aGUgbmV3IHNlY3Rpb24gMzoNCg0KMy4gIFNjb3BlLCBBcHBsaWNhYmlsaXR5LCBhbmQg QXNzdW1wdGlvbnMNCg0KICAgSW4tc2l0dSBPQU0gZGVwbG95bWVudCBhc3N1bWVzIGEgc2V0IG9m IGNvbnRyYWludHMsIHJlcXVpcmVtZW50cywgYW5kDQogICBndWlkaW5nIHByaW5jaXBsZXMgd2hp Y2ggYXJlIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24uDQoNCiAgIFNjb3BlOiBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgdGhlIGRhdGEgZmllbGRzIGFuZCBhc3NvY2lhdGVkIGRhdGENCiAgIHR5cGVz IGZvciBpbi1zaXR1IE9BTS4gIFRoZSBpbi1zaXR1IE9BTSBkYXRhIGZpZWxkIGNhbiBiZSB0cmFu c3BvcnRlZA0KICAgYnkgYSB2YXJpZXR5IG9mIHRyYW5zcG9ydCBwcm90b2NvbHMsIGluY2x1ZGlu ZyBOU0gsIFNlZ21lbnQgUm91dGluZywNCiAgIFZYTEFOLUdQRSwgR2VuZXZlLCBJUHY2LCBvciBJ UHY0LiAgRW5jYXBzdWxhdGlvbiBkZXRhaWxzIGZvciB0aGVzZQ0KICAgZGlmZmVyZW50IHRyYW5z cG9ydCBwcm90b2NvbHMgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoN CiAgIERlcGxveW1lbnQgZG9tYWluIChvciBzY29wZSkgb2YgaW4tc2l0dSBPQU0gZGVwbG95bWVu dDogSU9BTSBpcyBhDQogICBuZXR3b3JrIGRvbWFpbiBmb2N1c2VkIGZlYXR1cmUsIHdpdGggIm5l dHdvcmsgZG9tYWluIiBiZWluZyBhIHNldCBvZg0KICAgbmV0d29yayBkZXZpY2VzIG9yIGVudGl0 aWVzIHdpdGhpbiBhIHNpbmdsZSBhZG1pbmlzdHJhdGlvbi4gIEZvcg0KICAgZXhhbXBsZSwgYSBu ZXR3b3JrIGRvbWFpbiBjYW4gaW5jbHVkZSBhbiBlbnRlcnByaXNlIGNhbXB1cyB1c2luZw0KICAg cGh5c2ljYWwgY29ubmVjdGlvbnMgYmV0d2VlbiBkZXZpY2VzIG9yIGFuIG92ZXJsYXkgbmV0d29y ayB1c2luZw0KICAgdmlydHVhbCBjb25uZWN0aW9ucyAvIHR1bm5lbHMgZm9yIGNvbm5lY3Rpdml0 eSBiZXR3ZWVuIHNhaWQgZGV2aWNlcy4NCiAgIEEgbmV0d29yayBkb21haW4gaXMgZGVmaW5lZCBi eSBpdHMgcGVyaW1pdGVyIG9yIGVkZ2UuICBUaGUgb3BlcmF0b3INCiAgIG9mIHN1Y2ggYSBkb21h aW4gTVVTVCBwdXQgcHJvdmlzaW9ucyBpbiBwbGFjZSB0byBlbnN1cmUgdGhhdCBpbi1zaXR1DQog ICBPQU0gZGF0YSBzdGF5cyB3aXRoaW4gdGhlIHNwZWNpZmljIGRvbWFpbiBvbmx5IChpLmUuLCBk b2VzIG5vdCBsZWFrDQogICBiZXlvbmQgdGhlIGVkZ2UpIGFuZCBjb25zaWRlciBwb3RlbnRpYWwg aW1wYWN0IG9mIElPQU0gdG8gRUNNUA0KICAgcHJvY2Vzc2luZywgcGF0aCBNVFUgYW5kIElDTVAg bWVzc2FnZSBoYW5kbGluZy4NCg0KICAgSW4tc2l0dSBPQU0gY29udHJvbCBwb2ludHM6IElPQU0g ZGF0YSBmaWVsZHMgYXJlIGFkZGVkIHRvIG9yIHJlbW92ZWQNCiAgIGZyb20gdGhlIGxpdmUgdXNl ciB0cmFmZmljIGJ5IHRoZSBkZXZpY2VzIHdoaWNoIGZvcm0gdGhlIGVkZ2Ugb2YgYQ0KICAgZG9t YWluLiAgRGV2aWNlcyB3aXRoaW4gYW4gSU9BTSBkb21haW4gY2FuIHVwZGF0ZSBhbmQvb3IgYWRk IElPQU0NCiAgIGRhdGEtZmllbGRzLiAgRG9tYWluIGVkZ2UgZGV2aWNlcyBjYW4gYmUgaG9zdHMg b3IgbmV0d29yayBkZXZpY2VzLg0KDQogICBUcmFmZmljLXNldHMgdGhhdCBpbi1zaXR1IE9BTSBp cyBhcHBsaWVkIHRvOiBJT0FNIGNhbiBiZSBkZXBsb3llZCBvbg0KICAgYWxsIG9yIG9ubHkgb24g c3Vic2V0cyBvZiB0aGUgbGl2ZSB1c2VyIHRyYWZmaWMuICBJdCBTSE9VTEQgYmUNCiAgIHBvc3Np YmxlIHRvIGVuYWJsZSBpbi1zaXR1IE9BTSBvbiBhIHNlbGVjdGVkIHNldCBvZiB0cmFmZmljIChl LmcuLA0KICAgcGVyIGludGVyZmFjZSwgYmFzZWQgb24gYW4gYWNjZXNzIGNvbnRyb2wgbGlzdCBv ciBmbG93IHNwZWNpZmljYXRpb24NCiAgIGRlZmluaW5nIGEgc3BlY2lmaWMgc2V0IG9mIHRyYWZm aWMsIGV0Yy4pICBUaGUgc2VsZWN0ZWQgc2V0IG9mDQogICB0cmFmZmljIGNhbiBhbHNvIGJlIGFs bCB0cmFmZmljLg0KDQogICBFbmNhcHN1bGF0aW9uIGluZGVwZW5kZW5jZTogRGF0YSBmb3JtYXRz IGZvciBpbi1zaXR1IE9BTSBTSE9VTEQgYmUNCiAgIGRlZmluZWQgaW4gYSB0cmFuc3BvcnQtaW5k ZXBlbmRlbnQgbWFubmVyLiAgSW4tc2l0dSBPQU0gYXBwbGllcyB0byBhDQogICB2YXJpZXR5IG9m IGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2xzLiAgQSBkZWZpbml0aW9uIG9mIGhvdyBJT0FNIGRhdGEN CiAgIGZpZWxkcyBhcmUgY2FycmllZCBieSBkaWZmZXJlbnQgdHJhbnNwb3J0IHByb3RvY29scyBp cyBvdXRzaWRlIHRoZQ0KICAgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgTGF5ZXJpbmc6 IElmIHNldmVyYWwgZW5jYXBzdWxhdGlvbiBwcm90b2NvbHMgKGUuZy4sIGluIGNhc2Ugb2YNCiAg IHR1bm5lbGluZykgYXJlIHN0YWNrZWQgb24gdG9wIG9mIGVhY2ggb3RoZXIsIGluLXNpdHUgT0FN IGRhdGEtcmVjb3Jkcw0KICAgY291bGQgYmUgcHJlc2VudCBhdCBldmVyeSBsYXllci4gIFRoZSBi ZWhhdmlvciBmb2xsb3dzIHRoZSBzaGlwcy1pbi0NCiAgIHRoZS1uaWdodCBtb2RlbC4NCg0KICAg Q29tYmluYXRpb24gd2l0aCBhY3RpdmUgT0FNIG1lY2hhbmlzbXM6IEluLXNpdHUgT0FNIFNIT1VM RCBiZSB1c2FibGUNCiAgIGZvciBhY3RpdmUgbmV0d29yayBwcm9iaW5nLCBlbmFibGluZyBmb3Ig ZXhhbXBsZSBhIGN1c3RvbWl6ZWQgdmVyc2lvbg0KICAgb2YgdHJhY2Vyb3V0ZS4gIERlY2Fwc3Vs YXRpbmcgaW4tc2l0dSBPQU0gbm9kZXMgbWF5IGhhdmUgYW4gYWJpbGl0eQ0KICAgdG8gc2VuZCB0 aGUgaW4tc2l0dSBPQU0gaW5mb3JtYXRpb24gcmV0cmlldmVkIGZyb20gdGhlIHBhY2tldCBiYWNr IHRvDQogICB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIHBhY2tldCBvciB0byB0aGUgZW5jYXBz dWxhdGluZyBub2RlLg0KDQogICBJbS1zaXR1IE9BTSBpbXBsZW1lbnRhdGlvbjogVGhlIElPQU0g ZGF0YS1maWVsZCBkZWZpbml0aW9ucyB0YWtlIHRoZQ0KICAgc3BlY2lmaWNzIG9mIGRldmljZXMg d2l0aCBoYXJkd2FyZSBkYXRhLXBsYW5lIGFuZCBzb2Z0d2FyZSBkYXRhLXBsYW5lDQogICBpbnRv IGFjY291bnQuDQoNClRob3VnaHRzL2NvbW1lbnRzPyBXaXRoIHRoZXNlIGNoYW5nZXMsIGFyZSB3 ZSBhYmxlIHRvIGtpY2stb2ZmIGFuIGFkb3B0aW9uIGNhbGw/DQoNClRoYW5rcywgRnJhbmsNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1PUlRPTiwgQUxGUkVEIEMgKEFMKSBb bWFpbHRvOmFjbW9ydG9uQGF0dC5jb21dIA0KU2VudDogTWl0dHdvY2gsIDI5LiBNw6RyeiAyMDE3 IDE4OjExDQpUbzogYWRyaWFuQG9sZGRvZy5jby51azsgJ0JyaWFuIFRyYW1tZWxsIChJRVRGKScg PGlldGZAdHJhbW1lbGwuY2g+OyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSA8ZmJyb2NrbmVA Y2lzY28uY29tPg0KQ2M6ICdJUFBNIENoYWlycycgPGlwcG0tY2hhaXJzQGlldGYub3JnPjsgaXBw bUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtpcHBtXSBWb3RlIGF0IElQUE0gc2Vzc2lvbg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGlwcG0gW21haWx0bzppcHBtLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQo+IFNlbnQ6IFdlZG5l c2RheSwgTWFyY2ggMjksIDIwMTcgNTozMiBQTQ0KPiBUbzogJ0JyaWFuIFRyYW1tZWxsIChJRVRG KSc7ICdGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKScNCj4gQ2M6ICdJUFBNIENoYWlycyc7IGlw cG1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtpcHBtXSBWb3RlIGF0IElQUE0gc2Vzc2lvbg0K PiANCj4gPiA+IFRoZXJlIHdlcmUgc2V2ZXJhbCBxdWVzdGlvbnMgcmVsYXRlZCB0byBzY29wZSBh bmQgYXBwbGljYWJpbGl0eSBpbiANCj4gPiA+IHRoZSBXRw0KPiA+IGRpc2N1c3Npb24g4oCTIGFu ZCBldmVuIG1vcmUgcmVjZW50bHkgb24gdGhlIGxpc3QuIFRob3NlIGNhbiBlYXNpbHkgYmUgDQo+ ID4gYWRkcmVzc2VkIGJ5IGFkZGluZyBwYXJhZ3JhcGggb24gYXBwbGljYWJpbGl0eSB0byANCj4g PiBkcmFmdC1icm9ja25lcnMtaW5iYW5kLW9hbS1kYXRhIOKAkyB0aGVyZSBpc27igJl0IGEgbmVl ZCBmb3IgYSBkZWRpY2F0ZWQgcmVxdWlyZW1lbnRzIGRvY3VtZW50Lg0KPiA+DQo+ID4gSSB0ZW5k IHRvIGFncmVlIHdpdGggdGhpcywgYWx0aG91Z2ggImEgcGFyYWdyYXBoIiBzZWVtcyBhIGxpdHRs ZSANCj4gPiB0aGluIHRvIG1lLiBJIHRoaW5rIHRoZXJlIHdlcmUgc29tZSB2YWxpZCBwb2ludHMg bWFkZSBpbiB0aGF0IA0KPiA+IGRpc2N1c3Npb24gYWJvdXQgdGhlIHNjb3BlIG9mIHRoZSBwcm9w b3NhbCB0aGF0IHNob3VsZCBiZSBhZGRyZXNzZWQ6IA0KPiA+IGlzIElPQU0gbWVhbnQgZm9yIHVz ZSB0dW5uZWwtZW5kLSB0by10dW5uZWwtIGVuZCBlbnZpcm9ubWVudCwgIA0KPiA+IGVuZC1ob3N0 LXRvLWVuZC1ob3N0LCB3aXRoaW4gYSBzaW5nbGUgbmV0d29yayBhbmQvb3IgYWNyb3NzIHRoZSAN Cj4gPiBJbnRlcm5ldC4gIFdoYXQgSSB3b3VsZCBzdWdnZXN0IGlzIGFkZGluZyBhIHNlY3Rpb24g dG8gdGhlIGRhdGEgDQo+ID4gbW9kZWwgZHJhZnQgb24gYXBwbGljYWJpbGl0eSBhbmQgYXNzdW1w dGlvbnMgYWJvdXQgdGhlIGVudmlyb25tZW50IA0KPiA+IC0tIGJvdGggYWJvdXQgdGhlIGRldmlj ZXMgYWRkaW5nIElPQU0gc2lnbmFscyB0byB0cmFmZmljIGFzIHdlbGwgYXMgDQo+ID4gdGhvc2Ug Y29uc3VtaW5nIHRoZXNlIHNpZ25hbHMgZnJvbSB0aGUgd2lyZSBhbmQgYW5hbHl6aW5nIHRoZW0g DQo+ID4gKHBvc3NpYmx5IHdpdGggdGhlIGNvb3BlcmF0aW9uIG9mIGRldmljZXMgbm90IG9uIHRo ZQ0KPiA+IHdpcmUpIC0tIHN1Ym1pdHRpbmcgYSBuZXcgcmV2aXNpb24sIGFuZCB3ZSBjYW4gcnVu IGEgbW9yZSBmb3JtYWwgDQo+ID4gYWRvcHRpb24gY2FsbCBvbiB0aGF0Lg0KPiANCj4gQWx0aG91 Z2ggSSB3YXMgb25lIG9mIHRoZSBwZW9wbGUgcmFpc2luZyB0aGUgIm5lZWQiIGZvciB0aGUgc2Nv cGUgYW5kIA0KPiByZXF1aXJlbWVudHMsIEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBsZWFkaW5nIG9u IHdoZXRoZXIgdGhpcyBuZWVkcyB0byANCj4gYmUgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCBvbiBm b2xkZWQgaW50byB0aGUgZGF0YSBmb3JtYXQgZG9jdW1lbnQuIFNvIA0KPiBCcmlhbidzIHByb3Bv c2FsIHdvdWxkIHdvcmsgZm9yIG1lLg0KPiANCj4gVGh1cywgSSdkIGxvdmUgdG8gc2VlIHRoaXMg c2NvcGluZyB0ZXh0IGRyYWZ0ZWQgYW5kIGZsb2F0ZWQgdG8gdGhlIA0KPiBsaXN0IGFzIGFuIGVt YWlsIG9yIGluIGEgcmV2aXNpb24gb2YgdGhlIGRhdGEgZm9ybWF0IGRvY3VtZW50Lg0KPiANCj4g Q2hlZXJzLA0KPiBBZHJpYW4NCltBQ01dIA0KDQorMSBmb3IgYWRkaW5nIGEgU2NvcGUgc2VjdGlv biB0bw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyb2NrbmVycy1pbmJhbmQt b2FtLWRhdGEtMDINCg0KSSBmZWx0IHRoYXQgSSB1bmRlcnN0b29kIHRoZSBzY29wZSBnb2luZyBp bnRvIHRoZSBkaXNjdXNzaW9uIE1vbmRheSBhbmQgdGhlIGFwcGxpY2FibGUgKHJlc3RyaWN0ZWQp IGRvbWFpbiAoSSBkaWQgdGhlIGhvbWV3b3JrLCB0aGUgc2luZ2xlIGRyYWZ0IEZyYW5rIGludHJv ZHVjZWQgb24gdGhlIG1haWxpbmcgbGlzdCB3YXMgWzBdICkuDQoNClNvbWUgYWRkaXRpb25hbCBx dWVzdGlvbnMgaGF2ZSBiZWVuIHJhaXNlZCAoZS5nLiwgIndoZXJlIHdpbGwgT0FNIGJlIGluc2Vy dGVkIGFuZCByZW1vdmVkPyIpIGFuZCBJJ2QgbGlrZSB0byBzZWUgdGhvc2UgaXRlbXMgc29ydGVk LW91dCBiZWZvcmUgd2UgZ28gdmVyeSBmYXIgKHRoZSBhZHZhbnRhZ2Ugb2Ygd2lkZXIgcmV2aWV3 KS4NCg0KVGhlIHJlcXVpcmVtZW50cyBkcmFmdCBvbmx5IGNhbWUtdXAgd2hlbiBJIGFza2VkIHNv bWUgcXVlc3Rpb25zIG9uIHRoZSBsaXN0LiBGcmFuayBtZW50aW9uZWQgdGhhdCB0aGUgb3VyIGxp c3QgZGlzY3Vzc2lvbiBvbiBlcXVpdmFsZW50IHRyZWF0bWVudCBvZiBPQU0gJiBub24tT0FNIHBh Y2tldHMgKCJjbGFzcyBDIikgd2FzIGFkZGVkIHRvIHRoZSByZXF1aXJlbWVudHMgZG9jdW1lbnQs IGFuZCB0aGF0IHNob3VsZCBtb3ZlIHRvIC1vYW0tZGF0YS0gdG9vLg0KIA0KSXQgd291bGQgYmUg Z29vZCB0byBoYXZlIGEgdmVyc2lvbiBvZiB0aGUgc2NvcGUgdG8gcmV2aWV3IEFTQVAuDQoNCnRo YW5rcyBhbmQgcmVnYXJkcywNCkFsDQoNClswXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtYnJvY2tuZXJzLWluYmFuZC1vYW0tZGF0YS0wMg0KDQoNCg0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaXBwbSBtYWlsaW5nIGxp c3QNCj4gaXBwbUBpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pcHBt JmQ9RHdJR2FRJmM9TEZZWi0NCj4gbzlfSFVNZU1UU1FpY3ZqSWcmcj1PZnNTdThrVElsdFZ5RDFv TDcyY0J3Jm09R2FxdWN6dEs1N2ZUajN2eVljTW5IRzlZSw0KPiBMMSB0VmtBU1E1QzNLaDYzb29B JnM9TWVzTTZCRlp5RWtWUHFzR3EySG80TEtTX0E0bnRmNVg1aEwwU3gwUnNkYyZlPQ0K