Subject: Re: [nmrg] meeting at the upcoming ietf 71
From: Aiko Pras <[email-masked]>
To: [email-masked]
Cc: Lisandro Zambenedetti Granville <[email-masked]>, Juergen Schoenwaelder <[email-masked]>, Georgios Karagiannis <[email-masked]>
Date: Fri, 29 Feb 2008 13:55:24 +0100
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

Hi

I would appreciate if you could put on the agenda for the Philadelphia IETF an 
item on network management research classification. This classification is under 
development within the Emanics NoE, and it would be great if we can have 10 
minutes for a short presentation and possible feedback.

Georgios will be able to give that presentation.

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
> 

From: Luca Deri <[email-masked]>
To: Bert Wijnen - IETF <[email-masked]>
Subject: Re: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps
Date: Thu, 28 Feb 2008 20:45:12 +0100
Cc: Nmrg <[email-masked]>

Bert,
in his email Juergen has explained why he made some design choices.  
I'm happy with them, hence for me the document is ready for publication.

Regards Luca

On Feb 27, 2008, at 6:05 PM, Bert Wijnen - IETF wrote:

> Luca,
>
> Juergen has answered you comments as per
>  http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-December/001270.html
> I think the new document is ready for publication now.
>
> If you want to recheck, pls do so before March 13 2008.
>
> Bert Wijnen
> Document shepherd

Resent-From: [email-masked]
Resent-Date: Thu, 28 Feb 2008 10:02:53 +0100
Resent-Message-ID: <[email-masked]>
Resent-To: [email-masked]
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>
Subject: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps
Date: Wed, 27 Feb 2008 16:02:40 -0500

trying again.

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Wednesday, February 27, 2008 3:26 PM
To: 'Bert Wijnen - IETF'; [email-masked]
Cc: 'Dan Romascanu'; [email-masked]
Subject: RE: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next
steps

Hi,

I have reviewed -03-. I (naturally) have a few comments. Hopefully,
they are all editorial only. 

1. The statement that this is the work of the NMRG is repeated
unnecessarily in the abstract and introduction. It might actually be
better in the acknowledgements.

s/loosing/losing/
s/It should be noted that//g - it is noted, and therefore doesn't need
to say it should be noted.
s/In addition, //g - this is overused.
s/In situation /In situations /

Assuming this document is generated using xml2rfc, I recommend using
the compact option to reduce the blank lines generated between
sections.

I notice that the XSDMI XSD for object identifier differs from your
XSD:
XSDMI:
   <xs:simpleType name="ObjectIdentifier">
     <xs:restriction base="xs:string">
       <xs:pattern value=
       "[0-2](\.[1-3]?[0-9])(\.(0|([1-9]\d*))){0,126}"/>
     </xs:restriction>
   </xs:simpleType>
measure:
 oid.type =
   xsd:string {
     pattern =
       """[0-2](\.[0-9]+)+"""
   }
Should these patterns be similar? or doesn't it matter?
Or is this a difference in regexp between XSD and relaxNG?

I notice the ipv4address pattern differs as well:
XSDMI:
   <xs:simpleType name="IpAddress">
     <xs:restriction base="xs:string">
       <xs:pattern value=
 
"((0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])?|[3-9][0-9]?)\.){3}
       (0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])?|[3-9][0-9]?)"/>
     </xs:restriction>
   </xs:simpleType>
measure:
 ipv4address.type =
   xsd:string {
     pattern =
       """[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*"""
   }
is this difference significant?

in the CSV format, item 13 1., the text has been changed to refer to a
single object name, but then it says names are separated by commas. I
found this a bit confusing.

s/An IPv4 addesses is/An IPv4 address is/

"In case of an exception, the object value is an empty string." Does
this mean it shows up as ,, or ,"",?

In the third paragraph of security considerations, a sentence starts
"When using anonymization, values should only be added when". I found
this a little hard to parse; I thought you were talking about creating
some new value and adding it to anonymization (which made no sense to
me), when you were really talking about keeping or not keeping a value
extracted from the input. I recommend "When using anonymization,
values should only be kept when" or something similar.

As an editor, I'm curious. For normative and informational references,
you used symbolic identifiers, but changed to numeric identifiers for
the URI section. Any particular reason for changing the style? Are the
URIs informative or normative? Are there guidelines for listing URIs
in an I-D?

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bert Wijnen -
IETF
> Sent: Tuesday, February 26, 2008 11:58 AM
> To: [email-masked]
> Cc: Dan Romascanu; [email-masked]
> Subject: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps
> 
> Dear NMRG participants,
> 
> This document has been out for 2 weeks now.
> I have not seen anyone speak up that the document does
> not address the comments we had received. Basically I (as the
> document shepherd) am now assuming that the comments have
> indeed been addressed. A list of commenters (with pointers
> to their actual comments) can be found here:
> 
>   http://www3.tools.ietf.org/group/irtf/trac/ticket/9
> 
> So you can all check if you want.
> 
> The document does request an assignment in the IETF XML 
> registry (RFC3688),
> and such a registration requires IETF consensus (sect 3.1 of
RFC3688).
> So the IESG has issued an IETF Last Call for that on feb 14 2008.
That
> Last Call ends on March 13, 2008.
> 
> So we have approx 2 more weeks before the document will go onto the
> IESG agenda and before any other action happens (or so I think).
> If anyone still finds anything to be an issue, pls speak up
> rather sooner than later, but certainly BEFORE March 13, 2008.
> 
> Bert Wijnen 
> document shepherd
> 
> > -----Oorspronkelijk bericht-----
> > Van: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> > Verzonden: dinsdag 12 februari 2008 22:02
> > Aan: Dan Romascanu; Bert Wijnen
> > CC: [email-masked]
> > Onderwerp: draft-irtf-nmrg-snmp-measure-03.txt - next steps
> > 
> > 
> > Hi,
> > 
> > I have posted <draft-irtf-nmrg-snmp-measure-03.txt> which 
> incorporates
> > changes to address David Harrington's last call comments and to
put
> > into place the correct boilerplate to allocate a proper URN for
the
> > XML namespace.
> > 
> > I believe this version addresses all concerns and so I would like
to
> > ask Dan to start the IETF wide last call on the XML namespace URN
> > allocation and Bert to pick up the document and move it 
> along the IRTF
> > publication procedure.
> > 
> > /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.
> 

Resent-From: [email-masked]
Resent-Date: Thu, 28 Feb 2008 10:02:58 +0100
Resent-Message-ID: <[email-masked]>
Resent-To: [email-masked]
Date: Thu, 28 Feb 2008 02:03:32 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: David B Harrington <[email-masked]>
Subject: Re: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps
Reply-To: [email-masked]

On Wed, Feb 27, 2008 at 04:02:40PM -0500, David B Harrington wrote:
 
> I have reviewed -03-. I (naturally) have a few comments. Hopefully,
> they are all editorial only. 
> 
> 1. The statement that this is the work of the NMRG is repeated
> unnecessarily in the abstract and introduction. It might actually be
> better in the acknowledgements.

There are new boilerplates for IRTF publications and I am just trying
to be a brave soul. ;-)
 
> s/loosing/losing/
> s/It should be noted that//g - it is noted, and therefore doesn't need
> to say it should be noted.
> s/In addition, //g - this is overused.
> s/In situation /In situations /

Editorial fixes - no problem.

> Assuming this document is generated using xml2rfc, I recommend using
> the compact option to reduce the blank lines generated between
> sections.

OK

> I notice that the XSDMI XSD for object identifier differs from your
> XSD:
> XSDMI:
>    <xs:simpleType name="ObjectIdentifier">
>      <xs:restriction base="xs:string">
>        <xs:pattern value=
>        "[0-2](\.[1-3]?[0-9])(\.(0|([1-9]\d*))){0,126}"/>
>      </xs:restriction>
>    </xs:simpleType>
> measure:
>  oid.type =
>    xsd:string {
>      pattern =
>        """[0-2](\.[0-9]+)+"""
>    }
> Should these patterns be similar? or doesn't it matter?
> Or is this a difference in regexp between XSD and relaxNG?

The XSDMI is more precise or restrictive. I am fine with adopting the
XSDMI version.

> I notice the ipv4address pattern differs as well:
> XSDMI:
>    <xs:simpleType name="IpAddress">
>      <xs:restriction base="xs:string">
>        <xs:pattern value=
>  
> "((0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])?|[3-9][0-9]?)\.){3}
>        (0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])?|[3-9][0-9]?)"/>
>      </xs:restriction>
>    </xs:simpleType>
> measure:
>  ipv4address.type =
>    xsd:string {
>      pattern =
>        """[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*"""
>    }
> is this difference significant?

Significant? I don't know. The XSDMI pattern is more precise but on
the other hand it does not fit on an RFC line and hence the pattern is
actually broken until someone fixes it by removing the white
space. But since we have the same line length problem with the IPv6
pattern, I am fine with adopting the XSDMI version.

> in the CSV format, item 13 1., the text has been changed to refer to a
> single object name, but then it says names are separated by commas. I
> found this a bit confusing.

I suggest to remove the second sentence since it is not needed.
 
