From mailman-admin@ietf.org Sun Feb 1 09:21:41 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14864 for ; Sun, 1 Feb 2004 09:21:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnITJ-0006Ad-MY for ippm-archive@lists.ietf.org; Sun, 01 Feb 2004 09:21:13 -0500 Date: Sun, 01 Feb 2004 09:21:13 -0500 Message-ID: <20040201142113.1364.57281.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ippm-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ippm-request@ietf.org ) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ippm-archive@lists.ietf.org: List Password // URL ---- -------- ippm@ietf.org wurudu https://www1.ietf.org/mailman/options/ippm/ippm-archive%40lists.ietf.org From exim@www1.ietf.org Sun Feb 1 10:20:36 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27933 for ; Sun, 1 Feb 2004 10:20: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 1AnJOK-0004UK-Rz for ippm-archive@odin.ietf.org; Sun, 01 Feb 2004 10:20:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i11FK8X1017246 for ippm-archive@odin.ietf.org; Sun, 1 Feb 2004 10:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnJOJ-0004U5-IT for ippm-web-archive@optimus.ietf.org; Sun, 01 Feb 2004 10:20: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 KAA27774 for ; Sun, 1 Feb 2004 10:20:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnJOD-0006ev-00 for ippm-web-archive@ietf.org; Sun, 01 Feb 2004 10:20:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnJ3S-0001BH-00 for ippm-web-archive@ietf.org; Sun, 01 Feb 2004 09:58:37 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnIe9-0002Yb-09 for ippm-web-archive@ietf.org; Sun, 01 Feb 2004 09:32:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnITA-00061i-Ur for ippm-web-archive@ietf.org; Sun, 01 Feb 2004 09:21:04 -0500 Date: Sun, 01 Feb 2004 09:21:04 -0500 Message-ID: <20040201142104.1364.64487.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ippm-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ippm-request@ietf.org ) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ippm-web-archive@ietf.org: List Password // URL ---- -------- ippm@ietf.org ikrodi https://www1.ietf.org/mailman/options/ippm/ippm-web-archive%40ietf.org From ippm-admin@ietf.org Mon Feb 2 16:07:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09927 for ; Mon, 2 Feb 2004 16:07: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 1AnlHa-0007Km-9U; Mon, 02 Feb 2004 16:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlGh-0007Im-GI for ippm@optimus.ietf.org; Mon, 02 Feb 2004 16:06:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09608; Mon, 2 Feb 2004 16:06:04 -0500 (EST) Message-Id: <200402022106.QAA09608@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: Mon, 02 Feb 2004 16:06:04 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-metrics-registry-05.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 : IPPM metrics registry Author(s) : E. Stephan Filename : draft-ietf-ippm-metrics-registry-05.txt Pages : 16 Date : 2004-2-2 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrics-registry-05.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-metrics-registry-05.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-metrics-registry-05.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: <2004-2-2150931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-metrics-registry-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-metrics-registry-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150931.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Feb 2 16:09:25 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10260 for ; Mon, 2 Feb 2004 16:09: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 1AnlJR-00086d-Ij for ippm-archive@odin.ietf.org; Mon, 02 Feb 2004 16:08:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12L8vts031153 for ippm-archive@odin.ietf.org; Mon, 2 Feb 2004 16:08:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlJR-00086O-E1 for ippm-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 16:08: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 QAA10179 for ; Mon, 2 Feb 2004 16:08:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnlJP-0001KD-00 for ippm-web-archive@ietf.org; Mon, 02 Feb 2004 16:08:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnlIT-0001E0-00 for ippm-web-archive@ietf.org; Mon, 02 Feb 2004 16:07:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnlHm-00018F-00 for ippm-web-archive@ietf.org; Mon, 02 Feb 2004 16:07:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlHa-0007Km-9U; Mon, 02 Feb 2004 16:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlGh-0007Im-GI for ippm@optimus.ietf.org; Mon, 02 Feb 2004 16:06:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09608; Mon, 2 Feb 2004 16:06:04 -0500 (EST) Message-Id: <200402022106.QAA09608@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: Mon, 02 Feb 2004 16:06:04 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-metrics-registry-05.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : IPPM metrics registry Author(s) : E. Stephan Filename : draft-ietf-ippm-metrics-registry-05.txt Pages : 16 Date : 2004-2-2 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrics-registry-05.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-metrics-registry-05.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-metrics-registry-05.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: <2004-2-2150931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-metrics-registry-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-metrics-registry-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150931.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Feb 2 19:57:42 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27920 for ; Mon, 2 Feb 2004 19:57: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 1Anos8-0001kq-Ma; Mon, 02 Feb 2004 19:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDzy-0006a6-T7 for ippm@optimus.ietf.org; Thu, 29 Jan 2004 10:22:30 -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 KAA23834 for ; Thu, 29 Jan 2004 10:22:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmDzw-0002EZ-00 for ippm@ietf.org; Thu, 29 Jan 2004 10:22:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmDz4-00027k-00 for ippm@ietf.org; Thu, 29 Jan 2004 10:21:34 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AmDyO-00020n-00 for ippm@ietf.org; Thu, 29 Jan 2004 10:20:52 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 16:20:43 +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 Date: Thu, 29 Jan 2004 16:20:42 +0100 Message-ID: Thread-Topic: IPPM Registry Status Thread-Index: AcPhvZtPbHZ7PeQUSIaphbvU85a3wgEu+aEg From: "STEPHAN Emile FTRD/DAC/LAN" To: "Matthew J Zekauskas" Cc: X-OriginalArrivalTime: 29 Jan 2004 15:20:43.0679 (UTC) FILETIME=[764F72F0:01C3E67B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ippm] RE : IPPM Registry Status 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, I posted the update of the registry a week ago. Unfortunately it is not = yet online. I would be glad if you may check with the IETF secretary what is = happening. Best regards Emile > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@internet2.edu]=20 > Envoy=E9 : vendredi 23 janvier 2004 15:31 > =C0 : ippm@ietf.org > Cc : STEPHAN Emile FTRD/DAC/LAN; Matt Zekauskas; Henk=20 > Uijterwaal (RIPE-NCC); Andy Bierman > Objet : Re: IPPM Registry Status >=20 >=20 > Emile, >=20 > Thanks for the update. I figured out a couple weeks ago > that your draft was one of the ones that the internet-drafts=20 > administration system had lost just before the last meeting--=20 > the old version got reposted when you noticed, but the new=20 > one never did. >=20 > As soon as this posts, I'll forward to the AD's. >=20 > --Matt >=20 > --On Friday, January 23, 2004 10:54 AM +0100 "STEPHAN Emile=20 > FTRD/DAC/LAN"=20 > wrote: >=20 > > > > Dear all, > > > > The minutes of the last meeting says "Emile wanted to know=20 > the status=20 > > of the registry -- it will be presented to the ADs as soon as the=20 > > (apparently now expired) version is refreshed by the I-D=20 > editor after=20 > > the meeting. RMON would like the OIDs for the metrics. Bob=20 > Cole asked=20 > > what happens for new metrics? Matt said OIDs should be included in=20 > > those drafts." > > > > So I posted the version 5 of the registry today. I have=20 > only updated=20 > > the date of the draft. > > > > Regards > > Emile >=20 >=20 >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Feb 2 19:59:35 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28034 for ; Mon, 2 Feb 2004 19:59: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 1AnouA-0001wI-9h for ippm-archive@odin.ietf.org; Mon, 02 Feb 2004 19:59:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i130x61K007454 for ippm-archive@odin.ietf.org; Mon, 2 Feb 2004 19:59:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnouA-0001w9-3w for ippm-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 19:59: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 TAA28016 for ; Mon, 2 Feb 2004 19:59:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anou8-00017d-00 for ippm-web-archive@ietf.org; Mon, 02 Feb 2004 19:59:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnotA-00010h-00 for ippm-web-archive@ietf.org; Mon, 02 Feb 2004 19:58:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnosL-0000tm-00 for ippm-web-archive@ietf.org; Mon, 02 Feb 2004 19: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 1Anos8-0001kq-Ma; Mon, 02 Feb 2004 19:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AmDzy-0006a6-T7 for ippm@optimus.ietf.org; Thu, 29 Jan 2004 10:22:30 -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 KAA23834 for ; Thu, 29 Jan 2004 10:22:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AmDzw-0002EZ-00 for ippm@ietf.org; Thu, 29 Jan 2004 10:22:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AmDz4-00027k-00 for ippm@ietf.org; Thu, 29 Jan 2004 10:21:34 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AmDyO-00020n-00 for ippm@ietf.org; Thu, 29 Jan 2004 10:20:52 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 29 Jan 2004 16:20:43 +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 Date: Thu, 29 Jan 2004 16:20:42 +0100 Message-ID: Thread-Topic: IPPM Registry Status Thread-Index: AcPhvZtPbHZ7PeQUSIaphbvU85a3wgEu+aEg From: "STEPHAN Emile FTRD/DAC/LAN" To: "Matthew J Zekauskas" Cc: X-OriginalArrivalTime: 29 Jan 2004 15:20:43.0679 (UTC) FILETIME=[764F72F0:01C3E67B] Content-Transfer-Encoding: quoted-printable Subject: [ippm] RE : IPPM Registry Status 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Matt, I posted the update of the registry a week ago. Unfortunately it is not = yet online. I would be glad if you may check with the IETF secretary what is = happening. Best regards Emile > -----Message d'origine----- > De : Matthew J Zekauskas [mailto:matt@internet2.edu]=20 > Envoy=E9 : vendredi 23 janvier 2004 15:31 > =C0 : ippm@ietf.org > Cc : STEPHAN Emile FTRD/DAC/LAN; Matt Zekauskas; Henk=20 > Uijterwaal (RIPE-NCC); Andy Bierman > Objet : Re: IPPM Registry Status >=20 >=20 > Emile, >=20 > Thanks for the update. I figured out a couple weeks ago > that your draft was one of the ones that the internet-drafts=20 > administration system had lost just before the last meeting--=20 > the old version got reposted when you noticed, but the new=20 > one never did. >=20 > As soon as this posts, I'll forward to the AD's. >=20 > --Matt >=20 > --On Friday, January 23, 2004 10:54 AM +0100 "STEPHAN Emile=20 > FTRD/DAC/LAN"=20 > wrote: >=20 > > > > Dear all, > > > > The minutes of the last meeting says "Emile wanted to know=20 > the status=20 > > of the registry -- it will be presented to the ADs as soon as the=20 > > (apparently now expired) version is refreshed by the I-D=20 > editor after=20 > > the meeting. RMON would like the OIDs for the metrics. Bob=20 > Cole asked=20 > > what happens for new metrics? Matt said OIDs should be included in=20 > > those drafts." > > > > So I posted the version 5 of the registry today. I have=20 > only updated=20 > > the date of the draft. > > > > Regards > > Emile >=20 >=20 >=20 _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Feb 2 20:20:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28864 for ; Mon, 2 Feb 2004 20:20:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpES-0004jX-6t; Mon, 02 Feb 2004 20:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpDR-0004hY-Q9 for ippm@optimus.ietf.org; Mon, 02 Feb 2004 20:19:02 -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 UAA28828 for ; Mon, 2 Feb 2004 20:18:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnpDP-0003Co-00 for ippm@ietf.org; Mon, 02 Feb 2004 20:18:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnpCT-00037J-00 for ippm@ietf.org; Mon, 02 Feb 2004 20:18:01 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AnpBw-00032P-00 for ippm@ietf.org; Mon, 02 Feb 2004 20:17:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 55FDA15ED; Mon, 2 Feb 2004 20:17:28 -0500 (EST) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id EB81D15EC; Mon, 2 Feb 2004 20:17:26 -0500 (EST) Date: Mon, 02 Feb 2004 20:17:21 -0500 From: Matthew J Zekauskas To: Mark Santcroos , "STEPHAN Emile FTRD/DAC/LAN" Cc: Matthew J Zekauskas , ippm@ietf.org Subject: Re: [ippm] RE : IPPM Registry Status Message-ID: <807091886.1075753041@localhost> In-Reply-To: <20040203010153.GB683@laptop.6bone.nl> References: <20040203010153.GB683@laptop.6bone.nl> 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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Actually, the message was sent before the posting, but it got held up with a bunch of spam (because the posting address was different than the subscribing address). I acted on the message (the copy sent directly to me) and neglected to approve the original last week; I approved it just now based on the "approve everything even remotely related to IPPM" psuedo-rule, even though it was "old". For some reason Emile's messages to internet-drafts appear to be lost/held/flagged/... and they don't get delivered. We're working on it... (Also I've added the francetelecom.com address to the "ok to send even though not on the list" filter; and am working with Emile to make sure his subscription is correct.) Now that the registry has hit the I-D list, I intend to forward it to the AD's based on our too-long ago last call and feedback received. I intend to do that tomorrow, EST. If any working group member has a comment, they are welcome now through the eventual IESG last call period... --Matt --On Tuesday, February 03, 2004 2:01 AM +0100 Mark Santcroos wrote: > On Thu, Jan 29, 2004 at 04:20:42PM +0100, STEPHAN Emile FTRD/DAC/LAN wrote: >> I posted the update of the registry a week ago. Unfortunately it is not yet online. >> I would be glad if you may check with the IETF secretary what is happening. > > You mean > http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrics-registry-05.txt ? > > Mark > > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Feb 2 20:22:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28971 for ; Mon, 2 Feb 2004 20:22: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 1AnpGK-0004wV-Gz for ippm-archive@odin.ietf.org; Mon, 02 Feb 2004 20:22:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i131M0M3018993 for ippm-archive@odin.ietf.org; Mon, 2 Feb 2004 20:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpGK-0004wG-CC for ippm-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 20:22: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 UAA28905 for ; Mon, 2 Feb 2004 20:21:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnpGI-0003S7-00 for ippm-web-archive@ietf.org; Mon, 02 Feb 2004 20:21:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnpFK-0003NK-00 for ippm-web-archive@ietf.org; Mon, 02 Feb 2004 20:20:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnpEg-0003Iu-00 for ippm-web-archive@ietf.org; Mon, 02 Feb 2004 20:20:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpES-0004jX-6t; Mon, 02 Feb 2004 20:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpDR-0004hY-Q9 for ippm@optimus.ietf.org; Mon, 02 Feb 2004 20:19:02 -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 UAA28828 for ; Mon, 2 Feb 2004 20:18:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnpDP-0003Co-00 for ippm@ietf.org; Mon, 02 Feb 2004 20:18:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnpCT-00037J-00 for ippm@ietf.org; Mon, 02 Feb 2004 20:18:01 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AnpBw-00032P-00 for ippm@ietf.org; Mon, 02 Feb 2004 20:17:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 55FDA15ED; Mon, 2 Feb 2004 20:17:28 -0500 (EST) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id EB81D15EC; Mon, 2 Feb 2004 20:17:26 -0500 (EST) Date: Mon, 02 Feb 2004 20:17:21 -0500 From: Matthew J Zekauskas To: Mark Santcroos , "STEPHAN Emile FTRD/DAC/LAN" Cc: Matthew J Zekauskas , ippm@ietf.org Subject: Re: [ippm] RE : IPPM Registry Status Message-ID: <807091886.1075753041@localhost> In-Reply-To: <20040203010153.GB683@laptop.6bone.nl> References: <20040203010153.GB683@laptop.6bone.nl> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Actually, the message was sent before the posting, but it got held up with a bunch of spam (because the posting address was different than the subscribing address). I acted on the message (the copy sent directly to me) and neglected to approve the original last week; I approved it just now based on the "approve everything even remotely related to IPPM" psuedo-rule, even though it was "old". For some reason Emile's messages to internet-drafts appear to be lost/held/flagged/... and they don't get delivered. We're working on it... (Also I've added the francetelecom.com address to the "ok to send even though not on the list" filter; and am working with Emile to make sure his subscription is correct.) Now that the registry has hit the I-D list, I intend to forward it to the AD's based on our too-long ago last call and feedback received. I intend to do that tomorrow, EST. If any working group member has a comment, they are welcome now through the eventual IESG last call period... --Matt --On Tuesday, February 03, 2004 2:01 AM +0100 Mark Santcroos wrote: > On Thu, Jan 29, 2004 at 04:20:42PM +0100, STEPHAN Emile FTRD/DAC/LAN wrote: >> I posted the update of the registry a week ago. Unfortunately it is not yet online. >> I would be glad if you may check with the IETF secretary what is happening. > > You mean > http://www.ietf.org/internet-drafts/draft-ietf-ippm-metrics-registry-05.txt ? > > Mark > > _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Wed Feb 11 10:31:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05401 for ; Wed, 11 Feb 2004 10:31:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwKL-0008LR-Nm; Wed, 11 Feb 2004 10: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 1AqwJl-0008K1-CI for ippm@optimus.ietf.org; Wed, 11 Feb 2004 10:30:25 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05324 for ; Wed, 11 Feb 2004 10:30:21 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1AqwJG-0008IG-Rh; Wed, 11 Feb 2004 10:29:54 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Wed, 11 Feb 2004 10:29:54 -0500 Subject: [ippm] Document Action: 'A One-way Active Measurement Protocol Requirements' to Informational RFC 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: , The IESG has approved the following document: - 'A One-way Active Measurement Protocol Requirements ' as an Informational RFC This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. RFC Editor Note In the Security Considerations, in the discussion of open mode - OLD: In this mode, mandatory-to-use mechanisms must be specified that prevent the use of the protocol for network capacity starvation denial-of-service attacks (e.g., only sending test data back to the client that requested them to be sent with the request delivered over a TCP connection). NEW: In this mode, mandatory-to-use mechanisms must be specified that prevent the use of the protocol for network capacity starvation denial-of-service attacks (e.g., only sending test data back to the client that requested them to be sent with the request delivered over a TCP connection), and that prevent a worm from using the protocol to send test data to a very large number of hosts in a short time (e.g. ensuring that open mode requests can only be made by humans, rate-limiting the acceptance of open mode requests). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Wed Feb 11 10:33:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05453 for ; Wed, 11 Feb 2004 10:33:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwM3-0008VQ-Ng for ippm-archive@odin.ietf.org; Wed, 11 Feb 2004 10:32:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BFWlqn032690 for ippm-archive@odin.ietf.org; Wed, 11 Feb 2004 10:32:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwM3-0008VB-Gl for ippm-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 10:32:47 -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 KAA05432 for ; Wed, 11 Feb 2004 10:32:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqwM1-00006P-00 for ippm-web-archive@ietf.org; Wed, 11 Feb 2004 10:32:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqwL9-00000r-00 for ippm-web-archive@ietf.org; Wed, 11 Feb 2004 10:31:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqwKg-0007jC-00 for ippm-web-archive@ietf.org; Wed, 11 Feb 2004 10:31:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqwKL-0008LR-Nm; Wed, 11 Feb 2004 10: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 1AqwJl-0008K1-CI for ippm@optimus.ietf.org; Wed, 11 Feb 2004 10:30:25 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05324 for ; Wed, 11 Feb 2004 10:30:21 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1AqwJG-0008IG-Rh; Wed, 11 Feb 2004 10:29:54 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Wed, 11 Feb 2004 10:29:54 -0500 Subject: [ippm] Document Action: 'A One-way Active Measurement Protocol Requirements' to Informational RFC 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has approved the following document: - 'A One-way Active Measurement Protocol Requirements ' as an Informational RFC This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. RFC Editor Note In the Security Considerations, in the discussion of open mode - OLD: In this mode, mandatory-to-use mechanisms must be specified that prevent the use of the protocol for network capacity starvation denial-of-service attacks (e.g., only sending test data back to the client that requested them to be sent with the request delivered over a TCP connection). NEW: In this mode, mandatory-to-use mechanisms must be specified that prevent the use of the protocol for network capacity starvation denial-of-service attacks (e.g., only sending test data back to the client that requested them to be sent with the request delivered over a TCP connection), and that prevent a worm from using the protocol to send test data to a very large number of hosts in a short time (e.g. ensuring that open mode requests can only be made by humans, rate-limiting the acceptance of open mode requests). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Wed Feb 11 16:28:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27273 for ; Wed, 11 Feb 2004 16:28:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1tp-0008W4-Q0; Wed, 11 Feb 2004 16: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 1Ar1tl-0008VH-KU for ippm@optimus.ietf.org; Wed, 11 Feb 2004 16:27:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27126; Wed, 11 Feb 2004 16:27:54 -0500 (EST) Message-Id: <200402112127.QAA27126@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: Wed, 11 Feb 2004 16:27:54 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-reordering-05.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-05.txt Pages : 28 Date : 2004-2-10 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-05.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-05.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-05.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: <2004-2-10165626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reordering-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reordering-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10165626.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Wed Feb 11 16:31:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27584 for ; Wed, 11 Feb 2004 16:31:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1wN-0000SY-Bt for ippm-archive@odin.ietf.org; Wed, 11 Feb 2004 16:30:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLUdxl001762 for ippm-archive@odin.ietf.org; Wed, 11 Feb 2004 16:30:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1wN-0000SL-85 for ippm-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:30:39 -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 QAA27520 for ; Wed, 11 Feb 2004 16:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1wL-0002O1-00 for ippm-web-archive@ietf.org; Wed, 11 Feb 2004 16:30:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1vN-0002FF-00 for ippm-web-archive@ietf.org; Wed, 11 Feb 2004 16:29:38 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1uP-00028D-00 for ippm-web-archive@ietf.org; Wed, 11 Feb 2004 16:28:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar1uP-0006Xc-Gl for ippm-web-archive@ietf.org; Wed, 11 Feb 2004 16:28:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1tp-0008W4-Q0; Wed, 11 Feb 2004 16: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 1Ar1tl-0008VH-KU for ippm@optimus.ietf.org; Wed, 11 Feb 2004 16:27:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27126; Wed, 11 Feb 2004 16:27:54 -0500 (EST) Message-Id: <200402112127.QAA27126@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: Wed, 11 Feb 2004 16:27:54 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-reordering-05.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-05.txt Pages : 28 Date : 2004-2-10 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-05.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-05.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-05.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: <2004-2-10165626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reordering-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reordering-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-10165626.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 Feb 11 17:21:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03704 for ; Wed, 11 Feb 2004 17:21: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 1Ar2j7-0006wx-RO; Wed, 11 Feb 2004 17: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 1Ar2in-0006vY-Vr for ippm@optimus.ietf.org; Wed, 11 Feb 2004 17:20:44 -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 RAA03599 for ; Wed, 11 Feb 2004 17:20:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2il-0002sV-00 for ippm@ietf.org; Wed, 11 Feb 2004 17:20:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2hn-0002k1-00 for ippm@ietf.org; Wed, 11 Feb 2004 17:19:39 -0500 Received: from sea2-f54.sea2.hotmail.com ([207.68.165.54] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar2gq-0002Wi-00 for ippm@ietf.org; Wed, 11 Feb 2004 17:18:40 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Feb 2004 14:18:10 -0800 Received: from 62.255.64.9 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 11 Feb 2004 22:18:10 GMT X-Originating-IP: [62.255.64.9] X-Originating-Email: [seun_ewulomi@hotmail.com] X-Sender: seun_ewulomi@hotmail.com From: "gab.seun jones.ewulomi" To: Kave.Salamatian@lip6.fr, ippm@ietf.org Date: Wed, 11 Feb 2004 22:18:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Feb 2004 22:18:10.0366 (UTC) FILETIME=[EEAB55E0:01C3F0EC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ippm] approach to determine bandwidth used by application 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: , Hi Guys, Need advice as I dont know what to conclude Scenario I went to a customer site and did some packet captures using NAI sniffer. I will use the logon-app.trc as an example. I basically captured packets while a user logged on to a remote application. The aim being how much traffic is generated while logging on to determine how much bandwidth is used on logon to the application 1)i used tethereal/ethereal(same as the summary window i presume) to view the logon-app,trc file (output below and please correct me if I have misunderstood any part in my descriptions) frame frames:303 bytes:29884(Total payload+headers) tr frames:303 bytes:29884 llc frames:303 bytes:29884 ip frames:303 bytes:29884 tcp frames:303 bytes:29884 data frames:214 bytes:24366 (total payload bytes) 2)using NAI sniffer I got 31096 bytes in total when you click on the statistics tab on NAI sniffer. 3)using tcpdump 12:38:40.760392 snap ip 10.101.2.161.3459 > 11.134.32.61.ica: P [tcp sum ok] 98260575:98260602(27) ack 3072908457 win 8458 (DF) (ttl 32, id 2330, len 67) My understanding is (27) - is the payload in bytes len 67 - is total bytes payload+headers (I think this only adds the tcp and ip headers) I then used a script using a combination of awk and sed to format and grab the columns with the total byte lengths for each frame e.g (len 67) for both src and dst e.g tcpdump -r logon-app-trc.cap src -vvv tcpdump -r logon-app-trc.cap dst -vvv and then added them all together and it gave me 23218 bytes in total 23218 bytes Now judging by what I want done which is to determine the amount of bandwidth consumed on logon which of this is giving me a true picture in which I can use in my bandwidth calculation. And please correct me any where I might have mis-understood anything. As this is the ippm forum. Is there a better approach to this e.g finding out how much bandwidth is being used while users do certain tasks. Any help or advice will be greatly appreciated on the best approach. Regards, seun _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Wed Feb 11 17:23:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03873 for ; Wed, 11 Feb 2004 17:23: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 1Ar2kw-0007AF-TM for ippm-archive@odin.ietf.org; Wed, 11 Feb 2004 17:22:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMMsVT027533 for ippm-archive@odin.ietf.org; Wed, 11 Feb 2004 17:22:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2kw-0007A0-Oj for ippm-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:22: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 RAA03847 for ; Wed, 11 Feb 2004 17:22:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2ku-0003BX-00 for ippm-web-archive@ietf.org; Wed, 11 Feb 2004 17:22:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2k4-00033p-00 for ippm-web-archive@ietf.org; Wed, 11 Feb 2004 17:22:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2jD-0002vk-00 for ippm-web-archive@ietf.org; Wed, 11 Feb 2004 17:21:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2j7-0006wx-RO; Wed, 11 Feb 2004 17: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 1Ar2in-0006vY-Vr for ippm@optimus.ietf.org; Wed, 11 Feb 2004 17:20:44 -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 RAA03599 for ; Wed, 11 Feb 2004 17:20:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2il-0002sV-00 for ippm@ietf.org; Wed, 11 Feb 2004 17:20:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2hn-0002k1-00 for ippm@ietf.org; Wed, 11 Feb 2004 17:19:39 -0500 Received: from sea2-f54.sea2.hotmail.com ([207.68.165.54] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar2gq-0002Wi-00 for ippm@ietf.org; Wed, 11 Feb 2004 17:18:40 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Feb 2004 14:18:10 -0800 Received: from 62.255.64.9 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 11 Feb 2004 22:18:10 GMT X-Originating-IP: [62.255.64.9] X-Originating-Email: [seun_ewulomi@hotmail.com] X-Sender: seun_ewulomi@hotmail.com From: "gab.seun jones.ewulomi" To: Kave.Salamatian@lip6.fr, ippm@ietf.org Date: Wed, 11 Feb 2004 22:18:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Feb 2004 22:18:10.0366 (UTC) FILETIME=[EEAB55E0:01C3F0EC] Subject: [ippm] approach to determine bandwidth used by application 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Guys, Need advice as I dont know what to conclude Scenario I went to a customer site and did some packet captures using NAI sniffer. I will use the logon-app.trc as an example. I basically captured packets while a user logged on to a remote application. The aim being how much traffic is generated while logging on to determine how much bandwidth is used on logon to the application 1)i used tethereal/ethereal(same as the summary window i presume) to view the logon-app,trc file (output below and please correct me if I have misunderstood any part in my descriptions) frame frames:303 bytes:29884(Total payload+headers) tr frames:303 bytes:29884 llc frames:303 bytes:29884 ip frames:303 bytes:29884 tcp frames:303 bytes:29884 data frames:214 bytes:24366 (total payload bytes) 2)using NAI sniffer I got 31096 bytes in total when you click on the statistics tab on NAI sniffer. 3)using tcpdump 12:38:40.760392 snap ip 10.101.2.161.3459 > 11.134.32.61.ica: P [tcp sum ok] 98260575:98260602(27) ack 3072908457 win 8458 (DF) (ttl 32, id 2330, len 67) My understanding is (27) - is the payload in bytes len 67 - is total bytes payload+headers (I think this only adds the tcp and ip headers) I then used a script using a combination of awk and sed to format and grab the columns with the total byte lengths for each frame e.g (len 67) for both src and dst e.g tcpdump -r logon-app-trc.cap src -vvv tcpdump -r logon-app-trc.cap dst -vvv and then added them all together and it gave me 23218 bytes in total 23218 bytes Now judging by what I want done which is to determine the amount of bandwidth consumed on logon which of this is giving me a true picture in which I can use in my bandwidth calculation. And please correct me any where I might have mis-understood anything. As this is the ippm forum. Is there a better approach to this e.g finding out how much bandwidth is being used while users do certain tasks. Any help or advice will be greatly appreciated on the best approach. Regards, seun _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Feb 12 09:22:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25068 for ; Thu, 12 Feb 2004 09:22: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 1ArHiA-0006sY-HX; Thu, 12 Feb 2004 09:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHJB-0004XC-56 for ippm@optimus.ietf.org; Thu, 12 Feb 2004 08:55: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 IAA24037 for ; Thu, 12 Feb 2004 08:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHJ5-0006Kf-00 for ippm@ietf.org; Thu, 12 Feb 2004 08:55:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHIA-0006Fj-00 for ippm@ietf.org; Thu, 12 Feb 2004 08:54:11 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1ArHHU-00065L-00 for ippm@ietf.org; Thu, 12 Feb 2004 08:53:28 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 12 Feb 2004 05:51:00 -0800 Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1CDqthu025051 for ; Thu, 12 Feb 2004 08:52:55 -0500 (EST) Received: from localhost (rtp-vpn2-219.cisco.com [10.82.240.219]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA06131 for ; Thu, 12 Feb 2004 08:52:56 -0500 (EST) Date: Thu, 12 Feb 2004 08:52:55 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: ippm@ietf.org Message-ID: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ippm] Network Benchmarking Considerations Draft 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: , Y'all: A while back, I posted Considerations in Benchmarking Routing Protocol Network Convergence, draft-white-network-benchmark-01.txt, to BMWG. This is slated to be an individual contribution/informational RFC, since it doesn't appear to fit within BMWG's purview, nor any other WG. I've recently posted the -01 version of this draft, but it's probably stuck in a queue someplace, and it's identical to the -00 version, other than date changes, anyway. So, I'd like to get any comments on this I can. I've asked Alex (the Routing AD) to place it into last call as an individual submission/informational at this point. http://www.ietf.org/internet-drafts/draft-white-network-benchmark-00.txt Thanks! :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Feb 12 09:23:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25147 for ; Thu, 12 Feb 2004 09:23:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHkR-0007EI-IP for ippm-archive@odin.ietf.org; Thu, 12 Feb 2004 09:23:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CENN0s027786 for ippm-archive@odin.ietf.org; Thu, 12 Feb 2004 09:23:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHkR-0007E5-EW for ippm-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 09:23:23 -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 JAA25136 for ; Thu, 12 Feb 2004 09:23:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHkL-0001FG-00 for ippm-web-archive@ietf.org; Thu, 12 Feb 2004 09:23:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHjc-00019n-00 for ippm-web-archive@ietf.org; Thu, 12 Feb 2004 09:22:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArHj3-00013n-00 for ippm-web-archive@ietf.org; Thu, 12 Feb 2004 09:21:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHiA-0006sY-HX; Thu, 12 Feb 2004 09:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArHJB-0004XC-56 for ippm@optimus.ietf.org; Thu, 12 Feb 2004 08:55: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 IAA24037 for ; Thu, 12 Feb 2004 08:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArHJ5-0006Kf-00 for ippm@ietf.org; Thu, 12 Feb 2004 08:55:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArHIA-0006Fj-00 for ippm@ietf.org; Thu, 12 Feb 2004 08:54:11 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1ArHHU-00065L-00 for ippm@ietf.org; Thu, 12 Feb 2004 08:53:28 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 12 Feb 2004 05:51:00 -0800 Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1CDqthu025051 for ; Thu, 12 Feb 2004 08:52:55 -0500 (EST) Received: from localhost (rtp-vpn2-219.cisco.com [10.82.240.219]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA06131 for ; Thu, 12 Feb 2004 08:52:56 -0500 (EST) Date: Thu, 12 Feb 2004 08:52:55 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: ippm@ietf.org Message-ID: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [ippm] Network Benchmarking Considerations Draft 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Y'all: A while back, I posted Considerations in Benchmarking Routing Protocol Network Convergence, draft-white-network-benchmark-01.txt, to BMWG. This is slated to be an individual contribution/informational RFC, since it doesn't appear to fit within BMWG's purview, nor any other WG. I've recently posted the -01 version of this draft, but it's probably stuck in a queue someplace, and it's identical to the -00 version, other than date changes, anyway. So, I'd like to get any comments on this I can. I've asked Alex (the Routing AD) to place it into last call as an individual submission/informational at this point. http://www.ietf.org/internet-drafts/draft-white-network-benchmark-00.txt Thanks! :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Sun Feb 15 21:24:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09451 for ; Sun, 15 Feb 2004 21:24: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 1AsYQS-0000tB-OA; Sun, 15 Feb 2004 21:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsWzG-0002sN-Nx for ippm@optimus.ietf.org; Sun, 15 Feb 2004 19:51:50 -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 TAA05527 for ; Sun, 15 Feb 2004 19:51:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsWzE-0004VH-00 for ippm@ietf.org; Sun, 15 Feb 2004 19:51:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsWyJ-0004NF-00 for ippm@ietf.org; Sun, 15 Feb 2004 19:50:56 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AsWxM-0004Dr-00 for ippm@ietf.org; Sun, 15 Feb 2004 19:49: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, 16 Feb 2004 01:49:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F426.C35701CC" Date: Mon, 16 Feb 2004 01:49:41 +0100 Message-ID: Thread-Topic: IPPM MIB: Integration of Andy comments Thread-Index: AcP0JsA852CoP5qzSVaUPXNGKUilcA== From: "STEPHAN Emile FTRD/DAC/LAN" To: Cc: "Matthew J Zekauskas" , "Andy Bierman" , "Henk Uijterwaal (RIPE-NCC)" X-OriginalArrivalTime: 16 Feb 2004 00:49:42.0936 (UTC) FILETIME=[C3EA6980:01C3F426] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [ippm] IPPM MIB: Integration of Andy comments 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_01C3F426.C35701CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, Andy made precise comments on the IPPM MIB just before the previous = meeting. I integrated most of them in the update of the MIB I have posted today = (see below). To sum up I deleted the report group, most of the = notifications and added 2 thresholds in the ippmAggrMeasureTable. Following is an important to discuss:=20 Andy comments N=B020.=20 MIB, ippmNetMeasureTable " The IppmNetMeasureTable is mandatory, and its content is read=20 only. It means that the measurement software handles the table=20 internally. The setup of the network measure is not permitted=20 through the IPPM REPORTING MIB. As an example, OWAP provides a=20 setup protocol to setup and tear down networks measures.=20 Andy said: 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. Regards Emile #########################################################################= #### 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=20 tables can get extremely large, which would lead to=20 poor SNMP performance. The resource limitation mechanisms=20 do not align well with actual SNMP agent implementation=20 constraints. This MIB is way too complicated and contains too many=20 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,=20 etc. should be left to the application. ----------------------------------------------------------------- Andy comments N=B017. 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. =20 Keeping a timestamp and value for every metric value collected by the = probe is overkill. Emile:=20 The only solution to avoid unstable values in the history table = consists in aggregating the network measures and in filtering the = aggregated results. =09 Regarding the timestamp, it is mandatory to known when a measure was = performed. If not the measure is unusable. =09 =09 ----------------------------------------------------------------- Andy comments N=B02. sec. 3) SNMP Framework This boilerplate is out of date. Use the new template at: http://www.ops.ietf.org/mib-boilerplate.html 34. References Check the MIB template for update to SNMP references. Emile:=20 The references are not updated. I will be addressed asap as the draft = will be considered as stable by the chairs and the TA. ----------------------------------------------------------------- Andy comments N=B03. sec 4, para 4) RMON model This paragraph is incorrect. RMON can collect data from=20 several interfaces which are not required to be in the same chassis. Emile: Done, I removed it. ----------------------------------------------------------------- Andy comments N=B04. sec. 4.1.3.1) Internet addresses=20 Why are special address types needed for Src and Dest? Emile: Because of the IPPM TypeP. ----------------------------------------------------------------- Andy comments N=B05. sec. 4.1.4) GMTTimeStamp=20 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. Emile: Initial the reason was to keep a bit free to manage the accuracy = of the measure. As this is mamnaged in the ippmSyncTable I change back = to "seconds since 1900". ----------------------------------------------------------------- Andy comments N=B07. 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. Emile: RMON protocol identifiers are 'informational'. The main point is = to point to a common reference to avoid encapsulation mistakes. =20 ----------------------------------------------------------------- Andy comments N=B09. 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? Emile: in the PointOfmeasure ----------------------------------------------------------------- Andy comments N=B010. 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. Emile:=20 There is a generic problem behind each MIB. Regarding IPPM measurement, = he RFC2330 states that implementation should "document the sources of = uncertainty/error and quantify the amounts of uncertainty/error". Synchronization is the main cause of measure uncertainties/errors , So = it have to be treated in a specific way for IPPM measurement. ----------------------------------------------------------------- Andy comments N=B011. 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. = Emile: 64k is an arbitrary number. It is not recommended to keep = permanently an history of 64k events. Is there a need of a scalar to indicate the duration a event stays in = the table ?=20 I clarified the definition. ----------------------------------------------------------------- Andy comments N=B012.a MIB, point of measure table IppmPointOfMeasureEntry ::=3D SEQUENCE {=20 ippmPointOfMeasureIndex Unsigned32,=20 ippmPointOfMeasureMgmtAddrType InetAddressType,=20 ippmPointOfMeasureMgmtAddress InetAddress,=20 ippmPointOfMeasureTestAddrTypeP TypeP,=20 ippmPointOfMeasureTestAddr TypePaddress,=20 ippmPointOfMeasureMetrics IppmStandardMetrics=20 }=20 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? Emile: A MIB managing points of measure should at least known their IP = addresses for the test and for the management. ----------------------------------------------------------------- Andy comments N=B012.b MIB, point of measure table Why is the test address of the measurement point needed? Why isn't it an InetAddress? How is this used? Emile: I changed ippmPointOfMeasureTestAddr and type to InetAddress ----------------------------------------------------------------- Andy comments N=B013 and 14 . MIB, ippmMetricEntry & = ippmMetricCapabilities 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. ippmMetricCapabilities OBJECT-TYPE=20 SYNTAX INTEGER {=20 notImplemented(0),=20 implemented(1)=20 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. Emile:=20 The Table is not broken ... but there was overlapping between = pointOfMeasureTable and ippmMetricsTable: Metrics implemented in a point of measures are listed in the field = ippmPointOfMeasureMetrics (bit string) of the table = ippmPointOfMeasureTable. ippmMetricCapabilities is not at the right place: it should describe the = aggretation capabilities of the SNMP agent. So I deleted it from the = ippmMetricTable and added ippmSystemAggregatedMetrics in system group. = ippmSystemAggregatedMetrics describes the aggreated metrics compute in = the SNMP agent. ----------------------------------------------------------------- Andy comments N=B015. MIB, ippmOwnersTable IppmOwnersEntry ::=3D SEQUENCE {=20 ippmOwnersIndex Unsigned32,=20 ippmOwnersOwner IppmOwnerString,=20 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=20 table should be indexed by the ippmOwnersOwner object. Emile: I agree and removed ippmOwnersIndex ----------------------------------------------------------------- Andy comments N=B016. MIB, owner address ippmOwnersIpAddressType InetAddressType,=20 ippmOwnersIpAddress InetAddress,=20 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,=20 ippmOwnersSMS SnmpAdminString,=20 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. Emile:=20 I removed the reports functions. If VACM is not used there is an need to have administrative information = on the owner: ippmOwnersIpAddressType and ippmOwnersIpAddress are needed to send = SNMP Trap or Inform; ippmOwnersEmail is need to send fast report =20 I removed ippmOwnersSMS =20 =09 ----------------------------------------------------------------- Andy comments N=B018. MIB, ippmHistorySequence Network metrics: =20 It's the sequence number of a measurement packet. Typically, it=20 identifies the order of the packet in the stream of packets sent=20 by the source.=20 =20 Aggregated metrics:=20 It is the sequence number of the computed aggregated metric=20 result."=20 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? Emile: As there are more that one packet per = measure,ippmHistorySequence identifies each packet of the measure ----------------------------------------------------------------- Andy comments N=B019. MIB, ippmHistoryValue SYNTAX Integer32=20 Why is this an Integer32 instead of Unsigned32? Could it ever be a negative number? Emile: A metrics result can be negative ----------------------------------------------------------------- Andy comments N=B020. MIB, ippmNetMeasureTable " The IppmNetMeasureTable is mandatory, and its content is read=20 only. It means that the measurement software handles the table=20 internally. The setup of the network measure is not permitted=20 through the IPPM REPORTING MIB. As an example, OWAP provides a=20 setup protocol to setup and tear down networks measures.=20 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=20 table indicates the configuration of test traffic generators. =20 The comments in the previous paragraph apply to the MIB module=20 that is eventually used for traffic generation. The=20 Synthetic Sources for Performance Measurements MIB (SSPM-MIB)=20 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=20 may be appropriate for this MIB module. Emile: =20 ----------------------------------------------------------------- Andy comments N=B021. MIB, IppmAggrMeasureEntry ippmAggrMeasureOwner IppmOwnerString,=20 ippmAggrMeasureIndex Unsigned32,=20 ippmAggrMeasureName SnmpAdminString,=20 ippmAggrMeasureMetrics IppmStandardMetrics,=20 ippmAggrMeasureBeginTime GMTTimeStamp,=20 ippmAggrMeasureAggrPeriodUnit TimeUnit,=20 ippmAggrMeasureAggrPeriod Unsigned32,=20 ippmAggrMeasureDurationUnit TimeUnit,=20 ippmAggrMeasureDuration Unsigned32,=20 ippmAggrMeasureHistorySize Unsigned32,=20 ippmAggrMeasureStorageType StorageType,=20 ippmAggrMeasureHistoryOwner IppmOwnerString,=20 ippmAggrMeasureHistoryOwnerIndex Unsigned32,=20 ippmAggrMeasureHistoryMetric Unsigned32,=20 ippmAggrMeasureAdminState INTEGER,=20 ippmAggrMeasureFastReport OBJECT IDENTIFIER,=20 ippmAggrMeasureMap SnmpAdminString,=20 ippmAggrMeasureResultsMgmt INTEGER,=20 ippmAggrMeasureLastUpdate GMTTimeStamp,=20 ippmAggrMeasureOperState INTEGER,=20 ippmAggrMeasureNbPktsTreated Counter64,=20 ippmAggrMeasureStatus RowStatus=20 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? Emile: =20 I remove all the report group. The fast report mode is designed to send by email results of a short = and fast measure: It is not=20 ----------------------------------------------------------------- Andy comments N=B022. MIB, ippmAggrMeasureMap SYNTAX SnmpAdminString=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "This object allows for classification of the measure. It is=20 typically the name of an administrative map.=20 I have no idea what this object is for. There are no guidelines for = populating this object and therefore no interoperability possible. Emile: I deleted ippmAggrMeasureMap and ippmNetMeasureMap=20 ----------------------------------------------------------------- Andy comments 6, 8, 23-31: Report Group Emile Correction: I deleted the group. 6. sec. 4.1.6) Report definition=20 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. 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=20 4 TCs (or MIB objects). 23. MIB, ippmReportPathToResults=20 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=20 to be included in this table.=20 27. MIB, ippmReportSetupNMS DESCRIPTION=20 "The recipient of the report may be provided in the setup. By=20 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=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "Even though the notification to use is defined in the report=20 definition, the object ippmReportSetupNotification provides=20 flexibility to select another notification. "=20 DEFVAL { zeroDotZero }=20 This object is too vague and there is no chance for=20 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=20 "An administrative name of a map to which the report belongs."=20 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=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value."=20 Why is this object an Integer32 instead of Unsigned32? The description is not very useful. Emile: Object removed ----------------------------------------------------------------- 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. Emile: I removed most of them as they were related to the report group. ----------------------------------------------------------------- 33. Security considerations Very good security section! _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm ------_=_NextPart_001_01C3F426.C35701CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPPM MIB: Integration of Andy comments

Dear All,

Andy made precise comments on the IPPM = MIB just before the previous meeting.

I integrated most of them in the update = of the MIB I have posted today (see below). To sum up I deleted the = report group, most of the notifications and added 2 thresholds in the = ippmAggrMeasureTable.

Following is an important to discuss: =

    Andy comments N=B020.
            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.

    Andy said:
            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.



Regards
Emile


##########################################################= ###################

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.


----------------------------------------------------------= -------
Andy comments N=B017. 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.

Emile:
        The only solution to avoid unstable values in the history = table consists in aggregating the network measures and in filtering the = aggregated results.

       =20
        Regarding the timestamp, it is mandatory to known when a = measure was performed. If not the measure is unusable.
       =20
       =20


----------------------------------------------------------= -------
Andy comments N=B02. sec. 3) SNMP = Framework

This boilerplate is out of date.
Use the new template at: http://www.ops.ietf.org/mib-boilerplate.html


34. References

Check the MIB template for update to = SNMP references.

Emile:
        The references are not updated. I will be addressed asap = as the draft will be considered as stable by the chairs and the = TA.

----------------------------------------------------------= -------
Andy comments N=B03. 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.

Emile: Done, I removed it.

----------------------------------------------------------= -------
Andy comments N=B04. sec. 4.1.3.1) = Internet addresses

