From ippm-admin@ietf.org Mon Nov 3 09:14:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02552 for ; Mon, 3 Nov 2003 09:14:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfT0-0007yW-3D; Mon, 03 Nov 2003 09:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfSs-0007yB-AV for ippm@optimus.ietf.org; Mon, 03 Nov 2003 09:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02514 for ; Mon, 3 Nov 2003 09:13:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfSq-00067V-00 for ippm@ietf.org; Mon, 03 Nov 2003 09:13:52 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AGfSq-00067B-00 for ippm@ietf.org; Mon, 03 Nov 2003 09:13:52 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 3 Nov 2003 15:13:32 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [ippm] Re: next meeting agenda X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 3 Nov 2003 15:13:31 +0100 Message-ID: Thread-Topic: [ippm] Re: next meeting agenda Thread-Index: AcOcujAmlOb1aH2dR6SrLhll6eKf3gFWF7WA From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE-NCC)" , "Matthew J Zekauskas" Cc: X-OriginalArrivalTime: 03 Nov 2003 14:13:32.0781 (UTC) FILETIME=[A9C4F9D0:01C3A214] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Henk, Matt Did you get an answer ?=20 Best Regards Emile -----Message d'origine----- De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net]=20 Envoy=E9 : lundi 27 octobre 2003 19:42 =C0 : STEPHAN Emile FTRD/DAC/LAN Cc : Matthew J Zekauskas; ippm@ietf.org Objet : [ippm] Re: next meeting agenda Dear Emile, > I don't see any entry regarding the agenda of the next meeting. Correct, we only just (30 mins) ago decided to ask for a slot. The MIB = will be one of the topics. Henk > I would > be glad to have 15-20 minutes to present the usage (without any SNMP > background) of the IPPM MIB proxy for sharing measure, for controlling = > results exchange and for SLA monitoring. > > Best Regards > Emile > > > > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@internet2.edu] > Envoy=E9 : lundi 27 octobre 2003 15:35 > =C0 : ippm@ietf.org > Cc : Matt Zekauskas; Merike Kaeo; Henk Uijterwaal; Allison Mankin=20 > Objet : [ippm] New ippm co-chair: Henk Uijterwaal > > > Merike Kaeo has decided to step down as the co-chair of > the IPPM working group because of her increasing focus > on the scurity area. Henk Uijterwaal has agreed to replace Merike as=20 > co-chair. Please welcome Henk! > > --Matt and Merike > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: = http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- That problem that we weren't having yesterday, is it better? (Big ISP = NOC) _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Nov 3 09:14:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02567 for ; Mon, 3 Nov 2003 09:14:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfTG-000813-NZ for ippm-archive@odin.ietf.org; Mon, 03 Nov 2003 09:14:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3EEIHw030807 for ippm-archive@odin.ietf.org; Mon, 3 Nov 2003 09:14:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfTG-00080o-Hd for ippm-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 09:14:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02536 for ; Mon, 3 Nov 2003 09:14:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfTF-000688-00 for ippm-web-archive@ietf.org; Mon, 03 Nov 2003 09:14:17 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGfTE-000684-00 for ippm-web-archive@ietf.org; Mon, 03 Nov 2003 09:14:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfT0-0007yW-3D; Mon, 03 Nov 2003 09:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGfSs-0007yB-AV for ippm@optimus.ietf.org; Mon, 03 Nov 2003 09:13:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02514 for ; Mon, 3 Nov 2003 09:13:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGfSq-00067V-00 for ippm@ietf.org; Mon, 03 Nov 2003 09:13:52 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AGfSq-00067B-00 for ippm@ietf.org; Mon, 03 Nov 2003 09:13:52 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 3 Nov 2003 15:13:32 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE : [ippm] Re: next meeting agenda X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 3 Nov 2003 15:13:31 +0100 Message-ID: Thread-Topic: [ippm] Re: next meeting agenda Thread-Index: AcOcujAmlOb1aH2dR6SrLhll6eKf3gFWF7WA From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE-NCC)" , "Matthew J Zekauskas" Cc: X-OriginalArrivalTime: 03 Nov 2003 14:13:32.0781 (UTC) FILETIME=[A9C4F9D0:01C3A214] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Henk, Matt Did you get an answer ?=20 Best Regards Emile -----Message d'origine----- De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net]=20 Envoy=E9 : lundi 27 octobre 2003 19:42 =C0 : STEPHAN Emile FTRD/DAC/LAN Cc : Matthew J Zekauskas; ippm@ietf.org Objet : [ippm] Re: next meeting agenda Dear Emile, > I don't see any entry regarding the agenda of the next meeting. Correct, we only just (30 mins) ago decided to ask for a slot. The MIB = will be one of the topics. Henk > I would > be glad to have 15-20 minutes to present the usage (without any SNMP > background) of the IPPM MIB proxy for sharing measure, for controlling = > results exchange and for SLA monitoring. > > Best Regards > Emile > > > > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@internet2.edu] > Envoy=E9 : lundi 27 octobre 2003 15:35 > =C0 : ippm@ietf.org > Cc : Matt Zekauskas; Merike Kaeo; Henk Uijterwaal; Allison Mankin=20 > Objet : [ippm] New ippm co-chair: Henk Uijterwaal > > > Merike Kaeo has decided to step down as the co-chair of > the IPPM working group because of her increasing focus > on the scurity area. Henk Uijterwaal has agreed to replace Merike as=20 > co-chair. Please welcome Henk! > > --Matt and Merike > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: = http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- That problem that we weren't having yesterday, is it better? (Big ISP = NOC) _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Nov 3 11:01:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08094 for ; Mon, 3 Nov 2003 11:01:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGh8Z-000630-8m; Mon, 03 Nov 2003 11:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGh8S-00061o-3g for ippm@optimus.ietf.org; Mon, 03 Nov 2003 11:00:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08044 for ; Mon, 3 Nov 2003 11:00:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGh8P-0007jt-00 for ippm@ietf.org; Mon, 03 Nov 2003 11:00:53 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AGh8K-0007jQ-00 for ippm@ietf.org; Mon, 03 Nov 2003 11:00:53 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 0DE2F4FDE3; Mon, 3 Nov 2003 17:00:18 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6C50A4FDE0; Mon, 3 Nov 2003 17:00:17 +0100 (CET) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hA3G0HHl021073; Mon, 3 Nov 2003 17:00:17 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id hA3G0H3d028817; Mon, 3 Nov 2003 17:00:17 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 3 Nov 2003 17:00:17 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN Cc: Matthew J Zekauskas , ippm@ietf.org Subject: Re: RE : [ippm] Re: next meeting agenda In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-RIPE-Spam-Status: N 0.408480 X-RIPE-Signature: 8c36c22147a484c777b968c4065363ac Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 3 Nov 2003, STEPHAN Emile FTRD/DAC/LAN wrote: > Dear Henk, Matt > > Did you get an answer ? Yes and no. Marcia wrote that she'd find a slot for us, but no day/time yet. H. > > Best Regards > Emile > > -----Message d'origine----- > De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] > Envoy=E9 : lundi 27 octobre 2003 19:42 > =C0 : STEPHAN Emile FTRD/DAC/LAN > Cc : Matthew J Zekauskas; ippm@ietf.org > Objet : [ippm] Re: next meeting agenda > > > Dear Emile, > > > I don't see any entry regarding the agenda of the next meeting. > > Correct, we only just (30 mins) ago decided to ask for a slot. The MIB w= ill be one of the topics. > > Henk > > > > > I would > > be glad to have 15-20 minutes to present the usage (without any SNMP > > background) of the IPPM MIB proxy for sharing measure, for controlling > > results exchange and for SLA monitoring. > > > > Best Regards > > Emile > > > > > > > > -----Message d'origine----- > > De : Matthew J Zekauskas [mailto:matt@internet2.edu] > > Envoy=E9 : lundi 27 octobre 2003 15:35 > > =C0 : ippm@ietf.org > > Cc : Matt Zekauskas; Merike Kaeo; Henk Uijterwaal; Allison Mankin > > Objet : [ippm] New ippm co-chair: Henk Uijterwaal > > > > > > Merike Kaeo has decided to step down as the co-chair of > > the IPPM working group because of her increasing focus > > on the scurity area. Henk Uijterwaal has agreed to replace Merike as > > co-chair. Please welcome Henk! > > > > --Matt and Merike > > > > > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www1.ietf.org/mailman/listinfo/ippm > > > > -------------------------------------------------------------------------= ----- > Henk Uijterwaal Email: henk.uijterwaal@ripe.n= et > RIPE Network Coordination Centre WWW: http://www.ripe.net/home= /henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > -------------------------------------------------------------------------= ----- > > That problem that we weren't having yesterday, is it better? (Big ISP NOC= ) > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/h= enk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------= --- That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Nov 3 11:01:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08109 for ; Mon, 3 Nov 2003 11:01:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGh8j-00065A-AS for ippm-archive@odin.ietf.org; Mon, 03 Nov 2003 11:01:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3G1DEA023380 for ippm-archive@odin.ietf.org; Mon, 3 Nov 2003 11:01:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGh8j-000651-3e for ippm-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 11:01:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08058 for ; Mon, 3 Nov 2003 11:01:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGh8g-0007kK-00 for ippm-web-archive@ietf.org; Mon, 03 Nov 2003 11:01:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGh8g-0007kH-00 for ippm-web-archive@ietf.org; Mon, 03 Nov 2003 11:01:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGh8Z-000630-8m; Mon, 03 Nov 2003 11:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGh8S-00061o-3g for ippm@optimus.ietf.org; Mon, 03 Nov 2003 11:00:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08044 for ; Mon, 3 Nov 2003 11:00:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGh8P-0007jt-00 for ippm@ietf.org; Mon, 03 Nov 2003 11:00:53 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AGh8K-0007jQ-00 for ippm@ietf.org; Mon, 03 Nov 2003 11:00:53 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 0DE2F4FDE3; Mon, 3 Nov 2003 17:00:18 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6C50A4FDE0; Mon, 3 Nov 2003 17:00:17 +0100 (CET) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hA3G0HHl021073; Mon, 3 Nov 2003 17:00:17 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id hA3G0H3d028817; Mon, 3 Nov 2003 17:00:17 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Mon, 3 Nov 2003 17:00:17 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN Cc: Matthew J Zekauskas , ippm@ietf.org Subject: Re: RE : [ippm] Re: next meeting agenda In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-RIPE-Spam-Status: N 0.408480 X-RIPE-Signature: 8c36c22147a484c777b968c4065363ac Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 3 Nov 2003, STEPHAN Emile FTRD/DAC/LAN wrote: > Dear Henk, Matt > > Did you get an answer ? Yes and no. Marcia wrote that she'd find a slot for us, but no day/time yet. H. > > Best Regards > Emile > > -----Message d'origine----- > De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] > Envoy=E9 : lundi 27 octobre 2003 19:42 > =C0 : STEPHAN Emile FTRD/DAC/LAN > Cc : Matthew J Zekauskas; ippm@ietf.org > Objet : [ippm] Re: next meeting agenda > > > Dear Emile, > > > I don't see any entry regarding the agenda of the next meeting. > > Correct, we only just (30 mins) ago decided to ask for a slot. The MIB w= ill be one of the topics. > > Henk > > > > > I would > > be glad to have 15-20 minutes to present the usage (without any SNMP > > background) of the IPPM MIB proxy for sharing measure, for controlling > > results exchange and for SLA monitoring. > > > > Best Regards > > Emile > > > > > > > > -----Message d'origine----- > > De : Matthew J Zekauskas [mailto:matt@internet2.edu] > > Envoy=E9 : lundi 27 octobre 2003 15:35 > > =C0 : ippm@ietf.org > > Cc : Matt Zekauskas; Merike Kaeo; Henk Uijterwaal; Allison Mankin > > Objet : [ippm] New ippm co-chair: Henk Uijterwaal > > > > > > Merike Kaeo has decided to step down as the co-chair of > > the IPPM working group because of her increasing focus > > on the scurity area. Henk Uijterwaal has agreed to replace Merike as > > co-chair. Please welcome Henk! > > > > --Matt and Merike > > > > > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www1.ietf.org/mailman/listinfo/ippm > > > > -------------------------------------------------------------------------= ----- > Henk Uijterwaal Email: henk.uijterwaal@ripe.n= et > RIPE Network Coordination Centre WWW: http://www.ripe.net/home= /henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > -------------------------------------------------------------------------= ----- > > That problem that we weren't having yesterday, is it better? (Big ISP NOC= ) > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > ---------------------------------------------------------------------------= --- Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/h= enk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ---------------------------------------------------------------------------= --- That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Tue Nov 4 03:28:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03467 for ; Tue, 4 Nov 2003 03:28:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwXh-000788-KU; Tue, 04 Nov 2003 03:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwXR-00077W-BH for ippm@optimus.ietf.org; Tue, 04 Nov 2003 03:27:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03447 for ; Tue, 4 Nov 2003 03:27:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwXO-0000en-00 for ippm@ietf.org; Tue, 04 Nov 2003 03:27:43 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AGwXO-0000e0-00 for ippm@ietf.org; Tue, 04 Nov 2003 03:27:42 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id D42F34EC43; Tue, 4 Nov 2003 09:26:19 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7D7664E2E8 for ; Tue, 4 Nov 2003 09:26:19 +0100 (CET) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hA48QJHl021609 for ; Tue, 4 Nov 2003 09:26:19 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id hA48QJHl003383 for ; Tue, 4 Nov 2003 09:26:19 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Tue, 4 Nov 2003 09:26:19 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.206674 X-RIPE-Signature: 1037f96bd4f820337baa6c2898e996b4 Subject: [ippm] Meeting in Minneapolis (fwd) Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Dear All, The IPPM working group will meet on Thursday, November 13, 13:00-15:00. Agenda items so-far are: - Emile Stephan - The two drafts on reordering. If you have any additional agenda topics, please drop us a note. The official agenda will go out later this week. Henk & Matt. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Tue Nov 4 03:28:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03482 for ; Tue, 4 Nov 2003 03:28:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwXr-0007AU-QP for ippm-archive@odin.ietf.org; Tue, 04 Nov 2003 03:28:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA48SBn3027550 for ippm-archive@odin.ietf.org; Tue, 4 Nov 2003 03:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwXr-0007AH-Ix for ippm-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 03:28:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03455 for ; Tue, 4 Nov 2003 03:28:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwXp-0000f5-00 for ippm-web-archive@ietf.org; Tue, 04 Nov 2003 03:28:09 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGwXo-0000f2-00 for ippm-web-archive@ietf.org; Tue, 04 Nov 2003 03:28:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwXh-000788-KU; Tue, 04 Nov 2003 03:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwXR-00077W-BH for ippm@optimus.ietf.org; Tue, 04 Nov 2003 03:27:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03447 for ; Tue, 4 Nov 2003 03:27:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwXO-0000en-00 for ippm@ietf.org; Tue, 04 Nov 2003 03:27:43 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AGwXO-0000e0-00 for ippm@ietf.org; Tue, 04 Nov 2003 03:27:42 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id D42F34EC43; Tue, 4 Nov 2003 09:26:19 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7D7664E2E8 for ; Tue, 4 Nov 2003 09:26:19 +0100 (CET) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hA48QJHl021609 for ; Tue, 4 Nov 2003 09:26:19 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id hA48QJHl003383 for ; Tue, 4 Nov 2003 09:26:19 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Tue, 4 Nov 2003 09:26:19 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.206674 X-RIPE-Signature: 1037f96bd4f820337baa6c2898e996b4 Subject: [ippm] Meeting in Minneapolis (fwd) Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Dear All, The IPPM working group will meet on Thursday, November 13, 13:00-15:00. Agenda items so-far are: - Emile Stephan - The two drafts on reordering. If you have any additional agenda topics, please drop us a note. The official agenda will go out later this week. Henk & Matt. ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Tue Nov 4 15:28:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03842 for ; Tue, 4 Nov 2003 15:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7mS-00027e-PR; Tue, 04 Nov 2003 15:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7m3-00027C-UT for ippm@optimus.ietf.org; Tue, 04 Nov 2003 15:27:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03807; Tue, 4 Nov 2003 15:27:23 -0500 (EST) Message-Id: <200311042027.PAA03807@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Nov 2003 15:27:23 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-reordering-04.txt Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Packet Reordering Metric for IPPM Author(s) : A. Morton Filename : draft-ietf-ippm-reordering-04.txt Pages : 25 Date : 2003-11-4 This memo defines a simple metric to determine if a network has maintained packet order. It provides motivations for the new metric, gives the metric definition, and discusses the issues associated with its measurement. The memo defines additional sample metrics to quantify the extent of reordering in several useful dimensions. Some examples of evaluation using the various sample metrics are included. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-reordering-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-reordering-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-4154912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reordering-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reordering-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-4154912.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Tue Nov 4 15:28:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03864 for ; Tue, 4 Nov 2003 15:28:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7mh-00029m-PG for ippm-archive@odin.ietf.org; Tue, 04 Nov 2003 15:28:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4KSF0L008287 for ippm-archive@odin.ietf.org; Tue, 4 Nov 2003 15:28:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7mh-00029Y-Jz for ippm-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 15:28:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03834 for ; Tue, 4 Nov 2003 15:28:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7mg-0004dF-00 for ippm-web-archive@ietf.org; Tue, 04 Nov 2003 15:28:14 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH7mf-0004dB-00 for ippm-web-archive@ietf.org; Tue, 04 Nov 2003 15:28:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7mS-00027e-PR; Tue, 04 Nov 2003 15:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7m3-00027C-UT for ippm@optimus.ietf.org; Tue, 04 Nov 2003 15:27:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03807; Tue, 4 Nov 2003 15:27:23 -0500 (EST) Message-Id: <200311042027.PAA03807@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Nov 2003 15:27:23 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-reordering-04.txt Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : Packet Reordering Metric for IPPM Author(s) : A. Morton Filename : draft-ietf-ippm-reordering-04.txt Pages : 25 Date : 2003-11-4 This memo defines a simple metric to determine if a network has maintained packet order. It provides motivations for the new metric, gives the metric definition, and discusses the issues associated with its measurement. The memo defines additional sample metrics to quantify the extent of reordering in several useful dimensions. Some examples of evaluation using the various sample metrics are included. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-reordering-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-reordering-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-4154912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reordering-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reordering-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-4154912.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Wed Nov 5 16:43:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25416 for ; Wed, 5 Nov 2003 16:43:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVPe-0008Um-4j; Wed, 05 Nov 2003 16:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVP4-0008RZ-B0 for ippm@optimus.ietf.org; Wed, 05 Nov 2003 16:41:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25365 for ; Wed, 5 Nov 2003 16:41:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVP2-0003vl-00 for ippm@ietf.org; Wed, 05 Nov 2003 16:41:24 -0500 Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AHVP1-0003vH-00 for ippm@ietf.org; Wed, 05 Nov 2003 16:41:23 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hA5LXSNh016374 for ; Wed, 5 Nov 2003 16:40:54 -0500 Received: from custsla.mt.att.com (135.21.14.109) by attrh5i.attrh.att.com (6.5.032) id 3F307C6C01A81FF0 for ippm@ietf.org; Wed, 5 Nov 2003 16:40:35 -0500 Received: from acmortonw.att.com (acmortonw.mt.att.com [135.16.251.219]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id hA5Lrb115853 for ; Wed, 5 Nov 2003 16:53:37 -0500 (EST) Message-Id: <5.2.1.1.0.20031105162430.05a183a0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 05 Nov 2003 16:40:49 -0500 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-reordering-04.txt In-Reply-To: <200311042027.PAA03807@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , At 03:27 PM 11/04/2003 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts... >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-04.txt We finally got this announced and posted, it was more fun than usual. Thanks to our Chairs for their help. One of the Action Items from the last meeting was to prepare some text on fragmentation. I put this together as an Appendix, because it's two pages long and would interrupt the flow. I also held it out of the 04 version, seeking simplifications over time but with minimal success. Suggestions welcome. Al 13. Appendix on fragment order evaluation Section 3 stated that fragment re-assembly is assumed prior to order evaluation, but that similar procedures could be applied prior to re-assembly. This appendix gives definitions and procedures to identify reordering in a packet stream that includes fragmentation. The Metric retains the same name, Type-P-reordered, but additional parameters are required. 13.1 Additional Metric Parameters: + MoreFrag, the state of the More Fragments Flag in the IP header + FragOffset, the offset from the beginning of a fragmented packet, in 8 octet units (also from the IP header). + FragSeq#, the sequence number from the IP header of a fragmented packet currently under evaluation for reordering. When set to zero, fragment evaluation is not in progress. + NextExpFrag, the Next Expected Fragment Offset at the Destination, in 8 octet units. Set to zero when fragment evaluation is not in progress. The packet sequence number, s, is assumed to be the same as the IP header sequence number. Also, the value of NextExp does not change with the in-order arrival of fragments. NextExp is only updated when a last fragment or a complete packet arrives. Note that packets with missing fragments MUST be declared lost, and the Reordering status of any fragments that do arrive MUST be excluded from sample metrics. 13.2 Definition: The value of Type-P-Reordered is typically false (the packet is in- order) when * the sequence number s >= NextExp, * AND the fragment offset FragOffset >= NextExpFrag However, it more efficient to define reordered conditions exactly, and designate Type-P-Reordered as False otherwise. The value of Type-P-Reordered is defined as True (the packet is reordered) under the conditions below. In these cases, the NextExp value does not change. Case 1: if s < NextExp Case 2: if s>= NextExp AND s < FragSeq# Case 3: if s>= NextExp AND s = FragSeq# AND FragOffset < NextExpFrag This definition can also be illustrated in pseudo-code. An early draft version of the code follows, and simplification may be possible. The challenging aspect surrounds the housekeeping for the new parameters. NextExp=0; NextExpFrag=0; FragSeq#=0; while(packets arrive with s, MoreFrag, FragOffset) { if (s>=NextExp AND MoreFrag==0){ /* a normal packet or the last fragment of a packet arrived */ NextExp = s+1; FragSeq# = 0; NextExpFrag = 0; Reordering = False; } if (s>=NextExp AND MoreFrag==1 AND s>FragSeq#>=0){ /* a fragment of a new packet arrived, possibly with a higher sequence number than the current fragmented packet */ FragSeq# = s; NextExpFrag = FragOffset+1; Reordering = False; } if (s>=NextExp AND MoreFrag==1 AND s==FragSeq#){ /* a fragment of the "current packet s" arrived */ if (FragOffset >= NextExpFrag){ NextExpFrag = FragOffset+1; Reordering = False; } else{ Reordering = True; /* fragment reordered */ } } if (s>=NextExp AND MoreFrag==1 AND s < FragSeq#){ /* case where a late fragment arrived */ Reordering = True; } else { /* when s < NextExp */ Reordering = True; } } A working version of the code would include a check to ensure that all fragments of a packet arrive before using the Reordered status further, such as in sample metrics. 13.3 Notes on Sample Metrics All fragments with the same Source Sequence Number are assigned the same Source Time. Evaluation with byte stream numbering may be simplified if the fragment offset is simply added to the SourceByte of the first packet (with fragment offset = 0), keeping the 8 octet units of the offset in mind. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Wed Nov 5 16:51:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25906 for ; Wed, 5 Nov 2003 16:51:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVYz-0000gq-K5 for ippm-archive@odin.ietf.org; Wed, 05 Nov 2003 16:51:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Lpfdx002646 for ippm-archive@odin.ietf.org; Wed, 5 Nov 2003 16:51:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVYz-0000gb-FQ for ippm-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:51:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25896 for ; Wed, 5 Nov 2003 16:51:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVYx-00047Z-00 for ippm-web-archive@ietf.org; Wed, 05 Nov 2003 16:51:39 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHVYx-00047V-00 for ippm-web-archive@ietf.org; Wed, 05 Nov 2003 16:51:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVPe-0008Um-4j; Wed, 05 Nov 2003 16:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVP4-0008RZ-B0 for ippm@optimus.ietf.org; Wed, 05 Nov 2003 16:41:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25365 for ; Wed, 5 Nov 2003 16:41:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVP2-0003vl-00 for ippm@ietf.org; Wed, 05 Nov 2003 16:41:24 -0500 Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AHVP1-0003vH-00 for ippm@ietf.org; Wed, 05 Nov 2003 16:41:23 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hA5LXSNh016374 for ; Wed, 5 Nov 2003 16:40:54 -0500 Received: from custsla.mt.att.com (135.21.14.109) by attrh5i.attrh.att.com (6.5.032) id 3F307C6C01A81FF0 for ippm@ietf.org; Wed, 5 Nov 2003 16:40:35 -0500 Received: from acmortonw.att.com (acmortonw.mt.att.com [135.16.251.219]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id hA5Lrb115853 for ; Wed, 5 Nov 2003 16:53:37 -0500 (EST) Message-Id: <5.2.1.1.0.20031105162430.05a183a0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 05 Nov 2003 16:40:49 -0500 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-reordering-04.txt In-Reply-To: <200311042027.PAA03807@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , At 03:27 PM 11/04/2003 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts... >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-04.txt We finally got this announced and posted, it was more fun than usual. Thanks to our Chairs for their help. One of the Action Items from the last meeting was to prepare some text on fragmentation. I put this together as an Appendix, because it's two pages long and would interrupt the flow. I also held it out of the 04 version, seeking simplifications over time but with minimal success. Suggestions welcome. Al 13. Appendix on fragment order evaluation Section 3 stated that fragment re-assembly is assumed prior to order evaluation, but that similar procedures could be applied prior to re-assembly. This appendix gives definitions and procedures to identify reordering in a packet stream that includes fragmentation. The Metric retains the same name, Type-P-reordered, but additional parameters are required. 13.1 Additional Metric Parameters: + MoreFrag, the state of the More Fragments Flag in the IP header + FragOffset, the offset from the beginning of a fragmented packet, in 8 octet units (also from the IP header). + FragSeq#, the sequence number from the IP header of a fragmented packet currently under evaluation for reordering. When set to zero, fragment evaluation is not in progress. + NextExpFrag, the Next Expected Fragment Offset at the Destination, in 8 octet units. Set to zero when fragment evaluation is not in progress. The packet sequence number, s, is assumed to be the same as the IP header sequence number. Also, the value of NextExp does not change with the in-order arrival of fragments. NextExp is only updated when a last fragment or a complete packet arrives. Note that packets with missing fragments MUST be declared lost, and the Reordering status of any fragments that do arrive MUST be excluded from sample metrics. 13.2 Definition: The value of Type-P-Reordered is typically false (the packet is in- order) when * the sequence number s >= NextExp, * AND the fragment offset FragOffset >= NextExpFrag However, it more efficient to define reordered conditions exactly, and designate Type-P-Reordered as False otherwise. The value of Type-P-Reordered is defined as True (the packet is reordered) under the conditions below. In these cases, the NextExp value does not change. Case 1: if s < NextExp Case 2: if s>= NextExp AND s < FragSeq# Case 3: if s>= NextExp AND s = FragSeq# AND FragOffset < NextExpFrag This definition can also be illustrated in pseudo-code. An early draft version of the code follows, and simplification may be possible. The challenging aspect surrounds the housekeeping for the new parameters. NextExp=0; NextExpFrag=0; FragSeq#=0; while(packets arrive with s, MoreFrag, FragOffset) { if (s>=NextExp AND MoreFrag==0){ /* a normal packet or the last fragment of a packet arrived */ NextExp = s+1; FragSeq# = 0; NextExpFrag = 0; Reordering = False; } if (s>=NextExp AND MoreFrag==1 AND s>FragSeq#>=0){ /* a fragment of a new packet arrived, possibly with a higher sequence number than the current fragmented packet */ FragSeq# = s; NextExpFrag = FragOffset+1; Reordering = False; } if (s>=NextExp AND MoreFrag==1 AND s==FragSeq#){ /* a fragment of the "current packet s" arrived */ if (FragOffset >= NextExpFrag){ NextExpFrag = FragOffset+1; Reordering = False; } else{ Reordering = True; /* fragment reordered */ } } if (s>=NextExp AND MoreFrag==1 AND s < FragSeq#){ /* case where a late fragment arrived */ Reordering = True; } else { /* when s < NextExp */ Reordering = True; } } A working version of the code would include a check to ensure that all fragments of a packet arrive before using the Reordered status further, such as in sample metrics. 13.3 Notes on Sample Metrics All fragments with the same Source Sequence Number are assigned the same Source Time. Evaluation with byte stream numbering may be simplified if the fragment offset is simply added to the SourceByte of the first packet (with fragment offset = 0), keeping the 8 octet units of the offset in mind. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Nov 7 04:35:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07330 for ; Fri, 7 Nov 2003 04:35:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI31C-0002nD-0r; Fri, 07 Nov 2003 04:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI30W-0002mG-Ef for ippm@optimus.ietf.org; Fri, 07 Nov 2003 04:34:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07218; Fri, 7 Nov 2003 04:34:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI30R-0001sM-00; Fri, 07 Nov 2003 04:34:15 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AI30Q-0001sJ-00; Fri, 07 Nov 2003 04:34:15 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 7 Nov 2003 10:34:11 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 7 Nov 2003 10:34:10 +0100 Message-ID: Thread-Topic: URGENT: IPPM WG doc Thread-Index: AcOirZpJ7+Z/OG7OTUapqUB4wHfyzwCYSBWw From: "STEPHAN Emile FTRD/DAC/LAN" To: , "Henk Uijterwaal (RIPE-NCC)" , Cc: X-OriginalArrivalTime: 07 Nov 2003 09:34:11.0703 (UTC) FILETIME=[4D0A7070:01C3A512] Content-Transfer-Encoding: quoted-printable Subject: [ippm] URGENT: IPPM WG doc Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear, In the IPPM WG I am in charge of the draft-ietf-ippm-metrics-registry-04.txt. The WG document draft-ietf-ippm-metrics-registry-04.txt disappeared from the web page of the IPPM WG and from the internet draft list too. Is it due to some mistake ?=20 Regards Emile _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Nov 7 09:08:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15190 for ; Fri, 7 Nov 2003 09:08:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7HO-0007be-3q; Fri, 07 Nov 2003 09:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7GO-0007L7-6N for ippm@optimus.ietf.org; Fri, 07 Nov 2003 09:07:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15119 for ; Fri, 7 Nov 2003 09:06:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7GM-0005WI-00 for ippm@ietf.org; Fri, 07 Nov 2003 09:06:58 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AI7GL-0005WF-00 for ippm@ietf.org; Fri, 07 Nov 2003 09:06:58 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 7 Nov 2003 15:06:50 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: [ippm] Agenda ? Date: Fri, 7 Nov 2003 15:06:49 +0100 Message-ID: Thread-Topic: [ippm] Agenda ? Thread-Index: AcOirZpJ7+Z/OG7OTUapqUB4wHfyzwCinB0Q From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE-NCC)" Cc: , "Matt Zekauskas" X-OriginalArrivalTime: 07 Nov 2003 14:06:50.0203 (UTC) FILETIME=[637772B0:01C3A538] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Henk, Do you have a more detailled agenda available ?=20 I would be glad if you may add a slot for discussing the status of the = ipp registry. Very Best Regards Emile -----Message d'origine----- De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net]=20 Envoy=E9 : mardi 4 novembre 2003 09:26 =C0 : ippm@ietf.org Objet : [ippm] Meeting in Minneapolis (fwd) Dear All, The IPPM working group will meet on Thursday, November 13, 13:00-15:00. = Agenda items so-far are: - Emile Stephan - The two drafts on reordering. If you have any additional agenda topics, please drop us a note. The = official agenda will go out later this week. Henk & Matt. -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: = http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- That problem that we weren't having yesterday, is it better? (Big ISP = NOC) _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Nov 7 09:08:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15209 for ; Fri, 7 Nov 2003 09:08:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7HW-0007fp-F6 for ippm-archive@odin.ietf.org; Fri, 07 Nov 2003 09:08:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7E8Aa7029491 for ippm-archive@odin.ietf.org; Fri, 7 Nov 2003 09:08:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7HV-0007fa-Qn for ippm-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 09:08:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15126 for ; Fri, 7 Nov 2003 09:07:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7HU-0005Wo-00 for ippm-web-archive@ietf.org; Fri, 07 Nov 2003 09:08:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI7HT-0005Wl-00 for ippm-web-archive@ietf.org; Fri, 07 Nov 2003 09:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7HO-0007be-3q; Fri, 07 Nov 2003 09:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7GO-0007L7-6N for ippm@optimus.ietf.org; Fri, 07 Nov 2003 09:07:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15119 for ; Fri, 7 Nov 2003 09:06:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7GM-0005WI-00 for ippm@ietf.org; Fri, 07 Nov 2003 09:06:58 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AI7GL-0005WF-00 for ippm@ietf.org; Fri, 07 Nov 2003 09:06:58 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 7 Nov 2003 15:06:50 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: [ippm] Agenda ? Date: Fri, 7 Nov 2003 15:06:49 +0100 Message-ID: Thread-Topic: [ippm] Agenda ? Thread-Index: AcOirZpJ7+Z/OG7OTUapqUB4wHfyzwCinB0Q From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE-NCC)" Cc: , "Matt Zekauskas" X-OriginalArrivalTime: 07 Nov 2003 14:06:50.0203 (UTC) FILETIME=[637772B0:01C3A538] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Henk, Do you have a more detailled agenda available ?=20 I would be glad if you may add a slot for discussing the status of the = ipp registry. Very Best Regards Emile -----Message d'origine----- De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net]=20 Envoy=E9 : mardi 4 novembre 2003 09:26 =C0 : ippm@ietf.org Objet : [ippm] Meeting in Minneapolis (fwd) Dear All, The IPPM working group will meet on Thursday, November 13, 13:00-15:00. = Agenda items so-far are: - Emile Stephan - The two drafts on reordering. If you have any additional agenda topics, please drop us a note. The = official agenda will go out later this week. Henk & Matt. -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: = http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- That problem that we weren't having yesterday, is it better? (Big ISP = NOC) _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Nov 7 09:21:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15535 for ; Fri, 7 Nov 2003 09:21:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7Tx-00084K-0w; Fri, 07 Nov 2003 09:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7T1-00082y-6L for ippm@optimus.ietf.org; Fri, 07 Nov 2003 09:20:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15482 for ; Fri, 7 Nov 2003 09:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7Sz-0005fb-00 for ippm@ietf.org; Fri, 07 Nov 2003 09:20:01 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AI7Sy-0005fS-00 for ippm@ietf.org; Fri, 07 Nov 2003 09:20:00 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA7EJxUC007666; Fri, 7 Nov 2003 23:19:59 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA7EJwpo005090; Fri, 7 Nov 2003 23:19:58 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA7EJw8H021811; Fri, 7 Nov 2003 23:19:58 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id XAA20388; Fri, 7 Nov 2003 23:19:57 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id XAA07604; Fri, 7 Nov 2003 23:19:57 +0900 (JST) Message-Id: <5.1.1.11.2.20031107231856.03db7330@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Fri, 07 Nov 2003 23:19:44 +0900 To: ippm@ietf.org From: "MORITA, Naotaka" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ippm] PPS and MF-PHB Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I would like to draw performance experts attention to the following three documents. http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt I am going to make a presentation on Monday morning at TSV WG. Naotaka ---- Title : Framework of Priority Promotion Scheme Author(s) : N. Morita, G. Karlsson Filename : draft-morita-tsvwg-pps-01.txt Pages : 18 Date : 2003-10-27 This document describes a framework of a new scheme for traffic control to achieve end-to-end QoS for interactive multimedia services. The scheme is based on end-to-end measurement of network resources by end systems. The network is assumed to fully support the priority control scheme specified in the Diffserv architecture for QoS and SIP [1] for session control. Since the scheme relies on the behavior of the end systems, this document also touches on mechanisms for monitoring end-system behavior. ------ Title : Measurable Forwarding: A New per-Hop Behavior (PHB) Author(s) : N. Morita Filename : draft-morita-tsvwg-mfphb-00.txt Pages : 19 Date : 2003-11-2 The Priority Promotion Scheme (PPS) is a new scheme for traffic control; specifically, the PPS achieves end-to-end QoS for interactive multimedia services by exercising admission control for a series of packets on a packet-based network. The scheme is based on the end-to-end measurement of network resources by end systems. The destination end system notifies the conditions of receipt for a limited set of packets sent from the source end. If this is acceptable, the source end system then promotes the priority of the succeeding IP packets to firmly establish the session. The network is only assumed to support a per-class form of priority control, since this allows the end systems to measure remaining resources without affecting the existing streams. If all end systems behave in the above way, we can achieve specific levels of end-to-end QoS without maintaining per-flow states in each item of network equipment. ------ Title : Verification scenarios for Measurable Forwarding PHB (Per-Hop Behavior) Author(s) : N. Morita Filename : draft-morita-tsvwg-mfverify-00.txt Pages : 7 Date : 2003-10-31 The Priority Promotion Scheme (PPS) is a new scheme for traffic control; specifically, the PPS achieves end-to-end QoS for interactive multimedia services by exercising admission control for series of packets on a packet-based network. The scheme is based on the end-to-end measurement of network resources by end systems. The destination end system notifies the conditions of receipt for a limited set of packets sent from the source end. If this is acceptable, the source end system then promotes the priority of the succeeding IP packets to firmly establish the session. The network is only assumed to support a per-class form of priority control, since this allows the end systems to measure remaining resources without affecting the existing streams. If all end systems behave in the above way, we can achieve specific levels of end-to-end QoS without maintaining per-flow states in each item of network equipment. The PPS is based on a new per-hop forwarding behavior, called measurable forwarding (MF-PHB), which will use the DiffServ architecture. In this document, we propose a way to verify whether MF-PHB is realizable by elaborating configurations of existing equipment. ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Nov 7 09:21:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15550 for ; Fri, 7 Nov 2003 09:21:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7U2-000871-9X for ippm-archive@odin.ietf.org; Fri, 07 Nov 2003 09:21:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7EL6J9031177 for ippm-archive@odin.ietf.org; Fri, 7 Nov 2003 09:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7U2-00086m-5b for ippm-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 09:21:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15523 for ; Fri, 7 Nov 2003 09:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7U0-0005gR-00 for ippm-web-archive@ietf.org; Fri, 07 Nov 2003 09:21:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI7U0-0005gO-00 for ippm-web-archive@ietf.org; Fri, 07 Nov 2003 09:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7Tx-00084K-0w; Fri, 07 Nov 2003 09:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7T1-00082y-6L for ippm@optimus.ietf.org; Fri, 07 Nov 2003 09:20:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15482 for ; Fri, 7 Nov 2003 09:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7Sz-0005fb-00 for ippm@ietf.org; Fri, 07 Nov 2003 09:20:01 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx with esmtp (Exim 4.12) id 1AI7Sy-0005fS-00 for ippm@ietf.org; Fri, 07 Nov 2003 09:20:00 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA7EJxUC007666; Fri, 7 Nov 2003 23:19:59 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA7EJwpo005090; Fri, 7 Nov 2003 23:19:58 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hA7EJw8H021811; Fri, 7 Nov 2003 23:19:58 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id XAA20388; Fri, 7 Nov 2003 23:19:57 +0900 (JST) Received: from morita-vaiodtop.lab.ntt.co.jp by imj.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id XAA07604; Fri, 7 Nov 2003 23:19:57 +0900 (JST) Message-Id: <5.1.1.11.2.20031107231856.03db7330@imj.m.ecl.ntt.co.jp> X-Sender: nm014@imj.m.ecl.ntt.co.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr5 Date: Fri, 07 Nov 2003 23:19:44 +0900 To: ippm@ietf.org From: "MORITA, Naotaka" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ippm] PPS and MF-PHB Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would like to draw performance experts attention to the following three documents. http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-01.txt http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfphb-00.txt http://www.ietf.org/internet-drafts/draft-morita-tsvwg-mfverify-00.txt I am going to make a presentation on Monday morning at TSV WG. Naotaka ---- Title : Framework of Priority Promotion Scheme Author(s) : N. Morita, G. Karlsson Filename : draft-morita-tsvwg-pps-01.txt Pages : 18 Date : 2003-10-27 This document describes a framework of a new scheme for traffic control to achieve end-to-end QoS for interactive multimedia services. The scheme is based on end-to-end measurement of network resources by end systems. The network is assumed to fully support the priority control scheme specified in the Diffserv architecture for QoS and SIP [1] for session control. Since the scheme relies on the behavior of the end systems, this document also touches on mechanisms for monitoring end-system behavior. ------ Title : Measurable Forwarding: A New per-Hop Behavior (PHB) Author(s) : N. Morita Filename : draft-morita-tsvwg-mfphb-00.txt Pages : 19 Date : 2003-11-2 The Priority Promotion Scheme (PPS) is a new scheme for traffic control; specifically, the PPS achieves end-to-end QoS for interactive multimedia services by exercising admission control for a series of packets on a packet-based network. The scheme is based on the end-to-end measurement of network resources by end systems. The destination end system notifies the conditions of receipt for a limited set of packets sent from the source end. If this is acceptable, the source end system then promotes the priority of the succeeding IP packets to firmly establish the session. The network is only assumed to support a per-class form of priority control, since this allows the end systems to measure remaining resources without affecting the existing streams. If all end systems behave in the above way, we can achieve specific levels of end-to-end QoS without maintaining per-flow states in each item of network equipment. ------ Title : Verification scenarios for Measurable Forwarding PHB (Per-Hop Behavior) Author(s) : N. Morita Filename : draft-morita-tsvwg-mfverify-00.txt Pages : 7 Date : 2003-10-31 The Priority Promotion Scheme (PPS) is a new scheme for traffic control; specifically, the PPS achieves end-to-end QoS for interactive multimedia services by exercising admission control for series of packets on a packet-based network. The scheme is based on the end-to-end measurement of network resources by end systems. The destination end system notifies the conditions of receipt for a limited set of packets sent from the source end. If this is acceptable, the source end system then promotes the priority of the succeeding IP packets to firmly establish the session. The network is only assumed to support a per-class form of priority control, since this allows the end systems to measure remaining resources without affecting the existing streams. If all end systems behave in the above way, we can achieve specific levels of end-to-end QoS without maintaining per-flow states in each item of network equipment. The PPS is based on a new per-hop forwarding behavior, called measurable forwarding (MF-PHB), which will use the DiffServ architecture. In this document, we propose a way to verify whether MF-PHB is realizable by elaborating configurations of existing equipment. ---------------------------------- Naotaka MORITA, Senior Research Engineer, Supervisor Network Service Systems Laboratories Information Sharing Laboratory Group NTT 3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012 E-mail: morita.naotaka@lab.ntt.co.jp MSN messenger: moritanaotaka@hotmail.com NTT home page: http://www.ntt.co.jp/about/e/index.html _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Nov 7 09:31:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15798 for ; Fri, 7 Nov 2003 09:31:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7dd-0008Um-TR; Fri, 07 Nov 2003 09:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI59y-0001jG-Qs for ippm@optimus.ietf.org; Fri, 07 Nov 2003 06:52:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11335; Fri, 7 Nov 2003 06:51:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI58y-0003er-00; Fri, 07 Nov 2003 06:51:12 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AI58v-0003ej-00; Fri, 07 Nov 2003 06:51:10 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 7 Nov 2003 12:50:55 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3A525.664D680A" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 7 Nov 2003 12:50:54 +0100 Message-ID: X-MS-Has-Attach: yes Thread-Topic: touch of the 'finale' version of the ippm metrics registry of the IPPM WG Thread-Index: AcMFh+Dka21ptADNTtWkV5tX2QS/8Cfm6Ccg From: "STEPHAN Emile FTRD/DAC/LAN" To: , Cc: "Matt Zekauskas" , "Henk Uijterwaal (RIPE-NCC)" , "Andy Bierman" , "JACQUENET Christian DRLD-ITP" X-OriginalArrivalTime: 07 Nov 2003 11:50:55.0171 (UTC) FILETIME=[66B05130:01C3A525] Subject: [ippm] touch of the 'finale' version of the ippm metrics registry of the IPPM WG Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A525.664D680A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C3A525.664D680A" ------_=_NextPart_002_01C3A525.664D680A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear, I don't see anymore the draft draft-ietf-ippm-metrics-registry-04.txt on the web page of the IPPM WG. It looks like it expired. So this is the version 5 of the ippm metrics registry: draft-ietf-ippm-metrics-registry-05.txt > This memo defines a registry of the IPPM working group metrics. It > assigns an OBJECT IDENTIFIER to each metric currently standardized by > the IPPM WG. It defines the rules for the identification of the > metrics standardized in the future. >=20 >=20 > Best regards > Emile >=20 >=20 <>=20 ------_=_NextPart_002_01C3A525.664D680A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable touch of the 'finale' version of the ippm metrics registry of = the IPPM WG

    Dear,

    I don't see = anymore the draft draft-ietf-ippm-metrics-registry-04.txt on the web = page of the IPPM WG. It looks like it expired.

    So this is the = version 5 of the ippm metrics registry: = draft-ietf-ippm-metrics-registry-05.txt

    This memo = defines a registry of the IPPM working group metrics. It assigns an = OBJECT IDENTIFIER to each metric currently standardized by the IPPM WG. = It defines the rules for the identification of the metrics standardized = in the future.


    Best = regards
    Emile


    = <<draft-ietf-ippm-metrics-registry-05.txt>>

------_=_NextPart_002_01C3A525.664D680A-- ------_=_NextPart_001_01C3A525.664D680A Content-Type: text/plain; name="draft-ietf-ippm-metrics-registry-05.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ippm-metrics-registry-05.txt Content-Disposition: attachment; filename="draft-ietf-ippm-metrics-registry-05.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEUuIFN0ZXBoYW4NCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZyYW5jZSBUZWxlY29tIFImRA0KRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtaXBwbS1tZXRyaWNzLXJlZ2lzdHJ5LTA1LnR4dCAgICAgICAgICBOb3ZlbWJlciAyMDAz DQpDYXRlZ29yeTogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgSVBQTSBtZXRy aWNzIHJlZ2lzdHJ5ICANCg0KU3RhdHVzIG9mIHRoaXMgTWVtbyANCg0KDQogIFRoaXMgZG9jdW1l bnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCAN CiAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMgMjAyNiBbUkZDMjAyNl0uIA0K DQogIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nIA0KICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdv cmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQgb3RoZXIgDQogIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gDQogIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cyANCiAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkgDQogIHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIElu dGVybmV0LSBEcmFmdHMgYXMgcmVmZXJlbmNlIA0KICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0g b3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iIA0KDQogIFRoZSBsaXN0IG9mIGN1cnJl bnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LiANCg0KICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1E cmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KICBodHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sLiANCg0KDQpBYnN0cmFjdCANCg0KICBUaGlzIG1lbW8gZGVm aW5lcyBhIHJlZ2lzdHJ5IG9mIHRoZSBJUFBNIHdvcmtpbmcgZ3JvdXAgbWV0cmljcy4gSXQgDQog IGFzc2lnbnMgYW4gT0JKRUNUIElERU5USUZJRVIgdG8gZWFjaCBtZXRyaWMgY3VycmVudGx5IHN0 YW5kYXJkaXplZCBieSANCiAgdGhlIElQUE0gV0cuIEl0IGRlZmluZXMgdGhlIHJ1bGVzIGZvciB0 aGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIA0KICBtZXRyaWNzIHN0YW5kYXJkaXplZCBpbiB0aGUg ZnV0dXJlLiANCg0KVGFibGUgb2YgQ29udGVudHMgDQoNCiAgMS4gICAgICBUaGUgSW50ZXJuZXQt U3RhbmRhcmQgTWFuYWdlbWVudCBGcmFtZXdvcmsuLi4uLi4uLi4uLi4uLi4uLi4uMg0KICAyLiAg ICAgIFRlcm1zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4yDQogIDMuICAgICAgT3ZlcnZpZXcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjINCiAgNC4gICAgICBUaGUgSVBQTSBGcmFtZXdvcmsu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMg0KICA1LiAgICAgIE92 ZXJ2aWV3Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4zDQogIDYuICAgICAgSVBQTSBtZXRyaWNzIFJlZ2lzdHJ5IGZyYW1ld29yay4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjMNCiAgNi4xLiAgICBNZXRyaWNzIHJlZ2lzdHJ5IHRlbXBsYXRl Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNA0KICA2LjIuICAgIEluaXRpYWwg SVBQTSBtZXRyaWNzIHJlZ2lzdHJ5IGNyZWF0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQog IDYuMy4gICAgRnV0dXJlIElQUE0gbWV0cmljcyByZWdpc3RyYXRpb24uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjYNCiAgNi40LiAgICBNZXRyaWMgZGVmaW5lZCBpbiBjb29wZXJhdGlvbiB3 aXRoIG90aGVyIGJvZGllcy4uLi4uLi4uLi4uLi4uNg0KICA3LiAgICAgIEluaXRpYWwgSVBQTSBy ZWdpc3RyeSBkZWZpbml0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogIDguICAg ICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTMNCg0KU3RlcGhhbiAgICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAg SVBQTSBtZXRyaWNzIHJlZ2lzdHJ5ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDMNCg0KDQogIDku ICAgICAgQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTMNCiAgMTAuICAgICBOb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KICAxMS4gICAgIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE0DQogIDEyLiAgICAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMTQNCiAgMTMuICAgICBBdXRob3IncyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xNQ0KICAxNC4gICAgIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVu dC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE1DQoNCg0KMS4gVGhlIEludGVy bmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrIA0KDQogIEZvciBhIGRldGFpbGVkIG92 ZXJ2aWV3IG9mIHRoZSBkb2N1bWVudHMgdGhhdCBkZXNjcmliZSB0aGUgY3VycmVudCANCiAgSW50 ZXJuZXQtU3RhbmRhcmQgTWFuYWdlbWVudCBGcmFtZXdvcmssIHBsZWFzZSByZWZlciB0byBzZWN0 aW9uIDcgb2YgDQogIFJGQyAzNDEwIFtSRkMzNDEwXS4gTWFuYWdlZCBvYmplY3RzIGFyZSBhY2Nl c3NlZCB2aWEgYSB2aXJ0dWFsIA0KICBpbmZvcm1hdGlvbiBzdG9yZSwgdGVybWVkIHRoZSBNYW5h Z2VtZW50IEluZm9ybWF0aW9uIEJhc2Ugb3IgTUlCLiAgDQogIE1JQiBvYmplY3RzIGFyZSBnZW5l cmFsbHkgYWNjZXNzZWQgdGhyb3VnaCB0aGUgU2ltcGxlIE5ldHdvcmsgDQogIE1hbmFnZW1lbnQg UHJvdG9jb2wgKFNOTVApLiBPYmplY3RzIGluIHRoZSBNSUIgYXJlIGRlZmluZWQgdXNpbmcgdGhl IA0KICBtZWNoYW5pc21zIGRlZmluZWQgaW4gdGhlIFN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50IElu Zm9ybWF0aW9uIChTTUkpLiANCiAgVGhpcyBtZW1vIHNwZWNpZmllcyBhIE1JQiBtb2R1bGUgdGhh dCBpcyBjb21wbGlhbnQgdG8gdGhlIFNNSXYyLCANCiAgd2hpY2ggaXMgZGVzY3JpYmVkIGluIFNU RCA1OCwgUkZDIDI1NzggW1JGQzI1NzhdLCBTVEQgNTgsIFJGQyAyNTc5IA0KICBbUkZDMjU3OV0g YW5kIFNURCA1OCwgUkZDIDI1ODAgW1JGQzI1ODBdLiANCg0KMi4gVGVybXMgDQoNCiAgVGhlIGtl eSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBO T1QiLCANCiAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgICJNQVkiLCBh bmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIEJDUCAxNCwgUkZDIDIxMTkgDQogIFtSRkMyMTE5XS4gDQoNCjMuIE92 ZXJ2aWV3IA0KDQogIFRoaXMgbWVtbyBkZWZpbmVzIGEgcmVnaXN0cnkgb2YgdGhlIElQUE0gd29y a2luZyBncm91cCBtZXRyaWNzLiBJdCANCiAgYXNzaWducyBhbiBPQkpFQ1QgSURFTlRJRklFUiB0 byBlYWNoIG1ldHJpYyBjdXJyZW50bHkgc3RhbmRhcmRpemVkIGJ5IA0KICB0aGUgSVBQTSBXRy4g SXQgZGVmaW5lcyB0aGUgcnVsZXMgZm9yIHRoZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgDQogIG1l dHJpY3Mgc3RhbmRhcmRpemVkIGluIHRoZSBmdXR1cmUuIA0KDQo0LiBUaGUgSVBQTSBGcmFtZXdv cmsgDQoNCiAgVGhlIElQUE0gRnJhbWV3b3JrIGNvbnNpc3RzIGluIGZvdXIgbWFqb3IgY29tcG9u ZW50czoNCg0KICAgICAgKyBBIGdlbmVyYWwgZnJhbWV3b3JrIGZvciBkZWZpbmluZyBwZXJmb3Jt YW5jZSBtZXRyaWNzIA0KICAgICAgICBkZXNjcmliZWQgaW4gdGhlIEZyYW1ld29yayBmb3IgSVAg UGVyZm9ybWFuY2UgTWV0cmljcyBSRkMyMzMwIA0KICAgICAgICBbUkZDIDIzMzBdOyANCg0KICAg ICAgKyBBIHNldCBvZiBzdGFuZGFyZGl6ZWQgbWV0cmljcywgd2hpY2ggY29uZm9ybSB0byB0aGlz IA0KICAgICAgICBmcmFtZXdvcmsuIA0KDQogICAgICArIEVtZXJnaW5nIG1ldHJpY3Mgd2hpY2gg YXJlIGJlaW5nIHNwZWNpZmllZCBpbiByZXNwZWN0IG9mIHRoaXMgDQogICAgICAgIGZyYW1ld29y azsgDQoNCg0KDQoNClN0ZXBoYW4gICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sg ICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAg IElQUE0gbWV0cmljcyByZWdpc3RyeSAgICAgICAgICAgICBOb3ZlbWJlciAyMDAzDQoNCg0KICAg ICAgKyBUaGUgSVBQTS1SRVBPUlRJTkctTUlCIGZvciByZXBvcnRpbmcgdGhlIHJlc3VsdHMgb2Yg dGhlIA0KICAgICAgICBtZWFzdXJlcyBhbmQgZm9yIGludGVyZmFjaW5nIGhldGVyb2dlbmVvdXMg bWVhc3VyZW1lbnQgc3lzdGVtcw0KICAgICAgICB3aXRoIG1hbmFnZW1lbnQgZW50aXRpZXMuIA0K DQoNCjUuIE92ZXJ2aWV3IA0KDQogIFRoaXMgbWVtbyBkZWZpbmVzIGEgcmVnaXN0cnkgb2YgdGhl IGN1cnJlbnQgbWV0cmljcyBhbmQgYSBmcmFtZXdvcmsgDQogIGZvciB0aGUgaW50ZWdyYXRpb24g b2YgZnV0dXJlIG1ldHJpY3MgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczogDQoNCiAgICAgICsg dG8gcGVybWl0IG1ldHJpY3MgdG8gYmUgY2xlYXJseSByZWZlcmVuY2VkIGJ5IE1JQnMgb3Igb3Ro ZXIgZGF0YQ0KICAgICAgICBtb2RlbHM7IA0KDQogICAgICArIE1ldHJpY3MgaWRlbnRpZmllcnMg YXJlIG5lZWRlZCB0byBhbGxvdyBtZWFzdXJlbWVudCANCiAgICAgICAgaW50ZXJvcGVyYWJpbGl0 eTsgDQoNCiAgICAgICsgQXMgc3BlY2lmaWNhdGlvbiBvZiBuZXcgbWV0cmljcyBpcyBhIGNvbnRp bnVvdXMgcHJvY2Vzcywgc3BlY2lhbA0KICAgICAgICBjYXJlIG11c3QgYmUgdGFrZW4gZm9yIHRo ZSBpbnRlZ3JhdGlvbiBvZiBmdXR1cmUgc3RhbmRhcmRpemVkDQogICAgICAgIG1ldHJpY3M7IA0K DQogICAgICArIEFzIHRoZSBpbnRlbnQgb2YgdGhlIElQUE0gV0cgaXMgdG8gY29vcGVyYXRlIHdp dGggb3RoZXIgDQogICAgICAgIGFwcHJvcHJpYXRlIHN0YW5kYXJkcyBib2RpZXMgYW5kIG90aGVy IGFyZWFzIG9mIElFVEYgdG8gcHJvbW90ZQ0KICAgICAgICBjb25zaXN0ZW50IG1ldHJpY3MsIHRo ZXJlIGlzIGEgbmVlZCB0byBwZXJtaXQgcmVnaXN0cmF0aW9uIG9mIA0KICAgICAgICBzdWNoIG1l dHJpY3MuIA0KDQoNCjYuIElQUE0gbWV0cmljcyBSZWdpc3RyeSBmcmFtZXdvcmsgDQoNCiAgTUlC cyBuZWVkIE9CSkVDVCBJTkRFTlRJRklFUnMgdG8gcmVmZXIgcHJlY2lzZWx5IHRvIHRoZSBzdGFu ZGFyZGl6ZWQgDQogIG1ldHJpY3MuIFRoZSByZWdpc3RyeSBhc3NvY2lhdGVzIGFuIE9CSkVDVCBJ REVOVElGSUVSIHdpdGggZWFjaCANCiAgbWV0cmljLiBBcyBhbiBleGFtcGxlIG9uZVdheURlbGF5 IGFuZCBvbmVXYXlEZWxheVBvaXNzb25TdHJlYW0gaGF2ZSANCiAgZGlmZmVyZW50IGlkZW50aWZp ZXJzLiANCg0KICBUaGUgcmVnaXN0cnkgaGFzIDIgcm9vdCBicmFuY2hlcy4gVGhlIGNhdGVnb3J5 IG9mIHRoZSBkb2N1bWVudCANCiAgZGV0ZXJtaW5lcyB0aGUgbm9kZSB3aGljaCBicmFuY2ggdGhl IG1ldHJpYyBpcyBpZGVudGlmaWVkIGluOiANCg0KICAgICAgKyBNZXRyaWNzIGRlZmluZWQgaW4g YSBSRkMgYXJlIGlkZW50aWZpZWQgaW4gdGhlICdyZmMnIHRyZWU7IA0KICAgICAgKyBNZXRyaWNz IGRlZmluZWQgaW4gY29vcGVyYXRpb24gd2l0aCBvdGhlciBib2RpZXMgbWF5IGJlIA0KICAgICAg ICBpZGVudGlmaWVkIGluIHRoZSAnb3RoZXJCb2RpZXMnIHRyZWUuIA0KDQogIFRoZSBuYW1lIG9m IHRoZSBtZXRyaWMgaW4gdGhlIHJlZ2lzdHJ5IG11c3QgcmVzcGVjdCB0aGUgU01JdjIgcnVsZXMg DQogIGZvciBkZXNjcmlwdG9ycyAoW1JGQzI1NzhdLCBzZWN0aW9uIDMuMSkgYW5kIHNob3VsZCBi ZSBlYXNpbHkgDQogIHJlYWRhYmxlLiBDb25zZXF1ZW50bHkgdGhlIGZvbGxvd2luZyBpcyBhcHBs aWVkIHRvIGFkYXB0IHRoZSBuYW1lIA0KICB1c2VkIGluIHRoZSBtZXRyaWMgZGVmaW5pdGlvbjog DQoNCiAgICAgICsgVGhlIGZpcnN0IGxldHRlciBpcyBmb3JjZWQgdG8gbG93ZXIgY2FzZTsgDQog ICAgICArICctJyBhcmUgcmVtb3ZlZDsgDQogICAgICArIFRoZSBsZXR0ZXIgZm9sbG93aW5nIGEg Jy0nIGlzIGZvcmNlZCB0byB1cHBlciBjYXNlOyANCiAgICAgICsgJ1R5cGUtUCcgcHJlZml4IGlz IHJlbW92ZWQuIA0KDQoNCg0KU3RlcGhhbiAgICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBU cmFjayAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAg ICAgICAgSVBQTSBtZXRyaWNzIHJlZ2lzdHJ5ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDMNCg0K DQogIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBpbml0aWFsIHJlZ2lzdHJ5IG9mIHRoZSBleGlz dGluZyBtZXRyaWNzLiANCiAgRG9jdW1lbnRzIGRlZmluaW5nIG1ldHJpY3MgaW4gdGhlIGZ1dHVy ZSB3aWxsIGluY2x1ZGUgYSByZWdpc3RyeSANCiAgc2VjdGlvbiB0byBjbGVhcmx5IGlkZW50aWZ5 IHRoZXNlIG1ldHJpY3MuICANCg0KDQo2LjEuIE1ldHJpY3MgcmVnaXN0cnkgdGVtcGxhdGUgDQoN CiAgRWFjaCBtZW1vIGluY2x1ZGVzIGEgcmVnaXN0cnkgd2hpY2ggaWRlbnRpZmllcyB0aGUgbWV0 cmljcy4gVGhlIA0KICByZWdpc3RyeSBpcyBkZWZpbmVkIHVzaW5nIGEgTU9EVUxFLUlERU5USVRZ IG1hY3JvLiBUaGUgbmFtZSBvZiB0aGUgDQogIG1vZHVsZSBtdXN0IGJlIHVuaXF1ZS4gRWFjaCBt ZXRyaWMgaXMgaWRlbnRpZmllZCBpbiB0aGUgcmVnaXN0cnkgDQogIHVzaW5nIGFuIE9CSkVDVC1J REVOVElUWSBtYWNybyBkZWZpbmluZyB0aGUgbWV0cmljIG5hbWUsIHN0YXR1cywgDQogIHJlZmVy ZW5jZSBhbmQgT0JKRUNUIElERU5USUZJRVIuICANCg0KICBUaGUgcmVnaXN0cnkgaXMgZGVmaW5l ZCBpbiBhIGRlZGljYXRlZCBzZWN0aW9uIG9mIHRoZSBtZW1vLiANCg0KICBBcyBhbiBleGFtcGxl LCBjb25zaWRlciBhbiBpbXByb2JhYmxlIElQUE0gV0cgZHJhZnQgdGhhdCBkZWZpbmVzIDQgDQog IG1ldHJpY3MgaW4gdGhlIHNlY3Rpb25zIDQsIDQuMSwgNC4yIGFuZCA0LjMsIHJlc3BlY3RpdmVs eTogDQoNCiAgICAgICsgVHlwZS1QLVBhY2tldC1TcGVlZCBtZXRyaWM7IA0KICAgICAgKyBUeXBl LVAtQXZlcmFnZS1QYWNrZXQtU3BlZWQgbWV0cmljOyANCiAgICAgICsgVHlwZS1QLU1pbmltdW0t UGFja2V0LVNwZWVkIG1ldHJpYzsgDQogICAgICArIFR5cGUtUC1NYXhpbXVtLVBhY2tldC1TcGVl ZCBtZXRyaWMuIA0KDQogIEZvbGxvd2luZyBpcyB0aGUgcmVnaXN0cnkgdGhhdCBtYXkgYmUgaW5j bHVkZWQgaW4gdGhlIGRvY3VtZW50Og0KDQogICAgICArIFRoZSBuYW1lIG9mIHRoZSBzZWN0aW9u IGlzICdJUFBNIFBhY2tldCBTcGVlZCBtZXRyaWNzIHJlZ2lzdHJ5JzsNCiAgICAgICsgVGhlIG5h bWUgb2YgdGhlIG1vZHVsZSBpcyBpcHBtUGFja2V0U3BlZWRNZXRyaWNzUmVnaXN0cnk7IA0KICAg ICAgKyAnTicgaXMgdGhlIG5vZGUgYXNzaWduZWQgYnkgSUFOQSB0byB0aGUgcmVnaXN0cnkgbW9k dWxlOyANCiAgICAgICsgVGhlIG5leHQgZnJlZSBub2RlIG9mIHRoZSBzdWIgdHJlZSBpcHBtTWV0 cmljc1JlZ2lzdHJ5LnJmYygxKSBpcw0KICAgICAgICAnMzQnLiANCg0KSVBQTS1QQUNLRVQtU1BF RUQtTUVUUklDUy1SRUdJU1RSWSBERUZJTklUSU9OUyA6Oj0gQkVHSU4gDQoNCklNUE9SVFMgDQog ICAgT0JKRUNULUlERU5USVRZLCBNT0RVTEUtSURFTlRJVFksIG1pYi0yIA0KICAgICAgICBGUk9N IFNOTVB2Mi1TTUkgDQogICAgcmZjIA0KICAgICAgICBGUk9NIElQUE0tTUVUUklDUy1SRUdJU1RS WTsgDQoNCg0KaXBwbVBhY2tldFNwZWVkTWV0cmljc1JlZ2lzdHJ5IE1PRFVMRS1JREVOVElUWSAg DQogICAgTEFTVC1VUERBVEVEICJZWVlZTU1ERDAwMDBaIiANCiAgICBPUkdBTklaQVRJT04gICAg ICAgIklFVEYgSVBQTSB3b3JraW5nIEdyb3VwIiANCiAgICBDT05UQUNULUlORk8gICAgICAgIiAN Cg0KDQogICAgICAgICAgIFRlbDogIA0KICAgICAgICBFLW1haWw6ICANCiAgICAgICAgUG9zdGFs OiAgDQoNCg0KDQpTdGVwaGFuICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0IERyYWZ0ICAgICAgICAgICBJ UFBNIG1ldHJpY3MgcmVnaXN0cnkgICAgICAgICAgICAgTm92ZW1iZXIgMjAwMw0KDQoNCiAgICAg ICAgU2VuZCBjb21tZW50cyB0byA8aXBwbUBpZXRmLm9yZz4gDQogICAgICAgIE1haWxpbmcgbGlz dCBzdWJzY3JpcHRpb24gaW5mbzogDQogICAgICAgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwcG0gIiANCiAgICBERVNDUklQVElPTiAgDQogICAgICAgICIgVGhpcyBt ZW1vIGRlZmluZXMgdGhlIHJlZ2lzdHJ5IGZvciBJUFBNIFBhY2tldCBTcGVlZCBtZXRyaWNzLiAN Cg0KICAgICAgICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAzKS4gIA0K DQogICAgICAgIFRoaXMgdmVyc2lvbiBvZiB0aGlzIE1JQiBtb2R1bGUgaXMgcGFydCBvZiBSRkMg eXl5eTsgc2VlIHRoZSANCiAgICAgICAgUkZDIGl0c2VsZiBmb3IgZnVsbCBsZWdhbCBub3RpY2Vz LiIgDQogICAgUkVWSVNJT04gICAgICAiWVlZWU1NREQwMDAwWiIgDQogICAgREVTQ1JJUFRJT04g DQogICAgICAgICJJbml0aWFsIHZlcnNpb24gb2YgdGhlIG1vZHVsZSBvZiB0aGUgcmVnaXN0cnkg Zm9yIElQUE0gUGFja2V0IA0KICAgICAgICBTcGVlZCBtZXRyaWNzLiANCiAgICAgICAgVGhpcyB2 ZXJzaW9uIHB1Ymxpc2hlZCBhcyBSRkMgeXl5eS4iIA0KICAgIDo6PSB7IG1pYi0yIE4gfSAgDQoN CmlwcG1QYWNrZXRTcGVlZE1ldHJpYyBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTIGN1cnJl bnQgDQogICAgREVTQ1JJUFRJT04gIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBU eXBlLVAtUGFja2V0LVNwZWVkIG1ldHJpYy4iIA0KICBSRUZFUkVOQ0UgIlJGQ3l5eXksIHNlY3Rp b24gNC4iIA0KICA6Oj0geyByZmMgMzQgfSANCg0KaXBwbUF2Z1BhY2tldFNwZWVkbWV0cmljICBP QkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gIA0K ICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtQXZlcmFnZS1QYWNrZXQtU3Bl ZWQgbWV0cmljLiIgDQogICAgUkVGRVJFTkNFICJSRkN5eXl5LCBzZWN0aW9uIDQuMS4iIA0KICAg IDo6PSB7IHJmYyAzNSB9IA0KDQppcHBtTWluUGFja2V0U3BlZWRtZXRyaWMgIE9CSkVDVC1JREVO VElUWSANCiAgICBTVEFUVVMgY3VycmVudCANCiAgICBERVNDUklQVElPTiAgDQogICAgICAgICJU aGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1NaW5pbXVtLVBhY2tldC1TcGVlZCBtZXRyaWMu IiANCiAgICBSRUZFUkVOQ0UgIlJGQ3l5eXksIHNlY3Rpb24gNC4yLiIgDQogICAgOjo9IHsgcmZj IDM2IH0gDQoNCmlwcG1NYXhQYWNrZXRTcGVlZG1ldHJpYyAgT0JKRUNULUlERU5USVRZIA0KICAg IFNUQVRVUyBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OICANCiAgICAgICAgIlRoZSBpZGVudGlm aWVyIGZvciB0aGUgVHlwZS1QLU1heGltdW0tUGFja2V0LVNwZWVkIG1ldHJpYy4iIA0KICAgIFJF RkVSRU5DRSAiUkZDeXl5eSwgc2VjdGlvbiA0LjMuIiANCiAgICA6Oj0geyByZmMgMzcgfSANCg0K RU5EICAgICAgDQoNCg0KNi4yLiBJbml0aWFsIElQUE0gbWV0cmljcyByZWdpc3RyeSBjcmVhdGlv biANCg0KDQoNClN0ZXBoYW4gICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAg ICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgIElQ UE0gbWV0cmljcyByZWdpc3RyeSAgICAgICAgICAgICBOb3ZlbWJlciAyMDAzDQoNCg0KICBUaGUg aW5pdGlhbCByZWdpc3RyeSBpZGVudGlmaWVzIHRoZSBtZXRyaWNzIGN1cnJlbnRseSBkZWZpbmVk IGluIHRoZSANCiAgUkZDcyBwcm9kdWNlZCBpbiB0aGUgSVBQTSBXRy4gDQoNCiAgQnkgbm93LCB0 aGUgSVBQTSBXRyBkZWZpbmVkIDMzIG1ldHJpY3MgcmVsYXRlZCB0byA3IHRvcGljczogDQoNCiAg ICAgICsgSVBQTSBNZXRyaWNzIGZvciBNZWFzdXJpbmcgQ29ubmVjdGl2aXR5LCBSRkMgMjY3OCBb UkZDMjY3OF07IA0KICAgICAgKyBPbmUtd2F5IERlbGF5IE1ldHJpY3MsIFJGQyAyNjc5ICBbUkZD MjY3OV07IA0KICAgICAgKyBPbmUtd2F5IFBhY2tldCBMb3NzIE1ldHJpY3MsIFJGQyAyNjgwIFtS RkMyNjgwXTsgDQogICAgICArIFJvdW5kLXRyaXAgRGVsYXkgTWV0cmljcywgUkZDIDI2ODEgW1JG QzI2ODFdOyANCiAgICAgICsgT25lLXdheSBMb3NzIFBhdHRlcm4gU2FtcGxlIE1ldHJpY3MsIFJG QyAzMzU3IFtSRkMzMzU3XTsgDQogICAgICArIElQIFBhY2tldCBEZWxheSBWYXJpYXRpb24gTWV0 cmljLCBSRkMgMzM5MyBbUkZDMzM5M107IA0KICAgICAgKyBJUFBNIE1ldHJpY3MgZm9yIHBlcmlv ZGljIHN0cmVhbXMsIFJGQyAzNDMyIFtSRkMzNDMyXTsgDQoNClRoZXkgYXJlIHJlZ2lzdGVyZWQg aW4gdGhlIG5vZGUgcmZjKDEpLiBUaGV5IGFyZSBudW1iZXJlZCB1c2luZyB0aGUgUkZDIA0Kb3Jk ZXIgYW5kIHRoZSBtZXRyaWNzIGRlZmluaXRpb25zIG9yZGVyIGluIGVhY2ggbWVtby4gVGhlIG5v ZGUgYXNzaWduZWQgDQp0byBhIG1ldHJpYyBpcyBkZWZpbml0aXZlIGFuZCBjYW5ub3QgYmUgcmV1 c2VkLiANCg0KNi4zLiBGdXR1cmUgSVBQTSBtZXRyaWNzIHJlZ2lzdHJhdGlvbiANCg0KICBXaGVu IHRoZSBJUFBNIFdHIGRyYWZ0IGlzIGNvbnNpZGVyZWQgbWF0dXJlIGVub3VnaDogDQoNCiAgICAg ICsgVGhlIGNoYWlyIG9mIHRoZSBJUFBNIFdHLCBvciBzb21lb25lIHByb3Bvc2VkIGJ5IHRoZSBk aXJlY3RvcnMgDQogICAgICAgIG9mIHRoZSBUcmFuc3BvcnQgQXJlYSwgYXNzaWducyB0byBlYWNo IG1ldHJpYyBhIHN1YiBub2RlIGNob3Nlbg0KICAgICAgICBpbiB0aGUgdHJlZSByZmMoMSkgb2Yg dGhlIElQUE0tTUVUUklDUy1SRUdJU1RSWTsgDQoNCiAgICAgICsgQXV0aG9ycyBpbnNlcnQgYSBy ZWdpc3RyeSB0ZW1wbGF0ZSBpbiB0aGVpciBkb2N1bWVudC4gVGhlbiB0aGV5DQogICAgICAgIGNy ZWF0ZSBhbiBPQkpFQ1QtSURFTlRJVFkgaW5zdGFuY2UgcGVyIG1ldHJpYyBhbmQgY29tcGxldGUg dGhlIA0KICAgICAgICBpbnN0YW5jZSB3aXRoIHRoZSBhc3NpZ25lZCBzdWIgbm9kZXMuIA0KDQog IFRoYXQgaGVscHMgdG8gcHJlcGFyZSB0aGUgZmluYWwgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIE1v cmVvdmVyIGl0IA0KICBmYWNpbGl0YXRlcyBzb2Z0d2FyZSBpbnRlZ3JhdGlvbiBhbmQgaW50ZXJv cGVyYWJpbGl0eSBtZWFzdXJlbWVudCANCiAgZHVyaW5nIHRoZSBzcGVjaWZpY2F0aW9uIHByb2Nl c3MuIA0KDQo2LjQuIE1ldHJpYyBkZWZpbmVkIGluIGNvb3BlcmF0aW9uIHdpdGggb3RoZXIgYm9k aWVzIA0KDQogIFN1Y2ggbWV0cmljcyBtYXkgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgbm9kZSBvdGhl ckJvZGllcygyKS4gDQoNCiAgTm90aGluZyBwcmV2ZW50cyB0aGVzZSBib2RpZXMgZnJvbSByZWdp c3RlcmluZyBtZXRyaWNzIGluIHRoZWlyIG93biANCiAgb2JqZWN0IGlkZW50aWZpZXIgdHJlZXMu IA0KDQoNCjcuIEluaXRpYWwgSVBQTSByZWdpc3RyeSBkZWZpbml0aW9uIA0KDQpJUFBNLU1FVFJJ Q1MtUkVHSVNUUlkgREVGSU5JVElPTlMgOjo9IEJFR0lOIA0KDQpJTVBPUlRTIA0KICAgIE9CSkVD VC1JREVOVElUWSwgTU9EVUxFLUlERU5USVRZLCBtaWItMiANCiAgICAgICAgRlJPTSBTTk1QdjIt U01JOyAgICAgICAgICAgICAgICAgICAgICAgIA0KDQppcHBtTWV0cmljc1JlZ2lzdHJ5IE1PRFVM RS1JREVOVElUWSANCiAgICBMQVNULVVQREFURUQgIjIwMDMwNDE3MDAwMFoiICAgIC0tIEFwcmls IDE3dGgsIDIwMDMgDQoNClN0ZXBoYW4gICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJh Y2sgICAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgIElQUE0gbWV0cmljcyByZWdpc3RyeSAgICAgICAgICAgICBOb3ZlbWJlciAyMDAzDQoNCg0K ICAgIE9SR0FOSVpBVElPTiAgICAgICAiSUVURiBJUFBNIHdvcmtpbmcgR3JvdXAiIA0KICAgIENP TlRBQ1QtSU5GTyAgICAgICAiIA0KICAgICAgICAgICAgICAgIEVtaWxlIFNURVBIQU4gDQogICAg ICAgICAgICAgICAgRnJhbmNlIFRlbGVjb20gUiZEIA0KICAgICAgICAgICBUZWw6ICsxIDMzIDIg OTYgMDUgMzYgMTAgDQogICAgICAgIEUtbWFpbDogZW1pbGUuc3RlcGhhbkBmcmFuY2V0ZWxlY29t LmNvbSANCiAgICAgICAgUG9zdGFsOiAyLCBhdmVudWUgUGllcnJlIE1hcnppbiANCiAgICAgICAg ICAgICAgICBMYW5uaW9uLCBGUkFOQ0UgMjIzMDcgDQoNCiAgICAgICAgU2VuZCBjb21tZW50cyB0 byA8aXBwbUBpZXRmLm9yZz4gDQogICAgICAgIE1haWxpbmcgbGlzdCBzdWJzY3JpcHRpb24gaW5m bzogDQogICAgICAgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0g IiANCiAgICBERVNDUklQVElPTiAgDQogICAgICAgICJUaGlzIG1lbW8gZGVmaW5lcyBhIHJlZ2lz dHJ5IG9mIHRoZSBJUFBNIHdvcmtpbmcgZ3JvdXAgDQogICAgICAgIG1ldHJpY3MuIA0KDQoNCiAg ICAgICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMykuIFRoaXMgdmVy c2lvbiBvZiB0aGlzIA0KICAgICAgICBNSUIgbW9kdWxlIGlzIHBhcnQgb2YgUkZDIHl5eXk7IHNl ZSB0aGUgUkZDIGl0c2VsZiBmb3IgZnVsbCANCiAgICAgICAgbGVnYWwgbm90aWNlcy4iIA0KICAg IFJFVklTSU9OICAgICAgIjIwMDMwNDE3MDAwMFoiICAgIC0tIEFwcmlsIDE3dGgsIDIwMDMgDQog ICAgREVTQ1JJUFRJT04gDQogICAgICAgICJJbml0aWFsIHZlcnNpb24gb2YgdGhlIElQUE0gbWV0 cmljcyByZWdpc3RyeSBtb2R1bGUuIA0KICAgICAgICAgVGhpcyB2ZXJzaW9uIHB1Ymxpc2hlZCBh cyBSRkMgeXl5eS4iIA0KICAgIDo6PSB7IG1pYi0yIFhYWCB9ICAtLSBYWFggdG8gYmUgYXNzaWdu ZWQgYnkgSUFOQQ0KDQpyZmMgICAgICAgICAgICAgT0JKRUNUIElERU5USUZJRVIgICAgOjo9IHsg aXBwbU1ldHJpY3NSZWdpc3RyeSAxIH0gIA0Kb3RoZXJCb2RpZXMgICAgIE9CSkVDVCBJREVOVElG SUVSICAgIDo6PSB7IGlwcG1NZXRyaWNzUmVnaXN0cnkgMiB9ICANCg0KICAtLSANCiAgLS0gUmVn aXN0cnkgb2YgdGhlIG1ldHJpY3Mgb2YgdGhlIElQUE0gV0cgUkZDcyANCiAgLS0gDQoNCiAgLS0g DQogIC0tIFJGQyAyNjc4ICIgSVBQTSBNZXRyaWNzIGZvciBNZWFzdXJpbmcgQ29ubmVjdGl2aXR5 IiANCiAgLS0gDQoNCmluc3RhbnRVbmlkaXJlY3Rpb25Db25uZWN0aXZpdHkgT0JKRUNULUlERU5U SVRZIA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAg IlRoZSBpZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLUluc3RhbnRhbmVvdXMtVW5pZGlyZWN0aW9u YWwtDQogICAgICAgIENvbm5lY3Rpdml0eSBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIlJGQzI2 NzgsIHNlY3Rpb24gMi4iIA0KICAgIDo6PXtyZmMgMX0gDQoNCmluc3RhbnRCaWRpcmVjdGlvbkNv bm5lY3Rpdml0eSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAg IERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtSW5z dGFudGFuZW91cy1CaWRpcmVjdGlvbmFsLQ0KICAgICAgICBDb25uZWN0aXZpdHkgbWV0cmljLiIg DQogICAgUkVGRVJFTkNFICJSRkMyNjc4LCBzZWN0aW9uIDMuIiANCg0KU3RlcGhhbiAgICAgICAg ICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDdd DQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgSVBQTSBtZXRyaWNzIHJlZ2lzdHJ5ICAgICAg ICAgICAgIE5vdmVtYmVyIDIwMDMNCg0KDQogICAgOjo9e3JmYyAyfSANCg0KaW50ZXJ2YWxVbmlk aXJlY3Rpb25Db25uZWN0aXZpdHkgT0JKRUNULUlERU5USVRZIA0KICAgIFNUQVRVUyAgICAgY3Vy cmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRoZSBpZGVudGlmaWVyIGZvciB0aGUg VHlwZS1QLUludGVydmFsLVVuaWRpcmVjdGlvbmFsLQ0KICAgICAgICBDb25uZWN0aXZpdHkgbWV0 cmljLiIgDQogICAgUkVGRVJFTkNFICJSRkMyNjc4LCBzZWN0aW9uIDQuIiANCiAgICA6Oj0geyBy ZmMgMyB9IA0KDQppbnRlcnZhbEJpZGlyZWN0aW9uQ29ubmVjdGl2aXR5IE9CSkVDVC1JREVOVElU WSANCiAgICBTVEFUVVMgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRoZSBp ZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLUludGVydmFsLUJpZGlyZWN0aW9uYWwtDQogICAgICAg IENvbm5lY3Rpdml0eSBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIlJGQzI2NzgsIHNlY3Rpb24g NS4iIA0KICAgIDo6PSB7IHJmYyAgNCB9IA0KDQppbnRlcnZhbFRlbXBvcmFsQ29ubmVjdGl2aXR5 IE9CSkVDVC1JREVOVElUWSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJ T04gDQogICAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUDEtUDItSW50ZXJ2YWwt VGVtcG9yYWwtDQogICAgICAgIENvbm5lY3Rpdml0eSBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0Ug IlJGQzI2NzgsIHNlY3Rpb24gNi4iIA0KICAgIDo6PSB7IHJmYyAgNSB9IA0KDQotLSANCi0tIFJG QyAyNjc5ICJBIE9uZS13YXkgRGVsYXkgTWV0cmljIGZvciBJUFBNIiANCi0tIA0KDQpvbmVXYXlE ZWxheSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NS SVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdheS1E ZWxheSBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIlJGQzI2NzksIHNlY3Rpb24gMy4iIA0KICAg IDo6PSB7IHJmYyAgNiB9IA0KDQpvbmVXYXlEZWxheVBvaXNzb25TdHJlYW0gT0JKRUNULUlERU5U SVRZIA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAg IlRoZSBpZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLU9uZS13YXktRGVsYXktUG9pc3Nvbi1TdHJl YW0gDQogICAgICAgIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiUkZDMjY3OSwgc2VjdGlvbiA0 LiIgDQogICAgOjo9IHsgcmZjICA3IH0gDQoNCm9uZVdheURlbGF5UGVyY2VudGlsZSBPQkpFQ1Qt SURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAg ICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdheS1EZWxheS1QZXJjZW50 aWxlIA0KICAgICAgICBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIlJGQzI2NzksIHNlY3Rpb24g NS4xLiIgDQoNCg0KU3RlcGhhbiAgICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAg SVBQTSBtZXRyaWNzIHJlZ2lzdHJ5ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDMNCg0KDQogICAg Ojo9IHsgcmZjICA4IH0gDQoNCm9uZVdheURlbGF5TWVkaWFuIE9CSkVDVC1JREVOVElUWSANCiAg ICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRl bnRpZmllciBmb3IgdGhlIFR5cGUtUC1PbmUtd2F5LURlbGF5LU1lZGlhbiBtZXRyaWMuIiANCiAg ICBSRUZFUkVOQ0UgIlJGQzI2NzksIHNlY3Rpb24gNS4yLiIgDQogICAgOjo9IHsgcmZjICA5IH0g DQoNCm9uZVdheURlbGF5TWluaW11bSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBj dXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRo ZSBUeXBlLVAtT25lLXdheS1EZWxheS1NaW5pbXVtIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAi UkZDMjY3OSwgc2VjdGlvbiA1LjMuIiANCiAgICA6Oj0geyByZmMgMTAgfSANCg0Kb25lV2F5RGVs YXlJbnZlcnNlUGVyY2VudGlsZSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJy ZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBU eXBlLVAtT25lLXdheS1EZWxheS1JbnZlcnNlLVBlcmNlbnRpbGUgDQogICAgICAgIG1ldHJpYy4g IiANCiAgICBSRUZFUkVOQ0UgIlJGQzI2NzksIHNlY3Rpb24gNS40LiIgDQogICAgOjo9IHsgcmZj IDExIH0gDQoNCi0tIA0KLS0gUkZDIDI2ODAgICJPbmUgV2F5IFBhY2tldCBMb3NzIE1ldHJpYyBm b3IgSVBQTSIgDQotLSANCg0Kb25lV2F5UGFja2V0TG9zcyBPQkpFQ1QtSURFTlRJVFkgDQogICAg U1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50 aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdheS1QYWNrZXQtTG9zcyBtZXRyaWMuIiANCiAgICBS RUZFUkVOQ0UgIlJGQzI2ODAsIHNlY3Rpb24gMi4iIA0KICAgIDo6PSB7IHJmYyAxMiB9IA0KDQpv bmVXYXlQYWNrZXRMb3NzUG9pc3NvblN0cmVhbSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVT ICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIg Zm9yIHRoZSBUeXBlLVAtT25lLXdheS1QYWNrZXQtTG9zcy1Qb2lzc29uLQ0KICAgICAgICBTdHJl YW0gbWV0cmljLiIgDQogICAgUkVGRVJFTkNFICJSRkMyNjgwLCBzZWN0aW9uIDMuIiANCiAgICA6 Oj0geyByZmMgMTMgfSANCg0Kb25lV2F5UGFja2V0TG9zc0F2ZXJhZ2UgT0JKRUNULUlERU5USVRZ IA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRo ZSBpZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLU9uZS13YXktUGFja2V0LUxvc3MtQXZlcmFnZSAN CiAgICAgICAgbWV0cmljLiIgDQogICAgUkVGRVJFTkNFICJSRkMyNjgwLCBzZWN0aW9uIDQuIiAN CiAgICA6Oj0geyByZmMgMTQgfSANCg0KLS0gDQoNClN0ZXBoYW4gICAgICAgICAgICAgICAgICAg ICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJu ZXQgRHJhZnQgICAgICAgICAgIElQUE0gbWV0cmljcyByZWdpc3RyeSAgICAgICAgICAgICBOb3Zl bWJlciAyMDAzDQoNCg0KLS0gUkZDMjY4MSAiQSBSb3VuZC10cmlwIERlbGF5IE1ldHJpYyBmb3Ig SVBQTSIgDQotLSANCg0Kcm91bmR0cmlwRGVsYXkgT0JKRUNULUlERU5USVRZIA0KICAgIFNUQVRV UyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRoZSBpZGVudGlmaWVy IGZvciB0aGUgVHlwZS1QLVJvdW5kLXRyaXAtRGVsYXkgbWV0cmljLiIgDQogICAgUkVGRVJFTkNF ICIgc2VjdGlvbiAyIG9mIHRoZSByZmMyNjgxLiIgDQogICAgOjo9IHsgcmZjIDE1IH0gDQoNCnJv dW5kdHJpcERlbGF5UG9pc3NvblN0cmVhbSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAg ICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9y IHRoZSBUeXBlLVAtUm91bmQtdHJpcC1EZWxheS1Qb2lzc29uLVN0cmVhbSANCiAgICAgICAgbWV0 cmljLiIgDQogICAgUkVGRVJFTkNFICJSRkMyNjgxLCBzZWN0aW9uIDQuIiANCiAgICA6Oj0geyBy ZmMgMTYgfSANCg0Kcm91bmR0cmlwRGVsYXlQZXJjZW50aWxlIE9CSkVDVC1JREVOVElUWSANCiAg ICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRl bnRpZmllciBmb3IgdGhlIFR5cGUtUC1Sb3VuZC10cmlwLURlbGF5LVBlcmNlbnRpbGUgDQogICAg ICAgIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiUkZDMjY4MSwgc2VjdGlvbiA0LjEuIiANCiAg ICA6Oj0geyByZmMgMTcgfSANCg0Kcm91bmR0cmlwRGVsYXlNZWRpYW4gT0JKRUNULUlERU5USVRZ IA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRo ZSBpZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLVJvdW5kLXRyaXAtRGVsYXktTWVkaWFuIG1ldHJp Yy4iIA0KICAgIFJFRkVSRU5DRSAiUkZDMjY4MSwgc2VjdGlvbiA0LjIuIiANCiAgICA6Oj0geyBy ZmMgMTggfSANCg0Kcm91bmR0cmlwRGVsYXlNaW5pbXVtIE9CSkVDVC1JREVOVElUWSANCiAgICBT VEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRlbnRp ZmllciBmb3IgdGhlIFR5cGUtUC1Sb3VuZC10cmlwLURlbGF5LU1pbmltdW0gDQogICAgICAgIG1l dHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiUkZDMjY4MSwgc2VjdGlvbiA0LjMuIiANCiAgICA6Oj0g eyByZmMgMTkgfSANCg0Kcm91bmR0cmlwRGVsYXlJbnZlcnNlUGVyY2VudGlsZSBPQkpFQ1QtSURF TlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAg ICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtUm91bmQtdHJpcC1JbnZlcnNlLVBlcmNl bnRpbGUgDQogICAgICAgIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiUkZDMjY4MSwgc2VjdGlv biA0LjQuIiANCiAgICA6Oj0geyByZmMgMjAgfSANCg0KLS0gDQotLSBSRkMzMzU3OiAiT25lLXdh eSBMb3NzIFBhdHRlcm4gU2FtcGxlIE1ldHJpY3MiICANCi0tIA0KDQpTdGVwaGFuICAgICAgICAg ICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMF0N CgwNCkludGVybmV0IERyYWZ0ICAgICAgICAgICBJUFBNIG1ldHJpY3MgcmVnaXN0cnkgICAgICAg ICAgICAgTm92ZW1iZXIgMjAwMw0KDQoNCg0Kb25lV2F5TG9zc0Rpc3RhbmNlU3RyZWFtIE9CSkVD VC1JREVOVElUWSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQog ICAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1PbmUtV2F5LUxvc3MtRGlzdGFu Y2UtU3RyZWFtIA0KICAgICAgICBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIiBSRkMzMzU3LCBz ZWN0aW9uIDUuNC4xLiIgDQogICAgOjo9eyByZmMgMjF9IA0KDQpvbmVXYXlMb3NzUGVyaW9kU3Ry ZWFtIE9CSkVDVC1JREVOVElUWSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJ UFRJT04gDQogICAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1PbmUtV2F5LUxv c3MtUGVyaW9kLVN0cmVhbSANCiAgICAgICAgbWV0cmljLiIgDQogICAgUkVGRVJFTkNFICIgUkZD MzM1Nywgc2VjdGlvbiA1LjQuMi4iIA0KICAgIDo6PXsgcmZjIDIyfSANCg0Kb25lV2F5TG9zc05v dGljZWFibGVSYXRlIE9CSkVDVC1JREVOVElUWSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQgDQog ICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1P bmUtV2F5LUxvc3MtTm90aWNlYWJsZS1SYXRlIA0KICAgICAgICBtZXRyaWMuIiANCiAgICBSRUZF UkVOQ0UgIiBSRkMzMzU3LCBzZWN0aW9uIDYuMS4iIA0KICAgIDo6PSB7IHJmYyAyMyB9IA0KDQpv bmVXYXlMb3NzUGVyaW9kVG90YWwgT0JKRUNULUlERU5USVRZIA0KICAgIFNUQVRVUyAgICAgY3Vy cmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRoZSBpZGVudGlmaWVyIGZvciB0aGUg VHlwZS1QLU9uZS1XYXktTG9zcy1QZXJpb2QtVG90YWwgDQogICAgICAgIG1ldHJpYy4iIA0KICAg IFJFRkVSRU5DRSAiIFJGQzMzNTcsIHNlY3Rpb24gNi4yLiIgDQogICAgOjo9IHsgcmZjIDI0IH0g DQoNCm9uZVdheUxvc3NQZXJpb2RMZW5ndGhzIE9CSkVDVC1JREVOVElUWSANCiAgICBTVEFUVVMg ICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRlbnRpZmllciBm b3IgdGhlIFR5cGUtUC1PbmUtV2F5LUxvc3MtUGVyaW9kLUxlbmd0aHMgDQogICAgICAgIG1ldHJp Yy4iIA0KICAgIFJFRkVSRU5DRSAiIFJGQzMzNTcsIHNlY3Rpb24gNi4zLiIgDQogICAgOjo9IHsg cmZjICAyNSB9IA0KDQpvbmVXYXlJbnRlckxvc3NQZXJpb2RMZW5ndGhzIE9CSkVDVC1JREVOVElU WSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJU aGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1PbmUtV2F5LUludGVyLUxvc3MtUGVyaW9kLQ0K ICAgICAgICBMZW5ndGhzIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiIFJGQzMzNTcsIHNlY3Rp b24gNi40LiIgDQogICAgOjo9IHsgcmZjIDI2IH0gDQoNCg0KLS0gDQoNCg0KU3RlcGhhbiAgICAg ICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MTFdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgSVBQTSBtZXRyaWNzIHJlZ2lzdHJ5ICAg ICAgICAgICAgIE5vdmVtYmVyIDIwMDMNCg0KDQotLSBSRkMzMzkzOiAgDQotLSAiSVAgUGFja2V0 IERlbGF5IFZhcmlhdGlvbiBNZXRyaWMgZm9yIElQIFBlcmZvcm1hbmNlIE1ldHJpY3MgKElQUE0p IiANCg0Kb25lV2F5SXBkdiBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50 IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBl LVAtT25lLXdheS1pcGR2IG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiIFJGQzMzOTMsIHNlY3Rp b24gMi4iIA0KICAgIDo6PSB7IHJmYyAyNyB9IA0KDQpvbmVXYXlJcGR2UG9pc3NvblN0cmVhbSBP QkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9O IA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdheS1pcGR2LVBv aXNzb24tc3RyZWFtIA0KICAgICAgICBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIiBSRkMzMzkz LCBzZWN0aW9uIDMuIiANCiAgICA6Oj0geyByZmMgMjggfSANCg0Kb25lV2F5SXBkdlBlcmNlbnRp bGUgT0JKRUNULUlERU5USVRZIA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQ VElPTiANCiAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1PbmUtd2F5LWlwZHYt cGVyY2VudGlsZSBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIiBSRkMzMzkzLCBzZWN0aW9uIDQu My4iIA0KICAgIDo6PSB7IHJmYyAyOSB9IA0KDQpvbmVXYXlJcGR2SW52ZXJzZVBlcmNlbnRpbGUg T0JKRUNULUlERU5USVRZIA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElP TiANCiAgICAgICAgIlRoZSBpZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLU9uZS13YXktaXBkdi1p bnZlcnNlLXBlcmNlbnRpbGUgDQogICAgICAgIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiIFJG QzMzOTMsIHNlY3Rpb24gNC40LiIgDQogICAgOjo9IHsgcmZjIDMwIH0gDQoNCg0Kb25lV2F5SXBk dkppdHRlciBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERF U0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdh eS1pcGR2LWppdHRlciBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIiBSRkMzMzkzLCBzZWN0aW9u IDQuNS4iIA0KICAgIDo6PSB7IHJmYyAzMSB9IA0KDQpvbmVXYXlQZWFrVG9QZWFrSXBkdiBPQkpF Q1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0K ICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdheS1wZWFrLXRvLXBl YWstaXBkdiANCiAgICAgICAgbWV0cmljLiIgDQogICAgUkVGRVJFTkNFICIgUkZDMzM5Mywgc2Vj dGlvbiA0LjYuIiANCiAgICA6Oj0geyByZmMgMzIgfSANCg0KLS0gDQotLSBSRkMzNDMyOiAiTmV0 d29yayBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCB3aXRoIHBlcmlvZGljIHN0cmVhbXMiIA0KLS0g DQoNClN0ZXBoYW4gICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgIElQUE0gbWV0 cmljcyByZWdpc3RyeSAgICAgICAgICAgICBOb3ZlbWJlciAyMDAzDQoNCg0KDQpvbmVXYXlEZWxh eVBlcmlvZGljU3RyZWFtIE9CSkVDVC1JREVOVElUWSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQg DQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUt UC1PbmUtd2F5LURlbGF5LVBlcmlvZGljLVN0cmVhbSANCiAgICAgICAgbWV0cmljLiIgDQogICAg UkVGRVJFTkNFICIgUkZDMzQzMiwgc2VjdGlvbiA0LiIgDQogICAgOjo9IHsgcmZjIDMzIH0gDQoN CkVORCANCg0KDQo4LiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgDQoNCiAgVGhlIElFVEYgdGFrZXMg bm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkgDQogIGlu dGVsbGVjdHVhbCBwcm9wZXJ0eSBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVk IHRvIA0KICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hu b2xvZ3kgZGVzY3JpYmVkIGluIA0KICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hp Y2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMgDQogIG1pZ2h0IG9yIG1pZ2h0IG5vdCBi ZSBhdmFpbGFibGU7IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCANCiAgaGFzIG1h ZGUgYW55IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuIEluZm9ybWF0aW9uIG9u IHRoZSANCiAgSUVURidzIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBzdGFu ZGFyZHMtdHJhY2sgYW5kIA0KICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBi ZSBmb3VuZCBpbiBCQ1AtMTEuIENvcGllcyBvZiANCiAgY2xhaW1zIG9mIHJpZ2h0cyBtYWRlIGF2 YWlsYWJsZSBmb3IgcHVibGljYXRpb24gYW5kIGFueSBhc3N1cmFuY2VzIG9mIA0KICBsaWNlbnNl cyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiBhdHRlbXB0IG1hZGUg dG8gDQogIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNl IG9mIHN1Y2ggDQogIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRvcnMgb3IgdXNlcnMg b2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbiANCiAgYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBT ZWNyZXRhcmlhdC4gDQoNCiAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0 byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueSANCiAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBw YXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeSANCiAgcmlnaHRzIHdoaWNo IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlIA0K ICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJ RVRGIEV4ZWN1dGl2ZSANCiAgRGlyZWN0b3IuIA0KDQo5LiBBY2tub3dsZWRnbWVudHMgDQoNCiAg VGhlIGF1dGhvciBncmF0ZWZ1bGx5IGFja25vd2xlZGdlcyBBbmR5IEJpZXJtYW4gYW5kIFJhbmR5 IFByZXN1aG4gZm9yIA0KICB0aGVpciBndWlkYW5jZSBhbmQgY29tbWVudHMuIA0KDQoxMC4gTm9y bWF0aXZlIFJlZmVyZW5jZXMgDQoNCiAgW1JGQzI1NzhdIE1jQ2xvZ2hyaWUsIEsuLCBQZXJraW5z LCBELiwgU2Nob2Vud2FlbGRlciwgSi4sIENhc2UsIEouLCANCiAgICAgUm9zZSwgTS4gYW5kIFMu IFdhbGRidXNzZXIsICJTdHJ1Y3R1cmUgb2YgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiANCiAgICAg VmVyc2lvbiAyIChTTUl2MikiLCBTVEQgNTgsIFJGQyAyNTc4LCBBcHJpbCAxOTk5LiANCg0KICBb UkZDMjU3OV0gTWNDbG9naHJpZSwgSy4sIFBlcmtpbnMsIEQuLCBTY2hvZW53YWVsZGVyLCBKLiwg Q2FzZSwgSi4sIA0KICAgICBSb3NlLCBNLiBhbmQgUy4gV2FsZGJ1c3NlciwgIlRleHR1YWwgQ29u dmVudGlvbnMgZm9yIFNNSXYyIiwgU1REIA0KICAgICA1OCwgUkZDIDI1NzksIEFwcmlsIDE5OTku IA0KDQoNCg0KDQpTdGVwaGFuICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAg ICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0IERyYWZ0ICAgICAgICAgICBJ UFBNIG1ldHJpY3MgcmVnaXN0cnkgICAgICAgICAgICAgTm92ZW1iZXIgMjAwMw0KDQoNCiAgW1JG QzI1ODBdIE1jQ2xvZ2hyaWUsIEsuLCBQZXJraW5zLCBELiwgU2Nob2Vud2FlbGRlciwgSi4sIENh c2UsIEouLCANCiAgICAgUm9zZSwgTS4gYW5kIFMuIFdhbGRidXNzZXIsICJDb25mb3JtYW5jZSBT dGF0ZW1lbnRzIGZvciBTTUl2MiIsIA0KICAgICBTVEQgNTgsIFJGQyAyNTgwLCBBcHJpbCAxOTk5 LiANCg0KMTEuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgDQoNCiAgW1JGQzIwMjZdIEJyYWRuZXIs IFMuLCAiVGhlIEludGVybmV0IFN0YW5kYXJkcyBQcm9jZXNzIC0tIFJldmlzaW9uIA0KICAgICAz IiwgQkNQIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYuIA0KDQogIFtSRkMyMzMwXSBQYXhzb24s IFYuLCBBbG1lcywgRy4sIE1haGRhdmksIEouIGFuZCBNLiBNYXRoaXMsIA0KICAgICAiRnJhbWV3 b3JrIGZvciBJUCBQZXJmb3JtYW5jZSBNZXRyaWNzIiwgUkZDIDIzMzAsIE1heSAxOTk4LiANCg0K ICBbUkZDMjY3OF0gTWFoZGF2aSBKLiBhbmQgVi4gUGF4c29uLCAiSVBQTSBNZXRyaWNzIGZvciBN ZWFzdXJpbmcgIA0KICAgICBDb25uZWN0aXZpdHkiLCBSRkMgMjY3OCwgU2VwdGVtYmVyIDE5OTku IA0KDQogIFtSRkMyNjc5XSBBbG1lcywgRy4sICBLYWxpZGluZGksIFMuICBhbmQgTS4gWmVrYXVz a2FzLCAiQSBPbmUtd2F5IA0KICAgICBEZWxheSBNZXRyaWMgZm9yIElQUE0iLCBSRkMgMjY3OSwg U2VwdGVtYmVyIDE5OTkuIA0KDQogIFtSRkMyNjgwXSBBbG1lcywgRy4sIEthbGlkaW5kaSwgUy4g YW5kIE0uIFpla2F1c2thcywgIkEgT25lLXdheSANCiAgICAgUGFja2V0IExvc3MgTWV0cmljIGZv ciBJUFBNIiwgUkZDIDI2ODAsIFNlcHRlbWJlciAxOTk5LiANCg0KICBbUkZDMjY4MV0gQWxtZXMs IEcuLCBLYWxpZGluZGksIFMuIGFuZCBNLiBaZWthdXNrYXMsICJBIFJvdW5kLXRyaXAgDQogICAg IERlbGF5IE1ldHJpYyBmb3IgSVBQTSIsIFJGQyAyNjgxLCBTZXB0ZW1iZXIgMTk5OS4gDQoNCiAg W1JGQzMzNTddIEtvb2RsaSwgUi4gYW5kIFJhdmlrYW50aCwgUi4sICJPbmUtd2F5IExvc3MgUGF0 dGVybiBTYW1wbGUgDQogICAgIE1ldHJpY3MiLCBSRkMgMzM1NywgQXVndXN0IDIwMDIuIA0KDQog IFtSRkMzMzkzXSBEZW1pY2hlbGlzLCBDLiBhbmQgUC4gQ2hpbWVudG8sICIgSVAgUGFja2V0IERl bGF5IFZhcmlhdGlvbiANCiAgICAgTWV0cmljIGZvciBJUCBQZXJmb3JtYW5jZSBNZXRyaWNzIChJ UFBNKSIsIFJGQyAzMzkzLCBOb3ZlbWJlciANCiAgICAgMjAwMi4gDQoNCiAgW1JGQzM0MTBdIENh c2UsIEouLCBNdW5keSwgUi4sIFBhcnRhaW4sIEQuIGFuZCBCLiBTdGV3YXJ0LCANCiAgICAgIklu dHJvZHVjdGlvbiBhbmQgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIGZvciBJbnRlcm5ldCBTdGFu ZGFyZCANCiAgICAgTWFuYWdlbWVudCBGcmFtZXdvcmsiLCBSRkMgMzQxMCwgRGVjZW1iZXIgMjAw Mi4gDQoNCiAgW1JGQzM0MzJdIFJhaXNhbmVuLCBWLiwgR3JvdGVmZWxkLCBHLiBhbmQgQS4gTW9y dG9uLCAiTmV0d29yayANCiAgICAgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgd2l0aCBwZXJpb2Rp YyBzdHJlYW1zIiwgUkZDIDM0MzIsIE5vdmVtYmVyIA0KICAgICAyMDAyLiANCg0KDQoNCjEyLiBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCg0KICBBbGwgdGhlIGl0ZW1zIHNwZWNpZmllZCBpbiB0 aGlzIE1JQiBtb2R1bGUgYXJlIGRlZmluZWQgdXNpbmcgdGhlIA0KICBtYWNybyBPQkpFQ1QtSURF TlRJVFkuIFRoaXMgbWFjcm8gZG9lcyBub3QgaGF2ZSBhIE1BWC1BQ0NFU1MgY2xhdXNlLiANCg0K ICBUaGVyZSBhcmUgbm8gbWFuYWdlbWVudCBvYmplY3RzIGRlZmluZWQgaW4gdGhpcyBNSUIgbW9k dWxlIHRoYXQgaGF2ZSANCiAgYSBNQVgtQUNDRVNTIGNsYXVzZSBvZiByZWFkLXdyaXRlIGFuZC9v ciByZWFkLWNyZWF0ZS4gIFNvLCBpZiB0aGlzIA0KICBNSUIgbW9kdWxlIGlzIGltcGxlbWVudGVk IGNvcnJlY3RseSwgdGhlbiB0aGVyZSBpcyBubyByaXNrIHRoYXQgYW4gDQogIGludHJ1ZGVyIGNh biBhbHRlciBvciBjcmVhdGUgYW55IG1hbmFnZW1lbnQgb2JqZWN0cyBvZiB0aGlzIE1JQiANCiAg bW9kdWxlIHZpYSBkaXJlY3QgU05NUCBTRVQgb3BlcmF0aW9ucy4gDQoNClN0ZXBoYW4gICAgICAg ICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0 XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgIElQUE0gbWV0cmljcyByZWdpc3RyeSAgICAg ICAgICAgICBOb3ZlbWJlciAyMDAzDQoNCg0KDQogIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgaW1w bGVtZW50ZXJzIGNvbnNpZGVyIHRoZSBzZWN1cml0eSBmZWF0dXJlcyBhcyANCiAgcHJvdmlkZWQg YnkgdGhlIFNOTVB2MyBmcmFtZXdvcmsgKHNlZSBbUkZDMzQxMF0sIHNlY3Rpb24gOCksIA0KICBp bmNsdWRpbmcgZnVsbCBzdXBwb3J0IGZvciB0aGUgU05NUHYzIGNyeXB0b2dyYXBoaWMgbWVjaGFu aXNtcyAoZm9yIA0KICBhdXRoZW50aWNhdGlvbiBhbmQgcHJpdmFjeSkuIA0KDQogIEZ1cnRoZXIs IGRlcGxveW1lbnQgb2YgU05NUCB2ZXJzaW9ucyBwcmlvciB0byBTTk1QdjMgaXMgTk9UIA0KICBS RUNPTU1FTkRFRC4gIEluc3RlYWQsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGRlcGxveSBTTk1QdjMg YW5kIHRvIA0KICBlbmFibGUgY3J5cHRvZ3JhcGhpYyBzZWN1cml0eS4gIEl0IGlzIHRoZW4gYSBj dXN0b21lci9vcGVyYXRvciANCiAgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdGhlIFNO TVAgZW50aXR5IGdpdmluZyBhY2Nlc3MgdG8gYW4gDQogIGluc3RhbmNlIG9mIHRoaXMgTUlCIG1v ZHVsZSBpcyBwcm9wZXJseSBjb25maWd1cmVkIHRvIGdpdmUgYWNjZXNzIHRvIA0KICB0aGUgb2Jq ZWN0cyBvbmx5IHRvIHRob3NlIHByaW5jaXBhbHMgKHVzZXJzKSB0aGF0IGhhdmUgbGVnaXRpbWF0 ZSANCiAgcmlnaHRzIHRvIGluZGVlZCBHRVQgb3IgU0VUIChjaGFuZ2UvY3JlYXRlL2RlbGV0ZSkg dGhlbS4gDQoNCjEzLiBBdXRob3IncyBBZGRyZXNzDQoNCiAgRW1pbGUgU1RFUEhBTiANCiAgRnJh bmNlIFRlbGVjb20gUiZEIA0KICAyLCBhdmVudWUgUGllcnJlIE1hcnppbiAgICAgICAgICAgICAg IA0KICBGLTIyMzA3IExhbm5pb24gY2VkZXggIA0KICBQaG9uZTogKyAzMyAyIDk2IDA1IDM2IDEw IA0KICBFbWFpbDogZW1pbGUuc3RlcGhhbkBmcmFuY2V0ZWxlY29tLmNvbSANCg0KDQoxNC4gRnVs bCBDb3B5cmlnaHQgU3RhdGVtZW50IA0KDQoNCiAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMjAwMykuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIA0KDQogIFRoaXMgZG9jdW1lbnQg YW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8gDQog IG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lz ZSBleHBsYWluIGl0IA0KICBvciBhc3Npc3QgaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVw YXJlZCwgY29waWVkLCBwdWJsaXNoZWQgYW5kIA0KICBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3Ig aW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkga2luZCwgDQogIHByb3ZpZGVkIHRo YXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZSANCiAg aW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVy LCB0aGlzIA0KICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5 LCBzdWNoIGFzIGJ5IHJlbW92aW5nIA0KICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVu Y2VzIHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyIA0KICBJbnRlcm5ldCBvcmdhbml6 YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiANCiAgZGV2ZWxvcGlu ZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgDQog IGNvcHlyaWdodHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVz dCBiZSANCiAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxh bmd1YWdlcyBvdGhlciB0aGFuIA0KICBFbmdsaXNoLiANCg0KICBUaGUgbGltaXRlZCBwZXJtaXNz aW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlIA0KICByZXZv a2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMu IA0KDQogIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IGlzIHByb3ZpZGVkIG9uIGFuIA0KICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09D SUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIA0KICBUQVNLIEZPUkNFIERJU0NMQUlN UyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgDQogIEJVVCBO T1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElP TiANCg0KDQpTdGVwaGFuICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAg ICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwNCkludGVybmV0IERyYWZ0ICAgICAgICAgICBJUFBN IG1ldHJpY3MgcmVnaXN0cnkgICAgICAgICAgICAgTm92ZW1iZXIgMjAwMw0KDQoNCiAgSEVSRUlO IFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBP RiANCiAgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF LiANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpTdGVwaGFuICAg ICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICBbUGFn ZSAxNl0NCg0K ------_=_NextPart_001_01C3A525.664D680A-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Nov 7 09:31:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15821 for ; Fri, 7 Nov 2003 09:31:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7dw-000097-PZ for ippm-archive@odin.ietf.org; Fri, 07 Nov 2003 09:31:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7EVKFU000554 for ippm-archive@odin.ietf.org; Fri, 7 Nov 2003 09:31:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7dt-00008p-QP for ippm-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 09:31:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15791 for ; Fri, 7 Nov 2003 09:31:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7ds-0005ns-00 for ippm-web-archive@ietf.org; Fri, 07 Nov 2003 09:31:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI7dr-0005np-00 for ippm-web-archive@ietf.org; Fri, 07 Nov 2003 09:31:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7dd-0008Um-TR; Fri, 07 Nov 2003 09:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI59y-0001jG-Qs for ippm@optimus.ietf.org; Fri, 07 Nov 2003 06:52:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11335; Fri, 7 Nov 2003 06:51:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI58y-0003er-00; Fri, 07 Nov 2003 06:51:12 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AI58v-0003ej-00; Fri, 07 Nov 2003 06:51:10 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 7 Nov 2003 12:50:55 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3A525.664D680A" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 7 Nov 2003 12:50:54 +0100 Message-ID: X-MS-Has-Attach: yes Thread-Topic: touch of the 'finale' version of the ippm metrics registry of the IPPM WG Thread-Index: AcMFh+Dka21ptADNTtWkV5tX2QS/8Cfm6Ccg From: "STEPHAN Emile FTRD/DAC/LAN" To: , Cc: "Matt Zekauskas" , "Henk Uijterwaal (RIPE-NCC)" , "Andy Bierman" , "JACQUENET Christian DRLD-ITP" X-OriginalArrivalTime: 07 Nov 2003 11:50:55.0171 (UTC) FILETIME=[66B05130:01C3A525] Subject: [ippm] touch of the 'finale' version of the ippm metrics registry of the IPPM WG Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A525.664D680A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C3A525.664D680A" ------_=_NextPart_002_01C3A525.664D680A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear, I don't see anymore the draft draft-ietf-ippm-metrics-registry-04.txt on the web page of the IPPM WG. It looks like it expired. So this is the version 5 of the ippm metrics registry: draft-ietf-ippm-metrics-registry-05.txt > This memo defines a registry of the IPPM working group metrics. It > assigns an OBJECT IDENTIFIER to each metric currently standardized by > the IPPM WG. It defines the rules for the identification of the > metrics standardized in the future. >=20 >=20 > Best regards > Emile >=20 >=20 <>=20 ------_=_NextPart_002_01C3A525.664D680A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable touch of the 'finale' version of the ippm metrics registry of = the IPPM WG

    Dear,

    I don't see = anymore the draft draft-ietf-ippm-metrics-registry-04.txt on the web = page of the IPPM WG. It looks like it expired.

    So this is the = version 5 of the ippm metrics registry: = draft-ietf-ippm-metrics-registry-05.txt

    This memo = defines a registry of the IPPM working group metrics. It assigns an = OBJECT IDENTIFIER to each metric currently standardized by the IPPM WG. = It defines the rules for the identification of the metrics standardized = in the future.


    Best = regards
    Emile


    = <<draft-ietf-ippm-metrics-registry-05.txt>>

------_=_NextPart_002_01C3A525.664D680A-- ------_=_NextPart_001_01C3A525.664D680A Content-Type: text/plain; name="draft-ietf-ippm-metrics-registry-05.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ippm-metrics-registry-05.txt Content-Disposition: attachment; filename="draft-ietf-ippm-metrics-registry-05.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEUuIFN0ZXBoYW4NCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZyYW5jZSBUZWxlY29tIFImRA0KRG9jdW1lbnQ6IGRyYWZ0 LWlldGYtaXBwbS1tZXRyaWNzLXJlZ2lzdHJ5LTA1LnR4dCAgICAgICAgICBOb3ZlbWJlciAyMDAz DQpDYXRlZ29yeTogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgSVBQTSBtZXRy aWNzIHJlZ2lzdHJ5ICANCg0KU3RhdHVzIG9mIHRoaXMgTWVtbyANCg0KDQogIFRoaXMgZG9jdW1l bnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCAN CiAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMgMjAyNiBbUkZDMjAyNl0uIA0K DQogIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nIA0KICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdv cmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQgb3RoZXIgDQogIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmli dXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gDQogIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cyANCiAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cyBhdCBhbnkgDQogIHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIElu dGVybmV0LSBEcmFmdHMgYXMgcmVmZXJlbmNlIA0KICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0g b3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iIA0KDQogIFRoZSBsaXN0IG9mIGN1cnJl bnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LiANCg0KICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1E cmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0IA0KICBodHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sLiANCg0KDQpBYnN0cmFjdCANCg0KICBUaGlzIG1lbW8gZGVm aW5lcyBhIHJlZ2lzdHJ5IG9mIHRoZSBJUFBNIHdvcmtpbmcgZ3JvdXAgbWV0cmljcy4gSXQgDQog IGFzc2lnbnMgYW4gT0JKRUNUIElERU5USUZJRVIgdG8gZWFjaCBtZXRyaWMgY3VycmVudGx5IHN0 YW5kYXJkaXplZCBieSANCiAgdGhlIElQUE0gV0cuIEl0IGRlZmluZXMgdGhlIHJ1bGVzIGZvciB0 aGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIA0KICBtZXRyaWNzIHN0YW5kYXJkaXplZCBpbiB0aGUg ZnV0dXJlLiANCg0KVGFibGUgb2YgQ29udGVudHMgDQoNCiAgMS4gICAgICBUaGUgSW50ZXJuZXQt U3RhbmRhcmQgTWFuYWdlbWVudCBGcmFtZXdvcmsuLi4uLi4uLi4uLi4uLi4uLi4uMg0KICAyLiAg ICAgIFRlcm1zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4yDQogIDMuICAgICAgT3ZlcnZpZXcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjINCiAgNC4gICAgICBUaGUgSVBQTSBGcmFtZXdvcmsu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMg0KICA1LiAgICAgIE92 ZXJ2aWV3Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4zDQogIDYuICAgICAgSVBQTSBtZXRyaWNzIFJlZ2lzdHJ5IGZyYW1ld29yay4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLjMNCiAgNi4xLiAgICBNZXRyaWNzIHJlZ2lzdHJ5IHRlbXBsYXRl Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNA0KICA2LjIuICAgIEluaXRpYWwg SVBQTSBtZXRyaWNzIHJlZ2lzdHJ5IGNyZWF0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41DQog IDYuMy4gICAgRnV0dXJlIElQUE0gbWV0cmljcyByZWdpc3RyYXRpb24uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjYNCiAgNi40LiAgICBNZXRyaWMgZGVmaW5lZCBpbiBjb29wZXJhdGlvbiB3 aXRoIG90aGVyIGJvZGllcy4uLi4uLi4uLi4uLi4uNg0KICA3LiAgICAgIEluaXRpYWwgSVBQTSBy ZWdpc3RyeSBkZWZpbml0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogIDguICAg ICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uMTMNCg0KU3RlcGhhbiAgICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAg SVBQTSBtZXRyaWNzIHJlZ2lzdHJ5ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDMNCg0KDQogIDku ICAgICAgQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTMNCiAgMTAuICAgICBOb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMw0KICAxMS4gICAgIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE0DQogIDEyLiAgICAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uMTQNCiAgMTMuICAgICBBdXRob3IncyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4xNQ0KICAxNC4gICAgIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVu dC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE1DQoNCg0KMS4gVGhlIEludGVy bmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrIA0KDQogIEZvciBhIGRldGFpbGVkIG92 ZXJ2aWV3IG9mIHRoZSBkb2N1bWVudHMgdGhhdCBkZXNjcmliZSB0aGUgY3VycmVudCANCiAgSW50 ZXJuZXQtU3RhbmRhcmQgTWFuYWdlbWVudCBGcmFtZXdvcmssIHBsZWFzZSByZWZlciB0byBzZWN0 aW9uIDcgb2YgDQogIFJGQyAzNDEwIFtSRkMzNDEwXS4gTWFuYWdlZCBvYmplY3RzIGFyZSBhY2Nl c3NlZCB2aWEgYSB2aXJ0dWFsIA0KICBpbmZvcm1hdGlvbiBzdG9yZSwgdGVybWVkIHRoZSBNYW5h Z2VtZW50IEluZm9ybWF0aW9uIEJhc2Ugb3IgTUlCLiAgDQogIE1JQiBvYmplY3RzIGFyZSBnZW5l cmFsbHkgYWNjZXNzZWQgdGhyb3VnaCB0aGUgU2ltcGxlIE5ldHdvcmsgDQogIE1hbmFnZW1lbnQg UHJvdG9jb2wgKFNOTVApLiBPYmplY3RzIGluIHRoZSBNSUIgYXJlIGRlZmluZWQgdXNpbmcgdGhl IA0KICBtZWNoYW5pc21zIGRlZmluZWQgaW4gdGhlIFN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50IElu Zm9ybWF0aW9uIChTTUkpLiANCiAgVGhpcyBtZW1vIHNwZWNpZmllcyBhIE1JQiBtb2R1bGUgdGhh dCBpcyBjb21wbGlhbnQgdG8gdGhlIFNNSXYyLCANCiAgd2hpY2ggaXMgZGVzY3JpYmVkIGluIFNU RCA1OCwgUkZDIDI1NzggW1JGQzI1NzhdLCBTVEQgNTgsIFJGQyAyNTc5IA0KICBbUkZDMjU3OV0g YW5kIFNURCA1OCwgUkZDIDI1ODAgW1JGQzI1ODBdLiANCg0KMi4gVGVybXMgDQoNCiAgVGhlIGtl eSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBO T1QiLCANCiAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgICJNQVkiLCBh bmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQg YXMgZGVzY3JpYmVkIGluIEJDUCAxNCwgUkZDIDIxMTkgDQogIFtSRkMyMTE5XS4gDQoNCjMuIE92 ZXJ2aWV3IA0KDQogIFRoaXMgbWVtbyBkZWZpbmVzIGEgcmVnaXN0cnkgb2YgdGhlIElQUE0gd29y a2luZyBncm91cCBtZXRyaWNzLiBJdCANCiAgYXNzaWducyBhbiBPQkpFQ1QgSURFTlRJRklFUiB0 byBlYWNoIG1ldHJpYyBjdXJyZW50bHkgc3RhbmRhcmRpemVkIGJ5IA0KICB0aGUgSVBQTSBXRy4g SXQgZGVmaW5lcyB0aGUgcnVsZXMgZm9yIHRoZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgDQogIG1l dHJpY3Mgc3RhbmRhcmRpemVkIGluIHRoZSBmdXR1cmUuIA0KDQo0LiBUaGUgSVBQTSBGcmFtZXdv cmsgDQoNCiAgVGhlIElQUE0gRnJhbWV3b3JrIGNvbnNpc3RzIGluIGZvdXIgbWFqb3IgY29tcG9u ZW50czoNCg0KICAgICAgKyBBIGdlbmVyYWwgZnJhbWV3b3JrIGZvciBkZWZpbmluZyBwZXJmb3Jt YW5jZSBtZXRyaWNzIA0KICAgICAgICBkZXNjcmliZWQgaW4gdGhlIEZyYW1ld29yayBmb3IgSVAg UGVyZm9ybWFuY2UgTWV0cmljcyBSRkMyMzMwIA0KICAgICAgICBbUkZDIDIzMzBdOyANCg0KICAg ICAgKyBBIHNldCBvZiBzdGFuZGFyZGl6ZWQgbWV0cmljcywgd2hpY2ggY29uZm9ybSB0byB0aGlz IA0KICAgICAgICBmcmFtZXdvcmsuIA0KDQogICAgICArIEVtZXJnaW5nIG1ldHJpY3Mgd2hpY2gg YXJlIGJlaW5nIHNwZWNpZmllZCBpbiByZXNwZWN0IG9mIHRoaXMgDQogICAgICAgIGZyYW1ld29y azsgDQoNCg0KDQoNClN0ZXBoYW4gICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sg ICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAg IElQUE0gbWV0cmljcyByZWdpc3RyeSAgICAgICAgICAgICBOb3ZlbWJlciAyMDAzDQoNCg0KICAg ICAgKyBUaGUgSVBQTS1SRVBPUlRJTkctTUlCIGZvciByZXBvcnRpbmcgdGhlIHJlc3VsdHMgb2Yg dGhlIA0KICAgICAgICBtZWFzdXJlcyBhbmQgZm9yIGludGVyZmFjaW5nIGhldGVyb2dlbmVvdXMg bWVhc3VyZW1lbnQgc3lzdGVtcw0KICAgICAgICB3aXRoIG1hbmFnZW1lbnQgZW50aXRpZXMuIA0K DQoNCjUuIE92ZXJ2aWV3IA0KDQogIFRoaXMgbWVtbyBkZWZpbmVzIGEgcmVnaXN0cnkgb2YgdGhl IGN1cnJlbnQgbWV0cmljcyBhbmQgYSBmcmFtZXdvcmsgDQogIGZvciB0aGUgaW50ZWdyYXRpb24g b2YgZnV0dXJlIG1ldHJpY3MgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczogDQoNCiAgICAgICsg dG8gcGVybWl0IG1ldHJpY3MgdG8gYmUgY2xlYXJseSByZWZlcmVuY2VkIGJ5IE1JQnMgb3Igb3Ro ZXIgZGF0YQ0KICAgICAgICBtb2RlbHM7IA0KDQogICAgICArIE1ldHJpY3MgaWRlbnRpZmllcnMg YXJlIG5lZWRlZCB0byBhbGxvdyBtZWFzdXJlbWVudCANCiAgICAgICAgaW50ZXJvcGVyYWJpbGl0 eTsgDQoNCiAgICAgICsgQXMgc3BlY2lmaWNhdGlvbiBvZiBuZXcgbWV0cmljcyBpcyBhIGNvbnRp bnVvdXMgcHJvY2Vzcywgc3BlY2lhbA0KICAgICAgICBjYXJlIG11c3QgYmUgdGFrZW4gZm9yIHRo ZSBpbnRlZ3JhdGlvbiBvZiBmdXR1cmUgc3RhbmRhcmRpemVkDQogICAgICAgIG1ldHJpY3M7IA0K DQogICAgICArIEFzIHRoZSBpbnRlbnQgb2YgdGhlIElQUE0gV0cgaXMgdG8gY29vcGVyYXRlIHdp dGggb3RoZXIgDQogICAgICAgIGFwcHJvcHJpYXRlIHN0YW5kYXJkcyBib2RpZXMgYW5kIG90aGVy IGFyZWFzIG9mIElFVEYgdG8gcHJvbW90ZQ0KICAgICAgICBjb25zaXN0ZW50IG1ldHJpY3MsIHRo ZXJlIGlzIGEgbmVlZCB0byBwZXJtaXQgcmVnaXN0cmF0aW9uIG9mIA0KICAgICAgICBzdWNoIG1l dHJpY3MuIA0KDQoNCjYuIElQUE0gbWV0cmljcyBSZWdpc3RyeSBmcmFtZXdvcmsgDQoNCiAgTUlC cyBuZWVkIE9CSkVDVCBJTkRFTlRJRklFUnMgdG8gcmVmZXIgcHJlY2lzZWx5IHRvIHRoZSBzdGFu ZGFyZGl6ZWQgDQogIG1ldHJpY3MuIFRoZSByZWdpc3RyeSBhc3NvY2lhdGVzIGFuIE9CSkVDVCBJ REVOVElGSUVSIHdpdGggZWFjaCANCiAgbWV0cmljLiBBcyBhbiBleGFtcGxlIG9uZVdheURlbGF5 IGFuZCBvbmVXYXlEZWxheVBvaXNzb25TdHJlYW0gaGF2ZSANCiAgZGlmZmVyZW50IGlkZW50aWZp ZXJzLiANCg0KICBUaGUgcmVnaXN0cnkgaGFzIDIgcm9vdCBicmFuY2hlcy4gVGhlIGNhdGVnb3J5 IG9mIHRoZSBkb2N1bWVudCANCiAgZGV0ZXJtaW5lcyB0aGUgbm9kZSB3aGljaCBicmFuY2ggdGhl IG1ldHJpYyBpcyBpZGVudGlmaWVkIGluOiANCg0KICAgICAgKyBNZXRyaWNzIGRlZmluZWQgaW4g YSBSRkMgYXJlIGlkZW50aWZpZWQgaW4gdGhlICdyZmMnIHRyZWU7IA0KICAgICAgKyBNZXRyaWNz IGRlZmluZWQgaW4gY29vcGVyYXRpb24gd2l0aCBvdGhlciBib2RpZXMgbWF5IGJlIA0KICAgICAg ICBpZGVudGlmaWVkIGluIHRoZSAnb3RoZXJCb2RpZXMnIHRyZWUuIA0KDQogIFRoZSBuYW1lIG9m IHRoZSBtZXRyaWMgaW4gdGhlIHJlZ2lzdHJ5IG11c3QgcmVzcGVjdCB0aGUgU01JdjIgcnVsZXMg DQogIGZvciBkZXNjcmlwdG9ycyAoW1JGQzI1NzhdLCBzZWN0aW9uIDMuMSkgYW5kIHNob3VsZCBi ZSBlYXNpbHkgDQogIHJlYWRhYmxlLiBDb25zZXF1ZW50bHkgdGhlIGZvbGxvd2luZyBpcyBhcHBs aWVkIHRvIGFkYXB0IHRoZSBuYW1lIA0KICB1c2VkIGluIHRoZSBtZXRyaWMgZGVmaW5pdGlvbjog DQoNCiAgICAgICsgVGhlIGZpcnN0IGxldHRlciBpcyBmb3JjZWQgdG8gbG93ZXIgY2FzZTsgDQog ICAgICArICctJyBhcmUgcmVtb3ZlZDsgDQogICAgICArIFRoZSBsZXR0ZXIgZm9sbG93aW5nIGEg Jy0nIGlzIGZvcmNlZCB0byB1cHBlciBjYXNlOyANCiAgICAgICsgJ1R5cGUtUCcgcHJlZml4IGlz IHJlbW92ZWQuIA0KDQoNCg0KU3RlcGhhbiAgICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBU cmFjayAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAg ICAgICAgSVBQTSBtZXRyaWNzIHJlZ2lzdHJ5ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDMNCg0K DQogIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBpbml0aWFsIHJlZ2lzdHJ5IG9mIHRoZSBleGlz dGluZyBtZXRyaWNzLiANCiAgRG9jdW1lbnRzIGRlZmluaW5nIG1ldHJpY3MgaW4gdGhlIGZ1dHVy ZSB3aWxsIGluY2x1ZGUgYSByZWdpc3RyeSANCiAgc2VjdGlvbiB0byBjbGVhcmx5IGlkZW50aWZ5 IHRoZXNlIG1ldHJpY3MuICANCg0KDQo2LjEuIE1ldHJpY3MgcmVnaXN0cnkgdGVtcGxhdGUgDQoN CiAgRWFjaCBtZW1vIGluY2x1ZGVzIGEgcmVnaXN0cnkgd2hpY2ggaWRlbnRpZmllcyB0aGUgbWV0 cmljcy4gVGhlIA0KICByZWdpc3RyeSBpcyBkZWZpbmVkIHVzaW5nIGEgTU9EVUxFLUlERU5USVRZ IG1hY3JvLiBUaGUgbmFtZSBvZiB0aGUgDQogIG1vZHVsZSBtdXN0IGJlIHVuaXF1ZS4gRWFjaCBt ZXRyaWMgaXMgaWRlbnRpZmllZCBpbiB0aGUgcmVnaXN0cnkgDQogIHVzaW5nIGFuIE9CSkVDVC1J REVOVElUWSBtYWNybyBkZWZpbmluZyB0aGUgbWV0cmljIG5hbWUsIHN0YXR1cywgDQogIHJlZmVy ZW5jZSBhbmQgT0JKRUNUIElERU5USUZJRVIuICANCg0KICBUaGUgcmVnaXN0cnkgaXMgZGVmaW5l ZCBpbiBhIGRlZGljYXRlZCBzZWN0aW9uIG9mIHRoZSBtZW1vLiANCg0KICBBcyBhbiBleGFtcGxl LCBjb25zaWRlciBhbiBpbXByb2JhYmxlIElQUE0gV0cgZHJhZnQgdGhhdCBkZWZpbmVzIDQgDQog IG1ldHJpY3MgaW4gdGhlIHNlY3Rpb25zIDQsIDQuMSwgNC4yIGFuZCA0LjMsIHJlc3BlY3RpdmVs eTogDQoNCiAgICAgICsgVHlwZS1QLVBhY2tldC1TcGVlZCBtZXRyaWM7IA0KICAgICAgKyBUeXBl LVAtQXZlcmFnZS1QYWNrZXQtU3BlZWQgbWV0cmljOyANCiAgICAgICsgVHlwZS1QLU1pbmltdW0t UGFja2V0LVNwZWVkIG1ldHJpYzsgDQogICAgICArIFR5cGUtUC1NYXhpbXVtLVBhY2tldC1TcGVl ZCBtZXRyaWMuIA0KDQogIEZvbGxvd2luZyBpcyB0aGUgcmVnaXN0cnkgdGhhdCBtYXkgYmUgaW5j bHVkZWQgaW4gdGhlIGRvY3VtZW50Og0KDQogICAgICArIFRoZSBuYW1lIG9mIHRoZSBzZWN0aW9u IGlzICdJUFBNIFBhY2tldCBTcGVlZCBtZXRyaWNzIHJlZ2lzdHJ5JzsNCiAgICAgICsgVGhlIG5h bWUgb2YgdGhlIG1vZHVsZSBpcyBpcHBtUGFja2V0U3BlZWRNZXRyaWNzUmVnaXN0cnk7IA0KICAg ICAgKyAnTicgaXMgdGhlIG5vZGUgYXNzaWduZWQgYnkgSUFOQSB0byB0aGUgcmVnaXN0cnkgbW9k dWxlOyANCiAgICAgICsgVGhlIG5leHQgZnJlZSBub2RlIG9mIHRoZSBzdWIgdHJlZSBpcHBtTWV0 cmljc1JlZ2lzdHJ5LnJmYygxKSBpcw0KICAgICAgICAnMzQnLiANCg0KSVBQTS1QQUNLRVQtU1BF RUQtTUVUUklDUy1SRUdJU1RSWSBERUZJTklUSU9OUyA6Oj0gQkVHSU4gDQoNCklNUE9SVFMgDQog ICAgT0JKRUNULUlERU5USVRZLCBNT0RVTEUtSURFTlRJVFksIG1pYi0yIA0KICAgICAgICBGUk9N IFNOTVB2Mi1TTUkgDQogICAgcmZjIA0KICAgICAgICBGUk9NIElQUE0tTUVUUklDUy1SRUdJU1RS WTsgDQoNCg0KaXBwbVBhY2tldFNwZWVkTWV0cmljc1JlZ2lzdHJ5IE1PRFVMRS1JREVOVElUWSAg DQogICAgTEFTVC1VUERBVEVEICJZWVlZTU1ERDAwMDBaIiANCiAgICBPUkdBTklaQVRJT04gICAg ICAgIklFVEYgSVBQTSB3b3JraW5nIEdyb3VwIiANCiAgICBDT05UQUNULUlORk8gICAgICAgIiAN Cg0KDQogICAgICAgICAgIFRlbDogIA0KICAgICAgICBFLW1haWw6ICANCiAgICAgICAgUG9zdGFs OiAgDQoNCg0KDQpTdGVwaGFuICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0IERyYWZ0ICAgICAgICAgICBJ UFBNIG1ldHJpY3MgcmVnaXN0cnkgICAgICAgICAgICAgTm92ZW1iZXIgMjAwMw0KDQoNCiAgICAg ICAgU2VuZCBjb21tZW50cyB0byA8aXBwbUBpZXRmLm9yZz4gDQogICAgICAgIE1haWxpbmcgbGlz dCBzdWJzY3JpcHRpb24gaW5mbzogDQogICAgICAgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwcG0gIiANCiAgICBERVNDUklQVElPTiAgDQogICAgICAgICIgVGhpcyBt ZW1vIGRlZmluZXMgdGhlIHJlZ2lzdHJ5IGZvciBJUFBNIFBhY2tldCBTcGVlZCBtZXRyaWNzLiAN Cg0KICAgICAgICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAzKS4gIA0K DQogICAgICAgIFRoaXMgdmVyc2lvbiBvZiB0aGlzIE1JQiBtb2R1bGUgaXMgcGFydCBvZiBSRkMg eXl5eTsgc2VlIHRoZSANCiAgICAgICAgUkZDIGl0c2VsZiBmb3IgZnVsbCBsZWdhbCBub3RpY2Vz LiIgDQogICAgUkVWSVNJT04gICAgICAiWVlZWU1NREQwMDAwWiIgDQogICAgREVTQ1JJUFRJT04g DQogICAgICAgICJJbml0aWFsIHZlcnNpb24gb2YgdGhlIG1vZHVsZSBvZiB0aGUgcmVnaXN0cnkg Zm9yIElQUE0gUGFja2V0IA0KICAgICAgICBTcGVlZCBtZXRyaWNzLiANCiAgICAgICAgVGhpcyB2 ZXJzaW9uIHB1Ymxpc2hlZCBhcyBSRkMgeXl5eS4iIA0KICAgIDo6PSB7IG1pYi0yIE4gfSAgDQoN CmlwcG1QYWNrZXRTcGVlZE1ldHJpYyBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTIGN1cnJl bnQgDQogICAgREVTQ1JJUFRJT04gIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBU eXBlLVAtUGFja2V0LVNwZWVkIG1ldHJpYy4iIA0KICBSRUZFUkVOQ0UgIlJGQ3l5eXksIHNlY3Rp b24gNC4iIA0KICA6Oj0geyByZmMgMzQgfSANCg0KaXBwbUF2Z1BhY2tldFNwZWVkbWV0cmljICBP QkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gIA0K ICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtQXZlcmFnZS1QYWNrZXQtU3Bl ZWQgbWV0cmljLiIgDQogICAgUkVGRVJFTkNFICJSRkN5eXl5LCBzZWN0aW9uIDQuMS4iIA0KICAg IDo6PSB7IHJmYyAzNSB9IA0KDQppcHBtTWluUGFja2V0U3BlZWRtZXRyaWMgIE9CSkVDVC1JREVO VElUWSANCiAgICBTVEFUVVMgY3VycmVudCANCiAgICBERVNDUklQVElPTiAgDQogICAgICAgICJU aGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1NaW5pbXVtLVBhY2tldC1TcGVlZCBtZXRyaWMu IiANCiAgICBSRUZFUkVOQ0UgIlJGQ3l5eXksIHNlY3Rpb24gNC4yLiIgDQogICAgOjo9IHsgcmZj IDM2IH0gDQoNCmlwcG1NYXhQYWNrZXRTcGVlZG1ldHJpYyAgT0JKRUNULUlERU5USVRZIA0KICAg IFNUQVRVUyBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OICANCiAgICAgICAgIlRoZSBpZGVudGlm aWVyIGZvciB0aGUgVHlwZS1QLU1heGltdW0tUGFja2V0LVNwZWVkIG1ldHJpYy4iIA0KICAgIFJF RkVSRU5DRSAiUkZDeXl5eSwgc2VjdGlvbiA0LjMuIiANCiAgICA6Oj0geyByZmMgMzcgfSANCg0K RU5EICAgICAgDQoNCg0KNi4yLiBJbml0aWFsIElQUE0gbWV0cmljcyByZWdpc3RyeSBjcmVhdGlv biANCg0KDQoNClN0ZXBoYW4gICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAg ICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgIElQ UE0gbWV0cmljcyByZWdpc3RyeSAgICAgICAgICAgICBOb3ZlbWJlciAyMDAzDQoNCg0KICBUaGUg aW5pdGlhbCByZWdpc3RyeSBpZGVudGlmaWVzIHRoZSBtZXRyaWNzIGN1cnJlbnRseSBkZWZpbmVk IGluIHRoZSANCiAgUkZDcyBwcm9kdWNlZCBpbiB0aGUgSVBQTSBXRy4gDQoNCiAgQnkgbm93LCB0 aGUgSVBQTSBXRyBkZWZpbmVkIDMzIG1ldHJpY3MgcmVsYXRlZCB0byA3IHRvcGljczogDQoNCiAg ICAgICsgSVBQTSBNZXRyaWNzIGZvciBNZWFzdXJpbmcgQ29ubmVjdGl2aXR5LCBSRkMgMjY3OCBb UkZDMjY3OF07IA0KICAgICAgKyBPbmUtd2F5IERlbGF5IE1ldHJpY3MsIFJGQyAyNjc5ICBbUkZD MjY3OV07IA0KICAgICAgKyBPbmUtd2F5IFBhY2tldCBMb3NzIE1ldHJpY3MsIFJGQyAyNjgwIFtS RkMyNjgwXTsgDQogICAgICArIFJvdW5kLXRyaXAgRGVsYXkgTWV0cmljcywgUkZDIDI2ODEgW1JG QzI2ODFdOyANCiAgICAgICsgT25lLXdheSBMb3NzIFBhdHRlcm4gU2FtcGxlIE1ldHJpY3MsIFJG QyAzMzU3IFtSRkMzMzU3XTsgDQogICAgICArIElQIFBhY2tldCBEZWxheSBWYXJpYXRpb24gTWV0 cmljLCBSRkMgMzM5MyBbUkZDMzM5M107IA0KICAgICAgKyBJUFBNIE1ldHJpY3MgZm9yIHBlcmlv ZGljIHN0cmVhbXMsIFJGQyAzNDMyIFtSRkMzNDMyXTsgDQoNClRoZXkgYXJlIHJlZ2lzdGVyZWQg aW4gdGhlIG5vZGUgcmZjKDEpLiBUaGV5IGFyZSBudW1iZXJlZCB1c2luZyB0aGUgUkZDIA0Kb3Jk ZXIgYW5kIHRoZSBtZXRyaWNzIGRlZmluaXRpb25zIG9yZGVyIGluIGVhY2ggbWVtby4gVGhlIG5v ZGUgYXNzaWduZWQgDQp0byBhIG1ldHJpYyBpcyBkZWZpbml0aXZlIGFuZCBjYW5ub3QgYmUgcmV1 c2VkLiANCg0KNi4zLiBGdXR1cmUgSVBQTSBtZXRyaWNzIHJlZ2lzdHJhdGlvbiANCg0KICBXaGVu IHRoZSBJUFBNIFdHIGRyYWZ0IGlzIGNvbnNpZGVyZWQgbWF0dXJlIGVub3VnaDogDQoNCiAgICAg ICsgVGhlIGNoYWlyIG9mIHRoZSBJUFBNIFdHLCBvciBzb21lb25lIHByb3Bvc2VkIGJ5IHRoZSBk aXJlY3RvcnMgDQogICAgICAgIG9mIHRoZSBUcmFuc3BvcnQgQXJlYSwgYXNzaWducyB0byBlYWNo IG1ldHJpYyBhIHN1YiBub2RlIGNob3Nlbg0KICAgICAgICBpbiB0aGUgdHJlZSByZmMoMSkgb2Yg dGhlIElQUE0tTUVUUklDUy1SRUdJU1RSWTsgDQoNCiAgICAgICsgQXV0aG9ycyBpbnNlcnQgYSBy ZWdpc3RyeSB0ZW1wbGF0ZSBpbiB0aGVpciBkb2N1bWVudC4gVGhlbiB0aGV5DQogICAgICAgIGNy ZWF0ZSBhbiBPQkpFQ1QtSURFTlRJVFkgaW5zdGFuY2UgcGVyIG1ldHJpYyBhbmQgY29tcGxldGUg dGhlIA0KICAgICAgICBpbnN0YW5jZSB3aXRoIHRoZSBhc3NpZ25lZCBzdWIgbm9kZXMuIA0KDQog IFRoYXQgaGVscHMgdG8gcHJlcGFyZSB0aGUgZmluYWwgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIE1v cmVvdmVyIGl0IA0KICBmYWNpbGl0YXRlcyBzb2Z0d2FyZSBpbnRlZ3JhdGlvbiBhbmQgaW50ZXJv cGVyYWJpbGl0eSBtZWFzdXJlbWVudCANCiAgZHVyaW5nIHRoZSBzcGVjaWZpY2F0aW9uIHByb2Nl c3MuIA0KDQo2LjQuIE1ldHJpYyBkZWZpbmVkIGluIGNvb3BlcmF0aW9uIHdpdGggb3RoZXIgYm9k aWVzIA0KDQogIFN1Y2ggbWV0cmljcyBtYXkgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgbm9kZSBvdGhl ckJvZGllcygyKS4gDQoNCiAgTm90aGluZyBwcmV2ZW50cyB0aGVzZSBib2RpZXMgZnJvbSByZWdp c3RlcmluZyBtZXRyaWNzIGluIHRoZWlyIG93biANCiAgb2JqZWN0IGlkZW50aWZpZXIgdHJlZXMu IA0KDQoNCjcuIEluaXRpYWwgSVBQTSByZWdpc3RyeSBkZWZpbml0aW9uIA0KDQpJUFBNLU1FVFJJ Q1MtUkVHSVNUUlkgREVGSU5JVElPTlMgOjo9IEJFR0lOIA0KDQpJTVBPUlRTIA0KICAgIE9CSkVD VC1JREVOVElUWSwgTU9EVUxFLUlERU5USVRZLCBtaWItMiANCiAgICAgICAgRlJPTSBTTk1QdjIt U01JOyAgICAgICAgICAgICAgICAgICAgICAgIA0KDQppcHBtTWV0cmljc1JlZ2lzdHJ5IE1PRFVM RS1JREVOVElUWSANCiAgICBMQVNULVVQREFURUQgIjIwMDMwNDE3MDAwMFoiICAgIC0tIEFwcmls IDE3dGgsIDIwMDMgDQoNClN0ZXBoYW4gICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJh Y2sgICAgICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgIElQUE0gbWV0cmljcyByZWdpc3RyeSAgICAgICAgICAgICBOb3ZlbWJlciAyMDAzDQoNCg0K ICAgIE9SR0FOSVpBVElPTiAgICAgICAiSUVURiBJUFBNIHdvcmtpbmcgR3JvdXAiIA0KICAgIENP TlRBQ1QtSU5GTyAgICAgICAiIA0KICAgICAgICAgICAgICAgIEVtaWxlIFNURVBIQU4gDQogICAg ICAgICAgICAgICAgRnJhbmNlIFRlbGVjb20gUiZEIA0KICAgICAgICAgICBUZWw6ICsxIDMzIDIg OTYgMDUgMzYgMTAgDQogICAgICAgIEUtbWFpbDogZW1pbGUuc3RlcGhhbkBmcmFuY2V0ZWxlY29t LmNvbSANCiAgICAgICAgUG9zdGFsOiAyLCBhdmVudWUgUGllcnJlIE1hcnppbiANCiAgICAgICAg ICAgICAgICBMYW5uaW9uLCBGUkFOQ0UgMjIzMDcgDQoNCiAgICAgICAgU2VuZCBjb21tZW50cyB0 byA8aXBwbUBpZXRmLm9yZz4gDQogICAgICAgIE1haWxpbmcgbGlzdCBzdWJzY3JpcHRpb24gaW5m bzogDQogICAgICAgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwcG0g IiANCiAgICBERVNDUklQVElPTiAgDQogICAgICAgICJUaGlzIG1lbW8gZGVmaW5lcyBhIHJlZ2lz dHJ5IG9mIHRoZSBJUFBNIHdvcmtpbmcgZ3JvdXAgDQogICAgICAgIG1ldHJpY3MuIA0KDQoNCiAg ICAgICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMykuIFRoaXMgdmVy c2lvbiBvZiB0aGlzIA0KICAgICAgICBNSUIgbW9kdWxlIGlzIHBhcnQgb2YgUkZDIHl5eXk7IHNl ZSB0aGUgUkZDIGl0c2VsZiBmb3IgZnVsbCANCiAgICAgICAgbGVnYWwgbm90aWNlcy4iIA0KICAg IFJFVklTSU9OICAgICAgIjIwMDMwNDE3MDAwMFoiICAgIC0tIEFwcmlsIDE3dGgsIDIwMDMgDQog ICAgREVTQ1JJUFRJT04gDQogICAgICAgICJJbml0aWFsIHZlcnNpb24gb2YgdGhlIElQUE0gbWV0 cmljcyByZWdpc3RyeSBtb2R1bGUuIA0KICAgICAgICAgVGhpcyB2ZXJzaW9uIHB1Ymxpc2hlZCBh cyBSRkMgeXl5eS4iIA0KICAgIDo6PSB7IG1pYi0yIFhYWCB9ICAtLSBYWFggdG8gYmUgYXNzaWdu ZWQgYnkgSUFOQQ0KDQpyZmMgICAgICAgICAgICAgT0JKRUNUIElERU5USUZJRVIgICAgOjo9IHsg aXBwbU1ldHJpY3NSZWdpc3RyeSAxIH0gIA0Kb3RoZXJCb2RpZXMgICAgIE9CSkVDVCBJREVOVElG SUVSICAgIDo6PSB7IGlwcG1NZXRyaWNzUmVnaXN0cnkgMiB9ICANCg0KICAtLSANCiAgLS0gUmVn aXN0cnkgb2YgdGhlIG1ldHJpY3Mgb2YgdGhlIElQUE0gV0cgUkZDcyANCiAgLS0gDQoNCiAgLS0g DQogIC0tIFJGQyAyNjc4ICIgSVBQTSBNZXRyaWNzIGZvciBNZWFzdXJpbmcgQ29ubmVjdGl2aXR5 IiANCiAgLS0gDQoNCmluc3RhbnRVbmlkaXJlY3Rpb25Db25uZWN0aXZpdHkgT0JKRUNULUlERU5U SVRZIA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAg IlRoZSBpZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLUluc3RhbnRhbmVvdXMtVW5pZGlyZWN0aW9u YWwtDQogICAgICAgIENvbm5lY3Rpdml0eSBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIlJGQzI2 NzgsIHNlY3Rpb24gMi4iIA0KICAgIDo6PXtyZmMgMX0gDQoNCmluc3RhbnRCaWRpcmVjdGlvbkNv bm5lY3Rpdml0eSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAg IERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtSW5z dGFudGFuZW91cy1CaWRpcmVjdGlvbmFsLQ0KICAgICAgICBDb25uZWN0aXZpdHkgbWV0cmljLiIg DQogICAgUkVGRVJFTkNFICJSRkMyNjc4LCBzZWN0aW9uIDMuIiANCg0KU3RlcGhhbiAgICAgICAg ICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDdd DQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgSVBQTSBtZXRyaWNzIHJlZ2lzdHJ5ICAgICAg ICAgICAgIE5vdmVtYmVyIDIwMDMNCg0KDQogICAgOjo9e3JmYyAyfSANCg0KaW50ZXJ2YWxVbmlk aXJlY3Rpb25Db25uZWN0aXZpdHkgT0JKRUNULUlERU5USVRZIA0KICAgIFNUQVRVUyAgICAgY3Vy cmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRoZSBpZGVudGlmaWVyIGZvciB0aGUg VHlwZS1QLUludGVydmFsLVVuaWRpcmVjdGlvbmFsLQ0KICAgICAgICBDb25uZWN0aXZpdHkgbWV0 cmljLiIgDQogICAgUkVGRVJFTkNFICJSRkMyNjc4LCBzZWN0aW9uIDQuIiANCiAgICA6Oj0geyBy ZmMgMyB9IA0KDQppbnRlcnZhbEJpZGlyZWN0aW9uQ29ubmVjdGl2aXR5IE9CSkVDVC1JREVOVElU WSANCiAgICBTVEFUVVMgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRoZSBp ZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLUludGVydmFsLUJpZGlyZWN0aW9uYWwtDQogICAgICAg IENvbm5lY3Rpdml0eSBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIlJGQzI2NzgsIHNlY3Rpb24g NS4iIA0KICAgIDo6PSB7IHJmYyAgNCB9IA0KDQppbnRlcnZhbFRlbXBvcmFsQ29ubmVjdGl2aXR5 IE9CSkVDVC1JREVOVElUWSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJ T04gDQogICAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUDEtUDItSW50ZXJ2YWwt VGVtcG9yYWwtDQogICAgICAgIENvbm5lY3Rpdml0eSBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0Ug IlJGQzI2NzgsIHNlY3Rpb24gNi4iIA0KICAgIDo6PSB7IHJmYyAgNSB9IA0KDQotLSANCi0tIFJG QyAyNjc5ICJBIE9uZS13YXkgRGVsYXkgTWV0cmljIGZvciBJUFBNIiANCi0tIA0KDQpvbmVXYXlE ZWxheSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NS SVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdheS1E ZWxheSBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIlJGQzI2NzksIHNlY3Rpb24gMy4iIA0KICAg IDo6PSB7IHJmYyAgNiB9IA0KDQpvbmVXYXlEZWxheVBvaXNzb25TdHJlYW0gT0JKRUNULUlERU5U SVRZIA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAg IlRoZSBpZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLU9uZS13YXktRGVsYXktUG9pc3Nvbi1TdHJl YW0gDQogICAgICAgIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiUkZDMjY3OSwgc2VjdGlvbiA0 LiIgDQogICAgOjo9IHsgcmZjICA3IH0gDQoNCm9uZVdheURlbGF5UGVyY2VudGlsZSBPQkpFQ1Qt SURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAg ICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdheS1EZWxheS1QZXJjZW50 aWxlIA0KICAgICAgICBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIlJGQzI2NzksIHNlY3Rpb24g NS4xLiIgDQoNCg0KU3RlcGhhbiAgICAgICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAg SVBQTSBtZXRyaWNzIHJlZ2lzdHJ5ICAgICAgICAgICAgIE5vdmVtYmVyIDIwMDMNCg0KDQogICAg Ojo9IHsgcmZjICA4IH0gDQoNCm9uZVdheURlbGF5TWVkaWFuIE9CSkVDVC1JREVOVElUWSANCiAg ICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRl bnRpZmllciBmb3IgdGhlIFR5cGUtUC1PbmUtd2F5LURlbGF5LU1lZGlhbiBtZXRyaWMuIiANCiAg ICBSRUZFUkVOQ0UgIlJGQzI2NzksIHNlY3Rpb24gNS4yLiIgDQogICAgOjo9IHsgcmZjICA5IH0g DQoNCm9uZVdheURlbGF5TWluaW11bSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBj dXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRo ZSBUeXBlLVAtT25lLXdheS1EZWxheS1NaW5pbXVtIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAi UkZDMjY3OSwgc2VjdGlvbiA1LjMuIiANCiAgICA6Oj0geyByZmMgMTAgfSANCg0Kb25lV2F5RGVs YXlJbnZlcnNlUGVyY2VudGlsZSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJy ZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBU eXBlLVAtT25lLXdheS1EZWxheS1JbnZlcnNlLVBlcmNlbnRpbGUgDQogICAgICAgIG1ldHJpYy4g IiANCiAgICBSRUZFUkVOQ0UgIlJGQzI2NzksIHNlY3Rpb24gNS40LiIgDQogICAgOjo9IHsgcmZj IDExIH0gDQoNCi0tIA0KLS0gUkZDIDI2ODAgICJPbmUgV2F5IFBhY2tldCBMb3NzIE1ldHJpYyBm b3IgSVBQTSIgDQotLSANCg0Kb25lV2F5UGFja2V0TG9zcyBPQkpFQ1QtSURFTlRJVFkgDQogICAg U1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50 aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdheS1QYWNrZXQtTG9zcyBtZXRyaWMuIiANCiAgICBS RUZFUkVOQ0UgIlJGQzI2ODAsIHNlY3Rpb24gMi4iIA0KICAgIDo6PSB7IHJmYyAxMiB9IA0KDQpv bmVXYXlQYWNrZXRMb3NzUG9pc3NvblN0cmVhbSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVT ICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIg Zm9yIHRoZSBUeXBlLVAtT25lLXdheS1QYWNrZXQtTG9zcy1Qb2lzc29uLQ0KICAgICAgICBTdHJl YW0gbWV0cmljLiIgDQogICAgUkVGRVJFTkNFICJSRkMyNjgwLCBzZWN0aW9uIDMuIiANCiAgICA6 Oj0geyByZmMgMTMgfSANCg0Kb25lV2F5UGFja2V0TG9zc0F2ZXJhZ2UgT0JKRUNULUlERU5USVRZ IA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRo ZSBpZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLU9uZS13YXktUGFja2V0LUxvc3MtQXZlcmFnZSAN CiAgICAgICAgbWV0cmljLiIgDQogICAgUkVGRVJFTkNFICJSRkMyNjgwLCBzZWN0aW9uIDQuIiAN CiAgICA6Oj0geyByZmMgMTQgfSANCg0KLS0gDQoNClN0ZXBoYW4gICAgICAgICAgICAgICAgICAg ICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJu ZXQgRHJhZnQgICAgICAgICAgIElQUE0gbWV0cmljcyByZWdpc3RyeSAgICAgICAgICAgICBOb3Zl bWJlciAyMDAzDQoNCg0KLS0gUkZDMjY4MSAiQSBSb3VuZC10cmlwIERlbGF5IE1ldHJpYyBmb3Ig SVBQTSIgDQotLSANCg0Kcm91bmR0cmlwRGVsYXkgT0JKRUNULUlERU5USVRZIA0KICAgIFNUQVRV UyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRoZSBpZGVudGlmaWVy IGZvciB0aGUgVHlwZS1QLVJvdW5kLXRyaXAtRGVsYXkgbWV0cmljLiIgDQogICAgUkVGRVJFTkNF ICIgc2VjdGlvbiAyIG9mIHRoZSByZmMyNjgxLiIgDQogICAgOjo9IHsgcmZjIDE1IH0gDQoNCnJv dW5kdHJpcERlbGF5UG9pc3NvblN0cmVhbSBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAg ICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9y IHRoZSBUeXBlLVAtUm91bmQtdHJpcC1EZWxheS1Qb2lzc29uLVN0cmVhbSANCiAgICAgICAgbWV0 cmljLiIgDQogICAgUkVGRVJFTkNFICJSRkMyNjgxLCBzZWN0aW9uIDQuIiANCiAgICA6Oj0geyBy ZmMgMTYgfSANCg0Kcm91bmR0cmlwRGVsYXlQZXJjZW50aWxlIE9CSkVDVC1JREVOVElUWSANCiAg ICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRl bnRpZmllciBmb3IgdGhlIFR5cGUtUC1Sb3VuZC10cmlwLURlbGF5LVBlcmNlbnRpbGUgDQogICAg ICAgIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiUkZDMjY4MSwgc2VjdGlvbiA0LjEuIiANCiAg ICA6Oj0geyByZmMgMTcgfSANCg0Kcm91bmR0cmlwRGVsYXlNZWRpYW4gT0JKRUNULUlERU5USVRZ IA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRo ZSBpZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLVJvdW5kLXRyaXAtRGVsYXktTWVkaWFuIG1ldHJp Yy4iIA0KICAgIFJFRkVSRU5DRSAiUkZDMjY4MSwgc2VjdGlvbiA0LjIuIiANCiAgICA6Oj0geyBy ZmMgMTggfSANCg0Kcm91bmR0cmlwRGVsYXlNaW5pbXVtIE9CSkVDVC1JREVOVElUWSANCiAgICBT VEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRlbnRp ZmllciBmb3IgdGhlIFR5cGUtUC1Sb3VuZC10cmlwLURlbGF5LU1pbmltdW0gDQogICAgICAgIG1l dHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiUkZDMjY4MSwgc2VjdGlvbiA0LjMuIiANCiAgICA6Oj0g eyByZmMgMTkgfSANCg0Kcm91bmR0cmlwRGVsYXlJbnZlcnNlUGVyY2VudGlsZSBPQkpFQ1QtSURF TlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAg ICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtUm91bmQtdHJpcC1JbnZlcnNlLVBlcmNl bnRpbGUgDQogICAgICAgIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiUkZDMjY4MSwgc2VjdGlv biA0LjQuIiANCiAgICA6Oj0geyByZmMgMjAgfSANCg0KLS0gDQotLSBSRkMzMzU3OiAiT25lLXdh eSBMb3NzIFBhdHRlcm4gU2FtcGxlIE1ldHJpY3MiICANCi0tIA0KDQpTdGVwaGFuICAgICAgICAg ICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMF0N CgwNCkludGVybmV0IERyYWZ0ICAgICAgICAgICBJUFBNIG1ldHJpY3MgcmVnaXN0cnkgICAgICAg ICAgICAgTm92ZW1iZXIgMjAwMw0KDQoNCg0Kb25lV2F5TG9zc0Rpc3RhbmNlU3RyZWFtIE9CSkVD VC1JREVOVElUWSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQog ICAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1PbmUtV2F5LUxvc3MtRGlzdGFu Y2UtU3RyZWFtIA0KICAgICAgICBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIiBSRkMzMzU3LCBz ZWN0aW9uIDUuNC4xLiIgDQogICAgOjo9eyByZmMgMjF9IA0KDQpvbmVXYXlMb3NzUGVyaW9kU3Ry ZWFtIE9CSkVDVC1JREVOVElUWSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJ UFRJT04gDQogICAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1PbmUtV2F5LUxv c3MtUGVyaW9kLVN0cmVhbSANCiAgICAgICAgbWV0cmljLiIgDQogICAgUkVGRVJFTkNFICIgUkZD MzM1Nywgc2VjdGlvbiA1LjQuMi4iIA0KICAgIDo6PXsgcmZjIDIyfSANCg0Kb25lV2F5TG9zc05v dGljZWFibGVSYXRlIE9CSkVDVC1JREVOVElUWSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQgDQog ICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1P bmUtV2F5LUxvc3MtTm90aWNlYWJsZS1SYXRlIA0KICAgICAgICBtZXRyaWMuIiANCiAgICBSRUZF UkVOQ0UgIiBSRkMzMzU3LCBzZWN0aW9uIDYuMS4iIA0KICAgIDo6PSB7IHJmYyAyMyB9IA0KDQpv bmVXYXlMb3NzUGVyaW9kVG90YWwgT0JKRUNULUlERU5USVRZIA0KICAgIFNUQVRVUyAgICAgY3Vy cmVudCANCiAgICBERVNDUklQVElPTiANCiAgICAgICAgIlRoZSBpZGVudGlmaWVyIGZvciB0aGUg VHlwZS1QLU9uZS1XYXktTG9zcy1QZXJpb2QtVG90YWwgDQogICAgICAgIG1ldHJpYy4iIA0KICAg IFJFRkVSRU5DRSAiIFJGQzMzNTcsIHNlY3Rpb24gNi4yLiIgDQogICAgOjo9IHsgcmZjIDI0IH0g DQoNCm9uZVdheUxvc3NQZXJpb2RMZW5ndGhzIE9CSkVDVC1JREVOVElUWSANCiAgICBTVEFUVVMg ICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRlbnRpZmllciBm b3IgdGhlIFR5cGUtUC1PbmUtV2F5LUxvc3MtUGVyaW9kLUxlbmd0aHMgDQogICAgICAgIG1ldHJp Yy4iIA0KICAgIFJFRkVSRU5DRSAiIFJGQzMzNTcsIHNlY3Rpb24gNi4zLiIgDQogICAgOjo9IHsg cmZjICAyNSB9IA0KDQpvbmVXYXlJbnRlckxvc3NQZXJpb2RMZW5ndGhzIE9CSkVDVC1JREVOVElU WSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQgDQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJU aGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1PbmUtV2F5LUludGVyLUxvc3MtUGVyaW9kLQ0K ICAgICAgICBMZW5ndGhzIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiIFJGQzMzNTcsIHNlY3Rp b24gNi40LiIgDQogICAgOjo9IHsgcmZjIDI2IH0gDQoNCg0KLS0gDQoNCg0KU3RlcGhhbiAgICAg ICAgICAgICAgICAgICAgIFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MTFdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgSVBQTSBtZXRyaWNzIHJlZ2lzdHJ5ICAg ICAgICAgICAgIE5vdmVtYmVyIDIwMDMNCg0KDQotLSBSRkMzMzkzOiAgDQotLSAiSVAgUGFja2V0 IERlbGF5IFZhcmlhdGlvbiBNZXRyaWMgZm9yIElQIFBlcmZvcm1hbmNlIE1ldHJpY3MgKElQUE0p IiANCg0Kb25lV2F5SXBkdiBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50 IA0KICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBl LVAtT25lLXdheS1pcGR2IG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiIFJGQzMzOTMsIHNlY3Rp b24gMi4iIA0KICAgIDo6PSB7IHJmYyAyNyB9IA0KDQpvbmVXYXlJcGR2UG9pc3NvblN0cmVhbSBP QkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9O IA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdheS1pcGR2LVBv aXNzb24tc3RyZWFtIA0KICAgICAgICBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIiBSRkMzMzkz LCBzZWN0aW9uIDMuIiANCiAgICA6Oj0geyByZmMgMjggfSANCg0Kb25lV2F5SXBkdlBlcmNlbnRp bGUgT0JKRUNULUlERU5USVRZIA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQ VElPTiANCiAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUtUC1PbmUtd2F5LWlwZHYt cGVyY2VudGlsZSBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIiBSRkMzMzkzLCBzZWN0aW9uIDQu My4iIA0KICAgIDo6PSB7IHJmYyAyOSB9IA0KDQpvbmVXYXlJcGR2SW52ZXJzZVBlcmNlbnRpbGUg T0JKRUNULUlERU5USVRZIA0KICAgIFNUQVRVUyAgICAgY3VycmVudCANCiAgICBERVNDUklQVElP TiANCiAgICAgICAgIlRoZSBpZGVudGlmaWVyIGZvciB0aGUgVHlwZS1QLU9uZS13YXktaXBkdi1p bnZlcnNlLXBlcmNlbnRpbGUgDQogICAgICAgIG1ldHJpYy4iIA0KICAgIFJFRkVSRU5DRSAiIFJG QzMzOTMsIHNlY3Rpb24gNC40LiIgDQogICAgOjo9IHsgcmZjIDMwIH0gDQoNCg0Kb25lV2F5SXBk dkppdHRlciBPQkpFQ1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERF U0NSSVBUSU9OIA0KICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdh eS1pcGR2LWppdHRlciBtZXRyaWMuIiANCiAgICBSRUZFUkVOQ0UgIiBSRkMzMzkzLCBzZWN0aW9u IDQuNS4iIA0KICAgIDo6PSB7IHJmYyAzMSB9IA0KDQpvbmVXYXlQZWFrVG9QZWFrSXBkdiBPQkpF Q1QtSURFTlRJVFkgDQogICAgU1RBVFVTICAgICBjdXJyZW50IA0KICAgIERFU0NSSVBUSU9OIA0K ICAgICAgICAiVGhlIGlkZW50aWZpZXIgZm9yIHRoZSBUeXBlLVAtT25lLXdheS1wZWFrLXRvLXBl YWstaXBkdiANCiAgICAgICAgbWV0cmljLiIgDQogICAgUkVGRVJFTkNFICIgUkZDMzM5Mywgc2Vj dGlvbiA0LjYuIiANCiAgICA6Oj0geyByZmMgMzIgfSANCg0KLS0gDQotLSBSRkMzNDMyOiAiTmV0 d29yayBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCB3aXRoIHBlcmlvZGljIHN0cmVhbXMiIA0KLS0g DQoNClN0ZXBoYW4gICAgICAgICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAg ICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgIElQUE0gbWV0 cmljcyByZWdpc3RyeSAgICAgICAgICAgICBOb3ZlbWJlciAyMDAzDQoNCg0KDQpvbmVXYXlEZWxh eVBlcmlvZGljU3RyZWFtIE9CSkVDVC1JREVOVElUWSANCiAgICBTVEFUVVMgICAgIGN1cnJlbnQg DQogICAgREVTQ1JJUFRJT04gDQogICAgICAgICJUaGUgaWRlbnRpZmllciBmb3IgdGhlIFR5cGUt UC1PbmUtd2F5LURlbGF5LVBlcmlvZGljLVN0cmVhbSANCiAgICAgICAgbWV0cmljLiIgDQogICAg UkVGRVJFTkNFICIgUkZDMzQzMiwgc2VjdGlvbiA0LiIgDQogICAgOjo9IHsgcmZjIDMzIH0gDQoN CkVORCANCg0KDQo4LiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgDQoNCiAgVGhlIElFVEYgdGFrZXMg bm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkgDQogIGlu dGVsbGVjdHVhbCBwcm9wZXJ0eSBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVk IHRvIA0KICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hu b2xvZ3kgZGVzY3JpYmVkIGluIA0KICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hp Y2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMgDQogIG1pZ2h0IG9yIG1pZ2h0IG5vdCBi ZSBhdmFpbGFibGU7IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCANCiAgaGFzIG1h ZGUgYW55IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuIEluZm9ybWF0aW9uIG9u IHRoZSANCiAgSUVURidzIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBzdGFu ZGFyZHMtdHJhY2sgYW5kIA0KICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBi ZSBmb3VuZCBpbiBCQ1AtMTEuIENvcGllcyBvZiANCiAgY2xhaW1zIG9mIHJpZ2h0cyBtYWRlIGF2 YWlsYWJsZSBmb3IgcHVibGljYXRpb24gYW5kIGFueSBhc3N1cmFuY2VzIG9mIA0KICBsaWNlbnNl cyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbiBhdHRlbXB0IG1hZGUg dG8gDQogIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNl IG9mIHN1Y2ggDQogIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRvcnMgb3IgdXNlcnMg b2YgdGhpcyBzcGVjaWZpY2F0aW9uIGNhbiANCiAgYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBT ZWNyZXRhcmlhdC4gDQoNCiAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0 byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueSANCiAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBw YXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeSANCiAgcmlnaHRzIHdoaWNo IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlIA0K ICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJ RVRGIEV4ZWN1dGl2ZSANCiAgRGlyZWN0b3IuIA0KDQo5LiBBY2tub3dsZWRnbWVudHMgDQoNCiAg VGhlIGF1dGhvciBncmF0ZWZ1bGx5IGFja25vd2xlZGdlcyBBbmR5IEJpZXJtYW4gYW5kIFJhbmR5 IFByZXN1aG4gZm9yIA0KICB0aGVpciBndWlkYW5jZSBhbmQgY29tbWVudHMuIA0KDQoxMC4gTm9y bWF0aXZlIFJlZmVyZW5jZXMgDQoNCiAgW1JGQzI1NzhdIE1jQ2xvZ2hyaWUsIEsuLCBQZXJraW5z LCBELiwgU2Nob2Vud2FlbGRlciwgSi4sIENhc2UsIEouLCANCiAgICAgUm9zZSwgTS4gYW5kIFMu IFdhbGRidXNzZXIsICJTdHJ1Y3R1cmUgb2YgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiANCiAgICAg VmVyc2lvbiAyIChTTUl2MikiLCBTVEQgNTgsIFJGQyAyNTc4LCBBcHJpbCAxOTk5LiANCg0KICBb UkZDMjU3OV0gTWNDbG9naHJpZSwgSy4sIFBlcmtpbnMsIEQuLCBTY2hvZW53YWVsZGVyLCBKLiwg Q2FzZSwgSi4sIA0KICAgICBSb3NlLCBNLiBhbmQgUy4gV2FsZGJ1c3NlciwgIlRleHR1YWwgQ29u dmVudGlvbnMgZm9yIFNNSXYyIiwgU1REIA0KICAgICA1OCwgUkZDIDI1NzksIEFwcmlsIDE5OTku IA0KDQoNCg0KDQpTdGVwaGFuICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAg ICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0IERyYWZ0ICAgICAgICAgICBJ UFBNIG1ldHJpY3MgcmVnaXN0cnkgICAgICAgICAgICAgTm92ZW1iZXIgMjAwMw0KDQoNCiAgW1JG QzI1ODBdIE1jQ2xvZ2hyaWUsIEsuLCBQZXJraW5zLCBELiwgU2Nob2Vud2FlbGRlciwgSi4sIENh c2UsIEouLCANCiAgICAgUm9zZSwgTS4gYW5kIFMuIFdhbGRidXNzZXIsICJDb25mb3JtYW5jZSBT dGF0ZW1lbnRzIGZvciBTTUl2MiIsIA0KICAgICBTVEQgNTgsIFJGQyAyNTgwLCBBcHJpbCAxOTk5 LiANCg0KMTEuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgDQoNCiAgW1JGQzIwMjZdIEJyYWRuZXIs IFMuLCAiVGhlIEludGVybmV0IFN0YW5kYXJkcyBQcm9jZXNzIC0tIFJldmlzaW9uIA0KICAgICAz IiwgQkNQIDksIFJGQyAyMDI2LCBPY3RvYmVyIDE5OTYuIA0KDQogIFtSRkMyMzMwXSBQYXhzb24s IFYuLCBBbG1lcywgRy4sIE1haGRhdmksIEouIGFuZCBNLiBNYXRoaXMsIA0KICAgICAiRnJhbWV3 b3JrIGZvciBJUCBQZXJmb3JtYW5jZSBNZXRyaWNzIiwgUkZDIDIzMzAsIE1heSAxOTk4LiANCg0K ICBbUkZDMjY3OF0gTWFoZGF2aSBKLiBhbmQgVi4gUGF4c29uLCAiSVBQTSBNZXRyaWNzIGZvciBN ZWFzdXJpbmcgIA0KICAgICBDb25uZWN0aXZpdHkiLCBSRkMgMjY3OCwgU2VwdGVtYmVyIDE5OTku IA0KDQogIFtSRkMyNjc5XSBBbG1lcywgRy4sICBLYWxpZGluZGksIFMuICBhbmQgTS4gWmVrYXVz a2FzLCAiQSBPbmUtd2F5IA0KICAgICBEZWxheSBNZXRyaWMgZm9yIElQUE0iLCBSRkMgMjY3OSwg U2VwdGVtYmVyIDE5OTkuIA0KDQogIFtSRkMyNjgwXSBBbG1lcywgRy4sIEthbGlkaW5kaSwgUy4g YW5kIE0uIFpla2F1c2thcywgIkEgT25lLXdheSANCiAgICAgUGFja2V0IExvc3MgTWV0cmljIGZv ciBJUFBNIiwgUkZDIDI2ODAsIFNlcHRlbWJlciAxOTk5LiANCg0KICBbUkZDMjY4MV0gQWxtZXMs IEcuLCBLYWxpZGluZGksIFMuIGFuZCBNLiBaZWthdXNrYXMsICJBIFJvdW5kLXRyaXAgDQogICAg IERlbGF5IE1ldHJpYyBmb3IgSVBQTSIsIFJGQyAyNjgxLCBTZXB0ZW1iZXIgMTk5OS4gDQoNCiAg W1JGQzMzNTddIEtvb2RsaSwgUi4gYW5kIFJhdmlrYW50aCwgUi4sICJPbmUtd2F5IExvc3MgUGF0 dGVybiBTYW1wbGUgDQogICAgIE1ldHJpY3MiLCBSRkMgMzM1NywgQXVndXN0IDIwMDIuIA0KDQog IFtSRkMzMzkzXSBEZW1pY2hlbGlzLCBDLiBhbmQgUC4gQ2hpbWVudG8sICIgSVAgUGFja2V0IERl bGF5IFZhcmlhdGlvbiANCiAgICAgTWV0cmljIGZvciBJUCBQZXJmb3JtYW5jZSBNZXRyaWNzIChJ UFBNKSIsIFJGQyAzMzkzLCBOb3ZlbWJlciANCiAgICAgMjAwMi4gDQoNCiAgW1JGQzM0MTBdIENh c2UsIEouLCBNdW5keSwgUi4sIFBhcnRhaW4sIEQuIGFuZCBCLiBTdGV3YXJ0LCANCiAgICAgIklu dHJvZHVjdGlvbiBhbmQgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIGZvciBJbnRlcm5ldCBTdGFu ZGFyZCANCiAgICAgTWFuYWdlbWVudCBGcmFtZXdvcmsiLCBSRkMgMzQxMCwgRGVjZW1iZXIgMjAw Mi4gDQoNCiAgW1JGQzM0MzJdIFJhaXNhbmVuLCBWLiwgR3JvdGVmZWxkLCBHLiBhbmQgQS4gTW9y dG9uLCAiTmV0d29yayANCiAgICAgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgd2l0aCBwZXJpb2Rp YyBzdHJlYW1zIiwgUkZDIDM0MzIsIE5vdmVtYmVyIA0KICAgICAyMDAyLiANCg0KDQoNCjEyLiBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCg0KICBBbGwgdGhlIGl0ZW1zIHNwZWNpZmllZCBpbiB0 aGlzIE1JQiBtb2R1bGUgYXJlIGRlZmluZWQgdXNpbmcgdGhlIA0KICBtYWNybyBPQkpFQ1QtSURF TlRJVFkuIFRoaXMgbWFjcm8gZG9lcyBub3QgaGF2ZSBhIE1BWC1BQ0NFU1MgY2xhdXNlLiANCg0K ICBUaGVyZSBhcmUgbm8gbWFuYWdlbWVudCBvYmplY3RzIGRlZmluZWQgaW4gdGhpcyBNSUIgbW9k dWxlIHRoYXQgaGF2ZSANCiAgYSBNQVgtQUNDRVNTIGNsYXVzZSBvZiByZWFkLXdyaXRlIGFuZC9v ciByZWFkLWNyZWF0ZS4gIFNvLCBpZiB0aGlzIA0KICBNSUIgbW9kdWxlIGlzIGltcGxlbWVudGVk IGNvcnJlY3RseSwgdGhlbiB0aGVyZSBpcyBubyByaXNrIHRoYXQgYW4gDQogIGludHJ1ZGVyIGNh biBhbHRlciBvciBjcmVhdGUgYW55IG1hbmFnZW1lbnQgb2JqZWN0cyBvZiB0aGlzIE1JQiANCiAg bW9kdWxlIHZpYSBkaXJlY3QgU05NUCBTRVQgb3BlcmF0aW9ucy4gDQoNClN0ZXBoYW4gICAgICAg ICAgICAgICAgICAgICBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0 XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgIElQUE0gbWV0cmljcyByZWdpc3RyeSAgICAg ICAgICAgICBOb3ZlbWJlciAyMDAzDQoNCg0KDQogIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgaW1w bGVtZW50ZXJzIGNvbnNpZGVyIHRoZSBzZWN1cml0eSBmZWF0dXJlcyBhcyANCiAgcHJvdmlkZWQg YnkgdGhlIFNOTVB2MyBmcmFtZXdvcmsgKHNlZSBbUkZDMzQxMF0sIHNlY3Rpb24gOCksIA0KICBp bmNsdWRpbmcgZnVsbCBzdXBwb3J0IGZvciB0aGUgU05NUHYzIGNyeXB0b2dyYXBoaWMgbWVjaGFu aXNtcyAoZm9yIA0KICBhdXRoZW50aWNhdGlvbiBhbmQgcHJpdmFjeSkuIA0KDQogIEZ1cnRoZXIs IGRlcGxveW1lbnQgb2YgU05NUCB2ZXJzaW9ucyBwcmlvciB0byBTTk1QdjMgaXMgTk9UIA0KICBS RUNPTU1FTkRFRC4gIEluc3RlYWQsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGRlcGxveSBTTk1QdjMg YW5kIHRvIA0KICBlbmFibGUgY3J5cHRvZ3JhcGhpYyBzZWN1cml0eS4gIEl0IGlzIHRoZW4gYSBj dXN0b21lci9vcGVyYXRvciANCiAgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdGhlIFNO TVAgZW50aXR5IGdpdmluZyBhY2Nlc3MgdG8gYW4gDQogIGluc3RhbmNlIG9mIHRoaXMgTUlCIG1v ZHVsZSBpcyBwcm9wZXJseSBjb25maWd1cmVkIHRvIGdpdmUgYWNjZXNzIHRvIA0KICB0aGUgb2Jq ZWN0cyBvbmx5IHRvIHRob3NlIHByaW5jaXBhbHMgKHVzZXJzKSB0aGF0IGhhdmUgbGVnaXRpbWF0 ZSANCiAgcmlnaHRzIHRvIGluZGVlZCBHRVQgb3IgU0VUIChjaGFuZ2UvY3JlYXRlL2RlbGV0ZSkg dGhlbS4gDQoNCjEzLiBBdXRob3IncyBBZGRyZXNzDQoNCiAgRW1pbGUgU1RFUEhBTiANCiAgRnJh bmNlIFRlbGVjb20gUiZEIA0KICAyLCBhdmVudWUgUGllcnJlIE1hcnppbiAgICAgICAgICAgICAg IA0KICBGLTIyMzA3IExhbm5pb24gY2VkZXggIA0KICBQaG9uZTogKyAzMyAyIDk2IDA1IDM2IDEw IA0KICBFbWFpbDogZW1pbGUuc3RlcGhhbkBmcmFuY2V0ZWxlY29tLmNvbSANCg0KDQoxNC4gRnVs bCBDb3B5cmlnaHQgU3RhdGVtZW50IA0KDQoNCiAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMjAwMykuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIA0KDQogIFRoaXMgZG9jdW1lbnQg YW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8gDQog IG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lz ZSBleHBsYWluIGl0IA0KICBvciBhc3Npc3QgaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVw YXJlZCwgY29waWVkLCBwdWJsaXNoZWQgYW5kIA0KICBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3Ig aW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkga2luZCwgDQogIHByb3ZpZGVkIHRo YXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZSANCiAg aW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVy LCB0aGlzIA0KICBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5 LCBzdWNoIGFzIGJ5IHJlbW92aW5nIA0KICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVu Y2VzIHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyIA0KICBJbnRlcm5ldCBvcmdhbml6 YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiANCiAgZGV2ZWxvcGlu ZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgDQog IGNvcHlyaWdodHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVz dCBiZSANCiAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxh bmd1YWdlcyBvdGhlciB0aGFuIA0KICBFbmdsaXNoLiANCg0KICBUaGUgbGltaXRlZCBwZXJtaXNz aW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlIA0KICByZXZv a2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMu IA0KDQogIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IGlzIHByb3ZpZGVkIG9uIGFuIA0KICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09D SUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIA0KICBUQVNLIEZPUkNFIERJU0NMQUlN UyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgDQogIEJVVCBO T1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElP TiANCg0KDQpTdGVwaGFuICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAg ICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwNCkludGVybmV0IERyYWZ0ICAgICAgICAgICBJUFBN IG1ldHJpY3MgcmVnaXN0cnkgICAgICAgICAgICAgTm92ZW1iZXIgMjAwMw0KDQoNCiAgSEVSRUlO IFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBP RiANCiAgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF LiANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpTdGVwaGFuICAg ICAgICAgICAgICAgICAgICAgU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICBbUGFn ZSAxNl0NCg0K ------_=_NextPart_001_01C3A525.664D680A-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Nov 7 15:52:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07213 for ; Fri, 7 Nov 2003 15:52:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDaK-0007cH-6g; Fri, 07 Nov 2003 15:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDZy-0007bl-Vd for ippm@optimus.ietf.org; Fri, 07 Nov 2003 15:51:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07163; Fri, 7 Nov 2003 15:51:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDZx-0002kt-00; Fri, 07 Nov 2003 15:51:37 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AIDZw-0002km-00; Fri, 07 Nov 2003 15:51:36 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 647F34E327; Fri, 7 Nov 2003 21:51:06 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 82AFE4EEEC; Fri, 7 Nov 2003 21:51:05 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hA7Kp57x031592; Fri, 7 Nov 2003 21:51:05 +0100 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id hA7Kp5hr025997; Fri, 7 Nov 2003 21:51:05 +0100 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Fri, 7 Nov 2003 21:51:05 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN Cc: ietf-web@ietf.org, matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] URGENT: IPPM WG doc In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.095504 X-RIPE-Signature: 3f99361dc8f7ca9d3a9f9d570e36645c Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , On Fri, 7 Nov 2003, STEPHAN Emile FTRD/DAC/LAN wrote: > Dear, > > In the IPPM WG I am in charge of the > draft-ietf-ippm-metrics-registry-04.txt. > The WG document draft-ietf-ippm-metrics-registry-04.txt disappeared from > the web page of the IPPM WG and from the internet draft list too. > > Is it due to some mistake ? Yes, there is at least 1 other draft that got dropped as well. We'll sort this out, not sure if we can do this before MPLS. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Nov 7 15:52:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07230 for ; Fri, 7 Nov 2003 15:52:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDab-0007eT-JY for ippm-archive@odin.ietf.org; Fri, 07 Nov 2003 15:52:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7KqH9G029407 for ippm-archive@odin.ietf.org; Fri, 7 Nov 2003 15:52:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDab-0007eE-F0 for ippm-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:52:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07169 for ; Fri, 7 Nov 2003 15:52:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDaZ-0002lL-00 for ippm-web-archive@ietf.org; Fri, 07 Nov 2003 15:52:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDaZ-0002lI-00 for ippm-web-archive@ietf.org; Fri, 07 Nov 2003 15:52:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDaK-0007cH-6g; Fri, 07 Nov 2003 15:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDZy-0007bl-Vd for ippm@optimus.ietf.org; Fri, 07 Nov 2003 15:51:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07163; Fri, 7 Nov 2003 15:51:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDZx-0002kt-00; Fri, 07 Nov 2003 15:51:37 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AIDZw-0002km-00; Fri, 07 Nov 2003 15:51:36 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 647F34E327; Fri, 7 Nov 2003 21:51:06 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 82AFE4EEEC; Fri, 7 Nov 2003 21:51:05 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hA7Kp57x031592; Fri, 7 Nov 2003 21:51:05 +0100 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id hA7Kp5hr025997; Fri, 7 Nov 2003 21:51:05 +0100 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Fri, 7 Nov 2003 21:51:05 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: STEPHAN Emile FTRD/DAC/LAN Cc: ietf-web@ietf.org, matt@internet2.edu, ippm@ietf.org Subject: Re: [ippm] URGENT: IPPM WG doc In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.095504 X-RIPE-Signature: 3f99361dc8f7ca9d3a9f9d570e36645c Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , On Fri, 7 Nov 2003, STEPHAN Emile FTRD/DAC/LAN wrote: > Dear, > > In the IPPM WG I am in charge of the > draft-ietf-ippm-metrics-registry-04.txt. > The WG document draft-ietf-ippm-metrics-registry-04.txt disappeared from > the web page of the IPPM WG and from the internet draft list too. > > Is it due to some mistake ? Yes, there is at least 1 other draft that got dropped as well. We'll sort this out, not sure if we can do this before MPLS. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Nov 10 13:47:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05071 for ; Mon, 10 Nov 2003 13:47:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH42-00009U-1W; Mon, 10 Nov 2003 13:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH3w-00009F-BD for ippm@optimus.ietf.org; Mon, 10 Nov 2003 13:46:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05034; Mon, 10 Nov 2003 13:46:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJH3t-00025t-00; Mon, 10 Nov 2003 13:46:53 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AJH3s-00025o-00; Mon, 10 Nov 2003 13:46:53 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 19:46:42 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: [ippm] draft-ietf-ippm-metrics-registry-04.txt back on the IPPM WEB page. Date: Mon, 10 Nov 2003 19:46:41 +0100 Message-ID: Thread-Topic: [ippm] draft-ietf-ippm-metrics-registry-04.txt back on the IPPM WEB page. Thread-Index: AcOntAZvHpC83B4mSKKW7SoPhKlpIgAA6i8g From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE-NCC)" Cc: , , "Al Morton" , X-OriginalArrivalTime: 10 Nov 2003 18:46:42.0475 (UTC) FILETIME=[FBAE0FB0:01C3A7BA] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Henk, As the document draft-ietf-ippm-metrics-registry-04.txt is not obsolete = the secretary should make the correction by itself before the RMON WG = session of this evening. Regards Emile -----Message d'origine----- De : STEPHAN Emile FTRD/DAC/LAN=20 Envoy=E9 : lundi 10 novembre 2003 03:27 =C0 : '=3DSMTP:dinaras@ietf.org'; '=3DSMTP:henk@ripe.net'; 'Matt = Zekauskas' Cc : '=3DSMTP:ippm@ietf.org'; BARNOLE Valerie FTRD/DSRD/ISS; JACQUENET = Christian DRLD-ITP Objet : RE : URGENT: IPPM WG doc & TR : IPPM: = draft-ietf-ippm-metrics-registry-04.txt=20 Dear Dinara, Actually the version 04 was updated by Matt in June (see below). It = looks like that the expiration process has not checked the date of the = file itself. This document is less than 6 months old. This document creation was initially requested by the RMON WG. So I = would be glad if you may put back the document in the internet draft = list and on the WEB page of the IPPM WG before Monday noon (day of the = RMON session). There is still something I am missing. Why the version 4 draft was not = replaced with the same kind of file (see = draft-ietf-ippm-metrics-registry-05.txt attached) telling that it = expired ? Regards Emile=20 -----Message d'origine----- De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net]=20 Envoy=E9 : lundi 10 novembre 2003 18:57 =C0 : Al Morton Cc : STEPHAN Emile FTRD/DAC/LAN; matt@internet2.edu Objet : Re: [ippm] URGENT: IPPM WG doc All, > The registry draft may have been dropped when the reordering draft was = > posted, i seem to remember four drafts before, four after. i take it=20 > that the registry draft did not expire, either... Right now, I see 5 drafts: 1. A One-way Active Measurement Protocol (OWAMP) (86233 bytes) 2. A One-way Active Measurement Protocol Requirements (21551 bytes) 3. IPPM metrics registry (675 bytes) 4. IPPM reporting MIB (158332 bytes) 5. Packet Reordering Metric for IPPM (56012 bytes) 3 looked a bit short and is indeed only a note that it expired. Emile, = please resubmit after MPLS. Missing is the Colorado draft on reordering = (or is that still an individual submission?). In the latter case, we should discuss if/how this should become a WG = item on Thu. Any other ID's that I missed? Henk -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: = http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- That problem that we weren't having yesterday, is it better? (Big ISP = NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Nov 10 13:47:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05089 for ; Mon, 10 Nov 2003 13:47:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH4J-0000Bi-8I for ippm-archive@odin.ietf.org; Mon, 10 Nov 2003 13:47:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAIlJSX000713 for ippm-archive@odin.ietf.org; Mon, 10 Nov 2003 13:47:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH4H-0000BP-2E for ippm-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 13:47:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05052 for ; Mon, 10 Nov 2003 13:47:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJH4E-000264-00 for ippm-web-archive@ietf.org; Mon, 10 Nov 2003 13:47:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJH4E-00025y-00 for ippm-web-archive@ietf.org; Mon, 10 Nov 2003 13:47:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH42-00009U-1W; Mon, 10 Nov 2003 13:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJH3w-00009F-BD for ippm@optimus.ietf.org; Mon, 10 Nov 2003 13:46:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05034; Mon, 10 Nov 2003 13:46:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJH3t-00025t-00; Mon, 10 Nov 2003 13:46:53 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1AJH3s-00025o-00; Mon, 10 Nov 2003 13:46:53 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 19:46:42 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: [ippm] draft-ietf-ippm-metrics-registry-04.txt back on the IPPM WEB page. Date: Mon, 10 Nov 2003 19:46:41 +0100 Message-ID: Thread-Topic: [ippm] draft-ietf-ippm-metrics-registry-04.txt back on the IPPM WEB page. Thread-Index: AcOntAZvHpC83B4mSKKW7SoPhKlpIgAA6i8g From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE-NCC)" Cc: , , "Al Morton" , X-OriginalArrivalTime: 10 Nov 2003 18:46:42.0475 (UTC) FILETIME=[FBAE0FB0:01C3A7BA] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Henk, As the document draft-ietf-ippm-metrics-registry-04.txt is not obsolete = the secretary should make the correction by itself before the RMON WG = session of this evening. Regards Emile -----Message d'origine----- De : STEPHAN Emile FTRD/DAC/LAN=20 Envoy=E9 : lundi 10 novembre 2003 03:27 =C0 : '=3DSMTP:dinaras@ietf.org'; '=3DSMTP:henk@ripe.net'; 'Matt = Zekauskas' Cc : '=3DSMTP:ippm@ietf.org'; BARNOLE Valerie FTRD/DSRD/ISS; JACQUENET = Christian DRLD-ITP Objet : RE : URGENT: IPPM WG doc & TR : IPPM: = draft-ietf-ippm-metrics-registry-04.txt=20 Dear Dinara, Actually the version 04 was updated by Matt in June (see below). It = looks like that the expiration process has not checked the date of the = file itself. This document is less than 6 months old. This document creation was initially requested by the RMON WG. So I = would be glad if you may put back the document in the internet draft = list and on the WEB page of the IPPM WG before Monday noon (day of the = RMON session). There is still something I am missing. Why the version 4 draft was not = replaced with the same kind of file (see = draft-ietf-ippm-metrics-registry-05.txt attached) telling that it = expired ? Regards Emile=20 -----Message d'origine----- De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net]=20 Envoy=E9 : lundi 10 novembre 2003 18:57 =C0 : Al Morton Cc : STEPHAN Emile FTRD/DAC/LAN; matt@internet2.edu Objet : Re: [ippm] URGENT: IPPM WG doc All, > The registry draft may have been dropped when the reordering draft was = > posted, i seem to remember four drafts before, four after. i take it=20 > that the registry draft did not expire, either... Right now, I see 5 drafts: 1. A One-way Active Measurement Protocol (OWAMP) (86233 bytes) 2. A One-way Active Measurement Protocol Requirements (21551 bytes) 3. IPPM metrics registry (675 bytes) 4. IPPM reporting MIB (158332 bytes) 5. Packet Reordering Metric for IPPM (56012 bytes) 3 looked a bit short and is indeed only a note that it expired. Emile, = please resubmit after MPLS. Missing is the Colorado draft on reordering = (or is that still an individual submission?). In the latter case, we should discuss if/how this should become a WG = item on Thu. Any other ID's that I missed? Henk -------------------------------------------------------------------------= ----- Henk Uijterwaal Email: = henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: = http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 -------------------------------------------------------------------------= ----- That problem that we weren't having yesterday, is it better? (Big ISP = NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Nov 10 14:15:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06640 for ; Mon, 10 Nov 2003 14:15:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHV8-0002CK-Ky; Mon, 10 Nov 2003 14:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHIU-0001Vt-2m for ippm@optimus.ietf.org; Mon, 10 Nov 2003 14:01:58 -0500 Received: from dinaras.cnri.reston.va.us (dinaras-desktop.cnri.reston.va.us [10.27.16.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05836; Mon, 10 Nov 2003 14:01:38 -0500 (EST) Message-Id: <5.1.0.14.2.20031110140013.0220b6a0@odin> X-Sender: dinaras@odin X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Nov 2003 14:02:40 -0500 To: "STEPHAN Emile FTRD/DAC/LAN" , "Henk Uijterwaal (RIPE-NCC)" From: Dinara Suleymanova Subject: Re: [ippm] draft-ietf-ippm-metrics-registry-04.txt back on the IPPM WEB page. Cc: , "Al Morton" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear All, The -04 version was expired and that is why automatically dropped from the= =20 registry. (the submission was in April, 6 months ago). But upon your request we have= =20 restored it and it should be available after 300 PM EST. Dinara Suleymanova At 07:46 PM 11/10/03 +0100, STEPHAN Emile FTRD/DAC/LAN wrote: >Dear Henk, > >As the document draft-ietf-ippm-metrics-registry-04.txt is not obsolete=20 >the secretary should make the correction by itself before the RMON WG=20 >session of this evening. > >Regards >Emile > >-----Message d'origine----- >De : STEPHAN Emile FTRD/DAC/LAN >Envoy=E9 : lundi 10 novembre 2003 03:27 >=C0 : '=3DSMTP:dinaras@ietf.org'; '=3DSMTP:henk@ripe.net'; 'Matt Zekauskas' >Cc : '=3DSMTP:ippm@ietf.org'; BARNOLE Valerie FTRD/DSRD/ISS; JACQUENET=20 >Christian DRLD-ITP >Objet : RE : URGENT: IPPM WG doc & TR : IPPM:=20 >draft-ietf-ippm-metrics-registry-04.txt > > >Dear Dinara, > >Actually the version 04 was updated by Matt in June (see below). It looks= =20 >like that the expiration process has not checked the date of the file=20 >itself. This document is less than 6 months old. > >This document creation was initially requested by the RMON WG. So I would= =20 >be glad if you may put back the document in the internet draft list and on= =20 >the WEB page of the IPPM WG before Monday noon (day of the RMON session). > >There is still something I am missing. Why the version 4 draft was not=20 >replaced with the same kind of file (see=20 >draft-ietf-ippm-metrics-registry-05.txt attached) telling that it expired ? > >Regards >Emile > >-----Message d'origine----- >De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] >Envoy=E9 : lundi 10 novembre 2003 18:57 >=C0 : Al Morton >Cc : STEPHAN Emile FTRD/DAC/LAN; matt@internet2.edu >Objet : Re: [ippm] URGENT: IPPM WG doc > > > >All, > > > The registry draft may have been dropped when the reordering draft was > > posted, i seem to remember four drafts before, four after. i take it > > that the registry draft did not expire, either... > >Right now, I see 5 drafts: > > 1. A One-way Active Measurement Protocol (OWAMP) (86233 bytes) > 2. A One-way Active Measurement Protocol Requirements (21551 bytes) > 3. IPPM metrics registry (675 bytes) > 4. IPPM reporting MIB (158332 bytes) > 5. Packet Reordering Metric for IPPM (56012 bytes) > >3 looked a bit short and is indeed only a note that it expired. Emile,=20 >please resubmit after MPLS. Missing is the Colorado draft on reordering=20 >(or is that still an individual submission?). > >In the latter case, we should discuss if/how this should become a WG item= =20 >on Thu. > >Any other ID's that I missed? > >Henk > >---------------------------------------------------------------------------= --- >Henk Uijterwaal Email: henk.uijterwaal@ripe.net >RIPE Network Coordination Centre WWW:= http://www.ripe.net/home/henk >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 >The Netherlands The Netherlands Mobile: +31.6.55861746 >---------------------------------------------------------------------------= --- > >That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Nov 10 14:15:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06655 for ; Mon, 10 Nov 2003 14:15:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHVN-0002Ge-7j for ippm-archive@odin.ietf.org; Mon, 10 Nov 2003 14:15:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJFHaG008717 for ippm-archive@odin.ietf.org; Mon, 10 Nov 2003 14:15:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHVM-0002Fl-H1 for ippm-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 14:15:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06624 for ; Mon, 10 Nov 2003 14:15:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHVJ-0002ZG-00 for ippm-web-archive@ietf.org; Mon, 10 Nov 2003 14:15:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJHVJ-0002ZD-00 for ippm-web-archive@ietf.org; Mon, 10 Nov 2003 14:15:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHV8-0002CK-Ky; Mon, 10 Nov 2003 14:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHIU-0001Vt-2m for ippm@optimus.ietf.org; Mon, 10 Nov 2003 14:01:58 -0500 Received: from dinaras.cnri.reston.va.us (dinaras-desktop.cnri.reston.va.us [10.27.16.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05836; Mon, 10 Nov 2003 14:01:38 -0500 (EST) Message-Id: <5.1.0.14.2.20031110140013.0220b6a0@odin> X-Sender: dinaras@odin X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Nov 2003 14:02:40 -0500 To: "STEPHAN Emile FTRD/DAC/LAN" , "Henk Uijterwaal (RIPE-NCC)" From: Dinara Suleymanova Subject: Re: [ippm] draft-ietf-ippm-metrics-registry-04.txt back on the IPPM WEB page. Cc: , "Al Morton" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear All, The -04 version was expired and that is why automatically dropped from the= =20 registry. (the submission was in April, 6 months ago). But upon your request we have= =20 restored it and it should be available after 300 PM EST. Dinara Suleymanova At 07:46 PM 11/10/03 +0100, STEPHAN Emile FTRD/DAC/LAN wrote: >Dear Henk, > >As the document draft-ietf-ippm-metrics-registry-04.txt is not obsolete=20 >the secretary should make the correction by itself before the RMON WG=20 >session of this evening. > >Regards >Emile > >-----Message d'origine----- >De : STEPHAN Emile FTRD/DAC/LAN >Envoy=E9 : lundi 10 novembre 2003 03:27 >=C0 : '=3DSMTP:dinaras@ietf.org'; '=3DSMTP:henk@ripe.net'; 'Matt Zekauskas' >Cc : '=3DSMTP:ippm@ietf.org'; BARNOLE Valerie FTRD/DSRD/ISS; JACQUENET=20 >Christian DRLD-ITP >Objet : RE : URGENT: IPPM WG doc & TR : IPPM:=20 >draft-ietf-ippm-metrics-registry-04.txt > > >Dear Dinara, > >Actually the version 04 was updated by Matt in June (see below). It looks= =20 >like that the expiration process has not checked the date of the file=20 >itself. This document is less than 6 months old. > >This document creation was initially requested by the RMON WG. So I would= =20 >be glad if you may put back the document in the internet draft list and on= =20 >the WEB page of the IPPM WG before Monday noon (day of the RMON session). > >There is still something I am missing. Why the version 4 draft was not=20 >replaced with the same kind of file (see=20 >draft-ietf-ippm-metrics-registry-05.txt attached) telling that it expired ? > >Regards >Emile > >-----Message d'origine----- >De : Henk Uijterwaal (RIPE-NCC) [mailto:henk@ripe.net] >Envoy=E9 : lundi 10 novembre 2003 18:57 >=C0 : Al Morton >Cc : STEPHAN Emile FTRD/DAC/LAN; matt@internet2.edu >Objet : Re: [ippm] URGENT: IPPM WG doc > > > >All, > > > The registry draft may have been dropped when the reordering draft was > > posted, i seem to remember four drafts before, four after. i take it > > that the registry draft did not expire, either... > >Right now, I see 5 drafts: > > 1. A One-way Active Measurement Protocol (OWAMP) (86233 bytes) > 2. A One-way Active Measurement Protocol Requirements (21551 bytes) > 3. IPPM metrics registry (675 bytes) > 4. IPPM reporting MIB (158332 bytes) > 5. Packet Reordering Metric for IPPM (56012 bytes) > >3 looked a bit short and is indeed only a note that it expired. Emile,=20 >please resubmit after MPLS. Missing is the Colorado draft on reordering=20 >(or is that still an individual submission?). > >In the latter case, we should discuss if/how this should become a WG item= =20 >on Thu. > >Any other ID's that I missed? > >Henk > >---------------------------------------------------------------------------= --- >Henk Uijterwaal Email: henk.uijterwaal@ripe.net >RIPE Network Coordination Centre WWW:= http://www.ripe.net/home/henk >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 >The Netherlands The Netherlands Mobile: +31.6.55861746 >---------------------------------------------------------------------------= --- > >That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Nov 10 17:01:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16162 for ; Mon, 10 Nov 2003 17:01:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK5n-0007i6-5s; Mon, 10 Nov 2003 17:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK52-0007aD-6y for ippm@optimus.ietf.org; Mon, 10 Nov 2003 17:00:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15899; Mon, 10 Nov 2003 17:00:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK4y-0005YY-00; Mon, 10 Nov 2003 17:00:12 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AJK4y-0005Wc-00; Mon, 10 Nov 2003 17:00:12 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 7E2134FFF6; Mon, 10 Nov 2003 22:59:41 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 0B9FA4FFF4; Mon, 10 Nov 2003 22:59:41 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hAALxf7x019019; Mon, 10 Nov 2003 22:59:41 +0100 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id hAALxeMD000881; Mon, 10 Nov 2003 22:59:40 +0100 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Mon, 10 Nov 2003 22:59:40 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@ietf.org, agenda@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.283001 X-RIPE-Signature: 4f2740b5ee16ab0858a21a928f4e902a Subject: [ippm] Agenda for the IPPM WG (Thu 13/11, 13:00) Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Folks, Sorry for the late announcement, but here's the agenda for Thursday's meeting. Henk 1. Agenda Bashing 5' 2. Packet Reordering 2.1. Al Morton/draft-ietf-ippm-reordering 20' 2.2. Nischal Piratla/draft-jayasumana-reorder-density 20' 2.3. Discussion on how to proceed with these efforts 10' 3. MIB 3.1 Emile Stephan/draft-ietf-ippm-reporting-mib 10' 3.2. ES/draft-ietf-ippm-metrics-registry 10' 3.3 Discussion 10' 4. OWAMP 4.1 Status and discussion 5' draft-ietf-ippm-owdp-reqs draft-ietf-ippm-owdp 5. Future work: 20' 5.1 Implementation reports 5.2 Bandwidth 5.3 Milestones 6. AOB 5' (I'll post this unless you object in the next 12 hours) Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Nov 10 17:01:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16177 for ; Mon, 10 Nov 2003 17:01:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK64-0007o1-02 for ippm-archive@odin.ietf.org; Mon, 10 Nov 2003 17:01:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAM1JA9030005 for ippm-archive@odin.ietf.org; Mon, 10 Nov 2003 17:01:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK63-0007ns-S5 for ippm-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 17:01:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16122 for ; Mon, 10 Nov 2003 17:01:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK61-0005fv-00 for ippm-web-archive@ietf.org; Mon, 10 Nov 2003 17:01:17 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AJK61-0005fs-00 for ippm-web-archive@ietf.org; Mon, 10 Nov 2003 17:01:17 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AJK61-0005gg-0I for ippm-web-archive@ietf.org; Mon, 10 Nov 2003 17:01:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK5n-0007i6-5s; Mon, 10 Nov 2003 17:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK52-0007aD-6y for ippm@optimus.ietf.org; Mon, 10 Nov 2003 17:00:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15899; Mon, 10 Nov 2003 17:00:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK4y-0005YY-00; Mon, 10 Nov 2003 17:00:12 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AJK4y-0005Wc-00; Mon, 10 Nov 2003 17:00:12 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 7E2134FFF6; Mon, 10 Nov 2003 22:59:41 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 0B9FA4FFF4; Mon, 10 Nov 2003 22:59:41 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hAALxf7x019019; Mon, 10 Nov 2003 22:59:41 +0100 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id hAALxeMD000881; Mon, 10 Nov 2003 22:59:40 +0100 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Mon, 10 Nov 2003 22:59:40 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@ietf.org, agenda@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.283001 X-RIPE-Signature: 4f2740b5ee16ab0858a21a928f4e902a Subject: [ippm] Agenda for the IPPM WG (Thu 13/11, 13:00) Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Folks, Sorry for the late announcement, but here's the agenda for Thursday's meeting. Henk 1. Agenda Bashing 5' 2. Packet Reordering 2.1. Al Morton/draft-ietf-ippm-reordering 20' 2.2. Nischal Piratla/draft-jayasumana-reorder-density 20' 2.3. Discussion on how to proceed with these efforts 10' 3. MIB 3.1 Emile Stephan/draft-ietf-ippm-reporting-mib 10' 3.2. ES/draft-ietf-ippm-metrics-registry 10' 3.3 Discussion 10' 4. OWAMP 4.1 Status and discussion 5' draft-ietf-ippm-owdp-reqs draft-ietf-ippm-owdp 5. Future work: 20' 5.1 Implementation reports 5.2 Bandwidth 5.3 Milestones 6. AOB 5' (I'll post this unless you object in the next 12 hours) Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Tue Nov 11 00:40:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06751 for ; Tue, 11 Nov 2003 00:40:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRFy-0002jh-24; Tue, 11 Nov 2003 00:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRF6-0002XF-RB for ippm@optimus.ietf.org; Tue, 11 Nov 2003 00:39:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06663; Tue, 11 Nov 2003 00:38:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJRF3-0005FP-00; Tue, 11 Nov 2003 00:39:05 -0500 Received: from goku.engr.colostate.edu ([129.82.224.16]) by ietf-mx with esmtp (Exim 4.12) id 1AJRF2-0005FM-00; Tue, 11 Nov 2003 00:39:04 -0500 Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by goku.engr.colostate.edu (8.12.8/8.12.0.Beta7) with ESMTP id hAB5cr5J018487; Mon, 10 Nov 2003 22:38:53 -0700 (MST) X-WebMail-UserID: nischal@mail.engr.colostate.edu Date: Mon, 10 Nov 2003 22:38:53 -0700 From: Nischal M Piratla To: "Henk Uijterwaal (RIPE-NCC)" , agenda , ippm X-EXP32-SerialNo: 00002247, 00002264 Subject: RE: [ippm] Agenda for the IPPM WG (Thu 13/11, 13:00) Message-ID: <3FB4B5C1@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01 X-ECS-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henk, Prof.Anura Jayasumana will be presenting the new concepts in draft-jayasumana-reorder-density. I apologize for any confusion. - Nischal Piratla >===== Original Message From "Henk Uijterwaal (RIPE-NCC)" ===== >Folks, > >Sorry for the late announcement, but here's the agenda for Thursday's >meeting. > >Henk > > > >1. Agenda Bashing 5' > >2. Packet Reordering > 2.1. Al Morton/draft-ietf-ippm-reordering 20' > 2.2. Nischal Piratla/draft-jayasumana-reorder-density 20' > 2.3. Discussion on how to proceed with these efforts 10' > >3. MIB > 3.1 Emile Stephan/draft-ietf-ippm-reporting-mib 10' > 3.2. ES/draft-ietf-ippm-metrics-registry 10' > 3.3 Discussion 10' > >4. OWAMP > 4.1 Status and discussion 5' > draft-ietf-ippm-owdp-reqs > draft-ietf-ippm-owdp > >5. Future work: 20' > 5.1 Implementation reports > 5.2 Bandwidth > 5.3 Milestones > >6. AOB 5' > >(I'll post this unless you object in the next 12 hours) > >Henk > >----------------------------------------------------------------------------- - >Henk Uijterwaal Email: henk.uijterwaal@ripe.net >RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 >The Netherlands The Netherlands Mobile: +31.6.55861746 >----------------------------------------------------------------------------- - > >That problem that we weren't having yesterday, is it better? (Big ISP NOC) > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Tue Nov 11 00:40:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06768 for ; Tue, 11 Nov 2003 00:40:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRG9-0002md-Ah for ippm-archive@odin.ietf.org; Tue, 11 Nov 2003 00:40:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB5eDgP010693 for ippm-archive@odin.ietf.org; Tue, 11 Nov 2003 00:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRG9-0002mO-1C for ippm-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 00:40:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06730 for ; Tue, 11 Nov 2003 00:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJRG6-0005GS-00 for ippm-web-archive@ietf.org; Tue, 11 Nov 2003 00:40:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJRG6-0005GP-00 for ippm-web-archive@ietf.org; Tue, 11 Nov 2003 00:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRFy-0002jh-24; Tue, 11 Nov 2003 00:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJRF6-0002XF-RB for ippm@optimus.ietf.org; Tue, 11 Nov 2003 00:39:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06663; Tue, 11 Nov 2003 00:38:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJRF3-0005FP-00; Tue, 11 Nov 2003 00:39:05 -0500 Received: from goku.engr.colostate.edu ([129.82.224.16]) by ietf-mx with esmtp (Exim 4.12) id 1AJRF2-0005FM-00; Tue, 11 Nov 2003 00:39:04 -0500 Received: from webmail.colostate.edu (csunts4.acns.colostate.edu [129.82.100.135]) by goku.engr.colostate.edu (8.12.8/8.12.0.Beta7) with ESMTP id hAB5cr5J018487; Mon, 10 Nov 2003 22:38:53 -0700 (MST) X-WebMail-UserID: nischal@mail.engr.colostate.edu Date: Mon, 10 Nov 2003 22:38:53 -0700 From: Nischal M Piratla To: "Henk Uijterwaal (RIPE-NCC)" , agenda , ippm X-EXP32-SerialNo: 00002247, 00002264 Subject: RE: [ippm] Agenda for the IPPM WG (Thu 13/11, 13:00) Message-ID: <3FB4B5C1@webmail.colostate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Infinite Mobile Delivery (Hydra) SMTP v3.62.01 X-ECS-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henk, Prof.Anura Jayasumana will be presenting the new concepts in draft-jayasumana-reorder-density. I apologize for any confusion. - Nischal Piratla >===== Original Message From "Henk Uijterwaal (RIPE-NCC)" ===== >Folks, > >Sorry for the late announcement, but here's the agenda for Thursday's >meeting. > >Henk > > > >1. Agenda Bashing 5' > >2. Packet Reordering > 2.1. Al Morton/draft-ietf-ippm-reordering 20' > 2.2. Nischal Piratla/draft-jayasumana-reorder-density 20' > 2.3. Discussion on how to proceed with these efforts 10' > >3. MIB > 3.1 Emile Stephan/draft-ietf-ippm-reporting-mib 10' > 3.2. ES/draft-ietf-ippm-metrics-registry 10' > 3.3 Discussion 10' > >4. OWAMP > 4.1 Status and discussion 5' > draft-ietf-ippm-owdp-reqs > draft-ietf-ippm-owdp > >5. Future work: 20' > 5.1 Implementation reports > 5.2 Bandwidth > 5.3 Milestones > >6. AOB 5' > >(I'll post this unless you object in the next 12 hours) > >Henk > >----------------------------------------------------------------------------- - >Henk Uijterwaal Email: henk.uijterwaal@ripe.net >RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk >P.O.Box 10096 Singel 258 Phone: +31.20.5354414 >1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 >The Netherlands The Netherlands Mobile: +31.6.55861746 >----------------------------------------------------------------------------- - > >That problem that we weren't having yesterday, is it better? (Big ISP NOC) > >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Nov 13 03:56:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17150 for ; Thu, 13 Nov 2003 03:56:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDGn-0002sY-0m; Thu, 13 Nov 2003 03:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDGh-0002rg-Df for ippm@optimus.ietf.org; Thu, 13 Nov 2003 03:55:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17102 for ; Thu, 13 Nov 2003 03:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDGe-00016f-00 for ippm@ietf.org; Thu, 13 Nov 2003 03:55:56 -0500 Received: from web15210.mail.cnb.yahoo.com ([202.3.77.140] helo=web15210.mail.bjs.yahoo.com) by ietf-mx with smtp (Exim 4.12) id 1AKDGd-00015U-00 for ippm@ietf.org; Thu, 13 Nov 2003 03:55:55 -0500 Message-ID: <20031113085522.33601.qmail@web15210.mail.bjs.yahoo.com> Received: from [202.96.96.35] by web15210.mail.bjs.yahoo.com via HTTP; Thu, 13 Nov 2003 16:55:22 CST Date: Thu, 13 Nov 2003 16:55:22 +0800 (CST) From: =?gb2312?q?Jing=20Shen?= To: ippm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [ippm] question with e2e ethernet measurement parameters Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, I know the question is out of scope of this list. But I do not know where to ask for help, avoid the question if this make you inconvinence. Where could I find measurement data set and threshhold data between two ethernet ports connected by optic fiber? thanks in advance. regards ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Nov 13 03:56:54 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17165 for ; Thu, 13 Nov 2003 03:56:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDHG-0002z6-8h for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 03:56:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD8uYqH011466 for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 03:56:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDHF-0002yr-R7 for ippm-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 03:56:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17131 for ; Thu, 13 Nov 2003 03:56:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDHD-00017d-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 03:56:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKDHC-00017X-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 03:56:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDGn-0002sY-0m; Thu, 13 Nov 2003 03:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDGh-0002rg-Df for ippm@optimus.ietf.org; Thu, 13 Nov 2003 03:55:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17102 for ; Thu, 13 Nov 2003 03:55:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDGe-00016f-00 for ippm@ietf.org; Thu, 13 Nov 2003 03:55:56 -0500 Received: from web15210.mail.cnb.yahoo.com ([202.3.77.140] helo=web15210.mail.bjs.yahoo.com) by ietf-mx with smtp (Exim 4.12) id 1AKDGd-00015U-00 for ippm@ietf.org; Thu, 13 Nov 2003 03:55:55 -0500 Message-ID: <20031113085522.33601.qmail@web15210.mail.bjs.yahoo.com> Received: from [202.96.96.35] by web15210.mail.bjs.yahoo.com via HTTP; Thu, 13 Nov 2003 16:55:22 CST Date: Thu, 13 Nov 2003 16:55:22 +0800 (CST) From: =?gb2312?q?Jing=20Shen?= To: ippm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [ippm] question with e2e ethernet measurement parameters Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I know the question is out of scope of this list. But I do not know where to ask for help, avoid the question if this make you inconvinence. Where could I find measurement data set and threshhold data between two ethernet ports connected by optic fiber? thanks in advance. regards ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Nov 13 11:05:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05009 for ; Thu, 13 Nov 2003 11:05:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJxw-00075h-5C; Thu, 13 Nov 2003 11:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJxQ-000749-VG for ippm@optimus.ietf.org; Thu, 13 Nov 2003 11:04:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04942 for ; Thu, 13 Nov 2003 11:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJxN-0007dH-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:04:29 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKJxM-0007cK-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:04:28 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Nov 2003 08:06:23 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hADG3tmU025624 for ; Thu, 13 Nov 2003 08:03:56 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-323.cisco.com [10.21.65.67]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOE70408; Thu, 13 Nov 2003 08:03:54 -0800 (PST) Message-Id: <4.3.2.7.2.20031113075842.02615600@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Nov 2003 08:02:36 -0800 To: ippm@ietf.org From: Andy Bierman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , 1. General comments Although a good job has been done documenting this MIB, IMO it is too complex to be deployable. The resource requirements in the agent are very large. Some of the tables can get extremely large, which would lead to poor SNMP performance. The resource limitation mechanisms do not align well with actual SNMP agent implementation constraints. This MIB is way too complicated and contains too many features that should be provided by an EMS or NMS. There are likely to be many implementation difficulties due to undocumented (and unforeseen) interactions between features. The MIB should be simplified to collect metric values and provide aggregation reports which can be retrieved via SNMP. Analysis of the reports, threshold based exception handling, sending email and pages to administrators, etc. should be left to the application. 2. sec. 3) SNMP Framework This boilerplate is out of date. Use the new template at: http://www.ops.ietf.org/mib-boilerplate.html 3. sec 4, para 4) RMON model This paragraph is incorrect. RMON can collect data from several interfaces which are not required to be in the same chassis. 4. sec. 4.1.3.1) Internet addresses Why are special address types needed for Src and Dest? 5. sec. 4.1.4) GMTTimeStamp Why is it important to start the timestamp from 2000 instead of 1900? This is extra work since implementations are likely to support the standard "seconds since 1900" format, not this new format. 6. sec. 4.1.6) Report definition This TC is very complex and overloads many functions into a single bit string. It should be broken out into several MIB objects for simplicity and clarity. 7. MIB, TypeP TC) This design is flawed because the authoritative name of the protocol is based on the descriptive string found in an RMON protocol identifier. However this text string is not normative and not required to be globally unique or even consistent across implementations. 8. MIB, IppmReportDefinition TC This TC overloads event management, report filtering, delivery options, and report cleanup options in a long bit string. This should be split into at least 4 TCs (or MIB objects). 9. MIB, ippmSystemTime object There should not need to be a special object for the system time. Also, how does the NMS know if the probe is in proxy mode? 10. MIB, Clock sync objects ippmSystemSynchronizationType ippmSystemSynchronizationDesc ippmSystemClockResolution These objects should be in a separate MIB module since this is a generic problem not specific to IPPM reporting. 11. MIB, ippmSynchronizationTable Why is a history table of up to 64K clock sync events needed? This will take up a lot of memory for very questionable value. 12. MIB, point of measure table IppmPointOfMeasureEntry ::= SEQUENCE { ippmPointOfMeasureIndex Unsigned32, ippmPointOfMeasureMgmtAddrType InetAddressType, ippmPointOfMeasureMgmtAddress InetAddress, ippmPointOfMeasureTestAddrTypeP TypeP, ippmPointOfMeasureTestAddr TypePaddress, ippmPointOfMeasureMetrics IppmStandardMetrics } Why is there a management address for each test point? How is this used? Why does the NMS need to know this? Doesn't the NMS just contact the IPPM SNMP agent to retrieve data? Why is the test address of the measurement point needed? Why isn't it an InetAddress? How is this used? 13. MIB, ippmMetricEntry This table is broken because there is only one entry per metric. This assumes that the collection capabilities are the same for every point of measure, which is not very likely. The ippmPointOfMeasureIndex should be added (first) to the INDEX clause in this table. 14. MIB, ippmMetricCapabilities ippmMetricCapabilities OBJECT-TYPE SYNTAX INTEGER { notImplemented(0), implemented(1) Why is this object needed? Why not just populate the table for metrics that are implemented. The other objects in this table are irrelevant or unknown if the metric is not implemented by the agent. 15. MIB, ippmOwnersTable IppmOwnersEntry ::= SEQUENCE { ippmOwnersIndex Unsigned32, ippmOwnersOwner IppmOwnerString, The ippmOwnerOwner object is the object that is used to create unique index values in other tables (e.g., that represent history entries), yet this object is required to be unique in this table. The ippmOwnersIndex object has no value at all and should be removed. This table should be indexed by the ippmOwnersOwner object. 16. MIB, owner address ippmOwnersIpAddressType InetAddressType, ippmOwnersIpAddress InetAddress, Why are these objects in the MIB? Why does it matter what the owner's address is in this MIB module? If this is for sending notifications, then use the MIBs in the SNMP Applications document, not this table. ippmOwnersEmail SnmpAdminString, ippmOwnersSMS SnmpAdminString, These objects should be removed and the functions of sending IPPM metric reports in email or phone messages should be removed. These functions are too complex for an SNMP agent. In addition, the format of the email or SMS is not defined in any way. This will not be interoperable in any way. 17. MIB, ippmHistoryTable This table is very complex and can get very huge, or entries will be so short-lived that the table will be unstable and very difficult to retrieve. Keeping a timestamp and value for every metric value collected by the probe is overkill. 18. MIB, ippmHistorySequence Network metrics: It's the sequence number of a measurement packet. Typically, it identifies the order of the packet in the stream of packets sent by the source. Aggregated metrics: It is the sequence number of the computed aggregated metric result." Why is this object useful if the table already has an index for the measure instance? Why is an additional index for the packet sequence needed? What if the entry is for a metric that utilizes more than one packet in the measurement? 19. MIB, ippmHistoryValue SYNTAX Integer32 Why is this an Integer32 instead of Unsigned32? Could it ever be a negative number? 20. MIB, ippmNetMeasureTable " The IppmNetMeasureTable is mandatory, and its content is read only. It means that the measurement software handles the table internally. The setup of the network measure is not permitted through the IPPM REPORTING MIB. As an example, OWAP provides a setup protocol to setup and tear down networks measures. This goes entirely against the spirit of SNMP to contain a configuration table that is populated in an unspecified manner, and not allowing SNMP to be used for configuration. These objects should be read-create with a MIN-ACCESS of read-only. Also, this MIB should not include this table because this table indicates the configuration of test traffic generators. The comments in the previous paragraph apply to the MIB module that is eventually used for traffic generation. The Synthetic Sources for Performance Measurements MIB (SSPM-MIB) should be used for this purpose. The status and statistics objects in this table should be split out and placed in another table. That table may be appropriate for this MIB module. 21. MIB, IppmAggrMeasureEntry ippmAggrMeasureOwner IppmOwnerString, ippmAggrMeasureIndex Unsigned32, ippmAggrMeasureName SnmpAdminString, ippmAggrMeasureMetrics IppmStandardMetrics, ippmAggrMeasureBeginTime GMTTimeStamp, ippmAggrMeasureAggrPeriodUnit TimeUnit, ippmAggrMeasureAggrPeriod Unsigned32, ippmAggrMeasureDurationUnit TimeUnit, ippmAggrMeasureDuration Unsigned32, ippmAggrMeasureHistorySize Unsigned32, ippmAggrMeasureStorageType StorageType, ippmAggrMeasureHistoryOwner IppmOwnerString, ippmAggrMeasureHistoryOwnerIndex Unsigned32, ippmAggrMeasureHistoryMetric Unsigned32, ippmAggrMeasureAdminState INTEGER, ippmAggrMeasureFastReport OBJECT IDENTIFIER, ippmAggrMeasureMap SnmpAdminString, ippmAggrMeasureResultsMgmt INTEGER, ippmAggrMeasureLastUpdate GMTTimeStamp, ippmAggrMeasureOperState INTEGER, ippmAggrMeasureNbPktsTreated Counter64, ippmAggrMeasureStatus RowStatus This configuration table is rather complex. The ippmAggrMeasureName object is redundant, since this info is already available in another table. Recording this long string in every entry is wasteful. The ippmAggrMeasureHistoryOwner object makes this too complex. The same value for the owner in this table and the history table should be used. The ippmAggrMeasureHistoryMetric object is confusing. How does it relate to the ippmAggrMeasureMetrics object in this table? It is not clear why the ippmAggrMeasureAdminState object is needed and what it means to start or stop this entry at any time. The ippmAggrMeasureFastReport object is complex and it is not clear what value it adds. Why is this needed and ippmReport needed? 22. MIB, ippmAggrMeasureMap SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows for classification of the measure. It is typically the name of an administrative map. I have no idea what this object is for. There are no guidelines for populating this object and therefore no interoperability possible. 23. MIB, ippmReportPathToResults This URL object is a global scalar, which is odd since multiple reports for multiple owners are created. Why are results pushed off the box to a file? What is the format of this file? Just SNMP access should be provided. 24. MIB, IppmReportSetupEntry This table sets up a report but it looks like each entry represents one metric. This seems broken since the parameters would be the same for each metric collected in the set (IppmStandardMetrics OCTET STRING). A different complex report configuration for each metric is too complicated. Since some metrics are related to each other, it doesn't really make sense to have a report for each metric. It would be much better to have one report for each set of metrics collected. 25. MIB, ippmReportSetupMeasureOwner Why is this object needed? This is too complex. Any type of access control should be done by VACM, not by matching values of IppmOwnerStrings. Just the integer index pointer is needed. 26. MIB, thresholding objects in this table This thresholding mechanism is too complex and too generic to be included in this table. 27. MIB, ippmReportSetupNMS DESCRIPTION "The recipient of the report may be provided in the setup. By This object is not needed. SNMP should be used to retrieve data and other MIBs exist to determine where to send notifications. 28. MIB, ippmReportSetupNotification SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "Even though the notification to use is defined in the report definition, the object ippmReportSetupNotification provides flexibility to select another notification. " DEFVAL { zeroDotZero } This object is too vague and there is no chance for interoperability. This is also too complicated on the agent to be told by the NMS which notification to generate for each report. 29. MIB, ippmReportSetupMap DESCRIPTION "An administrative name of a map to which the report belongs." This object is too vague and has no chance for interoperability. It should be removed. 30. MIB, ippmReportEntry This table doesn't seem to add much value beyond the history table. It is also too complicated to have separate results for every metric collected in a report. How are all metrics collected for a given report correlated? The network and aggregated features seem too complicated and are not well defined. A single report for all metrics collected together for a given test should be provided instead. 31. MIB, ippmReportValue SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value." Why is this object an Integer32 instead of Unsigned32? The description is not very useful. 32. MIB, Notifications It is not very clear the exact conditions and configuration used by the agent to decide when to send each notification. It is not very clear why so many different notification types are needed. All notifications include a lot of static info that is not really needed. 33. Security considerations Very good security section! 34. References Check the MIB template for update to SNMP references. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Nov 13 11:05:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05020 for ; Thu, 13 Nov 2003 11:05:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJyD-0007F8-IL for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 11:05:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADG5Lne027841 for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 11:05:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJyD-0007Ey-Dr for ippm-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 11:05:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04988 for ; Thu, 13 Nov 2003 11:05:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJyA-0007eS-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 11:05:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJyA-0007eP-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 11:05:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJxw-00075h-5C; Thu, 13 Nov 2003 11:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJxQ-000749-VG for ippm@optimus.ietf.org; Thu, 13 Nov 2003 11:04:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04942 for ; Thu, 13 Nov 2003 11:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJxN-0007dH-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:04:29 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKJxM-0007cK-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:04:28 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Nov 2003 08:06:23 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hADG3tmU025624 for ; Thu, 13 Nov 2003 08:03:56 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-323.cisco.com [10.21.65.67]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOE70408; Thu, 13 Nov 2003 08:03:54 -0800 (PST) Message-Id: <4.3.2.7.2.20031113075842.02615600@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Nov 2003 08:02:36 -0800 To: ippm@ietf.org From: Andy Bierman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , 1. General comments Although a good job has been done documenting this MIB, IMO it is too complex to be deployable. The resource requirements in the agent are very large. Some of the tables can get extremely large, which would lead to poor SNMP performance. The resource limitation mechanisms do not align well with actual SNMP agent implementation constraints. This MIB is way too complicated and contains too many features that should be provided by an EMS or NMS. There are likely to be many implementation difficulties due to undocumented (and unforeseen) interactions between features. The MIB should be simplified to collect metric values and provide aggregation reports which can be retrieved via SNMP. Analysis of the reports, threshold based exception handling, sending email and pages to administrators, etc. should be left to the application. 2. sec. 3) SNMP Framework This boilerplate is out of date. Use the new template at: http://www.ops.ietf.org/mib-boilerplate.html 3. sec 4, para 4) RMON model This paragraph is incorrect. RMON can collect data from several interfaces which are not required to be in the same chassis. 4. sec. 4.1.3.1) Internet addresses Why are special address types needed for Src and Dest? 5. sec. 4.1.4) GMTTimeStamp Why is it important to start the timestamp from 2000 instead of 1900? This is extra work since implementations are likely to support the standard "seconds since 1900" format, not this new format. 6. sec. 4.1.6) Report definition This TC is very complex and overloads many functions into a single bit string. It should be broken out into several MIB objects for simplicity and clarity. 7. MIB, TypeP TC) This design is flawed because the authoritative name of the protocol is based on the descriptive string found in an RMON protocol identifier. However this text string is not normative and not required to be globally unique or even consistent across implementations. 8. MIB, IppmReportDefinition TC This TC overloads event management, report filtering, delivery options, and report cleanup options in a long bit string. This should be split into at least 4 TCs (or MIB objects). 9. MIB, ippmSystemTime object There should not need to be a special object for the system time. Also, how does the NMS know if the probe is in proxy mode? 10. MIB, Clock sync objects ippmSystemSynchronizationType ippmSystemSynchronizationDesc ippmSystemClockResolution These objects should be in a separate MIB module since this is a generic problem not specific to IPPM reporting. 11. MIB, ippmSynchronizationTable Why is a history table of up to 64K clock sync events needed? This will take up a lot of memory for very questionable value. 12. MIB, point of measure table IppmPointOfMeasureEntry ::= SEQUENCE { ippmPointOfMeasureIndex Unsigned32, ippmPointOfMeasureMgmtAddrType InetAddressType, ippmPointOfMeasureMgmtAddress InetAddress, ippmPointOfMeasureTestAddrTypeP TypeP, ippmPointOfMeasureTestAddr TypePaddress, ippmPointOfMeasureMetrics IppmStandardMetrics } Why is there a management address for each test point? How is this used? Why does the NMS need to know this? Doesn't the NMS just contact the IPPM SNMP agent to retrieve data? Why is the test address of the measurement point needed? Why isn't it an InetAddress? How is this used? 13. MIB, ippmMetricEntry This table is broken because there is only one entry per metric. This assumes that the collection capabilities are the same for every point of measure, which is not very likely. The ippmPointOfMeasureIndex should be added (first) to the INDEX clause in this table. 14. MIB, ippmMetricCapabilities ippmMetricCapabilities OBJECT-TYPE SYNTAX INTEGER { notImplemented(0), implemented(1) Why is this object needed? Why not just populate the table for metrics that are implemented. The other objects in this table are irrelevant or unknown if the metric is not implemented by the agent. 15. MIB, ippmOwnersTable IppmOwnersEntry ::= SEQUENCE { ippmOwnersIndex Unsigned32, ippmOwnersOwner IppmOwnerString, The ippmOwnerOwner object is the object that is used to create unique index values in other tables (e.g., that represent history entries), yet this object is required to be unique in this table. The ippmOwnersIndex object has no value at all and should be removed. This table should be indexed by the ippmOwnersOwner object. 16. MIB, owner address ippmOwnersIpAddressType InetAddressType, ippmOwnersIpAddress InetAddress, Why are these objects in the MIB? Why does it matter what the owner's address is in this MIB module? If this is for sending notifications, then use the MIBs in the SNMP Applications document, not this table. ippmOwnersEmail SnmpAdminString, ippmOwnersSMS SnmpAdminString, These objects should be removed and the functions of sending IPPM metric reports in email or phone messages should be removed. These functions are too complex for an SNMP agent. In addition, the format of the email or SMS is not defined in any way. This will not be interoperable in any way. 17. MIB, ippmHistoryTable This table is very complex and can get very huge, or entries will be so short-lived that the table will be unstable and very difficult to retrieve. Keeping a timestamp and value for every metric value collected by the probe is overkill. 18. MIB, ippmHistorySequence Network metrics: It's the sequence number of a measurement packet. Typically, it identifies the order of the packet in the stream of packets sent by the source. Aggregated metrics: It is the sequence number of the computed aggregated metric result." Why is this object useful if the table already has an index for the measure instance? Why is an additional index for the packet sequence needed? What if the entry is for a metric that utilizes more than one packet in the measurement? 19. MIB, ippmHistoryValue SYNTAX Integer32 Why is this an Integer32 instead of Unsigned32? Could it ever be a negative number? 20. MIB, ippmNetMeasureTable " The IppmNetMeasureTable is mandatory, and its content is read only. It means that the measurement software handles the table internally. The setup of the network measure is not permitted through the IPPM REPORTING MIB. As an example, OWAP provides a setup protocol to setup and tear down networks measures. This goes entirely against the spirit of SNMP to contain a configuration table that is populated in an unspecified manner, and not allowing SNMP to be used for configuration. These objects should be read-create with a MIN-ACCESS of read-only. Also, this MIB should not include this table because this table indicates the configuration of test traffic generators. The comments in the previous paragraph apply to the MIB module that is eventually used for traffic generation. The Synthetic Sources for Performance Measurements MIB (SSPM-MIB) should be used for this purpose. The status and statistics objects in this table should be split out and placed in another table. That table may be appropriate for this MIB module. 21. MIB, IppmAggrMeasureEntry ippmAggrMeasureOwner IppmOwnerString, ippmAggrMeasureIndex Unsigned32, ippmAggrMeasureName SnmpAdminString, ippmAggrMeasureMetrics IppmStandardMetrics, ippmAggrMeasureBeginTime GMTTimeStamp, ippmAggrMeasureAggrPeriodUnit TimeUnit, ippmAggrMeasureAggrPeriod Unsigned32, ippmAggrMeasureDurationUnit TimeUnit, ippmAggrMeasureDuration Unsigned32, ippmAggrMeasureHistorySize Unsigned32, ippmAggrMeasureStorageType StorageType, ippmAggrMeasureHistoryOwner IppmOwnerString, ippmAggrMeasureHistoryOwnerIndex Unsigned32, ippmAggrMeasureHistoryMetric Unsigned32, ippmAggrMeasureAdminState INTEGER, ippmAggrMeasureFastReport OBJECT IDENTIFIER, ippmAggrMeasureMap SnmpAdminString, ippmAggrMeasureResultsMgmt INTEGER, ippmAggrMeasureLastUpdate GMTTimeStamp, ippmAggrMeasureOperState INTEGER, ippmAggrMeasureNbPktsTreated Counter64, ippmAggrMeasureStatus RowStatus This configuration table is rather complex. The ippmAggrMeasureName object is redundant, since this info is already available in another table. Recording this long string in every entry is wasteful. The ippmAggrMeasureHistoryOwner object makes this too complex. The same value for the owner in this table and the history table should be used. The ippmAggrMeasureHistoryMetric object is confusing. How does it relate to the ippmAggrMeasureMetrics object in this table? It is not clear why the ippmAggrMeasureAdminState object is needed and what it means to start or stop this entry at any time. The ippmAggrMeasureFastReport object is complex and it is not clear what value it adds. Why is this needed and ippmReport needed? 22. MIB, ippmAggrMeasureMap SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "This object allows for classification of the measure. It is typically the name of an administrative map. I have no idea what this object is for. There are no guidelines for populating this object and therefore no interoperability possible. 23. MIB, ippmReportPathToResults This URL object is a global scalar, which is odd since multiple reports for multiple owners are created. Why are results pushed off the box to a file? What is the format of this file? Just SNMP access should be provided. 24. MIB, IppmReportSetupEntry This table sets up a report but it looks like each entry represents one metric. This seems broken since the parameters would be the same for each metric collected in the set (IppmStandardMetrics OCTET STRING). A different complex report configuration for each metric is too complicated. Since some metrics are related to each other, it doesn't really make sense to have a report for each metric. It would be much better to have one report for each set of metrics collected. 25. MIB, ippmReportSetupMeasureOwner Why is this object needed? This is too complex. Any type of access control should be done by VACM, not by matching values of IppmOwnerStrings. Just the integer index pointer is needed. 26. MIB, thresholding objects in this table This thresholding mechanism is too complex and too generic to be included in this table. 27. MIB, ippmReportSetupNMS DESCRIPTION "The recipient of the report may be provided in the setup. By This object is not needed. SNMP should be used to retrieve data and other MIBs exist to determine where to send notifications. 28. MIB, ippmReportSetupNotification SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "Even though the notification to use is defined in the report definition, the object ippmReportSetupNotification provides flexibility to select another notification. " DEFVAL { zeroDotZero } This object is too vague and there is no chance for interoperability. This is also too complicated on the agent to be told by the NMS which notification to generate for each report. 29. MIB, ippmReportSetupMap DESCRIPTION "An administrative name of a map to which the report belongs." This object is too vague and has no chance for interoperability. It should be removed. 30. MIB, ippmReportEntry This table doesn't seem to add much value beyond the history table. It is also too complicated to have separate results for every metric collected in a report. How are all metrics collected for a given report correlated? The network and aggregated features seem too complicated and are not well defined. A single report for all metrics collected together for a given test should be provided instead. 31. MIB, ippmReportValue SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value." Why is this object an Integer32 instead of Unsigned32? The description is not very useful. 32. MIB, Notifications It is not very clear the exact conditions and configuration used by the agent to decide when to send each notification. It is not very clear why so many different notification types are needed. All notifications include a lot of static info that is not really needed. 33. Security considerations Very good security section! 34. References Check the MIB template for update to SNMP references. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Nov 13 11:24:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05672 for ; Thu, 13 Nov 2003 11:24:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKGI-0000OL-2N; Thu, 13 Nov 2003 11:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKFw-0000No-JP for ippm@optimus.ietf.org; Thu, 13 Nov 2003 11:23:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05653 for ; Thu, 13 Nov 2003 11:23:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKFv-00008t-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:23:39 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AKKFv-00008n-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:23:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A1E6D38A; Thu, 13 Nov 2003 11:23:38 -0500 (EST) Received: from BMW (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id 621C1379; Thu, 13 Nov 2003 11:23:37 -0500 (EST) Date: Thu, 13 Nov 2003 11:23:09 -0500 From: Matthew J Zekauskas To: ippm@ietf.org Cc: Matt Zekauskas Subject: Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Message-ID: <33018387.1068722589@localhost> In-Reply-To: <4.3.2.7.2.20031113075842.02615600@fedex.cisco.com> References: <4.3.2.7.2.20031113075842.02615600@fedex.cisco.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: 7bit Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As chair, I'd like to say that Andy's comment below is what I've heard informally, but no one has to-date posted to the list. I'd like to ask others to read the draft, and comment on the complexity (or any other area) -- do you agree, or do you think that the current draft is on the right track. With my chair hat off, I concur with Andy's assessment below. What I always intended to implement with Surveyor was a simple scheme to export the basic data types; if there was any complex manipulation, it would be done by the software playing the role as a network management system. --Matt --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman wrote: > Although a good job has been done documenting this MIB, > IMO it is too complex to be deployable. The resource > requirements in the agent are very large. Some of the > tables can get extremely large, which would lead to > poor SNMP performance. The resource limitation mechanisms > do not align well with actual SNMP agent implementation > constraints. > > This MIB is way too complicated and contains too many > features that should be provided by an EMS or NMS. There > are likely to be many implementation difficulties due to > undocumented (and unforeseen) interactions between features. > The MIB should be simplified to collect metric values > and provide aggregation reports which can be retrieved > via SNMP. Analysis of the reports, threshold based > exception handling, sending email and pages to administrators, > etc. should be left to the application. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Nov 13 11:24:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05701 for ; Thu, 13 Nov 2003 11:24:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKGQ-0000RP-Lv for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 11:24:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADGOAj0001689 for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 11:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKGQ-0000RA-Gg for ippm-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 11:24:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05660 for ; Thu, 13 Nov 2003 11:23:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKGP-000095-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 11:24:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKKGP-000091-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 11:24:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKGI-0000OL-2N; Thu, 13 Nov 2003 11:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKFw-0000No-JP for ippm@optimus.ietf.org; Thu, 13 Nov 2003 11:23:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05653 for ; Thu, 13 Nov 2003 11:23:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKFv-00008t-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:23:39 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AKKFv-00008n-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:23:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A1E6D38A; Thu, 13 Nov 2003 11:23:38 -0500 (EST) Received: from BMW (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id 621C1379; Thu, 13 Nov 2003 11:23:37 -0500 (EST) Date: Thu, 13 Nov 2003 11:23:09 -0500 From: Matthew J Zekauskas To: ippm@ietf.org Cc: Matt Zekauskas Subject: Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Message-ID: <33018387.1068722589@localhost> In-Reply-To: <4.3.2.7.2.20031113075842.02615600@fedex.cisco.com> References: <4.3.2.7.2.20031113075842.02615600@fedex.cisco.com> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: 7bit Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As chair, I'd like to say that Andy's comment below is what I've heard informally, but no one has to-date posted to the list. I'd like to ask others to read the draft, and comment on the complexity (or any other area) -- do you agree, or do you think that the current draft is on the right track. With my chair hat off, I concur with Andy's assessment below. What I always intended to implement with Surveyor was a simple scheme to export the basic data types; if there was any complex manipulation, it would be done by the software playing the role as a network management system. --Matt --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman wrote: > Although a good job has been done documenting this MIB, > IMO it is too complex to be deployable. The resource > requirements in the agent are very large. Some of the > tables can get extremely large, which would lead to > poor SNMP performance. The resource limitation mechanisms > do not align well with actual SNMP agent implementation > constraints. > > This MIB is way too complicated and contains too many > features that should be provided by an EMS or NMS. There > are likely to be many implementation difficulties due to > undocumented (and unforeseen) interactions between features. > The MIB should be simplified to collect metric values > and provide aggregation reports which can be retrieved > via SNMP. Analysis of the reports, threshold based > exception handling, sending email and pages to administrators, > etc. should be left to the application. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Nov 13 11:26:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05790 for ; Thu, 13 Nov 2003 11:26:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKID-0000fz-Hq; Thu, 13 Nov 2003 11:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKHS-0000cb-9k for ippm@optimus.ietf.org; Thu, 13 Nov 2003 11:25:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05735 for ; Thu, 13 Nov 2003 11:25:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKHR-00009x-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:25:13 -0500 Received: from barry.mail.mindspring.net ([207.69.200.25]) by ietf-mx with esmtp (Exim 4.12) id 1AKKHQ-00009s-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:25:12 -0500 Received: from [192.168.167.47] (helo=wamui09.slb.atl.earthlink.net) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AKKHO-0007XC-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:25:10 -0500 Message-ID: <14958126.1068740709775.JavaMail.root@wamui09.slb.atl.earthlink.net> Date: Thu, 13 Nov 2003 10:25:09 -0600 (GMT-06:00) From: Randy Presuhn Reply-To: Randy Presuhn To: ippm@ietf.org Subject: Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi - > From: Andy Bierman > Sent: Nov 13, 2003 10:02 AM > To: ippm@ietf.org > Subject: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt ... > 5. sec. 4.1.4) GMTTimeStamp > > Why is it important to start the timestamp from 2000 > instead of 1900? This is extra work since implementations > are likely to support the standard "seconds since 1900" > format, not this new format. ... A thirty-two bit count of seconds since 1900 will soon wrap. No comment on the other merits / demerits of this TC. Randy _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Nov 13 11:26:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05805 for ; Thu, 13 Nov 2003 11:26:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKIF-0000iQ-M8 for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 11:26:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADGQ3oq002744 for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 11:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKIF-0000i7-ED for ippm-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 11:26:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05777 for ; Thu, 13 Nov 2003 11:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKIE-0000B7-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 11:26:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKKIE-0000B4-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 11:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKID-0000fz-Hq; Thu, 13 Nov 2003 11:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKHS-0000cb-9k for ippm@optimus.ietf.org; Thu, 13 Nov 2003 11:25:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05735 for ; Thu, 13 Nov 2003 11:25:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKHR-00009x-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:25:13 -0500 Received: from barry.mail.mindspring.net ([207.69.200.25]) by ietf-mx with esmtp (Exim 4.12) id 1AKKHQ-00009s-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:25:12 -0500 Received: from [192.168.167.47] (helo=wamui09.slb.atl.earthlink.net) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AKKHO-0007XC-00 for ippm@ietf.org; Thu, 13 Nov 2003 11:25:10 -0500 Message-ID: <14958126.1068740709775.JavaMail.root@wamui09.slb.atl.earthlink.net> Date: Thu, 13 Nov 2003 10:25:09 -0600 (GMT-06:00) From: Randy Presuhn Reply-To: Randy Presuhn To: ippm@ietf.org Subject: Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - > From: Andy Bierman > Sent: Nov 13, 2003 10:02 AM > To: ippm@ietf.org > Subject: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt ... > 5. sec. 4.1.4) GMTTimeStamp > > Why is it important to start the timestamp from 2000 > instead of 1900? This is extra work since implementations > are likely to support the standard "seconds since 1900" > format, not this new format. ... A thirty-two bit count of seconds since 1900 will soon wrap. No comment on the other merits / demerits of this TC. Randy _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Nov 13 13:39:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11894 for ; Thu, 13 Nov 2003 13:39:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMMv-0002nB-UG; Thu, 13 Nov 2003 13:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMM0-0002fv-Sf for ippm@optimus.ietf.org; Thu, 13 Nov 2003 13:38:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11864 for ; Thu, 13 Nov 2003 13:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMLy-0002Sx-00 for ippm@ietf.org; Thu, 13 Nov 2003 13:38:02 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AKMLx-0002Su-00 for ippm@ietf.org; Thu, 13 Nov 2003 13:38:02 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 19:37:17 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Date: Thu, 13 Nov 2003 19:37:16 +0100 Message-ID: Thread-Topic: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Thread-Index: AcOqApkaNALIKoQpRReY52AX2v7nTwAECCjw From: "STEPHAN Emile FTRD/DAC/LAN" To: "Andy Bierman" , "Matthew J Zekauskas" , X-OriginalArrivalTime: 13 Nov 2003 18:37:17.0304 (UTC) FILETIME=[2A0D0F80:01C3AA15] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear Matt and Andy, The input I received from Matt was to focus on the implemtation of the = MIB as an proxy rather than an agent embedded in each probe. When the IPPM MIB is implemeted as a proxy it is an application on the = top of the measurement system that makes a first level of aggregation = for NMS and that provides a SNMP interface to the measurement system. =20 Collecting results take a lot of place either in Surveyor the IPPM MIB, = in the RMON MIB or in a IPFIX collector. The rule of the IPPM MIB is to = make an initial consolidation of the result to avoid to flood NMS = application with unrelevant information. FTRD has implemented the proxy on the top of an industrial measurement = system. I can make a live demo of it during the meeting or after. Best Regards Emile -----Message d'origine----- De : Matthew J Zekauskas [mailto:matt@internet2.edu]=20 Envoy=E9 : jeudi 13 novembre 2003 17:23 =C0 : ippm@ietf.org Cc : Matt Zekauskas Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt As chair, I'd like to say that Andy's comment below is what I've heard = informally, but no one has to-date posted to the list. I'd like to ask = others to read the draft, and comment on the complexity (or any other = area) -- do you agree, or do you think that the current draft is on the = right track. With my chair hat off, I concur with Andy's assessment below. What I = always intended to implement with Surveyor was a simple scheme to export = the basic data types; if there was any complex manipulation, it would be = done by the software playing the role as a network management system. --Matt --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman = wrote: > Although a good job has been done documenting this MIB, > IMO it is too complex to be deployable. The resource requirements in=20 > the agent are very large. Some of the tables can get extremely large, = > which would lead to poor SNMP performance. The resource limitation=20 > mechanisms do not align well with actual SNMP agent implementation > constraints. > > This MIB is way too complicated and contains too many features that=20 > should be provided by an EMS or NMS. There are likely to be many=20 > implementation difficulties due to undocumented (and unforeseen)=20 > interactions between features. The MIB should be simplified to collect = > metric values and provide aggregation reports which can be retrieved > via SNMP. Analysis of the reports, threshold based > exception handling, sending email and pages to administrators, > etc. should be left to the application. _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Nov 13 13:39:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11912 for ; Thu, 13 Nov 2003 13:39:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMN7-0002pc-5b for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 13:39:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADIdDNp010883 for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 13:39:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMN6-0002pO-Kx for ippm-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 13:39:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11881 for ; Thu, 13 Nov 2003 13:39:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMN4-0002TX-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 13:39:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKMN4-0002TU-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 13:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMMv-0002nB-UG; Thu, 13 Nov 2003 13:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMM0-0002fv-Sf for ippm@optimus.ietf.org; Thu, 13 Nov 2003 13:38:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11864 for ; Thu, 13 Nov 2003 13:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMLy-0002Sx-00 for ippm@ietf.org; Thu, 13 Nov 2003 13:38:02 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AKMLx-0002Su-00 for ippm@ietf.org; Thu, 13 Nov 2003 13:38:02 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 19:37:17 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Date: Thu, 13 Nov 2003 19:37:16 +0100 Message-ID: Thread-Topic: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Thread-Index: AcOqApkaNALIKoQpRReY52AX2v7nTwAECCjw From: "STEPHAN Emile FTRD/DAC/LAN" To: "Andy Bierman" , "Matthew J Zekauskas" , X-OriginalArrivalTime: 13 Nov 2003 18:37:17.0304 (UTC) FILETIME=[2A0D0F80:01C3AA15] Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Matt and Andy, The input I received from Matt was to focus on the implemtation of the = MIB as an proxy rather than an agent embedded in each probe. When the IPPM MIB is implemeted as a proxy it is an application on the = top of the measurement system that makes a first level of aggregation = for NMS and that provides a SNMP interface to the measurement system. =20 Collecting results take a lot of place either in Surveyor the IPPM MIB, = in the RMON MIB or in a IPFIX collector. The rule of the IPPM MIB is to = make an initial consolidation of the result to avoid to flood NMS = application with unrelevant information. FTRD has implemented the proxy on the top of an industrial measurement = system. I can make a live demo of it during the meeting or after. Best Regards Emile -----Message d'origine----- De : Matthew J Zekauskas [mailto:matt@internet2.edu]=20 Envoy=E9 : jeudi 13 novembre 2003 17:23 =C0 : ippm@ietf.org Cc : Matt Zekauskas Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt As chair, I'd like to say that Andy's comment below is what I've heard = informally, but no one has to-date posted to the list. I'd like to ask = others to read the draft, and comment on the complexity (or any other = area) -- do you agree, or do you think that the current draft is on the = right track. With my chair hat off, I concur with Andy's assessment below. What I = always intended to implement with Surveyor was a simple scheme to export = the basic data types; if there was any complex manipulation, it would be = done by the software playing the role as a network management system. --Matt --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman = wrote: > Although a good job has been done documenting this MIB, > IMO it is too complex to be deployable. The resource requirements in=20 > the agent are very large. Some of the tables can get extremely large, = > which would lead to poor SNMP performance. The resource limitation=20 > mechanisms do not align well with actual SNMP agent implementation > constraints. > > This MIB is way too complicated and contains too many features that=20 > should be provided by an EMS or NMS. There are likely to be many=20 > implementation difficulties due to undocumented (and unforeseen)=20 > interactions between features. The MIB should be simplified to collect = > metric values and provide aggregation reports which can be retrieved > via SNMP. Analysis of the reports, threshold based > exception handling, sending email and pages to administrators, > etc. should be left to the application. _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Nov 13 14:14:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13554 for ; Thu, 13 Nov 2003 14:14:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMun-0005IL-Rx; Thu, 13 Nov 2003 14:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMu7-0005Dx-6v for ippm@optimus.ietf.org; Thu, 13 Nov 2003 14:13:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13390 for ; Thu, 13 Nov 2003 14:13:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMu4-00036S-00 for ippm@ietf.org; Thu, 13 Nov 2003 14:13:16 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKMu4-00035R-00 for ippm@ietf.org; Thu, 13 Nov 2003 14:13:16 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Nov 2003 11:15:11 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hADJCfw7010749; Thu, 13 Nov 2003 11:12:43 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-614.cisco.com [10.21.66.102]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOE96324; Thu, 13 Nov 2003 11:12:40 -0800 (PST) Message-Id: <4.3.2.7.2.20031113111036.0261fe10@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Nov 2003 11:11:23 -0800 To: Randy Presuhn From: Andy Bierman Subject: Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Cc: ippm@ietf.org In-Reply-To: <14958126.1068740709775.JavaMail.root@wamui09.slb.atl.earth link.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , At 08:25 AM 11/13/2003, Randy Presuhn wrote: >Hi - > >> From: Andy Bierman >> Sent: Nov 13, 2003 10:02 AM >> To: ippm@ietf.org >> Subject: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt >... >> 5. sec. 4.1.4) GMTTimeStamp >> >> Why is it important to start the timestamp from 2000 >> instead of 1900? This is extra work since implementations >> are likely to support the standard "seconds since 1900" >> format, not this new format. >... > >A thirty-two bit count of seconds since 1900 will soon wrap. >No comment on the other merits / demerits of this TC. I meant seconds since 1970. I think the DateAndTime TC should be used instead. >Randy Andy >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Nov 13 14:14:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13586 for ; Thu, 13 Nov 2003 14:14:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMuw-0005N2-EB for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 14:14:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADJEA0N020638 for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 14:14:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMuw-0005Mm-8X for ippm-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 14:14:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13493 for ; Thu, 13 Nov 2003 14:13:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMut-00037W-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 14:14:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKMut-00037S-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 14:14:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMun-0005IL-Rx; Thu, 13 Nov 2003 14:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMu7-0005Dx-6v for ippm@optimus.ietf.org; Thu, 13 Nov 2003 14:13:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13390 for ; Thu, 13 Nov 2003 14:13:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMu4-00036S-00 for ippm@ietf.org; Thu, 13 Nov 2003 14:13:16 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKMu4-00035R-00 for ippm@ietf.org; Thu, 13 Nov 2003 14:13:16 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 Nov 2003 11:15:11 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hADJCfw7010749; Thu, 13 Nov 2003 11:12:43 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn3-614.cisco.com [10.21.66.102]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AOE96324; Thu, 13 Nov 2003 11:12:40 -0800 (PST) Message-Id: <4.3.2.7.2.20031113111036.0261fe10@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Nov 2003 11:11:23 -0800 To: Randy Presuhn From: Andy Bierman Subject: Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Cc: ippm@ietf.org In-Reply-To: <14958126.1068740709775.JavaMail.root@wamui09.slb.atl.earth link.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , At 08:25 AM 11/13/2003, Randy Presuhn wrote: >Hi - > >> From: Andy Bierman >> Sent: Nov 13, 2003 10:02 AM >> To: ippm@ietf.org >> Subject: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt >... >> 5. sec. 4.1.4) GMTTimeStamp >> >> Why is it important to start the timestamp from 2000 >> instead of 1900? This is extra work since implementations >> are likely to support the standard "seconds since 1900" >> format, not this new format. >... > >A thirty-two bit count of seconds since 1900 will soon wrap. >No comment on the other merits / demerits of this TC. I meant seconds since 1970. I think the DateAndTime TC should be used instead. >Randy Andy >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Nov 13 17:23:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24481 for ; Thu, 13 Nov 2003 17:23:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPrg-0003Rd-TQ; Thu, 13 Nov 2003 17:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPqt-0003R8-1T for ippm@optimus.ietf.org; Thu, 13 Nov 2003 17:22:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24430 for ; Thu, 13 Nov 2003 17:21:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKPqq-0006f5-00 for ippm@ietf.org; Thu, 13 Nov 2003 17:22:08 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AKPqq-0006ev-00 for ippm@ietf.org; Thu, 13 Nov 2003 17:22:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 0FB7D43E; Thu, 13 Nov 2003 17:22:01 -0500 (EST) Received: from BMW (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id 1D29A434; Thu, 13 Nov 2003 17:21:59 -0500 (EST) Date: Thu, 13 Nov 2003 17:21:56 -0500 From: Matthew J Zekauskas To: ippm@ietf.org Cc: Matt Zekauskas Message-ID: <54542327.1068744116@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: 7bit Subject: [ippm] IPMP / IMP discussion Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit For those not on the IMRG (Internet Measurement Research Group) or the TSVWG list, as mentioned in the meeting today there is a discussion of IPMP (presented in this group by both Tony McGregor and Jon Bennett) going on inside IMRG. Jon's announcement on tsvwg: > Date: Wed, 12 Nov 2003 07:10:04 -0800 (PST) > From: jon b > To: tsvwg@ietf.org > Subject: [Tsvwg] IPMP discussion on the IMRG list > > As mentioned in the meeting on Monday the discussion of IPMP has now > moved to the IMRG list at > > https://www1.ietf.org/mail-archive/working-groups/imrg/current/msg00154.html > > We invite anyone interested in the topic to participate in the > discussion. > > Jon Bennett _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Nov 13 17:23:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24496 for ; Thu, 13 Nov 2003 17:23:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPs2-0003Tr-0g for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 17:23:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADMNLsb013376 for ippm-archive@odin.ietf.org; Thu, 13 Nov 2003 17:23:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPs1-0003Tf-NY for ippm-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 17:23:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24473 for ; Thu, 13 Nov 2003 17:23:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKPrz-0006fs-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 17:23:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKPrz-0006fp-00 for ippm-web-archive@ietf.org; Thu, 13 Nov 2003 17:23:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPrg-0003Rd-TQ; Thu, 13 Nov 2003 17:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPqt-0003R8-1T for ippm@optimus.ietf.org; Thu, 13 Nov 2003 17:22:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24430 for ; Thu, 13 Nov 2003 17:21:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKPqq-0006f5-00 for ippm@ietf.org; Thu, 13 Nov 2003 17:22:08 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AKPqq-0006ev-00 for ippm@ietf.org; Thu, 13 Nov 2003 17:22:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 0FB7D43E; Thu, 13 Nov 2003 17:22:01 -0500 (EST) Received: from BMW (unknown [207.75.164.22]) by basie.internet2.edu (Postfix) with ESMTP id 1D29A434; Thu, 13 Nov 2003 17:21:59 -0500 (EST) Date: Thu, 13 Nov 2003 17:21:56 -0500 From: Matthew J Zekauskas To: ippm@ietf.org Cc: Matt Zekauskas Message-ID: <54542327.1068744116@localhost> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by mail.internet2.edu virus scanner Content-Transfer-Encoding: 7bit Subject: [ippm] IPMP / IMP discussion Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit For those not on the IMRG (Internet Measurement Research Group) or the TSVWG list, as mentioned in the meeting today there is a discussion of IPMP (presented in this group by both Tony McGregor and Jon Bennett) going on inside IMRG. Jon's announcement on tsvwg: > Date: Wed, 12 Nov 2003 07:10:04 -0800 (PST) > From: jon b > To: tsvwg@ietf.org > Subject: [Tsvwg] IPMP discussion on the IMRG list > > As mentioned in the meeting on Monday the discussion of IPMP has now > moved to the IMRG list at > > https://www1.ietf.org/mail-archive/working-groups/imrg/current/msg00154.html > > We invite anyone interested in the topic to participate in the > discussion. > > Jon Bennett _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Nov 14 13:25:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23541 for ; Fri, 14 Nov 2003 13:25:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKicy-0005Q7-1X; Fri, 14 Nov 2003 13:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKici-0005Iz-U9 for ippm@optimus.ietf.org; Fri, 14 Nov 2003 13:24:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23475 for ; Fri, 14 Nov 2003 13:24:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKicg-0002JI-00 for ippm@ietf.org; Fri, 14 Nov 2003 13:24:46 -0500 Received: from u-mail.rd.francetelecom.com ([208.25.178.63]) by ietf-mx with esmtp (Exim 4.12) id 1AKicg-0002JF-00 for ippm@ietf.org; Fri, 14 Nov 2003 13:24:46 -0500 Received: by U-MAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Nov 2003 10:23:29 -0800 Message-ID: <037E7050631FD611AAFD0002A509146A0119FD71@U-MAIL2> From: JEWITT Jessie / FTR&D / US To: STEPHAN Emile FTRD/DAC/LAN , "'Andy Bierman'" , "'Matthew J Zekauskas'" , "'ippm@ietf.org'" Subject: RE: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Date: Fri, 14 Nov 2003 10:26:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AADC.C768B140" Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AADC.C768B140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Emile- I am back in the office and would be happy to arrange a demo for = anyone, either here in the lab or via an external interface. Jessie -----Original Message----- From: STEPHAN Emile FTRD/DAC/LAN=20 Sent: Thursday, November 13, 2003 10:40 AM To: Andy Bierman; Matthew J Zekauskas; ippm@ietf.org Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Dear Matt and Andy, The input I received from Matt was to focus on the implemtation of the = MIB as an proxy rather than an agent embedded in each probe. When the IPPM MIB is implemeted as a proxy it is an application on the = top of the measurement system that makes a first level of aggregation for = NMS and that provides a SNMP interface to the measurement system. =20 Collecting results take a lot of place either in Surveyor the IPPM MIB, = in the RMON MIB or in a IPFIX collector. The rule of the IPPM MIB is to = make an initial consolidation of the result to avoid to flood NMS application = with unrelevant information. FTRD has implemented the proxy on the top of an industrial measurement system. I can make a live demo of it during the meeting or after. Best Regards Emile -----Message d'origine----- De : Matthew J Zekauskas [mailto:matt@internet2.edu]=20 Envoy=E9 : jeudi 13 novembre 2003 17:23 =C0 : ippm@ietf.org Cc : Matt Zekauskas Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt As chair, I'd like to say that Andy's comment below is what I've heard informally, but no one has to-date posted to the list. I'd like to ask others to read the draft, and comment on the complexity (or any other = area) -- do you agree, or do you think that the current draft is on the = right track. With my chair hat off, I concur with Andy's assessment below. What I = always intended to implement with Surveyor was a simple scheme to export the = basic data types; if there was any complex manipulation, it would be done by = the software playing the role as a network management system. --Matt --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman wrote: > Although a good job has been done documenting this MIB, > IMO it is too complex to be deployable. The resource requirements in = > the agent are very large. Some of the tables can get extremely = large,=20 > which would lead to poor SNMP performance. The resource limitation=20 > mechanisms do not align well with actual SNMP agent implementation > constraints. > > This MIB is way too complicated and contains too many features that=20 > should be provided by an EMS or NMS. There are likely to be many=20 > implementation difficulties due to undocumented (and unforeseen)=20 > interactions between features. The MIB should be simplified to = collect=20 > metric values and provide aggregation reports which can be retrieved > via SNMP. Analysis of the reports, threshold based > exception handling, sending email and pages to administrators, > etc. should be left to the application. _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm ------_=_NextPart_001_01C3AADC.C768B140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE : [ippm] comments on = draft-ietf-ippm-reporting-mib-04.txt

Emile-
   I am back in the office and would be = happy to arrange a demo for anyone, either here in the lab or via an = external interface.

Jessie

-----Original Message-----
From: STEPHAN Emile FTRD/DAC/LAN
Sent: Thursday, November 13, 2003 10:40 AM
To: Andy Bierman; Matthew J Zekauskas; = ippm@ietf.org
Subject: RE : [ippm] comments on = draft-ietf-ippm-reporting-mib-04.txt



Dear Matt and Andy,

The input I received from Matt was to focus on the = implemtation of the MIB as an proxy rather than an agent embedded in = each probe.

When the IPPM MIB is implemeted as a proxy it is an = application on the top of the measurement system that makes a first = level of aggregation for NMS and that provides a SNMP interface to the = measurement system.

 
Collecting results take a lot of place either in = Surveyor the IPPM MIB, in the RMON MIB or in a IPFIX collector. The = rule of the IPPM MIB is to make an initial consolidation of the result = to avoid to flood NMS application with unrelevant = information.

FTRD has implemented the proxy on the top of an = industrial measurement system. I can make a live demo of it during the = meeting or after.

Best Regards
Emile


-----Message d'origine-----
De : Matthew J Zekauskas [mailto:matt@internet2.edu] =
Envoy=E9 : jeudi 13 novembre 2003 17:23
=C0 : ippm@ietf.org
Cc : Matt Zekauskas
Objet : Re: [ippm] comments on = draft-ietf-ippm-reporting-mib-04.txt


As chair, I'd like to say that Andy's comment below = is what I've heard informally, but no one has to-date posted to the = list.  I'd like to ask others to read the draft, and comment on = the complexity (or any other area) --  do you agree, or do you = think that the current draft is on the right track.

With my chair hat off, I concur with Andy's = assessment below. What I always intended to implement with Surveyor was = a simple scheme to export the basic data types; if there was any = complex manipulation, it would be done by the software playing the role = as a network management system.

--Matt

--On Thursday, November 13, 2003 8:02 AM -0800 Andy = Bierman <abierman@cisco.com> wrote:

> Although a good job has been done documenting = this MIB,
> IMO it is too complex to be deployable.  = The resource requirements in
> the agent are very large.  Some of the = tables can get extremely large,
> which would lead to poor SNMP = performance.  The resource limitation
> mechanisms do not align well with actual SNMP = agent implementation
> constraints.
>
> This MIB is way too complicated and contains = too many features that
> should be provided by an EMS or NMS.  = There are likely to be many
> implementation difficulties due to undocumented = (and unforeseen)
> interactions between features. The MIB should = be simplified to collect
> metric values and provide aggregation reports = which can be retrieved
> via SNMP.  Analysis of the reports, = threshold based
> exception handling, sending email and pages to = administrators,
> etc. should be left to the application.



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

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

------_=_NextPart_001_01C3AADC.C768B140-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Nov 14 13:25:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23559 for ; Fri, 14 Nov 2003 13:25:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKidL-0005ez-1J for ippm-archive@odin.ietf.org; Fri, 14 Nov 2003 13:25:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEIPQfW021751 for ippm-archive@odin.ietf.org; Fri, 14 Nov 2003 13:25:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKidK-0005ek-RK for ippm-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 13:25:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23493 for ; Fri, 14 Nov 2003 13:25:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKidI-0002Ju-00 for ippm-web-archive@ietf.org; Fri, 14 Nov 2003 13:25:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKidI-0002Jq-00 for ippm-web-archive@ietf.org; Fri, 14 Nov 2003 13:25:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKicy-0005Q7-1X; Fri, 14 Nov 2003 13:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKici-0005Iz-U9 for ippm@optimus.ietf.org; Fri, 14 Nov 2003 13:24:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23475 for ; Fri, 14 Nov 2003 13:24:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKicg-0002JI-00 for ippm@ietf.org; Fri, 14 Nov 2003 13:24:46 -0500 Received: from u-mail.rd.francetelecom.com ([208.25.178.63]) by ietf-mx with esmtp (Exim 4.12) id 1AKicg-0002JF-00 for ippm@ietf.org; Fri, 14 Nov 2003 13:24:46 -0500 Received: by U-MAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Nov 2003 10:23:29 -0800 Message-ID: <037E7050631FD611AAFD0002A509146A0119FD71@U-MAIL2> From: JEWITT Jessie / FTR&D / US To: STEPHAN Emile FTRD/DAC/LAN , "'Andy Bierman'" , "'Matthew J Zekauskas'" , "'ippm@ietf.org'" Subject: RE: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Date: Fri, 14 Nov 2003 10:26:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AADC.C768B140" Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3AADC.C768B140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Emile- I am back in the office and would be happy to arrange a demo for = anyone, either here in the lab or via an external interface. Jessie -----Original Message----- From: STEPHAN Emile FTRD/DAC/LAN=20 Sent: Thursday, November 13, 2003 10:40 AM To: Andy Bierman; Matthew J Zekauskas; ippm@ietf.org Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Dear Matt and Andy, The input I received from Matt was to focus on the implemtation of the = MIB as an proxy rather than an agent embedded in each probe. When the IPPM MIB is implemeted as a proxy it is an application on the = top of the measurement system that makes a first level of aggregation for = NMS and that provides a SNMP interface to the measurement system. =20 Collecting results take a lot of place either in Surveyor the IPPM MIB, = in the RMON MIB or in a IPFIX collector. The rule of the IPPM MIB is to = make an initial consolidation of the result to avoid to flood NMS application = with unrelevant information. FTRD has implemented the proxy on the top of an industrial measurement system. I can make a live demo of it during the meeting or after. Best Regards Emile -----Message d'origine----- De : Matthew J Zekauskas [mailto:matt@internet2.edu]=20 Envoy=E9 : jeudi 13 novembre 2003 17:23 =C0 : ippm@ietf.org Cc : Matt Zekauskas Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt As chair, I'd like to say that Andy's comment below is what I've heard informally, but no one has to-date posted to the list. I'd like to ask others to read the draft, and comment on the complexity (or any other = area) -- do you agree, or do you think that the current draft is on the = right track. With my chair hat off, I concur with Andy's assessment below. What I = always intended to implement with Surveyor was a simple scheme to export the = basic data types; if there was any complex manipulation, it would be done by = the software playing the role as a network management system. --Matt --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman wrote: > Although a good job has been done documenting this MIB, > IMO it is too complex to be deployable. The resource requirements in = > the agent are very large. Some of the tables can get extremely = large,=20 > which would lead to poor SNMP performance. The resource limitation=20 > mechanisms do not align well with actual SNMP agent implementation > constraints. > > This MIB is way too complicated and contains too many features that=20 > should be provided by an EMS or NMS. There are likely to be many=20 > implementation difficulties due to undocumented (and unforeseen)=20 > interactions between features. The MIB should be simplified to = collect=20 > metric values and provide aggregation reports which can be retrieved > via SNMP. Analysis of the reports, threshold based > exception handling, sending email and pages to administrators, > etc. should be left to the application. _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm ------_=_NextPart_001_01C3AADC.C768B140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RE : [ippm] comments on = draft-ietf-ippm-reporting-mib-04.txt

Emile-
   I am back in the office and would be = happy to arrange a demo for anyone, either here in the lab or via an = external interface.

Jessie

-----Original Message-----
From: STEPHAN Emile FTRD/DAC/LAN
Sent: Thursday, November 13, 2003 10:40 AM
To: Andy Bierman; Matthew J Zekauskas; = ippm@ietf.org
Subject: RE : [ippm] comments on = draft-ietf-ippm-reporting-mib-04.txt



Dear Matt and Andy,

The input I received from Matt was to focus on the = implemtation of the MIB as an proxy rather than an agent embedded in = each probe.

When the IPPM MIB is implemeted as a proxy it is an = application on the top of the measurement system that makes a first = level of aggregation for NMS and that provides a SNMP interface to the = measurement system.

 
Collecting results take a lot of place either in = Surveyor the IPPM MIB, in the RMON MIB or in a IPFIX collector. The = rule of the IPPM MIB is to make an initial consolidation of the result = to avoid to flood NMS application with unrelevant = information.

FTRD has implemented the proxy on the top of an = industrial measurement system. I can make a live demo of it during the = meeting or after.

Best Regards
Emile


-----Message d'origine-----
De : Matthew J Zekauskas [mailto:matt@internet2.edu] =
Envoy=E9 : jeudi 13 novembre 2003 17:23
=C0 : ippm@ietf.org
Cc : Matt Zekauskas
Objet : Re: [ippm] comments on = draft-ietf-ippm-reporting-mib-04.txt


As chair, I'd like to say that Andy's comment below = is what I've heard informally, but no one has to-date posted to the = list.  I'd like to ask others to read the draft, and comment on = the complexity (or any other area) --  do you agree, or do you = think that the current draft is on the right track.

With my chair hat off, I concur with Andy's = assessment below. What I always intended to implement with Surveyor was = a simple scheme to export the basic data types; if there was any = complex manipulation, it would be done by the software playing the role = as a network management system.

--Matt

--On Thursday, November 13, 2003 8:02 AM -0800 Andy = Bierman <abierman@cisco.com> wrote:

> Although a good job has been done documenting = this MIB,
> IMO it is too complex to be deployable.  = The resource requirements in
> the agent are very large.  Some of the = tables can get extremely large,
> which would lead to poor SNMP = performance.  The resource limitation
> mechanisms do not align well with actual SNMP = agent implementation
> constraints.
>
> This MIB is way too complicated and contains = too many features that
> should be provided by an EMS or NMS.  = There are likely to be many
> implementation difficulties due to undocumented = (and unforeseen)
> interactions between features. The MIB should = be simplified to collect
> metric values and provide aggregation reports = which can be retrieved
> via SNMP.  Analysis of the reports, = threshold based
> exception handling, sending email and pages to = administrators,
> etc. should be left to the application.



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

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

------_=_NextPart_001_01C3AADC.C768B140-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Nov 14 14:22:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25046 for ; Fri, 14 Nov 2003 14:22:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjW5-0001AN-NW; Fri, 14 Nov 2003 14:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjW1-0001A8-Ag for ippm@optimus.ietf.org; Fri, 14 Nov 2003 14:21:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25033 for ; Fri, 14 Nov 2003 14:21:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjVy-0002zV-00 for ippm@ietf.org; Fri, 14 Nov 2003 14:21:54 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AKjVy-0002zS-00 for ippm@ietf.org; Fri, 14 Nov 2003 14:21:54 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAEJJOx3013518 for ; Fri, 14 Nov 2003 14:19:24 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAEJJMx3013476 for ; Fri, 14 Nov 2003 14:19:23 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 14 Nov 2003 21:21:46 +0200 Message-ID: Thread-Topic: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Thread-Index: AcOqApkaNALIKoQpRReY52AX2v7nTwAECCjwADRXYLA= From: "Romascanu, Dan (Dan)" To: "STEPHAN Emile FTRD/DAC/LAN" , "Andy Bierman" , "Matthew J Zekauskas" , Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Emile, I think that the IPPM MIB document would benefit from a framework = section explaining in more details the concepts that you and Matt are = describing in your mails - what are the targets where the MIB is = expected to run, how you define the relationship between the entities = that you call proxy, Surveyor, NMS, etc.=20 Regards, Dan > -----Original Message----- > From: ippm-admin@ietf.org [mailto:ippm-admin@ietf.org]On=20 > Behalf Of STEPHAN Emile FTRD/DAC/LAN > Sent: 13 November, 2003 8:37 PM > To: Andy Bierman; Matthew J Zekauskas; ippm@ietf.org > Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt >=20 >=20 >=20 > Dear Matt and Andy, >=20 > The input I received from Matt was to focus on the=20 > implemtation of the MIB as an proxy rather than an agent=20 > embedded in each probe. >=20 > When the IPPM MIB is implemeted as a proxy it is an=20 > application on the top of the measurement system that makes a=20 > first level of aggregation for NMS and that provides a SNMP=20 > interface to the measurement system. > =20 > Collecting results take a lot of place either in Surveyor the=20 > IPPM MIB, in the RMON MIB or in a IPFIX collector. The rule=20 > of the IPPM MIB is to make an initial consolidation of the=20 > result to avoid to flood NMS application with unrelevant information. >=20 > FTRD has implemented the proxy on the top of an industrial=20 > measurement system. I can make a live demo of it during the=20 > meeting or after. >=20 > Best Regards > Emile >=20 >=20 > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@internet2.edu]=20 > Envoy=E9 : jeudi 13 novembre 2003 17:23 > =C0 : ippm@ietf.org > Cc : Matt Zekauskas > Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt >=20 >=20 > As chair, I'd like to say that Andy's comment below is what=20 > I've heard informally, but no one has to-date posted to the=20 > list. I'd like to ask others to read the draft, and comment=20 > on the complexity (or any other area) -- do you agree, or do=20 > you think that the current draft is on the right track. >=20 > With my chair hat off, I concur with Andy's assessment below.=20 > What I always intended to implement with Surveyor was a=20 > simple scheme to export the basic data types; if there was=20 > any complex manipulation, it would be done by the software=20 > playing the role as a network management system. >=20 > --Matt >=20 > --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman=20 > wrote: >=20 > > Although a good job has been done documenting this MIB, > > IMO it is too complex to be deployable. The resource=20 > requirements in=20 > > the agent are very large. Some of the tables can get=20 > extremely large,=20 > > which would lead to poor SNMP performance. The resource limitation=20 > > mechanisms do not align well with actual SNMP agent implementation > > constraints. > > > > This MIB is way too complicated and contains too many features that=20 > > should be provided by an EMS or NMS. There are likely to be many=20 > > implementation difficulties due to undocumented (and unforeseen)=20 > > interactions between features. The MIB should be simplified=20 > to collect=20 > > metric values and provide aggregation reports which can be retrieved > > via SNMP. Analysis of the reports, threshold based > > exception handling, sending email and pages to administrators, > > etc. should be left to the application. >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ippm >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Nov 14 14:24:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25198 for ; Fri, 14 Nov 2003 14:24:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjYW-0001Jj-9U for ippm-archive@odin.ietf.org; Fri, 14 Nov 2003 14:24:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEJOW1F005057 for ippm-archive@odin.ietf.org; Fri, 14 Nov 2003 14:24:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjYW-0001JU-4G for ippm-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 14:24:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25144 for ; Fri, 14 Nov 2003 14:24:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjYT-000321-00 for ippm-web-archive@ietf.org; Fri, 14 Nov 2003 14:24:29 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AKjYS-00031k-02 for ippm-web-archive@ietf.org; Fri, 14 Nov 2003 14:24:28 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AKjWC-0001nI-Aw for ippm-web-archive@ietf.org; Fri, 14 Nov 2003 14:22:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjW5-0001AN-NW; Fri, 14 Nov 2003 14:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjW1-0001A8-Ag for ippm@optimus.ietf.org; Fri, 14 Nov 2003 14:21:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25033 for ; Fri, 14 Nov 2003 14:21:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjVy-0002zV-00 for ippm@ietf.org; Fri, 14 Nov 2003 14:21:54 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AKjVy-0002zS-00 for ippm@ietf.org; Fri, 14 Nov 2003 14:21:54 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAEJJOx3013518 for ; Fri, 14 Nov 2003 14:19:24 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAEJJMx3013476 for ; Fri, 14 Nov 2003 14:19:23 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 14 Nov 2003 21:21:46 +0200 Message-ID: Thread-Topic: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Thread-Index: AcOqApkaNALIKoQpRReY52AX2v7nTwAECCjwADRXYLA= From: "Romascanu, Dan (Dan)" To: "STEPHAN Emile FTRD/DAC/LAN" , "Andy Bierman" , "Matthew J Zekauskas" , Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Emile, I think that the IPPM MIB document would benefit from a framework = section explaining in more details the concepts that you and Matt are = describing in your mails - what are the targets where the MIB is = expected to run, how you define the relationship between the entities = that you call proxy, Surveyor, NMS, etc.=20 Regards, Dan > -----Original Message----- > From: ippm-admin@ietf.org [mailto:ippm-admin@ietf.org]On=20 > Behalf Of STEPHAN Emile FTRD/DAC/LAN > Sent: 13 November, 2003 8:37 PM > To: Andy Bierman; Matthew J Zekauskas; ippm@ietf.org > Subject: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt >=20 >=20 >=20 > Dear Matt and Andy, >=20 > The input I received from Matt was to focus on the=20 > implemtation of the MIB as an proxy rather than an agent=20 > embedded in each probe. >=20 > When the IPPM MIB is implemeted as a proxy it is an=20 > application on the top of the measurement system that makes a=20 > first level of aggregation for NMS and that provides a SNMP=20 > interface to the measurement system. > =20 > Collecting results take a lot of place either in Surveyor the=20 > IPPM MIB, in the RMON MIB or in a IPFIX collector. The rule=20 > of the IPPM MIB is to make an initial consolidation of the=20 > result to avoid to flood NMS application with unrelevant information. >=20 > FTRD has implemented the proxy on the top of an industrial=20 > measurement system. I can make a live demo of it during the=20 > meeting or after. >=20 > Best Regards > Emile >=20 >=20 > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@internet2.edu]=20 > Envoy=E9 : jeudi 13 novembre 2003 17:23 > =C0 : ippm@ietf.org > Cc : Matt Zekauskas > Objet : Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt >=20 >=20 > As chair, I'd like to say that Andy's comment below is what=20 > I've heard informally, but no one has to-date posted to the=20 > list. I'd like to ask others to read the draft, and comment=20 > on the complexity (or any other area) -- do you agree, or do=20 > you think that the current draft is on the right track. >=20 > With my chair hat off, I concur with Andy's assessment below.=20 > What I always intended to implement with Surveyor was a=20 > simple scheme to export the basic data types; if there was=20 > any complex manipulation, it would be done by the software=20 > playing the role as a network management system. >=20 > --Matt >=20 > --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman=20 > wrote: >=20 > > Although a good job has been done documenting this MIB, > > IMO it is too complex to be deployable. The resource=20 > requirements in=20 > > the agent are very large. Some of the tables can get=20 > extremely large,=20 > > which would lead to poor SNMP performance. The resource limitation=20 > > mechanisms do not align well with actual SNMP agent implementation > > constraints. > > > > This MIB is way too complicated and contains too many features that=20 > > should be provided by an EMS or NMS. There are likely to be many=20 > > implementation difficulties due to undocumented (and unforeseen)=20 > > interactions between features. The MIB should be simplified=20 > to collect=20 > > metric values and provide aggregation reports which can be retrieved > > via SNMP. Analysis of the reports, threshold based > > exception handling, sending email and pages to administrators, > > etc. should be left to the application. >=20 >=20 >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ippm >=20 > _______________________________________________ > ippm mailing list > ippm@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ippm >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Wed Nov 19 07:57:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14926 for ; Wed, 19 Nov 2003 07:57:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRtF-0007EM-D5; Wed, 19 Nov 2003 07:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRsX-00079P-DI for ippm@optimus.ietf.org; Wed, 19 Nov 2003 07:56:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14875 for ; Wed, 19 Nov 2003 07:56:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRsW-0006Ss-00 for ippm@ietf.org; Wed, 19 Nov 2003 07:56:16 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AMRsV-0006Sp-00 for ippm@ietf.org; Wed, 19 Nov 2003 07:56:16 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAJCrjdC004030 for ; Wed, 19 Nov 2003 07:53:45 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAJCrgdC003987 for ; Wed, 19 Nov 2003 07:53:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Date: Wed, 19 Nov 2003 14:56:10 +0200 Message-ID: Thread-Topic: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Thread-Index: AcOumQAqUjpxfCXNSC6qZUst6hKZUQAAwrnQ From: "Romascanu, Dan (Dan)" To: "Henk Uijterwaal (RIPE-NCC)" Cc: "STEPHAN Emile FTRD/DAC/LAN" , "Andy Bierman" , "Matthew J Zekauskas" , Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Henk, >=20 >=20 > Dan, >=20 > > I think that the IPPM MIB document would benefit from a framework > > section explaining in more details the concepts that you=20 > and Matt are > > describing in your mails - what are the targets where the MIB is > > expected to run, how you define the relationship between=20 > the entities > > that you call proxy, Surveyor, NMS, etc. >=20 > Wait a second: Surveyor is only one of the implementations of the > One-way-delay and one-way-loss metrics, there are more=20 > implementations. >=20 This was not clear from the chain of mails, and this is why a framework = section explaining the role of the different entities, and the proposed = configurations for deployment would be useful. Specific implementations = need not be covered in the standard, but may of course be a subject for = informational documents. > Henk >=20 Dan >=20 > -------------------------------------------------------------- > ---------------- > Henk Uijterwaal Email:=20 > henk.uijterwaal@ripe.net > RIPE Network Coordination Centre WWW:=20 > http://www.ripe.net/home/henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > -------------------------------------------------------------- > ---------------- >=20 > That problem that we weren't having yesterday, is it better?=20 > (Big ISP NOC) >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Wed Nov 19 07:57:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14944 for ; Wed, 19 Nov 2003 07:57:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRtS-0007Gn-HC for ippm-archive@odin.ietf.org; Wed, 19 Nov 2003 07:57:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJCvEeb027944 for ippm-archive@odin.ietf.org; Wed, 19 Nov 2003 07:57:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRtS-0007Gd-Bx for ippm-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 07:57:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14920 for ; Wed, 19 Nov 2003 07:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRtR-0006TY-00 for ippm-web-archive@ietf.org; Wed, 19 Nov 2003 07:57:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMRtR-0006TU-00 for ippm-web-archive@ietf.org; Wed, 19 Nov 2003 07:57:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRtF-0007EM-D5; Wed, 19 Nov 2003 07:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRsX-00079P-DI for ippm@optimus.ietf.org; Wed, 19 Nov 2003 07:56:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14875 for ; Wed, 19 Nov 2003 07:56:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRsW-0006Ss-00 for ippm@ietf.org; Wed, 19 Nov 2003 07:56:16 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AMRsV-0006Sp-00 for ippm@ietf.org; Wed, 19 Nov 2003 07:56:16 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAJCrjdC004030 for ; Wed, 19 Nov 2003 07:53:45 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hAJCrgdC003987 for ; Wed, 19 Nov 2003 07:53:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Date: Wed, 19 Nov 2003 14:56:10 +0200 Message-ID: Thread-Topic: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt Thread-Index: AcOumQAqUjpxfCXNSC6qZUst6hKZUQAAwrnQ From: "Romascanu, Dan (Dan)" To: "Henk Uijterwaal (RIPE-NCC)" Cc: "STEPHAN Emile FTRD/DAC/LAN" , "Andy Bierman" , "Matthew J Zekauskas" , Content-Transfer-Encoding: quoted-printable Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Henk, >=20 >=20 > Dan, >=20 > > I think that the IPPM MIB document would benefit from a framework > > section explaining in more details the concepts that you=20 > and Matt are > > describing in your mails - what are the targets where the MIB is > > expected to run, how you define the relationship between=20 > the entities > > that you call proxy, Surveyor, NMS, etc. >=20 > Wait a second: Surveyor is only one of the implementations of the > One-way-delay and one-way-loss metrics, there are more=20 > implementations. >=20 This was not clear from the chain of mails, and this is why a framework = section explaining the role of the different entities, and the proposed = configurations for deployment would be useful. Specific implementations = need not be covered in the standard, but may of course be a subject for = informational documents. > Henk >=20 Dan >=20 > -------------------------------------------------------------- > ---------------- > Henk Uijterwaal Email:=20 > henk.uijterwaal@ripe.net > RIPE Network Coordination Centre WWW:=20 > http://www.ripe.net/home/henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > -------------------------------------------------------------- > ---------------- >=20 > That problem that we weren't having yesterday, is it better?=20 > (Big ISP NOC) >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Wed Nov 19 08:02:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15188 for ; Wed, 19 Nov 2003 08:02:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRy5-0007ct-Rq; Wed, 19 Nov 2003 08:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRxs-0007cV-SP for ippm@optimus.ietf.org; Wed, 19 Nov 2003 08:01:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15163 for ; Wed, 19 Nov 2003 08:01:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRxr-0006Zt-00 for ippm@ietf.org; Wed, 19 Nov 2003 08:01:47 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AMRxr-0006Zm-00 for ippm@ietf.org; Wed, 19 Nov 2003 08:01:47 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id E728F4ECAB; Wed, 19 Nov 2003 14:01:16 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 478CB4E528; Wed, 19 Nov 2003 14:01:16 +0100 (CET) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hAJD1G4L030955; Wed, 19 Nov 2003 14:01:16 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id hAJD1Gra030240; Wed, 19 Nov 2003 14:01:16 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 19 Nov 2003 14:01:16 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Matthew J Zekauskas Cc: ippm@ietf.org Subject: Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt In-Reply-To: <33018387.1068722589@localhost> Message-ID: References: <4.3.2.7.2.20031113075842.02615600@fedex.cisco.com> <33018387.1068722589@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.459399 X-RIPE-Signature: d0fd2576bf60e89d157801f14c2a9286 Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , On Thu, 13 Nov 2003, Matthew J Zekauskas wrote: > As chair, I'd like to say that Andy's comment below is what > I've heard informally, but no one has to-date posted to the > list. I'd like to ask others to read the draft, and comment > on the complexity (or any other area) -- do you agree, or > do you think that the current draft is on the right track. > > With my chair hat off, I concur with Andy's assessment below. > What I always intended to implement with Surveyor was a simple > scheme to export the basic data types; if there was any complex > manipulation, it would be done by the software playing the role > as a network management system. Also with my chair hat off. The way I currently see this (and the way that we've implemented this) is something like: +------+ /-------- | User |----------------\ Control +------+ Control | | V V +--------+ +----------+ | Sender | | Receiver | +--------+ +----------+ | | ^ | | | | | | \--------Measurement ---------/ | | | V V +--------------------------------------------+ | Results | +--------------------------------------------+ | V +------------+ | Processing | +------------+ | V User The user requests up a measurement session by sending a control message to both sender and receiver. Sender and receiver set up the measurement using a home-grown mechanism now, perhaps OWAMP-control in the future. The measurement is done, currently with our own protocol, perhaps OWAMP-test in the future. Both sender and receiver record data regarding the measurement in a file. After the measurement is over, these files are pulled to a central point at regular intervals. Here data is processed: combine what sender and receiver know about a measurement, aggregate, filter, plot and print on web pages or so, depending on what the user wants. The last steps are often done more than once, people tend to aggregate over short intervals as well as long intervals, make 2 or more plots of the same data etc. When talking to users, the biggest issue is that the data is not available until the file has been written. A buffer with the data from the last X minutes would solve that. An application can then query the buffer and do whatever it wants to do with the data. This is where I see a standard format (MIB) and protocol (SNMP) come in. What people are not interested in, is a standard way to aggregate and filter data. Requirements vary a lot here: time interval, loops over the data, format (numbers vs a plot), etc, and the one size-fits all approach doesn't seem right. Henk > > --Matt > > --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman wrote: > > > Although a good job has been done documenting this MIB, > > IMO it is too complex to be deployable. The resource > > requirements in the agent are very large. Some of the > > tables can get extremely large, which would lead to > > poor SNMP performance. The resource limitation mechanisms > > do not align well with actual SNMP agent implementation > > constraints. > > > > This MIB is way too complicated and contains too many > > features that should be provided by an EMS or NMS. There > > are likely to be many implementation difficulties due to > > undocumented (and unforeseen) interactions between features. > > The MIB should be simplified to collect metric values > > and provide aggregation reports which can be retrieved > > via SNMP. Analysis of the reports, threshold based > > exception handling, sending email and pages to administrators, > > etc. should be left to the application. > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Wed Nov 19 08:02:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15203 for ; Wed, 19 Nov 2003 08:02:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRyB-0007jc-Nz for ippm-archive@odin.ietf.org; Wed, 19 Nov 2003 08:02:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJD272n029726 for ippm-archive@odin.ietf.org; Wed, 19 Nov 2003 08:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRyB-0007jN-IY for ippm-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 08:02:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15172 for ; Wed, 19 Nov 2003 08:01:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRyA-0006a7-00 for ippm-web-archive@ietf.org; Wed, 19 Nov 2003 08:02:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMRyA-0006a4-00 for ippm-web-archive@ietf.org; Wed, 19 Nov 2003 08:02:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRy5-0007ct-Rq; Wed, 19 Nov 2003 08:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRxs-0007cV-SP for ippm@optimus.ietf.org; Wed, 19 Nov 2003 08:01:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15163 for ; Wed, 19 Nov 2003 08:01:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRxr-0006Zt-00 for ippm@ietf.org; Wed, 19 Nov 2003 08:01:47 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AMRxr-0006Zm-00 for ippm@ietf.org; Wed, 19 Nov 2003 08:01:47 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id E728F4ECAB; Wed, 19 Nov 2003 14:01:16 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 478CB4E528; Wed, 19 Nov 2003 14:01:16 +0100 (CET) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hAJD1G4L030955; Wed, 19 Nov 2003 14:01:16 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id hAJD1Gra030240; Wed, 19 Nov 2003 14:01:16 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 19 Nov 2003 14:01:16 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Matthew J Zekauskas Cc: ippm@ietf.org Subject: Re: [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt In-Reply-To: <33018387.1068722589@localhost> Message-ID: References: <4.3.2.7.2.20031113075842.02615600@fedex.cisco.com> <33018387.1068722589@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.459399 X-RIPE-Signature: d0fd2576bf60e89d157801f14c2a9286 Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , On Thu, 13 Nov 2003, Matthew J Zekauskas wrote: > As chair, I'd like to say that Andy's comment below is what > I've heard informally, but no one has to-date posted to the > list. I'd like to ask others to read the draft, and comment > on the complexity (or any other area) -- do you agree, or > do you think that the current draft is on the right track. > > With my chair hat off, I concur with Andy's assessment below. > What I always intended to implement with Surveyor was a simple > scheme to export the basic data types; if there was any complex > manipulation, it would be done by the software playing the role > as a network management system. Also with my chair hat off. The way I currently see this (and the way that we've implemented this) is something like: +------+ /-------- | User |----------------\ Control +------+ Control | | V V +--------+ +----------+ | Sender | | Receiver | +--------+ +----------+ | | ^ | | | | | | \--------Measurement ---------/ | | | V V +--------------------------------------------+ | Results | +--------------------------------------------+ | V +------------+ | Processing | +------------+ | V User The user requests up a measurement session by sending a control message to both sender and receiver. Sender and receiver set up the measurement using a home-grown mechanism now, perhaps OWAMP-control in the future. The measurement is done, currently with our own protocol, perhaps OWAMP-test in the future. Both sender and receiver record data regarding the measurement in a file. After the measurement is over, these files are pulled to a central point at regular intervals. Here data is processed: combine what sender and receiver know about a measurement, aggregate, filter, plot and print on web pages or so, depending on what the user wants. The last steps are often done more than once, people tend to aggregate over short intervals as well as long intervals, make 2 or more plots of the same data etc. When talking to users, the biggest issue is that the data is not available until the file has been written. A buffer with the data from the last X minutes would solve that. An application can then query the buffer and do whatever it wants to do with the data. This is where I see a standard format (MIB) and protocol (SNMP) come in. What people are not interested in, is a standard way to aggregate and filter data. Requirements vary a lot here: time interval, loops over the data, format (numbers vs a plot), etc, and the one size-fits all approach doesn't seem right. Henk > > --Matt > > --On Thursday, November 13, 2003 8:02 AM -0800 Andy Bierman wrote: > > > Although a good job has been done documenting this MIB, > > IMO it is too complex to be deployable. The resource > > requirements in the agent are very large. Some of the > > tables can get extremely large, which would lead to > > poor SNMP performance. The resource limitation mechanisms > > do not align well with actual SNMP agent implementation > > constraints. > > > > This MIB is way too complicated and contains too many > > features that should be provided by an EMS or NMS. There > > are likely to be many implementation difficulties due to > > undocumented (and unforeseen) interactions between features. > > The MIB should be simplified to collect metric values > > and provide aggregation reports which can be retrieved > > via SNMP. Analysis of the reports, threshold based > > exception handling, sending email and pages to administrators, > > etc. should be left to the application. > > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www1.ietf.org/mailman/listinfo/ippm > ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Wed Nov 19 19:53:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27100 for ; Wed, 19 Nov 2003 19:53:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMd48-0001jB-PX; Wed, 19 Nov 2003 19:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRUk-0005mv-Tl for ippm@optimus.ietf.org; Wed, 19 Nov 2003 07:31:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14404 for ; Wed, 19 Nov 2003 07:31:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRUk-0006D1-00 for ippm@ietf.org; Wed, 19 Nov 2003 07:31:42 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AMRUj-0006AV-00 for ippm@ietf.org; Wed, 19 Nov 2003 07:31:41 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 161504FCA6; Wed, 19 Nov 2003 13:31:08 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 97F574EDC2; Wed, 19 Nov 2003 13:31:07 +0100 (CET) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hAJCV74L023663; Wed, 19 Nov 2003 13:31:07 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id hAJCV6ZQ028896; Wed, 19 Nov 2003 13:31:07 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 19 Nov 2003 13:31:06 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: "Romascanu, Dan (Dan)" Cc: STEPHAN Emile FTRD/DAC/LAN , Andy Bierman , Matthew J Zekauskas , ippm@ietf.org Subject: RE: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.122230 X-RIPE-Signature: e2cdcffcb609ce84f237f5ab35554393 Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Dan, > I think that the IPPM MIB document would benefit from a framework > section explaining in more details the concepts that you and Matt are > describing in your mails - what are the targets where the MIB is > expected to run, how you define the relationship between the entities > that you call proxy, Surveyor, NMS, etc. Wait a second: Surveyor is only one of the implementations of the One-way-delay and one-way-loss metrics, there are more implementations. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Wed Nov 19 19:53:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27118 for ; Wed, 19 Nov 2003 19:53:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMd4O-0001lu-6o for ippm-archive@odin.ietf.org; Wed, 19 Nov 2003 19:53:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK0rGh2006804 for ippm-archive@odin.ietf.org; Wed, 19 Nov 2003 19:53:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMd4N-0001lf-JF for ippm-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 19:53:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27093 for ; Wed, 19 Nov 2003 19:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMd4L-0000CS-00 for ippm-web-archive@ietf.org; Wed, 19 Nov 2003 19:53:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMd4L-0000CP-00 for ippm-web-archive@ietf.org; Wed, 19 Nov 2003 19:53:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMd48-0001jB-PX; Wed, 19 Nov 2003 19:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMRUk-0005mv-Tl for ippm@optimus.ietf.org; Wed, 19 Nov 2003 07:31:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14404 for ; Wed, 19 Nov 2003 07:31:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMRUk-0006D1-00 for ippm@ietf.org; Wed, 19 Nov 2003 07:31:42 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AMRUj-0006AV-00 for ippm@ietf.org; Wed, 19 Nov 2003 07:31:41 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 161504FCA6; Wed, 19 Nov 2003 13:31:08 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 97F574EDC2; Wed, 19 Nov 2003 13:31:07 +0100 (CET) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id hAJCV74L023663; Wed, 19 Nov 2003 13:31:07 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id hAJCV6ZQ028896; Wed, 19 Nov 2003 13:31:07 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Wed, 19 Nov 2003 13:31:06 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: "Romascanu, Dan (Dan)" Cc: STEPHAN Emile FTRD/DAC/LAN , Andy Bierman , Matthew J Zekauskas , ippm@ietf.org Subject: RE: RE : [ippm] comments on draft-ietf-ippm-reporting-mib-04.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.122230 X-RIPE-Signature: e2cdcffcb609ce84f237f5ab35554393 Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Dan, > I think that the IPPM MIB document would benefit from a framework > section explaining in more details the concepts that you and Matt are > describing in your mails - what are the targets where the MIB is > expected to run, how you define the relationship between the entities > that you call proxy, Surveyor, NMS, etc. Wait a second: Surveyor is only one of the implementations of the One-way-delay and one-way-loss metrics, there are more implementations. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm