Subject: [nmrg] Re: nmrgmeeting in november at davis
From: Wes Hardaker <[email-masked]>
To: [email-masked]
Date: Wed, 28 Jul 2004 13:19:10 -0700
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

>>>>> On Wed, 28 Jul 2004 10:21:55 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> I have started a web page. Please let me know if you plan to
Juergen> attend for our planning purposes.

I'll attend.  Since I live in Davis, I'd be happy to help with
whatever additional planning might be needed and can probably offer
hotel suggestions.

-- 
Wes Hardaker
Sparta

Date: Wed, 28 Jul 2004 11:20:23 +0200
From: Aiko Pras <[email-masked]>
CC: [email-masked]
Subject: Re: [nmrg] meeting in november at davis
Sender: [email-masked]

Juergen Schoenwaelder wrote:

> Given the feedback I have received so far, I am planning for a meeting
> in Davis in November. My personal preference would be to meet on Sunday
> November 14th just before DSOM. This gives enough time to fly from
> the IETF (Washington DC) over to DSOM and to recover a bit from the
> IETF week and to fly back home on Friday after the IM TPC meeting.
> 
> I have started a web page. Please let me know if you plan to attend
> for our planning purposes.

I'll be there

Aiko

Date: Wed, 28 Jul 2004 10:21:55 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] meeting in november at davis
Sender: [email-masked]

Given the feedback I have received so far, I am planning for a meeting
in Davis in November. My personal preference would be to meet on Sunday
November 14th just before DSOM. This gives enough time to fly from
the IETF (Washington DC) over to DSOM and to recover a bit from the
IETF week and to fly back home on Friday after the IM TPC meeting.

I have started a web page. Please let me know if you plan to attend
for our planning purposes.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
From: Wes Hardaker <[email-masked]>
Organization: Sparta
Date: Tue, 27 Jul 2004 07:00:36 -0700
Subject: [nmrg] Re: ietf mib module productivity
Sender: [email-masked]

>>>>> On Tue, 27 Jul 2004 08:27:58 +0200, Jürgen Schönwälder <[email-masked]> said:

Jürgen> Sure. But still it is interesting to look at those numbers.

Yes.  Sorry, I didn't meant to imply they weren't interesting to look at.

-- 
Wes Hardaker
Sparta

Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
From: =?ISO-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= <[email-masked]>
Subject: Re: [nmrg] Re: ietf mib module productivity
Date: Tue, 27 Jul 2004 08:27:58 +0200
To: Wes Hardaker <[email-masked]>
Sender: [email-masked]

On Jul 26, 2004, at 15:55, Wes Hardaker wrote:

>>>>>> On Fri, 23 Jul 2004 00:58:54 +0200, Juergen Schoenwaelder 
>>>>>> <[email-masked]> said:
>
> Juergen> Lets hope this is true. Only 21 % of the current SMIv2 IETF
> Juergen> MIB modules were ever revised. So lets hope that the other 79
> Juergen> % are just so high quality that they do not need
> Juergen> maintenance. ;-) (Note that Enterasys manages to revise more
> Juergen> than 60 % of their modules.)
>
> I don't think comparing a commercial entity to a standards body
> produces results which are very meaningful.  The structure of how
> things are done is just too different.  EG, It's likely when Enterasys
> updates something to add a new feature, they just update the original
> MIB.  The IETF, however, has a policy of adding an additional
> augmenting MIB instead (not always the case, but is common).  Very
> frequently we augment when we don't have to...

Sure. But still it is interesting to look at those numbers. I now also
have numbers for Juniper Networks and their revision speed matches 
almost
100% Enterasys revision speed. If I can get some other commercial data
sets, then we would have a decent understanding of what the "normal"
revision speed is if there are no constraints. The question is how far
one can deviate from that in a standards setting and also whether so
called forums are indeed faster (as people sometimes claim).

In general: I do not know what comes out of these numbers and figures.
But still, gaining some insight how things are put to work in practice
is interesting and fun.

/js

Juergen Schoenwaelder               International University Bremen
<http://www.eecs.iu-bremen.de/>     P.O. Box 750 561, 28725 Bremen, 
Germany

To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked]
From: Wes Hardaker <[email-masked]>
Organization: Sparta
Date: Mon, 26 Jul 2004 06:55:34 -0700
Subject: [nmrg] Re: ietf mib module productivity
Sender: [email-masked]

>>>>> On Fri, 23 Jul 2004 00:58:54 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> Lets hope this is true. Only 21 % of the current SMIv2 IETF
Juergen> MIB modules were ever revised. So lets hope that the other 79
Juergen> % are just so high quality that they do not need
Juergen> maintenance. ;-) (Note that Enterasys manages to revise more
Juergen> than 60 % of their modules.)

I don't think comparing a commercial entity to a standards body
produces results which are very meaningful.  The structure of how
things are done is just too different.  EG, It's likely when Enterasys
updates something to add a new feature, they just update the original
MIB.  The IETF, however, has a policy of adding an additional
augmenting MIB instead (not always the case, but is common).  Very
frequently we augment when we don't have to...

-- 
Wes Hardaker
Sparta

Date: Mon, 26 Jul 2004 10:54:20 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Vern Paxson <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: Vern Paxson <[email-masked]>, [email-masked]
Subject: [nmrg] Re: [IRSG] IRTF summaries for July
Sender: [email-masked]

--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sun, Jul 25, 2004 at 09:02:19PM -0700, Vern Paxson wrote:

> A reminder, these are due next Sunday.  Please don't be late, as these
> will be used in the state-of-the-IRTF presentation on Wednesday evening,
> August 4th.

Attached is the report for July 2004. Since the SMIng was completed in
May with the publication of RFC 3780 and RFC 3781, we are now trying
to develop a better understanding how management is used in practice
and how new technologies compare to SNMP.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=nmrg-july-2004

NMRG report for July 2004:

[1] Several groups within the NMRG are working on measurements in
    order to develop a better understanding of the various trade-offs
    in network management protocols. The measurements focus on
    different aspects:
    
    (a) Measuring the contents of MIB modules and the MIB module
        development processes
    (b) Building a framework for the collection, storage, exchange
        and analysis of SNMP traffic traces which takes into account 
	privacy issues
    (c) Measurements to understand the performance of Web Services
        technologies relative to SNMP

[2] The next NMRG meeting will be held in Fall 2004 next to DSOM 2004,
    most likely in Davis, California (the week after the Fall IETF
    meeting in Washington). The meeting will likely to focus on the
    measurement activities listed above.

--9jxsPFA5p3P2qPhR--

Date: Fri, 23 Jul 2004 00:58:54 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] ietf mib module productivity
Reply-To: [email-masked]
Mail-Followup-To: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Sender: [email-masked]

--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Jul 22, 2004 at 04:53:40PM +0200, Wijnen, Bert (Bert) wrote:

> Maybe the initial quality of IETF MIB modules is betetr and so we
> do not need to revise as quickly ?

Lets hope this is true. Only 21 % of the current SMIv2 IETF MIB modules
were ever revised. So lets hope that the other 79 % are just so high
quality that they do not need maintenance. ;-) (Note that Enterasys
manages to revise more than 60 % of their modules.)

More seriously, I investigates a bit further and the graph was very
much screwed by some modules which contain registrations and are thus
updated regularily. This became obvious when I added the IANAifType-MIB
to the set of IETF MIBs. I have now taken these registration modules
out of the figure and it looks a bit different now.

[It is fun to see how easy it is to tune these figured. ;-]

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--RnlQjJ0d97Da+TV1
Content-Type: application/pdf
Content-Disposition: attachment; filename="mib-rev-speed.pdf"
Content-Transfer-Encoding: base64

--RnlQjJ0d97Da+TV1--

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: [nmrg] ietf mib module productivity
Date: Thu, 22 Jul 2004 16:53:40 +0200
Sender: [email-masked]

Maybe the initial quality of IETF MIB modules is betetr and so we
do not need to revise as quickly ?

At least I can hope or sound positive ;-)

Thanks,
Bert 

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: donderdag 22 juli 2004 15:54
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: [nmrg] ietf mib module productivity
> 
> 
> On Wed, Jul 21, 2004 at 06:57:42PM +0200, Wijnen, Bert (Bert) wrote:
> 
> [...]
> 
> Bert, here is another figure that you might find interesting. 
> I compares
> the speed in which three organizations revise MIB modules (and I only
> look at the MIB modules that actually get revised). It shows clearly
> that the selected company does revisions much faster and that 
> a consortium 
> like the ATM Forum already slows down but still revises specs 
> faster than
> typically the IETF. If you look at the IETF curve, it is interesting
> to note that this more or less looks like a bimodal distribution with
> centers around one year and four years.
> 
> Perhaps the comparison is not totally fair since I do not include the
> IANA MIBs in the set of IETF MIB modules while vendors typically also
> have registration modules that are updated regularily. I might change
> my mind and include IANA MIBs in the set of IETF MIBs.
> 
> The almost 10 year revision cycle is BTW the Printer-MIB, which is not
> totally fair since the printer consortium did internal updates which
> were however never published as IETF documents (and you know that it
> took quite some time to get the update into the final shape).
> 
> BTW, also the portion of modules that experience updates seems to be
> different. As we know, the IETF has a large fraction of modules which
> are never touched again.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 

Date: Thu, 22 Jul 2004 15:54:27 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] ietf mib module productivity
Reply-To: [email-masked]
Mail-Followup-To: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Sender: [email-masked]

--UugvWAfsgieZRqgk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jul 21, 2004 at 06:57:42PM +0200, Wijnen, Bert (Bert) wrote:

[...]

Bert, here is another figure that you might find interesting. I compares
the speed in which three organizations revise MIB modules (and I only
look at the MIB modules that actually get revised). It shows clearly
that the selected company does revisions much faster and that a consortium 
like the ATM Forum already slows down but still revises specs faster than
typically the IETF. If you look at the IETF curve, it is interesting
to note that this more or less looks like a bimodal distribution with
centers around one year and four years.

Perhaps the comparison is not totally fair since I do not include the
IANA MIBs in the set of IETF MIB modules while vendors typically also
have registration modules that are updated regularily. I might change
my mind and include IANA MIBs in the set of IETF MIBs.

The almost 10 year revision cycle is BTW the Printer-MIB, which is not
totally fair since the printer consortium did internal updates which
were however never published as IETF documents (and you know that it
took quite some time to get the update into the final shape).

BTW, also the portion of modules that experience updates seems to be
different. As we know, the IETF has a large fraction of modules which
are never touched again.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--UugvWAfsgieZRqgk
Content-Type: application/pdf
Content-Disposition: attachment; filename="gaga.pdf"
Content-Transfer-Encoding: base64

--UugvWAfsgieZRqgk--

Date: Wed, 21 Jul 2004 20:33:52 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] ietf mib module productivity
Reply-To: [email-masked]
Mail-Followup-To: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Sender: [email-masked]

On Wed, Jul 21, 2004 at 06:57:42PM +0200, Wijnen, Bert (Bert) wrote:

> Did you extrapolate or pro-rate 2004, or do we now (july) already 
> have more than last year? I assume "published" means "published as RFC" ?

Published means published as RFCs. I am actually looking at the REVISION
clauses and for IETF MIBs, that means published as RFC. BTW, it seems
already very clear that enterprise MIBs get revised much more often than
IETF MIBs - a clear sign of the heavy process the IETF imposes on the
revision cycle. (I am not saying this is good or bad - jus that this
seems to be different.)

I do not extrapolate - so yes, we now (july) have already more than last
year. (My plan would be to run this again at the end of the year to get
nice numbers aligned with the end of the year).
 
> I do not know what happened in 1997 or 2001.
> 1997 we were very busy with SNMPv3 I beleieve. or maybe some of the 
> v2u-v2* wars 2001  ??

Well, I just checked again the numbers and it turns out that the sizes
are not accurate - so better ignore the right graph for the time being.
But the left graph should be correct. It is also important to know that
the actual publication typically happens some time of the real work has
been done.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: [nmrg] ietf mib module productivity
Date: Wed, 21 Jul 2004 18:57:42 +0200
Sender: [email-masked]

Did you extrapolate or pro-rate 2004, or do we now (july) already have more than 
last year? I assume "published" means "published as RFC" ?

I do not know what happened in 1997 or 2001.
1997 we were very busy with SNMPv3 I beleieve. or maybe some of the v2u-v2* wars
2001  ??

Thanks,
Bert 

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: woensdag 21 juli 2004 16:52
> To: [email-masked]
> Subject: [nmrg] ietf mib module productivity
> 
> 
> I just produced some graphs (see attached PDF file) showing the IETF 
> productivity in terms of published MIB modules. The size of a MIB
> module is defined as the number of scalar/column/notification and 
> type (textual convention) definitions contained in a MIB module.
> I am wondering if someone has an explanation what happened in 1997
> and 2001...
> 
> This work goes back to a discussion about MIB metrics which we had at 
> the NMRG meeting Vienna last year. I would be interested to have some 
> more discussions based on some more graphs I am producing right now
> during the upcoming NMRG meeting next to DSOM if there is general 
> interest in this.
> 
> I am trying to produce similar plots for other MIB module sets. I
> have a rather useful set from Enterasys (formerly Cabletron) to
> work with. Analyzing Cisco MIBs turns out to be hard since the many
> MIBs they have do not easily compile using my toolset and I am not 
> sure how to work around this.
> 
> It would be nice to have other sets of MIB modules from other
> standards bodies such as the IEEE or other vendors to play with. 
> If you know a good and reliable source, please let me know.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 