> s/An IPv4 addesses is/An IPv4 address is/

Editorial.

> "In case of an exception, the object value is an empty string." Does
> this mean it shows up as ,, or ,"",?

It is perhaps better to say:

   In case of an exception, the object value is empty.

> In the third paragraph of security considerations, a sentence starts
> "When using anonymization, values should only be added when". I found
> this a little hard to parse; I thought you were talking about creating
> some new value and adding it to anonymization (which made no sense to
> me), when you were really talking about keeping or not keeping a value
> extracted from the input. I recommend "When using anonymization,
> values should only be kept when" or something similar.

Yes, kept is better than added.

> As an editor, I'm curious. For normative and informational references,
> you used symbolic identifiers, but changed to numeric identifiers for
> the URI section. Any particular reason for changing the style?

I use whatever xml2rfc spits out.

> Are the URIs informative or normative?

It is relatively obvious that all listed URIs are informative.

> Are there guidelines for listing URIs in an I-D?

I am sure someone will write such guidelines if they have not been
written yet. I hope, however, that this does not stop this document.
Just in case you write in your response that the header above the URIs
should be changed to "Informative URIs", let me tell you that I have
no clue how to do that in xml2rfc since the header is generated
automagically.

/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: Wes Hardaker <[email-masked]>
To: "Bert Wijnen - IETF" <[email-masked]>
Organization: Sparta
Date: Wed, 27 Feb 2008 12:36:26 -0800
Cc: Nmrg <[email-masked]>
Subject: [nmrg] Re: FW: nmrgdraft-irtf-nmrg-snmp-measure-03.txt - next steps

>>>>> "BW" == Bert Wijnen <- IETF" <[email-masked]>> writes:

BW> Wes, you commented as documented here
BW> http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-February/001198.html

BW> I think this doc is now OK.
BW> But if you want to re-check, pls do so before Matrch 13th.

Thanks.  I expect to have the time to do so before the 13th.

-- 
Wes Hardaker
Sparta, Inc.

From: "Bert Wijnen - IETF" <[email-masked]>
To: "David Perkins" <[email-masked]>
Subject: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps
Date: Wed, 27 Feb 2008 18:05:08 +0100
Importance: Normal
Cc: Nmrg <[email-masked]>

David,

Juergen has answered to your comments in december
  http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-December/001268.html
and I think the new rev of the document is OK
to go out as RFC.

If you want to re-check, pls do so before 13 March 2008

Bert Wijnen 
document shepherd

From: "Bert Wijnen - IETF" <[email-masked]>
To: <[email-masked]>
Subject: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps
Date: Wed, 27 Feb 2008 18:05:08 +0100
Importance: Normal
Cc: Nmrg <[email-masked]>

Luca,

Juergen has answered you comments as per
  http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-December/001270.html
I think the new document is ready for publication now.

If you want to recheck, pls do so before March 13 2008.

Bert Wijnen 
Document shepherd

From: "Bert Wijnen - IETF" <[email-masked]>
To: <[email-masked]>
Subject: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps
Date: Wed, 27 Feb 2008 18:05:08 +0100
Importance: Normal
Cc: Nmrg <[email-masked]>

Medhi,

Juergen has answered your comments as per
  http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-December/001269.html

I think the new document is ready for publication now.

If you do want to recheck, pls do so before Match 13 2008

Bert Wijnen 
document shepherd

From: "Bert Wijnen - IETF" <[email-masked]>
To: "Wes Hardaker" <[email-masked]>
Subject: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps
Date: Wed, 27 Feb 2008 17:44:49 +0100
Importance: Normal
Cc: Nmrg <[email-masked]>

Wes, you commented as documented here
  http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-February/001198.html

I think this doc is now OK.
But if you want to re-check, pls do so before Matrch 13th.

Bert Wijnen 
document shepherd

From: =?ISO-8859-1?Q?Frank_Strau=DF?= <[email-masked]>
To: Bert Wijnen - IETF <[email-masked]>
Date: Wed, 27 Feb 2008 09:28:04 +0100
Cc: [email-masked]
Subject: [nmrg] Re: draft-irtf-nmrg-snmp-measure-03.txt - next steps

Hi Bert,

Am 26.02.2008 um 18:04 schrieb Bert Wijnen - IETF:

> Frank, I believe most of you rcomments have been addressed
> and/or answered. As document shepherd I want to pass the
> doc on to the IRSG for approval. Can you check and let is
> know if you are OK with the document now, BEFORE mar 13?
>
> Your comemnts are/were recorded here:
> http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-January/001194.html

