Subject: [nmrg] meeting preparation
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Date: Mon, 30 Apr 2001 11:36:08 +0200

I would like to ask people who have proposed agenda items to provide
pointers where people attending the meeting can obtain some background
information. In general, I prefer to use the Internet-Drafts repository
to distribute them, but I understand that sometimes this does not work
for several reasons.

Aiko, can we expect say an ID which describes the MIB Object
Information Lookup Service before the NMRG meeting? Or which other
document to you want us to study before the NMRG meeting?

Jean-Philippe, which document should we read to prepare ourself for
the Universal Information Model discussion? If you can not make things
publically available, is it possible to distribute material privately
to those who plan to attend the meeting?

Dave Perkins, can you write down a problem statement or a proposal
regarding "Simple Capabilities Tables and Session-Based Security"
which folks can read before the NMRG meeting?

/js

Date: Thu, 26 Apr 2001 16:42:41 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative)
Sender: [email-masked]

>>>>> Wes Hardaker writes:

Wes> Ahh, I was just curious as to why the working group was
Wes> discussing a particular implementation that wasn't going to be
Wes> standardized.  Seemed a bit out of scope (but cool, don't get me
Wes> wrong).

The purpose of an IRTF research group is not to define standards. This
is still the job of the IETF. The goal of this group is to discuss new
ideas or proposals in order to develop a better understanding of the
problem space and to draft potential technical solutions.

So I believe that the topic is well in scope, especially since Frank
had some ideas to solve a similar (or the same?) problem when he
originally designed libsmi.

/js

From: Frank Strauss <[email-masked]>
To: Wes Hardaker <[email-masked]>
Cc: Aiko Pras <[email-masked]>, Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative)
Date: 26 Apr 2001 16:39:12 +0200
Lines: 14
Sender: [email-masked]

Hi!

Frank> No. Well, `hope' maybe. But I don't intend to put substantial
Frank> efforts here in the near future. I just intend to share
Frank> thoughts with Aiko.  Maybe, he has more substantial plans.

Wes> Ahh, I was just curious as to why the working group was discussing a
Wes> particular implementation that wasn't going to be standardized.
Wes> Seemed a bit out of scope (but cool, don't get me wrong).

Please note, that the NMRG is a research group, not an engineering
working group. ;-)

 -frank

To: Frank Strauss <[email-masked]>
Cc: Aiko Pras <[email-masked]>, Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative)
From: Wes Hardaker <[email-masked]>
Organization: Network Associates - NAI Labs
Date: 26 Apr 2001 07:30:04 -0700
Lines: 14
Sender: [email-masked]

>>>>> On 25 Apr 2001 20:04:53 +0200, Frank Strauss <[email-masked]> said:

Frank> No. Well, `hope' maybe. But I don't intend to put substantial
Frank> efforts here in the near future. I just intend to share
Frank> thoughts with Aiko.  Maybe, he has more substantial plans.

Ahh, I was just curious as to why the working group was discussing a
particular implementation that wasn't going to be standardized.
Seemed a bit out of scope (but cool, don't get me wrong).

-- 
Wes Hardaker
NAI Labs
Network Associates

From: Frank Strauss <[email-masked]>
To: Wes Hardaker <[email-masked]>
Cc: Aiko Pras <[email-masked]>, Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative)
Date: 25 Apr 2001 20:04:53 +0200
Lines: 17
Sender: [email-masked]

Hi!

Juergen> 1. MIB Object Information Lookup Service (Aiko Pras, Saturday) 

Frank> Aiko, I'd like to let you know in advance of the meeting, what
Frank> I had in mind some time ago. Here is a part of a mail I've sent
Frank> some time ago when you first announced your work on the MIB
Frank> lookup service...

Wes> Is it your hope that the lookup protocol is going to be standardized
Wes> and thats the reason its going to be discussed?

No. Well, `hope' maybe. But I don't intend to put substantial efforts
here in the near future. I just intend to share thoughts with Aiko.
Maybe, he has more substantial plans.

 -frank

To: Frank Strauss <[email-masked]>
Cc: Aiko Pras <[email-masked]>, Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative)
From: Wes Hardaker <[email-masked]>
Organization: Network Associates - NAI Labs
Date: 25 Apr 2001 09:13:44 -0700
Lines: 16
Sender: [email-masked]

>>>>> On 25 Apr 2001 17:56:26 +0200, Frank Strauss <[email-masked]> said:

Juergen> 1. MIB Object Information Lookup Service (Aiko Pras, Saturday) 

Frank> Aiko, I'd like to let you know in advance of the meeting, what
Frank> I had in mind some time ago. Here is a part of a mail I've sent
Frank> some time ago when you first announced your work on the MIB
Frank> lookup service...

Is it your hope that the lookup protocol is going to be standardized
and thats the reason its going to be discussed?

-- 
Wes Hardaker
NAI Labs
Network Associates

From: Frank Strauss <[email-masked]>
To: Aiko Pras <[email-masked]>
Cc: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative)
Date: 25 Apr 2001 17:56:26 +0200
Lines: 40
Sender: [email-masked]

Hi!

Juergen> Topics to be discussed during the meeting: 

Juergen>  1. MIB Object Information Lookup Service (Aiko Pras, Saturday) 

[...]

Aiko, I'd like to let you know in advance of the meeting, what I had
in mind some time ago. Here is a part of a mail I've sent some time
ago when you first announced your work on the MIB lookup service...

    This sounds interesting to me, especially if you would intend to build
    it on top of (or even integrated with) the libsmi. ;-) In the early
    days of the libsmi design I had a similar idea:
    
      (a) a server that is built on top of the SMI library, that serves
          connecting clients that use the server to serve SMI related
          requests.
    
      (b) a libsmi input driver that makes the library talks to such a
          server (or even a list of servers, if the first one doesn't know
          the answer) if the configured SMIPATH is configured
          appropriately.
    
    This rough idea looked very nice to me, but soon a number of problems
    became visible and we shelved this plan.
    
    However, if your work on this topic starts, I would be interested in
    it.

This is still true. I would see some benefit, if your service could be
applicable by a libsmi input driver. However, it could be hard to align
both efforts.

 -frank

Date: Wed, 25 Apr 2001 17:15:37 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] 9th nmrg meeting agenda (tentative)
Sender: [email-masked]

The 9th NMRG meeting will take place in Seattle (USA) on May 12-13
2001, just before the IM 2001 conference. The meeting will be held at
the Westin Hotel in the Whidbey Room from 10:00am-5:00pm.

The address of the meeting place is: 

         Westin Seattle
         Whidbey Room
         1900 Fifth Avenue
         Seattle, WA 98101

         Phone: (206) 728-1000
         Fax: (206) 728-2259 

Topics to be discussed during the meeting: 

 1. MIB Object Information Lookup Service (Aiko Pras, Saturday) 

 2. Recent IETF Activities (SMIng, EOS) and the NMRG (Juergen
    Schoenwaelder, Saturday) 

 3. Universal Information Models (Jean-Philippe Martin-Flatin, Sunday) 

 4. Simple Capabilities Tables and Session-Based Security 
    (David T. Perkins, Sunday)

I expect at this point in time that we will focus most of our time on
topics 1 and 3 since I know that Aiko and Jean-Philippe have done some
serious work in that area.

Do not hesitate to air your comments on the proposed agenda.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Wed, 25 Apr 2001 17:11:24 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] FW: Meeting Rooms on the 12th and 13th
Sender: [email-masked]

>>>>> Andrea Westerinen writes:

Andrea> Juergen, I got a meeting room at the Westin Hotel - The
Andrea> Whidbey Room - for both Saturday and Sunday (5/12-13) from
Andrea> 10:00am-5:00pm. The room will accommodate 20 people maximum.
Andrea> It will be set "conference style" with a large table, and a
Andrea> whiteboard or flip chart.  I will try to get a PC projector
Andrea> from the Cisco office.

Great. Many thanks to you for organizing this room and lots of thanks
fo course to Cisco for hosting us. I have updated the meeting page at:

<http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2001/seattle/>

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: Re: [nmrg] Agenda for meeting
From: Wes Hardaker <[email-masked]>
Organization: Network Associates - NAI Labs
Date: 20 Apr 2001 08:43:00 -0700
Lines: 18
Sender: [email-masked]

>>>>> On Wed, 18 Apr 2001 09:33:31 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> We do not have a confirmation for a meeting room for both
Juergen> days yet and thus I am still waiting with a more detailed
Juergen> agenda.

I'd suggest developing an agenda that assumes a room will be
available, and truncating the agenda if its found that a room is
unavailable on one of those days.

Personally, in order for me to think about attending I need to see an
agenda ASAP to see if it is worth my time.  At this point, I'm not
planning on attending solely because without knowing the subject
material I can not justify charging my contract for the trip.
-- 
Wes Hardaker
NAI Labs
Network Associates

From: "Andrea Westerinen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>, "Network Management Research Group" <[email-masked]>
Subject: [nmrg] FW: Meeting Rooms on the 12th and 13th
Date: Tue, 24 Apr 2001 10:18:31 -0700
Importance: Normal
Sender: [email-masked]

Juergen,
I got a meeting room at the Westin Hotel -  The Whidbey Room - for both
Saturday and Sunday (5/12-13) from 10:00am-5:00pm. The room will accommodate
20 people maximum.  It will be set "conference style" with a large table,
and a whiteboard or flip chart.  I will try to get a PC projector from
the Cisco office.

Andrea

From: "Andrea Westerinen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [nmrg] Agenda for meeting
Date: Fri, 20 Apr 2001 02:41:19 -0700
Importance: Normal
Sender: [email-masked]

I am still working on it.  I hope to have an answer on a room by Monday.
Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Juergen Schoenwaelder
Sent: Wednesday, April 18, 2001 12:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nmrg] Agenda for meeting

>>>>> David T Perkins writes:

David> Have the times and topics been determined for the meeting yet.

David> Please post ASAP so I and other can make travel plans.

The meeting will be on Saturday/Sunday before IM 2001 (May 12-13).

<http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2001/seattle/>

So far, I got a request to discuss work being done in Twente allows
programs to retrieve SMI definitions from a networked infrastructure.
I also got a request to discuss policy translations, that is how you
move from a high-level declarative policy definition to concrete
configurations and configuration changes. I am personally also
interested in discussing long term visions on network management.

We do not have a confirmation for a meeting room for both days yet and
thus I am still waiting with a more detailed agenda.

/js

Date: Wed, 18 Apr 2001 14:49:50 -0700
From: "J.P. Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Subject: Re: [nmrg] Agenda for meeting
Sender: [email-masked]

Hi,

I would like to present on Sunday my recent work on Universal
Information Models, and discuss with you a new modeling and
standardization process that a colleague and I will shortly propose. I
would like to get feedback from people heavily involved in
standardization WGs at the IETF and DMTF.

Andrea, we can talk about this during IM 2001 if you're interested.

Jean-Philippe

Aiko Pras wrote:
> 
> Hi
> 
> One think I would like to talk about, is something we're working on in
> Twente and which we call "MIB object information lookup service". We now
> have a single server version (see
> http://wwwsnmp.cs.utwente.nl/ietf/mibs/oidd/help/), and we're working on
> a multi-server solution. I would appreciate comments on this.
> 
> bye
> 
> Aiko
> 
> "David T. Perkins" wrote:
> >
> > HI,
> >
> > Have the times and topics been determined for the meeting yet.
> >
> > Please post ASAP so I and other can make travel plans.
> >
> > Thanks,
> > /david t. perkins

Date: Wed, 18 Apr 2001 12:01:08 +0200
From: Aiko Pras <[email-masked]>
To: "David T. Perkins" <[email-masked]>
CC: [email-masked], Aiko Pras <[email-masked]>, Bert Helthuis <[email-masked]>, szabolcs boros <[email-masked]>
Subject: Re: [nmrg] Agenda for meeting
Sender: [email-masked]

Hi

One think I would like to talk about, is something we're working on in
Twente and which we call "MIB object information lookup service". We now
have a single server version (see
http://wwwsnmp.cs.utwente.nl/ietf/mibs/oidd/help/), and we're working on
a multi-server solution. I would appreciate comments on this.

bye

Aiko

"David T. Perkins" wrote:
> 
> HI,
> 
> Have the times and topics been determined for the meeting yet.
> 
> Please post ASAP so I and other can make travel plans.
> 
> Thanks,
> /david t. perkins

From: "Andrea Westerinen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001?
Date: Wed, 18 Apr 2001 01:08:33 -0700
Importance: Normal
Sender: [email-masked]

OK - I will work on getting the Bellevue office's meeting room for Saturday.

And, wrt your second question, the answer is (b) - I can't attend and
therefore you can't get into the office.  So, it falls to being creative.
However, while checking on the meeting room for Saturday, I will see if any
creative options pop up for Sunday.

I will let you know ...
Andrea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Juergen Schoenwaelder
Sent: Wednesday, April 18, 2001 12:28 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before
IM 2001?

>>>>> Andrea Westerinen writes:

Andrea> Juergen, I am a bit worried that the Cisco office is well
Andrea> outside of Seattle's downtown.  It is in Bellevue, which is a
Andrea> 20-25 minute drive.  If we have to meet downtown, then I may
Andrea> not be able to host - since I do not have budget to do this.
Andrea> I will check on getting a room at a nearby hotel and see what
Andrea> the price is.

I personally don't mind to take a 20-25 minutes drive. We did this in
Austin as well and it worked fine. Those folks with a car just picked
people up at the hotel. Perhaps we can arrange something like this in
Seattle as well.

Andrea> Also, I have a problem with meeting on Sunday - since I have
Andrea> to be at the conference hotel to make sure that everything is
Andrea> ready for Monday morning (I am the local coordinator).

Are you saying that (a) you are not able to attend, but it is still
possible for the NMRG to meet in Bellevue or (b) that you are not able
to attend and that it is therefore also not possible for the NMRG to
meet in Bellevue?

I think we should try to use the Sunday for a meeting since it is not
easy to get folks together in one place. In case (a), we could still
use the facilities in Bellevue. In case (b), we need to be creative
again...

/js

Date: Wed, 18 Apr 2001 09:33:31 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Agenda for meeting
Sender: [email-masked]

>>>>> David T Perkins writes:

David> Have the times and topics been determined for the meeting yet.

David> Please post ASAP so I and other can make travel plans.

The meeting will be on Saturday/Sunday before IM 2001 (May 12-13).

<http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2001/seattle/>

So far, I got a request to discuss work being done in Twente allows
programs to retrieve SMI definitions from a networked infrastructure.
I also got a request to discuss policy translations, that is how you
move from a high-level declarative policy definition to concrete
configurations and configuration changes. I am personally also
interested in discussing long term visions on network management.

We do not have a confirmation for a meeting room for both days yet and
thus I am still waiting with a more detailed agenda.

/js

Date: Wed, 18 Apr 2001 09:27:47 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001?
Sender: [email-masked]

>>>>> Andrea Westerinen writes:

Andrea> Juergen, I am a bit worried that the Cisco office is well
Andrea> outside of Seattle's downtown.  It is in Bellevue, which is a
Andrea> 20-25 minute drive.  If we have to meet downtown, then I may
Andrea> not be able to host - since I do not have budget to do this.
Andrea> I will check on getting a room at a nearby hotel and see what
Andrea> the price is.

I personally don't mind to take a 20-25 minutes drive. We did this in
Austin as well and it worked fine. Those folks with a car just picked
people up at the hotel. Perhaps we can arrange something like this in
Seattle as well.

Andrea> Also, I have a problem with meeting on Sunday - since I have
Andrea> to be at the conference hotel to make sure that everything is
Andrea> ready for Monday morning (I am the local coordinator).

Are you saying that (a) you are not able to attend, but it is still
possible for the NMRG to meet in Bellevue or (b) that you are not able
to attend and that it is therefore also not possible for the NMRG to
meet in Bellevue?

I think we should try to use the Sunday for a meeting since it is not
easy to get folks together in one place. In case (a), we could still
use the facilities in Bellevue. In case (b), we need to be creative
again...

/js

Date: Tue, 17 Apr 2001 13:35:32 -0700
To: <[email-masked]>
From: "David T. Perkins" <[email-masked]>
Subject: [nmrg] Agenda for meeting
Sender: [email-masked]

HI,

Have the times and topics been determined for the meeting yet.

Please post ASAP so I and other can make travel plans.

Thanks,
/david t. perkins

From: "Andrea Westerinen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001?
Date: Tue, 17 Apr 2001 09:38:59 -0700
Importance: Normal
Sender: [email-masked]

Juergen, I am a bit worried that the Cisco office is well outside of
Seattle's downtown.  It is in Bellevue, which is a 20-25 minute drive.  If
we have to meet downtown, then I may not be able to host - since I do not
have budget to do this.  I will check on getting a room at a nearby hotel
and see what the price is.

Also, I have a problem with meeting on Sunday - since I have to be at the
conference hotel to make sure that everything is ready for Monday morning (I
am the local coordinator).

Andrea

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Tuesday, April 17, 2001 8:16 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before
IM 2001?

>>>>> Aiko Pras writes:

Aiko> "J.P. Martin-Flatin" wrote:
>>  I will arrive in Seattle on Saturday evening. Can the meeting be
>> shifted to Saturday-Sunday?

Aiko> I support this idea! I expect to arrive friday evening.

The meeting is scheduled for May 12-13, as documented on the NMRG web
page.

Andrea, can you please send me material for the meeting location so
that I can update the meeting Web page?

     <http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2001/seattle/>

/js

--
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Tue, 17 Apr 2001 17:16:00 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001?
Sender: [email-masked]

>>>>> Aiko Pras writes:

Aiko> "J.P. Martin-Flatin" wrote:
>>  I will arrive in Seattle on Saturday evening. Can the meeting be
>> shifted to Saturday-Sunday?

Aiko> I support this idea! I expect to arrive friday evening.

The meeting is scheduled for May 12-13, as documented on the NMRG web
page.

Andrea, can you please send me material for the meeting location so
that I can update the meeting Web page?

     <http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2001/seattle/>

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Tue, 17 Apr 2001 15:00:45 +0200
From: Aiko Pras <[email-masked]>
To: "J.P. Martin-Flatin" <[email-masked]>
CC: Andrea Westerinen <[email-masked]>, Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001?
Sender: [email-masked]

"J.P. Martin-Flatin" wrote:
> 
> I will arrive in Seattle on Saturday evening. Can the meeting be shifted
> to Saturday-Sunday?

I support this idea! I expect to arrive friday evening.

Bye

Aiko

Date: Wed, 11 Apr 2001 13:29:19 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] please post draft-irtf-nmrg-snmp-compression-01.txt
Sender: [email-masked]

Please post the following document as an Internet Draft. It updates a
previous version which has already expired. The document has been
produced by the network management IRTF research group.

http://www.ibr.cs.tu-bs.de/~schoenw/draft-irtf-nmrg-snmp-compression-01.txt

Thank you.

[NMRG note: The version I did send to the mailing list yesterday
 contains many errors, especially in the examples. Frank did a serious
 review and we hope to have fixed them now. So please use the new
 version if you want to study the details.]

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Tue, 10 Apr 2001 16:56:52 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] snmp payload compression update
Sender: [email-masked]

Since the EOS IETF WG is now looking at the compression, I thought it
is a good time to document what we have been discussing here on the
list. Below is an update of the NMRG snmp compression draft. I intent
to post it as an ID in the next few days. If someone wants me to fix
bugs etc, then please respond quickly.

My main concern right now is to make sure the compression algorithm is
understandable. That's why I have added quite a few examples.

/js

Network Working Group                                   J. Schoenwaelder
Internet-Draft                                           TU Braunschweig
Expires: October 9, 2001                                  April 10, 2001

                        SNMP Payload Compression
                draft-irtf-nmrg-snmp-compression-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 9, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This memo defines a mechanism for lossless compression of SNMP
   payloads.  Compression is especially useful when retrieving large
   amounts of data or when SNMP encryption is being used over a
   transport which provides data compression.

Schoenwaelder            Expires October 9, 2001                [Page 1]

Internet-Draft          SNMP Payload Compression              April 2001

Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   2.      Requirements . . . . . . . . . . . . . . . . . . . . . . .  3
   3.      Identifying Compressed Payload . . . . . . . . . . . . . .  4
   3.1     Compression as an SNMPv3 Encryption Algorithm  . . . . . .  4
   3.2     Indicating Compression in the msgFlags . . . . . . . . . .  4
   3.3     Compression as a new PDU type  . . . . . . . . . . . . . .  5
   4.      Negotiating Compression Algorithms . . . . . . . . . . . .  6
   5.      Compression Algorithms . . . . . . . . . . . . . . . . . .  6
   5.1     DEFLATE  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.2     OID Delta Compression (ODC)  . . . . . . . . . . . . . . .  7
   5.2.1   ODC Algorithm  . . . . . . . . . . . . . . . . . . . . . .  7
   5.2.2   ODC Examples . . . . . . . . . . . . . . . . . . . . . . .  9
   5.2.2.1 Simple Substitutions . . . . . . . . . . . . . . . . . . .  9
   5.2.2.2 Range Substitutions  . . . . . . . . . . . . . . . . . . . 10
   5.2.2.3 Substitutions and Truncations  . . . . . . . . . . . . . . 12
   6.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 13
           References . . . . . . . . . . . . . . . . . . . . . . . . 13
           Author's Address . . . . . . . . . . . . . . . . . . . . . 13
           Full Copyright Statement . . . . . . . . . . . . . . . . . 14

Schoenwaelder            Expires October 9, 2001                [Page 2]

Internet-Draft          SNMP Payload Compression              April 2001

1. Introduction

   This memo defines a mechanism for lossless compression of SNMP
   payloads.  Compression is useful when retrieving large amounts of
   management data since the BER encoding used by SNMP is not very space
   efficient and the payload tends to have a high degree of redundancy.

   SNMP payload compression is especially useful when SNMP encryption is
   used.  Encrypting the SNMP payload causes the data to be random in
   nature, rendering compression at lower protocol layers (e.g., IP
   Payload Compression Protocol [2]) ineffective.  If both compression
   and encryption are required, then compression must be applied before
   encryption.

2. Requirements

   A solution for SNMP payload compression has to satisfy the following
   requirements:

   1.  Compression must happen before encryption if compression is used
       together with encryption.  Compression is most useful if there
       are regular pattern in the data.  It is the nature of encryption
       algorithms to destroy any regular pattern and hence encrypted
       data does not compress very well.

   2.  SNMP payload compression should support multiple compression
       algorithms.  This implies that SNMP engines must be able to
       negotiate the compression algorithm they are using.  Instead of
       carrying compression algorithm identifier in every protocol
       message, it seems more effective to indicate compression
       algorithms in a MIB module (similar to authentication or
       encryption algorithms in SNMPv3).

   3.  Each SNMP message is compressed and decompressed by itself
       without any relation to other SNMP messages ("stateless
       compression"), as SNMP messages may arrive out of order or not
       arrive at all.

   4.  The size of a compressed SNMP message must never exceed the size
       of the uncompressed SNMP message ("non-expansion policy").  A
       sender may send an uncompressed SNMP message if an attempt to
       compress the message produces a result which is longer than the
       uncompressed SNMP message.  An SNMP engine configured to receive
       compressed SNMP messages must thus also accept uncompressed SNMP
       messages.

   5.  The abstract syntax of compressed SNMP messages must be defined
       using ASN.1.  This ensures that a compressed SNMP message is a

Schoenwaelder            Expires October 9, 2001                [Page 3]

Internet-Draft          SNMP Payload Compression              April 2001

       valid ASN.1/BER encoding which simplifies the integration into
       existing SNMP toolkits.

   6.  It is desirable to define common compression algorithms in order
       to achieve interoperability.  The compression algorithms should
       be openly available and they should represent different trade-
       offs between compression efficiency and CPU efficiency.

3. Identifying Compressed Payload

   It is necessary to distinguish between compressed and uncompressed
   SNMP payload.  There are several ways to implement this.  The
   following sections discuss alternatives that have been considered.

3.1 Compression as an SNMPv3 Encryption Algorithm

   The idea behind the first approach is to treat compression as an
   additional SNMPv3 encryption algorithm.  In fact, compression as well
   as encryption can both be treated as a loss-less data transformation.
   This approach the following advantages / disadvantages:

   +  No change required to the SNMPv3 specifications.

   +  Compression of the complete ScopedPDU.

   -  Support of N encryption algorithms and M compression algorithms
      leads to N*M possible combinations.

   -  Compression requires authentication since there is no noAuthPriv
      security level.

   -  Does not work with older and widely deployed versions of SNMP
      (SNMPv1, SNMPv2c).

3.2 Indicating Compression in the msgFlags

   To avoid some of the drawbacks of the previous approach, one can
   treat compression independent of encryption by allocating an unused
   bit in the msgFlags [3]) to indicate whether compression is used or
   not.  However, RFC 2572 [3]) says in section 6.4:

   The remaining bits in msgFlags are reserved, and must be set to zero
   when sending a message and should be ignored when receiving a
   message.

   Similarly, RFC 2572 [3] specifies in section 7.1 step 7) and in

Schoenwaelder            Expires October 9, 2001                [Page 4]

Internet-Draft          SNMP Payload Compression              April 2001

   section 7.2 step 5) that other bits in the msgFlags are set to zero
   or ignored.  This means that this alternative can not be supported by
   an implementation which is strictly compliant to RFC 2572 [3].

   In summary, this approach has the following advantages /
   disadvantages:

   +  Combination of M compression and N encryption algorithms possible
      without having to define N*M algorithms.

   +  Compression can be used with or without encryption or
      authentication.

   +  Compression of the complete ScopedPDU.

   -  Not strictly compliant to the current SNMPv3 specifications.

   -  Does not work with older widely deployed versions of SNMP (SNMPv1,
      SNMPv2c).

3.3 Compression as a new PDU type

   The third alternative is to restrict compression to PDUs rather than
   ScopedPDUs and to introduce a new PDU type for compressed payloads.
   RFC 1157 [4] defines the SNMPv1 message header as follows:

       Message ::= SEQUENCE {
           version   INTEGER { version-1(0) },
           community OCTET STRING,
           data      ANY  -- e.g., PDUs if trivial authentication
   		       -- is being used
       }

   Similarly, RFC 2572 [3] defines the ScopedPDU as follows:

       ScopedPDU ::= SEQUENCE {
           contextEngineID  OCTET STRING,
           contextName      OCTET STRING,
           data             ANY -- e.g., PDUs as defined in RFC 1905
       }

   This means that a new PDU could be defined which holds the compressed
   version of a PDU:

       CompressedPDU ::= [42] IMPLICIT OCTET STRING
   		       -- contains a compressed PDU

Schoenwaelder            Expires October 9, 2001                [Page 5]

Internet-Draft          SNMP Payload Compression              April 2001

   It is important to analyze how a compliant SNMP implementation
   behaves when it receives an unknown PDU type.  From a formal point of
   view, any PDU which is a valid BER serialization of an ASN.1 type
   must be accepted since the data portion is of the ASN.1 type ANY.  In
   practice, most SNMP implementations will only recognize the PDU types
   defined in the SNMP specifications.

   The SNMPv3 message processing model [3] defines in section 7.2 step
   7) that parse errors while decoding the ScopedPDU cause the packet to
   be discarded after incrementing snmpInASNParseErrs.  Even an
   implementation which is capable to decode arbitrary PDUs will have
   problems to determine the pduType as defined in section 7.2 step 9).
   This basically means that a compliant SNMPv3 engine will simply
   discard compressed PDUs.

   The SNMPv1 specification [4] defines in section 4.1 second step (4)
   that parse errors while decoding the PDU will cause the SNMP engine
   to drop the PDU.  Hence, it can be expected that most implementations
   will simply drop a compressed PDU.

   In summary, this approach has the following advantages /
   disadvantages:

   +  Combination of M compression and N encryption algorithms possible
      without having to define N*M algorithms.

   +  Compression can be used with or without encryption or
      authentication.

   +  Works with every version of SNMP.

   -  Not strictly compliant to the current SNMPv3 specifications.

   -  Compression of the PDU rather than the ScopedPDU.

4. Negotiating Compression Algorithms

   [TBD]

5. Compression Algorithms

5.1 DEFLATE

   The DEFLATE algorithm is a well-know compression algorithm which
   achieves good compression ratios and which is used for example in RFC
   2394 for IP payload compression.  It is also used on the World Wide
   Web to compress documents before transmission over HTTP.

Schoenwaelder            Expires October 9, 2001                [Page 6]

Internet-Draft          SNMP Payload Compression              April 2001

   Using DEFLATE for SNMP payload compression however shows some
   undesirable aspects.  First, DEFLATE compression is relatively CPU
   intensive.  Furthermore, the DEFLATE algorithm requires to transmit a
   dictionary, which reduces the compression efficiency for small
   messages.  On the other hand, DEFLATE compresses both names and
   values and may achieve particularly good compression if the encoded
   values show a similar structure.

   Experiments with DEFLATE show that it should not be used on
   relatively short SNMP messages.  Furthermore, DEFLATE introduces
   significant delays due to the compression computations.  Finally,
   estimating message sizes is hard with DEFLATE since there is no upper
   bound for the message length addition if one adds another varbind.
   This has impacts in particular the getbulk PDU implementation.  It is
   therefore not recommended to adopt DEFLATE compression.

5.2 OID Delta Compression (ODC)

   SNMP payloads use OIDs to represent the names of SNMP variables.  The
   amount of space used for encoding these OIDs frequently exceeds the
   space needed to represent that values identified by the OIDs.
   Furthermore, subsequent OIDs usually have many sub-identifier in
   common.

   The OID Delta Compression (ODC) algorithm has been designed to reduce
   the OID overhead inherent in SNMP messages.  The general idea is to
   encode an OID as a delta to the previous OID.  The ODC algorithm only
   achieves a reduction in the SNMP naming information.  It does not
   compress the data of MIB variables, even if the value itself is an
   OID.  (The reason for not compressing OID values is that they are (a)
   relatively infrequent and (b) compressing value OIDs has negative
   impact on the compression achieved for the following variable name.)
   In many cases (e.g., if when retrieving large tables which basically
   contain numbers), the achieved compression ratio is significant while
   the CPU cycles spend on the compression algorithm itself are very
   small.

5.2.1 ODC Algorithm

   The ODC algorithm encodes OID deltas using three mechansisms:

   1.  Substitution of sub-identifier values at a certain position.  A
       sub-identifier substitution is encoded as follows:

Schoenwaelder            Expires October 9, 2001                [Page 7]

Internet-Draft          SNMP Payload Compression              April 2001

       0               7
       +---------------+--------------------------//-+
       |    s-offset   | BER encoded sub-identifier  |
       +---------------+--------------------------//-+

       s-offset      Defines the offset of the sub-identifier to
                     substitute. The offset value is in the range
                     0-0x7f. The value 0 refers to the first OID
                     sub-identifier.

   2.  Substitution of ranges of sub-identifiers at a given starting
       positions.  A substitution of a range of sub-identifiers is
       encoded as follows:

       0               7              15
       +---------------+---------------+--------------------------//-+
       |    r-offset   |   r-length    | BER encoded sub-identifiers |
       +---------------+---------------+--------------------------//-+

       r-offset      Defines the offset of the sub-identifier range
                     to substitute. The offset value has the most
                     significant bit set and is in the range
                     0x80-0xff. The value 0x80 refers to the first
                     OID sub-identifier.
       r-length      Defines the number of sub-identifier that will
                     be substituted in the range 0x01-0x7f.

   3.  Truncation of OIDs (which may shorten or enlarge OIDs).  A
       truncation, which may only appear at the end, is encoded as
       follows:

       0               7
       +---------------+
       |    t-length   |
       +---------------+

       t-length      Defines the new length of the OID in the range
                     0x01-0x7f. The value 0x01 identifies an OID which
                     consists of two sub-identifiers. Truncation may
                     be used to shorten or enlarge an OID. New
                     sub-identifiers will have the value 0 if an OID
                     is enlarged.

   An ODC compressed OID is simply the combination of several sub-
   identifiers or sub-identifier range substitutions followed by an
   option truncation.  Note that substitutions can increase the size of
   the OID if the offset or range specifies sub-identifier positions
   outside of the previous OID.  New sub-identifiers without an explicit

Schoenwaelder            Expires October 9, 2001                [Page 8]

Internet-Draft          SNMP Payload Compression              April 2001

   value assignement will have the value 0.  An ODC compressed OID is
   distinguished from a normal OID by introducing the following new
   ASN.1 type:

                   CompOID ::= [42] IMPLICIT OCTET STRING

   A high-level description of the encoding algorithm is as follows:

   1.  Loop through the SNMP PDU until you find an OID name value pair
       (varbind).

   2.  If it is the first varbind, make a copy of the OID, pass it to
       the output buffer and continue.

   3.  Otherwise, compute the delta to the copied OID and BER encode it
       into the CompOID value.

   4.  If the CompOID representation is larger than the OID, pass the
       OID to the output buffer, else pass the CompOID to the output
       buffer.

   5.  Make a copy of the OID and continue.

   Some SNMP implementations use a reverse encoding scheme where PDUs
   are encoded from the end to the beginning.  The ODC algorithm can
   also be used efficiently in this case by using an OID look-ahead of 1
   varbind.

5.2.2 ODC Examples

   This sections shows some example ODC encodings.  This section is
   provided to better understand how ODC encodings work.  It is not
   intended to give a formal analysis of the compression ratios that can
   be achieved on arbitrary SNMP payload.

5.2.2.1 Simple Substitutions

   Lets assume a command generator uses getbulk operations to retrieve
   the tcpConnTable of the TCP-MIB.  A good manager will do that by
   retrieving the tcpConnState column.  The command responder will
   return a sequence of tcpConnState (1.3.6.1.2.1.6.13.1.1) values:

         tcpConnState.0.0.0.0.21.0.0.0.0.0 = listen(2)
         tcpConnState.0.0.0.0.22.0.0.0.0.0 = listen(2)
         tcpConnState.0.0.0.0.23.0.0.0.0.0 = listen(2)
         tcpConnState.0.0.0.0.98.0.0.0.0.0 = listen(2)

   The BER encoding of this varbind list is the following sequence of

Schoenwaelder            Expires October 9, 2001                [Page 9]

Internet-Draft          SNMP Payload Compression              April 2001

   bytes:

   30:17                                   // sequence
      06:13:2B:06:01:02:01:06:0D:01:01:    // tcpConnState
            00:00:00:00:15:00:00:00:00:00  // instance identifier
      02:01:02                             // value
   30:17                                   // sequence
      06:13:2B:06:01:02:01:06:0D:01:01:    // tcpConnState
            00:00:00:00:16:00:00:00:00:00  // instance identifier
      02:01:02                             // value
   30:17                                   // sequence
      06:13:2B:06:01:02:01:06:0D:01:01:    // tcpConnState
            00:00:00:00:17:00:00:00:00:00  // instance identifier
      02:01:02                             // value
   30:17                                   // sequence
      06:13:2B:06:01:02:01:06:0D:01:01:    // tcpConnState
            00:00:00:00:62:00:00:00:00:00  // instance identifier
      02:01:02                             // value

   Using ODC compression, the following sequence of bytes would be used:

   30:17                                   // sequence
      06:13:2B:06:01:02:01:06:0D:01:01:    // tcpConnState
            00:00:00:00:15:00:00:00:00:00  // instance identifier
      02:01:02                             // value
   30:06                                   // sequence
      2a:01:16                             // substitution
      02:01:02                             // value
   30:06                                   // sequence
      2a:01:17                             // substitution
      02:01:02                             // value
   30:06                                   // sequence
      2a:01:62                             // substitution
      02:01:02                             // value

   In this particular example, the total size of the encoded varbind
   list drops from 104 bytes to 50 bytes.

5.2.2.2 Range Substitutions

   This example expands the previous example by showing how range
   substitutions work.  In this example, we assume that the command
   responder will return a sequence of tcpConnState values with
   different IP addresses in the instance identifier:

         tcpConnState.134.169.34.190.50054.130.240.64.53.80 = closeWait(8)
         tcpConnState.134.169.34.190.50366.212.185.76.85.80 = closeWait(8)
         tcpConnState.134.169.34.190.53370.134.169.34.117.6000 = established(5)

Schoenwaelder            Expires October 9, 2001               [Page 10]

Internet-Draft          SNMP Payload Compression              April 2001

         tcpConnState.134.169.34.190.56398.134.169.34.190.120 = closeWait(8)

   The BER encoding of this varbind list is the following sequence of
   bytes:

   30:1F                                   // sequence
      06:1A:2B:06:01:02:01:06:0D:01:01:    // tcpConnState
         81:06:81:29:22:81:3E:83:87:06:    // instance
         81:02:81:70:40:35:50              // identifier
      02:01:08                             // value
   30:1F                                   // sequence
      06:1A:2B:06:01:02:01:06:0D:01:01:    // tcpConnState
         81:06:81:29:22:81:3E:83:89:3E:    // instance
         81:54:81:39:4C:55:50              // identifier
      02:01:08                             // value
   30:20                                   // sequence
      06:1B:2B:06:01:02:01:06:0D:01:01:    // tcpConnState
         81:06:81:29:22:81:3E:83:A0:7A:    // instance
         81:06:81:29:22:75:AE:70           // identifier
      02:01:05                             // value
   30:20:                                  // sequence
      06:1B:2B:06:01:02:01:06:0D:01:01:    // tcpConnState
         81:06:81:29:22:81:3E:83:B8:4E:    // instance
         81:06:81:29:22:81:3E:78           // identifier
      02:01:08                             // value

   Using ODC compression, the following sequence of bytes would be used:

   30:1F                                   // sequence
      06:1A:2B:06:01:02:01:06:0D:01:01:    // tcpConnState
         81:06:81:29:22:81:3E:83:87:06:    // instance
         81:02:81:70:40:35:50              // identifier
      02:01:08                             // value
   30:10                                   // sequence
      2a:0B:0e:85:                         // range
      83:89:3E:81:54:81:39:4C:55           // substitution
      02:01:08                             // value
   30:12                                   // sequence
      2a:0C:0e:86:                         // range
      83:A0:7A:81:06:81:29:22:75:AE:70     // substitution
      02:01:05                             // value
   30:0e                                   // sequence
      2a:09:0e:83:A0:7A                    // substitution
      12:82:81:3E:78                       // range substitution
      02:01:05                             // value

   In this particular example, the total size of the encoded varbind
   list drops from 134 bytes to 87 bytes.

Schoenwaelder            Expires October 9, 2001               [Page 11]

Internet-Draft          SNMP Payload Compression              April 2001

5.2.2.3 Substitutions and Truncations

   This example assumes that a command genertor retrieves the
   ipNetToMediaTable defined in the IP-MIB.  A good manager will
   retrieve ipNetToMediaPhysAddress (1.3.6.1.2.1.4.22.1.2) and
   ipNetToMediaType (1.3.6.1.2.1.4.22.1.4) pairs.  The following values
   might be returned for a system which only has one entry in the cache:

         ipNetToMediaPhysAddress.2.224.8.8.0 = 01:00:5E:08:08:00
         ipNetToMediaType.2.224.8.8.0 = dynamic(3)
         IP-MIB!ipNetToMediaNetAddress.2.134.169.34.1 = 134.169.34.1
         IP-MIB!ipRoutingDiscards.0 = 0

   The BER encoding of this varbind list is the following sequence of
   bytes:

   30:19                                   // sequence
      06:0F:2B:06:01:02:01:04:16:01:02:    // ipNetToMediaPhysAddress
         02:81:60:08:08:00                 // instance identifier
      04:06:01:00:5E:08:08:00              // value
   30:14:                                  // sequence
      06:0F:2B:06:01:02:01:04:16:01:04:    // ipNetToMediaType
         02:81:60:08:08:00                 // instance identifier
      02:01:03                             // value
   30:18                                   // sequence
      06:10:2B:06:01:02:01:04:16:01:03:    // ipNetToMediaNetAddress
         02:81:06:81:29:22:01              // instance identifier
      40:04:86:A9:22:01                    // value
   30:0D:                                  // sequence
      06:08:2B:06:01:02:01:04:17           // ipRoutingDiscards
      00                                   // instance identifier
      41:01:00                             // value

   Using ODC compression, the following sequence of bytes would be used:

   30:19                                   // sequence
      06:0F:2B:06:01:02:01:04:16:01:02:    // ipNetToMediaPhysAddress
         02:81:60:08:08:00                 // instance identifier
      04:06:01:00:5E:08:08:00              // value
   30:07                                   // sequence
      2a:02:09:04                          // substitution
      02:01:03                             // value
   30:0c                                   // sequence
      2a:0a:09:03:10:84:81:06:81:29:22:01  // substitutions
      40:04:86:A9:22:01                    // value
   30:06                                   // sequence
      2a:04:82:17:00:                      // substitution
      88                                   // truncation

Schoenwaelder            Expires October 9, 2001               [Page 12]

Internet-Draft          SNMP Payload Compression              April 2001

      41:01:00                             // value

   In this particular example, the total size of the encoded varbind
   list drops from 90 bytes to 58 bytes.

6. Acknowledgments

   This document is the result of discussions within the Network
   Management Research Group (NMRG).  of the Internet Research Task
   Force[5] (IRTF).  Special thanks go to Luca Deri, Wes Hardacker,
   Jean-Philippe Martin-Flatin, Joe Marzot, Aiko Pras, Ron Sprenkels,
   and Bert Wijnen for their comments and suggestions.

References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload
        Compression Protocol (IPComp)", RFC 2393, December 1998.

   [3]  Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
        Processing and Dispatching for the Simple Network Management
        Protocol (SNMP)", RFC 2572, April 1999.

   [4]  Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
        Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.

   [5]  <http://www.irtf.org/>

Author's Address

   Juergen Schoenwaelder
   TU Braunschweig
   Bueltenweg 74/75
   38106 Braunschweig
   Germany

   Phone: +49 531 391-3289
   EMail: [email-masked]

Schoenwaelder            Expires October 9, 2001               [Page 13]

Internet-Draft          SNMP Payload Compression              April 2001

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Schoenwaelder            Expires October 9, 2001               [Page 14]


Date: Wed, 4 Apr 2001 23:02:50 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001?
Sender: [email-masked]

>>>>> Andrea Westerinen writes:

Andrea> I need to get a room if we are.  I have not seen any further
Andrea> mails on this - so, I am asking.

Good that you bing up this topic now. There were discussions to hold
some other meetings next to IM 2001 and I tried to make sure that we
do not get overlaps which would make things hard for some of us to
attend. In particular, I know that the SMIng chair is working on an
SMIng interim next to IM 2001. The latest proposal I am aware of is to
hold an SMIng interim on Friday/Saturday after the IM 2001. This would
allow the NMRG to keep the original plan to meet just before IM 2001.

I agree with J.P. that holding the meeting on Saturday/Sunday is more
time efficient for those who can't spend the weekend at home anyway,
which is probably the majority.

So I suggest that you try to arrange a room for an NMRG meeting on
Saturday/Sunday before IM 2001 (May 12-13).

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

Date: Wed, 04 Apr 2001 14:40:27 -0700
From: "J.P. Martin-Flatin" <[email-masked]>
Reply-To: "J.P. Martin-Flatin" <[email-masked]>
To: Andrea Westerinen <[email-masked]>
Cc: Network Management Research Group <[email-masked]>
Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001?
Sender: [email-masked]

I will arrive in Seattle on Saturday evening. Can the meeting be shifted
to Saturday-Sunday?

JP

Andrea Westerinen wrote:
> 
> I need to get a room if we are.  I have not seen any further mails on this -
> so, I am asking.
> 
> Andrea

From: "Andrea Westerinen" <[email-masked]>
To: "Network Management Research Group" <[email-masked]>
Subject: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001?
Date: Wed, 4 Apr 2001 09:34:09 -0700
Importance: Normal
Sender: [email-masked]

I need to get a room if we are.  I have not seen any further mails on this -
so, I am asking.

Andrea