From ippm-admin@ietf.org Thu Apr 1 15:29:28 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 PAA29970 for ; Thu, 1 Apr 2004 15:29:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98nl-0008Cd-5p; Thu, 01 Apr 2004 15:28:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98nT-0007wr-JX for ippm@optimus.ietf.org; Thu, 01 Apr 2004 15:28:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29947 for ; Thu, 1 Apr 2004 15:28:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98nS-0006Q1-00 for ippm@ietf.org; Thu, 01 Apr 2004 15:28:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98mW-0006LQ-00 for ippm@ietf.org; Thu, 01 Apr 2004 15:27:21 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1B98lh-0006Gt-00 for ippm@ietf.org; Thu, 01 Apr 2004 15:26:29 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 8B66130FE; Thu, 1 Apr 2004 15:26:29 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16793-01; Thu, 1 Apr 2004 15:26:29 -0500 (EST) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 6663A30C8; Thu, 1 Apr 2004 15:26:29 -0500 (EST) Date: Thu, 01 Apr 2004 15:26:28 -0500 From: Matthew J Zekauskas To: ippm@ietf.org Cc: Matt Zekauskas , Henk Uijterwaal Message-ID: <14727206.1080833188@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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [ippm] minutes for IPPM at IETF-59 Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've added the minutes to http://people.internet2.edu/~matt/IPPM/Meetings/ietf59/ If you have any comments, get them to Henk as soon as possible. I'll be offline until after the minutes deadline (5pm ET friday). --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Apr 1 15:31:10 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 PAA00045 for ; Thu, 1 Apr 2004 15:31:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98pk-0004fP-O1 for ippm-archive@odin.ietf.org; Thu, 01 Apr 2004 15:30:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31KUWcS016697 for ippm-archive@odin.ietf.org; Thu, 1 Apr 2004 15:30:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98pa-0004A4-Rx for ippm-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 15:30: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 PAA00035 for ; Thu, 1 Apr 2004 15:30:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98pS-0006eG-00 for ippm-web-archive@ietf.org; Thu, 01 Apr 2004 15:30:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98oU-0006Vs-00 for ippm-web-archive@ietf.org; Thu, 01 Apr 2004 15:29:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B98o7-0006RI-00 for ippm-web-archive@ietf.org; Thu, 01 Apr 2004 15:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98nl-0008Cd-5p; Thu, 01 Apr 2004 15:28:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98nT-0007wr-JX for ippm@optimus.ietf.org; Thu, 01 Apr 2004 15:28:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29947 for ; Thu, 1 Apr 2004 15:28:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98nS-0006Q1-00 for ippm@ietf.org; Thu, 01 Apr 2004 15:28:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98mW-0006LQ-00 for ippm@ietf.org; Thu, 01 Apr 2004 15:27:21 -0500 Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx with esmtp (Exim 4.12) id 1B98lh-0006Gt-00 for ippm@ietf.org; Thu, 01 Apr 2004 15:26:29 -0500 Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 8B66130FE; Thu, 1 Apr 2004 15:26:29 -0500 (EST) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16793-01; Thu, 1 Apr 2004 15:26:29 -0500 (EST) Received: from BMW (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 6663A30C8; Thu, 1 Apr 2004 15:26:29 -0500 (EST) Date: Thu, 01 Apr 2004 15:26:28 -0500 From: Matthew J Zekauskas To: ippm@ietf.org Cc: Matt Zekauskas , Henk Uijterwaal Message-ID: <14727206.1080833188@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] minutes for IPPM at IETF-59 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've added the minutes to http://people.internet2.edu/~matt/IPPM/Meetings/ietf59/ If you have any comments, get them to Henk as soon as possible. I'll be offline until after the minutes deadline (5pm ET friday). --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From mailman-admin@ietf.org Thu Apr 1 18:51:45 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 SAA10616 for ; Thu, 1 Apr 2004 18:51:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9A72-0007Ca-3C for ippm-archive@lists.ietf.org; Thu, 01 Apr 2004 16:52:36 -0500 Date: Thu, 01 Apr 2004 11:27:05 -0500 Message-ID: <20040401162705.11029.25555.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 Fri Apr 2 00:02:53 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 AAA09489 for ; Fri, 2 Apr 2004 00:02:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Dz7-0000x1-2W for ippm-archive@odin.ietf.org; Thu, 01 Apr 2004 21:00:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3220fTg003650 for ippm-archive@odin.ietf.org; Thu, 1 Apr 2004 21:00:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9CQB-0007hc-Bi for ippm-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 19:20:31 -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 TAA13305 for ; Thu, 1 Apr 2004 19:20:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9CQ9-0000vS-00 for ippm-web-archive@ietf.org; Thu, 01 Apr 2004 19:20:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9CPI-0000pD-00 for ippm-web-archive@ietf.org; Thu, 01 Apr 2004 19:19:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9COa-0000j4-00 for ippm-web-archive@ietf.org; Thu, 01 Apr 2004 19:18:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9A5h-00072V-Qe for ippm-web-archive@ietf.org; Thu, 01 Apr 2004 16:51:13 -0500 Date: Thu, 01 Apr 2004 11:26:59 -0500 Message-ID: <20040401162659.11029.75848.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.7 required=5.0 tests=AWL,DATE_IN_PAST_03_06, 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 Tue Apr 6 10:48:37 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 KAA23021 for ; Tue, 6 Apr 2004 10:48:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArrt-000581-Hg; Tue, 06 Apr 2004 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArqv-0004rB-OU for ippm@optimus.ietf.org; Tue, 06 Apr 2004 10:47:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22928 for ; Tue, 6 Apr 2004 10:46:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BArqt-0002ss-00 for ippm@ietf.org; Tue, 06 Apr 2004 10:46:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BArEx-00077Y-00 for ippm@ietf.org; Tue, 06 Apr 2004 10:07:48 -0400 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1BAr1k-0004XH-00; Tue, 06 Apr 2004 09:54:09 -0400 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 1A6DD77A6E0; Tue, 6 Apr 2004 09:53:38 -0400 (EDT) To: imrg@ietf.org, ippm@ietf.org From: Mark Allman Reply-To: mallman@icir.org Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Still Rock and Roll to Me MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 06 Apr 2004 09:53:38 -0400 Message-Id: <20040406135338.1A6DD77A6E0@guns.icir.org> 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=AWL autolearn=no version=2.60 Subject: [ippm] FW: cfp: network troubleshooting workshop 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: , --=-=-= A quick reminder that the deadline for paper registration (abstract + author list) for the "Network Troubleshooting" workshop is Thursday (4/8). The submission site and instructions are available from the link below. Thanks! allman ------- Forwarded Message Hi folks! A workshop on "Network Troubleshooting: Research Theory and Operations Practice Meet Malfunctioning Reality" will be held in conjunction with SIGCOMM this fall. We're encouraging research / operators / etc. with applicable contributions to submit a short paper to this workshop (3-6 pages). In addition, we're planning on having a poster session. If you'd like to setup a poster, please send a 1-page abstract. The workshop web page is at: http://www.acm.org/sigs/sigcomm/sigcomm2004/netts.html Submissions will be handled electronically and a link will be added to the above page soon. The call for papers is attached. Thanks! allman Network Troubleshooting: Research Theory and Operations Practice Meet Malfunctioning Reality Call For Papers: Network monitoring and measurement has received a great deal of attention in the research community recently. While some research to-date has been focused on finding problems, failures and anomalies in networks this workshop endeavors to focus specifically on such topics. The workshop seeks papers exploring several themes: * DETECTION: Mechanisms and techniques for detecting failures, imminent failures and other anomalies in real time. The focus of this workshop is research that can be used operationally to help the network in the short-term. Techniques that require heavyweight offline analysis to find problems provide the community with an understanding of and an insight into the dynamics and potential long-term solutions for network issues, but are not the main focus of this workshop. * CORRECTION: While detecting problems (or imminent problems) and alerting network operators is a good first step, techniques for automatically mitigating problems as they occur are also sought. * COORDINATION: Detecting and solving problems in a multi-provider environment inevitably involves communicating between distinct autonomous entities. Mechanisms and facilities to streamline and automate such communication are sought. * EXPERIENCE: Insight from network operators into network problems they cannot easily detect (or, detect far too late) and tools that would make network management much easier. Input from network operators on non-obvious or non-technical considerations which impact technical solutions are also sought. This workshop invites two kinds of submissions: (1) Original papers on any area of network measurement, monitoring or management specifically directed towards one or more of the above themes. (2) Poster presentation proposals. While posters on any of the above themes will be accepted, posters on operational experience are highly sought. Note: For this workshop, "networks" includes both physical networks and virtual networks (CDNs, overlays, etc.). Some of the specific problems of interest, include: + Protocol failures - link, routing, management + Detecting mis-configuration of network elements + Partial hardware failures - intermittent, unreported + Traffic engineering for overload control + Security - DDoS attacks, detecting compromised network elements, intrusion detection (especially for non-edge networks since a large body of work already tackles the problems at the network edge) Submissions: Submissions ranging from presentations of specific research to position papers are welcome. Papers presenting interesting and novel ideas at an early stage of development are preferred over completed journal-style results. Selected papers will be forward-looking, with impact and implications for both operational networks and ongoing or future research. Original papers should be 3-6 standard SIGCOMM formatted pages (with the expectation that position papers will be shorter and research papers longer). Poster proposals should be sent in the form of 1-page abstracts. The submission process and specific guidelines will be posted at a later date. Important Dates: Submission Registration: April 8, 2004 Submission deadline: April 15, 2004 Notification deadline: May 15, 2004 Camera ready deadline: June 15, 2004 Workshop Organizers: Program Co-Chairs (trouble04-chairs@icir.org): Jon C.R. Bennett, Harvard University Mark Allman, ICIR Program Committee: Randy Bush, IIJ Albert Greenberg, AT&T Research Geoff Huston, Telstra David Moore, CAIDA/UCSD CSE Craig Partridge, BBN Technologies Neil Spring, Univ. of Washington Rob Thomas, Cisco/Team Cymru ------- End of Forwarded Message --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAcrZiWyrrWs4yIs4RAvClAJ4vxkam1BEiXIrFjlWIwP0VGD2tGACePIHL tIvGaKtQpI3k6ILvI1pmLcI= =n7Zr -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Tue Apr 6 11:49:32 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 LAA29180 for ; Tue, 6 Apr 2004 11:49:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAsop-000760-Qa for ippm-archive@odin.ietf.org; Tue, 06 Apr 2004 11:49:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36FmnHR027259 for ippm-archive@odin.ietf.org; Tue, 6 Apr 2004 11:48:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAsog-00075I-PR for ippm-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 11:48:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29152 for ; Tue, 6 Apr 2004 11:48:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAsoc-00037e-00 for ippm-web-archive@ietf.org; Tue, 06 Apr 2004 11:48:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAsDv-0006wA-00 for ippm-web-archive@ietf.org; Tue, 06 Apr 2004 11:10:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BArs5-00037c-00 for ippm-web-archive@ietf.org; Tue, 06 Apr 2004 10:48:13 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BArs5-000510-0h for ippm-web-archive@ietf.org; Tue, 06 Apr 2004 10:48:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArrt-000581-Hg; Tue, 06 Apr 2004 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArqv-0004rB-OU for ippm@optimus.ietf.org; Tue, 06 Apr 2004 10:47:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22928 for ; Tue, 6 Apr 2004 10:46:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BArqt-0002ss-00 for ippm@ietf.org; Tue, 06 Apr 2004 10:46:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BArEx-00077Y-00 for ippm@ietf.org; Tue, 06 Apr 2004 10:07:48 -0400 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1BAr1k-0004XH-00; Tue, 06 Apr 2004 09:54:09 -0400 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 1A6DD77A6E0; Tue, 6 Apr 2004 09:53:38 -0400 (EDT) To: imrg@ietf.org, ippm@ietf.org From: Mark Allman Reply-To: mallman@icir.org Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: It's Still Rock and Roll to Me MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 06 Apr 2004 09:53:38 -0400 Message-Id: <20040406135338.1A6DD77A6E0@guns.icir.org> Subject: [ippm] FW: cfp: network troubleshooting workshop 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=AWL autolearn=no version=2.60 --=-=-= A quick reminder that the deadline for paper registration (abstract + author list) for the "Network Troubleshooting" workshop is Thursday (4/8). The submission site and instructions are available from the link below. Thanks! allman ------- Forwarded Message Hi folks! A workshop on "Network Troubleshooting: Research Theory and Operations Practice Meet Malfunctioning Reality" will be held in conjunction with SIGCOMM this fall. We're encouraging research / operators / etc. with applicable contributions to submit a short paper to this workshop (3-6 pages). In addition, we're planning on having a poster session. If you'd like to setup a poster, please send a 1-page abstract. The workshop web page is at: http://www.acm.org/sigs/sigcomm/sigcomm2004/netts.html Submissions will be handled electronically and a link will be added to the above page soon. The call for papers is attached. Thanks! allman Network Troubleshooting: Research Theory and Operations Practice Meet Malfunctioning Reality Call For Papers: Network monitoring and measurement has received a great deal of attention in the research community recently. While some research to-date has been focused on finding problems, failures and anomalies in networks this workshop endeavors to focus specifically on such topics. The workshop seeks papers exploring several themes: * DETECTION: Mechanisms and techniques for detecting failures, imminent failures and other anomalies in real time. The focus of this workshop is research that can be used operationally to help the network in the short-term. Techniques that require heavyweight offline analysis to find problems provide the community with an understanding of and an insight into the dynamics and potential long-term solutions for network issues, but are not the main focus of this workshop. * CORRECTION: While detecting problems (or imminent problems) and alerting network operators is a good first step, techniques for automatically mitigating problems as they occur are also sought. * COORDINATION: Detecting and solving problems in a multi-provider environment inevitably involves communicating between distinct autonomous entities. Mechanisms and facilities to streamline and automate such communication are sought. * EXPERIENCE: Insight from network operators into network problems they cannot easily detect (or, detect far too late) and tools that would make network management much easier. Input from network operators on non-obvious or non-technical considerations which impact technical solutions are also sought. This workshop invites two kinds of submissions: (1) Original papers on any area of network measurement, monitoring or management specifically directed towards one or more of the above themes. (2) Poster presentation proposals. While posters on any of the above themes will be accepted, posters on operational experience are highly sought. Note: For this workshop, "networks" includes both physical networks and virtual networks (CDNs, overlays, etc.). Some of the specific problems of interest, include: + Protocol failures - link, routing, management + Detecting mis-configuration of network elements + Partial hardware failures - intermittent, unreported + Traffic engineering for overload control + Security - DDoS attacks, detecting compromised network elements, intrusion detection (especially for non-edge networks since a large body of work already tackles the problems at the network edge) Submissions: Submissions ranging from presentations of specific research to position papers are welcome. Papers presenting interesting and novel ideas at an early stage of development are preferred over completed journal-style results. Selected papers will be forward-looking, with impact and implications for both operational networks and ongoing or future research. Original papers should be 3-6 standard SIGCOMM formatted pages (with the expectation that position papers will be shorter and research papers longer). Poster proposals should be sent in the form of 1-page abstracts. The submission process and specific guidelines will be posted at a later date. Important Dates: Submission Registration: April 8, 2004 Submission deadline: April 15, 2004 Notification deadline: May 15, 2004 Camera ready deadline: June 15, 2004 Workshop Organizers: Program Co-Chairs (trouble04-chairs@icir.org): Jon C.R. Bennett, Harvard University Mark Allman, ICIR Program Committee: Randy Bush, IIJ Albert Greenberg, AT&T Research Geoff Huston, Telstra David Moore, CAIDA/UCSD CSE Craig Partridge, BBN Technologies Neil Spring, Univ. of Washington Rob Thomas, Cisco/Team Cymru ------- End of Forwarded Message --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAcrZiWyrrWs4yIs4RAvClAJ4vxkam1BEiXIrFjlWIwP0VGD2tGACePIHL tIvGaKtQpI3k6ILvI1pmLcI= =n7Zr -----END PGP SIGNATURE----- --=-=-=-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Thu Apr 29 07:11:09 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 HAA20140 for ; Thu, 29 Apr 2004 07:11:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9C6-00013i-Go; Thu, 29 Apr 2004 06:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9AB-0000VS-Ua for ippm@optimus.ietf.org; Thu, 29 Apr 2004 06:53:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19620 for ; Thu, 29 Apr 2004 06:52:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ9A2-000130-Qn for ippm@ietf.org; Thu, 29 Apr 2004 06:52:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ994-0000sK-00 for ippm@ietf.org; Thu, 29 Apr 2004 06:51:59 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1BJ987-0000Xx-00 for ippm@ietf.org; Thu, 29 Apr 2004 06:51:00 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 5BBAD5DF9C; Thu, 29 Apr 2004 12:50:32 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 798285DF9F for ; Thu, 29 Apr 2004 12:50:31 +0200 (CEST) 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 i3TAoVVt026749 for ; Thu, 29 Apr 2004 12:50:31 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i3TAoV7u017086 for ; Thu, 29 Apr 2004 12:50:31 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Thu, 29 Apr 2004 12:50:31 +0200 (CEST) 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.003329 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8323d20a2b741b06bf613423a6e469cf 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,REMOVE_REMOVAL_NEAR autolearn=no version=2.60 Subject: [ippm] OPS-AD evaluation of: draft-ietf-ippm-metrics-registry-05.txt (fwd) Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , Dear All, We received the attached set of comments on draft-ietf-ippm-metrics-registry-05.txt from Bert Wijnen. Emile is already looking into them, as soon as he has processed them, an 06-draft will be published and the WGLC repeated, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~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). ---------- Forwarded message ---------- Date: Sun, 25 Apr 2004 05:52:49 +0200 From: "Wijnen, Bert (Bert)" [...] Here we go: 1. Abstract s/OBJECT IDENTIFIER/OBJECT-IDENTITY/ I actually would word it differently. SO I would change it from Abstract 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. to something aka: Abstract This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF. This memo also defines the rules for adding new IP Performance Metrics in the future, both those standardized inside and outside the IETF. IANA has been assigned to administer this new registry. 2. Section 3 currently is a copy of the abstract. Not sure if that is usefull. I would just leave it out. Section 5 (also named overview) seems to be more helpfull. 3. In sect 5, the memo speaks of "MIBs". This should be changed to "MIB modules". I think I have mentioned many times that we have only one single MIB that is composed of multiple MIB modules. This same change needs to be made at multiple places in this document 4. Sect 5. first bullet. I think I would change "clearly" into "clearly and unambiguously" 5. Sect 6, 1st para MIBs need OBJECT INDENTIFIERs to refer precisely to the standardized metrics. The registry associates an OBJECT IDENTIFIER with each metric. As an example oneWayDelay and oneWayDelayPoissonStream have different identifiers. change to something aka: MIB modules need to be able to precisely reference IPPM Metrics. The registry associates an OBJECT-IDENTITY with each metric. As an example oneWayDelay and oneWayDelayPoissonStream have different OBJECT IDENTITIES. 6. Sect 6 2nd para I do not know why we would name a branch "rfc". The OIDs under RFC are IETF OIDs, and so I would name the branch ietf and not rfc. 7. Sect 6 3rd para Seems that this specifically applies to metrics defined in IPPM sofar. You may want to add a note about that. Or better, I would change The name of the metric in the registry must respect the SMIv2 rules for descriptors ([RFC2578], section 3.1) and should be easily readable. Consequently the following is applied to adapt the name used in the metric definition: + The first letter is forced to lower case; + '-' are removed; + The letter following a '-' is forced to upper case; + 'Type-P' prefix is removed. Into The name of the metric in the registry must respect the SMIv2 rules for descriptors ([RFC2578], section 3.1) and should be easily readable. Consequently the following is applied to adapt the name used in the IPPM WG metric definitions: + The first letter is changed to lower case; + '-' are removed; + The letter following a '-' is changed to upper case; + 'Type-P' prefix is removed. But as I said before, I think I would add to all of them a prefix of ietf. So I would even change it to: + The name always starts with prefix 'ietf' + 'Type-P' prefix is removed. + '-' are removed; + The letter following a '-' is changed to upper case; 8. I am not sure what section 6.1 is. If I understand the word "improbable" correctly, then it means that this does not yet exist and will probably never exists. So it is an example of how new metrics would be added (as per the idea of this internet-draft). I think that that method is wrong, because - it will move the assignments over many documents, - therefor it will be more difficult to ensure that there are no name clashes/conflicts and that assignments are unique - for people who want to use metrics it will be difficult to find them. So I would make it a single IANA maintained MIB module in which the IANA can add new assignments. If you all do agree, then of course the writeup needs to change. Each document that creates new Metrics would have an IANA considerations secrion in which it would request to assign the new metrics. For each metric, that document would have (in IANA Considerations sect) a statement aka: IANA has registed the following Metric in the IANA-IPPM-METRICS-MIB: ietfSomeNewMetricName OBJECT-IDENTITY STATUS current DESCRIPTION "The identifier for the Type-P-Some-New_Metric-Name metric." REFERENCE "RFCxxxx, section n." -- RFC-Editor fills in xxxx ::= { ietf nn } -- IANA assigns nn There is one little concern I have... do we expect the RFCxxxx that contains the metrics to be updated? In any event, such is possible. And in that case, the REFERENCE clause may have to be updated (assuming no semantic change was made to the metric... in which case it would have to be assigned another name anyway, no?). So if the REFERENCE clause then needs to be updated, we should say something about that too in the IANA rules. 9. Sect 6.2 needs to change a bit if you agree with my proposal to have IANA maintain this registry 10. Sect 6.3 I think it is better if assignments are made by IANA and such AFTER approval of a document by the IESG. SO very much similar to the way MIB Modules are assigned a root OID. 11. Sect 6.4 I think "otherBodies" is a bad name. I would call it otherOrganizations Or maybe nonIetfSpecifications 12. Although other organisations can indeed define their metrics in their own OID tree, I would strongly encourage them to register with IANA instead. That way we have one place to find the metrics. We could also add a enterprise branch, under which enterprises can create new names with their enterprise.vendodID (as assigned per IANA already). 13. I think that most of the Informative References (those that point to RFCs that contain metrics that are assigned an OID in this memo) MUST be normative. Because they are the authoritative source of the metric. 14. By the way, if we do use an IANA maintained MIB module, then we MUST describe the rules for assignments in the MODULE-IDENTITY DESSCRIPTION clause, so that IANA always has them handy and so that people who pick up the iana mib module can see it. 15. I would make the Security Considerations MUCH simpler. And spcifically if we follow my suggestion/proposal to make it an IANA maintained MIB module. I would make it something aka: This module does not define any management objects. Instead, it assigns a set of OBJECT-IDENTITIES which may be used by other MIB modules to identify specific IP Performance Metrics. Meaningful security considerations can only be written in the MIB modules that define management objects. This document has therefore no impact on the security of the Internet. 16. In any case, there SHOULD be an IANA considerations section Thanks, Bert _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Thu Apr 29 07:24:03 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 HAA20645 for ; Thu, 29 Apr 2004 07:24:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9Wl-0005IY-8g for ippm-archive@odin.ietf.org; Thu, 29 Apr 2004 07:16:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TBGR0x020366 for ippm-archive@odin.ietf.org; Thu, 29 Apr 2004 07:16:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9Sy-0004DK-5S for ippm-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 07:12:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20284 for ; Thu, 29 Apr 2004 07:12:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ9So-0004ZR-TX for ippm-web-archive@ietf.org; Thu, 29 Apr 2004 07:12:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ9S0-0004MD-00 for ippm-web-archive@ietf.org; Thu, 29 Apr 2004 07:11:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ9R6-00048L-00 for ippm-web-archive@ietf.org; Thu, 29 Apr 2004 07:10:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9C6-00013i-Go; Thu, 29 Apr 2004 06:55:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9AB-0000VS-Ua for ippm@optimus.ietf.org; Thu, 29 Apr 2004 06:53:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19620 for ; Thu, 29 Apr 2004 06:52:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ9A2-000130-Qn for ippm@ietf.org; Thu, 29 Apr 2004 06:52:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ994-0000sK-00 for ippm@ietf.org; Thu, 29 Apr 2004 06:51:59 -0400 Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx with esmtp (Exim 4.12) id 1BJ987-0000Xx-00 for ippm@ietf.org; Thu, 29 Apr 2004 06:51:00 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 5BBAD5DF9C; Thu, 29 Apr 2004 12:50:32 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 798285DF9F for ; Thu, 29 Apr 2004 12:50:31 +0200 (CEST) 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 i3TAoVVt026749 for ; Thu, 29 Apr 2004 12:50:31 +0200 Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i3TAoV7u017086 for ; Thu, 29 Apr 2004 12:50:31 +0200 X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Thu, 29 Apr 2004 12:50:31 +0200 (CEST) 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.003329 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8323d20a2b741b06bf613423a6e469cf Subject: [ippm] OPS-AD evaluation of: draft-ietf-ippm-metrics-registry-05.txt (fwd) Sender: ippm-admin@ietf.org Errors-To: ippm-admin@ietf.org X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IP Performance Metrics Working Group List-Post: List-Help: List-Subscribe: , 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,REMOVE_REMOVAL_NEAR autolearn=no version=2.60 Dear All, We received the attached set of comments on draft-ietf-ippm-metrics-registry-05.txt from Bert Wijnen. Emile is already looking into them, as soon as he has processed them, an 06-draft will be published and the WGLC repeated, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~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). ---------- Forwarded message ---------- Date: Sun, 25 Apr 2004 05:52:49 +0200 From: "Wijnen, Bert (Bert)" [...] Here we go: 1. Abstract s/OBJECT IDENTIFIER/OBJECT-IDENTITY/ I actually would word it differently. SO I would change it from Abstract 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. to something aka: Abstract This memo defines a registry for IP Performance Metrics (IPPM). It assigns and registers an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF. This memo also defines the rules for adding new IP Performance Metrics in the future, both those standardized inside and outside the IETF. IANA has been assigned to administer this new registry. 2. Section 3 currently is a copy of the abstract. Not sure if that is usefull. I would just leave it out. Section 5 (also named overview) seems to be more helpfull. 3. In sect 5, the memo speaks of "MIBs". This should be changed to "MIB modules". I think I have mentioned many times that we have only one single MIB that is composed of multiple MIB modules. This same change needs to be made at multiple places in this document 4. Sect 5. first bullet. I think I would change "clearly" into "clearly and unambiguously" 5. Sect 6, 1st para MIBs need OBJECT INDENTIFIERs to refer precisely to the standardized metrics. The registry associates an OBJECT IDENTIFIER with each metric. As an example oneWayDelay and oneWayDelayPoissonStream have different identifiers. change to something aka: MIB modules need to be able to precisely reference IPPM Metrics. The registry associates an OBJECT-IDENTITY with each metric. As an example oneWayDelay and oneWayDelayPoissonStream have different OBJECT IDENTITIES. 6. Sect 6 2nd para I do not know why we would name a branch "rfc". The OIDs under RFC are IETF OIDs, and so I would name the branch ietf and not rfc. 7. Sect 6 3rd para Seems that this specifically applies to metrics defined in IPPM sofar. You may want to add a note about that. Or better, I would change The name of the metric in the registry must respect the SMIv2 rules for descriptors ([RFC2578], section 3.1) and should be easily readable. Consequently the following is applied to adapt the name used in the metric definition: + The first letter is forced to lower case; + '-' are removed; + The letter following a '-' is forced to upper case; + 'Type-P' prefix is removed. Into The name of the metric in the registry must respect the SMIv2 rules for descriptors ([RFC2578], section 3.1) and should be easily readable. Consequently the following is applied to adapt the name used in the IPPM WG metric definitions: + The first letter is changed to lower case; + '-' are removed; + The letter following a '-' is changed to upper case; + 'Type-P' prefix is removed. But as I said before, I think I would add to all of them a prefix of ietf. So I would even change it to: + The name always starts with prefix 'ietf' + 'Type-P' prefix is removed. + '-' are removed; + The letter following a '-' is changed to upper case; 8. I am not sure what section 6.1 is. If I understand the word "improbable" correctly, then it means that this does not yet exist and will probably never exists. So it is an example of how new metrics would be added (as per the idea of this internet-draft). I think that that method is wrong, because - it will move the assignments over many documents, - therefor it will be more difficult to ensure that there are no name clashes/conflicts and that assignments are unique - for people who want to use metrics it will be difficult to find them. So I would make it a single IANA maintained MIB module in which the IANA can add new assignments. If you all do agree, then of course the writeup needs to change. Each document that creates new Metrics would have an IANA considerations secrion in which it would request to assign the new metrics. For each metric, that document would have (in IANA Considerations sect) a statement aka: IANA has registed the following Metric in the IANA-IPPM-METRICS-MIB: ietfSomeNewMetricName OBJECT-IDENTITY STATUS current DESCRIPTION "The identifier for the Type-P-Some-New_Metric-Name metric." REFERENCE "RFCxxxx, section n." -- RFC-Editor fills in xxxx ::= { ietf nn } -- IANA assigns nn There is one little concern I have... do we expect the RFCxxxx that contains the metrics to be updated? In any event, such is possible. And in that case, the REFERENCE clause may have to be updated (assuming no semantic change was made to the metric... in which case it would have to be assigned another name anyway, no?). So if the REFERENCE clause then needs to be updated, we should say something about that too in the IANA rules. 9. Sect 6.2 needs to change a bit if you agree with my proposal to have IANA maintain this registry 10. Sect 6.3 I think it is better if assignments are made by IANA and such AFTER approval of a document by the IESG. SO very much similar to the way MIB Modules are assigned a root OID. 11. Sect 6.4 I think "otherBodies" is a bad name. I would call it otherOrganizations Or maybe nonIetfSpecifications 12. Although other organisations can indeed define their metrics in their own OID tree, I would strongly encourage them to register with IANA instead. That way we have one place to find the metrics. We could also add a enterprise branch, under which enterprises can create new names with their enterprise.vendodID (as assigned per IANA already). 13. I think that most of the Informative References (those that point to RFCs that contain metrics that are assigned an OID in this memo) MUST be normative. Because they are the authoritative source of the metric. 14. By the way, if we do use an IANA maintained MIB module, then we MUST describe the rules for assignments in the MODULE-IDENTITY DESSCRIPTION clause, so that IANA always has them handy and so that people who pick up the iana mib module can see it. 15. I would make the Security Considerations MUCH simpler. And spcifically if we follow my suggestion/proposal to make it an IANA maintained MIB module. I would make it something aka: This module does not define any management objects. Instead, it assigns a set of OBJECT-IDENTITIES which may be used by other MIB modules to identify specific IP Performance Metrics. Meaningful security considerations can only be written in the MIB modules that define management objects. This document has therefore no impact on the security of the Internet. 16. In any case, there SHOULD be an IANA considerations section Thanks, Bert _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From ippm-admin@ietf.org Fri Apr 30 20:17: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 UAA14862 for ; Fri, 30 Apr 2004 20:17:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi4v-0005sh-O7; Fri, 30 Apr 2004 20:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi0Z-0004sJ-3A for ippm@optimus.ietf.org; Fri, 30 Apr 2004 20:05:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14427 for ; Fri, 30 Apr 2004 20:05:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJi0X-0004bZ-3r for ippm@ietf.org; Fri, 30 Apr 2004 20:05:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJhzZ-0004VI-00 for ippm@ietf.org; Fri, 30 Apr 2004 20:04:30 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BJhyt-0004KP-00; Fri, 30 Apr 2004 20:03:47 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4102HU08861; Fri, 30 Apr 2004 17:02:17 -0700 (PDT) Message-Id: <200405010002.i4102HU08861@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, ippm@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 30 Apr 2004 17:02:17 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-9.0 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Subject: [ippm] RFC 3763 on One-way Active Measurement Protocol (OWAMP) Requirements 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 Request for Comments is now available in online RFC libraries. RFC 3763 Title: One-way Active Measurement Protocol (OWAMP) Requirements Author(s): S. Shalunov, B. Teitelbaum Status: Informational Date: April 2004 Mailbox: shalunov@internet2.edu, ben@internet2.edu Pages: 11 Characters: 23360 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-owdp-reqs-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3763.txt With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. This document is a product of the IP Performance Metrics Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040430170059.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3763 --OtherAccess Content-Type: Message/External-body; name="rfc3763.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040430170059.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm From exim@www1.ietf.org Fri Apr 30 20:25:54 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 UAA15344 for ; Fri, 30 Apr 2004 20:25:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJiGn-00085r-Vq for ippm-archive@odin.ietf.org; Fri, 30 Apr 2004 20:22:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i410MHqT031109 for ippm-archive@odin.ietf.org; Fri, 30 Apr 2004 20:22:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJiD7-0007MX-Ob for ippm-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 20:18:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14925 for ; Fri, 30 Apr 2004 20:18:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJiD5-0005rJ-Pv for ippm-web-archive@ietf.org; Fri, 30 Apr 2004 20:18:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJiCA-0005ln-00 for ippm-web-archive@ietf.org; Fri, 30 Apr 2004 20:17:31 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJiBe-0005gO-00 for ippm-web-archive@ietf.org; Fri, 30 Apr 2004 20:16:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi4v-0005sh-O7; Fri, 30 Apr 2004 20:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJi0Z-0004sJ-3A for ippm@optimus.ietf.org; Fri, 30 Apr 2004 20:05:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14427 for ; Fri, 30 Apr 2004 20:05:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJi0X-0004bZ-3r for ippm@ietf.org; Fri, 30 Apr 2004 20:05:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJhzZ-0004VI-00 for ippm@ietf.org; Fri, 30 Apr 2004 20:04:30 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BJhyt-0004KP-00; Fri, 30 Apr 2004 20:03:47 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4102HU08861; Fri, 30 Apr 2004 17:02:17 -0700 (PDT) Message-Id: <200405010002.i4102HU08861@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, ippm@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 30 Apr 2004 17:02:17 -0700 X-ISI-4-28-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Subject: [ippm] RFC 3763 on One-way Active Measurement Protocol (OWAMP) Requirements 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=-1.6 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3763 Title: One-way Active Measurement Protocol (OWAMP) Requirements Author(s): S. Shalunov, B. Teitelbaum Status: Informational Date: April 2004 Mailbox: shalunov@internet2.edu, ben@internet2.edu Pages: 11 Characters: 23360 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ippm-owdp-reqs-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3763.txt With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol (OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. This document is a product of the IP Performance Metrics Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040430170059.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3763 --OtherAccess Content-Type: Message/External-body; name="rfc3763.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040430170059.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@ietf.org https://www1.ietf.org/mailman/listinfo/ippm