Why are special address types needed = for Src and Dest?

Emile: Because of the IPPM = TypeP.

----------------------------------------------------------= -------
Andy comments N=B05. 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.

Emile:  Initial the reason was to = keep a bit free to manage the accuracy of the measure. As this is = mamnaged in the ippmSyncTable I change back to "seconds since = 1900".

----------------------------------------------------------= -------

Andy comments N=B07. 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.


Emile: RMON protocol identifiers are = 'informational'. The main point is to point to a common reference to = avoid encapsulation mistakes. 

----------------------------------------------------------= -------


Andy comments N=B09. 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?

Emile: in the PointOfmeasure
----------------------------------------------------------= -------

Andy comments N=B010. 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.


Emile:

There is a generic problem behind each = MIB. Regarding IPPM measurement, he RFC2330 states that implementation = should "document the sources of uncertainty/error and quantify the = amounts of uncertainty/error".

Synchronization is the main cause of = measure uncertainties/errors , So it have to be treated in a specific = way for IPPM measurement.

----------------------------------------------------------= -------

Andy comments N=B011. 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. 

Emile: 64k is an arbitrary = number.  It is not recommended to keep permanently an history of = 64k events.
Is there a need of a scalar to = indicate the duration a event stays in the table ?
I clarified the definition.

----------------------------------------------------------= -------