Date: Wed, 21 Jul 2004 16:51:53 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] ietf mib module productivity
Sender: [email-masked]

--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

I just produced some graphs (see attached PDF file) showing the IETF 
productivity in terms of published MIB modules. The size of a MIB
module is defined as the number of scalar/column/notification and 
type (textual convention) definitions contained in a MIB module.
I am wondering if someone has an explanation what happened in 1997
and 2001...

This work goes back to a discussion about MIB metrics which we had at 
the NMRG meeting Vienna last year. I would be interested to have some 
more discussions based on some more graphs I am producing right now
during the upcoming NMRG meeting next to DSOM if there is general 
interest in this.

I am trying to produce similar plots for other MIB module sets. I
have a rather useful set from Enterasys (formerly Cabletron) to
work with. Analyzing Cisco MIBs turns out to be hard since the many
MIBs they have do not easily compile using my toolset and I am not 
sure how to work around this.

It would be nice to have other sets of MIB modules from other
standards bodies such as the IEEE or other vendors to play with. 
If you know a good and reliable source, please let me know.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--mYCpIKhGyMATD0i+
Content-Type: application/pdf
Content-Disposition: attachment; filename="out.pdf"
Content-Transfer-Encoding: base64

--mYCpIKhGyMATD0i+--

Date: Mon, 19 Jul 2004 15:14:35 +0200
From: Olivier Festor <[email-masked]>
Reply-To: [email-masked]
To: [email-masked], [email-masked]
Cc: Olivier Festor <[email-masked]>
Subject: Re: [nmrg] meeting in fall in the US
Sender: [email-masked]

Dear all,

If the meeting is organized around DSOM/IM TPC meeting, I suggest that 
one additional topic could be around :

"Performance evaluation of management frameworks" since  :

(1) most of us did or are doing things on this subject (we could also 
invite Lisandro Granville to share its experience on the subject with us)
(2) several results are already available and published,
(3) It would be great if we could try to go towards a common definition 
of a "measurement framework" so that we can compare two comparable 
things. Juergen already made a proposal around XORP. This great idea 
should be extended with several items such as : what
information model  and management algorithms are to be used when a 
performance tes has to be made, what network conditions, ...

This is in fact linked to with Juergen's topic #2

Best Regards,

/Olivier

Juergen Schoenwaelder wrote:

>Here is a proposal to organize a meeting in Fall 2004 somewhere 
>in the US, next to or inbetween the following events:
>
>November  7-12		61st IETF		(Washington, DC)
>November 15-17		DSOM 2004		(Davis, CA)
>November 17-19		IM 2005 TPC meeting	(Davis, CA)
>
>I am not sure how many people plan to attend these events (or both
>of them) so please let me know whether you prefer a meeting close
>to the IETF in Washington or a meeting close to DSOM in Davis (or
>perhaps San Francisco ;-).
>
>Regarding topics:
>
>- There is ongoing work on Web Services for management and based on
>  some more measurements and prototyping, some people like to look
>  further into issues such as the granularity of Web Services 
>  interfaces for management.
>
>- Another work item (although not new) has to do with the analysis
>  of SNMP exchanges (or perhaps even other protocols). It seems that
>  we do not have justified models how SNMP is used in practice and
>  so many papers looking at performance issues often lack substance.
>
>- Other topics might pop up once we know where to schedule this
>  meeting.
>
>Please contact me if you have any other proposals (or if you want to
>host us ;-).
>
>/js
>
>  
>

Date: Fri, 9 Jul 2004 16:00:26 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "J.P. Martin-Flatin" <[email-masked]>
Cc: IRTF Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] XORP
Reply-To: [email-masked]
Mail-Followup-To: "J.P. Martin-Flatin" <[email-masked]>, IRTF Network Management Research Group <[email-masked]>
Sender: [email-masked]

On Fri, Jul 09, 2004 at 11:29:11AM +0200, J.P. Martin-Flatin wrote:

