Subject: RE: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-02.txt
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], "'Wijnen, Bert \(Bert\)'" <[email-masked]>
Date: Mon, 28 Jan 2008 09:32:27 -0500
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

Hi,

I know that my original comments did not make it to the list, and Bert
forwarded them to NMRG. I don't know if Bert's forward made it to the
list either. 

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Monday, January 28, 2008 9:07 AM
> To: David B Harrington
> Cc: 'Wijnen, Bert (Bert)'; [email-masked]
> Subject: Re: [nmrg] RE: NMRG Last Call: 
> draft-irtf-nmrg-snmp-measure-02.txt
> 
> On Fri, Jan 25, 2008 at 04:25:20PM -0500, David B Harrington wrote:
>  
> > I have reviewed the changes in -02- and compared them to my 
> suggested
> > changes to -01-, as per my email of 2/13/07 (below).
> > 
> > I find that the suggested changes were not addressed, from the
> > simplest search and replace for English wording, to 
> discussion of the
> > impact of different application designs.
> >
> > Was that intentional or an oversight?
> 
> I obviously missed your comments when I updated the document in
> December. This clearly is an oversight and not intentional.
> 
> For some unknown reason, your comments were not in my private NMRG
> email archive and it seems your message did not make it into the
NMRG
> email archive maintained on the mailing list server either.
> 
> I will go over your comments later this week and then I guess we
will
> have an updated ID to take care of.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 

Date: Mon, 28 Jan 2008 15:07:10 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: David B Harrington <[email-masked]>
Subject: Re: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-02.txt
Mail-Followup-To: David B Harrington <[email-masked]>, "'Wijnen, Bert (Bert)'" <[email-masked]>, [email-masked]
Cc: [email-masked], "'Wijnen, Bert \(Bert\)'" <[email-masked]>
Reply-To: [email-masked]

On Fri, Jan 25, 2008 at 04:25:20PM -0500, David B Harrington wrote:
 
> I have reviewed the changes in -02- and compared them to my suggested
> changes to -01-, as per my email of 2/13/07 (below).
> 
> I find that the suggested changes were not addressed, from the
> simplest search and replace for English wording, to discussion of the
> impact of different application designs.
>
> Was that intentional or an oversight?

I obviously missed your comments when I updated the document in
December. This clearly is an oversight and not intentional.

For some unknown reason, your comments were not in my private NMRG
email archive and it seems your message did not make it into the NMRG
email archive maintained on the mailing list server either.

I will go over your comments later this week and then I guess we will
have an updated ID to take care of.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From: "David B Harrington" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: [nmrg] meeting at the upcoming ietf 71
Date: Fri, 25 Jan 2008 18:28:10 -0500

Hi,

I woul dlikely attend such a meeting. I will already be at the IETF
meeting.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Wednesday, January 23, 2008 1:00 PM
> To: [email-masked]
> Subject: [nmrg] meeting at the upcoming ietf 71
> 
> Hi,
> 
> I am wondering what the interest is here to schedule a meeting at
the
> upcoming IETF, say on Friday morning. 
> 
> A possible topics is a detailed review and discussion of the SNMP
> analysis definitions document - assuming I can get Gijs who is a
main
> contributor to travel to Philadelphia. It would be very nice to get
> technical feedback on the document (please be reminded that I posted
a
> poll whether this should become an NMRG work item on January 15th).
> 
> http://www.ietf.org/internet-drafts/draft-schoenw-nmrg-snmp-tr
> ace-definitions-00.txt
> 
> Another possible agenda item could be the presentation of a
> classification system for research work in the network and service
> management area that some people have put together by doing an
> analysis of information recorded in conference paper reviewing
> systems.
> 
> There might be other issues to discuss - feel free to propose topics
> that should be on a possible agenda.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> -- 
> !! 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://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

