Subject: [nmrg] Completed NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>
Date: Tue, 20 Feb 2007 11:20:44 +0100
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

NMRG participants,

On Jan 30 2007, I started (as the shepherd for this document) a
Last Call within the NMRG to make sure that this documents is
supported and reviewed by this Research Group.

I wrote:

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

We have now received 15 postings of reviews.
All have been positive and supportive to publish this document.
So I now consider this document as a real NMRG document.

But there were also a lot of constructive comments and there were some 
questions. 

So I have discussed this with Juergen (the author/editor of the
document),
and he will go through all the comments, and either make changes if that
makes sense. He will also post his views/answers on the comments to this

list. Juergen will try to get a new rev out before the I-D cutoff (March

5th), but he is pretty overloaded at the moment, so he did not give
a 100% guarantee he would make it. He will try though. And it would be
good
if we indeed DO have a new rev by that date. That woul allow us to 
read/review before Prague and then discuss it at the upcoming NMRG
meeting 
in Prague.

Last but not least: THANKS to all those who reviewed and posted their
comments.

Bert Wijnen

Date: Mon, 19 Feb 2007 17:15:28 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] draft prague nmrg meeting agenda
Reply-To: [email-masked]

Hi,

an NMRG meeting has been scheduled for Friday during the Prague meeting.
I have no clue whether we can continue after the IETF meeting ends at
11:30. Given the number of concrete time requests I have received, I am 
also not sure we need to continue past 11:30. Given this situation, 
I prefer to close the meeting at 11:30:

Here is a draft agenda for the meeting (09:00-11:30):

0) Agenda bashing, administrivia                  10
1) Report from the NMRG meeting in Utrecht (UT)   20
2) SNMP trace collection/analysis update (IUB)    30
3) Role-based access control for NETCONF (INRIA)  30
4) Distributed monitoring (KTH)                   30
5) Discussion                                     20
6) Wrap up					  10

Please let me know if you want to add something to the proposed
agenda or like something changed.

/js

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

Content-class: urn:content-classes:message
Date: Mon, 19 Feb 2007 11:55:53 +0100
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>
Cc: Mark Burgess <[email-masked]>
Subject: [nmrg] FW: RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC

Forwarding another review with permission. 

Thanks Mark!

Bert
-----Original Message-----
From: Mark Burgess [mailto:[email-masked]] 
Sent: vrijdag 16 februari 2007 20:32
To: Wijnen, Bert (Bert)
Subject: Re: FW: [nmrg] RE: NMRG Last Call:
draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC

Wijnen, Bert (Bert) wrote:
> Great!.
> Here is the pointer
> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-01.tx
> t
> 
> Bert
> 

Bert,

Here are my comments:

It is unclear from the title of the document that this is a proposal
for a future study, with guidelines and recommendations. The title
suggests that the document will provide some answers, but it does not.

On p.2 "This document descirbes an effort to collect...." Is the
effort past, present or future? Also, it claims to descrie tools etc,
but I am not sure that these have been highlighted clearly enough in
the text.

It is also not clear from the document what the point of the study
would be. Why are we carrying out the study? Some time is spent to
criticize the state of previous measurements, but these comments are
not followed up in the conclusion to indicate how the proposed study
would be an improvement.

p4. What is the reason for capturing a full week of data? To be able
to observe the widely observed trends in activity over a week. in this
case measurements should always be collected in time-spans of
whole-weeks so that multiple measurements can be compared at
corresponding times.

On p6. 2.4 some very specfific technologies are mentioned. Is it
necessary to be this specific?

Also in 2.5, I am not sure why we need to mention Perl or C/C++.

On p8 sec 3.2, is the title meant to be "periodic versus aperiodic
SNMP traffic"? i.e. is this the traffice caused by polling overhead of
udp/snmp or is this some other traffic. If so why could it be periodic?

After section 3.12 I lost interest in the details of the schemas.

Content-class: urn:content-classes:message
Subject: RE: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
Date: Sat, 17 Feb 2007 00:39:15 -0600
From: "Medhi, Deep" <[email-masked]>
To: "Wijnen, Bert \(Bert\)" <[email-masked]>, <[email-masked]>
Cc: [email-masked]

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.

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.

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

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.

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.

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. 

If issues raised by various members of this community on this mailing
list (including the above) are addressed adequately, I believe this
would be a worthwhile document to publish as an informational RFC. 

Thanks!

        -- Deep Medhi

           http://www.csee.umkc.edu/~dmedhi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wijnen, Bert (Bert)
> Sent: Tuesday, January 30, 2007 7:59 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [nmrg] NMRG Last Call: 
> draft-irtf-nmrg-snmp-measure-01.txt forInformational 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.
> 

From: Luca Deri <[email-masked]>
Subject: Re: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
Date: Fri, 16 Feb 2007 23:45:56 +0100
To: [email-masked]
Sender: Luca Deri <[email-masked]>
Cc: "Wijnen, Bert \(\(Bert\)\)" <[email-masked]>

Hi all,
I think that this draft is quite interesting for the community, well- 
written, comprehensive and easy to understand.

A few of comments
- 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 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?
- 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.

Said that I recommend to publish it as RFC.

Cheers, Luca

On Feb 14, 2007, at 9:01 AM, Wijnen, Bert ((Bert)) wrote:

> Another review, forwarded with permission.
>
> Thanks Randy!
>
> Bert
>
> -----Original Message-----
> From: Randy Bush [mailto:[email-masked]]
> Sent: dinsdag 13 februari 2007 20:59
> To: Wijnen, Bert (Bert)
> Cc: Juergen Schoenwaelder
> Subject: Re: FW: [nmrg] RE: NMRG Last Call:
> draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
>
> great work!
>
> --
>
> i do not like 2.2.  to paraphrase matt roughan, researchers spend a  
> lot
> of time getting data OUT of strange formats and places.  do not put  
> the
> data into mysql, xml, ..., you only make it harder for us.
>
> i would ditch the whole xml thing.  half our tools are awk, python,
> perl, ...  and xml just gets in the way bigtime.  look at mrt  
> format for
> bgp data, colon separated text; and researchers love it.
>
> 4.2, csv, is fine.
>
> --
>
> 2.3. anonymization is hard and can not really be successful.  so  
> expect
> wise operators to only be willing to share under nda.
>
> also need ip address anonymization, not just removal of fields.
>
> --
>
>    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,
>    the size of the trace, any known special events during the data
>    collection period and so on.
>
> be specific about things like ip of tracer etc.  i realize there are
> things here that can not be specific.  but be rigorous where you  
> can be.
>
> --
>
> 2.5. thanks mom, don't tell me how to write my code.
>
> --
>
> sectiom 3 gets into a particular set of measurements.  they are
> interesting.  but do you want this particular experiment in the  
> general
> data gathering document?  i am not sure.
>
> --
>
> i am sure that there will be idealists who think this is far too
> specific.  well kiddies, reality is pretty damned specific.  get over
> it.
>
>
> randy
>
>
> -- 
> !! 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] 
> bs.de>
> !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.

Content-class: urn:content-classes:message
Subject: FW: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
Date: Fri, 16 Feb 2007 10:56:32 +0100
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>
Cc: Sharon Chisholm <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C751B0.BCA366A6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Forwarding a review by Sharon Chisholm.
If the attached PDF does not get accepted by the mail archive,=20
then here is a pointer to it
=20
http://www.eecs.iu-bremen.de/users/schoenw/draft-irtf-nmrg-snmp-measure-
review-sharon.pdf

Thanks Sharon!

Bert

-----Original Message-----
From: Sharon Chisholm [mailto:[email-masked]]=20
Sent: donderdag 15 februari 2007 20:14
To: Wijnen, Bert (Bert)
Cc: Juergen Schoenwaelder
Subject: RE: [nmrg] RE: NMRG Last Call:
draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC

 hi

My comments are embedded in the attachment. It will be interesting to
get the results of this analysis.

Sharon

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Tuesday, February 13, 2007 5:36 AM
To: Chisholm, Sharon (CAR:ZZ00)
Subject: FW: [nmrg] RE: NMRG Last Call:
draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC

Sharon,

do you think you can find some time to review this document?
It is not too many pages, so should not be too much of a time drain.

Thanks,
Bert=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Wijnen, Bert (Bert)
Sent: dinsdag 13 februari 2007 10:56
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
>=20
> Juergen and NMRG members.=20
>=20
> Pls review and post your opinion BEFORE Feb 17th, 2007.
>=20
> 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?
> >=20
> > 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.
> >=20
> > /js
> I am starting my work as shepherd of this document, using the=20
> irtf-rfcs-01a draft (as Juergen had included in his posting last
> Friday) as the process to follow. This is based on:
>=20
> Juergen,
> According to the irtf-rfcs-01a draft, we need to make sure we have=20
> consensus that this is an RG supported document.
>=20
> from my quick checking of the nmrg mlist archives, it seems that you=20
> proposed to make this an NMRG document in march 2006, when you psted=20
> the abstract of your individual doument, and asked:
>=20
>    I believe that this work is highly relevant for the NMRG
>    and I hereby propose to turn this Internet-Draft which=20
>    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.
>=20
> For all I can tell, I am the only one who responded positive to this.=20
> 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=20
> silence as consent, or at least as no objection.
>=20
> NMRG members:
>=20
> 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=20
> review the document and to comment.
> If you are happy with the document and support its publication as an=20
> NMRG supported Informational RFC, then I would like to hear that,=20
> prefereably by posting such a statement to the NMRG list. Something=20
> aka
>=20
>   I have read the document, it is in good shape and I support
>   its publication as Informational RFC.
>=20
> If you have comments/sugegstions/concerns, pls let us know and post=20
> them to this NMRG mailing list.
>=20
> Pls send your review comments/results BEFORE 17 Feb 2007.
> Sooner is of course better. This allows for the authors to do a new=20
> revision (if needed) before the ID cutoff.
>=20
> 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.
>=20
> Bert
>=20
>=20

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

------_=_NextPart_001_01C751B0.BCA366A6
Content-Type: application/octet-stream;
	name="review.pdf"
Content-Transfer-Encoding: base64
Content-Description: review.pdf
Content-Disposition: attachment;
	filename="review.pdf"

------_=_NextPart_001_01C751B0.BCA366A6--

Content-class: urn:content-classes:message
Subject: FW: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
Date: Thu, 15 Feb 2007 14:41:18 +0100
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>

Another review, forwarded witrh permission.

Thanks Liam,
Bert

-----Original Message-----
From: Liam Fallon (AT/LMI) [mailto:[email-masked]] 
Sent: donderdag 15 februari 2007 13:37
To: Wijnen, Bert (Bert)
Subject: RE: [nmrg] RE: NMRG Last Call:
draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC

Hello,

I have read the document and the proposal looks interesting. I have just
one small comment.

2.1 Capturing Traffic Traces.
Traffic traces could be captured in the management system itself; in
fact it could be rather easy to do it there.

Best Regards
Liam Fallon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Wijnen, Bert (Bert)
Sent: 13 February 2007 09:56
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.

content-class: urn:content-classes:message
Date: Thu, 15 Feb 2007 13:41:06 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>
Cc: "Wijnen, Bert \(Bert\)" <[email-masked]>
Subject: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC

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'

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

It would also be useful to clarify what these operation environments
are. Do we mean carriers, or IP service providers vs. enterprise
networks? 

3. Section 2:

Explain what are 'pcap capture files'. Maybe a terminology and
abbreviations section would help. 

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. 

5. Section 3.1: 

PDU-type distribution and error messages frequency should be added to
the list of basic statistics

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. 

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? 

8. Section 3.5:

The use of the term 'cell-by-cell' when referring to tables is
inconsistent with the SMI terminology

I hope this helps. 

Dan

Content-class: urn:content-classes:message
Subject: FW: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
Date: Wed, 14 Feb 2007 13:52:44 +0100
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>

Mm... for some reason this one did not reach the NMRG 
mail archives. Hope this time it gets there.

Bert

-----Original Message-----
From: David B Harrington [mailto:	 
Sent: dinsdag 13 februari 2007 19:31
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.
> 

Content-class: urn:content-classes:message
Subject: FW: FW: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
Date: Wed, 14 Feb 2007 09:01:27 +0100
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>
Cc: Randy Bush <[email-masked]>

Another review, forwarded with permission.

Thanks Randy!

Bert 

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: dinsdag 13 februari 2007 20:59
To: Wijnen, Bert (Bert)
Cc: Juergen Schoenwaelder
Subject: Re: FW: [nmrg] RE: NMRG Last Call:
draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC

great work!

--

i do not like 2.2.  to paraphrase matt roughan, researchers spend a lot
of time getting data OUT of strange formats and places.  do not put the
data into mysql, xml, ..., you only make it harder for us.

i would ditch the whole xml thing.  half our tools are awk, python,
perl, ...  and xml just gets in the way bigtime.  look at mrt format for
bgp data, colon separated text; and researchers love it.

4.2, csv, is fine.

--

2.3. anonymization is hard and can not really be successful.  so expect
wise operators to only be willing to share under nda.

also need ip address anonymization, not just removal of fields.

--

   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,
   the size of the trace, any known special events during the data
   collection period and so on.

be specific about things like ip of tracer etc.  i realize there are
things here that can not be specific.  but be rigorous where you can be.

--

2.5. thanks mom, don't tell me how to write my code.

--

sectiom 3 gets into a particular set of measurements.  they are
interesting.  but do you want this particular experiment in the general
data gathering document?  i am not sure.

--

i am sure that there will be idealists who think this is far too
specific.  well kiddies, reality is pretty damned specific.  get over
it.

randy

Date: Tue, 13 Feb 2007 15:03:41 -0800 (PST)
From: "David T. Perkins" <[email-masked]>
To: "Wijnen, Bert \\(Bert\\)" <[email-masked]>
Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC
Cc: [email-masked], [email-masked]

HI,

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

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".
2) Add additional examples in last para of section 2.1
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.)
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.

Regards,
/david t. perkins

Content-class: urn:content-classes:message
Date: Tue, 13 Feb 2007 10:56:19 +0100
From: "Wijnen, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>
Subject: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational 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
> 
> 

From: Wes Hardaker <[email-masked]>
To: "Wijnen\, Bert \(Bert\)" <[email-masked]>
Organization: Sparta
Date: Mon, 12 Feb 2007 17:39:09 -0800
Cc: [email-masked], [email-masked]
Subject: [nmrg] Re: nmrgNMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC

>>>>> "BW" == Bert Wijnen <Wijnen> writes:

BW> Pls review and post your opinion BEFORE Feb 17th, 2007.

(note: I read the previous document more fully; I rescanned the -01
version but I didn't re-read everything completely)

Comments:

-  I do think the work is important to document and is an important
   field of study.

- ethereal -> wireshark  [wireshark is the new name for the ethereal project]

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

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

-- 
Wes Hardaker
Sparta, Inc.

Date: Mon, 12 Feb 2007 21:11:49 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] meeting in prague
Reply-To: [email-masked]

Hi,

according to the DRAFT agenda of the IETF week in Prague, the NMRG
meeting got scheduled for Friday as requested. It is still unclear
whether we can continue into the afternoon.

https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=68

I will keep you posted in case things change or I hear news about
the scheduling. I will post an agenda soon.

/js

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

Content-class: urn:content-classes:message
Subject: RE: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
Date: Fri, 9 Feb 2007 11:43:07 +0100
From: "Giorgio Nunzi" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, <[email-masked]>
Cc: [email-masked]

Dear All,

I think the document provides a useful tool to the network management community. The document seems to me well written and provides enough details. Therefore I support it on its way for an RFC.

I have a couple of remarks:
- 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.
- 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.

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.

Kind Regards,

Giorgio

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wijnen, Bert (Bert)
> Sent: Tuesday, January 30, 2007 2:59 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [nmrg] NMRG Last Call: 
> draft-irtf-nmrg-snmp-measure-01.txt forInformational 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.
> 

Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC
From: Remco van de Meent <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 06 Feb 2007 13:24:44 +0100
Cc: [email-masked], [email-masked]

On Tue, 2007-01-30 at 14:58 +0100, Wijnen, Bert (Bert) wrote:
> 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 read the document and I'm happy with it. I also recommend taking
Frank's suggestions for further improvement into account. Finally I
support the document's publication as Informational RFC.

regards,
Remco.