> I suggest you look at the eXtensible Open Router Platform (XORP):
> 
>   http://www.xorp.org/
> 
> Version 1.0 was released yesterday and is supposed to be stable.

I managed to crash the CLI in a few minutes, but otherwise the project
looks nice. This is a cool platform to prototype netconf or web
services management interfaces.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Fri, 09 Jul 2004 11:29:11 +0200
From: "J.P. Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
To: IRTF Network Management Research Group <[email-masked]>
Subject: [nmrg] XORP
Sender: [email-masked]

I suggest you look at the eXtensible Open Router Platform (XORP):

   http://www.xorp.org/

Version 1.0 was released yesterday and is supposed to be stable. For a 
short introduction, see:

http://www.networkmagazine.com/shared/article/showArticle.jhtml?articleId=18201787

XORP could become a building block of a standard environment for 
benchmarking different management systems and comparing different 
architectures or techniques. When a research team publishes results and 
makes claims about a new approach, such a standard benchmarking environment 
would allow others to check whether they get the same results in the same 
environment, and whether these results are sensitive to changes in the 
environment (the latter is often "forgotten" in papers).

Perhaps my dream of bringing management from technology hopping to science 
will eventually come true...

JP

Date: Fri, 2 Jul 2004 12:05:33 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Aiko Pras <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] best approach to process SNMP packet traces?
Reply-To: [email-masked]
Mail-Followup-To: Aiko Pras <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Jul 02, 2004 at 11:47:06AM +0200, Aiko Pras wrote:

> The only "magic button" is Edit -> Preferences -> Protocols -> IP -> 
> Reassemble fragmented IP datagrams.
> It may be that you have to reload the SNMP trace, but my SNMP responses 
> get reassembled and the PDML output too (Ethereal version 10.4).

Cool. So all we need is an xslt script which cleans up the PDL for our 
purposes. That should be easy.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Fri, 02 Jul 2004 11:47:06 +0200
From: Aiko Pras <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] best approach to process SNMP packet traces?
Sender: [email-masked]

The only "magic button" is Edit -> Preferences -> Protocols -> IP -> 
Reassemble fragmented IP datagrams.
It may be that you have to reload the SNMP trace, but my SNMP responses 
get reassembled and the PDML output too (Ethereal version 10.4).

Aiko

Juergen Schoenwaelder wrote:

> On Fri, Jul 02, 2004 at 10:09:11AM +0200, Aiko Pras wrote:
>  
> 
>>>Note that PDML is not directly useful for this purpose
>>>as it does not do IP reassembly
> 
> 
>>If you export Ethereal data into PDML, it does do reassembly!
> 
> 
> Sure? I tried yesterday and it did not reassemble. Or is there a magic
> button I have to hit to do reassembly?
> 
> 
>>Or:
>>Step 1: capture SNMP data (via tcpdump / Ethereal)
>>Step 2: export the data from Ethereal into PDML
>>Step 3: remove sensitive data via a small script
> 
> 
> This would be an ideal solution if we reassembly indeed can be done
> with ethereal. Shall I capture a fragmented SNMP packet and you then
> send me the reassembled PDML for it (and tell me how you generated it)?
> 
> /js
> 

Date: Fri, 02 Jul 2004 11:37:13 +0200
From: Remco van de Meent <[email-masked]>
To: [email-masked]
CC: [email-masked], Aiko Pras <[email-masked]>
Subject: Re: [nmrg] best approach to process SNMP packet traces?
Sender: [email-masked]

Juergen Schoenwaelder wrote:
> On Fri, Jul 02, 2004 at 10:09:11AM +0200, Aiko Pras wrote:
>  
> 
>>>Note that PDML is not directly useful for this purpose
>>>as it does not do IP reassembly
> 
> 
>>If you export Ethereal data into PDML, it does do reassembly!
> 
> 
> Sure? I tried yesterday and it did not reassemble. Or is there a magic
> button I have to hit to do reassembly?

preferences -> protocols -> ip  -> set the reassemble flag
(thanks Aiko!)

> 
> 
>>Or:
>>Step 1: capture SNMP data (via tcpdump / Ethereal)
>>Step 2: export the data from Ethereal into PDML
>>Step 3: remove sensitive data via a small script
> 
> 
> This would be an ideal solution if we reassembly indeed can be done
> with ethereal. Shall I capture a fragmented SNMP packet and you then
> send me the reassembled PDML for it (and tell me how you generated it)?

I just tried the following: (tethereal is the console based version of 
ethereal)

   tethereal -i eth0 -f 'host <ipnumber>' -T pdml

