Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBU7hBut025962 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 30 Dec 2007 08:43:19 +0100 X-IronPort-AV: E=Sophos;i="4.24,222,1196658000"; d="scan'208";a="89305130" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 30 Dec 2007 02:43:05 -0500 X-IronPort-AV: E=Sophos;i="4.24,222,1196658000"; d="scan'208";a="145265774" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Dec 2007 02:43:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt Date: Sun, 30 Dec 2007 08:43:03 +0100 Message-ID: In-Reply-To: <20071228220724.GA29009@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt Thread-Index: AchJni8DxUC+5PI1TDiZ18DWIEwiwQBGVYuA References: <20071228220724.GA29009@elstar.local> From: "Romascanu, Dan (Dan)" To: , X-IBRFilter-SpamReport: -1.951 () BAYES_20 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id lBU7hBut025962 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2007 07:43:27 -0000 I am not sure if I ack-ed previously but this version is OK with me. Dan > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Juergen > Schoenwaelder > Sent: Saturday, December 29, 2007 12:07 AM > To: nmrg@ibr.cs.tu-bs.de > Subject: Re: [nmrg] NMRF Last Call for > draft-irtf-nmrg-snmp-measure-02.txt > > On Fri, Dec 07, 2007 at 06:51:15PM +0100, WIJNEN, Bert (Bert) wrote: > > > Pls check if your comments have been addressed properly. > > If not, pls let us know asap, preferably before 22 Dec 2007. > > If no negative comments/objections are received by that > date, then we > > will go forward and ask for the IRSG review and further > steps towards > > publication as RFC. > > It would be nice to get some more "green light" that the > changes that have been made address the comments received as > part of the first last call. Here again the URL: > > http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measu > re-02.txt > > A HTML version with links to a colored diff is here: > > http://tools.ietf.org/html/draft-irtf-nmrg-snmp-measure-02 > > I have meanwhile implemented the format changes in snmpdump > (SVN revision 2403) - but I still have to update the test cases. > > Have a good start into 2008! > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To > unsubscribe or adjust !! your settings, send a mail message > to !! or look at > https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBSM7UpL015502 for ; Fri, 28 Dec 2007 23:07:35 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 786348A1DE for ; Fri, 28 Dec 2007 23:07:30 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 17423-02; Fri, 28 Dec 2007 23:07:25 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E24118A1CD; Fri, 28 Dec 2007 23:07:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A1F9244FF45; Fri, 28 Dec 2007 23:07:24 +0100 (CET) Date: Fri, 28 Dec 2007 23:07:24 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt Message-ID: <20071228220724.GA29009@elstar.local> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: -2.599 () BAYES_00 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 22:07:39 -0000 On Fri, Dec 07, 2007 at 06:51:15PM +0100, WIJNEN, Bert (Bert) wrote: > Pls check if your comments have been addressed properly. > If not, pls let us know asap, preferably before 22 Dec 2007. > If no negative comments/objections are received by that date, > then we will go forward and ask for the IRSG review and > further steps towards publication as RFC. It would be nice to get some more "green light" that the changes that have been made address the comments received as part of the first last call. Here again the URL: http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt A HTML version with links to a colored diff is here: http://tools.ietf.org/html/draft-irtf-nmrg-snmp-measure-02 I have meanwhile implemented the format changes in snmpdump (SVN revision 2403) - but I still have to update the test cases. Have a good start into 2008! /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBAL2VG5020308 for ; Mon, 10 Dec 2007 22:02:36 +0100 X-IronPort-AV: E=Sophos;i="4.24,148,1196658000"; d="scan'208";a="84786387" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 10 Dec 2007 16:02:22 -0500 X-IronPort-AV: E=Sophos;i="4.24,148,1196658000"; d="scan'208";a="139514245" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Dec 2007 16:02:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt Date: Mon, 10 Dec 2007 22:02:20 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt Thread-Index: Acg49VkRZsCcJRLEQmqeRdPjlgRKwAAA8f2AAJ2xjGA= References: From: "Romascanu, Dan (Dan)" To: "WIJNEN, Bert (Bert)" , X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id lBAL2VG5020308 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 21:02:41 -0000 The changes are fine with me. Thank you for addressing my comments. Dan > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of WIJNEN, Bert (Bert) > Sent: Friday, December 07, 2007 7:51 PM > To: nmrg@ibr.cs.tu-bs.de > Cc: Aaron Falk > Subject: [nmrg] NMRF Last Call for > draft-irtf-nmrg-snmp-measure-02.txt > > Dear NMRG participants. > > This is a new version in which Juergen has tried to address > all comments we received on revision 01. He also posted > answers to the comments to the nmrg mailing list. > > Pls check if your comments have been addressed properly. > If not, pls let us know asap, preferably before 22 Dec 2007. > If no negative comments/objections are received by that date, > then we will go forward and ask for the IRSG review and > further steps towards publication as RFC. > > Bert Wijnen > shepherd for this document > > > -----Original Message----- > > From: nmrg-bounces@ibr.cs.tu-bs.de > > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Friday, December 07, 2007 9:10 AM > > To: i-d-announce@ietf.org > > Subject: [nmrg] I-D Action:draft-irtf-nmrg-snmp-measure-02.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : SNMP Traffic Measurements and Trace > > Exchange Formats > > Author(s) : J. Schoenwaelder > > Filename : draft-irtf-nmrg-snmp-measure-02.txt > > Pages : 28 > > Date : 2007-12-07 > > > > The Simple Network Management Protocol (SNMP) is widely deployed to > > monitor, control and (sometimes also) configure network elements. > > Even though the SNMP technology is well documented, it remains > > relatively unclear how SNMP is used in practice and what > typical SNMP > > usage patterns are. > > > > This document proposes to carry out large scale SNMP traffic > > measurements in order to develop a better understanding how SNMP is > > used in real world production networks. It describes the > motivation, > > the measurement approach, and the tools and data formats needed to > > carry out such a study. > > > > This document was produced within the IRTF's Network Management > > Research Group (NMRG) and represents the consensus of all of the > > active contributors to this group. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measu > > re-02.txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > > the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > 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-irtf-nmrg-snmp-measure-02.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-irtf-nmrg-snmp-measure-02.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. > > > > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To > unsubscribe or adjust !! your settings, send a mail message > to !! or look at > https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB7HprOq020584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Dec 2007 18:51:59 +0100 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lB7HplP2012831; Fri, 7 Dec 2007 11:51:49 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:51:23 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.26]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 18:51:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 7 Dec 2007 18:51:15 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt Thread-Index: Acg49VkRZsCcJRLEQmqeRdPjlgRKwAAA8f2A References: From: "WIJNEN, Bert \(Bert\)" To: X-OriginalArrivalTime: 07 Dec 2007 17:51:21.0589 (UTC) FILETIME=[C6F31250:01C838F9] X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-IBRFilter-SpamReport: 0.001 () BAYES_50 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id lB7HprOq020584 Cc: Aaron Falk Subject: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 17:52:01 -0000 Dear NMRG participants. This is a new version in which Juergen has tried to address all comments we received on revision 01. He also posted answers to the comments to the nmrg mailing list. Pls check if your comments have been addressed properly. If not, pls let us know asap, preferably before 22 Dec 2007. If no negative comments/objections are received by that date, then we will go forward and ask for the IRSG review and further steps towards publication as RFC. Bert Wijnen shepherd for this document > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of > Internet-Drafts@ietf.org > Sent: Friday, December 07, 2007 9:10 AM > To: i-d-announce@ietf.org > Subject: [nmrg] I-D Action:draft-irtf-nmrg-snmp-measure-02.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : SNMP Traffic Measurements and Trace > Exchange Formats > Author(s) : J. Schoenwaelder > Filename : draft-irtf-nmrg-snmp-measure-02.txt > Pages : 28 > Date : 2007-12-07 > > The Simple Network Management Protocol (SNMP) is widely > deployed to monitor, control and (sometimes also) configure > network elements. > Even though the SNMP technology is well documented, it > remains relatively unclear how SNMP is used in practice and > what typical SNMP usage patterns are. > > This document proposes to carry out large scale SNMP traffic > measurements in order to develop a better understanding how > SNMP is used in real world production networks. It describes > the motivation, the measurement approach, and the tools and > data formats needed to carry out such a study. > > This document was produced within the IRTF's Network > Management Research Group (NMRG) and represents the consensus > of all of the active contributors to this group. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measu > re-02.txt > > To remove yourself from the I-D Announcement list, send a > message to i-d-announce-request@ietf.org with the word > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-irtf-nmrg-snmp-measure-02.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-irtf-nmrg-snmp-measure-02.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. > Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB7HJ5d1017255 for ; Fri, 7 Dec 2007 18:19:10 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EB208A118 for ; Fri, 7 Dec 2007 18:19:05 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 06136-03 for ; Fri, 7 Dec 2007 18:19:02 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02DEB84AE7 for ; Fri, 7 Dec 2007 18:19:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1906F41BFD2; Fri, 7 Dec 2007 18:19:02 +0100 (CET) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Fri, 7 Dec 2007 18:19:01 +0100 Resent-Message-ID: <20071207171901.GB11932@elstar.local> Resent-To: nmrg@ibr.cs.tu-bs.de Received: from merkur.jacobs-university.de ([unix socket]) by merkur (Cyrus v2.2.13) with LMTPA; Fri, 07 Dec 2007 18:15:27 +0100 X-Sieve: CMU Sieve 2.2 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by merkur.jacobs-university.de (Postfix) with ESMTP id A1DE827579 for ; Fri, 7 Dec 2007 18:15:27 +0100 (CET) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C17559747 for ; Fri, 7 Dec 2007 18:15:27 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 05754-04 for ; Fri, 7 Dec 2007 18:15:23 +0100 (CET) Received: from megatron.ietf.org (odin.ietf.ORG [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTP id BF4BF84AE7 for ; Fri, 7 Dec 2007 18:15:22 +0100 (CET) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0giE-0005x9-H8; Fri, 07 Dec 2007 12:10:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0giA-0005wv-HA for i-d-announce@ietf.org; Fri, 07 Dec 2007 12:10:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0giA-0002DY-45 for i-d-announce@ietf.org; Fri, 07 Dec 2007 12:10:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 08C9526E7E for ; Fri, 7 Dec 2007 17:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J0gi9-00020z-UM for i-d-announce@ietf.org; Fri, 07 Dec 2007 12:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 07 Dec 2007 12:10:01 -0500 X-Spam-Score: -0.6 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Errors-To: i-d-announce-bounces@ietf.org X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Status: No, score=-1.092 tagged_above=-100 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, NO_REAL_NAME=0.961, SARE_SUB_RAND_LETTRS4=0.799] X-Spam-Score: -1.092 X-Spam-Level: X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.008 () BAYES_50,MIME_BOUND_NEXTPART,NO_REAL_NAME X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] I-D Action:draft-irtf-nmrg-snmp-measure-02.txt X-BeenThere: nmrg@ibr.cs.tu-bs.de Reply-To: internet-drafts@ietf.org List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 17:19:14 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SNMP Traffic Measurements and Trace Exchange Formats Author(s) : J. Schoenwaelder Filename : draft-irtf-nmrg-snmp-measure-02.txt Pages : 28 Date : 2007-12-07 The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are. This document proposes to carry out large scale SNMP traffic measurements in order to develop a better understanding how SNMP is used in real world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study. This document was produced within the IRTF's Network Management Research Group (NMRG) and represents the consensus of all of the active contributors to this group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-irtf-nmrg-snmp-measure-02.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-irtf-nmrg-snmp-measure-02.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: <2007-12-07120012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-irtf-nmrg-snmp-measure-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-07120012.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB7FVffJ002202 for ; Fri, 7 Dec 2007 16:31:46 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F62F863F0; Fri, 7 Dec 2007 16:31:41 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28688-05-3; Fri, 7 Dec 2007 16:31:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5A3A8A175; Fri, 7 Dec 2007 16:31:29 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DAE5841B956; Fri, 7 Dec 2007 16:31:29 +0100 (CET) Date: Fri, 7 Dec 2007 16:31:29 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC Message-ID: <20071207153129.GH11352@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , nmrg@ibr.cs.tu-bs.de, "Wijnen, Bert (Bert)" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de, "Wijnen, Bert \(Bert\)" X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 15:31:48 -0000 On Thu, Feb 15, 2007 at 01:41:06PM +0200, Romascanu, Dan (Dan) wrote: > > Please find below my comments: > > 1. Section 1 : > > 'it is not clear which features are being used, > how SNMP usage differs in different types of networks or > organizations ...' > > I suggest to add to the list or begin the list with 'what protocol > versions are being used' changed > 2. same: > > This phrase is not clear to me: > > 'Furthermore, we do not generally > understand how much traffic is devoted to standardized MIB objects > and how much traffic deals with proprietary MIB objects and whether > the operation mix differs between these object classes or between > different operational environments.' > > Maybe it is meant to say? > > 'Furthermore, we do not generally > understand how much traffic is devoted to standardized MIB objects > and how much traffic deals with proprietary MIB objects and whether > the operation mix between these object classes differs in various > operational environments.' changed > It would also be useful to clarify what these operation environments > are. Do we mean carriers, or IP service providers vs. enterprise > networks? I now have: [...] Furthermore, we do not generally understand how much traffic is devoted to standardized MIB objects and how much traffic deals with proprietary MIB objects and whether the operation mix between these object classes differs between different operational environments (e.g., backbone networks, access networks, enterprise networks). > 3. Section 2: > > Explain what are 'pcap capture files'. Maybe a terminology and > abbreviations section would help. I already added a reference. > 4. Section 2.1: > > The concept of ' stable storage (e.g., compressed and encrypted on a CD > ROM or DVD).' Was 'stable' related to 'permanent'? Compression and > encryption should be dealt separately, and if there is a need to protect > privacy which seems to be the case this needs to be mentioned in the > Security Considerations section. replaced 'stable' with 'permanent' and added a sentence to the security considerations: In addition, it is recommended to encrypt traces when they are archived. > 5. Section 3.1: > > PDU-type distribution and error messages frequency should be added to > the list of basic statistics added > 6. Some place in Section 3, maybe in 3.1 I would add statistics related > to the used of privacy protection mode, i.e. how much of the traffic is > protected by using encrypted payload. Note that if priv is used many of > other measurements may not be possible. added > 7. Section 3.4: > > The concept of 'concurrency level' is not clear to me. What is the goal > and the metric here? To determine to how many agents a management > application is working simultaneously or in a given time window? Why is > this important? I think it is reasonable to ask the question whether management stations distribute the workload fairly over a time window and over the number of devices they talk to. > 8. Section 3.5: > > The use of the term 'cell-by-cell' when referring to tables is > inconsistent with the SMI terminology changed to 'object-by-object' /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB7FDQu0031188 for ; Fri, 7 Dec 2007 16:13:31 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60D988A118; Fri, 7 Dec 2007 16:13:26 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27078-03-8; Fri, 7 Dec 2007 16:13:21 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F33808A175; Fri, 7 Dec 2007 16:13:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 15D0141B8ED; Fri, 7 Dec 2007 16:13:16 +0100 (CET) Date: Fri, 7 Dec 2007 16:13:15 +0100 From: Juergen Schoenwaelder To: Luca Deri Subject: Re: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC Message-ID: <20071207151315.GG11352@elstar.local> Mail-Followup-To: Luca Deri , nmrg@ibr.cs.tu-bs.de, "Wijnen, Bert ((Bert))" References: <153A5907-3E2A-44EE-B3C3-CE74AA59C420@ntop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153A5907-3E2A-44EE-B3C3-CE74AA59C420@ntop.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de, "Wijnen, Bert \(\(Bert\)\)" X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 15:13:33 -0000 On Fri, Feb 16, 2007 at 11:45:56PM +0100, Luca Deri wrote: > - I think that the use of XML and CSV are two opposites. XML is > quite thick (an SNMP PDU converted to XML takes definitively more > space), it requires some knowledge, and I don't think is the best > format for creating statistics as those described in chapter 3. On > the other hand the CSV format, as specified in 4.2, needs further > specification work as two CSV files for the same .pcap file can look > very different even if they both adhere to 4.2. If both XML and CSV > have limitations, I'm asking myself if pcap-based API (such as those > offered by snmpdump) plus anonymized .pcap isn't a more flexible > solution The reason we do not use plain pcap is that parsing BER and doing things like packet reassembly is not much fun. It is really convenient to do this once and then code further analysis programs from a much simpler input format. I do not see that two CSV files produced from the same .pcap file can look different, unless you apply anonyzation or filtering. No change made. > - the author should further specify what filtering means. Is it > close to that tools like wireshark offer (you can filter on each > PDU-decoded field) or is something different? This is kind of implementation dependent. Our snmpdump tool can filter out whole messages using pcap expressions and it can filter out values based on protocol fields. I don't think we need to "standardize" on how tools work. We aim at interoperability of the exchange format, not the tools. No change made. > - chapter 5 should be expanded; I would like to read some examples > of anonymization beside some basic IP/community (e.g. field name, > example of anonymized values) and also better understand what > "anonymization transformations" are in practice. I have added some more references for the interested readers. Note that I do not want this document to become a tool specification; it aims at being an interchange format specification and a motivation for doing this work. Partially already addressed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB7Cw6n7010769 for ; Fri, 7 Dec 2007 13:58:11 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B2B78A118; Fri, 7 Dec 2007 13:58:06 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 10411-04-4; Fri, 7 Dec 2007 13:58:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 729118A15E; Fri, 7 Dec 2007 13:57:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0B9BF41B548; Fri, 7 Dec 2007 13:57:54 +0100 (CET) Date: Fri, 7 Dec 2007 13:57:54 +0100 From: Juergen Schoenwaelder To: "Medhi, Deep" Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC Message-ID: <20071207125754.GE11352@elstar.local> Mail-Followup-To: "Medhi, Deep" , nmrg@ibr.cs.tu-bs.de References: <032EC4F75A527A4FA58C5B1B5DECFBB30254F589@KC-MSX1.kc.umkc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <032EC4F75A527A4FA58C5B1B5DECFBB30254F589@KC-MSX1.kc.umkc.edu> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 12:58:13 -0000 On Sat, Feb 17, 2007 at 12:39:15AM -0600, Medhi, Deep wrote: > Overall, this is a good document. Here are my comments: > > 1. I noticed some disconnect between the abstract and the rest of the > document. "SNMP usage patterns" in the abstract conveys the notion of > frequency or how often it is used---however, that's not what is conveyed > in the rest of the document. I found the last paragraph of Introduction > (that starts with "This document describes ...") to be a better > representative of the content of the document -- thus, some sentences or > rewording from this paragraph should be included in the abstract, > instead. The first paragraph of the abstract sets the stage and provides motivation - and yes the motivation is to understand SNMP usage patterns. The second paragraph clearly states what the contribution of this document is and I think it is quite clear and on target. So I am not sure what needs to be changed. You perhaps have a narrower interpretation of the word "pattern" but I did not really find a better word. So no change made. > 2. Some "measure" about how much the raw data might get enlarged to > when XML is used should be given. This assessment can be provided > for a typical MIB a user is likely to collect. It is difficult to put down such numbers since you can always debate them. See also below. > 3. An example entry, each for XML and for CSV, should be included. > Although, this may look redundant for CSV, because of the each field > described, this is still helpful. For example, it would look like > > Fro IPv4, > > 1137764769.425484,127.0.0.1,4242, ... > > For IPv6, > > 1137764769.425484,::1,4242, ... This is a very good idea. I have added examples for both the XML and CSV representation. > 4. Collected data for different MIBs and environments (e.g., core > network, or enterprise network) could be quite in different size, which > would also depend on how often data is collected. Is it possible to give > some idea about how "big" the size of data collected for an example > scenario? So far, it only talks about collecting data for a week. This is related to your comment above. You can find some information in our IM 2007 paper and I think this is where it belongs since we discuss concrete traces there. > 5. Preferential format to store data might be quite different for > different environments and needs. For example, a core network provider > is more likely to use CSV. Thus, some guideline on where one might be > appropriate over the other would be good to discuss. Hm. There are many factors that go in choosing a format and some are clearly non-technical. I would rather not add such a discussion unless someone provides suitable text to include. > 6. Below are a couple of more references on IP address anonymization: > > Jinliang Fan, Jun Xu, Mostafa H. Ammar, Sue B. Moon: Prefix-preserving > IP address anonymization: measurement-based security evaluation and a > new cryptography-based scheme. Computer Networks 46(2): 253-272 (2004) > > Jun Xu, Jinliang Fan, Mostafa Ammar, Sue Moon, "Prefix-Preserving IP > Address Anonymization", Proceedings of the IEEE International Conference > on Network Protocols, 2002. I have added several references to related anonymization work since many people seem to find this useful information. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB7BmgVv000751 for ; Fri, 7 Dec 2007 12:48:47 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 278038A18D; Fri, 7 Dec 2007 12:48:42 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02741-04; Fri, 7 Dec 2007 12:48:37 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFF578652C; Fri, 7 Dec 2007 12:48:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 13CF441B351; Fri, 7 Dec 2007 12:48:37 +0100 (CET) Date: Fri, 7 Dec 2007 12:48:36 +0100 From: Juergen Schoenwaelder To: "David T. Perkins" Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC Message-ID: <20071207114836.GD11352@elstar.local> Mail-Followup-To: "David T. Perkins" , nmrg@ibr.cs.tu-bs.de References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 11:48:49 -0000 On Tue, Feb 13, 2007 at 03:03:41PM -0800, David T. Perkins wrote: > I re-read the doc. It is technically Ok except for the data types > of values specified in section 4.1 and 4.2. First, section 4.2 > is missing opaque found in section 4.1. Secondly, both are missing > data type "netAddr". Third, I believe that mapping types counter32, > gauge32, and timeticks to unsigned32 loses info and should not > be done. Also, counter64 should not be mapped to unsigned 64. The data types have been aligned to match SNMP. I did not add "netAddr" since something like that does not exist on the wire. > Note a wonder what is done if a ASN.1 type that is not defined > in SNMP (or was specified in an obsolete version of SNMP) is > used. How is the type specified. It's not incorrect, but I > suggest that type "ipaddress" be renamed to "ipv4address". We decided in Prague to stick with the SNMP/SMI names for types and PDUs. > Section 4.2 describes encoding of IPv6 address values. However, > there is no ipv6addr type, and thus, this description is > describing a value that will never exist, and is misleading. The IPv6 addresses can exist in the src/dst address of the UDP datagram carrying an SNMP message and this is why we need them. You are right that the definitions don't affect the SNMP payload. > Suggestions for additions: > 1) section 2 has the measurement approach. I'd like to hope > that it include a step for annotations (which is called > adding meta data later in the document). That is, put > in an explicit step such as "at 20070213 12:02:01 started > configuration app to add new DSL service" and "at 20070213 > 12:05:45 finished configuration operation". Or > "at 20070213 02:09:56 link down occured on dtp45:p2" and > "at 20070213 02:11:01 link up occured on dtp45:p2". There is now this text: For each captured trace, some meta data should be recorded and made available. The meta data should include information such as where the trace was collected, when it was collected, contact information, the size of the trace, any known special events, equipment failures, or major infrastructure changes during the data collection period and so on. I think this addresses your point. > 2) Add additional examples in last para of section 2.1 Not sure what is missing - no change made. > 3) Add a section, such as 2.2, about suggesting the creation > of test (or baseline) traces that are artificial and > are used to demonstrate a behavior (such as retrieving > a table a cell at a time in column order, showing > all data types, or a wide range of packet size > distribution.) I believe this is tool implementation specific or general good software development practice to have test cases. No change made. > 4) I'd like to see 2 formats for "object names". The > first just splits the OID of the object type from > the OID fragment encoding the instance specification. > The second additionally decodes the OID fragment > into values. For example, instead of just > 1.2.3.4.5.6.1.2.3.4.3.44.54.50, > format #1 would be > 1.2.3.4.5.6$1.2.3.4.3.44.54.50 > format #2 would be > 1.2.3.4.5.6[ipv4:1.2.3.4][vstr:3:"DTP"] > And of course, to do the above, you need the > object type definition info from MIB modules, > and you have to deal with instance encoding > bugs. So far, the conversion process does not require MIB information and I like to keep it that way. I also prefer to have a single simple representation rather than having to deal with different formats when I process a trace. What you are suggesting clearly is useful since nobody is really able to read OIDs. So I created a tool smixlate (part of libsmi) which is like cat but looks for character sequences that look like OIDs. If it finds a string that looks like an OID, it translates it into something human friendly. Having such a standalone tool is actually great for many purposes (I sometimes just cut'n'paste OIDs into it which is faster than grepping around.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB7B9ToB028951 for ; Fri, 7 Dec 2007 12:09:34 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2BFE8A0DB; Fri, 7 Dec 2007 12:09:29 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30136-02-36; Fri, 7 Dec 2007 12:09:24 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A4A6E86632; Fri, 7 Dec 2007 12:09:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BB83841B200; Fri, 7 Dec 2007 12:09:24 +0100 (CET) Date: Fri, 7 Dec 2007 12:09:24 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20071207110924.GB11352@elstar.local> Mail-Followup-To: Wes Hardaker , "Wijnen, Bert (Bert)" , nmrg@ibr.cs.tu-bs.de References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de, "Wijnen, Bert \(Bert\)" Subject: [nmrg] Re: nmrgNMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 11:09:37 -0000 On Mon, Feb 12, 2007 at 05:39:09PM -0800, Wes Hardaker wrote: > - ethereal -> wireshark [wireshark is the new name for the ethereal project] changed > - I don't think the document should be recommending one software > package over another for dealing with XML, etc. For example, in > perl it is repeatedly recommended to use the XML::libXML parser. > That parser is a very good one, but is designed for the XML (DOM) > knowledgeable coder and I wouldn't be surprised if a large part of > the target audience may not be that familiar with proper DOM APIs > (yes, I know it has others too). XML::Simple, on the other hand, is > very popular as well because it pulls in XML data into structures > that perl coders understand: perl structures. Instead, why not > reference a web page that describes how to choose a parser? > http://perl-xml.sourceforge.net/faq/ is probably the best place for > perl programmers to go. In short, people should use XML code bases > not on the recommendation of the author, but rather based on the > needs of the programmer. Sure. The perl-xml site is great. I have reworded the text fragments into the following: Filtering sensitive data can be achieved by manipulating the XML representation of an SNMP trace. Standard XSLT processors (e.g., xsltproc [6]) can be used for this purpose. People familiar with the scripting language Perl might be interested in choosing a suitable Perl module to manipulate XML documents [7]. [...] However, in order to facilitate a common vocabulary and to allow operators to easily read scripts they execute on trace files, it is suggested that analysis scripts are written in scripting languages such as Perl using suitable Perl modules to manipulate XML documents [7]. [6] [7] > - I didn't see any statements (but again, it was a quick scan) about > being careful about drawing conclusions based on a limited amount of > data but I'd be tempted to insert something like that. Also, having > operators document how their network was behaving during the period > is probably a good idea. IE, if there was major network > infrastructure changes going on but still no SNMP SET data was seen > that gives a much better chance of detecting that SETs aren't in use > than if it was a quiet week where no changes were being made to the > network. IE, you need to know something about the environment > you're monitoring to get a good feel for what type of data you can > expect to be able to see. Were there problems? Were changes being > made?... The relevant text at the end of section 2.1 now reads as follows: For each captured trace, some meta data should be recorded and made available. The meta data should include information such as where the trace was collected, when it was collected, contact information, the size of the trace, any known special events, equipment failures, or major infrastructure changes during the data collection period and so on. I addition, I added the following to section 2.5: I should be noted that any results produced by analyzing a trace must be interpreted in the context of the trace. The nature of the network, the attachment point used to collect the trace, or the events that happened while the trace was collected clearly influence the result. It is therefore important to be careful with drawing general conclusions based on a potentially limited data set. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB7AkufN026633 for ; Fri, 7 Dec 2007 11:47:01 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98CB78A1B5; Fri, 7 Dec 2007 11:46:56 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27478-02-6; Fri, 7 Dec 2007 11:46:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B74548A1D5; Fri, 7 Dec 2007 11:45:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CF3D141B166; Fri, 7 Dec 2007 11:45:27 +0100 (CET) Date: Fri, 7 Dec 2007 11:45:27 +0100 From: Juergen Schoenwaelder To: Giorgio Nunzi Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC Message-ID: <20071207104527.GA11352@elstar.local> Mail-Followup-To: Giorgio Nunzi , nmrg@ibr.cs.tu-bs.de References: <113091BD57179D4491C19DA7E10CD696AB366C@mx1.office> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <113091BD57179D4491C19DA7E10CD696AB366C@mx1.office> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 10:47:03 -0000 On Fri, Feb 09, 2007 at 11:43:07AM +0100, Giorgio Nunzi wrote: > - Motivations (contained in par.1): the document mentions only the > importance for the research community. I would expect that > providers can benefit from SNMP measurements too, because they can > improve their management processes and scripts. In other words, > providers can use management traffic statistics in the same way > they are already using data traffic statistics. I have added another paragraph to the introduction to make this clearer: While the SNMP trace collection and analysis effort was initiated by the research community, it should be noted that network operators can benefit from the SNMP measurements too. Several new tools are being developed as part of this effort that can be used to capture and analyze the traffic generated by management stations. This resulting information can then be used to improve the efficiency and scalability of management systems. > - Permanent store of raw traces. The document strongly suggests to > store raw traces (i.e. those without anonymization filtering), but > I think that this might require an additional effort to providers > (e.g. raw traces should be store securely and in a different place > than the anonymized traces). I understand that raw traces can be > used again if the scripts makes somehow wrong transformation > (i.e. they contains some bugs). However I think that in this > (unlucky) case we should simply trash the bad traces, fix the > scripts and take new fresh traces. Frank had similar opinion on > this. I added text to address this, see my response to Frank's review. > Finally, a small suggestion: can't we upload a complete W3C XML > schema somewhere (e.g. NMRG web page)? This would make the work > accessible to more people, if possible. I will see whether I can put things up somewhere. Right now, the sources of the ID are contained in the subversion system of the snmpdump package. I have checked the trang XSD conversion into the subversion system so we have everything in one place. https://trac.eecs.iu-bremen.de/projects/snmpdump/browser/trunk/doc /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB78aYaW012676; Fri, 7 Dec 2007 09:36:39 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 501268A195; Fri, 7 Dec 2007 09:36:34 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13984-08; Fri, 7 Dec 2007 09:36:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E2518A143; Fri, 7 Dec 2007 09:36:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 112CC41AF13; Fri, 7 Dec 2007 09:36:27 +0100 (CET) Date: Fri, 7 Dec 2007 09:36:27 +0100 From: Juergen Schoenwaelder To: Frank Strau? Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC Message-ID: <20071207083627.GA11147@elstar.local> Mail-Followup-To: Frank Strau? , nmrg@ibr.cs.tu-bs.de References: <45C0B90F.1040403@ibr.cs.tu-bs.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45C0B90F.1040403@ibr.cs.tu-bs.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 08:36:42 -0000 On Wed, Jan 31, 2007 at 04:43:11PM +0100, Frank Strau? wrote: > I have read the document and came up with the following comments: > > - General: > > What about a glossary to introduce a few common terms for the > entities and processing steps? I would love to see a figure that > shows these entities and steps with their relationships and the > levels of concrete/anonymized/meta data. This could especially help > to make clear in which spheres anonymized and non-anonymized data > could reside. (I still have my problems with this question.) Since there is no concrete proposal and I do not understand what is missing, I have not made any specific changes. > - Section 1, 2nd paragraph > > It looks a bit unfair to state that the mentioned performance > related publications are based on speculations about SNMP > performance. I propose to rephrase the last sentence to something > like: "In fact, there are many speculations how SNMP is being used > in real world production networks and performance comparisons are > based on limited test cases, but no systematic wide-range > measurements have been performed and published so far." changed > - Section 2.1, 1st paragraph > > You should probably also write a few words about the (unlikely) case > of fragmented packets. Section 2.2 talks about reassembly and I think this is where this belongs since you can't change anything when you capture packets. > - Section 2.1, concerning port monitoring > > In practice, such monitoring ports cannot always be configured this > way. E.g., our (relatively new) Nortel switches allow a monitoring > port only to monitor no more than two other ports or up to two MAC > addresses on any port. I have no experience with other vendors, but > I guess it is a general question of available CPU and bandwidth > resources on a device's management plane. I added: [...] Some bridges have restrictions concerning their monitoring capabilities and this should be investigated and documented where necessary. > - Section 2.1, 3rd paragraph concerning h/w checksum offloading > > Why do you suggest to turn offloading off? In my opinion, wrong > checksums in traces don't hurt. A short note, so that people don't > wonder about wrong checksums should be enough. The text now says: Several operating systems can offload some of the TCP/IP processing such as the calculation of transport layer checksum to network interface cards. Traces that include traffic to/from a capturing interface which supports TCP/IP offloading can include incorrect transport layer checksums. The simplest solution is of course to turn checksum offloading off while capturing traces (if that is feasible without loosing too many packets). The other solution is to correct or ignore checksums during the subsequent analysis of the raw pcap files. I think this covers both approaches (turning offloading off or correcting/ignoring checksums after the trace has been captured). > - Section 2.1, 4th paragraph concerning pcap backups/archives > > Hm. I don't like this paragraph. Software should be "mature enough" > before you ask people to use it. At least, integrety and correctness > of data at steps 4+5 should remain the responsibilty of the party > who would like to collect the measurements. The party capturing raw traces may choose to run software to provide anonymized or stripped data to researchers. And software can have bugs or it is simply applied in a way that later turns out to be problematic (e.g. stripping data that would have been useful to keep). We have seen this already happening and it was really useful to be able to go back to the original traces. So I am keeping the text. > - Section 2.2, 1st paragraph > > Pcap files *are* machine readable. Porposal: "...that are human > readable while remaining also machine readable for ..." changed > - Section 2.2, 2nd paragraph > > s/a [OASISRNG] schema/a RELAX NG schema [OASISRNG] fixed > - Section 2.2, 4th paragraph concerning h/w checksum offloading again > > I suggest to make checksum error ignorance mandatory. See another > comment above. Are you sure that pcap files recorded with a tool > like tcpdump and with the aforementioned filter expression contain > IP fragments at all? I didn't check it. Changed should to must. And yes, tcpdump captures fragments (and our snmpdump tool reassembles them). > - Section 2.2, last paragraph concerning XML and CSV formats > > So snmpdump cannot read CSV and creating CSV is one-way? Maybe, it's > worth to state this explicitly. Furthermore, I would prefer to > decide for one format. That would make data handling, script > authoring, etc. much easier. At the time this text was written, snmpdump did not read CSV format. This has been changed some time ago and so I have updated the text. > - Section 2.3, 1st paragraph concerning Perl > > The Perl community names it "modules" instead of "packages", > AFAIK. If you decide to change it, also grep for subsequent > occurances of the word "package". fixed > - Section 2.3, 2nd paragraph concerning anonymization retaining lexi-order > > It would be fine to have this feature mature enough so that this is > no longer work in progress when the document is ready to become an > Informational RFC. Maybe it already is, since HS06 was published in > April 2006? However, the goal seems to be non-trivial to me, > especially when you want to be able to merge traces, right? > > I'm generally missing more information about anonymization. Which > pieces of information can or should be anonymized? Wouldn't it be > meaningful to add a flag to the schema to signal which pieces have > actually been anonymized? Should a value A that has been anonymized > to value B be anonymized to B again in subsequent occurances? If > yes, how could this mapping be maintained for merged traces? I think > there are quite some interesting questions. :-) I added some additional text: [...] Note that anonymization transformations are often bound to an initialization key and depend on the data being anonymized in an anonymization run. As a consequence, users must be careful when they merge data from independently anonymized traces. > A central question for this document is, whether these issues should > be addressed here or whether they should be left to implementors or > to other documents. In the latter case, it should be made clear that > the schema specified in this document can be expanded somehow. The topic of anonymization always pops up when you approach people to get trace data. So I believe it needs to be mentioned here. Of course, this document is not intended to go into lengthy details about this subject. > - Section 2.4, 1st paragraph concerning storage of pcap and processed data > > Why should they be stored together? My understanding is that the > person that records the trace may be interested in anonymization of > the data. So pcap data MIGHT be archived by the user that applies > steps 1-3 (see also above), and the XML or CSV data is stored in the > repository. Changed "together with" to "as well as". > - Section 2.4, last paragraph concerning storage of original pcap data > > Due to the obvious conflict in the interests of the data supplier > (anonymized data) and the repository operator (availabilty also of > source data), I suggest to drop the strict need to keep the original > data. I have added the following paragraph: While this document recommends that raw traces should be kept, it must be noted that there are situations where this may not be feasible. The recommendation to keep raw traces may be ignored for example to comply with data protection laws or to protect a network operator from being forced to provide the data to other organizations. > - Section 3.6, 2nd paragraph > > s/identity/identify/ fixed > - Section 3.9 > > a/Assumption/Assumptions/ fixed > - Section 3.12 > > Please give a reference to RFC 2579. added an informative reference to RFC 2579 > - Section 4.1, the RNG Schema > > I did not read the schema carefully, primarily because I'm not very > familiar with Relax NG. Maybe some of the comments in Section 4.2 > also apply to this schema. > > I tried to convert the schema to XSD using trang, but only got a > trang segfault on Debian/sarge, so I'm not sure whether I did > something wrong, whether there is an error in the schema, or whether > just my trang is broken. > > Are elements by default optional? I suggest to make almost all > pieces of information optional, so that data suppliers can remove > those pieces of information that they have to hide for any reason. I think the stuff is OK; my version of trang does produce XSD output and I use tools to validate our XML output against the RNC schema. Note that only pattern has been broken into two lines due to the ID and RFC formatting restrictions. > - Section 4.2, CSV value #8 (SNMP protocol operation) > > Maybe, it would be better to delay decoding of the SNMP operation > (and probably other types of decoding) to the analysis step, so that > (obscure and very unlikely) cases of non-standard operations could > also be handled? If you want to have such values in a human readable > form, maybe a mixture of text (if well-known an decodeable) and > numeric (if unknown) values would be doable. Discussed in Prague and on the list and decided to make no changes. > - Section 4.2, CSV value #10 (SNMP error-status) > > Why do you decode protocol operations to keywords, and keep > error-status as a numeric value? Discussed in Prague and on the list and decided to make no changes. > - Section 4.2, CSV value #13/3 (object values) > > Does this mean, that exception names appear twice? Wouldn't it be > better to keep the third value empty in case of exceptions? Yes. I have removed the sentence and added that in case of exceptions, the object value field is empty. > - Section 5, 1st paragraph on sensitive data > > It is a subjective matter what pieces of information are > "unneeded". I propose something like s/unneeded/unwanted/. changed > - Section 5, 2nd paragraph > > s/suppress/suppress or anonymize/ ? changed /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB6LDGZ7015265 for ; Thu, 6 Dec 2007 22:13:21 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CCD88A14E; Thu, 6 Dec 2007 22:13:14 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 26448-04; Thu, 6 Dec 2007 22:13:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 455BD8A0EB; Thu, 6 Dec 2007 22:13:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 18D8241A75A; Thu, 6 Dec 2007 22:13:08 +0100 (CET) Date: Thu, 6 Dec 2007 22:13:08 +0100 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Subject: Re: [nmrg] future of the snmp measurement document - shepherdingvolunteer needed Message-ID: <20071206211308.GA10480@elstar.local> Mail-Followup-To: "Wijnen, Bert (Bert)" , nmrg@ibr.cs.tu-bs.de References: <20070126221609.GC937@boskop.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2007 21:13:23 -0000 On Mon, Jan 29, 2007 at 11:04:45AM +0100, Wijnen, Bert (Bert) wrote: > I reviewed the document and have the following comments, > just NITS and TYPOs > > - abstract > In order to prevent discussion/questioning about it, you might want > to de-emphasize the "configuration" usage of SNMP. How about changing > > The Simple Network Management Protocol (SNMP) is widely deployed to > monitor, control and configure network elements. Even though the > > wo something aka > > The Simple Network Management Protocol (SNMP) is widely deployed to > monitor, control and (sometimes also) configure network elements. > Even though the changed > - page 6 > It is recommended to capture at least a full week of data. Operators > are encouraged to capture traces over even longer periods of time. > Tools such as tcpslice [1] or pcapmerge [3] can be used to merge or > split pcap trace files as needed. > > I would change "to merge or split" into "to split or merge" so that > you have the same sequence as the "tcpslice pr pcapmerge". changed > - page 6 > For each captured trace, some meta data should be recorded and made > available. The meta data should include information such as where > the traces was collected, when it was collected, contact information, > > s/the traces/the trace/ ?? fixed > the size of the trace, any known special events during the data > collection period and so on. It is also extremely useful to provide > a unique identification. There are special online services such as > DatCat [4] where meta data can be store and which provide unique > identifiers. > > s/can be store/can be stored/ fixed > - section 4.2 > The comma separated values (CSV) format has been design to capture > > s/has been design/has been designed/ fixed > 2. Source IP address in dotted quad notation (IPv4), for example > "127.0.0.1", or compact hexadecimal notation (IPv6), for example > "::1". > > Would it not be better to use the reserved addresses for example as > per RFC3330 and RFC3849!!?? yes, fixed > 8. SNMP protocol operation indicated by one of the keywords get- > request, get-next-request, get-bulk-request, set-request, trap, > trap2, inform, response, report. > > I onder why sme operations are represented by the full name, while > other > are represented by a name that is not complete. > Why not use the pdu-names as per RFC3416L > PDUs ::= CHOICE { > get-request GetRequest-PDU, > get-next-request GetNextRequest-PDU, > get-bulk-request GetBulkRequest-PDU, > response Response-PDU, > set-request SetRequest-PDU, > inform-request InformRequest-PDU, > snmpV2-trap SNMPv2-Trap-PDU, > report Report-PDU } > > So change inform to inform-request and trap2 to snmpV2-trap changed > 13. For each varbind in the varbind list, three output elements are > generated > > 1. Object names given as object identifiers in dotted decimal > > s/Object names given as object identifiers/Object name goven as object > identifier/ > That is make it singular instead of plural? After all you speak "for > each object", > and it seems to me that for one object you have only one name/oid. > Same for sub-points 2 and 3. yes, all changed to singular > 2. Object base type name or exception names, that is one of the > following: null, integer32, unsigned32, unsigned64, > ipaddress, octet-string, object-identifier, no-such-object, > no-such-instance, and end-of-mib-view. > > Is the 'unsigned64' meant to be used for Counter64? yes, fixed > - security considerations section: > Anonymization techniques can be applied to keep more information in > traces which could reveal sensitive information. When using > > s/could reveal/could otherwise reveal/ ?? fixed > - general > You use "bytes" instead of "octets". > I know some IETF people prefer "octets". changed > - references. > not sure I understand why RFC3418 is normative while 2863 is > informative. > same for some other RFCs. But I can live with it. RFC3418 is not informative /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103