From: "David B Harrington" <[email-masked]>
To: "'David B Harrington'" <[email-masked]>, "'Wijnen, Bert \(Bert\)'" <[email-masked]>, <[email-masked]>
Date: Fri, 25 Jan 2008 16:25:20 -0500
Subject: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-02.txt

 Hi,

I have reviewed the changes in -02- and compared them to my suggested
changes to -01-, as per my email of 2/13/07 (below).

I find that the suggested changes were not addressed, from the
simplest search and replace for English wording, to discussion of the
impact of different application designs.

Was that intentional or an oversight?

dbh

> -----Original Message-----
> From: David B Harrington [mailto:[email-masked]] 
> Sent: Tuesday, February 13, 2007 1:31 PM
> To: 'Wijnen, Bert (Bert)'; [email-masked]
> Subject: RE: [nmrg] RE: NMRG Last Call: 
> draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
> 
> Hi,
> 
> I have reviewed this document. In my opinion, this document is
> well-written, and documents a useful research approach. I recommend
it
> be published as an RFC. 
> 
> Below are some comments that might or might not improve the
document.
> Many of the comments deal with application-specific considerations
> that could impact analysis results, and I feel the potential impact
is
> not as well documented as it should be.
> 
> s/patterns are in real world/patterns occur in real world/
> s/binding interface/interface/
> s/can be store/can be stored/
> s/an SNMP messages/an SNMP message/
> s/are able convert/are able to convert/
> s/unneeded/unnecessary/
> 
> "The CSV format only captures the most essential parts ..."
Shouldn't
> you provide a qualifier for "the most essential"? I would think "the
> most essential" depends on what you are trying to do with the raw
> data, and that for some purposes, the data not kept might actually
be
> the most essential. 
> 
> Storing Traffic Traces stresses keeping the original traces. While
> this is certainly important from a researcher's point of view, it
also
> incresaes the potential for security breach that could expose
> sensitive information. I think this emphasis would make it harder
for
> me to convince operators to run traces and make them available. I
> think there is a tradeoff between researcher needs and operators'
> security needs, and for an operator, security trumps research. I
think
> this section should be written to recognize and contrast both points
> of view, and to stress that operators should make the decision about
> long-term storage of their non-anonymized traces.
> 
> "Due to the availability" - This paragraph "rubs me the wrong way"
by
> suggesting that everybody use the same language. I think it would be
> more effective if presented as "Tool implementers can choose any
> language they want. The following tools have been used to do
analysis
> already, and are freely available for others to build on to speed
> development time and consistency with other analysis work." Let
people
> decide it is in their best interest to build on the existing
framework
> rather than to start from scratch. But don't suggest that everybody
> use the same language. But I do think it is important to inform the
> reader of available tools that can be used to build their own
solution
> so they can try to replicate results of others, and make repliation
of
> their results easy for others.
> 
> I found section 3.1 a little difficult to read. I think it might
> benefit from being made a list:
> 	1) protocol versions used,
> 	2) operations used,
> 	3) standardized, proprietary, or experimental data
> 	4) message size distributions, and
> 	5) periodicity.
> 
> For the third type of basic statistics, why not use mgmt(2),
> experimental(30, private(4), and snmpv2(6) rather than standardized,
> proprietary, and experimental? These are well-defined and standard
> subtrees for these purposes. You might actually just say "categorize
> by subtree" and then give examples. 
> 
> Differentiation at the layer you mention is useful, but within a
> proprietary subtree, the tree might be broken down by product model,
> and knowing which models generate which varbinds might be useful
info.
> Some polling applications adapt their requests based on what is
known
> to be available; once they determine that a given MIB module is not
> supported on a device, then they might not poll for that subtree
> (unless they detect a reboot or other event where the subtree might
> become available).  
> 
> When doing any analysis based on a pcap capture in front of an
> application, it should certainly be noted in the metadata which
> application's traffic was being captured. This should probably be
> mentioned in paragraph one of section 2.1.
> 
> Different applications are designed to do different things. A
generic
> MIB browser might not be particular about what it polls; a bridging
> fault detection application might poll the bridge mib and use traps
> more extensively than other applications. One type of analysis that
> could be done is to identify which MIB modules are polled regularly
by
> specific applications. 
> 
> Some applications rely on administrative configuration of polling;
for
> example, a popular application displays the date and time from the
> device; but it asks the operator which object (and its format) to
poll
> to get the raw data used to generate that information. The bias of a
> particular operator or a particular device vendor might be
eliminated
> in comparing large number of traces, but could be misleading is
small
> samples.
> 
> Some applications only poll what an operator asks it to, and at the
> frequency requested. This bias should be recognized.
> 
> 3.2 Periodicity
> 
> Again, the application should be taken into consideration. Spectrum,
> and I expect other application suites, use a shared polling engine
to
> support multiple applications, and has indicators in its local
> database of the likely variability of an object, and how important
> that variability is to each using application. An application can
tell
> the poller "I need the absolute latest value" which causes the
> database to always poll the object, or "Any value within the last 30
> minutes is fine", and the database will return a value form the
> database that was recorded within the last 30 minutes, if available,
> otherwise it polls to update the object, or "Any value since reboot"
> which might be used for things like sysContact. 
> 
> So the periodic polling behavior is highly dependent on the
> application and the polling engine it uses, and this needs to be
> considered when analyzing traces.
> 
> 3.3 Latency Distributions
> 
> Some device implementations update their SNMP counters from the
> underlying instrumentation following adaptive algorthms, not
> necessarily periodically, and not necessarily on-demand. For
example,
> if  an implementation chose to update the counters from the
> instrumentation only when asked, but then to update the counter for
> subsequent requests only if the data in the counter is more than X
> seconds old, the measured latency might vary as a result (assuming
> sending the repeat value takes less time than updating from the
actual
> instrumentation). The granularity of counter update may or may not
be
> significant to the latency measurement.
> 
> 3.4 Concurrency
> 
> It might also be interesting to see how many redundant requests
coming
> from different applications are processed almost simultaneously by a
> device. Understanding this might prompt more usage of shared polling
> engines to reduce the redundancy. 
> 
> Of course, for this you might need to perform the capture in front
of
> specific devices or device groups to capture traffic from multiple
> applications. Section 2.1 discusses the location of probes; it
> probably should mention the impact of  location on analysis affected
> by manager:device relationships of 1:m, m:1, and m:m.
> 
> 3.5 retrieval approaches
> 
> This is application-specific. 
> 
> "It will be useful to know which of these approaches are used on
> production networks, by which applications."
> 
> If an operator can detect that a particular application is being
> inefficient, he can ask the vendor to modify the application
retrieval
> approach to improve efficiency, or he can buy more efficient
> applications.
> 
> 3.6 Trap-directed polling
> 
> Whether polling is adapted based on having received a notification
is
> application-specific.
> 
> Any analysis should take into consideration the application-specific
> behavior before concluding "to what extent SNMP managers use
automated
> procedures ..."
> 
> With a large enough sample, this might become unimportant, but thus
> far, it has been hard to get samples, so this type of bias should be
> mentioned for small samples.
> 
> 3.8 Obsolete objects
> 
> By parseing sysObjectID and sysDecr and the Host Resources MIB, you
> might be able to determine how old the revisions of hardware and
> software of the mansged devices are. This should probably be taken
> into consideration when analyzing the use of obsolete and deprecated
> objects.
> 
> 3.10 Discontinuity
> 
> "It will be interesting to study to what extent these objects are
> actually used by management applications ..." isn't clear how you
> would determine which continuity indicators are used by management
> applications. The traces could be analyzed to correlate which
> discontinuity indicators are included in requests for which counters
> to infer what is used by management applications. 
> 
> 4.1 Should the irtf establish its own namespace registry?
> 
> 4.13 why should activation of trap conversion be the user's choice?
I
> can see reasons for this, but you don't mention any, and it could be
> important to the analysis. Is it also important to any subsequent
user
> of the CSV to know whether the traps were converted or not?
> 
> 5.0 (filter-in principle) is mentioned, but there is no defintion of
> what this means in the document, and no reference. It should either
be
> removed or a citation/reference added.
> 
> Good job.
> 
> David Harrington
> [email-masked] 
> [email-masked]
> [email-masked]
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Wijnen, Bert
> (Bert)
> > Sent: Tuesday, February 13, 2007 4:56 AM
> > To: [email-masked]
> > Subject: [nmrg] RE: NMRG Last Call: 
> > draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
> > 
> > Dear NMRG members,
> > 
> > We have now received 6 reviews for this document.
> > That is not a badd score. But of course we (as really active
> > participants) want to show the IRTF community that we are
> > much more active than any of these other reasearch groups.
> > 
> > There are 3 more days before the Last Call ends.
> > So PLEASE DO review and let us know your findings.
> > We also want to see statements aka:
> > 
> >   I did read it and it looks good to me.
> > 
> > I plan to summarize next Monday (so if you can only review during 
> > the coming weekend, you might still be able to squeeze it in).
> > 
> > Bert
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) 
> > > Sent: dinsdag 30 januari 2007 14:59
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt 
> > > for Informational RFC
> > > 
> > > Juergen and NMRG members. 
> > > 
> > > Pls review and post your opinion BEFORE Feb 17th, 2007.
> > > 
> > > Juergen wrote:
> > > > > [...] Since I am personally involved as the 
> > > author/editor, the first 
> > > > > thing we need is a shepherd who is willing to run the 
> > > process, which 
> > > > > starts with soliciting RG
> > > > reviews by
> > > > > doing a RG last call. Any volunteers?
> > > > 
> > > > Our shepherd for <draft-irtf-nmrg-snmp-measure-01.txt> is 
> > > Bert Wijnen 
> > > > and he will now take over the procedure. Thanks to Bert for 
> > > helping us 
> > > > with this and also many thanks to the others who 
> > > volunteered to help 
> > > > move this document along.
> > > > 
> > > > /js
> > > I am starting my work as shepherd of this document, using the 
> > > irtf-rfcs-01a draft (as Juergen had included in his posting 
> > > last Friday) as the process to follow. This is based on:
> > > 
> > > Juergen,
> > > According to the irtf-rfcs-01a draft, we need to make sure we 
> > > have consensus that this is an RG supported document.
> > > 
> > > from my quick checking of the nmrg mlist archives, it seems 
> > > that you proposed to make this an NMRG document in march 
> > > 2006, when you psted the abstract of your individual doument, 
> > > and asked:
> > > 
> > >    I believe that this work is highly relevant for the NMRG
> > >    and I hereby propose to turn this Internet-Draft which 
> > >    is still an individual submission into an NMRG sponsored
> > >    Internet-Draft. Please let me know what you think about
> > >    this and especially if you have concerns about doing so.
> > > 
> > > For all I can tell, I am the only one who responded positive 
> > > to this. I see no negative answers, but a lot of silence w.r.t.
> > > this question. So it seems you have assumed that silence 
> > > means consent (and give the formulation of your question, we 
> > > can indeed interpret silence as consent, or at least as no 
> > objection.
> > > 
> > > NMRG members:
> > > 
> > > In order to consider this as an NMRG document, it is not 
> > > sufficient to "not object". We need at least a set of NMRG 
> > > members/participants to review the document and to comment. 
> > > If you are happy with the document and support its 
> > > publication as an NMRG supported Informational RFC, then I 
> > > would like to hear that, prefereably by posting such a 
> > > statement to the NMRG list. Something aka
> > > 
> > >   I have read the document, it is in good shape and I support
> > >   its publication as Informational RFC.
> > > 
> > > If you have comments/sugegstions/concerns, pls let us know 
> > > and post them to this NMRG mailing list.
> > > 
> > > Pls send your review comments/results BEFORE 17 Feb 2007.
> > > Sooner is of course better. This allows for the authors to do 
> > > a new revision (if needed) before the ID cutoff.
> > > 
> > > I propose that we consider my own review comments (posted
> yesterday,
> > >
> http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-January/001187.html)
> > > as initial RG LC comments.
> > > 
> > > Bert
> > > 
> > > 
> > 
> > -- 
> > !! 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://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> > 
> 
> 
> 

Date: Wed, 23 Jan 2008 19:52:40 +0100
From: Aiko Pras <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] meeting at the upcoming ietf 71

Hi all

I can not make it to Philadelphia.
Detailed discussions on the SNMP analysis definitions document is something I 
would appreciate if it could be done.

Bye

Aiko

Juergen Schoenwaelder wrote:
> Hi,
> 
> I am wondering what the interest is here to schedule a meeting at the
> upcoming IETF, say on Friday morning. 
> 
> A possible topics is a detailed review and discussion of the SNMP
> analysis definitions document - assuming I can get Gijs who is a main
> contributor to travel to Philadelphia. It would be very nice to get
> technical feedback on the document (please be reminded that I posted a
> poll whether this should become an NMRG work item on January 15th).
> 
> http://www.ietf.org/internet-drafts/draft-schoenw-nmrg-snmp-trace-definitions-00.txt
> 
> Another possible agenda item could be the presentation of a
> classification system for research work in the network and service
> management area that some people have put together by doing an
> analysis of information recorded in conference paper reviewing
> systems.
> 
> There might be other issues to discuss - feel free to propose topics
> that should be on a possible agenda.
> 
> /js
> 

Date: Wed, 23 Jan 2008 18:59:57 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] meeting at the upcoming ietf 71
Reply-To: [email-masked]

Hi,

I am wondering what the interest is here to schedule a meeting at the
upcoming IETF, say on Friday morning. 

A possible topics is a detailed review and discussion of the SNMP
analysis definitions document - assuming I can get Gijs who is a main
contributor to travel to Philadelphia. It would be very nice to get
technical feedback on the document (please be reminded that I posted a
poll whether this should become an NMRG work item on January 15th).

http://www.ietf.org/internet-drafts/draft-schoenw-nmrg-snmp-trace-definitions-00.txt

Another possible agenda item could be the presentation of a
classification system for research work in the network and service
management area that some people have put together by doing an
analysis of information recorded in conference paper reviewing
systems.

There might be other issues to discuss - feel free to propose topics
that should be on a possible agenda.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Content-class: urn:content-classes:message
Subject: RE: [nmrg] I-D ACTION:draft-schoenw-nmrg-snmp-trace-definitions-00.txt
Date: Tue, 15 Jan 2008 18:54:19 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Juergen,

I support this work and I commit to review it.

Dan
(speaking as contributor) 

 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Tuesday, January 15, 2008 7:34 PM
> To: [email-masked]
> Subject: [nmrg] I-D 
> ACTION:draft-schoenw-nmrg-snmp-trace-definitions-00.txt
> 
> Hi,
> 
> the following Internet Draft just got posted. This ID is the 
> document we started at the last NMRG meeting in Enschede in 
> November 2007. It introduces a bunch of definitions that have 
> already been implemented in SNMP trace analysis tools 
> developed at the University of Twente and Jacobs University.
> 
> At the last NMRG meeting, our idea was to move this document 
> forward as an NMRG document. However, since the meeting was 
> only attend by a small number of people, I like to check with 
> the NMRG the level of support for taking on this document as 
> an NMRG work item. This in particular requires that we find 
> volunteers who (a) express their support for discussing this 
> work within the NMRG and who (b) commit reviewing cycles to 
> this document when it gets ready for RG last call.
> 
> Please let me know your level of support and/or the reasons 
> why you think this work should not be done within the NMRG. 
> Please do so within the next two weeks so that I can 
> summarize by the end of this months.
> 
> Thanks,
> 
> /js
> 
> ---8<---
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: SNMP Trace Analysis Definitions
> 	Author(s)	: J. Schoenwaelder, et al.
> 	Filename	: 
> draft-schoenw-nmrg-snmp-trace-definitions-00.txt
> 	Pages		: 26
> 	Date		: 2008-1-15
> 	
>    The Network Management Research Group (NMRG) started an activity to
>    collect traces of the Simple Network Management Protocol 
> (SNMP) from
>    operational networks.  To analyze these traces, it is necessary to
>    split potentially large traces into more manageable pieces 
> that make
>    it easier to deal with large data sets and simplify the analysis of
>    the data.
> 
>    This document provides some common definitions that have been found
>    useful for implementing tools to support trace analysis.  This
>    document mainly serves as a reference for the definitions 
> underlying
>    these tools and it is not meant to explain all the motivation and
>    reasoning behind the definitions.  Some of this background
>    information can be found in other research papers.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-schoenw-nmrg-snmp-tr
ace-definitions-00.txt

---8<---

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
-- 
!! 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://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

Date: Tue, 15 Jan 2008 18:33:53 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] I-D ACTION:draft-schoenw-nmrg-snmp-trace-definitions-00.txt
Reply-To: [email-masked]

Hi,

the following Internet Draft just got posted. This ID is the document
we started at the last NMRG meeting in Enschede in November 2007. It
introduces a bunch of definitions that have already been implemented
in SNMP trace analysis tools developed at the University of Twente and
Jacobs University.

At the last NMRG meeting, our idea was to move this document forward
as an NMRG document. However, since the meeting was only attend by a
small number of people, I like to check with the NMRG the level of
support for taking on this document as an NMRG work item. This in
particular requires that we find volunteers who (a) express their
support for discussing this work within the NMRG and who (b) commit
reviewing cycles to this document when it gets ready for RG last call.

Please let me know your level of support and/or the reasons why you
think this work should not be done within the NMRG. Please do so
within the next two weeks so that I can summarize by the end of this
months.

Thanks,

/js

---8<---

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: SNMP Trace Analysis Definitions
	Author(s)	: J. Schoenwaelder, et al.
	Filename	: draft-schoenw-nmrg-snmp-trace-definitions-00.txt
	Pages		: 26
	Date		: 2008-1-15
	
   The Network Management Research Group (NMRG) started an activity to
   collect traces of the Simple Network Management Protocol (SNMP) from
   operational networks.  To analyze these traces, it is necessary to
   split potentially large traces into more manageable pieces that make
   it easier to deal with large data sets and simplify the analysis of
   the data.

   This document provides some common definitions that have been found
   useful for implementing tools to support trace analysis.  This
   document mainly serves as a reference for the definitions underlying
   these tools and it is not meant to explain all the motivation and
   reasoning behind the definitions.  Some of this background
   information can be found in other research papers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-schoenw-nmrg-snmp-trace-definitions-00.txt

---8<---

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Content-class: urn:content-classes:message
Subject: RE: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txtforInformational RFC
Date: Tue, 15 Jan 2008 16:57:51 +0100
From: "Giorgio Nunzi" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]

Hi Juergen,

Thanks for the changes: they look fine to me.

Regarding the XML sources, I think that your solution is fine too.

Giorgio

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014  

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Friday, December 07, 2007 11:45 AM
> To: Giorgio Nunzi
> Cc: [email-masked]
> Subject: Re: [nmrg] NMRG Last Call: 
> draft-irtf-nmrg-snmp-measure-01.txtforInformational RFC
> 
> 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         <http://www.jacobs-university.de/>
> 

Date: Wed, 9 Jan 2008 23:17:11 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt
Mail-Followup-To: "Romascanu, Dan (Dan)" <[email-masked]>, "WIJNEN, Bert (Bert)" <[email-masked]>, [email-masked]
Cc: [email-masked], "WIJNEN, Bert \(Bert\)" <[email-masked]>
Reply-To: [email-masked]

On Wed, Jan 09, 2008 at 07:19:32PM +0100, Romascanu, Dan (Dan) wrote:
 
> Obviously that NOTE forgot to take into account that there are RFCs that
> do not necessarily go through a full IETF Consensus process (including
> IETF Last Call). 
> 
> Let me know what response you get from the IRSG and whether you want me
> to do a similar query with the IESG.