and then:

   snmpbulkget -v 2c -c <community> -C r100 <ipnumber> ifTable

Et voila.

bye,
Remco

PS Working on NetPacket::IPv6 as well..

Date: Fri, 2 Jul 2004 11:02:22 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Aiko Pras <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] best approach to process SNMP packet traces?
Reply-To: [email-masked]
Mail-Followup-To: Aiko Pras <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Jul 02, 2004 at 10:09:11AM +0200, Aiko Pras wrote:
 
> > Note that PDML is not directly useful for this purpose
> > as it does not do IP reassembly

> If you export Ethereal data into PDML, it does do reassembly!

Sure? I tried yesterday and it did not reassemble. Or is there a magic
button I have to hit to do reassembly?

> Or:
> Step 1: capture SNMP data (via tcpdump / Ethereal)
> Step 2: export the data from Ethereal into PDML
> Step 3: remove sensitive data via a small script

This would be an ideal solution if we reassembly indeed can be done
with ethereal. Shall I capture a fragmented SNMP packet and you then
send me the reassembled PDML for it (and tell me how you generated it)?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Fri, 02 Jul 2004 10:09:11 +0200
From: Aiko Pras <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] best approach to process SNMP packet traces?
Sender: [email-masked]

Juergen Schoenwaelder wrote:
> It turns out that some folks in Italy have invented the PDML
> format. For details see here:
> 
> http://analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm
> 
> It turns out that ethereal can generate PDML output. If you look
> at the PDML, you will notice that it is very detailed and thus
> very verbose.

I always considered PDML as a nice and useful approach to specify PDU 
structures; I never realized its potential to store packet data. :-|
Neither knew I that Ethereal could export in this format.
-> conclusion: my working day just started and I've already learned 
something. ;-)

 > Note that PDML is not directly useful for this purpose
 > as it does not do IP reassembly
If you export Ethereal data into PDML, it does do reassembly!

However, the exported PDML file still contains community strings and 
object data values. Before distributing such PDML files, a simple script 
would therefore be needed to remove such sensitive data. Such script 
could be easier to write and use as the snmpdump.pl script (which 
requires some non-standard libraries). Probably the only thing necessary 
would be some XSLT rules.

 > ... so in principle hacking
 > ethereal could be another option to get what is needed.
Or:
Step 1: capture SNMP data (via tcpdump / Ethereal)
Step 2: export the data from Ethereal into PDML
Step 3: remove sensitive data via a small script

Aiko

Date: Fri, 02 Jul 2004 09:14:06 +0200
From: Aiko Pras <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] meeting in fall in the US
Sender: [email-masked]

My preference would be after the IM-TPC meeting, but I assume I'll also 
attend if it is before DSOM or after the IETF. The topics you've 
mentioned are exactly the topics in which I'm interested.

Aiko

Juergen Schoenwaelder wrote:

> Here is a proposal to organize a meeting in Fall 2004 somewhere 
> in the US, next to or inbetween the following events:
> 
> November  7-12		61st IETF		(Washington, DC)
> November 15-17		DSOM 2004		(Davis, CA)
> November 17-19		IM 2005 TPC meeting	(Davis, CA)
> 
> I am not sure how many people plan to attend these events (or both
> of them) so please let me know whether you prefer a meeting close
> to the IETF in Washington or a meeting close to DSOM in Davis (or
> perhaps San Francisco ;-).
> 
> Regarding topics:
> 
> - There is ongoing work on Web Services for management and based on
>   some more measurements and prototyping, some people like to look
>   further into issues such as the granularity of Web Services 
>   interfaces for management.
> 
> - Another work item (although not new) has to do with the analysis
>   of SNMP exchanges (or perhaps even other protocols). It seems that
>   we do not have justified models how SNMP is used in practice and
>   so many papers looking at performance issues often lack substance.
> 
> - Other topics might pop up once we know where to schedule this
>   meeting.
> 
> Please contact me if you have any other proposals (or if you want to
> host us ;-).
> 
> /js
> 

Date: Fri, 2 Jul 2004 10:00:51 +0900
From: "Prof. J. Won-Ki Hong" <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] meeting in fall in the US
Sender: [email-masked]

Here is my vote for Davis around DSOM 2004 time frame since
I will likely be attending DSOM 2004/IM 2005 TPC meeting in Davis.

Cheers!

James