Andy comments N=B012.a MIB, point of = measure table

  IppmPointOfMeasureEntry ::=3D = SEQUENCE {
   = ippmPointOfMeasureIndex        &n= bsp;       Unsigned32,
   = ippmPointOfMeasureMgmtAddrType       &= nbsp; InetAddressType,
   = ippmPointOfMeasureMgmtAddress       &n= bsp;  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?

Emile: A MIB managing points of measure = should at least known their IP addresses for the test and for the = management.

----------------------------------------------------------= -------

Andy comments N=B012.b MIB, point of = measure table

Why is the test address of the = measurement point needed?
Why isn't it an InetAddress?  How = is this used?

Emile: I changed = ippmPointOfMeasureTestAddr and type to InetAddress

----------------------------------------------------------= -------

Andy comments N=B013 and 14 . MIB, = ippmMetricEntry & ippmMetricCapabilities

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.

  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.

Emile:

The Table is not broken ... but there = was overlapping between pointOfMeasureTable and ippmMetricsTable:
Metrics implemented in a point of = measures are listed in the field ippmPointOfMeasureMetrics (bit string) = of the table ippmPointOfMeasureTable.

ippmMetricCapabilities is not at the = right place: it should describe the aggretation capabilities of the SNMP = agent. So I deleted it from the ippmMetricTable and added = ippmSystemAggregatedMetrics in system group. ippmSystemAggregatedMetrics = describes the aggreated metrics compute in the SNMP agent.


----------------------------------------------------------= -------

Andy comments N=B015. MIB, = ippmOwnersTable

  IppmOwnersEntry ::=3D SEQUENCE { =
   = ippmOwnersIndex         &nbs= p;    Unsigned32,
   = ippmOwnersOwner         &nbs= p;    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.

Emile: I agree and removed = ippmOwnersIndex

----------------------------------------------------------= -------
Andy comments N=B016. 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         &nbs= p;    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.

Emile:
        I removed the reports functions.
        If VACM is not used there is an need to have = administrative information on the owner:
   ippmOwnersIpAddressType = and ippmOwnersIpAddress are needed to send SNMP Trap or Inform;
   ippmOwnersEmail is need = to send fast report
  
   I removed = ippmOwnersSMS
  
       =20

----------------------------------------------------------= -------
Andy comments N=B018. 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?

Emile:  As there are more that one = packet per measure,ippmHistorySequence identifies each packet of the = measure

----------------------------------------------------------= -------
Andy comments N=B019. MIB, = ippmHistoryValue
   SYNTAX Integer32

Why is this an Integer32 instead of = Unsigned32?
Could it ever be a negative = number?

Emile:  A metrics result can be = negative

----------------------------------------------------------= -------
Andy comments N=B020. 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.

Emile: 

----------------------------------------------------------= -------
Andy comments N=B021. MIB, = IppmAggrMeasureEntry

   = ippmAggrMeasureOwner         = ;         IppmOwnerString, =
   = ippmAggrMeasureIndex         = ;         Unsigned32,
   = ippmAggrMeasureName         =           SnmpAdminString, =
   = ippmAggrMeasureMetrics        &nb= sp;       IppmStandardMetrics,
   = ippmAggrMeasureBeginTime        &= nbsp;     GMTTimeStamp,
   = ippmAggrMeasureAggrPeriodUnit       &n= bsp; TimeUnit,
   = ippmAggrMeasureAggrPeriod        =      Unsigned32,
   = ippmAggrMeasureDurationUnit       &nbs= p;   TimeUnit,
   = ippmAggrMeasureDuration        &n= bsp;      Unsigned32,
   = ippmAggrMeasureHistorySize        = ;    Unsigned32,
   = ippmAggrMeasureStorageType        = ;    StorageType,
   = ippmAggrMeasureHistoryOwner       &nbs= p;   IppmOwnerString,
   = ippmAggrMeasureHistoryOwnerIndex      = Unsigned32,
   = ippmAggrMeasureHistoryMetric       &nb= sp;  Unsigned32,
   = ippmAggrMeasureAdminState        =      INTEGER,
   = ippmAggrMeasureFastReport        =      OBJECT IDENTIFIER,
   = ippmAggrMeasureMap         &= nbsp;          = SnmpAdminString,
   = ippmAggrMeasureResultsMgmt        = ;    INTEGER,
   = ippmAggrMeasureLastUpdate        =      GMTTimeStamp,
   = ippmAggrMeasureOperState        &= nbsp;     INTEGER,
   = ippmAggrMeasureNbPktsTreated       &nb= sp;  Counter64,
   = ippmAggrMeasureStatus        &nbs= p;        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?

Emile: 
        I remove all the report group.
        The fast report mode is designed to send by email results = of a short and fast measure: It is not

----------------------------------------------------------= -------
Andy comments N=B022. 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.

Emile:  I deleted = ippmAggrMeasureMap and ippmNetMeasureMap

----------------------------------------------------------= -------
Andy comments 6, 8, 23-31: Report = Group

Emile Correction: I deleted the = group.

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.

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).


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.


Emile: Object removed

----------------------------------------------------------= -------
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.

Emile: I removed most of them as they = were related to the report group.
----------------------------------------------------------= -------
33. Security considerations

Very good security section!




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



------_=_NextPart_001_01C3F426.C35701CC-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Sun Feb 15 21:26:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09521 for ; Sun, 15 Feb 2004 21:26: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 1AsYSK-00012w-TM for ippm-archive@odin.ietf.org; Sun, 15 Feb 2004 21:25:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G2PubV004016 for ippm-archive@odin.ietf.org; Sun, 15 Feb 2004 21:25:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYSK-00012h-MV for ippm-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 21:25: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 VAA09518 for ; Sun, 15 Feb 2004 21:25:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsYSH-0003It-00 for ippm-web-archive@ietf.org; Sun, 15 Feb 2004 21:25:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsYRN-0003G0-00 for ippm-web-archive@ietf.org; Sun, 15 Feb 2004 21:25:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsYQs-0003D2-00 for ippm-web-archive@ietf.org; Sun, 15 Feb 2004 21:24:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsYQS-0000tB-OA; Sun, 15 Feb 2004 21:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsWzG-0002sN-Nx for ippm@optimus.ietf.org; Sun, 15 Feb 2004 19:51:50 -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 TAA05527 for ; Sun, 15 Feb 2004 19:51:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsWzE-0004VH-00 for ippm@ietf.org; Sun, 15 Feb 2004 19:51:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsWyJ-0004NF-00 for ippm@ietf.org; Sun, 15 Feb 2004 19:50:56 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AsWxM-0004Dr-00 for ippm@ietf.org; Sun, 15 Feb 2004 19:49: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, 16 Feb 2004 01:49:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F426.C35701CC" Date: Mon, 16 Feb 2004 01:49:41 +0100 Message-ID: Thread-Topic: IPPM MIB: Integration of Andy comments Thread-Index: AcP0JsA852CoP5qzSVaUPXNGKUilcA== From: "STEPHAN Emile FTRD/DAC/LAN" To: Cc: "Matthew J Zekauskas" , "Andy Bierman" , "Henk Uijterwaal (RIPE-NCC)" X-OriginalArrivalTime: 16 Feb 2004 00:49:42.0936 (UTC) FILETIME=[C3EA6980:01C3F426] Subject: [ippm] IPPM MIB: Integration of Andy comments 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F426.C35701CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, Andy made precise comments on the IPPM MIB just before the previous = meeting. I integrated most of them in the update of the MIB I have posted today = (see below). To sum up I deleted the report group, most of the = notifications and added 2 thresholds in the ippmAggrMeasureTable. Following is an important to discuss:=20 Andy comments N=B020.=20 MIB, ippmNetMeasureTable " The IppmNetMeasureTable is mandatory, and its content is read=20 only. It means that the measurement software handles the table=20 internally. The setup of the network measure is not permitted=20 through the IPPM REPORTING MIB. As an example, OWAP provides a=20 setup protocol to setup and tear down networks measures.=20 Andy said: 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. Regards Emile #########################################################################= #### 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=20 tables can get extremely large, which would lead to=20 poor SNMP performance. The resource limitation mechanisms=20 do not align well with actual SNMP agent implementation=20 constraints. This MIB is way too complicated and contains too many=20 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,=20 etc. should be left to the application. ----------------------------------------------------------------- Andy comments N=B017. 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. =20 Keeping a timestamp and value for every metric value collected by the = probe is overkill. Emile:=20 The only solution to avoid unstable values in the history table = consists in aggregating the network measures and in filtering the = aggregated results. =09 Regarding the timestamp, it is mandatory to known when a measure was = performed. If not the measure is unusable. =09 =09 ----------------------------------------------------------------- Andy comments N=B02. sec. 3) SNMP Framework This boilerplate is out of date. Use the new template at: http://www.ops.ietf.org/mib-boilerplate.html 34. References Check the MIB template for update to SNMP references. Emile:=20 The references are not updated. I will be addressed asap as the draft = will be considered as stable by the chairs and the TA. ----------------------------------------------------------------- Andy comments N=B03. sec 4, para 4) RMON model This paragraph is incorrect. RMON can collect data from=20 several interfaces which are not required to be in the same chassis. Emile: Done, I removed it. ----------------------------------------------------------------- Andy comments N=B04. sec. 4.1.3.1) Internet addresses=20 Why are special address types needed for Src and Dest? Emile: Because of the IPPM TypeP. ----------------------------------------------------------------- Andy comments N=B05. sec. 4.1.4) GMTTimeStamp=20 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. Emile: Initial the reason was to keep a bit free to manage the accuracy = of the measure. As this is mamnaged in the ippmSyncTable I change back = to "seconds since 1900". ----------------------------------------------------------------- Andy comments N=B07. 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. Emile: RMON protocol identifiers are 'informational'. The main point is = to point to a common reference to avoid encapsulation mistakes. =20 ----------------------------------------------------------------- Andy comments N=B09. 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? Emile: in the PointOfmeasure ----------------------------------------------------------------- Andy comments N=B010. 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. Emile:=20 There is a generic problem behind each MIB. Regarding IPPM measurement, = he RFC2330 states that implementation should "document the sources of = uncertainty/error and quantify the amounts of uncertainty/error". Synchronization is the main cause of measure uncertainties/errors , So = it have to be treated in a specific way for IPPM measurement. ----------------------------------------------------------------- Andy comments N=B011. 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. = Emile: 64k is an arbitrary number. It is not recommended to keep = permanently an history of 64k events. Is there a need of a scalar to indicate the duration a event stays in = the table ?=20 I clarified the definition. ----------------------------------------------------------------- Andy comments N=B012.a MIB, point of measure table IppmPointOfMeasureEntry ::=3D SEQUENCE {=20 ippmPointOfMeasureIndex Unsigned32,=20 ippmPointOfMeasureMgmtAddrType InetAddressType,=20 ippmPointOfMeasureMgmtAddress InetAddress,=20 ippmPointOfMeasureTestAddrTypeP TypeP,=20 ippmPointOfMeasureTestAddr TypePaddress,=20 ippmPointOfMeasureMetrics IppmStandardMetrics=20 }=20 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? Emile: A MIB managing points of measure should at least known their IP = addresses for the test and for the management. ----------------------------------------------------------------- Andy comments N=B012.b MIB, point of measure table Why is the test address of the measurement point needed? Why isn't it an InetAddress? How is this used? Emile: I changed ippmPointOfMeasureTestAddr and type to InetAddress ----------------------------------------------------------------- Andy comments N=B013 and 14 . MIB, ippmMetricEntry & = ippmMetricCapabilities 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. ippmMetricCapabilities OBJECT-TYPE=20 SYNTAX INTEGER {=20 notImplemented(0),=20 implemented(1)=20 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. Emile:=20 The Table is not broken ... but there was overlapping between = pointOfMeasureTable and ippmMetricsTable: Metrics implemented in a point of measures are listed in the field = ippmPointOfMeasureMetrics (bit string) of the table = ippmPointOfMeasureTable. ippmMetricCapabilities is not at the right place: it should describe the = aggretation capabilities of the SNMP agent. So I deleted it from the = ippmMetricTable and added ippmSystemAggregatedMetrics in system group. = ippmSystemAggregatedMetrics describes the aggreated metrics compute in = the SNMP agent. ----------------------------------------------------------------- Andy comments N=B015. MIB, ippmOwnersTable IppmOwnersEntry ::=3D SEQUENCE {=20 ippmOwnersIndex Unsigned32,=20 ippmOwnersOwner IppmOwnerString,=20 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=20 table should be indexed by the ippmOwnersOwner object. Emile: I agree and removed ippmOwnersIndex ----------------------------------------------------------------- Andy comments N=B016. MIB, owner address ippmOwnersIpAddressType InetAddressType,=20 ippmOwnersIpAddress InetAddress,=20 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,=20 ippmOwnersSMS SnmpAdminString,=20 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. Emile:=20 I removed the reports functions. If VACM is not used there is an need to have administrative information = on the owner: ippmOwnersIpAddressType and ippmOwnersIpAddress are needed to send = SNMP Trap or Inform; ippmOwnersEmail is need to send fast report =20 I removed ippmOwnersSMS =20 =09 ----------------------------------------------------------------- Andy comments N=B018. MIB, ippmHistorySequence Network metrics: =20 It's the sequence number of a measurement packet. Typically, it=20 identifies the order of the packet in the stream of packets sent=20 by the source.=20 =20 Aggregated metrics:=20 It is the sequence number of the computed aggregated metric=20 result."=20 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? Emile: As there are more that one packet per = measure,ippmHistorySequence identifies each packet of the measure ----------------------------------------------------------------- Andy comments N=B019. MIB, ippmHistoryValue SYNTAX Integer32=20 Why is this an Integer32 instead of Unsigned32? Could it ever be a negative number? Emile: A metrics result can be negative ----------------------------------------------------------------- Andy comments N=B020. MIB, ippmNetMeasureTable " The IppmNetMeasureTable is mandatory, and its content is read=20 only. It means that the measurement software handles the table=20 internally. The setup of the network measure is not permitted=20 through the IPPM REPORTING MIB. As an example, OWAP provides a=20 setup protocol to setup and tear down networks measures.=20 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=20 table indicates the configuration of test traffic generators. =20 The comments in the previous paragraph apply to the MIB module=20 that is eventually used for traffic generation. The=20 Synthetic Sources for Performance Measurements MIB (SSPM-MIB)=20 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=20 may be appropriate for this MIB module. Emile: =20 ----------------------------------------------------------------- Andy comments N=B021. MIB, IppmAggrMeasureEntry ippmAggrMeasureOwner IppmOwnerString,=20 ippmAggrMeasureIndex Unsigned32,=20 ippmAggrMeasureName SnmpAdminString,=20 ippmAggrMeasureMetrics IppmStandardMetrics,=20 ippmAggrMeasureBeginTime GMTTimeStamp,=20 ippmAggrMeasureAggrPeriodUnit TimeUnit,=20 ippmAggrMeasureAggrPeriod Unsigned32,=20 ippmAggrMeasureDurationUnit TimeUnit,=20 ippmAggrMeasureDuration Unsigned32,=20 ippmAggrMeasureHistorySize Unsigned32,=20 ippmAggrMeasureStorageType StorageType,=20 ippmAggrMeasureHistoryOwner IppmOwnerString,=20 ippmAggrMeasureHistoryOwnerIndex Unsigned32,=20 ippmAggrMeasureHistoryMetric Unsigned32,=20 ippmAggrMeasureAdminState INTEGER,=20 ippmAggrMeasureFastReport OBJECT IDENTIFIER,=20 ippmAggrMeasureMap SnmpAdminString,=20 ippmAggrMeasureResultsMgmt INTEGER,=20 ippmAggrMeasureLastUpdate GMTTimeStamp,=20 ippmAggrMeasureOperState INTEGER,=20 ippmAggrMeasureNbPktsTreated Counter64,=20 ippmAggrMeasureStatus RowStatus=20 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? Emile: =20 I remove all the report group. The fast report mode is designed to send by email results of a short = and fast measure: It is not=20 ----------------------------------------------------------------- Andy comments N=B022. MIB, ippmAggrMeasureMap SYNTAX SnmpAdminString=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "This object allows for classification of the measure. It is=20 typically the name of an administrative map.=20 I have no idea what this object is for. There are no guidelines for = populating this object and therefore no interoperability possible. Emile: I deleted ippmAggrMeasureMap and ippmNetMeasureMap=20 ----------------------------------------------------------------- Andy comments 6, 8, 23-31: Report Group Emile Correction: I deleted the group. 6. sec. 4.1.6) Report definition=20 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. 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=20 4 TCs (or MIB objects). 23. MIB, ippmReportPathToResults=20 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=20 to be included in this table.=20 27. MIB, ippmReportSetupNMS DESCRIPTION=20 "The recipient of the report may be provided in the setup. By=20 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=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "Even though the notification to use is defined in the report=20 definition, the object ippmReportSetupNotification provides=20 flexibility to select another notification. "=20 DEFVAL { zeroDotZero }=20 This object is too vague and there is no chance for=20 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=20 "An administrative name of a map to which the report belongs."=20 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=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value."=20 Why is this object an Integer32 instead of Unsigned32? The description is not very useful. Emile: Object removed ----------------------------------------------------------------- 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. Emile: I removed most of them as they were related to the report group. ----------------------------------------------------------------- 33. Security considerations Very good security section! _______________________________________________ ippm mailing list ippm@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ippm ------_=_NextPart_001_01C3F426.C35701CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPPM MIB: Integration of Andy comments

Dear All,

Andy made precise comments on the IPPM = MIB just before the previous meeting.

I integrated most of them in the update = of the MIB I have posted today (see below). To sum up I deleted the = report group, most of the notifications and added 2 thresholds in the = ippmAggrMeasureTable.

Following is an important to discuss: =

    Andy comments N=B020.
            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.

    Andy said:
            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.



Regards
Emile


##########################################################= ###################

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.


----------------------------------------------------------= -------
Andy comments N=B017. 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.

Emile:
        The only solution to avoid unstable values in the history = table consists in aggregating the network measures and in filtering the = aggregated results.

       =20
        Regarding the timestamp, it is mandatory to known when a = measure was performed. If not the measure is unusable.
       =20
       =20


----------------------------------------------------------= -------
Andy comments N=B02. sec. 3) SNMP = Framework

This boilerplate is out of date.
Use the new template at: http://www.ops.ietf.org/mib-boilerplate.html


34. References

Check the MIB template for update to = SNMP references.

Emile:
        The references are not updated. I will be addressed asap = as the draft will be considered as stable by the chairs and the = TA.

----------------------------------------------------------= -------
Andy comments N=B03. 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.

Emile: Done, I removed it.

----------------------------------------------------------= -------
Andy comments N=B04. sec. 4.1.3.1) = Internet addresses

Why are special address types needed = for Src and Dest?

Emile: Because of the IPPM = TypeP.

----------------------------------------------------------= -------
Andy comments N=B05. 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.

Emile:  Initial the reason was to = keep a bit free to manage the accuracy of the measure. As this is = mamnaged in the ippmSyncTable I change back to "seconds since = 1900".

----------------------------------------------------------= -------

Andy comments N=B07. 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.


Emile: RMON protocol identifiers are = 'informational'. The main point is to point to a common reference to = avoid encapsulation mistakes. 

----------------------------------------------------------= -------


Andy comments N=B09. 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?

Emile: in the PointOfmeasure
----------------------------------------------------------= -------

Andy comments N=B010. 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.


Emile:

There is a generic problem behind each = MIB. Regarding IPPM measurement, he RFC2330 states that implementation = should "document the sources of uncertainty/error and quantify the = amounts of uncertainty/error".

Synchronization is the main cause of = measure uncertainties/errors , So it have to be treated in a specific = way for IPPM measurement.

----------------------------------------------------------= -------

Andy comments N=B011. 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. 

Emile: 64k is an arbitrary = number.  It is not recommended to keep permanently an history of = 64k events.
Is there a need of a scalar to = indicate the duration a event stays in the table ?
I clarified the definition.

----------------------------------------------------------= -------