I'm sorry that I did not response in December when Jürgen revised the  
document with respect to my comments. He sent me a detailed response  
upon my initial input. I've been completely fine with the changes and  
arguments against my comments. So, regarding my point of view: Move  
the document forward!

  -frank

From: "Bert Wijnen - IETF" <[email-masked]>
To: "Frank Strauss" <[email-masked]>
Date: Tue, 26 Feb 2008 18:04:52 +0100
Importance: Normal
Cc: [email-masked]
Subject: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps

Frank, I believe most of you rcomments have been addressed
and/or answered. As document shepherd I want to pass the
doc on to the IRSG for approval. Can you check and let is
know if you are OK with the document now, BEFORE mar 13?

Your comemnts are/were recorded here:
http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-January/001194.html

Bert Wijnen 

From: "Bert Wijnen - IETF" <[email-masked]>
To: <[email-masked]>
Date: Tue, 26 Feb 2008 18:04:52 +0100
Importance: Normal
Cc: [email-masked]
Subject: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps

Giogio,

I hope the new revision of the document is OK.
Your earlier comments were recorded here:

  http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-February/001196.html 

Your comments may not have been resolved exactly as you prefered, but
hopefully they have been answered and addressed such that the documnt
is now good enough for publication.

Bert Wijnen 
document shepherd

From: "Bert Wijnen - IETF" <[email-masked]>
To: <[email-masked]>
Date: Tue, 26 Feb 2008 17:58:29 +0100
Importance: Normal
Cc: Dan Romascanu <[email-masked]>, [email-masked]
Subject: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps

Dear NMRG participants,

This document has been out for 2 weeks now.
I have not seen anyone speak up that the document does
not address the comments we had received. Basically I (as the
document shepherd) am now assuming that the comments have
indeed been addressed. A list of commenters (with pointers
to their actual comments) can be found here:

  http://www3.tools.ietf.org/group/irtf/trac/ticket/9

So you can all check if you want.

The document does request an assignment in the IETF XML registry (RFC3688),
and such a registration requires IETF consensus (sect 3.1 of RFC3688).
So the IESG has issued an IETF Last Call for that on feb 14 2008. That
Last Call ends on March 13, 2008.

So we have approx 2 more weeks before the document will go onto the
IESG agenda and before any other action happens (or so I think).
If anyone still finds anything to be an issue, pls speak up
rather sooner than later, but certainly BEFORE March 13, 2008.

Bert Wijnen 
document shepherd

> -----Oorspronkelijk bericht-----
> Van: Juergen Schoenwaelder [mailto:[email-masked]]
> Verzonden: dinsdag 12 februari 2008 22:02
> Aan: Dan Romascanu; Bert Wijnen
> CC: [email-masked]
> Onderwerp: draft-irtf-nmrg-snmp-measure-03.txt - next steps
> 
> 
> Hi,
> 
> I have posted <draft-irtf-nmrg-snmp-measure-03.txt> which incorporates
> changes to address David Harrington's last call comments and to put
> into place the correct boilerplate to allocate a proper URN for the
> XML namespace.
> 
> I believe this version addresses all concerns and so I would like to
> ask Dan to start the IETF wide last call on the XML namespace URN
> allocation and Bert to pick up the document and move it along the IRTF
> publication procedure.
> 
> /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: "Bert Wijnen - IETF" <[email-masked]>
To: <[email-masked]>
Date: Tue, 26 Feb 2008 17:58:29 +0100
Importance: Normal
Cc: [email-masked]
Subject: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps

For the record,

My comments (to revision 1) as stated at
  http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-January/001187.html
have been adequately addressed.

Thanks

Bert Wijnen 

Date: Tue, 26 Feb 2008 08:43:31 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [nmrg] nmrg meeting at the ietf in philadelphia
Reply-To: [email-masked]

Hi,

I requested an NMRG meeting slot and we initially got scheduling
conflicts with the NETCONF data modeling BOF. This scheduling conflict
has now been resolved and the meeting is now scheduled for Friday
morning, that is 2008-03-14 in the time 09:00-11:30.

The main agenda item will be the revised version of the SNMP trace
analysis definitions document:

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

Gijs will attend the meeting and go through the definitions. The idea
is to get feedback where there might be problems and to decide whether
there is enough interest to make this document an NMRG work item
(which essentially means enough people committing to actively review
the document as it moves forward and to last call).

During the week, there will also be an IAB review of the NMRG, a
procedure every RG goes through periodically. I plan to report about
it on Friday; I am also soliciting input you might have for the
meeting.

If you have requests for the agenda, e.g. suggestions for new work
items, please let me know as soon as possible.

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

Resent-From: [email-masked]
Resent-Date: Mon, 25 Feb 2008 08:46:30 +0100
Resent-Message-ID: <[email-masked]>
Resent-To: [email-masked]
To: [email-masked]
From: [email-masked]
Date: Sun, 24 Feb 2008 23:45:02 -0800 (PST)
Sender: [email-masked]
Subject: [nmrg] I-D Action:draft-schoenw-nmrg-snmp-trace-definitions-01.txt 
Reply-To: [email-masked]

--NextPart

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

	Title           : SNMP Trace Analysis Definitions
	Author(s)       : U. Twente, et al.
	Filename        : draft-schoenw-nmrg-snmp-trace-definitions-01.txt
	Pages           : 27
	Date            : 2008-02-24

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

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

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-schoenw-nmrg-snmp-trace-definitions-01.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-schoenw-nmrg-snmp-trace-definitions-01.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-schoenw-nmrg-snmp-trace-definitions-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-schoenw-nmrg-snmp-trace-definitions-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2008-02-24234009.I-D\@ietf.org>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Content-class: urn:content-classes:message
Date: Thu, 14 Feb 2008 16:53:34 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Subject: [nmrg] FW: Last Call: draft-irtf-nmrg-snmp-measure (SNMP Traffic Measurements and Trace Exchange Formats) to Informational RFC

 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of The IESG
Sent: Thursday, February 14, 2008 5:43 PM
To: IETF-Announce
Subject: Last Call: draft-irtf-nmrg-snmp-measure (SNMP Traffic
Measurements and Trace Exchange Formats) to Informational RFC 

The IESG has received a request from an individual submitter to consider
the following document:

- 'SNMP Traffic Measurements and Trace Exchange Formats '
   <draft-irtf-nmrg-snmp-measure-03.txt> as an Informational RFC

This document which is the work of the Network Management Reseach Group
(NMRG) of the IRTF requests that IANA register a URI for the SNMP XML
trace format namespace in the IETF XML registry [RFC3688]. The IESG
plans to make a decision about this registration request in the next few
weeks, and solicits final comments on this action.  Please send
substantive comments to the [email-masked] mailing lists by 2008-03-13.
Exceptionally, comments may be sent to [email-masked] instead. In either
case, please retain the beginning of the Subject line to allow automated
sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
14654&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf-announce

Date: Tue, 12 Feb 2008 22:02:13 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Dan Romascanu <[email-masked]>, Bert Wijnen <[email-masked]>
Mail-Followup-To: Dan Romascanu <[email-masked]>, Bert Wijnen <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: [nmrg] draft-irtf-nmrg-snmp-measure-03.txt - next steps
Reply-To: [email-masked]

Hi,

I have posted <draft-irtf-nmrg-snmp-measure-03.txt> which incorporates
changes to address David Harrington's last call comments and to put
into place the correct boilerplate to allocate a proper URN for the
XML namespace.

I believe this version addresses all concerns and so I would like to
ask Dan to start the IETF wide last call on the XML namespace URN
allocation and Bert to pick up the document and move it along the IRTF
publication procedure.

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

Resent-From: [email-masked]
Resent-Date: Tue, 12 Feb 2008 21:38:14 +0100
Resent-Message-ID: <[email-masked]>
Resent-To: [email-masked]
To: [email-masked]
From: [email-masked]
Date: Tue, 12 Feb 2008 12:30:01 -0800 (PST)
Sender: [email-masked]
Subject: [nmrg] I-D Action:draft-irtf-nmrg-snmp-measure-03.txt 
Reply-To: [email-masked]

--NextPart

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

	Title           : SNMP Traffic Measurements and Trace Exchange Formats
	Author(s)       : J. Schoenwaelder
	Filename        : draft-irtf-nmrg-snmp-measure-03.txt
	Pages           : 30
	Date            : 2008-02-12

The Simple Network Management Protocol (SNMP) is widely deployed to
monitor, control and (sometimes also) configure network elements.
Even though the SNMP technology is well documented, it remains
relatively unclear how SNMP is used in practice and what typical SNMP
usage patterns are.

This document proposes to carry out large scale SNMP traffic
measurements in order to develop a better understanding how SNMP is
used in real world production networks.  It describes the motivation,
the measurement approach, and the tools and data formats needed to
carry out such a study.

This document was produced within the IRTF's Network Management
Research Group (NMRG) and represents the consensus of all of the
active contributors to this group.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-03.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-irtf-nmrg-snmp-measure-03.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-irtf-nmrg-snmp-measure-03.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-irtf-nmrg-snmp-measure-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-irtf-nmrg-snmp-measure-03.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2008-02-12121522.I-D\@ietf.org>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: [nmrg] RE:URNallocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt
Date: Tue, 12 Feb 2008 17:46:56 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], Lisa Dusseault <[email-masked]>

 