On Thu, Jul 01, 2004 at 06:05:31PM +0200, Juergen Schoenwaelder wrote:
> Here is a proposal to organize a meeting in Fall 2004 somewhere 
> in the US, next to or inbetween the following events:
> 
> November  7-12  61st IETF  (Washington, DC)
> November 15-17  DSOM 2004  (Davis, CA)
> November 17-19  IM 2005 TPC meeting (Davis, CA)
> 
> I am not sure how many people plan to attend these events (or both
> of them) so please let me know whether you prefer a meeting close
> to the IETF in Washington or a meeting close to DSOM in Davis (or
> perhaps San Francisco ;-).
> 
> Regarding topics:
> 
> - There is ongoing work on Web Services for management and based on
>   some more measurements and prototyping, some people like to look
>   further into issues such as the granularity of Web Services 
>   interfaces for management.
> 
> - Another work item (although not new) has to do with the analysis
>   of SNMP exchanges (or perhaps even other protocols). It seems that
>   we do not have justified models how SNMP is used in practice and
>   so many papers looking at performance issues often lack substance.
> 
> - Other topics might pop up once we know where to schedule this
>   meeting.
> 
> Please contact me if you have any other proposals (or if you want to
> host us ;-).
> 
> /js
> 
> -- 
> Juergen Schoenwaelder      International University Bremen
> <http://www.eecs.iu-bremen.de/>     P.O. Box 750 561, 28725 Bremen, Germany
> 
> -- 
> !! 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 <[email-masked]>
> !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

-- 
----------------------------------------------------------------------------
James Won-Ki Hong, PhD, Associate Professor
Dept. of Computer Science & Engineering, POSTECH, Pohang Korea 790-784
Tel: +82-54-279-2244 Fax: +82-54-279-5663 Mobile: +82-11-810-5641
Email: [email-masked]        http://dpnm.postech.ac.kr/~jwkhong/
KNOM Chair: http://www.knom.or.kr   
IEEE ComSoc CNOM Vice Chair: http://www.comsoc.org/~cnomwww/
IEEE ComSoc Director of Online Content:
http://www.comsoc.org/socstr/org/bog/officers/2004/
----------------------------------------------------------------------------

To: [email-masked]
From: Wes Hardaker <[email-masked]>
Organization: Sparta
Date: Thu, 01 Jul 2004 15:29:46 -0700
Subject: [nmrg] Re: nmrgbest approach to process SNMP packet traces?
Sender: [email-masked]

>>>>> On Thu, 1 Jul 2004 17:19:16 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> It turns out that BER decoding using the perl package I am using
Juergen> is rather slow.

Perl does many things well, but that is certainly not one of them.
The whole reason the SNMP perl module was originally written by Joe
Marzot and tied directly to the Net-SNMP C stack was to get speed
increases.  He originally got a speed increase of 10x or so, but thats
way out of date.

A better question would be what do you want to do with the data?  How
are you going to analyze it?  That would dictate how I look for a
solution to the collection problem.

ethereal is certainly an excellent starting point (I've written code
for it before, and its fairly nice to work with).  There is another
application called snmpsniff as well, but I don't have a reference to
it any longer.
-- 
Wes Hardaker
Sparta

To: [email-masked]
From: Wes Hardaker <[email-masked]>
Organization: Sparta
Date: Thu, 01 Jul 2004 15:25:27 -0700
Subject: [nmrg] Re: nmrgmeeting in fall in the US
Sender: [email-masked]

>>>>> On Thu, 1 Jul 2004 18:05:31 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> November 15-17		DSOM 2004		(Davis, CA)
Juergen> November 17-19		IM 2005 TPC meeting	(Davis, CA)

Oh oh oh!  I vote for one of those!  But I'm a bit biased.

-- 
Wes Hardaker
Sparta

Date: Thu, 1 Jul 2004 18:11:01 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Phil Shafer <[email-masked]>
Cc: Radu State <[email-masked]>, [email-masked]
Subject: Re: [nmrg] YENCA on sourgeforge
Reply-To: [email-masked]
Mail-Followup-To: Phil Shafer <[email-masked]>, Radu State <[email-masked]>, [email-masked]
Sender: [email-masked]

On Thu, Jul 01, 2004 at 12:05:44PM -0400, Phil Shafer wrote:

> It's all in cvs:

[...]

OK. I was just scared away by the sourceforge web page which is rather
empty and says " CVS Repository (0 commits, 0 adds)". Thanks for the
pointer to the CVS download.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

To: [email-masked]
cc: Radu State <[email-masked]>, [email-masked]
Subject: Re: [nmrg] YENCA on sourgeforge 
Date: Thu, 01 Jul 2004 12:05:44 -0400
From: Phil Shafer <[email-masked]>
Sender: [email-masked]

Juergen Schoenwaelder writes:
>> http://sourceforge.net/projects/yenca/
>Are you sure?

It's all in cvs:

 cvs -d:pserver:[email-masked]:/cvsroot/yenca login 
 cvs -z3 -d:pserver:[email-masked]:/cvsroot/yenca co .

I'd guess the modules are:

   Yenca_Agent Yenca_Docs Yenca_Manager

Also visible via:

  http://cvs.sourceforge.net/viewcvs.py/yenca/

Thanks,
 Phil

Date: Thu, 1 Jul 2004 18:05:31 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] meeting in fall in the US
Sender: [email-masked]

Here is a proposal to organize a meeting in Fall 2004 somewhere 
in the US, next to or inbetween the following events:

November  7-12		61st IETF		(Washington, DC)
November 15-17		DSOM 2004		(Davis, CA)
November 17-19		IM 2005 TPC meeting	(Davis, CA)

I am not sure how many people plan to attend these events (or both
of them) so please let me know whether you prefer a meeting close
to the IETF in Washington or a meeting close to DSOM in Davis (or
perhaps San Francisco ;-).

Regarding topics:

- There is ongoing work on Web Services for management and based on
  some more measurements and prototyping, some people like to look
  further into issues such as the granularity of Web Services 
  interfaces for management.

- Another work item (although not new) has to do with the analysis
  of SNMP exchanges (or perhaps even other protocols). It seems that
  we do not have justified models how SNMP is used in practice and
  so many papers looking at performance issues often lack substance.

- Other topics might pop up once we know where to schedule this
  meeting.

Please contact me if you have any other proposals (or if you want to
host us ;-).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Thu, 1 Jul 2004 17:53:10 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Radu State <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] YENCA on sourgeforge
Reply-To: [email-masked]
Mail-Followup-To: Radu State <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Jun 08, 2004 at 09:23:35AM +0200, Radu State wrote:

> I would like to announce that YENCA, a  MADYNE  open source 
> implmentation of a NetConf  based agent (running on Linux)  
> is now available from the sourceforge site : 

> http://sourceforge.net/projects/yenca/

Are you sure? I have checked the side several times but I can not
find a single file to download...

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Thu, 1 Jul 2004 17:34:46 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] best approach to process SNMP packet traces?
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Jul 01, 2004 at 05:19:16PM +0200, Juergen Schoenwaelder wrote:
> Remco so that it produces XML output which can then be stored,
> shared and fed into post processors. A copy of this unfinished
> script can be found at:
> 
> http://www.ibr.cs.tu-bs.de/users/schoenw/snmpdump.pl

The server obviously refuses to serve files with the extension .pl 
so I have just renamed this file by removing the extension:

http://www.ibr.cs.tu-bs.de/users/schoenw/snmpdump

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

Date: Thu, 1 Jul 2004 17:19:16 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] best approach to process SNMP packet traces?
Sender: [email-masked]

I was working on some software to capture SNMP packet traces for
further analysis. I hacked a perl script originally written by
Remco so that it produces XML output which can then be stored,
shared and fed into post processors. A copy of this unfinished
script can be found at:

http://www.ibr.cs.tu-bs.de/users/schoenw/snmpdump.pl

It turns out that BER decoding using the perl package I am using
is rather slow. Furthermore, dealing with IP headers and options
is not something the script is currently good at (and so a real
solution will just get quite a bit longer).

It turns out that some folks in Italy have invented the PDML
format. For details see here:

http://analyzer.polito.it/30alpha/docs/dissectors/PDMLSpec.htm

It turns out that ethereal can generate PDML output. If you look
at the PDML, you will notice that it is very detailed and thus
very verbose.

The main usage of SNMP message traces would be to better understand
how SNMP is actually used in practice, to understand the behaviour
of typical agent implementations, to understand the behaviour of
typical manager implementations and so on. Note that PDML is not
directly useful for this purpose as it does not do IP reassembly
(nor is is capable to reconstruct messages in a TCP stream of
course). Ethereal is able to reconstruct TCP streams so in
principle hacking ethereal could be another option to get what
is needed.

I am sending this message since I know that some other folks on this
list are looking at the same problem and perhaps we can together
figure out a reliable and easy to implement solution.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany