Subject: RE: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Sun, 30 Dec 2007 08:43:03 +0100
List-Id: Network Management Research Group <nmrg.ibr.cs.tu-bs.de>

I am not sure if I ack-ed previously but this version is OK with me. 

Dan

 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Saturday, December 29, 2007 12:07 AM
> To: [email-masked]
> Subject: Re: [nmrg] NMRF Last Call for 
> draft-irtf-nmrg-snmp-measure-02.txt
> 
> On Fri, Dec 07, 2007 at 06:51:15PM +0100, WIJNEN, Bert (Bert) wrote:
>  
> > Pls check if your comments have been addressed properly.
> > If not, pls let us know asap, preferably before 22 Dec 2007.
> > If no negative comments/objections are received by that 
> date, then we 
> > will go forward and ask for the IRSG review and further 
> steps towards 
> > publication as RFC.
> 
> It would be nice to get some more "green light" that the 
> changes that have been made address the comments received as 
> part of the first last call. Here again the URL:
> 
> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measu
> re-02.txt
> 
> A HTML version with links to a colored diff is here:
> 
> http://tools.ietf.org/html/draft-irtf-nmrg-snmp-measure-02
> 
> I have meanwhile implemented the format changes in snmpdump 
> (SVN revision 2403) - but I still have to update the test cases.
> 
> Have a good start into 2008!
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust !! your settings, send a mail message 
> to <[email-masked]> !! or look at 
> https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

Date: Fri, 28 Dec 2007 23:07:24 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt
Mail-Followup-To: [email-masked]
Reply-To: [email-masked]

On Fri, Dec 07, 2007 at 06:51:15PM +0100, WIJNEN, Bert (Bert) wrote:
 
> Pls check if your comments have been addressed properly.
> If not, pls let us know asap, preferably before 22 Dec 2007.
> If no negative comments/objections are received by that date,
> then we will go forward and ask for the IRSG review and 
> further steps towards publication as RFC.

It would be nice to get some more "green light" that the changes that
have been made address the comments received as part of the first last
call. Here again the URL:

http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt

A HTML version with links to a colored diff is here:

http://tools.ietf.org/html/draft-irtf-nmrg-snmp-measure-02

I have meanwhile implemented the format changes in snmpdump (SVN
revision 2403) - but I still have to update the test cases.

Have a good start into 2008!

/js

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

Content-class: urn:content-classes:message
Subject: RE: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt 
Date: Mon, 10 Dec 2007 22:02:20 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "WIJNEN, Bert (Bert)" <[email-masked]>, <[email-masked]>

The changes are fine with me. Thank you for addressing my comments. 

Dan

 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of WIJNEN, Bert (Bert)
> Sent: Friday, December 07, 2007 7:51 PM
> To: [email-masked]
> Cc: Aaron Falk
> Subject: [nmrg] NMRF Last Call for 
> draft-irtf-nmrg-snmp-measure-02.txt 
> 
> Dear NMRG participants.
> 
> This is a new version in which Juergen has tried to address 
> all comments we received on revision 01. He also posted 
> answers to the comments to the nmrg mailing list.
> 
> Pls check if your comments have been addressed properly.
> If not, pls let us know asap, preferably before 22 Dec 2007.
> If no negative comments/objections are received by that date, 
> then we will go forward and ask for the IRSG review and 
> further steps towards publication as RFC.
> 
> Bert Wijnen
> shepherd for this document
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of 
> > [email-masked]
> > Sent: Friday, December 07, 2007 9:10 AM
> > To: [email-masked]
> > Subject: [nmrg] I-D Action:draft-irtf-nmrg-snmp-measure-02.txt
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > 
> > 	Title           : SNMP Traffic Measurements and Trace 
> > Exchange Formats
> > 	Author(s)       : J. Schoenwaelder
> > 	Filename        : draft-irtf-nmrg-snmp-measure-02.txt
> > 	Pages           : 28
> > 	Date            : 2007-12-07
> > 
> > The Simple Network Management Protocol (SNMP) is widely deployed to 
> > monitor, control and (sometimes also) configure network elements.
> > Even though the SNMP technology is well documented, it remains 
> > relatively unclear how SNMP is used in practice and what 
> typical SNMP 
> > usage patterns are.
> > 
> > This document proposes to carry out large scale SNMP traffic 
> > measurements in order to develop a better understanding how SNMP is 
> > used in real world production networks.  It describes the 
> motivation, 
> > the measurement approach, and the tools and data formats needed to 
> > carry out such a study.
> > 
> > This document was produced within the IRTF's Network Management 
> > Research Group (NMRG) and represents the consensus of all of the 
> > active contributors to this group.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measu
> > re-02.txt
> > 
> > To remove yourself from the I-D Announcement list, send a 
> message to 
> > [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-02.txt".
> > 
> > A list of Internet-Drafts directories can be found in 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt".
> > 
> > NOTE:   The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > 
> 
> --
> !! This message is brought to you via the `nmrg' mailing list.
> !! Please do not reply to this message to unsubscribe. To 
> unsubscribe or adjust !! your settings, send a mail message 
> to <[email-masked]> !! or look at 
> https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg.
> 

Content-class: urn:content-classes:message
Date: Fri, 7 Dec 2007 18:51:15 +0100
From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
To: <[email-masked]>
Cc: Aaron Falk <[email-masked]>
Subject: [nmrg] NMRF Last Call for draft-irtf-nmrg-snmp-measure-02.txt 

Dear NMRG participants.

This is a new version in which Juergen has tried to address
all comments we received on revision 01. He also posted 
answers to the comments to the nmrg mailing list.

Pls check if your comments have been addressed properly.
If not, pls let us know asap, preferably before 22 Dec 2007.
If no negative comments/objections are received by that date,
then we will go forward and ask for the IRSG review and 
further steps towards publication as RFC.

Bert Wijnen  
shepherd for this document

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, December 07, 2007 9:10 AM
> To: [email-masked]
> Subject: [nmrg] I-D Action:draft-irtf-nmrg-snmp-measure-02.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 	Title           : SNMP Traffic Measurements and Trace 
> Exchange Formats
> 	Author(s)       : J. Schoenwaelder
> 	Filename        : draft-irtf-nmrg-snmp-measure-02.txt
> 	Pages           : 28
> 	Date            : 2007-12-07
> 
> The Simple Network Management Protocol (SNMP) is widely 
> deployed to monitor, control and (sometimes also) configure 
> network elements.
> Even though the SNMP technology is well documented, it 
> remains relatively unclear how SNMP is used in practice and 
> what typical SNMP usage patterns are.
> 
> This document proposes to carry out large scale SNMP traffic 
> measurements in order to develop a better understanding how 
> SNMP is used in real world production networks.  It describes 
> the motivation, the measurement approach, and the tools and 
> data formats needed to carry out such a study.
> 
> This document was produced within the IRTF's Network 
> Management Research Group (NMRG) and represents the consensus 
> of all of the active contributors to this group.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measu
> re-02.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [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-02.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 

Resent-From: [email-masked]
Resent-Date: Fri, 7 Dec 2007 18:19:01 +0100
Resent-Message-ID: <[email-masked]>
Resent-To: [email-masked]
To: [email-masked]
From: [email-masked]
Date: Fri, 07 Dec 2007 12:10:01 -0500
Subject: [nmrg] I-D Action:draft-irtf-nmrg-snmp-measure-02.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-02.txt
	Pages           : 28
	Date            : 2007-12-07

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

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

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

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

To remove yourself from the I-D Announcement list, send a message to
[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-02.txt".

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

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

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

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

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

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

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

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

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

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

Content-Type: text/plain
Content-ID: <2007-12-07120012.I-D\@ietf.org>

--OtherAccess--

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

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

--NextPart--

Date: Fri, 7 Dec 2007 16:31:29 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC
Mail-Followup-To: "Romascanu, Dan (Dan)" <[email-masked]>, [email-masked], "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], "Wijnen, Bert \(Bert\)" <[email-masked]>
Reply-To: [email-masked]

On Thu, Feb 15, 2007 at 01:41:06PM +0200, Romascanu, Dan (Dan) wrote:
> 
> Please find below my comments: 
> 
> 1. Section 1 : 
> 
>   'it is not clear which features are being used,
>    how SNMP usage differs in different types of networks or
>    organizations ...' 
>  
> I suggest to add to the list or begin the list with 'what protocol
> versions are being used'

changed
 
> 2. same:
> 
> This phrase is not clear to me: 
> 
>    'Furthermore, we do not generally
>    understand how much traffic is devoted to standardized MIB objects
>    and how much traffic deals with proprietary MIB objects and whether
>    the operation mix differs between these object classes or between
>    different operational environments.'
> 
> Maybe it is meant to say? 
> 
>   'Furthermore, we do not generally
>    understand how much traffic is devoted to standardized MIB objects
>    and how much traffic deals with proprietary MIB objects and whether
>    the operation mix between these object classes differs in various
>    operational environments.'

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

I now have:

   [...] Furthermore, we do not generally
   understand how much traffic is devoted to standardized MIB objects
   and how much traffic deals with proprietary MIB objects and whether
   the operation mix between these object classes differs between
   different operational environments (e.g., backbone networks, access
   networks, enterprise networks).
 
> 3. Section 2:
> 
> Explain what are 'pcap capture files'. Maybe a terminology and
> abbreviations section would help. 

I already added a reference.

> 4. Section 2.1: 
> 
> The concept of  ' stable storage (e.g., compressed and encrypted on a CD
> ROM or DVD).' Was 'stable' related to 'permanent'? Compression and
> encryption should be dealt separately, and if there is a need to protect
> privacy which seems to be the case this needs to be mentioned in the
> Security Considerations section. 

replaced 'stable' with 'permanent' and added a sentence to the
security considerations:

   In addition, it is recommended to encrypt traces when they are
   archived.

> 5. Section 3.1: 
> 
> PDU-type distribution and error messages frequency should be added to
> the list of basic statistics

added
 
> 6. Some place in Section 3, maybe in 3.1 I would add statistics related
> to the used of privacy protection mode, i.e. how much of the traffic is
> protected by using encrypted payload. Note that if priv is used many of
> other measurements may not be possible. 

added

> 7. Section 3.4: 
> 
> The concept of 'concurrency level' is not clear to me. What is the goal
> and the metric here? To determine to how many agents a management
> application is working simultaneously or in a given time window? Why is
> this important? 

I think it is reasonable to ask the question whether management
stations distribute the workload fairly over a time window and over
the number of devices they talk to.

> 8. Section 3.5:
> 
> The use of the term 'cell-by-cell' when referring to tables is
> inconsistent with the SMI terminology

changed to 'object-by-object'

/js

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

Date: Fri, 7 Dec 2007 16:13:15 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Luca Deri <[email-masked]>
Subject: Re: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
Mail-Followup-To: Luca Deri <[email-masked]>, [email-masked], "Wijnen, Bert ((Bert))" <[email-masked]>
Cc: [email-masked], "Wijnen, Bert \(\(Bert\)\)" <[email-masked]>
Reply-To: [email-masked]

On Fri, Feb 16, 2007 at 11:45:56PM +0100, Luca Deri wrote:

> - I think that the use of XML and CSV are two opposites. XML is
> quite thick (an SNMP PDU converted to XML takes definitively more
> space), it requires some knowledge, and I don't think is the best
> format for creating statistics as those described in chapter 3. On
> the other hand the CSV format, as specified in 4.2, needs further
> specification work as two CSV files for the same .pcap file can look
> very different even if they both adhere to 4.2. If both XML and CSV
> have limitations, I'm asking myself if pcap-based API (such as those
> offered by snmpdump) plus anonymized .pcap isn't a more flexible
> solution

The reason we do not use plain pcap is that parsing BER and doing
things like packet reassembly is not much fun. It is really convenient
to do this once and then code further analysis programs from a much
simpler input format. I do not see that two CSV files produced from
the same .pcap file can look different, unless you apply anonyzation
or filtering.

No change made.

> - the author should further specify what filtering means. Is it
> close to that tools like wireshark offer (you can filter on each
> PDU-decoded field) or is something different?

This is kind of implementation dependent. Our snmpdump tool can filter
out whole messages using pcap expressions and it can filter out values
based on protocol fields. I don't think we need to "standardize" on
how tools work. We aim at interoperability of the exchange format, not
the tools.

No change made.

> - chapter 5 should be expanded; I would like to read some examples
> of anonymization beside some basic IP/community (e.g. field name,
> example of anonymized values) and also better understand what
> "anonymization transformations" are in practice.

I have added some more references for the interested readers. Note
that I do not want this document to become a tool specification; it
aims at being an interchange format specification and a motivation for
doing this work.

Partially already addressed.

/js

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

Date: Fri, 7 Dec 2007 13:57:54 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Medhi, Deep" <[email-masked]>
Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
Mail-Followup-To: "Medhi, Deep" <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]

On Sat, Feb 17, 2007 at 12:39:15AM -0600, Medhi, Deep wrote:
 
> Overall, this is a good document. Here are my comments:
> 
> 1. I noticed some disconnect between the abstract and the rest of the
> document. "SNMP usage patterns" in the abstract conveys the notion of
> frequency or how often it is used---however, that's not what is conveyed
> in the rest of the document. I found the last paragraph of Introduction
> (that starts with "This document describes ...") to be a better
> representative of the content of the document -- thus, some sentences or
> rewording from this paragraph should be included in the abstract,
> instead.

The first paragraph of the abstract sets the stage and provides
motivation - and yes the motivation is to understand SNMP usage
patterns. The second paragraph clearly states what the contribution of
this document is and I think it is quite clear and on target.

So I am not sure what needs to be changed. You perhaps have a narrower
interpretation of the word "pattern" but I did not really find a
better word.

So no change made.
 
> 2. Some "measure" about how much the raw data might get enlarged to
> when XML is used should be given. This assessment can be provided
> for a typical MIB a user is likely to collect.

It is difficult to put down such numbers since you can always debate
them. See also below.

> 3. An example entry, each for XML and for CSV, should be included.
> Although, this may look redundant for CSV, because of the each field
> described, this is still helpful. For example, it would look like
> 
> Fro IPv4,
>   
>  1137764769.425484,127.0.0.1,4242, ...
> 
> For IPv6, 
> 
>  1137764769.425484,::1,4242, ...

This is a very good idea. I have added examples for both the XML and
CSV representation.
  
> 4. Collected data for different MIBs and environments (e.g., core
> network, or enterprise network) could be quite in different size, which
> would also depend on how often data is collected. Is it possible to give
> some idea about how "big" the size of data collected for an example
> scenario? So far, it only talks about collecting data for a week.

This is related to your comment above. You can find some information
in our IM 2007 paper and I think this is where it belongs since we
discuss concrete traces there.

> 5. Preferential format to store data might be quite different for
> different environments and needs. For example, a core network provider
> is more likely to use CSV. Thus, some guideline on where one might be
> appropriate over the other would be good to discuss.

Hm. There are many factors that go in choosing a format and some are
clearly non-technical. I would rather not add such a discussion unless
someone provides suitable text to include.
 
> 6. Below are a couple of more references on IP address anonymization:
> 
> Jinliang Fan, Jun Xu, Mostafa H. Ammar, Sue B. Moon: Prefix-preserving
> IP address anonymization: measurement-based security evaluation and a
> new cryptography-based scheme. Computer Networks 46(2): 253-272 (2004) 
> 
> Jun Xu, Jinliang Fan, Mostafa Ammar, Sue Moon, "Prefix-Preserving IP
> Address Anonymization", Proceedings of the IEEE International Conference
> on Network Protocols, 2002. 

I have added several references to related anonymization work since
many people seem to find this useful information.

/js

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

Date: Fri, 7 Dec 2007 12:48:36 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "David T. Perkins" <[email-masked]>
Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC
Mail-Followup-To: "David T. Perkins" <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]

On Tue, Feb 13, 2007 at 03:03:41PM -0800, David T. Perkins wrote:

> I re-read the doc. It is technically Ok except for the data types
> of values specified in section 4.1 and 4.2. First, section 4.2
> is missing opaque found in section 4.1. Secondly, both are missing
> data type "netAddr". Third, I believe that mapping types counter32,
> gauge32, and timeticks to unsigned32 loses info and should not
> be done. Also, counter64 should not be mapped to unsigned 64.

The data types have been aligned to match SNMP. I did not add
"netAddr" since something like that does not exist on the wire.

> Note a wonder what is done if a ASN.1 type that is not defined
> in SNMP (or was specified in an obsolete version of SNMP) is
> used. How is the type specified. It's not incorrect, but I
> suggest that type "ipaddress" be renamed to "ipv4address".

We decided in Prague to stick with the SNMP/SMI names for types and
PDUs.

> Section 4.2 describes encoding of IPv6 address values. However,
> there is no ipv6addr type, and thus, this description is
> describing a value that will never exist, and is misleading.

The IPv6 addresses can exist in the src/dst address of the UDP
datagram carrying an SNMP message and this is why we need them.  You
are right that the definitions don't affect the SNMP payload.

> Suggestions for additions:
> 1) section 2 has the measurement approach. I'd like to hope
>    that it include a step for annotations (which is called
>    adding meta data later in the document). That is, put
>    in an explicit step such as "at 20070213 12:02:01 started
>    configuration app to add new DSL service" and "at 20070213
>    12:05:45 finished configuration operation". Or
>    "at 20070213 02:09:56 link down occured on dtp45:p2" and
>    "at 20070213 02:11:01 link up occured on dtp45:p2".

There is now this text:

   For each captured trace, some meta data should be recorded and made
   available.  The meta data should include information such as where
   the trace was collected, when it was collected, contact information,
   the size of the trace, any known special events, equipment failures,
   or major infrastructure changes during the data collection period and
   so on.

I think this addresses your point.

> 2) Add additional examples in last para of section 2.1

Not sure what is missing - no change made.

> 3) Add a section, such as 2.2, about suggesting the creation
>    of test (or baseline) traces that are artificial and
>    are used to demonstrate a behavior (such as retrieving
>    a table a cell at a time in column order,  showing
>    all data types, or a wide range of packet size
>    distribution.)

I believe this is tool implementation specific or general good
software development practice to have test cases. No change made.

> 4) I'd like to see 2 formats for "object names". The
>    first just splits the OID of the object type from
>    the OID fragment encoding the instance specification.
>    The second additionally decodes the OID fragment
>    into values. For example, instead of just
>      1.2.3.4.5.6.1.2.3.4.3.44.54.50,
>    format #1 would be
>       1.2.3.4.5.6$1.2.3.4.3.44.54.50
>    format #2 would be
>       1.2.3.4.5.6[ipv4:1.2.3.4][vstr:3:"DTP"]
>    And of course, to do the above, you need the
>    object type definition info from MIB modules,
>    and you have to deal with instance encoding
>    bugs.

So far, the conversion process does not require MIB information and I
like to keep it that way. I also prefer to have a single simple
representation rather than having to deal with different formats when
I process a trace.

<soap>
  What you are suggesting clearly is useful since nobody is really
  able to read OIDs. So I created a tool smixlate (part of libsmi)
  which is like cat but looks for character sequences that look like
  OIDs. If it finds a string that looks like an OID, it translates it
  into something human friendly. Having such a standalone tool is
  actually great for many purposes (I sometimes just cut'n'paste
  OIDs into it which is faster than grepping around.)
</soap>

/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: Fri, 7 Dec 2007 12:09:24 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Wes Hardaker <[email-masked]>
Mail-Followup-To: Wes Hardaker <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Cc: [email-masked], "Wijnen, Bert \(Bert\)" <[email-masked]>
Subject: [nmrg] Re: nmrgNMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC
Reply-To: [email-masked]

On Mon, Feb 12, 2007 at 05:39:09PM -0800, Wes Hardaker wrote:
 
> - ethereal -> wireshark  [wireshark is the new name for the ethereal project]

changed
 
> - I don't think the document should be recommending one software
>   package over another for dealing with XML, etc.  For example, in
>   perl it is repeatedly recommended to use the XML::libXML parser.
>   That parser is a very good one, but is designed for the XML (DOM)
>   knowledgeable coder and I wouldn't be surprised if a large part of
>   the target audience may not be that familiar with proper DOM APIs
>   (yes, I know it has others too).  XML::Simple, on the other hand, is
>   very popular as well because it pulls in XML data into structures
>   that perl coders understand: perl structures.  Instead, why not
>   reference a web page that describes how to choose a parser?
>   http://perl-xml.sourceforge.net/faq/ is probably the best place for
>   perl programmers to go.  In short, people should use XML code bases
>   not on the recommendation of the author, but rather based on the
>   needs of the programmer.

Sure. The perl-xml site is great. I have reworded the text fragments
into the following:

   Filtering sensitive data can be achieved by manipulating the XML
   representation of an SNMP trace.  Standard XSLT processors (e.g.,
   xsltproc [6]) can be used for this purpose.  People familiar with the
   scripting language Perl might be interested in choosing a suitable
   Perl module to manipulate XML documents [7].

   [...] However, in order to facilitate a common
   vocabulary and to allow operators to easily read scripts they execute
   on trace files, it is suggested that analysis scripts are written in
   scripting languages such as Perl using suitable Perl modules to
   manipulate XML documents [7].

   [6]  <http://xmlsoft.org/XSLT/>

   [7]  <http://perl-xml.sourceforge.net/faq/>

> - I didn't see any statements (but again, it was a quick scan) about
>   being careful about drawing conclusions based on a limited amount of
>   data but I'd be tempted to insert something like that.  Also, having
>   operators document how their network was behaving during the period
>   is probably a good idea.  IE, if there was major network
>   infrastructure changes going on but still no SNMP SET data was seen
>   that gives a much better chance of detecting that SETs aren't in use
>   than if it was a quiet week where no changes were being made to the
>   network.  IE, you need to know something about the environment
>   you're monitoring to get a good feel for what type of data you can
>   expect to be able to see.  Were there problems?  Were changes being
>   made?...

The relevant text at the end of section 2.1 now reads as follows:

   For each captured trace, some meta data should be recorded and made
   available.  The meta data should include information such as where
   the trace was collected, when it was collected, contact information,
   the size of the trace, any known special events, equipment failures,
   or major infrastructure changes during the data collection period and
   so on.

I addition, I added the following to section 2.5: 

   I should be noted that any results produced by analyzing a trace must
   be interpreted in the context of the trace.  The nature of the
   network, the attachment point used to collect the trace, or the
   events that happened while the trace was collected clearly influence
   the result.  It is therefore important to be careful with drawing
   general conclusions based on a potentially limited data set.

/js

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

Date: Fri, 7 Dec 2007 11:45:27 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Giorgio Nunzi <[email-masked]>
Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt forInformational RFC
Mail-Followup-To: Giorgio Nunzi <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]

On Fri, Feb 09, 2007 at 11:43:07AM +0100, Giorgio Nunzi wrote:

> - Motivations (contained in par.1): the document mentions only the
>   importance for the research community. I would expect that
>   providers can benefit from SNMP measurements too, because they can
>   improve their management processes and scripts. In other words,
>   providers can use management traffic statistics in the same way
>   they are already using data traffic statistics.

I have added another paragraph to the introduction to make this
clearer:

        While the SNMP trace collection and analysis effort was
        initiated by the research community, it should be noted that
        network operators can benefit from the SNMP measurements too.
        Several new tools are being developed as part of this effort
        that can be used to capture and analyze the traffic generated
        by management stations. This resulting information can then be
        used to improve the efficiency and scalability of management
        systems.

> - Permanent store of raw traces. The document strongly suggests to
>   store raw traces (i.e. those without anonymization filtering), but
>   I think that this might require an additional effort to providers
>   (e.g. raw traces should be store securely and in a different place
>   than the anonymized traces). I understand that raw traces can be
>   used again if the scripts makes somehow wrong transformation
>   (i.e. they contains some bugs). However I think that in this
>   (unlucky) case we should simply trash the bad traces, fix the
>   scripts and take new fresh traces. Frank had similar opinion on
>   this.

I added text to address this, see my response to Frank's review.

> Finally, a small suggestion: can't we upload a complete W3C XML
> schema somewhere (e.g. NMRG web page)? This would make the work
> accessible to more people, if possible.

I will see whether I can put things up somewhere. Right now, the
sources of the ID are contained in the subversion system of the
snmpdump package. I have checked the trang XSD conversion into the
subversion system so we have everything in one place.

https://trac.eecs.iu-bremen.de/projects/snmpdump/browser/trunk/doc

/js

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

Date: Fri, 7 Dec 2007 09:36:27 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Frank Strau? <[email-masked]>
Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC
Mail-Followup-To: Frank Strau? <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]

On Wed, Jan 31, 2007 at 04:43:11PM +0100, Frank Strau? wrote:

> I have read the document and came up with the following comments:
>
> - General:
>
>   What about a glossary to introduce a few common terms for the
>   entities and processing steps? I would love to see a figure that
>   shows these entities and steps with their relationships and the
>   levels of concrete/anonymized/meta data. This could especially help
>   to make clear in which spheres anonymized and non-anonymized data
>   could reside. (I still have my problems with this question.)

Since there is no concrete proposal and I do not understand what is
missing, I have not made any specific changes.

> - Section 1, 2nd paragraph
>
>   It looks a bit unfair to state that the mentioned performance
>   related publications are based on speculations about SNMP
>   performance. I propose to rephrase the last sentence to something
>   like: "In fact, there are many speculations how SNMP is being used
>   in real world production networks and performance comparisons are
>   based on limited test cases, but no systematic wide-range
>   measurements have been performed and published so far."

changed

> - Section 2.1, 1st paragraph
>
>   You should probably also write a few words about the (unlikely) case
>   of fragmented packets.

Section 2.2 talks about reassembly and I think this is where this
belongs since you can't change anything when you capture packets.

> - Section 2.1, concerning port monitoring
>
>   In practice, such monitoring ports cannot always be configured this
>   way. E.g., our (relatively new) Nortel switches allow a monitoring
>   port only to monitor no more than two other ports or up to two MAC
>   addresses on any port. I have no experience with other vendors, but
>   I guess it is a general question of available CPU and bandwidth
>   resources on a device's management plane.

I added:

   [...] Some bridges have restrictions
   concerning their monitoring capabilities and this should be
   investigated and documented where necessary.

> - Section 2.1, 3rd paragraph concerning h/w checksum offloading
>
>   Why do you suggest to turn offloading off? In my opinion, wrong
>   checksums in traces don't hurt. A short note, so that people don't
>   wonder about wrong checksums should be enough.

The text now says:

   Several operating systems can offload some of the TCP/IP processing
   such as the calculation of transport layer checksum to network
   interface cards.  Traces that include traffic to/from a capturing
   interface which supports TCP/IP offloading can include incorrect
   transport layer checksums.  The simplest solution is of course to
   turn checksum offloading off while capturing traces (if that is
   feasible without loosing too many packets).  The other solution is to
   correct or ignore checksums during the subsequent analysis of the raw
   pcap files.

I think this covers both approaches (turning offloading off or
correcting/ignoring checksums after the trace has been captured).

> - Section 2.1, 4th paragraph concerning pcap backups/archives
>
>   Hm. I don't like this paragraph. Software should be "mature enough"
>   before you ask people to use it. At least, integrety and correctness
>   of data at steps 4+5 should remain the responsibilty of the party
>   who would like to collect the measurements.

The party capturing raw traces may choose to run software to provide
anonymized or stripped data to researchers. And software can have bugs
or it is simply applied in a way that later turns out to be
problematic (e.g. stripping data that would have been useful to keep).
We have seen this already happening and it was really useful to be
able to go back to the original traces. So I am keeping the text.

> - Section 2.2, 1st paragraph
>
>   Pcap files *are* machine readable. Porposal: "...that are human
>   readable while remaining also machine readable for ..."

changed

> - Section 2.2, 2nd paragraph
>
>   s/a [OASISRNG] schema/a RELAX NG schema [OASISRNG]

fixed

> - Section 2.2, 4th paragraph concerning h/w checksum offloading again
>
>   I suggest to make checksum error ignorance mandatory. See another
>   comment above.  Are you sure that pcap files recorded with a tool
>   like tcpdump and with the aforementioned filter expression contain
>   IP fragments at all? I didn't check it.

Changed should to must. And yes, tcpdump captures fragments (and our
snmpdump tool reassembles them).

> - Section 2.2, last paragraph concerning XML and CSV formats
>
>   So snmpdump cannot read CSV and creating CSV is one-way? Maybe, it's
>   worth to state this explicitly. Furthermore, I would prefer to
>   decide for one format. That would make data handling, script
>   authoring, etc. much easier.

At the time this text was written, snmpdump did not read CSV
format. This has been changed some time ago and so I have updated the
text.

> - Section 2.3, 1st paragraph concerning Perl
>
>   The Perl community names it "modules" instead of "packages",
>   AFAIK. If you decide to change it, also grep for subsequent
>   occurances of the word "package".

fixed

> - Section 2.3, 2nd paragraph concerning anonymization retaining lexi-order
>
>   It would be fine to have this feature mature enough so that this is
>   no longer work in progress when the document is ready to become an
>   Informational RFC.  Maybe it already is, since HS06 was published in
>   April 2006? However, the goal seems to be non-trivial to me,
>   especially when you want to be able to merge traces, right?
>
>   I'm generally missing more information about anonymization. Which
>   pieces of information can or should be anonymized? Wouldn't it be
>   meaningful to add a flag to the schema to signal which pieces have
>   actually been anonymized?  Should a value A that has been anonymized
>   to value B be anonymized to B again in subsequent occurances? If
>   yes, how could this mapping be maintained for merged traces? I think
>   there are quite some interesting questions. :-)

I added some additional text:

          [...] Note that           
          anonymization transformations are often bound to an
          initialization key and depend on the data being anonymized
          in an anonymization run.  As a consequence, users must be
          careful when they merge data from independently anonymized
          traces.                                   

>   A central question for this document is, whether these issues should
>   be addressed here or whether they should be left to implementors or
>   to other documents. In the latter case, it should be made clear that
>   the schema specified in this document can be expanded somehow.

The topic of anonymization always pops up when you approach people to
get trace data. So I believe it needs to be mentioned here. Of course,
this document is not intended to go into lengthy details about this
subject.

> - Section 2.4, 1st paragraph concerning storage of pcap and processed data
>
>   Why should they be stored together? My understanding is that the
>   person that records the trace may be interested in anonymization of
>   the data. So pcap data MIGHT be archived by the user that applies
>   steps 1-3 (see also above), and the XML or CSV data is stored in the
>   repository.

Changed "together with" to "as well as".

> - Section 2.4, last paragraph concerning storage of original pcap data
>
>   Due to the obvious conflict in the interests of the data supplier
>   (anonymized data) and the repository operator (availabilty also of
>   source data), I suggest to drop the strict need to keep the original
>   data.

I have added the following paragraph:

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

> - Section 3.6, 2nd paragraph
>
>   s/identity/identify/

fixed

> - Section 3.9
>
>   a/Assumption/Assumptions/

fixed

> - Section 3.12
>
>   Please give a reference to RFC 2579.

added an informative reference to RFC 2579

> - Section 4.1, the RNG Schema
>
>   I did not read the schema carefully, primarily because I'm not very
>   familiar with Relax NG. Maybe some of the comments in Section 4.2
>   also apply to this schema.
>
>   I tried to convert the schema to XSD using trang, but only got a
>   trang segfault on Debian/sarge, so I'm not sure whether I did
>   something wrong, whether there is an error in the schema, or whether
>   just my trang is broken.
>
>   Are elements by default optional? I suggest to make almost all
>   pieces of information optional, so that data suppliers can remove
>   those pieces of information that they have to hide for any reason.

I think the stuff is OK; my version of trang does produce XSD output
and I use tools to validate our XML output against the RNC schema.
Note that only pattern has been broken into two lines due to the ID
and RFC formatting restrictions.

> - Section 4.2, CSV value #8 (SNMP protocol operation)
>
>   Maybe, it would be better to delay decoding of the SNMP operation
>   (and probably other types of decoding) to the analysis step, so that
>   (obscure and very unlikely) cases of non-standard operations could
>   also be handled? If you want to have such values in a human readable
>   form, maybe a mixture of text (if well-known an decodeable) and
>   numeric (if unknown) values would be doable.

Discussed in Prague and on the list and decided to make no changes.

> - Section 4.2, CSV value #10 (SNMP error-status)
>
>   Why do you decode protocol operations to keywords, and keep
>   error-status as a numeric value?

Discussed in Prague and on the list and decided to make no changes.

> - Section 4.2, CSV value #13/3 (object values)
>
>   Does this mean, that exception names appear twice? Wouldn't it be
>   better to keep the third value empty in case of exceptions?

Yes. I have removed the sentence and added that in case of exceptions,
the object value field is empty.

> - Section 5, 1st paragraph on sensitive data
>
>   It is a subjective matter what pieces of information are
>   "unneeded". I propose something like s/unneeded/unwanted/.

changed

> - Section 5, 2nd paragraph
>
>   s/suppress/suppress or anonymize/ ?

changed

/js

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

Date: Thu, 6 Dec 2007 22:13:08 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: Re: [nmrg] future of the snmp measurement document - shepherdingvolunteer needed
Mail-Followup-To: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]

On Mon, Jan 29, 2007 at 11:04:45AM +0100, Wijnen, Bert (Bert) wrote:

> I reviewed the document and have the following comments,
> just NITS and TYPOs
> 
> - abstract
>   In order to prevent discussion/questioning about it, you might want
>   to de-emphasize the "configuration" usage of SNMP. How about changing
> 
>    The Simple Network Management Protocol (SNMP) is widely deployed to
>    monitor, control and configure network elements.  Even though the
> 
>   wo something aka
> 
>    The Simple Network Management Protocol (SNMP) is widely deployed to
>    monitor, control and (sometimes also) configure network elements.  
>    Even though the

changed
 
> - page 6
>    It is recommended to capture at least a full week of data.  Operators
>    are encouraged to capture traces over even longer periods of time.
>    Tools such as tcpslice [1] or pcapmerge [3] can be used to merge or
>    split pcap trace files as needed.
> 
>   I would change "to merge or split" into "to split or merge" so that
>   you have the same sequence as the "tcpslice pr pcapmerge".

changed
 
> - page 6
>    For each captured trace, some meta data should be recorded and made
>    available.  The meta data should include information such as where
>    the traces was collected, when it was collected, contact information,
> 
>   s/the traces/the trace/  ??

fixed
 
>    the size of the trace, any known special events during the data
>    collection period and so on.  It is also extremely useful to provide
>    a unique identification.  There are special online services such as
>    DatCat [4] where meta data can be store and which provide unique
>    identifiers.
> 
>   s/can be store/can be stored/

fixed

> - section 4.2
>    The comma separated values (CSV) format has been design to capture
> 
>   s/has been design/has been designed/ 

fixed

>   2.   Source IP address in dotted quad notation (IPv4), for example
>        "127.0.0.1", or compact hexadecimal notation (IPv6), for example
>        "::1".
> 
>   Would it not be better to use the reserved addresses for example as
>   per RFC3330 and RFC3849!!??

yes, fixed

>    8.   SNMP protocol operation indicated by one of the keywords get-
>         request, get-next-request, get-bulk-request, set-request, trap,
>         trap2, inform, response, report.
> 
>   I onder why sme operations are represented by the full name, while
> other
>   are represented by a name that is not complete.
>   Why not use the pdu-names as per RFC3416L
>    PDUs ::= CHOICE {
>         get-request      GetRequest-PDU,
>         get-next-request GetNextRequest-PDU,
>         get-bulk-request GetBulkRequest-PDU,
>         response         Response-PDU,
>         set-request      SetRequest-PDU,
>         inform-request   InformRequest-PDU,
>         snmpV2-trap      SNMPv2-Trap-PDU,
>         report           Report-PDU }
> 
>   So change inform to inform-request and trap2 to snmpV2-trap 

changed

>    13.  For each varbind in the varbind list, three output elements are
>         generated
> 
>         1.  Object names given as object identifiers in dotted decimal
> 
>   s/Object names given as object identifiers/Object name goven as object
> identifier/
>   That is make it singular instead of plural?  After all you speak "for
> each object",
>   and it seems to me that for one object you have only one name/oid.
>   Same for sub-points 2 and 3.

yes, all changed to singular

>         2.  Object base type name or exception names, that is one of the
>             following: null, integer32, unsigned32, unsigned64,
>             ipaddress, octet-string, object-identifier, no-such-object,
>             no-such-instance, and end-of-mib-view.
> 
>   Is the 'unsigned64' meant to be used for Counter64? 

yes, fixed
 
> - security considerations section:
>     Anonymization techniques can be applied to keep more information in
>     traces which could reveal sensitive information.  When using 
> 
>   s/could reveal/could otherwise reveal/ ??

fixed

> - general
>   You use "bytes" instead of "octets". 
>   I know some IETF people prefer "octets". 

changed

> - references.
>   not sure I understand why RFC3418 is normative while 2863 is
> informative.
>   same for some other RFCs. But I can live with it.

RFC3418 is not informative

/js

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