> -----Original Message-----
> From: Juergen Schoenwaelder 

> 
> Since the allocation is actually IETF last called via the 
> IESG, one could argue that the IESG is the registration 
> contact. But I am happy to put there whatever allows us to 
> move forward. What about:
> 
>    NMRG of the IRTF
> 
> /js
> 

Looks fine to me. 

Dan

Date: Tue, 12 Feb 2008 17:23:58 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: [nmrg] RE: URNallocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg- snmp-measure-02.txt
Mail-Followup-To: "Romascanu, Dan (Dan)" <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>
Cc: [email-masked], Lisa Dusseault <[email-masked]>
Reply-To: [email-masked]

On Tue, Feb 12, 2008 at 03:29:30PM +0100, Romascanu, Dan (Dan) wrote:
> This looks fine. 
> 
> One question:
> 
> >    Registrant Contact: The IESG.
> 
> Why would the IESG figure here as Registrant? 
> 
> RFC 3688 says:
> 
> Registrant Contact
>       The individual/organization that is the registration contact for
>       the component being registered.  Ideally, this will be the name
>       and pertinent physical and network contact information.  In the
>       case of IETF developed standards, the Registrant will be the IESG.
> 
> In this case it seems that we do not deal with the 'usual' IETF
> developped standard and that the IRTF or the NMRG would be the more
> appropriate organization to be mentioned.

Since the allocation is actually IETF last called via the IESG, one
could argue that the IESG is the registration contact. But I am happy
to put there whatever allows us to move forward. What about:

   NMRG of the IRTF

/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] RE: URNallocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt
Date: Tue, 12 Feb 2008 15:29:30 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], Lisa Dusseault <[email-masked]>

This looks fine. 

One question:

>    Registrant Contact: The IESG.

Why would the IESG figure here as Registrant? 

RFC 3688 says:

Registrant Contact
      The individual/organization that is the registration contact for
      the component being registered.  Ideally, this will be the name
      and pertinent physical and network contact information.  In the
      case of IETF developed standards, the Registrant will be the IESG.

In this case it seems that we do not deal with the 'usual' IETF
developped standard and that the IRTF or the NMRG would be the more
appropriate organization to be mentioned.

Dan

 

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, February 12, 2008 3:53 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; Lisa Dusseault
> Subject: Re: [nmrg] RE: 
> URNallocationforhttp://www.ietf.org/internet-drafts/draft-irtf
> -nmrg-snmp-measure-02.txt
> 
> On Tue, Feb 12, 2008 at 02:36:59PM +0100, Romascanu, Dan (Dan) wrote:
>  
> > Actually, now that I am looking, the I-D needs to be 
> revised in order 
> > to make the explicit request to IANA to allocate
> > 
> > urn:ietf:params:xml:ns:snmp-trace-1.0
> > 
> > according to the procedure described in RFC 3688. If you do 
> it better 
> > to write a separate IANA considerations section to make 
> id-nits happy.
> 
> Here is what is already in my sources:
> 
> 6.  IANA Considerations
> 
>    This document requests that IANA register a URI for the SNMP XML
>    trace format namespace in the IETF XML registry [RFC3688]. 
>  Following
>    the format in RFC 3688, the following registration is requested.
> 
>    URI: Please assign the URI "urn:ietf:params:xml:ns:snmp-trace-1.0"
>    for use by the SNMP trace format.
> 
>    Registrant Contact: The IESG.
> 
>    XML: N/A, the requested URI is an XML namespace.
> 
> > Also this may be the right opportunity to make the 
> editorial changes 
> > suggested by David Harrington.
> 
> I am waiting for David's ack for the proposed edits. Once I 
> get it, I will post the updated ID and then things are back 
> in Bert's hands (as the document shepherd) and it should be 
> fine to last call the URN allocation.
> 
> /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, 12 Feb 2008 14:53:16 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: [nmrg] RE: URN allocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snm p-measure-02.txt
Mail-Followup-To: "Romascanu, Dan (Dan)" <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>
Cc: [email-masked], Lisa Dusseault <[email-masked]>
Reply-To: [email-masked]

On Tue, Feb 12, 2008 at 02:36:59PM +0100, Romascanu, Dan (Dan) wrote:
 
> Actually, now that I am looking, the I-D needs to be revised in order to
> make the explicit request to IANA to allocate 
> 
> urn:ietf:params:xml:ns:snmp-trace-1.0
> 
> according to the procedure described in RFC 3688. If you do it better to
> write a separate IANA considerations section to make id-nits happy. 

Here is what is already in my sources:

6.  IANA Considerations

   This document requests that IANA register a URI for the SNMP XML
   trace format namespace in the IETF XML registry [RFC3688].  Following
   the format in RFC 3688, the following registration is requested.

   URI: Please assign the URI "urn:ietf:params:xml:ns:snmp-trace-1.0"
   for use by the SNMP trace format.

   Registrant Contact: The IESG.

   XML: N/A, the requested URI is an XML namespace.

> Also this may be the right opportunity to make the editorial changes
> suggested by David Harrington. 

I am waiting for David's ack for the proposed edits. Once I get it,
I will post the updated ID and then things are back in Bert's hands
(as the document shepherd) and it should be fine to last call the
URN allocation.

/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] RE: URN allocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt
Date: Tue, 12 Feb 2008 14:36:59 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>, <[email-masked]>
Cc: [email-masked], Lisa Dusseault <[email-masked]>

Juergen,

Actually, now that I am looking, the I-D needs to be revised in order to
make the explicit request to IANA to allocate 

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

according to the procedure described in RFC 3688. If you do it better to
write a separate IANA considerations section to make id-nits happy. 

Also this may be the right opportunity to make the editorial changes
suggested by David Harrington. 

Thanks and Regards,

Dan

 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, 
> Dan (Dan)
> Sent: Monday, February 11, 2008 4:26 PM
> To: [email-masked]
> Cc: [email-masked]; Lisa Dusseault
> Subject: [nmrg] RE: URN 
> allocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nm
> rg-snmp-measure-02.txt
> 
> OK, I will push the right buttons in the next 24 hours or so. 
> 
> Dan
> 
> 
>  
>  
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> 
> > So bottom line is that I am happy with an IETF last call 
> for the URN 
> > allocation. And thanks for your help and support in this case.
> > 
> > /js
> 
> --
> !! 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.
> 
> This email was protected during delivery to Avaya with TLS encryption
> 
> 

Content-class: urn:content-classes:message
Date: Mon, 11 Feb 2008 15:26:10 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], Lisa Dusseault <[email-masked]>
Subject: [nmrg] RE: URN allocation forhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt

OK, I will push the right buttons in the next 24 hours or so. 

Dan

 

> -----Original Message-----
> From: Juergen Schoenwaelder 

> So bottom line is that I am happy with an IETF last call for 
> the URN allocation. And thanks for your help and support in this case.
> 
> /js

Date: Mon, 11 Feb 2008 14:39:50 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Mail-Followup-To: "Romascanu, Dan (Dan)" <[email-masked]>, [email-masked], Lisa Dusseault <[email-masked]>, Aaron Falk <[email-masked]>
Cc: [email-masked], Lisa Dusseault <[email-masked]>
Subject: [nmrg] Re: URN allocation for http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02. txt
Reply-To: [email-masked]

On Mon, Feb 11, 2008 at 02:28:16PM +0100, Romascanu, Dan (Dan) wrote:
> 
> Hi Juergen,
> 
> The IESG discussed on the last telechat the issue of URN allocation in
> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt.
> 
> 
> The minutes of the telechat concluded: 
> 
> > Action item: Dan Romascanu to send mail to nmrg/irtf proposing two 
> > options to move forward: 1. Last Call their document for the specific 
> > question according to the current RFC 3688 text, or 2. Defining a 
> > urn:irtf... space for the IRTF to manage.
> > Action item: Lisa Dusseault to resolve the ambiguity in registration 
> > requirements in RFC 3866.
>  
> Please let me know which of options 1 or 2 you prefer. If you chose
> option 1 I will sponsor the I-D though the IESG process, and the Last
> Call will make clear that the question that is asked is related to the
> URN allocation and not to the whole document.  If you chose option 2 the
> IRTF needs to work with IANA the creation of the urn:irtf space and you
> resubmit the I-D with modified IANA considerations asking for an
> allocation under urn:irtf. 

I prefer to get the document out quickly and with the least pain. The
problem is that nothing in the IETF process is predictable. Right now,
I assume option 1 is the least pain but I know that I have been wrong
with these sorts of predictions many times.

Whether there is a need for an urn:irtf space is something the whole
IRTF concerns and likely not just the NMRG. But since the ambiguity in
RFC 3866 does not seem to have been resolved, I think the best for the
IRTF is simply to wait. But this is something for Aaron to decide.

So bottom line is that I am happy with an IETF last call for the URN
allocation. And thanks for your help and support in this case.

/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: Mon, 11 Feb 2008 14:28:16 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>
Subject: [nmrg] URN allocation for http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt

Hi Juergen,

The IESG discussed on the last telechat the issue of URN allocation in
http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt.

The minutes of the telechat concluded: 

> Action item: Dan Romascanu to send mail to nmrg/irtf proposing two 
> options to move forward: 1. Last Call their document for the specific 
> question according to the current RFC 3688 text, or 2. Defining a 
> urn:irtf... space for the IRTF to manage.
> Action item: Lisa Dusseault to resolve the ambiguity in registration 
> requirements in RFC 3866.

Please let me know which of options 1 or 2 you prefer. If you chose
option 1 I will sponsor the I-D though the IESG process, and the Last
Call will make clear that the question that is asked is related to the
URN allocation and not to the whole document.  If you chose option 2 the
IRTF needs to work with IANA the creation of the urn:irtf space and you
resubmit the I-D with modified IANA considerations asking for an
allocation under urn:irtf. 

Thanks and Regards,

Dan

Date: Mon, 4 Feb 2008 15:29:41 +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]>, [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]

On Fri, Jan 25, 2008 at 04:25:20PM -0500, David B Harrington wrote:

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

fixed

> s/binding interface/interface/

changed

> s/can be store/can be stored/

already fixed

> s/an SNMP messages/an SNMP message/

fixed

> s/are able convert/are able to convert/

already fixed

> s/unneeded/unnecessary/

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

replaced "the most essential" with "selected" since this is more
neutral

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

There is already new text in place:

   While this document recommends that raw traces should be kept, it
   must be noted that there are situations where this may not be
   feasible.  The recommendation to keep raw traces may be ignored for
   example to comply with data protection laws or to protect a network
   operator from being forced to provide the data to other
   organizations.

I think this addresses your concerns.

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

The language has already been softened - it now says "such as Perl".

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

Is this text better:

3.1.  Basic Statistics

   Basic statistics cover things such as

   o  protocol version used,
   o  protocol operations used,
   o  message size distribution,
   o  error message type frequency, or
   o  usage of authentication and encryption mechanisms.

   In addition, the OID names of the objects manipulated can be
   categorized into OID subtrees, for example to identify
   'standardized', 'proprietary', and 'experimental' objects.

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

We already added a general warning to section 2.5. I changed it
slightly and now it reads as follows:

   It should be noted that any results produced by analyzing a trace
   must be interpreted in the context of the trace.  The nature of the
   network, the attachment point used to collect the trace, the nature
   of the applications generating SNMP traffic, or the events that
   happened while the trace was collected clearly influence the result.
   It is therefore important to be careful when drawing general
   conclusions based on a potentially (too) limited data set.
 
> 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.

I think this is already covered by the above paragraph - not in that
level of detail but I think that is also not needed. If you think more
detail is needed, please suggest concrete text.

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

Added the following paragraph:

   The periodic polling behavior may dependent on the application and
   the polling engine it uses.  For example, some management platforms
   allow applications to specify how long polled values may be kept in a
   cache before it is polled again.  Such optimizations needs to be
   considered when analyzing traces for periodic and aperiodic traffic.
 
> 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.

Added the following paragraph:

   Some SNMP implementations update their counters from the underlying
   instrumentation following adaptive algorthms, not necessarily
   periodically, and not necessarily on-demand.  The granularity of
   internal counter updates may impact latency measurements and should
   be taken into account.

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

Added the following paragraph:

   In addition, it will be interesting to analyze how many redundant
   requests coming from applications are processed almost simultaneously
   by a device.
 
> 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.

The text already suggests to place probes close to management
system(s) - so this should almost always give you *:m. And we do not
require to have an inventory of management applications listed (and in
fact we have seen traces where people were somewhat surprised where
the SNMP traffic was originating from). Note that the general warning
about the interpretation of results already mentions the influence of
the attachement point. So I did not change anything.

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

I did not make any changes here as I prefer to stay away from
discussing for each item what can be done with the results.

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

I believe this is covered by the general warning about generalizations
of results mentioned above.

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

Added the following paragraph:

   Depending on the data recorded in a trace, it might be possible to
   determine the age of devices by looking at values of objects such as
   sysObjectID and sysDecr [RFC3418].  The age of a device can then 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. 

I am not sure I understand your suggestion. We take a management
application as a black box - such a block box either generates
requests checking for discontinuity indicators or not. Nothing
changed.

> 4.1 Should the irtf establish its own namespace registry?

Ongoing discussion, right now in the hands of the IESG...

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

Filtering is a users' choice as is anonymization as is trap
conversion. And some of these things can even interact. I think the
recommendation is fine as is.

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

The filter-in principle is explained in never versions of the ID.

> Good job.

Thanks or the review. If you are fine with changes and I do not hear
objections, I will post an updated ID.

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