Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id LAA29387 for nmrg-outgoing; Mon, 30 Apr 2001 11:36:10 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id LAA29370; Mon, 30 Apr 2001 11:36:08 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA23754; Mon, 30 Apr 2001 11:36:08 +0200 Date: Mon, 30 Apr 2001 11:36:08 +0200 Message-Id: <200104300936.LAA23754@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] meeting preparation Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id QAA21979 for nmrg-outgoing; Thu, 26 Apr 2001 16:42:45 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id QAA21857; Thu, 26 Apr 2001 16:42:41 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA10372; Thu, 26 Apr 2001 16:42:41 +0200 Date: Thu, 26 Apr 2001 16:42:41 +0200 Message-Id: <200104261442.QAA10372@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: wes@hardakers.net CC: nmrg@ibr.cs.tu-bs.de In-reply-to: (message from Wes Hardaker on 26 Apr 2001 07:30:04 -0700) Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative) References: <200104251515.RAA06745@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id QAA21231 for nmrg-outgoing; Thu, 26 Apr 2001 16:39:17 +0200 (MET DST) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id QAA21223; Thu, 26 Apr 2001 16:39:13 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id QAA07240; Thu, 26 Apr 2001 16:39:13 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Wes Hardaker Cc: Aiko Pras , Network Management Research Group Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative) References: <200104251515.RAA06745@henkell.ibr.cs.tu-bs.de> Date: 26 Apr 2001 16:39:12 +0200 In-Reply-To: Message-ID: Lines: 14 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id QAA20644 for nmrg-outgoing; Thu, 26 Apr 2001 16:29:56 +0200 (MET DST) Received: from wanderer.hardakers.net (dns1.hardaker.davis.ca.us [168.150.190.1]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id QAA20636; Thu, 26 Apr 2001 16:29:53 +0200 (MET DST) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id HAA01319; Thu, 26 Apr 2001 07:30:04 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Frank Strauss Cc: Aiko Pras , Network Management Research Group Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative) References: <200104251515.RAA06745@henkell.ibr.cs.tu-bs.de> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 In-Reply-To: (Frank Strauss's message of "25 Apr 2001 20:04:53 +0200") Message-ID: User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 26 Apr 2001 07:30:04 -0700 Lines: 14 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> On 25 Apr 2001 20:04:53 +0200, Frank Strauss 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id UAA11232 for nmrg-outgoing; Wed, 25 Apr 2001 20:06:09 +0200 (MET DST) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id UAA11169; Wed, 25 Apr 2001 20:04:53 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id UAA08276; Wed, 25 Apr 2001 20:04:53 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Wes Hardaker Cc: Aiko Pras , Network Management Research Group Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative) References: <200104251515.RAA06745@henkell.ibr.cs.tu-bs.de> Date: 25 Apr 2001 20:04:53 +0200 In-Reply-To: Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id SAA05187 for nmrg-outgoing; Wed, 25 Apr 2001 18:13:38 +0200 (MET DST) Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id SAA05175; Wed, 25 Apr 2001 18:13:35 +0200 (MET DST) Received: (from hardaker@localhost) by wanderer.hardakers.net (8.9.3/8.9.3) id JAA01254; Wed, 25 Apr 2001 09:13:44 -0700 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Frank Strauss Cc: Aiko Pras , Network Management Research Group Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative) References: <200104251515.RAA06745@henkell.ibr.cs.tu-bs.de> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Date: 25 Apr 2001 09:13:44 -0700 In-Reply-To: (Frank Strauss's message of "25 Apr 2001 17:56:26 +0200") Message-ID: Lines: 16 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> On 25 Apr 2001 17:56:26 +0200, Frank Strauss 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id RAA03324 for nmrg-outgoing; Wed, 25 Apr 2001 17:56:28 +0200 (MET DST) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id RAA03316; Wed, 25 Apr 2001 17:56:26 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id RAA01632; Wed, 25 Apr 2001 17:56:26 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Aiko Pras Cc: Network Management Research Group Subject: Re: [nmrg] 9th nmrg meeting agenda (tentative) References: <200104251515.RAA06745@henkell.ibr.cs.tu-bs.de> Date: 25 Apr 2001 17:56:26 +0200 In-Reply-To: <200104251515.RAA06745@henkell.ibr.cs.tu-bs.de> Message-ID: Lines: 40 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id RAA27162 for nmrg-outgoing; Wed, 25 Apr 2001 17:15:39 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id RAA27146; Wed, 25 Apr 2001 17:15:37 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA06745; Wed, 25 Apr 2001 17:15:37 +0200 Date: Wed, 25 Apr 2001 17:15:37 +0200 Message-Id: <200104251515.RAA06745@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] 9th nmrg meeting agenda (tentative) Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id RAA26545 for nmrg-outgoing; Wed, 25 Apr 2001 17:11:30 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id RAA26513; Wed, 25 Apr 2001 17:11:24 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA06684; Wed, 25 Apr 2001 17:11:24 +0200 Date: Wed, 25 Apr 2001 17:11:24 +0200 Message-Id: <200104251511.RAA06684@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: andreaw@cisco.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: Subject: Re: [nmrg] FW: Meeting Rooms on the 12th and 13th References: Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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: /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id RAA25631 for nmrg-outgoing; Wed, 25 Apr 2001 17:01:07 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id RAA25623; Wed, 25 Apr 2001 17:01:05 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA06434; Wed, 25 Apr 2001 17:01:05 +0200 X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f To: Juergen Schoenwaelder Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Agenda for meeting References: <5.0.2.1.2.20010417133358.02d63ec0@mail.scruznet.com> <200104180733.JAA13628@henkell.ibr.cs.tu-bs.de> From: Wes Hardaker X-URL: http://dcas.ucdavis.edu/~hardaker Organization: Network Associates - NAI Labs X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 In-Reply-To: <200104180733.JAA13628@henkell.ibr.cs.tu-bs.de> (Juergen Schoenwaelder's message of "Wed, 18 Apr 2001 09:33:31 +0200") Message-ID: User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: 20 Apr 2001 08:43:00 -0700 Lines: 18 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> On Wed, 18 Apr 2001 09:33:31 +0200, Juergen Schoenwaelder 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id TAA12972 for nmrg-outgoing; Tue, 24 Apr 2001 19:17:28 +0200 (MET DST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id TAA12963; Tue, 24 Apr 2001 19:17:26 +0200 (MET DST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3OHGvu07723; Tue, 24 Apr 2001 10:16:57 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AIH12300; Tue, 24 Apr 2001 10:16:36 -0700 (PDT) From: "Andrea Westerinen" To: "Juergen Schoenwaelder" , "Network Management Research Group" Subject: [nmrg] FW: Meeting Rooms on the 12th and 13th Date: Tue, 24 Apr 2001 10:18:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id LAA25671 for nmrg-outgoing; Fri, 20 Apr 2001 11:39:58 +0200 (MET DST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id LAA25663; Fri, 20 Apr 2001 11:39:56 +0200 (MET DST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id CAA16827; Fri, 20 Apr 2001 02:38:03 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AHF03207; Fri, 20 Apr 2001 02:39:23 -0700 (PDT) From: "Andrea Westerinen" To: "Juergen Schoenwaelder" , Cc: Subject: RE: [nmrg] Agenda for meeting Date: Fri, 20 Apr 2001 02:41:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200104180733.JAA13628@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk I am still working on it. I hope to have an answer on a room by Monday. Andrea -----Original Message----- From: owner-nmrg@ibr.cs.tu-bs.de [mailto:owner-nmrg@ibr.cs.tu-bs.de]On Behalf Of Juergen Schoenwaelder Sent: Wednesday, April 18, 2001 12:34 AM To: dperkins@dsperkins.com Cc: nmrg@ibr.cs.tu-bs.de 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). 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id UAA14980 for nmrg-outgoing; Wed, 18 Apr 2001 20:51:42 +0200 (MET DST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id UAA14975 for ; Wed, 18 Apr 2001 20:51:33 +0200 (MET DST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 627B14CE11 for ; Wed, 18 Apr 2001 14:51:32 -0400 (EDT) Received: from research.att.com ([135.210.4.201]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id OAA23213; Wed, 18 Apr 2001 14:51:27 -0400 (EDT) Message-ID: <3ADE0BFE.646A4CFC@research.att.com> Date: Wed, 18 Apr 2001 14:49:50 -0700 From: "J.P. Martin-Flatin" Reply-To: "J.P. Martin-Flatin" X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Agenda for meeting References: <5.0.2.1.2.20010417133358.02d63ec0@mail.scruznet.com> <3ADD65E4.47D38E89@ctit.utwente.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id MAA06685 for nmrg-outgoing; Wed, 18 Apr 2001 12:01:19 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id MAA06680 for ; Wed, 18 Apr 2001 12:01:18 +0200 (MET DST) Received: from ctit.utwente.nl (utip064.cs.utwente.nl [130.89.12.90]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id MAA07723; Wed, 18 Apr 2001 12:01:12 +0200 (MET DST) Message-ID: <3ADD65E4.47D38E89@ctit.utwente.nl> Date: Wed, 18 Apr 2001 12:01:08 +0200 From: Aiko Pras X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "David T. Perkins" CC: nmrg@ibr.cs.tu-bs.de, Aiko Pras , Bert Helthuis , szabolcs boros Subject: Re: [nmrg] Agenda for meeting References: <5.0.2.1.2.20010417133358.02d63ec0@mail.scruznet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id KAA22565 for nmrg-outgoing; Wed, 18 Apr 2001 10:07:14 +0200 (MET DST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id KAA22554; Wed, 18 Apr 2001 10:07:11 +0200 (MET DST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id BAA19617; Wed, 18 Apr 2001 01:06:44 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AGH06422; Wed, 18 Apr 2001 01:06:38 -0700 (PDT) From: "Andrea Westerinen" To: "Juergen Schoenwaelder" Cc: Subject: RE: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001? Date: Wed, 18 Apr 2001 01:08:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200104180727.JAA13599@henkell.ibr.cs.tu-bs.de> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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: owner-nmrg@ibr.cs.tu-bs.de [mailto:owner-nmrg@ibr.cs.tu-bs.de]On Behalf Of Juergen Schoenwaelder Sent: Wednesday, April 18, 2001 12:28 AM To: andreaw@cisco.com Cc: nmrg@ibr.cs.tu-bs.de 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id JAA19386 for nmrg-outgoing; Wed, 18 Apr 2001 09:33:35 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id JAA19377; Wed, 18 Apr 2001 09:33:32 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA13628; Wed, 18 Apr 2001 09:33:31 +0200 Date: Wed, 18 Apr 2001 09:33:31 +0200 Message-Id: <200104180733.JAA13628@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dperkins@dsperkins.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <5.0.2.1.2.20010417133358.02d63ec0@mail.scruznet.com> (dperkins@dsperkins.com) Subject: Re: [nmrg] Agenda for meeting References: <5.0.2.1.2.20010417133358.02d63ec0@mail.scruznet.com> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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). 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id JAA18981 for nmrg-outgoing; Wed, 18 Apr 2001 09:27:52 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id JAA18972; Wed, 18 Apr 2001 09:27:47 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA13599; Wed, 18 Apr 2001 09:27:47 +0200 Date: Wed, 18 Apr 2001 09:27:47 +0200 Message-Id: <200104180727.JAA13599@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: andreaw@cisco.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001? References: Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id WAA21413 for nmrg-outgoing; Tue, 17 Apr 2001 22:36:48 +0200 (MET DST) Received: from riverstonenet.com (mail.riverstonenetworks.net [63.113.148.10] (may be forged)) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id WAA21408 for ; Tue, 17 Apr 2001 22:36:43 +0200 (MET DST) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA12420; Tue, 17 Apr 2001 13:36:11 -0700 (PDT) Message-Id: <5.0.2.1.2.20010417133358.02d63ec0@mail.scruznet.com> X-Sender: dperkins@mail.scruznet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 17 Apr 2001 13:35:32 -0700 To: From: "David T. Perkins" Subject: [nmrg] Agenda for meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id SAA29515 for nmrg-outgoing; Tue, 17 Apr 2001 18:37:46 +0200 (MET DST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id SAA29507; Tue, 17 Apr 2001 18:37:44 +0200 (MET DST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id JAA17298; Tue, 17 Apr 2001 09:35:51 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AGE00786; Tue, 17 Apr 2001 09:37:11 -0700 (PDT) From: "Andrea Westerinen" To: "Juergen Schoenwaelder" , Cc: , Subject: RE: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001? Date: Tue, 17 Apr 2001 09:38:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200104171516.RAA12344@henkell.ibr.cs.tu-bs.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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:schoenw@ibr.cs.tu-bs.de] Sent: Tuesday, April 17, 2001 8:16 AM To: pras@ctit.utwente.nl Cc: jp.martin-flatin@ieee.org; andreaw@cisco.com; nmrg@ibr.cs.tu-bs.de 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? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id RAA22021 for nmrg-outgoing; Tue, 17 Apr 2001 17:16:15 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id RAA22006; Tue, 17 Apr 2001 17:16:00 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA12344; Tue, 17 Apr 2001 17:16:00 +0200 Date: Tue, 17 Apr 2001 17:16:00 +0200 Message-Id: <200104171516.RAA12344@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: pras@ctit.utwente.nl CC: jp.martin-flatin@ieee.org, andreaw@cisco.com, nmrg@ibr.cs.tu-bs.de In-reply-to: <3ADC3E7D.F856E2CC@ctit.utwente.nl> (message from Aiko Pras on Tue, 17 Apr 2001 15:00:45 +0200) Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001? References: <3ACB94CB.4F4BCBD3@research.att.com> <3ADC3E7D.F856E2CC@ctit.utwente.nl> Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id PAA13047 for nmrg-outgoing; Tue, 17 Apr 2001 15:02:57 +0200 (MET DST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id PAA13040 for ; Tue, 17 Apr 2001 15:02:55 +0200 (MET DST) Received: from ctit.utwente.nl (utip064.cs.utwente.nl [130.89.12.90]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id PAA06275; Tue, 17 Apr 2001 15:01:03 +0200 (MET DST) Message-ID: <3ADC3E7D.F856E2CC@ctit.utwente.nl> Date: Tue, 17 Apr 2001 15:00:45 +0200 From: Aiko Pras X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "J.P. Martin-Flatin" CC: Andrea Westerinen , Network Management Research Group Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001? References: <3ACB94CB.4F4BCBD3@research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk "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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id NAA06831 for nmrg-outgoing; Wed, 11 Apr 2001 13:29:23 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id NAA06823; Wed, 11 Apr 2001 13:29:19 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA01878; Wed, 11 Apr 2001 13:29:19 +0200 Date: Wed, 11 Apr 2001 13:29:19 +0200 Message-Id: <200104111129.NAA01878@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: Network Management Research Group Subject: [nmrg] please post draft-irtf-nmrg-snmp-compression-01.txt Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id QAA28550 for nmrg-outgoing; Tue, 10 Apr 2001 16:56:53 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id QAA28542; Tue, 10 Apr 2001 16:56:52 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA28257; Tue, 10 Apr 2001 16:56:52 +0200 Date: Tue, 10 Apr 2001 16:56:52 +0200 Message-Id: <200104101456.QAA28257@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] snmp payload compression update Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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] Author's Address Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3289 EMail: schoenw@ibr.cs.tu-bs.de 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] Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id XAA08395 for nmrg-outgoing; Wed, 4 Apr 2001 23:02:55 +0200 (MET DST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id XAA08387; Wed, 4 Apr 2001 23:02:51 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id XAA27022; Wed, 4 Apr 2001 23:02:50 +0200 Date: Wed, 4 Apr 2001 23:02:50 +0200 Message-Id: <200104042102.XAA27022@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: andreaw@cisco.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001? References: Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk >>>>> 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 Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id UAA01001 for nmrg-outgoing; Wed, 4 Apr 2001 20:42:03 +0200 (MET DST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id UAA00918 for ; Wed, 4 Apr 2001 20:42:01 +0200 (MET DST) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id EC86B4CEE7; Wed, 4 Apr 2001 14:41:59 -0400 (EDT) Received: from research.att.com ([135.210.128.159]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id OAA04288; Wed, 4 Apr 2001 14:41:56 -0400 (EDT) Message-ID: <3ACB94CB.4F4BCBD3@research.att.com> Date: Wed, 04 Apr 2001 14:40:27 -0700 From: "J.P. Martin-Flatin" Reply-To: "J.P. Martin-Flatin" X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrea Westerinen Cc: Network Management Research Group Subject: Re: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk 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 Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id SAA23196 for nmrg-outgoing; Wed, 4 Apr 2001 18:33:44 +0200 (MET DST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id SAA23191 for ; Wed, 4 Apr 2001 18:33:42 +0200 (MET DST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA26635 for ; Wed, 4 Apr 2001 09:33:34 -0700 (PDT) Received: from andreawlap (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ABY09460; Wed, 4 Apr 2001 09:32:40 -0700 (PDT) From: "Andrea Westerinen" To: "Network Management Research Group" Subject: [nmrg] Are we still meeting on the Friday-Saturday before IM 2001? Date: Wed, 4 Apr 2001 09:34:09 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk I need to get a room if we are. I have not seen any further mails on this - so, I am asking. Andrea