Thanks for offering help.

I assume that Aaron Falk will contact the IESG; perhaps you can
collaborate with him to get this discussed and resolved and finally an
errata posted (which hopefully says "specification required" was the
intention ;-).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Content-class: urn:content-classes:message
Subject: RE: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt
Date: Wed, 9 Jan 2008 19:19:32 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, "WIJNEN, Bert (Bert)" <[email-masked]>
Cc: [email-masked]

Juergen,

Obviously that NOTE forgot to take into account that there are RFCs that
do not necessarily go through a full IETF Consensus process (including
IETF Last Call). 

Let me know what response you get from the IRSG and whether you want me
to do a similar query with the IESG.

Dan

 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Tuesday, January 08, 2008 1:25 PM
> To: WIJNEN, Bert (Bert)
> Cc: [email-masked]
> 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.
> 
> I checked the idnits output and the tool complains that there 
> is no IANA considerations section. In fact, we have an IANA 
> consideration since we need a URI for the XML namespace. My 
> preference would be to follow RFC 3688 and request from IANA 
> that the URN
> 
>    urn:ietf:params:xml:ns:snmp-trace
> 
> is being allocated. However, I note that RFC 3688 says the following:
> 
>    [...] NOTE: in order for a URN of this type to be
>    assigned, the item being registered MUST have been through the IETF
>    consensus process.  Basically, this means that it must be 
> documented
>    in a RFC.
> 
> This text is somewhat ambiguous whether IRTF RFCs can 
> actually allocate URNs. I will check with the IRSG how to 
> handle this and keep you informed.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> --
> !! 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://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

From: Aaron Falk <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt
Date: Tue, 8 Jan 2008 09:34:05 -0500
Cc: [email-masked], "WIJNEN, Bert \(Bert\)" <[email-masked]>

I'll look into this.  (btw, [email-masked] is my preferred address.)

--aaron

On Jan 8, 2008, at 6:24 AM, Juergen Schoenwaelder wrote:

> 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.
>
> I checked the idnits output and the tool complains that there is no
> IANA considerations section. In fact, we have an IANA consideration
> since we need a URI for the XML namespace. My preference would be
> to follow RFC 3688 and request from IANA that the URN
>
>   urn:ietf:params:xml:ns:snmp-trace
>
> is being allocated. However, I note that RFC 3688 says the following:
>
>   [...] NOTE: in order for a URN of this type to be
>   assigned, the item being registered MUST have been through the IETF
>   consensus process.  Basically, this means that it must be documented
>   in a RFC.
>
> This text is somewhat ambiguous whether IRTF RFCs can actually
> allocate URNs. I will check with the IRSG how to handle this and
> keep you informed.
>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Date: Tue, 8 Jan 2008 12:24:47 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "WIJNEN, Bert (Bert)" <[email-masked]>
Subject: Re: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt
Mail-Followup-To: "WIJNEN, Bert (Bert)" <[email-masked]>, [email-masked], Aaron Falk <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]

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.

I checked the idnits output and the tool complains that there is no
IANA considerations section. In fact, we have an IANA consideration
since we need a URI for the XML namespace. My preference would be
to follow RFC 3688 and request from IANA that the URN

   urn:ietf:params:xml:ns:snmp-trace

is being allocated. However, I note that RFC 3688 says the following:

   [...] NOTE: in order for a URN of this type to be
   assigned, the item being registered MUST have been through the IETF
   consensus process.  Basically, this means that it must be documented
   in a RFC.

This text is somewhat ambiguous whether IRTF RFCs can actually
allocate URNs. I will check with the IRSG how to handle this and
keep you informed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Date: Wed, 2 Jan 2008 14:28:50 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] updates of the nmrg web page
Reply-To: [email-masked]

Hi,

I hope you all had a good start into 2008. I started the year 2008 or
the NMRG by updating the NMRG web pages and it would be nice to update
the list of research papers that are related to the NMRG (i.e. they
acknowledge NMRG meetings or NMRG results in some way).

Please check out the list on http://www.ibr.cs.tu-bs.de/projects/nmrg/
and send me any missing items (preferrably in BiBTeX format).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Content-class: urn:content-classes:message
Date: Tue, 1 Jan 2008 10:37:05 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [nmrg] FW: I-D ACTION:draft-jinxiang-operations-and-management-ngi-00.txt 

This is a multi-part message in MIME format.

------_=_NextPart_001_01C84C59.DFC82AA7
Content-Type: text/plain; name="warning1.txt"
Content-Disposition: inline; filename="warning1.txt"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.417 (Entity 5.417)

WARNING: This e-mail has been altered by MIMEDefang.  Following this
paragraph are indications of the actual changes made.  For more
information about your site's MIMEDefang policy, contact
MIMEDefang Administrator <[email-masked]>.  For more information about MIMEDefang, see:

            http://www.roaringpenguin.com/mimedefang/enduser.php3

An attachment named draft-jinxiang-operations-and-management-ngi-00.URL was removed from this document as it
constituted a security hazard.  If you require this document, please contact
the sender and arrange an alternate means of receiving it.

------_=_NextPart_001_01C84C59.DFC82AA7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

=20
I apologize for cross-posting.=20

Dan

=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Monday, December 31, 2007 7:15 PM
To: [email-masked]
Subject: I-D ACTION:draft-jinxiang-operations-and-management-ngi-00.txt=20

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Retriving MIB Information based on NGI=20=20
	Author(s)	: J. Zhang, et al.
	Filename	:
draft-jinxiang-operations-and-management-ngi-00.txt
	Pages		: 15
	Date		: 2007-12-31
=09
   An important task of network management is to collect and analyze=20
   MIB information  of various object combinations based on the
   Simple Network Management Protocol (SNMP) with proper frequency.
   The purpose of this document is to propose two algorithms to retrieve
   MIB information  for a large (up to exponential) number of managed=20
   objects using SNMP in Next Generation Internet (NGI).=20

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jinxiang-operations-and-manage
ment-ngi-00.txt

To remove yourself from the I-D Announcement list, send a message to=20
[email-masked] with the word unsubscribe in the body of=20
the message.=20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the=20
username "anonymous" and a password of your e-mail address. After=20
logging in, type "cd internet-drafts" and then=20
"get draft-jinxiang-operations-and-management-ngi-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-jinxiang-operations-and-management-ngi-00.txt".
=09
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_001_01C84C59.DFC82AA7
Content-Type: application/octet-stream;
	name="ATT585536.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT585536.TXT
Content-Disposition: attachment; filename="ATT585536.TXT"

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10
eXBlPSJtYWlsLXNlcnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9y
ZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8
MjAwNy0xMi0zMTExMjAxMS5JLURAaWV0Zi5vcmc+DQoNCkVOQ09ESU5HIG1p
bWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qaW54aWFuZy1vcGVy
YXRpb25zLWFuZC1tYW5hZ2VtZW50LW5naS0wMC50eHQNCg==

------_=_NextPart_001_01C84C59.DFC82AA7
Content-Type: text/plain;
	name="ATT585537.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT585537.txt
Content-Disposition: attachment; filename="ATT585537.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBp
ZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vaS1kLWFubm91bmNlDQo=

------_=_NextPart_001_01C84C59.DFC82AA7--