Andy comments N=B012.a MIB, point of = measure table

  IppmPointOfMeasureEntry ::=3D = SEQUENCE {
   = ippmPointOfMeasureIndex        &n= bsp;       Unsigned32,
   = ippmPointOfMeasureMgmtAddrType       &= nbsp; InetAddressType,
   = ippmPointOfMeasureMgmtAddress       &n= bsp;  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?

Emile: A MIB managing points of measure = should at least known their IP addresses for the test and for the = management.

----------------------------------------------------------= -------

Andy comments N=B012.b MIB, point of = measure table

Why is the test address of the = measurement point needed?
Why isn't it an InetAddress?  How = is this used?

Emile: I changed = ippmPointOfMeasureTestAddr and type to InetAddress

----------------------------------------------------------= -------

Andy comments N=B013 and 14 . MIB, = ippmMetricEntry & ippmMetricCapabilities

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.

  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.

Emile:

The Table is not broken ... but there = was overlapping between pointOfMeasureTable and ippmMetricsTable:
Metrics implemented in a point of = measures are listed in the field ippmPointOfMeasureMetrics (bit string) = of the table ippmPointOfMeasureTable.

ippmMetricCapabilities is not at the = right place: it should describe the aggretation capabilities of the SNMP = agent. So I deleted it from the ippmMetricTable and added = ippmSystemAggregatedMetrics in system group. ippmSystemAggregatedMetrics = describes the aggreated metrics compute in the SNMP agent.


----------------------------------------------------------= -------

Andy comments N=B015. MIB, = ippmOwnersTable

  IppmOwnersEntry ::=3D SEQUENCE { =
   = ippmOwnersIndex         &nbs= p;    Unsigned32,
   = ippmOwnersOwner         &nbs= p;    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.

Emile: I agree and removed = ippmOwnersIndex

----------------------------------------------------------= -------
Andy comments N=B016. 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         &nbs= p;    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.

Emile:
        I removed the reports functions.
        If VACM is not used there is an need to have = administrative information on the owner:
   ippmOwnersIpAddressType = and ippmOwnersIpAddress are needed to send SNMP Trap or Inform;
   ippmOwnersEmail is need = to send fast report
  
   I removed = ippmOwnersSMS
  
       =20

----------------------------------------------------------= -------
Andy comments N=B018. 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?

Emile:  As there are more that one = packet per measure,ippmHistorySequence identifies each packet of the = measure

----------------------------------------------------------= -------
Andy comments N=B019. MIB, = ippmHistoryValue
   SYNTAX Integer32

Why is this an Integer32 instead of = Unsigned32?
Could it ever be a negative = number?

Emile:  A metrics result can be = negative

----------------------------------------------------------= -------
Andy comments N=B020. 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.

Emile: 

----------------------------------------------------------= -------
Andy comments N=B021. MIB, = IppmAggrMeasureEntry

   = ippmAggrMeasureOwner         = ;         IppmOwnerString, =
   = ippmAggrMeasureIndex         = ;         Unsigned32,
   = ippmAggrMeasureName         =           SnmpAdminString, =
   = ippmAggrMeasureMetrics        &nb= sp;       IppmStandardMetrics,
   = ippmAggrMeasureBeginTime        &= nbsp;     GMTTimeStamp,
   = ippmAggrMeasureAggrPeriodUnit       &n= bsp; TimeUnit,
   = ippmAggrMeasureAggrPeriod        =      Unsigned32,
   = ippmAggrMeasureDurationUnit       &nbs= p;   TimeUnit,
   = ippmAggrMeasureDuration        &n= bsp;      Unsigned32,
   = ippmAggrMeasureHistorySize        = ;    Unsigned32,
   = ippmAggrMeasureStorageType        = ;    StorageType,
   = ippmAggrMeasureHistoryOwner       &nbs= p;   IppmOwnerString,
   = ippmAggrMeasureHistoryOwnerIndex      = Unsigned32,
   = ippmAggrMeasureHistoryMetric       &nb= sp;  Unsigned32,
   = ippmAggrMeasureAdminState        =      INTEGER,
   = ippmAggrMeasureFastReport        =      OBJECT IDENTIFIER,
   = ippmAggrMeasureMap         &= nbsp;          = SnmpAdminString,
   = ippmAggrMeasureResultsMgmt        = ;    INTEGER,
   = ippmAggrMeasureLastUpdate        =      GMTTimeStamp,
   = ippmAggrMeasureOperState        &= nbsp;     INTEGER,
   = ippmAggrMeasureNbPktsTreated       &nb= sp;  Counter64,
   = ippmAggrMeasureStatus        &nbs= p;        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?

Emile: 
        I remove all the report group.
        The fast report mode is designed to send by email results = of a short and fast measure: It is not

----------------------------------------------------------= -------
Andy comments N=B022. 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.

Emile:  I deleted = ippmAggrMeasureMap and ippmNetMeasureMap

----------------------------------------------------------= -------
Andy comments 6, 8, 23-31: Report = Group

Emile Correction: I deleted the = group.

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.

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).


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.


Emile: Object removed

----------------------------------------------------------= -------
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.

Emile: I removed most of them as they = were related to the report group.
----------------------------------------------------------= -------
33. Security considerations

Very good security section!




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



------_=_NextPart_001_01C3F426.C35701CC-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Feb 16 00:34:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14511 for ; Mon, 16 Feb 2004 00:34: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 1AsbOL-00017N-9d; Mon, 16 Feb 2004 00:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsbI6-0000zZ-SI for ippm@optimus.ietf.org; Mon, 16 Feb 2004 00:27:34 -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 AAA14234 for ; Mon, 16 Feb 2004 00:27:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsbI4-0005g9-00 for ippm@ietf.org; Mon, 16 Feb 2004 00:27:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsbH6-0005Zk-00 for ippm@ietf.org; Mon, 16 Feb 2004 00:26:33 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AsbGR-0005Sr-00; Mon, 16 Feb 2004 00:25:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 30FBFCB5; Mon, 16 Feb 2004 00:25:52 -0500 (EST) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id F10F9C1D; Mon, 16 Feb 2004 00:25:50 -0500 (EST) Date: Mon, 16 Feb 2004 00:25:52 -0500 From: Matthew J Zekauskas To: Allison Mankin , Jon Peterson Cc: iesg-secretary@ietf.org, Matt Zekauskas , Henk Uijterwaal , ippm@ietf.org, Andy Bierman Message-ID: <346496886.1076891152@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 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ippm] Request to have draft-ietf-ippm-metrics-registry-05.txt published as a proposed standard RFC 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 Allison, The IPPM WG would like to submit draft-ietf-ippm-metrics-registry-05.txt for consideration as a Proposed Standard RFC. This document has been through extensive vetting, and this version reflects all the comments from the working group, including during the WG last call. In addition, other groups (in particular, RMONMIB) indicate that standard MIB objects for the metrics would be useful. Thanks, --Matt and Henk _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Feb 16 00:36:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14571 for ; Mon, 16 Feb 2004 00:36: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 1AsbQJ-0001HP-V6 for ippm-archive@odin.ietf.org; Mon, 16 Feb 2004 00:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1G5a3Qc004918 for ippm-archive@odin.ietf.org; Mon, 16 Feb 2004 00:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsbQJ-0001HF-N1 for ippm-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 00:36: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 AAA14544 for ; Mon, 16 Feb 2004 00:36:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsbQH-000691-00 for ippm-web-archive@ietf.org; Mon, 16 Feb 2004 00:36:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsbPI-00065p-00 for ippm-web-archive@ietf.org; Mon, 16 Feb 2004 00:35:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsbOT-000634-00 for ippm-web-archive@ietf.org; Mon, 16 Feb 2004 00:34:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsbOL-00017N-9d; Mon, 16 Feb 2004 00:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsbI6-0000zZ-SI for ippm@optimus.ietf.org; Mon, 16 Feb 2004 00:27:34 -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 AAA14234 for ; Mon, 16 Feb 2004 00:27:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsbI4-0005g9-00 for ippm@ietf.org; Mon, 16 Feb 2004 00:27:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsbH6-0005Zk-00 for ippm@ietf.org; Mon, 16 Feb 2004 00:26:33 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1AsbGR-0005Sr-00; Mon, 16 Feb 2004 00:25:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 30FBFCB5; Mon, 16 Feb 2004 00:25:52 -0500 (EST) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id F10F9C1D; Mon, 16 Feb 2004 00:25:50 -0500 (EST) Date: Mon, 16 Feb 2004 00:25:52 -0500 From: Matthew J Zekauskas To: Allison Mankin , Jon Peterson Cc: iesg-secretary@ietf.org, Matt Zekauskas , Henk Uijterwaal , ippm@ietf.org, Andy Bierman Message-ID: <346496886.1076891152@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] Request to have draft-ietf-ippm-metrics-registry-05.txt published as a proposed standard RFC 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Allison, The IPPM WG would like to submit draft-ietf-ippm-metrics-registry-05.txt for consideration as a Proposed Standard RFC. This document has been through extensive vetting, and this version reflects all the comments from the working group, including during the WG last call. In addition, other groups (in particular, RMONMIB) indicate that standard MIB objects for the metrics would be useful. Thanks, --Matt and Henk _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Mon Feb 16 15:40:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19876 for ; Mon, 16 Feb 2004 15:39: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 1AspWA-0001ne-Vh; Mon, 16 Feb 2004 15:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspVy-0001kp-Ib for ippm@optimus.ietf.org; Mon, 16 Feb 2004 15:38:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19629; Mon, 16 Feb 2004 15:38:48 -0500 (EST) Message-Id: <200402162038.PAA19629@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: Mon, 16 Feb 2004 15:38:47 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-reporting-mib-05.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 : IPPM reporting MIB Author(s) : E. Stephan, J. Jewitt Filename : draft-ietf-ippm-reporting-mib-05.txt Pages : 65 Date : 2004-2-16 This memo defines a portion of the Management Information Base (MIB) designed for use with network management protocols in TCP/IP-based internets. In particular, this MIB specifies the objects used for managing the results of the IPPM metrics measures, for pushing alarms, and for reporting the measures results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-mib-05.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-reporting-mib-05.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-reporting-mib-05.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: <2004-2-16122804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reporting-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reporting-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16122804.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Mon Feb 16 15:41:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20294 for ; Mon, 16 Feb 2004 15:41: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 1AspYV-0002hA-Oa for ippm-archive@odin.ietf.org; Mon, 16 Feb 2004 15:41:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKfRnJ010354 for ippm-archive@odin.ietf.org; Mon, 16 Feb 2004 15:41:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspYV-0002gv-K9 for ippm-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:41:27 -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 PAA20196 for ; Mon, 16 Feb 2004 15:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspYU-0002Tn-00 for ippm-web-archive@ietf.org; Mon, 16 Feb 2004 15:41:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspXX-0002NM-00 for ippm-web-archive@ietf.org; Mon, 16 Feb 2004 15:40:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AspWc-0002I8-00 for ippm-web-archive@ietf.org; Mon, 16 Feb 2004 15:39:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspWA-0001ne-Vh; Mon, 16 Feb 2004 15:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspVy-0001kp-Ib for ippm@optimus.ietf.org; Mon, 16 Feb 2004 15:38:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19629; Mon, 16 Feb 2004 15:38:48 -0500 (EST) Message-Id: <200402162038.PAA19629@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: Mon, 16 Feb 2004 15:38:47 -0500 Subject: [ippm] I-D ACTION:draft-ietf-ippm-reporting-mib-05.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : IPPM reporting MIB Author(s) : E. Stephan, J. Jewitt Filename : draft-ietf-ippm-reporting-mib-05.txt Pages : 65 Date : 2004-2-16 This memo defines a portion of the Management Information Base (MIB) designed for use with network management protocols in TCP/IP-based internets. In particular, this MIB specifies the objects used for managing the results of the IPPM metrics measures, for pushing alarms, and for reporting the measures results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reporting-mib-05.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-reporting-mib-05.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-reporting-mib-05.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: <2004-2-16122804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-reporting-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-reporting-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16122804.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Tue Feb 17 03:28:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16390 for ; Tue, 17 Feb 2004 03:28: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 1At0aH-0004RW-Uh; Tue, 17 Feb 2004 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 1At0aB-0004NI-Gy for ippm@optimus.ietf.org; Tue, 17 Feb 2004 03:27:55 -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 DAA16384 for ; Tue, 17 Feb 2004 03:27:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0a9-0001HR-00 for ippm@ietf.org; Tue, 17 Feb 2004 03:27:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0ZE-0001Ec-00 for ippm@ietf.org; Tue, 17 Feb 2004 03:26:56 -0500 Received: from cosmos.kaist.ac.kr ([192.249.24.2]) by ietf-mx with esmtp (Exim 4.12) id 1At0Ya-0001Bm-00 for ippm@ietf.org; Tue, 17 Feb 2004 03:26:16 -0500 Received: from cosmos.kaist.ac.kr (localhost.kaist.ac.kr [127.0.0.1]) by cosmos.kaist.ac.kr (8.12.2/8.9.3) with ESMTP id i1H8BeSD002833; Tue, 17 Feb 2004 17:11:40 +0900 (KST) Received: (from hkpark@localhost) by cosmos.kaist.ac.kr (8.12.2/8.12.2/Submit) id i1H8Be8v002832; Tue, 17 Feb 2004 17:11:40 +0900 (KST) (envelope-from hkpark) Message-ID: <20040217171140.A2599@cosmos.kaist.ac.kr> Date: Tue, 17 Feb 2004 17:11:40 +0900 From: Heonkyu Park To: ippm@ietf.org Cc: Heonkyu Park Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ippm] unscribe this mailist 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: , unscribe this maillist, thank you. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Tue Feb 17 03:30:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16458 for ; Tue, 17 Feb 2004 03:30: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 1At0c9-0004aJ-Lx for ippm-archive@odin.ietf.org; Tue, 17 Feb 2004 03:29:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H8Tv0o017617 for ippm-archive@odin.ietf.org; Tue, 17 Feb 2004 03:29:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0c7-0004a0-P8 for ippm-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 03:29:55 -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 DAA16445 for ; Tue, 17 Feb 2004 03:29:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0c5-0001OC-00 for ippm-web-archive@ietf.org; Tue, 17 Feb 2004 03:29:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0b9-0001LH-00 for ippm-web-archive@ietf.org; Tue, 17 Feb 2004 03:28:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At0aa-0001IN-00 for ippm-web-archive@ietf.org; Tue, 17 Feb 2004 03:28:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At0aH-0004RW-Uh; Tue, 17 Feb 2004 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 1At0aB-0004NI-Gy for ippm@optimus.ietf.org; Tue, 17 Feb 2004 03:27:55 -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 DAA16384 for ; Tue, 17 Feb 2004 03:27:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At0a9-0001HR-00 for ippm@ietf.org; Tue, 17 Feb 2004 03:27:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At0ZE-0001Ec-00 for ippm@ietf.org; Tue, 17 Feb 2004 03:26:56 -0500 Received: from cosmos.kaist.ac.kr ([192.249.24.2]) by ietf-mx with esmtp (Exim 4.12) id 1At0Ya-0001Bm-00 for ippm@ietf.org; Tue, 17 Feb 2004 03:26:16 -0500 Received: from cosmos.kaist.ac.kr (localhost.kaist.ac.kr [127.0.0.1]) by cosmos.kaist.ac.kr (8.12.2/8.9.3) with ESMTP id i1H8BeSD002833; Tue, 17 Feb 2004 17:11:40 +0900 (KST) Received: (from hkpark@localhost) by cosmos.kaist.ac.kr (8.12.2/8.12.2/Submit) id i1H8Be8v002832; Tue, 17 Feb 2004 17:11:40 +0900 (KST) (envelope-from hkpark) Message-ID: <20040217171140.A2599@cosmos.kaist.ac.kr> Date: Tue, 17 Feb 2004 17:11:40 +0900 From: Heonkyu Park To: ippm@ietf.org Cc: Heonkyu Park Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Subject: [ippm] unscribe this mailist 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 unscribe this maillist, thank you. _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Tue Feb 17 10:54:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08807 for ; Tue, 17 Feb 2004 10:54: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 1At7Xs-0004ba-Rd; Tue, 17 Feb 2004 10:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7X4-0004Y3-Az for ippm@optimus.ietf.org; Tue, 17 Feb 2004 10:53: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 KAA08680 for ; Tue, 17 Feb 2004 10:53:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7X1-0003lA-00 for ippm@ietf.org; Tue, 17 Feb 2004 10:53:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7W7-0003gT-00 for ippm@ietf.org; Tue, 17 Feb 2004 10:52:12 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1At7VD-0003Rq-00 for ippm@ietf.org; Tue, 17 Feb 2004 10:51:18 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2004 07:50:43 -0800 Received: from mcfeely.cisco.com (mcfeely.cisco.com [161.44.11.34]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1HFoghu027361 for ; Tue, 17 Feb 2004 10:50:43 -0500 (EST) Received: from RHOLLEYW2K1 (rtp-vpn1-190.cisco.com [10.82.224.190]) by mcfeely.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id KAA08578 for ; Tue, 17 Feb 2004 10:50:43 -0500 (EST) From: "Robert Holley" To: Subject: RE: [ippm] Network Benchmarking Considerations Draft Date: Tue, 17 Feb 2004 10:50:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 Russ, You draft is very interesting. I haven't seen much response on this list unless you've recieved some direct response. There is some work being done on building measurement methodologies that combine multiple parts. For example, the IPPM group is working on a "IP part". It sounds like you are working on an "OSPF part". And there are others working on other parts (e.g. "SS7 parts" etc.) I haven't found a group yet that is officially working on how the parts fit together. There is recent movement in the industry by the FCC to start "investigating" how IP networks fit into the national telecommuncations picture from a regulatory perspective. So, I expect that an understanding of multiple "parts" will be required to get the full picture. regards Bob > -----Original Message----- > From: ippm-admin@ietf.org [mailto:ippm-admin@ietf.org]On Behalf Of Russ > White > Sent: Thursday, February 12, 2004 8:53 AM > To: ippm@ietf.org > Subject: [ippm] Network Benchmarking Considerations Draft > > > Y'all: > > A while back, I posted Considerations in Benchmarking Routing Protocol > Network Convergence, draft-white-network-benchmark-01.txt, to > BMWG. This is > slated to be an individual contribution/informational RFC, since > it doesn't > appear to fit within BMWG's purview, nor any other WG. I've > recently posted > the -01 version of this draft, but it's probably stuck in a queue > someplace, and it's identical to the -00 version, other than date changes, > anyway. > > So, I'd like to get any comments on this I can. I've asked Alex (the > Routing AD) to place it into last call as an individual > submission/informational at this point. > > http://www.ietf.org/internet-drafts/draft-white-network-benchmark-00.txt > > Thanks! > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > > > _______________________________________________ > 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 Feb 17 11:01:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09418 for ; Tue, 17 Feb 2004 11:01:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7ev-0005Wx-92 for ippm-archive@odin.ietf.org; Tue, 17 Feb 2004 11:01:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HG1HGQ021259 for ippm-archive@odin.ietf.org; Tue, 17 Feb 2004 11:01:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7eu-0005Wo-TT for ippm-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 11:01: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 LAA09305 for ; Tue, 17 Feb 2004 11:01:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7es-0004mx-00 for ippm-web-archive@ietf.org; Tue, 17 Feb 2004 11:01:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7c2-0004GI-00 for ippm-web-archive@ietf.org; Tue, 17 Feb 2004 10:58:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1At7aw-00047B-00 for ippm-web-archive@ietf.org; Tue, 17 Feb 2004 10:57:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1At7Y2-0003tY-1o for ippm-web-archive@ietf.org; Tue, 17 Feb 2004 10:54:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7Xs-0004ba-Rd; Tue, 17 Feb 2004 10:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At7X4-0004Y3-Az for ippm@optimus.ietf.org; Tue, 17 Feb 2004 10:53: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 KAA08680 for ; Tue, 17 Feb 2004 10:53:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At7X1-0003lA-00 for ippm@ietf.org; Tue, 17 Feb 2004 10:53:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At7W7-0003gT-00 for ippm@ietf.org; Tue, 17 Feb 2004 10:52:12 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1At7VD-0003Rq-00 for ippm@ietf.org; Tue, 17 Feb 2004 10:51:18 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2004 07:50:43 -0800 Received: from mcfeely.cisco.com (mcfeely.cisco.com [161.44.11.34]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1HFoghu027361 for ; Tue, 17 Feb 2004 10:50:43 -0500 (EST) Received: from RHOLLEYW2K1 (rtp-vpn1-190.cisco.com [10.82.224.190]) by mcfeely.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id KAA08578 for ; Tue, 17 Feb 2004 10:50:43 -0500 (EST) From: "Robert Holley" To: Subject: RE: [ippm] Network Benchmarking Considerations Draft Date: Tue, 17 Feb 2004 10:50:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Russ, You draft is very interesting. I haven't seen much response on this list unless you've recieved some direct response. There is some work being done on building measurement methodologies that combine multiple parts. For example, the IPPM group is working on a "IP part". It sounds like you are working on an "OSPF part". And there are others working on other parts (e.g. "SS7 parts" etc.) I haven't found a group yet that is officially working on how the parts fit together. There is recent movement in the industry by the FCC to start "investigating" how IP networks fit into the national telecommuncations picture from a regulatory perspective. So, I expect that an understanding of multiple "parts" will be required to get the full picture. regards Bob > -----Original Message----- > From: ippm-admin@ietf.org [mailto:ippm-admin@ietf.org]On Behalf Of Russ > White > Sent: Thursday, February 12, 2004 8:53 AM > To: ippm@ietf.org > Subject: [ippm] Network Benchmarking Considerations Draft > > > Y'all: > > A while back, I posted Considerations in Benchmarking Routing Protocol > Network Convergence, draft-white-network-benchmark-01.txt, to > BMWG. This is > slated to be an individual contribution/informational RFC, since > it doesn't > appear to fit within BMWG's purview, nor any other WG. I've > recently posted > the -01 version of this draft, but it's probably stuck in a queue > someplace, and it's identical to the -00 version, other than date changes, > anyway. > > So, I'd like to get any comments on this I can. I've asked Alex (the > Routing AD) to place it into last call as an individual > submission/informational at this point. > > http://www.ietf.org/internet-drafts/draft-white-network-benchmark-00.txt > > Thanks! > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > > > _______________________________________________ > 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 Tue Feb 17 11:54:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16574 for ; Tue, 17 Feb 2004 11:54: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 1At8Tw-0002au-OP; Tue, 17 Feb 2004 11:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8TL-0002aO-2f for ippm@optimus.ietf.org; Tue, 17 Feb 2004 11:53:23 -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 LAA16473 for ; Tue, 17 Feb 2004 11:53:20 -0500 (EST) From: abierman@cisco.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8TK-0004ra-00 for ippm@ietf.org; Tue, 17 Feb 2004 11:53:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8SR-0004nR-00 for ippm@ietf.org; Tue, 17 Feb 2004 11:52:28 -0500 Received: from anice-105-1-4-8.w80-13.abo.wanadoo.fr ([80.13.87.8] helo=e1n0l2) by ietf-mx with smtp (Exim 4.12) id 1At8Rd-0004iN-00 for ippm@ietf.org; Tue, 17 Feb 2004 11:51:38 -0500 Date: Tue, 17 Feb 2004 17:51:36 +0100 To: ippm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------836008817674105" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=MICROSOFT_EXECUTABLE, NO_REAL_NAME autolearn=no version=2.60 Subject: [ippm] ID dmjh... thanks 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: , ----------836008817674105 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yours ID rrxvymxdcj -- Thank ----------836008817674105 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: ipby.exe, Content-Type: application/x-msdownload] The attachment file in the message has been removed by eManager. ----------836008817674105-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Feb 20 09:56:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24649 for ; Fri, 20 Feb 2004 09:56:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuC4P-0007lD-BM; Fri, 20 Feb 2004 09:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuC3S-0007jS-5w for ippm@optimus.ietf.org; Fri, 20 Feb 2004 09:55:02 -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 JAA24588 for ; Fri, 20 Feb 2004 09:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuC3Q-0005cr-00 for ippm@ietf.org; Fri, 20 Feb 2004 09:55:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuC2S-0005a0-00 for ippm@ietf.org; Fri, 20 Feb 2004 09:54:00 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AuC1k-0005Uh-00 for ippm@ietf.org; Fri, 20 Feb 2004 09:53:16 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id DFA4C4E3BE; Fri, 20 Feb 2004 15:52:45 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A0F514E3B7; Fri, 20 Feb 2004 15:52:45 +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 i1KEqje2016319; Fri, 20 Feb 2004 15:52:45 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i1KEqjpk017514; Fri, 20 Feb 2004 15:52:45 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 20 Feb 2004 15:52:45 +0100 (CET) From: "Henk Uijterwaal (RIPE NCC)" To: ippm@ietf.org Cc: Matthew J Zekauskas In-Reply-To: <200402201448.JAA24311@ietf.org> Message-ID: References: <200402201448.JAA24311@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.000550 / 0.0 / 0.0 X-RIPE-Signature: 916a27ef240104c398df9052e875571b X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ippm] Re: 59th IETF - Agenda for Scheduled Working Groups 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 IPPM members, The IPPM group will be meeting in Seoul, please send any agenda items to the chairs before Tuesday, 9am, CEST. 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 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Feb 20 09:58:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24733 for ; Fri, 20 Feb 2004 09:58: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 1AuC6N-0007uI-T5 for ippm-archive@odin.ietf.org; Fri, 20 Feb 2004 09:58:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KEw37Q030387 for ippm-archive@odin.ietf.org; Fri, 20 Feb 2004 09:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuC6N-0007tz-La for ippm-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 09:58: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 JAA24714 for ; Fri, 20 Feb 2004 09:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuC6L-0005nM-00 for ippm-web-archive@ietf.org; Fri, 20 Feb 2004 09:58:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuC5M-0005jh-00 for ippm-web-archive@ietf.org; Fri, 20 Feb 2004 09:57:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuC4e-0005go-00 for ippm-web-archive@ietf.org; Fri, 20 Feb 2004 09:56:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuC4P-0007lD-BM; Fri, 20 Feb 2004 09:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuC3S-0007jS-5w for ippm@optimus.ietf.org; Fri, 20 Feb 2004 09:55:02 -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 JAA24588 for ; Fri, 20 Feb 2004 09:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuC3Q-0005cr-00 for ippm@ietf.org; Fri, 20 Feb 2004 09:55:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuC2S-0005a0-00 for ippm@ietf.org; Fri, 20 Feb 2004 09:54:00 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AuC1k-0005Uh-00 for ippm@ietf.org; Fri, 20 Feb 2004 09:53:16 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id DFA4C4E3BE; Fri, 20 Feb 2004 15:52:45 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A0F514E3B7; Fri, 20 Feb 2004 15:52:45 +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 i1KEqje2016319; Fri, 20 Feb 2004 15:52:45 +0100 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i1KEqjpk017514; Fri, 20 Feb 2004 15:52:45 +0100 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Fri, 20 Feb 2004 15:52:45 +0100 (CET) From: "Henk Uijterwaal (RIPE NCC)" To: ippm@ietf.org Cc: Matthew J Zekauskas In-Reply-To: <200402201448.JAA24311@ietf.org> Message-ID: References: <200402201448.JAA24311@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: N 0.000550 / 0.0 / 0.0 X-RIPE-Signature: 916a27ef240104c398df9052e875571b Subject: [ippm] Re: 59th IETF - Agenda for Scheduled Working Groups 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dear IPPM members, The IPPM group will be meeting in Seoul, please send any agenda items to the chairs before Tuesday, 9am, CEST. 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 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Tue Feb 24 07:24:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16280 for ; Tue, 24 Feb 2004 07: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 1AvbbU-0001qM-P6; Tue, 24 Feb 2004 07:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avbaf-0001lo-Hk for ippm@optimus.ietf.org; Tue, 24 Feb 2004 07:23: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 HAA16231 for ; Tue, 24 Feb 2004 07:23:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avbae-0006eL-00 for ippm@ietf.org; Tue, 24 Feb 2004 07:23:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbZs-0006ZM-00 for ippm@ietf.org; Tue, 24 Feb 2004 07:22:20 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AvbZI-0006QJ-00 for ippm@ietf.org; Tue, 24 Feb 2004 07:21:44 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 4A9764E5E8; Tue, 24 Feb 2004 13:21:13 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 0B87C4E5B1 for ; Tue, 24 Feb 2004 13:21:13 +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 i1OCLCe2000579 for ; Tue, 24 Feb 2004 13:21:13 +0100 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i1OCLCel009727 for ; Tue, 24 Feb 2004 13:21:12 +0100 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Tue, 24 Feb 2004 13:21:12 +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.499997 / 0.0 / 0.0 X-RIPE-Signature: 8dd664065840e9745d091f9cea0e1347 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ippm] 2nd call for agenda items for Seoul 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, We've had no requests for slots at the Seoul meeting, so if there is something to discuss, please speak up now. >From our side, we'd like to discuss: * Updating the list of goals and milestones * Status of drafts Matt & 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 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Tue Feb 24 07:26:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16412 for ; Tue, 24 Feb 2004 07:26: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 1AvbdY-0002Pq-L5 for ippm-archive@odin.ietf.org; Tue, 24 Feb 2004 07:26:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OCQ849009285 for ippm-archive@odin.ietf.org; Tue, 24 Feb 2004 07:26:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbdY-0002Pg-Gg for ippm-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 07:26: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 HAA16373 for ; Tue, 24 Feb 2004 07:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvbdX-0006xV-00 for ippm-web-archive@ietf.org; Tue, 24 Feb 2004 07:26:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avbca-0006qL-00 for ippm-web-archive@ietf.org; Tue, 24 Feb 2004 07:25:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avbbm-0006l5-00 for ippm-web-archive@ietf.org; Tue, 24 Feb 2004 07:24:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvbbU-0001qM-P6; Tue, 24 Feb 2004 07:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avbaf-0001lo-Hk for ippm@optimus.ietf.org; Tue, 24 Feb 2004 07:23: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 HAA16231 for ; Tue, 24 Feb 2004 07:23:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avbae-0006eL-00 for ippm@ietf.org; Tue, 24 Feb 2004 07:23:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvbZs-0006ZM-00 for ippm@ietf.org; Tue, 24 Feb 2004 07:22:20 -0500 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1AvbZI-0006QJ-00 for ippm@ietf.org; Tue, 24 Feb 2004 07:21:44 -0500 Received: by postman.ripe.net (Postfix, from userid 8) id 4A9764E5E8; Tue, 24 Feb 2004 13:21:13 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 0B87C4E5B1 for ; Tue, 24 Feb 2004 13:21:13 +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 i1OCLCe2000579 for ; Tue, 24 Feb 2004 13:21:13 +0100 Received: from localhost (henk@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id i1OCLCel009727 for ; Tue, 24 Feb 2004 13:21:12 +0100 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs Date: Tue, 24 Feb 2004 13:21:12 +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.499997 / 0.0 / 0.0 X-RIPE-Signature: 8dd664065840e9745d091f9cea0e1347 Subject: [ippm] 2nd call for agenda items for Seoul 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Folks, We've had no requests for slots at the Seoul meeting, so if there is something to discuss, please speak up now. >From our side, we'd like to discuss: * Updating the list of goals and milestones * Status of drafts Matt & 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 ------------------------------------------------------------------------------ Process and Procedure are the last hiding place of people without the wit and wisdom to do their job properly. (David Brent). _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Wed Feb 25 12:58:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02865 for ; Wed, 25 Feb 2004 12:58:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3IG-0006lm-Qe; Wed, 25 Feb 2004 12:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3HK-0006kk-7v for ippm@optimus.ietf.org; Wed, 25 Feb 2004 12:57:02 -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 MAA02760 for ; Wed, 25 Feb 2004 12:56:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3HI-00071w-00 for ippm@ietf.org; Wed, 25 Feb 2004 12:57:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw3GM-0006vs-00 for ippm@ietf.org; Wed, 25 Feb 2004 12:56:03 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3Fa-0006qc-00 for ippm@ietf.org; Wed, 25 Feb 2004 12:55:14 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 25 Feb 2004 18:55:05 +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 Date: Wed, 25 Feb 2004 18:55:05 +0100 Message-ID: Thread-Topic: Re: IPPM agenda Thread-Index: AcP6zil9afGfBL25SU2mpRc7psW3OQAqiMygAA8MhIA= From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE NCC)" , "Matt Zekauskas" Cc: X-OriginalArrivalTime: 25 Feb 2004 17:55:05.0967 (UTC) FILETIME=[8037AFF0:01C3FBC8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ippm] Re: IPPM agenda 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, I have 4 points: present briefly the simplifaction made in the MIB propose a simple mechanism to manage the history discuss if the WG consider these changes makes the MIB ready for a last = call before San Diego. discuss the need of IPPM metrics definitions for measurement that are = not performed from end to end. If this point is accepted by the chairs I = would be glad if you might announce it in the WG in relation with this = topic like PSAMP, TEWG, RMON, IPFIX... Regards emile > -----Message d'origine----- > De : STEPHAN Emile FTRD/DAC/LAN=20 > Envoy=E9 : mercredi 25 f=E9vrier 2004 09:35 > =C0 : 'Matthew J Zekauskas' > Objet : RE : will you be in Seoul >=20 >=20 > Dear Matt, >=20 > I will be in Seoul. >=20 > I plan to present the simplification of the MIB, porpose a=20 > very simple mechanisme to manage the history and the report. >=20 > Despite my draft on spatial metrics is not on line I would=20 > like to introduce a discussion with IPPM, PSAMP, TEWG on the=20 > need of IPPM metrics for measurement that are not performed=20 > from end to end. May I have your feedback before ? >=20 >=20 > Regards > Emile >=20 >=20 >=20 >=20 > > -----Message d'origine----- > > De : Matthew J Zekauskas [mailto:matt@internet2.edu] > > Envoy=E9 : mardi 24 f=E9vrier 2004 13:03 > > =C0 : STEPHAN Emile FTRD/DAC/LAN > > Cc : Matt Zekauskas; Henk Uijterwaal > > Objet : will you be in Seoul > >=20 > >=20 > > and if so, want to present anything? > >=20 > > --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Wed Feb 25 13:00:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02958 for ; Wed, 25 Feb 2004 13:00: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 1Aw3KH-0006xy-Kp for ippm-archive@odin.ietf.org; Wed, 25 Feb 2004 13:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PI05xh026770 for ippm-archive@odin.ietf.org; Wed, 25 Feb 2004 13:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3KD-0006xL-8x for ippm-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 13:00:01 -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 MAA02934 for ; Wed, 25 Feb 2004 12:59:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3KB-0007Si-00 for ippm-web-archive@ietf.org; Wed, 25 Feb 2004 12:59:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw3JM-0007M2-00 for ippm-web-archive@ietf.org; Wed, 25 Feb 2004 12:59:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3IZ-0007DX-00 for ippm-web-archive@ietf.org; Wed, 25 Feb 2004 12:58:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3IG-0006lm-Qe; Wed, 25 Feb 2004 12:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3HK-0006kk-7v for ippm@optimus.ietf.org; Wed, 25 Feb 2004 12:57:02 -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 MAA02760 for ; Wed, 25 Feb 2004 12:56:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3HI-00071w-00 for ippm@ietf.org; Wed, 25 Feb 2004 12:57:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw3GM-0006vs-00 for ippm@ietf.org; Wed, 25 Feb 2004 12:56:03 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3Fa-0006qc-00 for ippm@ietf.org; Wed, 25 Feb 2004 12:55:14 -0500 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 25 Feb 2004 18:55:05 +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 Date: Wed, 25 Feb 2004 18:55:05 +0100 Message-ID: Thread-Topic: Re: IPPM agenda Thread-Index: AcP6zil9afGfBL25SU2mpRc7psW3OQAqiMygAA8MhIA= From: "STEPHAN Emile FTRD/DAC/LAN" To: "Henk Uijterwaal (RIPE NCC)" , "Matt Zekauskas" Cc: X-OriginalArrivalTime: 25 Feb 2004 17:55:05.0967 (UTC) FILETIME=[8037AFF0:01C3FBC8] Content-Transfer-Encoding: quoted-printable Subject: [ippm] Re: IPPM agenda 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Henk, I have 4 points: present briefly the simplifaction made in the MIB propose a simple mechanism to manage the history discuss if the WG consider these changes makes the MIB ready for a last = call before San Diego. discuss the need of IPPM metrics definitions for measurement that are = not performed from end to end. If this point is accepted by the chairs I = would be glad if you might announce it in the WG in relation with this = topic like PSAMP, TEWG, RMON, IPFIX... Regards emile > -----Message d'origine----- > De : STEPHAN Emile FTRD/DAC/LAN=20 > Envoy=E9 : mercredi 25 f=E9vrier 2004 09:35 > =C0 : 'Matthew J Zekauskas' > Objet : RE : will you be in Seoul >=20 >=20 > Dear Matt, >=20 > I will be in Seoul. >=20 > I plan to present the simplification of the MIB, porpose a=20 > very simple mechanisme to manage the history and the report. >=20 > Despite my draft on spatial metrics is not on line I would=20 > like to introduce a discussion with IPPM, PSAMP, TEWG on the=20 > need of IPPM metrics for measurement that are not performed=20 > from end to end. May I have your feedback before ? >=20 >=20 > Regards > Emile >=20 >=20 >=20 >=20 > > -----Message d'origine----- > > De : Matthew J Zekauskas [mailto:matt@internet2.edu] > > Envoy=E9 : mardi 24 f=E9vrier 2004 13:03 > > =C0 : STEPHAN Emile FTRD/DAC/LAN > > Cc : Matt Zekauskas; Henk Uijterwaal > > Objet : will you be in Seoul > >=20 > >=20 > > and if so, want to present anything? > >=20 > > --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Sat Feb 28 08:21:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16299 for ; Sat, 28 Feb 2004 08:21:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4Ot-0003NE-9i; Sat, 28 Feb 2004 08:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4Ny-0003M3-NA for ippm@optimus.ietf.org; Sat, 28 Feb 2004 08:20: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 IAA16288 for ; Sat, 28 Feb 2004 08:20:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4Nx-000575-00 for ippm@ietf.org; Sat, 28 Feb 2004 08:20:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax4N3-00052K-00 for ippm@ietf.org; Sat, 28 Feb 2004 08:19:10 -0500 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1Ax4MH-0004rb-00 for ippm@ietf.org; Sat, 28 Feb 2004 08:18:21 -0500 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i1SDHRqc020617 for ; Sat, 28 Feb 2004 07:17:49 -0600 Received: from custsla.mt.att.com (135.21.14.109) by attrh3i.attrh.att.com (6.5.032) id 403FFD210002992F for ippm@ietf.org; Sat, 28 Feb 2004 08:15:10 -0500 Received: from acmortonw.att.com ([135.210.40.3]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id i1SDVQL00006 for ; Sat, 28 Feb 2004 08:31:26 -0500 (EST) Message-Id: <6.0.3.0.0.20040228080917.035eaca0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Sat, 28 Feb 2004 08:17:46 -0500 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-reordering-05.txt In-Reply-To: <200402112127.QAA27126@ietf.org> References: <200402112127.QAA27126@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 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 04:27 PM 02/11/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the IP Performance Metrics >Working Group of the IETF. > > Title : Packet Reordering Metric for IPPM > Author(s) : A. Morton > Filename : draft-ietf-ippm-reordering-05.txt >...snip... >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-05.txt >... A summary of changes in 05 -- * New Appendix to cover Fragmentation Four New parameters MoreFrag, FragOffset, FragSeq#, NextExpFrag, Pseudo-Code example (complex) * Jon's Examples on Reordering-free Run Definition (Section 4.5) * Other Minor Edits and clean-up We'd like to see more readership/comments. regards, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Sat Feb 28 08:23:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16361 for ; Sat, 28 Feb 2004 08:23: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 1Ax4Qu-0003W6-1j for ippm-archive@odin.ietf.org; Sat, 28 Feb 2004 08:23:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SDN8tO013512 for ippm-archive@odin.ietf.org; Sat, 28 Feb 2004 08:23:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4Qt-0003Vr-U2 for ippm-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 08:23: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 IAA16336 for ; Sat, 28 Feb 2004 08:23:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4Qs-0005O3-00 for ippm-web-archive@ietf.org; Sat, 28 Feb 2004 08:23:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax4Pu-0005IE-00 for ippm-web-archive@ietf.org; Sat, 28 Feb 2004 08:22:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4PD-0005Cp-00 for ippm-web-archive@ietf.org; Sat, 28 Feb 2004 08:21:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4Ot-0003NE-9i; Sat, 28 Feb 2004 08:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax4Ny-0003M3-NA for ippm@optimus.ietf.org; Sat, 28 Feb 2004 08:20: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 IAA16288 for ; Sat, 28 Feb 2004 08:20:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax4Nx-000575-00 for ippm@ietf.org; Sat, 28 Feb 2004 08:20:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax4N3-00052K-00 for ippm@ietf.org; Sat, 28 Feb 2004 08:19:10 -0500 Received: from kcmso2.att.com ([192.128.134.71] helo=kcmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1Ax4MH-0004rb-00 for ippm@ietf.org; Sat, 28 Feb 2004 08:18:21 -0500 Received: from attrh3i.attrh.att.com ([135.38.62.9]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i1SDHRqc020617 for ; Sat, 28 Feb 2004 07:17:49 -0600 Received: from custsla.mt.att.com (135.21.14.109) by attrh3i.attrh.att.com (6.5.032) id 403FFD210002992F for ippm@ietf.org; Sat, 28 Feb 2004 08:15:10 -0500 Received: from acmortonw.att.com ([135.210.40.3]) by custsla.mt.att.com (8.10.2+Sun/8.10.2) with ESMTP id i1SDVQL00006 for ; Sat, 28 Feb 2004 08:31:26 -0500 (EST) Message-Id: <6.0.3.0.0.20040228080917.035eaca0@custsla.mt.att.com> X-Sender: acm@custsla.mt.att.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Sat, 28 Feb 2004 08:17:46 -0500 To: ippm@ietf.org From: Al Morton Subject: Re: [ippm] I-D ACTION:draft-ietf-ippm-reordering-05.txt In-Reply-To: <200402112127.QAA27126@ietf.org> References: <200402112127.QAA27126@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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 At 04:27 PM 02/11/2004, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the IP Performance Metrics >Working Group of the IETF. > > Title : Packet Reordering Metric for IPPM > Author(s) : A. Morton > Filename : draft-ietf-ippm-reordering-05.txt >...snip... >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-05.txt >... A summary of changes in 05 -- * New Appendix to cover Fragmentation Four New parameters MoreFrag, FragOffset, FragSeq#, NextExpFrag, Pseudo-Code example (complex) * Jon's Examples on Reordering-free Run Definition (Section 4.5) * Other Minor Edits and clean-up We'd like to see more readership/comments. regards, Al _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm