Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3U9RLN4016273; Tue, 30 Apr 2002 11:27:21 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g3U9RLR13517; Tue, 30 Apr 2002 11:27:21 +0200 Date: Tue, 30 Apr 2002 11:27:21 +0200 Message-Id: <200204300927.g3U9RLR13517@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: jp.martin-flatin@ieee.org CC: nmrg@ibr.cs.tu-bs.de In-reply-to: <3CCDBFF4.5000704@ieee.org> (jp.martin-flatin@ieee.org) Subject: Re: [nmrg] Fwd: Web Service Description Requirements published References: <3CCDBFF4.5000704@ieee.org> Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> J P Martin-Flatin writes: JP> FYI JP> http://www.w3.org/TR/ws-desc-reqs/ Very interesting as they are going through a process very similar to the SMIng process the SMIng WG went through in formalizing requirements. /js -- Juergen Schoenwaelder Received: from jabber.tecsiel.it ([195.31.151.66]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3U7tvN4012794 for ; Tue, 30 Apr 2002 09:55:58 +0200 Received: from tecsiel.it (localhost [127.0.0.1]) by jabber.tecsiel.it (8.9.3+Sun/8.9.3) with ESMTP id AAA05953; Tue, 30 Apr 2002 00:56:01 -0700 (PDT) Message-ID: <3CCE4E11.C0591364@tecsiel.it> Date: Tue, 30 Apr 2002 09:56:01 +0200 From: Luca Deri Reply-To: l.deri@tecsiel.it Organization: NETikos S.p.A. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: IRTF Network Management Research Group CC: Rocco Carbone Subject: Re: [nmrg] SOAP and WEB Services References: <3CC95CEE.7010103@ctit.utwente.nl> <3CC9A73F.5020609@ieee.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi all, in my opinion: - SOAP security is the second problem (hopefully somebody will fix this in the coming years) - SOAP complexity is the problem. I've played some experiments with it some months ago and I can tell you that it's not simple to learn and use. I understand that the complexity is necessary as it is very powerful. However the problem remains. I still prefer to use XML-RPC because it's simple to use, it's not OO, although SOAP is now one of the hottest tech. Some links: - http://weblog.masukomi.org/writings/xml-rpc_vs_soap.htm - http://www.xmlrpc.com/ The same problem applies to UDDI (http://www.uddi.org/) that's a mess compared to LDAP. Bottom line: XML is currently a hot technology. IMHO it's like Java (Corba and many more) in the early days: you're cool if you're rewriting all your stuff in Java. Today the same happens with XML. This trend will last for a while until this technology fills a nicle (today Java is basically used only on Java side apps) and a new technology comes. Cheers, Luca PS: Why do you want to move SOAP across a firewall? Aren't you just happy enough of CodeRed &co? PS2: If you want to check the content you need at least an XML proxy (something like squid-XML). "J.P. Martin-Flatin" wrote: > > Router filtering (i.e., filtering based on IP addresses and ports) is too > coarse grained for organizations that are serious about security, so they > run firewalls that look into the payload. Some ASICs can do pattern > matching very fast, on the fly. > > The argument that all protocols should be built on top of HTTP to traverse > firewalls easily only stands for small and midsize enterprises. They use > router filtering because they cannot afford full-blown firewalls, which > cost a fortune, and because they lack the know-how to maintain such > firewall systems. > > JP > > Frank Strauss wrote: > > Making a packet filtering firewall look into the payload and parse the > > HTTP content would be a bad and dangerous choice, since (a) HTTP > > requests might look very differently so that safe filtering would > > become very difficult and unreliable and (b) it would be too complex > > and time consuming. > > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust > !! your settings, send a mail message to > !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. -- Luca Deri NETikos S.p.A. Via Matteucci 34/B 56124 Pisa, Italy. Ph. +39/050/968.639 Fax. +39/050/968.626 Personal: luca@lucaderi.org Business: luca.deri@netikos.com WWW: http://www.lucaderi.org/ ICQ: 68183632 Hacker: someone who loves to program and enjoys being clever about it - Richard Stallman Received: from mta1n.bluewin.ch (mta1n.bluewin.ch [195.186.1.210]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3TLknN4023421 for ; Mon, 29 Apr 2002 23:46:49 +0200 Received: from ieee.org (62.202.164.128) by mta1n.bluewin.ch (Bluewin AG 6.0.040) id 3CBAF3690028954A for nmrg@ibr.cs.tu-bs.de; Mon, 29 Apr 2002 23:46:48 +0200 Message-ID: <3CCDBFF4.5000704@ieee.org> Date: Mon, 29 Apr 2002 23:49:40 +0200 From: "J.P. Martin-Flatin" Reply-To: "J.P. Martin-Flatin" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IRTF Network Management Research Group Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nmrg] Fwd: Web Service Description Requirements published Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: FYI -------- Original Message -------- Subject: Ann: Web Service Description Requirements published Resent-Date: Mon, 29 Apr 2002 14:45:56 -0400 (EDT) Resent-From: xml-dist-app@w3.org Date: Mon, 29 Apr 2002 11:43:57 -0700 From: "Jonathan Marsh" To: , , , , , CC: The Web Service Description Working Group has published the first working draft of its Web Service Description Requirements document: http://www.w3.org/TR/ws-desc-reqs/ We invite comments on this document at public-ws-desc-comments@w3.org. We especially invite review and additional potential requirements from the following groups: Web Services Architecture Working Group RDF Interest Group XForms Working Group - Jonathan Marsh, WS Desc WG Chair Received: from mta1n.bluewin.ch (mta1n.bluewin.ch [195.186.1.210]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3QJH9N4032638 for ; Fri, 26 Apr 2002 21:17:10 +0200 Received: from ieee.org (213.3.46.187) by mta1n.bluewin.ch (Bluewin AG 6.0.040) id 3CBAF369002231DE for nmrg@ibr.cs.tu-bs.de; Fri, 26 Apr 2002 21:17:04 +0200 Message-ID: <3CC9A73F.5020609@ieee.org> Date: Fri, 26 Apr 2002 21:15:11 +0200 From: "J.P. Martin-Flatin" Reply-To: "J.P. Martin-Flatin" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IRTF Network Management Research Group Subject: Re: [nmrg] SOAP and WEB Services References: <3CC95CEE.7010103@ctit.utwente.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Router filtering (i.e., filtering based on IP addresses and ports) is too coarse grained for organizations that are serious about security, so they run firewalls that look into the payload. Some ASICs can do pattern matching very fast, on the fly. The argument that all protocols should be built on top of HTTP to traverse firewalls easily only stands for small and midsize enterprises. They use router filtering because they cannot afford full-blown firewalls, which cost a fortune, and because they lack the know-how to maintain such firewall systems. JP Frank Strauss wrote: > Making a packet filtering firewall look into the payload and parse the > HTTP content would be a bad and dangerous choice, since (a) HTTP > requests might look very differently so that safe filtering would > become very difficult and unreliable and (b) it would be too complex > and time consuming. Received: from roam.psg.com (H-135-207-10-70.research.att.com [135.207.10.70]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3QEbFN4022758 for ; Fri, 26 Apr 2002 16:37:16 +0200 Received: from randy by roam.psg.com with local (Exim 4.04) id 1716qX-000Cc5-00; Fri, 26 Apr 2002 10:37:13 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Aiko Pras Cc: "Wijnen, Bert (Bert)" , "Nmrg (E-mail)" Subject: Re: [nmrg] SOAP and WEB Services References: <3CC95CEE.7010103@ctit.utwente.nl> Message-Id: Date: Fri, 26 Apr 2002 10:37:13 -0400 Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: soap is remote procedure call with in-flight modification allowed. the word "security" should not even be used in the same sentence. randy Received: from hansa.ibr.cs.tu-bs.de (root@hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3QEYCN4022504; Fri, 26 Apr 2002 16:34:12 +0200 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -5) with ESMTP id g3QEYCRr001488; Fri, 26 Apr 2002 16:34:12 +0200 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -5) id g3QEYCPu001484; Fri, 26 Apr 2002 16:34:12 +0200 From: Frank Strauss To: Aiko Pras Cc: "Wijnen, Bert (Bert)" , "Nmrg (E-mail)" Subject: Re: [nmrg] SOAP and WEB Services References: <3CC95CEE.7010103@ctit.utwente.nl> Date: 26 Apr 2002 16:34:12 +0200 In-Reply-To: <3CC95CEE.7010103@ctit.utwente.nl> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi! Aiko> Thanks for the pointer (http://www.prescod.net/rest/security.html). It Aiko> seems the website argues that SOAP is less secure since it uses common Aiko> and succesfull technology. The website proposes not to use such Aiko> technology, but invent something new: security by obscurity! Aiko> Great, I like that ;-) I don't think, this is what SOAP opponents propose. They just point out that the `benefit' of shipping SOAP via TCP port 80 (what many people assiciate with using HTTP) is in fact a severe problem in some environments. >> "SOAP is designed to slip through firewalls as HTTP... This is >> completely ridiculous from a security point of view. Aiko> I think the main design decision was to run SOAP over HTTP. As a Aiko> consequence, some firewalls may not be able to distinguish SOAP from Aiko> other HTTP traffic. Wouldn't it be easy to create new firewalls / Aiko> configure existing firewall such that they recognize SOAP?? (by using Aiko> different ports or look inside the HTTP packet)? Using different ports even when the SOAP transport is HTTP would probably be a solution to keep this kind of access control at the firewall entity. Making a packet filtering firewall look into the payload and parse the HTTP content would be a bad and dangerous choice, since (a) HTTP requests might look very differently so that safe filtering would become very difficult and unreliable and (b) it would be too complex and time consuming. -frank Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3QDw8N4021186 for ; Fri, 26 Apr 2002 15:58:08 +0200 Received: from ctit.utwente.nl (utip250.cs.utwente.nl [130.89.12.39]) by netlx010.civ.utwente.nl (8.11.4/HKD) with ESMTP id g3QDw6m17992; Fri, 26 Apr 2002 15:58:06 +0200 Message-ID: <3CC95CEE.7010103@ctit.utwente.nl> Date: Fri, 26 Apr 2002 15:58:06 +0200 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "Nmrg (E-mail)" Subject: Re: [nmrg] SOAP and WEB Services References: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi Bert Thanks for the pointer (http://www.prescod.net/rest/security.html). It seems the website argues that SOAP is less secure since it uses common and succesfull technology. The website proposes not to use such technology, but invent something new: security by obscurity! Great, I like that ;-) > "SOAP is designed to slip through firewalls as HTTP... This is > completely ridiculous from a security point of view. I think the main design decision was to run SOAP over HTTP. As a consequence, some firewalls may not be able to distinguish SOAP from other HTTP traffic. Wouldn't it be easy to create new firewalls / configure existing firewall such that they recognize SOAP?? (by using different ports or look inside the HTTP packet)? Anyway, I'll have to read the website with more care (fun); we could have a nice discussion on this :-) Have a nice weekend Aiko Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3Q98bN4010228; Fri, 26 Apr 2002 11:08:37 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g3Q98b923447; Fri, 26 Apr 2002 11:08:37 +0200 Date: Fri, 26 Apr 2002 11:08:37 +0200 Message-Id: <200204260908.g3Q98b923447@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: bwijnen@lucent.com CC: nmrg@ibr.cs.tu-bs.de In-reply-to: (bwijnen@lucent.com) Subject: Re: [nmrg] SOAP and WEB Services References: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> Wijnen, Bert (Bert) writes: Bert> It's message is summarized: Bert> "SOAP is designed to slip through firewalls as HTTP... This is Bert> completely ridiculous from a security point of view. People who understand networks well enough know that tunneling everything over HTTP is a ridiculous concept. Unfortunately, these people are in the minority and do not have the "handles" to control the public opinion. So eventually even people who know better give in and accept that running everything over HTTP is a feature. (And some of those who do not give in start to work on protocols which drill holes into firewall on user requests. :-) /js -- Juergen Schoenwaelder Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3PLvWN4017463 for ; Thu, 25 Apr 2002 23:57:32 +0200 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3PLvPY29276 for ; Thu, 25 Apr 2002 17:57:25 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2GN8AQNS>; Thu, 25 Apr 2002 23:57:24 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: "Nmrg (E-mail)" Date: Thu, 25 Apr 2002 23:57:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [nmrg] SOAP and WEB Services Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Since we discussed this last weekend... here is some input --------- Here's an example of some of the concerns about SOAP: http://www.prescod.net/rest/security.html It's message is summarized: "SOAP is designed to slip through firewalls as HTTP... This is completely ridiculous from a security point of view. "Firewalls exist so that corporations can monitor what goes in and out. If they wanted SOAP going in and out then they would configure their firewalls that way. But instead of making the reasoned argument to CIOs that SOAP is safe and should go through firewalls, it is instead tunneled over HTTP. This moves the decision out of the hands of the CIOs and into the hands of the software developer." and "The Web Services world must slow down and consider the security implications of its creations with much more rigour. " Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3ICMBCT021640; Thu, 18 Apr 2002 14:22:11 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g3ICMBQ25729; Thu, 18 Apr 2002 14:22:11 +0200 Date: Thu, 18 Apr 2002 14:22:11 +0200 Message-Id: <200204181222.g3ICMBQ25729@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: Network Management Research Group In-reply-to: <200204171503.g3HF3sd18907@haerke.ibr.cs.tu-bs.de> (message from Juergen Schoenwaelder on Wed, 17 Apr 2002 17:03:54 +0200) Subject: Re: [nmrg] meeting info References: <200204171503.g3HF3sd18907@haerke.ibr.cs.tu-bs.de> Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: >>>>> Juergen Schoenwaelder writes: Juergen> (2) I would like to remind people that they prepare a short Juergen> statement how they envision networks to be managed in 5-10 Juergen> years from now. Just to clarify: I am trying to get a discussion of visions going. The statement "everything will be the same as today, perhaps a bit worse" does not really count in this respect (even if one can argue that this is the most realistic scenario ;-). So please think a bit about the vision you will present and be prepared to defend it. I have been told that buying train tickets can actually take some time since you usually end up standing in a line. So it is a good idea to either buy the ticket this evening or to be at the station early enough. /js -- Juergen Schoenwaelder Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g3HF3s06010399; Wed, 17 Apr 2002 17:03:54 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g3HF3sd18907; Wed, 17 Apr 2002 17:03:54 +0200 Date: Wed, 17 Apr 2002 17:03:54 +0200 Message-Id: <200204171503.g3HF3sd18907@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] meeting info Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Some information and reminders for the upcoming meeting: (1) There is a train running from Florence to Pisa which leaves Florence at 9:25 and which arrives in Pisa around 10:30. I suggest we take this train - even if this means to start a bit late in case it takes more than 30 minutes to check into the hotels and to find the meeting site. (2) I would like to remind people that they prepare a short statement how they envision networks to be managed in 5-10 years from now. (3) Some people approached me in Florence asking me to reorder the agenda. I am open for any changes and thus would like to add agenda bashing as agenda item 0. /js -- Juergen Schoenwaelder Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g39FUSGY023966; Tue, 9 Apr 2002 17:30:28 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g39FUSu12964; Tue, 9 Apr 2002 17:30:28 +0200 Date: Tue, 9 Apr 2002 17:30:28 +0200 Message-Id: <200204091530.g39FUSu12964@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: Network Management Research Group Subject: [nmrg] pisa meeting Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Below is the final agenda. Note that I did not put in time estimates for the various agenda items. This is on purpose since I am not sure how we fill in the open positions. Note that Dave Perkins won't attend - but perhaps he contributes electronically or submits slides with his points to the list prior to the meeting. Dave Harrington won't be in Pisa, but Bert Wijnen will be in Florence and Pisa. I propose that we start the meeting at 11:00 am in Pisa since some people will leave the move from Florence to Pisa on Friday morning. Starting at 11:00 am gives enough time to switch hotels and to move to Pisa and it still allows to go through some of the status reports before we have lunch together. I wish you all a good trip to Pisa/Florence. /js -- Juergen Schoenwaelder 10th NMRG Meeting in Pisa The 10th NMRG meeting will take place in [1]Pisa (Italy) on April 19-20 2002, just after the [2]NOMS 2002 conference. The meeting will start at 11:00 am on April 19th. The address of the meeting place: NETikos Via Matteucci 34/b Pisa, Italy How to get to the meeting place: Take the train "Firenze SMN -> Pisa Centrale". Once in Pisa you can take a taxi to here (it will cost ~5 Euros). Once here you'll see a relatively big building, flat (at the bottom there's a shop called Media World that is the equivalent of the German Media Markt) with 2 (sort of) towers. Between the two towers there's a (sort of) gallery. In the middle of the gallery there's the entrance. You take the lift up to NETikos. The meeting will take place in the meeting room at the 4th floor: once out of the lift you must ring the bell. Otherwise at the 5th and 6th floor you can ask at the reception. For a map of Pisa go to [3]http://mappe.virgilio.it/mappe/index.html and select Pisa (it's in Italian but quite strightforward). Accomodation: [4]http://www.pisaonline.it/Pisa/Hotels.htm Flight: The airport in Florence has a rather short runway and it's located in a very bad place. If you can, choose Pisa (there are direct daily flight to/from London,Frankfurt,Rome,Milan) and then from the Pisa Airport you take the train (it's inside the airport itself) to Florence (Pisa Airport -> Center of Florence takes a bit more that Florence Airport -> Center of Florence). The train ticket (1 way) will not cost much (< 10 Euros). For more info [5]http://www.trenitalia.com/. Agenda: 1. Status Reports There are several documents we started and where we need to have status reports and develop a plan on how to proceed with them: + SNMP over TCP (Juergen Schoenwaelder) + SNMP Payload Compression (Juergen Schoenwaelder) + Subtree Retrieval (?) + Information Modeling vs. Data Modeling (Szabolcs Boros) Other activities what were or might be issues for the NMRG: + SMIng (Juergen Schoenwaelder / Frank Strauss) + SMI to XML and XML schema conversions (Frank Strauss) 2. Alarm Models The goal of this agenda item is to discuss and compare various existing and proposed alarm models. The focus is on the conceptual models being used, not on specific technical realisations of the models. + ITU Alarm Model(?) + IETF DISMAN Alarm Model (?) + CIM Alarm/Event Model (Jean-Philippe Martin-Flatin) + Universal Alarm Model (all) 3. Network Management Visions There are quite some discussions going on in various places what the future (5-10 years) of network management will be. There are several different scenarios one can imagine and it might be worthwhile to develop a joint view of what the goals, influencing factors, dependencies and problems with various visions are. We are going to make an experiment: Each participant should think up one scenario and prepare a 5-10 minute presentation (1-2 slides) to describe the may ideas. Extreme positions are welcome - of course people should be able to defend their scenarios afterwards. + Presentation/Discussion of Scenarios (all) + Identification of impact factors (all) + Identification of research aspects (all) 4. Future of the NMRG We need to discuss whether the NMRG still works well or whether it is time to change its operational mode. Things to consider might be to invite new fresh people, to discuss future topics and research directions, or to revisit our current organization and mode of operation. Expected Participants: * Jean-Philippe Martin-Flatin (independent consultant) * Marcus Brunner (NEC C&C Research) * Juergen Schoenwaelder (University of Osnabrueck) * John Strassner (Intelliden) * Szabolcs Boros (University of Twente) * Luca Deri (NETikos S.p.A.) * Frank Strauss (TU Braunschweig) * Dave Harrington (Enterasys) [no] * Bert Wijnen (Lucent Technologies) * Aiko Pras (University of Twente) [maybe] * Dave Perkins (Riverstone) [no] * Andrea Westerinen (Cisco Systems) [no] * Joseph L Hellerstein (IBM Research) [no] * Wes Hardaker (Network Associates) [no] The local host of this meeting [6]NETikos. Our contact is [7]Luca Deri. © IBR, TU Braunschweig, last updated 09-04-2002 17:28:58 by Juergen Schoenwaelder <[8]schoenw@ibr.cs.tu-bs.de> References 1. http://www.pisaonline.it/ 2. http://www.comsoc.org/confs/noms/2002/index.html 3. http://mappe.virgilio.it/mappe/index.html 4. http://www.pisaonline.it/Pisa/Hotels.htm 5. http://www.trenitalia.com/ 6. http://www.netikos.com/ 7. mailto:l.deri@tecsiel.it 8. mailto:schoenw@ibr.cs.tu-bs.de Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g340P33t011079 for ; Thu, 4 Apr 2002 02:25:05 +0200 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g340OCS12960; Wed, 3 Apr 2002 19:24:13 -0500 (EST) Received: from zrtpd0j9.us.nortel.com ([47.140.203.27]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GVX40PZY; Wed, 3 Apr 2002 19:24:13 -0500 Received: from americasm01.nt.com (actft0u0.europe.nortel.com [47.164.200.114]) by zrtpd0j9.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HCGKG6JB; Wed, 3 Apr 2002 19:24:12 -0500 Message-ID: <3CAB9E3B.FE60DCF6@americasm01.nt.com> Date: Wed, 03 Apr 2002 19:28:43 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Dave Sidor" Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Harrington, David" CC: "NMRG (E-mail)" Subject: Re: [nmrg] nmrg agenda References: <0BF8B32B723ED5119E0B0002A551748B03054692@corp-exc3.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: David et al, Re your item 5, you may interested to know that for at least 1-2 years telecom industry standards have moved beyond CMIP and now view CORBA GIOP and IDL as the NM technology of choice. That is true of ITU-T SG 4, the current owner of CMIP (X.700 series), and also of 3GPP SA5 responsible for 3G UMTS wireless. In addition, the TeleManagement Forum has issued some respected CORBA specs as well. And XML is not far behind. The prime motivation in my view for this change is to take advantage of an industrial-strength IT technologies to support management systems built from OTS components. Hope things go well with your father. Dave Sidor Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.enterasys.com [12.25.1.120]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g33KLL3t002645 for ; Wed, 3 Apr 2002 22:21:22 +0200 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA22587 for ; Wed, 3 Apr 2002 15:31:19 -0500 (EST) Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma022410; Wed, 3 Apr 02 15:30:59 -0500 Received: by smtp.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 15:19:39 -0500 Message-ID: <0BF8B32B723ED5119E0B0002A551748B0305469A@corp-exc3.ctron.com> From: "Harrington, David" To: "NMRG (E-mail)" Date: Wed, 3 Apr 2002 15:19:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB4C.D41C5AB0" Subject: [nmrg] change of plans Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB4C.D41C5AB0 Content-Type: text/plain; charset="iso-8859-1" Hi, Late-breaking news. I will NOT be attending the NMRG meeting. My father has been hospitalized and the condition is serious, so I can't make it. David Harrington Network Management Architect Office of the CTO Enterasys Networks ------_=_NextPart_001_01C1DB4C.D41C5AB0 Content-Type: text/html; charset="iso-8859-1" change of plans

Hi,

Late-breaking news. I will NOT be attending the NMRG meeting.
My father has been hospitalized and the condition is serious, so I can't make it.

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks
 

------_=_NextPart_001_01C1DB4C.D41C5AB0-- Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g33JxZ3t001923 for ; Wed, 3 Apr 2002 21:59:37 +0200 Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA08053; Wed, 3 Apr 2002 11:59:29 -0800 (PST) Message-Id: <5.0.2.1.2.20020403111715.03120e90@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 03 Apr 2002 11:56:15 -0800 To: "NMRG (E-mail)" From: "David T. Perkins" Subject: Re: [nmrg] nmrg agenda In-Reply-To: <0BF8B32B723ED5119E0B0002A551748B03054692@corp-exc3.ctron.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10871917==_.ALT" Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: --=====================_10871917==_.ALT Content-Type: text/plain; charset="us-ascii" HI, Thanks for the interesting message. Many people have observed that the IETF has become less "efficient" as it has been growing in size. Where this is most visible is in WGs that are creating designs instead of taking existing designs and practices and creating standard that is a composition using the most appropriate portions of these existing designs and practices. Also, in the management area, an important aspect is how a management system is used. But if the design creates a technology that has never existed, how can you tell if the usability (the operational aspects) are OK. One way to address these issues is to have the IRTF be more active in creating designs, creating implemenations, and also gathering feedback from deployments before starting up a WG. With the experiences from the research groups (and possibly some vendors), a WG can be much more efficient in creating a standard (and the standard most likely will be "better" - complete, implementable, unambiguous, useful, etc). Of course, funding this "applied research" is always an issue, and it seems like network management doesn't get many research funding. So, don't have the solutions, but do believe that a NMRG focused designing and trying out approaches to contained problems would be quite beneficial to the IETF and has a higher probability of obtaining funding. PS I've gone back and forth about attending. Personal safety given the terrorist threats and unrest in the middle-east is a concern, as well as how effective will be the meeting. Ideally, would like to "conference call" into the meeting. At 01:05 PM 4/3/2002 -0500, Harrington, David wrote: >Hi, > >I'll be attending the NMRG, but not the NOMS meeting. I'll be vacationing in the area from the 10th on. > >I'm interested in knowing the agenda. We seem to have an odd assortment of attendees, many noted for highly-focused interests. (Please note I did NOT say an assortment of odd attendees ;-) It should be interesting comparing views. > >I am interested in some discussion of NM futures, but I don't know how the nmrg fits into that now, given the dilbert-vision discussions and the IAB NM Workshop planned for this summer. For those not in the IETF, dilbert-vision is a group of interested persons, primarily leaders in the NM community, discussing visions for the future of network management. The IAB is the Internet Architectur Board, and they study general trends in Internet protocol designs, and hold workshops to discuss the overall needs and directions to provide guidance to the IESG, area directors and working groups. > >Maybe this would be an excellent time to have such a discussion in the nmrg, as input to further discussion in the IETF venues. Here's a real chance to influence the IETF 50,000 foot vision for NM. > >I would like to raise some particular questions for discussion. > >1) Existing NM protocols tend to differentiate different aspects: > Knowing (data modeling), > telling (message protocols), > crunching (converting data into service or business information), and > showing (user interfaces). > Are these aspects well enough understood to know what the requirements are? > Is there sufficient synergy between existing approaches for integration? > >2) Established NM protocols (SNMP, CMIP, TL1) tend to be horizontal - they are designed to be general purpose to encourage reuse for multiple purposes. Some are arguing for a more vertical approach - monitoring versus static configuration versus dynamic configuration. Is one way more appropriate than the other? Does vertical differentiation limit the potential for reuse? Does the general purpose focus keep some protocols from being truly useful in vertical applications? > >3) Computer languages and software development have gone through four generations - binary, assembly, procedural, and object-oriented. > >SNMP tends to be assembly-like with its peek/poke semantics; CLIs tend to be procedural; COPS and XML and SMING are focusing on bringing more object-orientedness to NM. Data-hiding is good in software development, but is it good for NM standards? Is the need for backwards compatibility with a 2nd-generation approach (SNMP) holding us back from providing useful alternatives? > >4) The web really has led to a fifth generation of languages and software development - distributed processing. Obviously distributed processing has been around for a long time, but the web made it easy and ubiquitous. Web services are coming on strong, with Microsoft's .NET, Sun J2EE, and IBM's WebSphere battling it out in marketing hype. > >Are any of the concepts real enough to apply to NM standards? Is NM just a special case of distributed processing? Should the industry be working to harness emerging distributed processing standards for NM use, rather than tweaking the assembly-style SMI, and trying to standardize procedural CLIs? > >The web services marketechtures all seem to build on the use of virtual machines to support multi-platform portability. .NET focuses on multi-language support as well. Could the NM community design a "virtual machine" that could support multiple languages, or are the different languages too different to allow a language neutral approach? > >5) Years ago, SNMP was developed by selecting a subset of CMIP. We seem to be moving closer and closer to CMIP. Should the industry consider taking CMIP, and selecting a light-weight subset that is more powerful than SNMP? Or should the industry be studying CMIP to see what it did right and what it did wrong, so we don't remake SNMP in its likeness, including its faults? > >-- >All of these questions have been raised before, at least to a degree. Many people are strong proponents of one or more of these possible approaches. > >What research can the NMRG do to help sort out the competing requirements, to help various standards bodies make progress at evaluating the tradeoffs, so they can develop standards for some of these problems? > >See you there, > >David Harrington >Network Management Architect >Office of the CTO >Enterasys Networks Regards, /david t. perkins --=====================_10871917==_.ALT Content-Type: text/html; charset="us-ascii" HI,

Thanks for the interesting message.

Many people have observed that the IETF has become less "efficient"
as it has been growing in size. Where this is most visible is
in WGs that are creating designs instead of taking existing
designs and practices and creating standard that is a composition
using the most appropriate portions of these existing designs
and practices. Also, in the management area, an important aspect
is how a management system is used. But if the design creates a
technology that has never existed, how can you tell if the usability
(the operational aspects) are OK. One way to address these issues
is to have the IRTF be more active in creating designs, creating
implemenations, and also gathering feedback from deployments
before starting up a WG. With the experiences from the research
groups (and possibly some vendors), a WG can be much more efficient
in creating a standard (and the standard most likely will be
"better" - complete, implementable, unambiguous, useful, etc).

Of course, funding this "applied research" is always an issue, and
it seems like network management doesn't get many research funding.

So, don't have the solutions, but do believe that a NMRG focused
designing and trying out approaches to contained problems would
be quite beneficial to the IETF and has a higher probability of
obtaining funding.

PS  I've gone back and forth about attending. Personal safety
given the terrorist threats and unrest in the middle-east is
a concern, as well as how effective will be the meeting. Ideally,
would like to "conference call" into the meeting.

At 01:05 PM 4/3/2002 -0500, Harrington, David wrote:
Hi,

I'll be attending the NMRG, but not the NOMS meeting. I'll be vacationing in the area from the 10th on.

I'm interested in knowing the agenda. We seem to have an odd assortment of attendees, many noted for highly-focused interests. (Please note I did NOT say an assortment of odd attendees ;-) It should be interesting comparing views.

I am interested in some discussion of NM futures, but I don't know how the nmrg fits into that now, given the dilbert-vision discussions and the IAB NM Workshop planned for this summer. For those not in the IETF, dilbert-vision is a group of interested persons, primarily leaders in the NM community, discussing visions for the future of network management. The IAB is the Internet Architectur Board, and they study general trends in Internet protocol designs, and hold workshops to discuss the overall needs and directions to provide guidance to the IESG, area directors and working groups.

Maybe this would be an excellent time to have such a discussion in the nmrg, as input to further discussion in the IETF venues. Here's a real chance to influence the IETF 50,000 foot vision for NM.

I would like to raise some particular questions for discussion.

1) Existing NM protocols tend to differentiate different aspects:
        Knowing (data modeling),
        telling (message protocols),
        crunching (converting data into service or business information), and
        showing (user interfaces).
   Are these aspects well enough understood to know what the requirements are?
   Is there sufficient synergy between existing approaches for integration?

2) Established NM protocols (SNMP, CMIP, TL1) tend to be horizontal - they are designed to be general purpose to encourage reuse for multiple purposes. Some are arguing for a more vertical approach - monitoring versus static configuration versus dynamic configuration. Is one way more appropriate than the other? Does vertical differentiation limit the potential for reuse? Does the general purpose focus keep some protocols from being truly useful in vertical applications?

3) Computer languages and software development have gone through four generations - binary, assembly, procedural, and object-oriented.

SNMP tends to be assembly-like with its peek/poke semantics; CLIs tend to be procedural; COPS and XML and SMING are focusing on bringing more object-orientedness to NM. Data-hiding is good in software development, but is it good for NM standards? Is the need for backwards compatibility with a 2nd-generation approach (SNMP) holding us back from providing useful alternatives?

4) The web really has led to a fifth generation of languages and software development - distributed processing. Obviously distributed processing has been around for a long time, but the web made it easy and ubiquitous. Web services are coming on strong, with Microsoft's .NET, Sun J2EE, and IBM's WebSphere battling it out in marketing hype.

Are any of the concepts real enough to apply to NM standards? Is NM just a special case of distributed processing? Should the industry be working to harness emerging distributed processing standards for NM use, rather than tweaking the assembly-style SMI, and trying to standardize procedural CLIs?

The web services marketechtures all seem to build on the use of virtual machines to support multi-platform portability. .NET focuses on multi-language support as well. Could the NM community design a "virtual machine" that could support multiple languages, or are the different languages too different to allow a language neutral approach?

5) Years ago, SNMP was developed by selecting a subset of CMIP. We seem to be moving closer and closer to CMIP. Should the industry consider taking CMIP, and selecting a light-weight subset that is more powerful than SNMP? Or should the industry be studying CMIP to see what it did right and what it did wrong, so we don't remake SNMP in its likeness, including its faults?

--
All of these questions have been raised before, at least to a degree. Many people are strong proponents of one or more of these possible approaches.

What research can the NMRG do to help sort out the competing requirements, to help various standards bodies make progress at evaluating the tradeoffs, so they can develop standards for some of these problems?

See you there,

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks

Regards,
/david t. perkins

--=====================_10871917==_.ALT-- Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.enterasys.com [12.25.1.120]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g33I8F3t030550 for ; Wed, 3 Apr 2002 20:08:15 +0200 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id NAA11716 for ; Wed, 3 Apr 2002 13:18:12 -0500 (EST) Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma011680; Wed, 3 Apr 02 13:17:18 -0500 Received: by smtp.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 13:05:59 -0500 Message-ID: <0BF8B32B723ED5119E0B0002A551748B03054692@corp-exc3.ctron.com> From: "Harrington, David" To: "NMRG (E-mail)" Date: Wed, 3 Apr 2002 13:05:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB3A.27721AA0" Subject: [nmrg] nmrg agenda Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1DB3A.27721AA0 Content-Type: text/plain; charset="iso-8859-1" Hi, I'll be attending the NMRG, but not the NOMS meeting. I'll be vacationing in the area from the 10th on. I'm interested in knowing the agenda. We seem to have an odd assortment of attendees, many noted for highly-focused interests. (Please note I did NOT say an assortment of odd attendees ;-) It should be interesting comparing views. I am interested in some discussion of NM futures, but I don't know how the nmrg fits into that now, given the dilbert-vision discussions and the IAB NM Workshop planned for this summer. For those not in the IETF, dilbert-vision is a group of interested persons, primarily leaders in the NM community, discussing visions for the future of network management. The IAB is the Internet Architectur Board, and they study general trends in Internet protocol designs, and hold workshops to discuss the overall needs and directions to provide guidance to the IESG, area directors and working groups. Maybe this would be an excellent time to have such a discussion in the nmrg, as input to further discussion in the IETF venues. Here's a real chance to influence the IETF 50,000 foot vision for NM. I would like to raise some particular questions for discussion. 1) Existing NM protocols tend to differentiate different aspects: Knowing (data modeling), telling (message protocols), crunching (converting data into service or business information), and showing (user interfaces). Are these aspects well enough understood to know what the requirements are? Is there sufficient synergy between existing approaches for integration? 2) Established NM protocols (SNMP, CMIP, TL1) tend to be horizontal - they are designed to be general purpose to encourage reuse for multiple purposes. Some are arguing for a more vertical approach - monitoring versus static configuration versus dynamic configuration. Is one way more appropriate than the other? Does vertical differentiation limit the potential for reuse? Does the general purpose focus keep some protocols from being truly useful in vertical applications? 3) Computer languages and software development have gone through four generations - binary, assembly, procedural, and object-oriented. SNMP tends to be assembly-like with its peek/poke semantics; CLIs tend to be procedural; COPS and XML and SMING are focusing on bringing more object-orientedness to NM. Data-hiding is good in software development, but is it good for NM standards? Is the need for backwards compatibility with a 2nd-generation approach (SNMP) holding us back from providing useful alternatives? 4) The web really has led to a fifth generation of languages and software development - distributed processing. Obviously distributed processing has been around for a long time, but the web made it easy and ubiquitous. Web services are coming on strong, with Microsoft's .NET, Sun J2EE, and IBM's WebSphere battling it out in marketing hype. Are any of the concepts real enough to apply to NM standards? Is NM just a special case of distributed processing? Should the industry be working to harness emerging distributed processing standards for NM use, rather than tweaking the assembly-style SMI, and trying to standardize procedural CLIs? The web services marketechtures all seem to build on the use of virtual machines to support multi-platform portability. .NET focuses on multi-language support as well. Could the NM community design a "virtual machine" that could support multiple languages, or are the different languages too different to allow a language neutral approach? 5) Years ago, SNMP was developed by selecting a subset of CMIP. We seem to be moving closer and closer to CMIP. Should the industry consider taking CMIP, and selecting a light-weight subset that is more powerful than SNMP? Or should the industry be studying CMIP to see what it did right and what it did wrong, so we don't remake SNMP in its likeness, including its faults? -- All of these questions have been raised before, at least to a degree. Many people are strong proponents of one or more of these possible approaches. What research can the NMRG do to help sort out the competing requirements, to help various standards bodies make progress at evaluating the tradeoffs, so they can develop standards for some of these problems? See you there, David Harrington Network Management Architect Office of the CTO Enterasys Networks ------_=_NextPart_001_01C1DB3A.27721AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable nmrg agenda

Hi,

I'll be attending the NMRG, but not the NOMS meeting. = I'll be vacationing in the area from the 10th on.

I'm interested in knowing the agenda. We seem to have = an odd assortment of attendees, many noted for highly-focused = interests. (Please note I did NOT say an assortment of odd attendees = ;-) It should be interesting comparing views.

I am interested in some discussion of NM futures, but = I don't know how the nmrg fits into that now, given the dilbert-vision = discussions and the IAB NM Workshop planned for this summer. For those = not in the IETF, dilbert-vision is a group of interested persons, = primarily leaders in the NM community, discussing visions for the = future of network management. The IAB is the Internet Architectur = Board, and they study general trends in Internet protocol designs, and = hold workshops to discuss the overall needs and directions to provide = guidance to the IESG, area directors and working groups.

Maybe this would be an excellent time to have such a = discussion in the nmrg, as input to further discussion in the IETF = venues. Here's a real chance to influence the IETF 50,000 foot vision = for NM.

I would like to raise some particular questions for = discussion.

1) Existing NM protocols tend to differentiate = different aspects:
        Knowing = (data modeling),
        telling = (message protocols),
        crunching = (converting data into service or business information), and
        showing = (user interfaces).
   Are these aspects well enough = understood to know what the requirements are?
   Is there sufficient synergy between = existing approaches for integration?

2) Established NM protocols (SNMP, CMIP, TL1) tend to = be horizontal - they are designed to be general purpose to encourage = reuse for multiple purposes. Some are arguing for a more vertical = approach - monitoring versus static configuration versus dynamic = configuration. Is one way more appropriate than the other? Does = vertical differentiation limit the potential for reuse? Does the = general purpose focus keep some protocols from being truly useful in = vertical applications?

3) Computer languages and software development have = gone through four generations - binary, assembly, procedural, and = object-oriented.

SNMP tends to be assembly-like with its peek/poke = semantics; CLIs tend to be procedural; COPS and XML and SMING are = focusing on bringing more object-orientedness to NM. Data-hiding is = good in software development, but is it good for NM standards? Is the = need for backwards compatibility with a 2nd-generation approach (SNMP) = holding us back from providing useful alternatives?

4) The web really has led to a fifth generation of = languages and software development - distributed processing. Obviously = distributed processing has been around for a long time, but the web = made it easy and ubiquitous. Web services are coming on strong, with = Microsoft's .NET, Sun J2EE, and IBM's WebSphere battling it out in = marketing hype.

Are any of the concepts real enough to apply to NM = standards? Is NM just a special case of distributed processing? Should = the industry be working to harness emerging distributed processing = standards for NM use, rather than tweaking the assembly-style SMI, and = trying to standardize procedural CLIs?

The web services marketechtures all seem to build on = the use of virtual machines to support multi-platform portability. .NET = focuses on multi-language support as well. Could the NM community = design a "virtual machine" that could support multiple = languages, or are the different languages too different to allow a = language neutral approach?

5) Years ago, SNMP was developed by selecting a = subset of CMIP. We seem to be moving closer and closer to CMIP. Should = the industry consider taking CMIP, and selecting a light-weight subset = that is more powerful than SNMP? Or should the industry be studying = CMIP to see what it did right and what it did wrong, so we don't remake = SNMP in its likeness, including its faults?

--
All of these questions have been raised before, at = least to a degree. Many people are strong proponents of one or more of = these possible approaches.

What research can the NMRG do to help sort out the = competing requirements, to help various standards bodies make progress = at evaluating the tradeoffs, so they can develop standards for some of = these problems?

See you there,

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks
 

------_=_NextPart_001_01C1DB3A.27721AA0--