Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6QMfNSA023447; Sun, 27 Jul 2003 00:41:23 +0200 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6QMfHh24283; Sat, 26 Jul 2003 17:41:18 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Jul 2003 00:41:16 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213B9DA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Frank Strauss , Marcus Brunner Cc: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] web page for uml diagrams Date: Sun, 27 Jul 2003 00:41:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C353C6.EEB2D716" X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-9.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SIGNATURE_LONG_SPARSE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 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_000_01C353C6.EEB2D716 Content-Type: text/plain Mmm... the complete set is kind of undoable. So I took just the LDP MIB. I have a .dia file that presents a reasonable picture. I do not have a proper tool to create a PDF file. Can one of you do so? Attached is the .dia file (strange, when it generated the file when I saved it, it seems to put virtually everything on one long line. Oj well). The associations in the MIB itself look awfully complex to me. Other comments? Thanks, Bert > -----Original Message----- > From: Frank Strauss [mailto:strauss@ibr.cs.tu-bs.de] > Sent: woensdag 23 juli 2003 18:12 > To: Marcus Brunner > Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de > Subject: Re: [nmrg] web page for uml diagrams > > > Hi! > > Marcus> I tried to do it for the MPLS MIBs, but I miserably > failed even > Marcus> parsing the MIBs in the latest drafts. But it might > be myself not > Marcus> using the tools correctly. > > >> Could you please point me (us) to the MIBs (or the I-Ds) you've fed > >> to smidump? There are 36 documents in > internet-drafts/*mpls*mib*, and > >> I don't want to check all of them. :-)) > > Marcus> draft-ietf-mpls-ftn-mib-07.txt > Marcus> draft-ietf-mpls-ldp-mib-12.txt > Marcus> draft-ietf-mpls-lsr-mib-11.txt > Marcus> draft-ietf-mpls-tc-mib-08.txt > Marcus> draft-ietf-mpls-te-mib-11.txt > > Thanks. Here is a short description of what I did to check > the modules, > to "repair" them so that they could be further processed, and > to generate > a diagram. Maybe this helps others to do similar things... > > 1. Get the documents. > > 2. Extract the modules using smistrip. (The latest version from CVS of > smistrip now also accepts .gz files and is able to read documents > from a given directory): > > smistrip -i /ftp/docs/internet-drafts \ > draft-ietf-mpls-ftn-mib-07.txt \ > draft-ietf-mpls-ldp-mib-12.txt \ > draft-ietf-mpls-lsr-mib-11.txt \ > draft-ietf-mpls-tc-mib-08.txt \ > draft-ietf-mpls-te-mib-11.txt > > Note that documents that are formatted in an "unexpected" form, may > lead to warnings or even broken MIB modules, because smistrip has > to make some vague assumptions on how to cut off page footers and > headers. > > 3. Check the extracted modules with smilint. If not otherwise set, the > local directory might have to be added to the paths in > which smilint > will search for modules. > > SMIPATH=.: smilint -i namelength-32 MPLS-* > > In this case I wanted to ignore all warnings about identifiers that > are longer than 32 chars. The errors that remain complain > about "XXX" > placeholders for a number of registrations. > > 4. Fix errors, if required. In this case nothing has to be done to > produce the dia diagrams. > > 5. Use smidump to generate whatever I want, e.g. metrics, > trees, diagrams: > > SMIPATH=.: smidump -u -f metrics MPLS-* | less > > SMIPATH=.: smidump -u -f tree MPLS-* | less > > SMIPATH=.: smidump -u -f cm MPLS-* > mpls-model.dia > > The -u option is used to get a "united" representation of all > input modules, instead of separated outputs per module. > > 6. Use dia to drag items around to get a better layout and finally > print the diagram to a PDF file. I have not yet done this. It > seems to be quite some work in this case. :-) The non-beautified > diagram is at http://www.ibr.cs.tu-bs.de/users/strauss/mpls-model.dia. -frank -- !! 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. ------_=_NextPart_000_01C353C6.EEB2D716 Content-Type: application/octet-stream; name="mpls-ldp-bw.dia" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mpls-ldp-bw.dia" =0A= #A4##Conceptual model of MPLS-LDP-STD-MIB - = generated by smidump = 0.4.1-pre2#= #mplsLdpEntityEntry##smi mib = class####mplsLdpEntityLdpId##MplsLdpIdentifier = {index}######mplsLdpEntityIndex##IndexInteger = {index}######mplsLdpEntityLdpId##MplsLdpIdentifier######mplsLdpEntityIndex##IndexInteger######mplsLdpEntityProtocolVersion##Unsigned32######mplsLdpEntityAdminStatus##Enumeration######mplsLdpEntityOperStatus##Enumeration######mplsLdpEntityTcpDscPort##InetPortNumber#<= dia:attribute = name=3D"value">#####mplsLdpEntityUdpDscPort##InetPortNumber#<= dia:attribute = name=3D"value">#####mplsLdpEntityMaxPduLength##Unsigned32######mplsLdpEntityKeepAliveHoldTimer#= #Unsigned32######mplsLdpEntityHelloHoldTimer##Unsigned32######mplsLdpEntityInitSessionThreshold##Integer32######mplsLdpEntityLabelDistMethod##MplsLabelDistributionMethod######mplsLdpEntityLabelRetentionMode#= #MplsRetentionMode######mplsLdpEntityPathVectorLimit##Integer32######mplsLdpEntityHopCountLimit##Integer32######mplsLdpEntityTransportAddrKind#<= /dia:attribute>#Enumeration######mplsLdpEntityTargetPeer##TruthValue######mplsLdpEntityTargetPeerAddrType#= #InetAddressType#= #####mplsLdpEntityTargetPeerAddr##InetAddress######mplsLdpEntityLabelType##MplsLdpLabelType######mplsLdpEntityDiscontinuityTime#<= /dia:attribute>#TimeStamp######mplsLdpEntityStorageType##StorageType######mplsLdpEntityRowStatus##RowStatus######mplsLdpEntityStatsEntry##smi mib = class####mplsLdpEntityLdpId##MplsLdpIdentifier = {index}######mplsLdpEntityIndex##IndexInteger = {index}######mplsLdpEntityStatsSessionAttempts##Counter32######mplsLdpEntityStatsSessionRejectedNoHelloError= s##Counter32######mplsLdpEntityStatsSessionRejectedAdErrors##Counter32######mplsLdpEntityStatsSessionRejectedMaxPduErrors= ##Counter32######mplsLdpEntityStatsSessionRejectedLRErrors##Counter32######mplsLdpEntityStatsBadLdpIdentifierErrors##Counter32######mplsLdpEntityStatsBadPduLengthErrors##Counter32######mplsLdpEntityStatsBadMessageLengthErrors##Counter32######mplsLdpEntityStatsBadTlvLengthErrors##Counter32######mplsLdpEntityStatsMalformedTlvValueErrors##Counter32######mplsLdpEntityStatsKeepAliveTimerExpErrors##Counter32######mplsLdpEntityStatsShutdownReceivedNotificatio= ns##Counter32######mplsLdpEntityStatsShutdownSentNotifications#<= /dia:string>#Counter32######augments####1####1##mplsLdpPeerEntry##smi mib = class####mplsLdpEntityLdpId##MplsLdpIdentifier = {index}######mplsLdpEntityIndex##IndexInteger = {index}######mplsLdpPeerLdpId##MplsLdpIdentifier = {index}######mplsLdpPeerLdpId##MplsLdpIdentifier######mplsLdpPeerLabelDistMethod##MplsLabelDistributionMethod######mplsLdpPeerPathVectorLimit##Integer32######mplsLdpPeerTransportAddrType##InetAddressType#= #####mplsLdpPeerTransportAddr##InetAddress######expands####1####*##mplsFecEntry##smi mib = class####mplsFecIndex##IndexInteger = {index}######mplsFecIndex##IndexInteger######mplsFecType##Enumeration######mplsFecAddrPrefixLength##InetAddressPrefixLength######mplsFecAddrType#= #InetAddressType#= #####mplsFecAddr##InetAddress######mplsFecStorageType##StorageType######mplsFecR= owStatus##RowStatus########## = #### = ##mplsLdpHelloAdjacencyEntry##smi mib = class####mplsLdpEntityLdpId##MplsLdpIdentifier = {index}######mplsLdpEntityIndex##IndexInteger = {index}######mplsLdpPeerLdpId##MplsLdpIdentifier = {index}######mplsLdpHelloAdjacencyIndex##Unsigned32 = {index}######mplsLdpHelloAdjacencyIndex##Unsigned32######mplsLdpHelloAdjacencyHoldTimeRem##TimeInterval######mplsLdpHelloAdjacencyHoldTime##Unsigned32######mplsLdpHelloAdjacencyType##Enumeration########## = #### = ##mplsInSegmentLdpLspEntry##smi mib = class####mplsLdpEntityLdpId##MplsLdpIdentifier = {index}######mplsLdpEntityIndex##IndexInteger = {index}######mplsLdpPeerLdpId##MplsLdpIdentifier = {index}######mplsInSegmentLdpLspIndex##MplsIndexType = {index}######mplsInSegmentLdpLspIndex##MplsIndexType###<= dia:attribute = name=3D"comment">###mplsInSegmentLdpLspLabelType##MplsLdpLabelType######mplsInSegmentLdpLspType##MplsLspType########## = #### = ##mplsOutSegmentLdpLspEntry##smi mib = class####mplsLdpEntityLdpId##MplsLdpIdentifier = {index}######mplsLdpEntityIndex##IndexInteger = {index}######mplsLdpPeerLdpId##MplsLdpIdentifier = {index}######mplsOutSegmentLdpLspIndex##MplsIndexType = {index}######mplsOutSegmentLdpLspIndex##MplsIndexType######mplsOutSegmentLdpLspLabelType##MplsLdpLabelType######mplsOutSegmentLdpLspType##MplsLspType########## = #### = ##mplsLdpLspFecEntry##smi mib = class####mplsLdpEntityLdpId##MplsLdpIdentifier = {index}######mplsLdpEntityIndex##IndexInteger = {index}######mplsLdpPeerLdpId##MplsLdpIdentifier = {index}######mplsLdpLspFecSegment##Enumeration = {index}######mplsLdpLspFecSegmentIndex##MplsIndexType = {index}######mplsLdpLspFecIndex##IndexInteger = {index}######mplsLdpLspFecSegment##Enumeration######mplsLdpLspFecSegmentIndex##MplsIndexType######mplsLdpLspFecIndex##IndexInteger######mplsLdpLspFecStorageType##StorageType######mplsLdpLspFecRowStatus##RowStatus########## = #### = ##mplsLdpSessionPeerAddrEntry##smi mib = class###= #mplsLdpEntityLdpId##MplsLdpIdentifier = {index}######mplsLdpEntityIndex##IndexInteger = {index}######mplsLdpPeerLdpId##MplsLdpIdentifier = {index}######mplsLdpSessionPeerAddrIndex##Unsigned32 = {index}######mplsLdpSessionPeerAddrIndex##Unsigned32######mplsLdpSessionPeerNextHopAddrType##InetAddressType#= #####mplsLdpSessionPeerNextHopAddr##InetAddress########## = #### = ###### = #### = ##mplsLdpSessionEntry##smi mib = class####mplsLdpEntityLdpId##MplsLdpIdentifier = {index}######mplsLdpEntityIndex##IndexInteger = {index}######mplsLdpPeerLdpId##MplsLdpIdentifier = {index}######mplsLdpSessionStateLastChange##TimeStamp######mplsLdpSessionState##Enumeration######mplsLdpSessionRole##Enumeration######mplsLdpSessionProtocolVersion##Unsigned32######mplsLdpSessionKeepAliveHoldTimeRem##TimeInterval######mplsLdpSessionKeepAliveTime##Unsigned32######mplsLdpSessionMaxPduLength##Unsigned32######mplsLdpSessionDiscontinuityTime#= #TimeStamp######augments####1####1##mplsLdpSessionStatsEntry##smi mib = class####mplsLdpEntityLdpId##MplsLdpIdentifier = {index}######mplsLdpEntityIndex##IndexInteger = {index}######mplsLdpPeerLdpId##MplsLdpIdentifier = {index}######mplsLdpSessionStatsUnknownMesTypeErrors##Counter32######mplsLdpSessionStatsUnknownTlvErrors##Counter32######augments####1####1##expands####1####*##expands####1####*##expands####1####*######expands####1####*#=0A= ------_=_NextPart_000_01C353C6.EEB2D716-- Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6O9irKH016753; Thu, 24 Jul 2003 11:44:53 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 922361ADF2; Thu, 24 Jul 2003 11:44:53 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id EB3D2BEA; Thu, 24 Jul 2003 11:44:52 +0200 (CEST) Received: by james (Postfix, from userid 1000) id CBAEC840B; Thu, 24 Jul 2003 11:44:52 +0200 (CEST) Date: Thu, 24 Jul 2003 11:44:52 +0200 From: Juergen Schoenwaelder To: Frank Strauss Cc: Marcus Brunner , nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] web page for uml diagrams Message-ID: <20030724094452.GC1515@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strauss , Marcus Brunner , nmrg@ibr.cs.tu-bs.de References: <20030723104116.GB1015@iu-bremen.de> <23434627.1058978590@[10.1.1.130]> <24299580.1058979455@[10.1.1.130]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: On Wed, Jul 23, 2003 at 06:11:34PM +0200, Frank Strauss wrote: > > Thanks. Here is a short description of what I did to check the modules, > to "repair" them so that they could be further processed, and to generate > a diagram. Maybe this helps others to do similar things... > [...] Thanks Frank. I noticed that the current smidump has a bug which causes index elements to appear twice in the UML classes. This needs to be fixed and I am sure that I am responsible for introducing this bug. So if someone revised the diagrams, you may want to pay attention to this. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NL0G3T004628 for ; Wed, 23 Jul 2003 23:00:16 +0200 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6NL0NP07728 for ; Wed, 23 Jul 2003 16:00:24 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 23:00:11 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213B673@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] web page for uml diagrams Date: Wed, 23 Jul 2003 23:00:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-IBRFilter-SpamReport: -3.3 () QUOTED_EMAIL_TEXT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I now have a test ops web page that points to the Info model page below. http://www.ops.ietf.org/index1.html It also has new ptrs to common TCs and MIB review tools Comments are welcome. Bert > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: woensdag 23 juli 2003 12:41 > To: nmrg@ibr.cs.tu-bs.de > Subject: [nmrg] web page for uml diagrams > > > I have created a web page where we can collect UML diagrams for the > information models behind IETF MIBs. Please take a look at: > > http://www.ibr.cs.tu-bs.de/projects/nmrg/infomodel/ > > It would be nice to get Sharon's diagrams in here as well and it would > be really cool if we could agree on a common UML editor so > that changes > can be done easily. I have made good experience with the "dia" editor > which is supposed to run on Unix and Win32 platforms: > > http://www.lysator.liu.se/~alla/dia/ > > If we can agree on this tool, we could also make the .dia sources > available so that more people can get involved in updating diagrams > and creating new ones. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > -- > !! 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. > Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NKg43T001313 for ; Wed, 23 Jul 2003 22:42:04 +0200 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2003 13:48:39 -0700 Received: from rtp-cse-133.cisco.com (rtp-cse-133.cisco.com [64.102.51.73]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6NKg1Ai021874; Wed, 23 Jul 2003 16:42:01 -0400 (EDT) Received: from localhost (chelliot@localhost) by rtp-cse-133.cisco.com (8.11.7+Sun/8.11.6) with ESMTP id h6NKg0g16220; Wed, 23 Jul 2003 16:42:01 -0400 (EDT) Date: Wed, 23 Jul 2003 16:42:00 -0400 (EDT) From: Chris Elliott To: Juergen Schoenwaelder cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] my meeting notes In-Reply-To: <20030723091342.GA792@iu-bremen.de> Message-ID: References: <20030723091342.GA792@iu-bremen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IBRFilter-SpamReport: -32.2 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen, I have Harrington's notes, as well as mine, of course. I'll merge your's in also and try to get them out real soon now. Chris. On Wed, 23 Jul 2003, Juergen Schoenwaelder wrote: > Attached are my few notes that I took during the meeting, basically > the list of things we collected on measurements. Might be good to > merge this into the meeting minutes. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > Chris Elliott CCIE# 2013 | | Customer Diagnostic Engineer ||| ||| RTP, NC, USA ||||| ||||| 919-392-2146 .:|||||||||:|||||||||:. chelliot@cisco.com c i s c o S y s t e m s Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NGBY3U018303 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Jul 2003 18:11:34 +0200 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NGBYSk018570; Wed, 23 Jul 2003 18:11:34 +0200 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h6NGBYAE018567; Wed, 23 Jul 2003 18:11:34 +0200 From: Frank Strauss To: Marcus Brunner Cc: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] web page for uml diagrams References: <20030723104116.GB1015@iu-bremen.de> <23434627.1058978590@[10.1.1.130]> <24299580.1058979455@[10.1.1.130]> Date: 23 Jul 2003 18:11:34 +0200 In-Reply-To: <24299580.1058979455@[10.1.1.130]> Message-ID: Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -26.2 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-25.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi! Marcus> I tried to do it for the MPLS MIBs, but I miserably failed even Marcus> parsing the MIBs in the latest drafts. But it might be myself not Marcus> using the tools correctly. >> Could you please point me (us) to the MIBs (or the I-Ds) you've fed >> to smidump? There are 36 documents in internet-drafts/*mpls*mib*, and >> I don't want to check all of them. :-)) Marcus> draft-ietf-mpls-ftn-mib-07.txt Marcus> draft-ietf-mpls-ldp-mib-12.txt Marcus> draft-ietf-mpls-lsr-mib-11.txt Marcus> draft-ietf-mpls-tc-mib-08.txt Marcus> draft-ietf-mpls-te-mib-11.txt Thanks. Here is a short description of what I did to check the modules, to "repair" them so that they could be further processed, and to generate a diagram. Maybe this helps others to do similar things... 1. Get the documents. 2. Extract the modules using smistrip. (The latest version from CVS of smistrip now also accepts .gz files and is able to read documents from a given directory): smistrip -i /ftp/docs/internet-drafts \ draft-ietf-mpls-ftn-mib-07.txt \ draft-ietf-mpls-ldp-mib-12.txt \ draft-ietf-mpls-lsr-mib-11.txt \ draft-ietf-mpls-tc-mib-08.txt \ draft-ietf-mpls-te-mib-11.txt Note that documents that are formatted in an "unexpected" form, may lead to warnings or even broken MIB modules, because smistrip has to make some vague assumptions on how to cut off page footers and headers. 3. Check the extracted modules with smilint. If not otherwise set, the local directory might have to be added to the paths in which smilint will search for modules. SMIPATH=.: smilint -i namelength-32 MPLS-* In this case I wanted to ignore all warnings about identifiers that are longer than 32 chars. The errors that remain complain about "XXX" placeholders for a number of registrations. 4. Fix errors, if required. In this case nothing has to be done to produce the dia diagrams. 5. Use smidump to generate whatever I want, e.g. metrics, trees, diagrams: SMIPATH=.: smidump -u -f metrics MPLS-* | less SMIPATH=.: smidump -u -f tree MPLS-* | less SMIPATH=.: smidump -u -f cm MPLS-* > mpls-model.dia The -u option is used to get a "united" representation of all input modules, instead of separated outputs per module. 6. Use dia to drag items around to get a better layout and finally print the diagram to a PDF file. I have not yet done this. It seems to be quite some work in this case. :-) The non-beautified diagram is at http://www.ibr.cs.tu-bs.de/users/strauss/mpls-model.dia. -frank Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NFeS3T012461; Wed, 23 Jul 2003 17:40:28 +0200 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6NFeZP16741; Wed, 23 Jul 2003 10:40:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 17:40:22 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213B637@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Marcus Brunner , Frank Strauss Cc: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] web page for uml diagrams Date: Wed, 23 Jul 2003 17:40:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-IBRFilter-SpamReport: -3.3 () QUOTED_EMAIL_TEXT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Plus draft-ietf-mpls-telink-mib-02.txt Thanks, Bert > -----Original Message----- > From: Marcus Brunner [mailto:brunner@ccrle.nec.de] > Sent: woensdag 23 juli 2003 16:58 > To: Frank Strauss > Cc: j.schoenwaelder@iu-bremen.de; nmrg@ibr.cs.tu-bs.de > Subject: Re: [nmrg] web page for uml diagrams > > > draft-ietf-mpls-ftn-mib-07.txt > draft-ietf-mpls-ldp-mib-12.txt > draft-ietf-mpls-lsr-mib-11.txt > draft-ietf-mpls-tc-mib-08.txt > draft-ietf-mpls-te-mib-11.txt > > MArcus > > --On Mittwoch, 23. Juli 2003 16:53 +0200 Frank Strauss > wrote: > > > Hi! > > > > Marcus> I tried to do it for the MPLS MIBs, but I miserably > failed even > > Marcus> parsing the MIBs in the latest drafts. But it might > be myself not > > Marcus> using the tools correctly. > > > > Could you please point me (us) to the MIBs (or the I-Ds) you've fed > > to smidump? There are 36 documents in > internet-drafts/*mpls*mib*, and > > I don't want to check all of them. :-)) > > > > -frank > > > > -------------------------------------- > Dr. Marcus Brunner > Network Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > WWW: http://www.ccrle.nec.de/ > Phone: +49 (0) 6221 905 11 29 > Mobile: +49 (0) 163 275 17 43 > personal home page: http://www.brubers.org/marcus > > > > > -- > !! 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. > Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NEvZ3T003211; Wed, 23 Jul 2003 16:57:35 +0200 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6NEvZVI005328; Wed, 23 Jul 2003 16:57:35 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1653485B02; Wed, 23 Jul 2003 16:37:41 +0200 (CEST) Date: Wed, 23 Jul 2003 16:57:35 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: Frank Strauss Cc: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] web page for uml diagrams Message-ID: <24299580.1058979455@[10.1.1.130]> In-Reply-To: References: <20030723104116.GB1015@iu-bremen.de> <23434627.1058978590@[10.1.1.130]> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IBRFilter-SpamReport: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-19.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: draft-ietf-mpls-ftn-mib-07.txt draft-ietf-mpls-ldp-mib-12.txt draft-ietf-mpls-lsr-mib-11.txt draft-ietf-mpls-tc-mib-08.txt draft-ietf-mpls-te-mib-11.txt MArcus --On Mittwoch, 23. Juli 2003 16:53 +0200 Frank Strauss wrote: > Hi! > > Marcus> I tried to do it for the MPLS MIBs, but I miserably failed even > Marcus> parsing the MIBs in the latest drafts. But it might be myself not > Marcus> using the tools correctly. > > Could you please point me (us) to the MIBs (or the I-Ds) you've fed > to smidump? There are 36 documents in internet-drafts/*mpls*mib*, and > I don't want to check all of them. :-)) > > -frank -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NEr33U002175 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Jul 2003 16:53:03 +0200 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NEr3Sk022753; Wed, 23 Jul 2003 16:53:03 +0200 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h6NEr3r6022750; Wed, 23 Jul 2003 16:53:03 +0200 From: Frank Strauss To: Marcus Brunner Cc: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] web page for uml diagrams References: <20030723104116.GB1015@iu-bremen.de> <23434627.1058978590@[10.1.1.130]> Date: 23 Jul 2003 16:53:03 +0200 In-Reply-To: <23434627.1058978590@[10.1.1.130]> Message-ID: Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -16.3 () IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-16.2 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi! Marcus> I tried to do it for the MPLS MIBs, but I miserably failed even Marcus> parsing the MIBs in the latest drafts. But it might be myself not Marcus> using the tools correctly. Could you please point me (us) to the MIBs (or the I-Ds) you've fed to smidump? There are 36 documents in internet-drafts/*mpls*mib*, and I don't want to check all of them. :-)) -frank Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NEhC3T032497 for ; Wed, 23 Jul 2003 16:43:12 +0200 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h6NEhAVI003946; Wed, 23 Jul 2003 16:43:10 +0200 (CEST) Received: from [10.1.1.130] (brunner.office [10.1.1.130]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 66BCC2B937; Wed, 23 Jul 2003 16:23:16 +0200 (CEST) Date: Wed, 23 Jul 2003 16:43:10 +0200 From: Marcus Brunner Reply-To: Marcus Brunner To: j.schoenwaelder@iu-bremen.de Cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] web page for uml diagrams Message-ID: <23434627.1058978590@[10.1.1.130]> In-Reply-To: <20030723104116.GB1015@iu-bremen.de> References: <20030723104116.GB1015@iu-bremen.de> X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IBRFilter-SpamReport: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-19.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Great. I tried to do it for the MPLS MIBs, but I miserably failed even parsing the MIBs in the latest drafts. But it might be myself not using the tools correctly. Marcus --On Mittwoch, 23. Juli 2003 12:41 +0200 Juergen Schoenwaelder wrote: > I have created a web page where we can collect UML diagrams for the > information models behind IETF MIBs. Please take a look at: > > http://www.ibr.cs.tu-bs.de/projects/nmrg/infomodel/ > > It would be nice to get Sharon's diagrams in here as well and it would > be really cool if we could agree on a common UML editor so that changes > can be done easily. I have made good experience with the "dia" editor > which is supposed to run on Unix and Win32 platforms: > > http://www.lysator.liu.se/~alla/dia/ > > If we can agree on this tool, we could also make the .dia sources > available so that more people can get involved in updating diagrams > and creating new ones. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, > Germany -- > !! 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. -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ Phone: +49 (0) 6221 905 11 29 Mobile: +49 (0) 163 275 17 43 personal home page: http://www.brubers.org/marcus Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6NAfK3T017798 for ; Wed, 23 Jul 2003 12:41:20 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 108FB1ADF0; Wed, 23 Jul 2003 12:41:17 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id 67C301ADA7; Wed, 23 Jul 2003 12:41:16 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 6116D840B; Wed, 23 Jul 2003 12:41:16 +0200 (CEST) Date: Wed, 23 Jul 2003 12:41:16 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20030723104116.GB1015@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.4 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] web page for uml diagrams 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I have created a web page where we can collect UML diagrams for the information models behind IETF MIBs. Please take a look at: http://www.ibr.cs.tu-bs.de/projects/nmrg/infomodel/ It would be nice to get Sharon's diagrams in here as well and it would be really cool if we could agree on a common UML editor so that changes can be done easily. I have made good experience with the "dia" editor which is supposed to run on Unix and Win32 platforms: http://www.lysator.liu.se/~alla/dia/ If we can agree on this tool, we could also make the .dia sources available so that more people can get involved in updating diagrams and creating new ones. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6N9Dh3T031721 for ; Wed, 23 Jul 2003 11:13:43 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 3DCD11ADF1; Wed, 23 Jul 2003 11:13:43 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id 8F2B41A989; Wed, 23 Jul 2003 11:13:42 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 7FA49840B; Wed, 23 Jul 2003 11:13:42 +0200 (CEST) Date: Wed, 23 Jul 2003 11:13:42 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20030723091342.GA792@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.4 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] my meeting notes 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached are my few notes that I took during the meeting, basically the list of things we collected on measurements. Might be good to merge this into the meeting minutes. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nmrg.txt" 13th NMRG Meeting in Vienna (Austria), 18-19 July 2003 The meeting is hosted by the Forschungszentrum Telekommunikation Wien (FTW) . Agenda: * Friday (July 18, 13:00-17:00): + Administrivia and Status Reports (Juergen Schoenwaelder) - Welcome and thanks to the FTW - Note takers and minute makers dbh and chris (minutes) - IETF news from the AD + Feedback on IAB Research Funding Document (Juergen Schoenwaelder) + SMIng Status and Remaining Issues (Frank Strauss) + MIB Module Metrics (Juergen Schoenwaelder) * Saturday (July 19, 9:00-12:00, 13:00-17:00): + IETF Information Model (Sharon Chisholm) Action Points: * Develop test methodology for measurements of different management protocols and transports and the implications on systems More concrete, what needs to be done: 1) Scope: configuration 2) Questions: - Which code bases are available on different operating environments? - Number of (interoperable) tools available? - How easy is X to install on IOS, Junos, BSD, Linux, ...? (Lengthy discussion whether data from non Unix environments is needed or not. Concensus that some data is better than no data at all.) - How much do transports influence SOAP? - How much do multiple sessions influence performance? - How much does (software) encryption influence performance? 3) Metrics: - Static memory footprint - Dynamic memory footprint - CPU usage - Latency (on the device) - Bandwidth efficiency 4) Test cases: - Test #1: Only focus on the transport and ignore any further processing (no xml parsing of data transferred) - Test #2: Compare transport costs to xml data parsing costs (potentially using different parsing approaches such as dom, sax, ...) - Test #3: Test how the size of the data portion influences the performance. --XsQoSWH+UP9D9v3l-- Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6MFtE3T013640 for ; Tue, 22 Jul 2003 17:55:14 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id DEE281ADDF; Tue, 22 Jul 2003 17:55:13 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id 40FEA2E87; Tue, 22 Jul 2003 17:55:13 +0200 (CEST) Received: by james (Postfix, from userid 1000) id AE9F58507; Tue, 22 Jul 2003 17:55:12 +0200 (CEST) Date: Tue, 22 Jul 2003 17:55:12 +0200 From: Juergen Schoenwaelder To: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] network management research funding text Message-ID: <20030722155512.GA1347@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de References: <20030708093936.GA1287@iu-bremen.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <20030708093936.GA1287@iu-bremen.de> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -16.3 () IN_REP_TO,REFERENCES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-16.3 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached is the revised text for section 3.5 of the IAB research funding draft which includes the changes made during the 13th NMRG meeting in Vienna. This is the last call to submit your input. If I do not receive any additional comments by August 10th, I consider this version to be in concens with the NMRG views. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-iab-research-funding-01.txt" 3.5. Network Management The Internet had early success in network device monitoring with the Simple Network Management Protocol (SNMP) and its associated Management Information Base (MIB). There has been comparatively less success in managing networks, in contrast to the monitoring of individual devices. Furthermore, there are a number of operator requirements not well supported by the current Internet management framework. An enhanced network management architecture that more fully supports real operational network management needs is desirable. Unfortunately, network management research has historically been very underfunded. Operators have complained that existing solutions are inadequate. Research needs to be done to better understand how to address the issues. 3.5.1. Managing Networks, Not Devices At present, there are few or no good tools for managing a whole network instead of isolated devices. Current network management protocols such as SNMP are fine for reading status of well-defined objects from individual devices. But managing networks instead of isolated devices requires the ability to view the network as a large distributed system. Research is needed on scalable distributed data aggregation mechanisms, scalable distributed event correlation algorithms, and distributed and dependable control mechanisms. Applied research into methods of managing sets of networked devices seems worthwhile. Ideally such a management approach would support distributed management, rather than being strictly centralized. The lack of appropriate network management tools has been cited as one of the major barriers to the deployment of IP multicast [Diot00, SP03]. This in particular impacts multimedia (voice and video) IP networks that rely on multicast services and research would be useful in this area. 3.5.2. Autonomous Network Management Current approaches to network management do not scale sufficiently, so network operators often have difficulties operating their network(s) as successfully and economically as desired. Hence, more work is needed to improve the automation achieved by network management systems and to localize management. This might involve application of control theory, artificial intelligence, expert systems technology, or other mechanisms. 3.5.3. Configuration Management Operators at the IAB Network Management Workshop [RFC-3535] held in 2002 reported that scalable distributed configuration management for sets of network devices is a significant challenge today. In particular, it is desirable to execute configuration transactions across a number of connected devices, which requires protocols that support distributed transactions. Furthermore, configuration data should be represented in a way which simplifies the processing and generation of configurations with standard tools. Even individual improvements in configuration management for sets of networked devices are very welcome. Such improvements need to include an integrated approach to security for the configuration data. 3.5.4. Enhanced Monitoring Capabilities SNMP does not scale very well to monitoring large numbers of objects in many devices in different parts of the network. Some implementations also show inaccuracies (especially when monitoring on shorter time scales) or they lack support for the objects that operators are interested in. An alternative approach worth exploring is how to provide scalable and distributed monitoring, not on individual devices, but instead on groups of devices and networks-as-a-whole. This requires adequate and scalable data aggregation techniques. 3.5.5. Customer Network Management An open issue related to network management is helping users and others to identify and resolve problems in the network. If a user can't access a web page, it would be useful if the user could find out, easily, without having to run low-level diagnostic tools (ping and traceroute), whether the problem was that the web server was down, that the network was partitioned due to a link failure, that there was heavy congestion along the path, that the DNS name couldn't be resolved, that the firewall prohibited the access, or something else. Applied research is needed to understand how to translate data that exists in a network or a network management system into terms understandable by customers. This also requires to be able to determine which customers are affected and how the business is affected if something breaks. Of course, customer network management mechanisms must not reveal any confidential details. 3.5.6 Analysis of Current Management Protocol Usage In the past, much work has been spent on the specification and implementation of the current Internet network management architecture. However, operators reported that they use only a subset of this architecture. A better understanding of what is used for which purpose (and what is not used) is highly desirable. One way to research this issue is by automated network management protocol traffic measurements and subsequent analysis in close cooperation with operators. --W/nzBZO5zC0uMSeA-- Received: from wanderer.hardakers.net (adsl-66-127-127-227.dsl.scrm01.pacbell.net [66.127.127.227]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6LDFF3T004712 for ; Mon, 21 Jul 2003 15:15:16 +0200 Received: by wanderer.hardakers.net (Postfix, from userid 274) id A15E35729E; Fri, 18 Jul 2003 18:50:23 -0700 (PDT) To: nmrg@ibr.cs.tu-bs.de From: Wes Hardaker 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 Organization: Sparta Date: Fri, 18 Jul 2003 18:50:23 -0700 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -6.4 () USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.3 required=5.0 tests=USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] ipsec alg speeds 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Here's the ipsec speeds that at leas Chris was interested in: As implemented in software via the NIST ipsec stack running on linux as a percentage of full speed (IE, No encryption/No Authentication = 100). Authentication None HMAC-MD5-96 HMAC-SHA-96 Encryption None 100 76 65 DES/CBC 51 47 43 3DES/CBC 34 32 30 AES/128 47 44 38 IDEA/CBC 50 45 41 RC5/CBC 62 53 49 Blowfish/CBC 51 47 42 (note: the smallest is 3des and sha only gets 30% of the original transmission speed) -- Wes Hardaker Sparta Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6J8KJRH004111 for ; Sat, 19 Jul 2003 10:20:20 +0200 Received: from ala-mrwtemp.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id BAA23338 for ; Sat, 19 Jul 2003 01:20:04 -0700 (PDT) Message-Id: <5.1.0.14.2.20030719041752.029446a8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 19 Jul 2003 04:19:23 -0400 To: nmrg@ibr.cs.tu-bs.de From: Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Where are you? 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi All, I went over to the Tech Gate Vienna this morning, but I didn't find any people or any way to get into the building. I'm back at my hotel now. If you get this message, please let me know where to go. Thanks, Margaret Received: from ibr.cs.tu-bs.de ([81.160.215.56]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HG6qRI018938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 17 Jul 2003 18:06:53 +0200 Message-ID: <3F16C98B.9040506@ibr.cs.tu-bs.de> Date: Thu, 17 Jul 2003 18:06:35 +0200 From: =?ISO-8859-1?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig, Germany User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: NMRG Subject: Re: [nmrg] remaining issues on sming snmp mapping and modules documents References: <20030701091544.GB1015@iu-bremen.de> <3F1407BF.9040102@ibr.cs.tu-bs.de> <3F16BA95.70601@ibr.cs.tu-bs.de> <20030717155115.GA987@iu-bremen.de> In-Reply-To: <20030717155115.GA987@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: -32.2 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen Schoenwaelder wrote: >>S> f) The fact that the scalars' implements statement assigns >>S> sub-identifier starting at 1 causes problems with existing scalar >>S> groups that have all sort of numbering gaps. I guess it is needed >>S> to be able to override it. >> >>>[Of course, this also applies to the table's implements statement.] >> >>From my perspective this is the only issue that currently remains open >>(besides the TimeTicks32/64 change). > > Did you not say that you agree that adding a statement block would be > the right solution? I just meant to say that I don't have a concrete proposal for the change. Received: from james ([81.160.180.141]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HFpFRH016120; Thu, 17 Jul 2003 17:51:15 +0200 Received: by james (Postfix, from userid 1000) id 76DBD84BA; Thu, 17 Jul 2003 17:51:15 +0200 (CEST) Date: Thu, 17 Jul 2003 17:51:15 +0200 From: Juergen Schoenwaelder To: Frank Strau? Cc: NMRG Subject: Re: [nmrg] remaining issues on sming snmp mapping and modules documents Message-ID: <20030717155115.GA987@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strau? , NMRG References: <20030701091544.GB1015@iu-bremen.de> <3F1407BF.9040102@ibr.cs.tu-bs.de> <3F16BA95.70601@ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F16BA95.70601@ibr.cs.tu-bs.de> User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: On Thu, Jul 17, 2003 at 05:02:45PM +0200, Frank Strau? wrote: > Some further comments on the "snmp" (S) and "modules" (M) documents... > > S> a) There is no section on revising SNMP mapping definitions. Not sure > S> why we overlooked that until now. > > I think working on this is really out of focus at this point and it > would bring up a lot of yet untouched questions. I can live with this position. > S> b) [...] we [probably should] change TimeTicks to TimeTicks32, > S> [then] we [would] have to update this document as well. > > M> f) While thinking about the TimeTicks and TimeStamp objects, I was > M> wondering whether we should rename them to TimeTicks32 and > M> TimeStamp32 and in addition introduce TimeTicks64 and TimeStamp64 > M> so that MIB authors can choose a timer which does not roll-over > M> every 497+ days. > > Should be straightforward to change and bring some more alignment > with other types. Would be fine with me. OK > S> d) The description of the node statement should probably say something > S> regarding the Pointer type. > > It already says "This may be useful to [...] uniquely define an SMIng > `identity? to be referenced in attributes of type Pointer. And the > subsection on "implements" says a bit more. I would regard this as > adequately specified. Do you have any better proposal? OK, I can accept that. > S> f) The fact that the scalars' implements statement assigns > S> sub-identifier starting at 1 causes problems with existing scalar > S> groups that have all sort of numbering gaps. I guess it is needed > S> to be able to override it. > > > >[Of course, this also applies to the table's implements statement.] > > From my perspective this is the only issue that currently remains open > (besides the TimeTicks32/64 change). Did you not say that you agree that adding a statement block would be the right solution? > S> k) Perhaps the NMRG-SMING-SNMP-EXT module should be renamed to > S> NMRG-SMING-EXT-SNMP so that all SMIng language extension are > S> grouped together and to reduce confusion by module authors (at > S> least I got sometimes confused). > > Many SMIv2 modules also use suffixes to differenciate classes of modules > (-MIB, -TC). I think we should stick with this scheme. While I believe that -TC was not really a good idea, I can live with the module name. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from ibr.cs.tu-bs.de ([81.160.215.56]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HF32RI006800 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 17 Jul 2003 17:03:02 +0200 Message-ID: <3F16BA95.70601@ibr.cs.tu-bs.de> Date: Thu, 17 Jul 2003 17:02:45 +0200 From: =?ISO-8859-1?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig, Germany User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: NMRG References: <20030701091544.GB1015@iu-bremen.de> <3F1407BF.9040102@ibr.cs.tu-bs.de> In-Reply-To: <3F1407BF.9040102@ibr.cs.tu-bs.de> X-Enigmail-Version: 0.80.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-IBRFilter-SpamReport: -25.6 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-25.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] remaining issues on sming snmp mapping and modules documents 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Some further comments on the "snmp" (S) and "modules" (M) documents... S> a) There is no section on revising SNMP mapping definitions. Not sure S> why we overlooked that until now. I think working on this is really out of focus at this point and it would bring up a lot of yet untouched questions. S> b) [...] we [probably should] change TimeTicks to TimeTicks32, S> [then] we [would] have to update this document as well. M> f) While thinking about the TimeTicks and TimeStamp objects, I was M> wondering whether we should rename them to TimeTicks32 and M> TimeStamp32 and in addition introduce TimeTicks64 and TimeStamp64 M> so that MIB authors can choose a timer which does not roll-over M> every 497+ days. Should be straightforward to change and bring some more alignment with other types. Would be fine with me. S> d) The description of the node statement should probably say something S> regarding the Pointer type. It already says "This may be useful to [...] uniquely define an SMIng `identity´ to be referenced in attributes of type Pointer. And the subsection on "implements" says a bit more. I would regard this as adequately specified. Do you have any better proposal? S> f) The fact that the scalars' implements statement assigns S> sub-identifier starting at 1 causes problems with existing scalar S> groups that have all sort of numbering gaps. I guess it is needed S> to be able to override it. > > [Of course, this also applies to the table's implements statement.] From my perspective this is the only issue that currently remains open (besides the TimeTicks32/64 change). S> k) Perhaps the NMRG-SMING-SNMP-EXT module should be renamed to S> NMRG-SMING-EXT-SNMP so that all SMIng language extension are S> grouped together and to reduce confusion by module authors (at S> least I got sometimes confused). Many SMIv2 modules also use suffixes to differenciate classes of modules (-MIB, -TC). I think we should stick with this scheme. Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6HARaRH018412; Thu, 17 Jul 2003 12:27:36 +0200 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id GAA16079; Thu, 17 Jul 2003 06:41:39 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma016064; Thu, 17 Jul 03 06:40:45 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2 with InterScan Messaging Security Suite; Thu, 17 Jul 2003 06:28:01 -0400 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 17 Jul 2003 06:28:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] upcoming meeting Date: Thu, 17 Jul 2003 06:27:21 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BAB8E06F@NHROCMBX1.ets.enterasys.com> Thread-Topic: [nmrg] upcoming meeting Thread-Index: AcNLWwNakqWU2i6WQGiOAnieGi1t0AA8tm6w From: "Harrington, David" To: "Ralph Droms" , "Juergen Schoenwaelder" Cc: "Network Management Research Group" X-OriginalArrivalTime: 17 Jul 2003 10:28:01.0318 (UTC) FILETIME=[195CD460:01C34C4E] X-IBRFilter-SpamReport: -3.3 () QUOTED_EMAIL_TEXT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id h6HARaRH018412 X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi, I plan to attend capwap, and Kevin Little (my guest at the nmrg meeting) will likely attend the dna meeting. dbh > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Tuesday, July 15, 2003 3:41 PM > To: Juergen Schoenwaelder > Cc: Network Management Research Group > Subject: Re: [nmrg] upcoming meeting > > > I would like to attend the dna meeting Fri AM. However, > if the nmrg is not rescheduled, I'll skip the dna meeting. > > - Ralph > > At 03:07 PM 7/15/2003 +0200, Juergen Schoenwaelder wrote: > > >I have updated the meeting web page to include the latest > >information. Looking at the IETF agenda, we have on Friday > >morning: > > > >Hall NO INT dna Detecting Network Attachment BOF > >Hall GH OPS capwap Control And Provisioning of Wireless Acc. > Points BOF > >Hall IK TSV tsvwg Transport Area Working Group * > > > >How many of the those who intent to participate in the NMRG meeting > >are planning to go to one of these meetings? I know that Markus will > >say something about SNMP in the capwap meeting. > > > >If more people are going there (or one of the other meetings > mentioned > >above), then we might want to start later with the NMRG meeting. > >Please let me know quickly what you think so that we can come to a > >decision when we start. > > > >[Note that the people hosting us asked that we arrive as a group > > rather than on an individual basis and we should plan accordingly.] > > > >/js > > > >-- > >Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 > Bremen, Germany > > > > > >-- > >!! 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. > > -- > !! 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. > Received: from ibr.cs.tu-bs.de ([81.160.165.183]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6GFG1RI003333 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 16 Jul 2003 17:16:02 +0200 Message-ID: <3F156C21.1060300@ibr.cs.tu-bs.de> Date: Wed, 16 Jul 2003 17:15:45 +0200 From: =?ISO-8859-1?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig, Germany User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: NMRG X-Enigmail-Version: 0.80.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: -5.8 () USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-5.8 required=5.0 tests=USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Updated SMIng Drafts 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I've just put the updated versions of the three documents on the NMRG web page. During the edits I noticed some minor things that I changed on the fly. I did not write a summary of these additional changes, but there are diffs on the web page, so that all changes can easily be identified. Received: from james ([81.160.180.141]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6GCsvRH005846 for ; Wed, 16 Jul 2003 14:54:57 +0200 Received: by james (Postfix, from userid 1000) id DF76A84BA; Wed, 16 Jul 2003 11:02:32 +0200 (CEST) Date: Wed, 16 Jul 2003 11:02:32 +0200 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20030716090232.GB1131@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.1 required=5.0 tests=DATE_IN_PAST_03_06,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] upcoming meeting rescheduled 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Based on the input I have received so far, I have decided the reschedule the upcoming meeting so that people can attend the Friday morning IETF sessions. The current plan is to meet after the IETF morning sessions at the message board around 11:30 and to have lunch together. We will then walk over to the FTW building at 13:00 to start the NMRG meeting. I have updated the web page accordingly. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from ibr.cs.tu-bs.de ([81.160.165.183]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6GCZJRI001177 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 16 Jul 2003 14:35:20 +0200 Message-ID: <3F154677.50403@ibr.cs.tu-bs.de> Date: Wed, 16 Jul 2003 14:35:03 +0200 From: =?ISO-8859-1?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig, Germany User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: NMRG Subject: Re: [nmrg] comments on sming modules document References: <20030701091426.GA1015@iu-bremen.de> In-Reply-To: <20030701091426.GA1015@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: -32.2 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I've integrated your proposed changes from your email and from your paper notes to the SMIng modules document. Here is just one slight additional comment and one remaining issue... Juergen Schoenwaelder wrote: > b) Add a copyright notice to the MIB module: Looking at some other documents, I noticed that they contain the sentence "All Rights Reserved.". Hence I added this as well (to all affected modules and documents): Copyright (C) The Internet Society (2003). All Rights Reserved. This version of this module is part of RFC XXXX, see the RFC itself for full legal notices."; > f) While thinking about the TimeTicks and TimeStamp objects, I was > wondering whether we should rename them to TimeTicks32 and > TimeStamp32 and in addition introduce TimeTicks64 and TimeStamp64 > so that MIB authors can choose a timer which does not roll-over > every 497+ days. Received: from james ([81.160.180.141]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FG4FRH002477; Tue, 15 Jul 2003 18:04:15 +0200 Received: by james (Postfix, from userid 1000) id 61DB084B9; Tue, 15 Jul 2003 18:04:15 +0200 (CEST) Date: Tue, 15 Jul 2003 18:04:15 +0200 From: Juergen Schoenwaelder To: Frank Strau? Cc: NMRG Subject: Re: [nmrg] commands on sming snmp mapping document Message-ID: <20030715160415.GA939@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strau? , NMRG References: <3F1407BF.9040102@ibr.cs.tu-bs.de> <20030715143315.GB757@iu-bremen.de> <3F141909.7060508@ibr.cs.tu-bs.de> <20030715153914.GA694@iu-bremen.de> <3F1424CC.5000908@ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1424CC.5000908@ibr.cs.tu-bs.de> User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: On Tue, Jul 15, 2003 at 05:59:08PM +0200, Frank Strau? wrote: > > >Yes and no. I believe the implicit numbering as it is now is kind > >of broken and I would prefer to fix this. But yes, we also need to > >draw a line somewhere. > > Ok. I agree that changing it to a small statement block that contains > something like a subid statement is the right thing. Do you have > something more concrete in mind or shall I make a proposal? Well, the question is whether to add also a status clause so that you can actually deprecate individual attribute level mappings. In other words, the implements status would actually be the status that would be used if one were to translate to the SMIv2. But we are now gradually moving from bug fix towards adding features - so I do not push for this. ;-) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from ibr.cs.tu-bs.de ([81.160.165.183]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FFxQRI000904 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 15 Jul 2003 17:59:26 +0200 Message-ID: <3F1424CC.5000908@ibr.cs.tu-bs.de> Date: Tue, 15 Jul 2003 17:59:08 +0200 From: =?ISO-8859-1?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig, Germany User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: NMRG Subject: Re: [nmrg] commands on sming snmp mapping document References: <3F1407BF.9040102@ibr.cs.tu-bs.de> <20030715143315.GB757@iu-bremen.de> <3F141909.7060508@ibr.cs.tu-bs.de> <20030715153914.GA694@iu-bremen.de> In-Reply-To: <20030715153914.GA694@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: -32.2 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen Schoenwaelder wrote: >>Well, I would not like it if this would be an SMING WG issue, but in >>the current situation I don't care that much. But I think we loose focus >>when we start changing things like this. I understand that our intention >>was just to freeze the documents to get published what was submitted by >>the NMRG to the failed SMING WG. > > Yes and no. I believe the implicit numbering as it is now is kind > of broken and I would prefer to fix this. But yes, we also need to > draw a line somewhere. Ok. I agree that changing it to a small statement block that contains something like a subid statement is the right thing. Do you have something more concrete in mind or shall I make a proposal? Received: from james ([81.160.180.141]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FFdERH029216; Tue, 15 Jul 2003 17:39:15 +0200 Received: by james (Postfix, from userid 1000) id 9E81C84B9; Tue, 15 Jul 2003 17:39:14 +0200 (CEST) Date: Tue, 15 Jul 2003 17:39:14 +0200 From: Juergen Schoenwaelder To: Frank Strau? Cc: NMRG Subject: Re: [nmrg] commands on sming snmp mapping document Message-ID: <20030715153914.GA694@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strau? , NMRG References: <3F1407BF.9040102@ibr.cs.tu-bs.de> <20030715143315.GB757@iu-bremen.de> <3F141909.7060508@ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F141909.7060508@ibr.cs.tu-bs.de> User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -33.4 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-33.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: On Tue, Jul 15, 2003 at 05:08:57PM +0200, Frank Strau? wrote: > My recent message was just meant to be an updated list of issues. > Hence, I have not yet comments on the left open issues. OK. So I will wait until Saturday and ask again. ;-) > > So we need to resolve this. I would prefer to make the implements > > statement actually more complex but consistent with the other statements > > by introducing a block which holds additional statements. I know you > > do not really like this... > > Well, I would not like it if this would be an SMING WG issue, but in > the current situation I don't care that much. But I think we loose focus > when we start changing things like this. I understand that our intention > was just to freeze the documents to get published what was submitted by > the NMRG to the failed SMING WG. Yes and no. I believe the implicit numbering as it is now is kind of broken and I would prefer to fix this. But yes, we also need to draw a line somewhere. > >>I changed it simply to "A null value used for pointers." Does > >>that make sense? > > > > Well, a no > > > > A node statement also defines constants for the ObjectIdentifier > > base type and zeroDotZero might be used as a NULL value. So I > > actually meant: > > > > "A value used as null value for object identifiers and pointers." > > > > Just refering to pointers is not telling the whole story I think. > > To me "a value used as null value" is just a "null value". :-) > Am I wrong? I agree that the short form is just fine. Lets go with it. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from ibr.cs.tu-bs.de ([81.160.165.183]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FFMlRI026424 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 15 Jul 2003 17:22:47 +0200 Message-ID: <3F141C37.1000108@ibr.cs.tu-bs.de> Date: Tue, 15 Jul 2003 17:22:31 +0200 From: =?ISO-8859-15?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig, Germany User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] network management research funding text References: <3F12952C.50003@ibr.cs.tu-bs.de> <20030715145250.GC757@iu-bremen.de> In-Reply-To: <20030715145250.GC757@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: -32.2 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen Schoenwaelder wrote: > What about this rewrite: > > 3.5.6 Analysis of Current Management Protocol Usage > > In the past, much work has been spent on the specification and > implementation of the current Internet network management > architecture. However, operators reported that they use only a > subset of this architecture. A better understanding of what is > used for which purpose (and what is not used) is highly desirable. > This issue can be addressed by automated network management > protocol traffic measurements and subsequent analysis in close > cooperation with operators. D'accord. Sounds better to me. Received: from ibr.cs.tu-bs.de ([81.160.165.183]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FF9DRI023161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 15 Jul 2003 17:09:13 +0200 Message-ID: <3F141909.7060508@ibr.cs.tu-bs.de> Date: Tue, 15 Jul 2003 17:08:57 +0200 From: =?ISO-8859-1?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig, Germany User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: NMRG Subject: Re: [nmrg] commands on sming snmp mapping document References: <3F1407BF.9040102@ibr.cs.tu-bs.de> <20030715143315.GB757@iu-bremen.de> In-Reply-To: <20030715143315.GB757@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: -15.7 () IN_REP_TO,REFERENCES,USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-15.7 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: My recent message was just meant to be an updated list of issues. Hence, I have not yet comments on the left open issues. >>>f) The fact that the scalars' implements statement assigns >>> sub-identifier starting at 1 causes problems with existing scalar >>> groups that have all sort of numbering gaps. I guess it is needed >>> to be able to override it. >> >>[Of course, this also applies to the table's implements statement.] > > So we need to resolve this. I would prefer to make the implements > statement actually more complex but consistent with the other statements > by introducing a block which holds additional statements. I know you > do not really like this... Well, I would not like it if this would be an SMING WG issue, but in the current situation I don't care that much. But I think we loose focus when we start changing things like this. I understand that our intention was just to freeze the documents to get published what was submitted by the NMRG to the failed SMING WG. >>>e) The description of zeroDotZero should probably be: >>> >>> "A value used as null value for identifiers and pointers." >> >>I changed it simply to "A null value used for pointers." Does >>that make sense? > > Well, a no > > A node statement also defines constants for the ObjectIdentifier > base type and zeroDotZero might be used as a NULL value. So I > actually meant: > > "A value used as null value for object identifiers and pointers." > > Just refering to pointers is not telling the whole story I think. To me "a value used as null value" is just a "null value". :-) Am I wrong? In (core) SMIng there are no object identifiers. This type is only meant for use in SNMP mappings while Pointers a core SMIng type. Hence I would suggest not to mix the use for object identifiers and for pointers. Alternatively we could express it yet a little more verbose. How about...? "A null value for pointers mapped to attributes of type ObjectIdentifier." :-) Received: from james ([81.160.180.141]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FEqoRH019846; Tue, 15 Jul 2003 16:52:50 +0200 Received: by james (Postfix, from userid 1000) id 5A3C084B9; Tue, 15 Jul 2003 16:52:50 +0200 (CEST) Date: Tue, 15 Jul 2003 16:52:50 +0200 From: Juergen Schoenwaelder To: Frank Strau? Cc: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] network management research funding text Message-ID: <20030715145250.GC757@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strau? , research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de References: <20030708093936.GA1287@iu-bremen.de> <3F0C72EF.50805@ibr.cs.tu-bs.de> <20030710083253.GC660@iu-bremen.de> <3F12952C.50003@ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <3F12952C.50003@ibr.cs.tu-bs.de> User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -33.4 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-33.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jul 14, 2003 at 01:34:04PM +0200, Frank Strau? wrote: > I agree that there are different intentions to be expressed by the > two sections (and by any of the other sections). Just reading the text > from a certain distance (like potential people that are addressed by > this document) lets me think that there are some common arguments. > The same is true for my initial comment on 3.5.4. Any concrete proposals for changes? > >3.5.4. Autonomous Network Management > > > > Current approaches to network management do not scale sufficiently, > > so network operators often have difficulty operating their > > ^ plural? fixed > > network(s) as successfully and economically as desired. Hence, > > more work is needed to improve the automation achieved by network > > management systems. This might involve application of control > > theory, artificial intelligence, expert systems technology, or > > other mechanisms, for example. > > Either "or other mechanisms" or "for example", not both, I suggest. fixed > > Applied research is needed how to translate data that exists in a > > network or a network management system into terms understandable by > > customers. This also requires to be able to determine which > > customers are affected and how if something breaks. Of course, > > customer network management mechanisms must not reveal any > > internals that are considered to be secrets of organization > > ^the fixed > > operating a network. > > Sounds good to me. [...] > Ok. How do you think about this...? > > Analysis of Current Network Management Application > > In the past much work has been spent on the specification and > implementation of a network management architecture. However, most > administrators use far less components of this architecture than > possible. There are only vague estimations about the reasons for > this reluctance. A better understanding of what is used for which > purpose and what is not for which reasons is highly disirable. > This can be done by an automated analysis of network management > protocol traffic and applications at operators' sites and enhanced > by additional conversations with the operators. What about this rewrite: 3.5.6 Analysis of Current Management Protocol Usage In the past, much work has been spent on the specification and implementation of the current Internet network management architecture. However, operators reported that they use only a subset of this architecture. A better understanding of what is used for which purpose (and what is not used) is highly desirable. This issue can be addressed by automated network management protocol traffic measurements and subsequent analysis in close cooperation with operators. [Attached is the complete current version.] /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-iab-research-funding-01.txt" 3.5. Network Management The Internet had early success in network device monitoring with the Simple Network Management Protocol (SNMP) and its associated Management Information Base (MIB). There has been comparatively less success in managing networks, in contrast to the monitoring of individual devices. Furthermore, there are a number of operator requirements not well supported by the current Internet management framework. An enhanced network management architecture that more fully supports real operational network management needs is desirable. Unfortunately, network management research has historically been very underfunded, because it is difficult to get funding bodies to recognize this as legitimate networking research. 3.5.1. Managing Networks, Not Devices At present, there are few or no good tools for managing a whole network instead of isolated devices. Current network management protocols such as SNMP are fine for reading status of well-defined objects from individual boxes. But managing networks instead of isolated devices requires to view the network as a large distributed system. Research is needed on scalable distributed data aggregation mechanisms, scalable distributed event correlation algorithms, and distributed and dependable control mechanisms. Applied research into methods of managing sets of networked devices seems worthwhile. Ideally such a management approach would support distributed management, rather than being strictly hierarchical. As an example, the current set of network management tools for managing multimedia (voice and video) IP networks is inadequate, and research would be useful in this area. The lack of appropriate network management tools has also been cited as one of the major barriers to the deployment of IP multicast [Diot00, SP03]. 3.5.2. Configuration Management Operators at the IAB Network Management Workshop [RFC-3535] held in 2002 reported that scalable distributed configuration management for sets of network devices is a significant challenge today. In particular, it is desirable to execute configuration transactions across a number of connected devices, which requires protocols that support distributed transactions. Furthermore, configuration data should be represented in a way which simplifies the processing and generation of configurations with standard tools. Even individual improvements in configuration management for sets of networked devices would be very welcome. Such improvements would need to include an integrated approach to security for the configuration data. 3.5.3. Enhanced Monitoring Capabilities SNMP does not scale very well to monitoring large numbers of objects in many devices in different parts of the network. Some implementations also show inaccuracies (especially when monitoring on shorter time scales) or they lack support for the objects that operators are interested in. An alternative approach worth exploring is how to provide scalable and distributed monitoring, not on individual devices, but instead on groups of devices and networks-as-a-whole. This requires adequate and scalable data aggregation techniques. 3.5.4. Autonomous Network Management Current approaches to network management do not scale sufficiently, so network operators often have difficulties operating their network(s) as successfully and economically as desired. Hence, more work is needed to improve the automation achieved by network management systems. This might involve application of control theory, artificial intelligence, expert systems technology, or other mechanisms. 3.5.5. Customer Network Management An open issue related to network management is helping users and others to identify and resolve problems in the network. If a user can't access a web page, it would be useful if the user could find out, easily, without having to run ping and traceroute, whether the problem was that the web server was down, that the network was partitioned due to a link failure, that there was heavy congestion along the path, that the DNS name couldn't be resolved, that the firewall prohibited the access, or something else. Applied research is needed how to translate data that exists in a network or a network management system into terms understandable by customers. This also requires to be able to determine which customers are affected and how if something breaks. Of course, customer network management mechanisms must not reveal any internals that are considered to be secrets of the organization operating a network. 3.5.6 Analysis of Current Management Protocol Usage In the past, much work has been spent on the specification and implementation of the current Internet network management architecture. However, operators reported that they use only a subset of this architecture. A better understanding of what is used for which purpose (and what is not used) is highly desirable. This issue can be addressed by automated network management protocol traffic measurements and subsequent analysis in close cooperation with operators. --qDbXVdCdHGoSgWSk-- Received: from james ([81.160.180.141]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FEXFRH015703; Tue, 15 Jul 2003 16:33:15 +0200 Received: by james (Postfix, from userid 1000) id 3086584B9; Tue, 15 Jul 2003 16:33:15 +0200 (CEST) Date: Tue, 15 Jul 2003 16:33:15 +0200 From: Juergen Schoenwaelder To: Frank Strau? Cc: NMRG Subject: Re: [nmrg] commands on sming snmp mapping document Message-ID: <20030715143315.GB757@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strau? , NMRG References: <20030701091544.GB1015@iu-bremen.de> <3F1407BF.9040102@ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1407BF.9040102@ibr.cs.tu-bs.de> User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: On Tue, Jul 15, 2003 at 03:55:11PM +0200, Frank Strau? wrote: > Ok. I've done another round of edits that address the editorial minor > issues you gave me in paper form and a number of issues in your email > upon which this is a reply. Great. > Below are the remaining issues that I did > not yet work on. > > >a) There is no section on revising SNMP mapping definitions. Not sure > > why we overlooked that until now. So what do we do about it? Do you have any suggestions? > >b) [...] we [probably should] change TimeTicks to TimeTicks32, > > [then] we [would] have to update this document as well. So what do you think about this? > >d) The description of the node statement should probably say something > > regarding the Pointer type. !? > >f) The fact that the scalars' implements statement assigns > > sub-identifier starting at 1 causes problems with existing scalar > > groups that have all sort of numbering gaps. I guess it is needed > > to be able to override it. > [Of course, this also applies to the table's implements statement.] So we need to resolve this. I would prefer to make the implements statement actually more complex but consistent with the other statements by introducing a block which holds additional statements. I know you do not really like this... > >k) Perhaps the NMRG-SMING-SNMP-EXT module should be renamed to > > NMRG-SMING-EXT-SNMP so that all SMIng language extension are > > grouped together and to reduce confusion by module authors (at > > least I got sometimes confused). Well, this is not really that important. > Slight comments on two of the other issues: > > > e) The description of zeroDotZero should probably be: > > > > "A value used as null value for identifiers and pointers." > > I changed it simply to "A null value used for pointers." Does > that make sense? Well, a no A node statement also defines constants for the ObjectIdentifier base type and zeroDotZero might be used as a NULL value. So I actually meant: "A value used as null value for object identifiers and pointers." Just refering to pointers is not telling the whole story I think. > >l) The References section must be split. I suggest to have normative > > references [SMIng] and [RFC2119] and to make all other references > > informative. > > Ok. I also moved the ABNF RFC to the normative references, since > implementors have to be able to read the SMIng grammar. I agree. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from ibr.cs.tu-bs.de ([81.160.165.183]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FDtSRI008256 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 15 Jul 2003 15:55:28 +0200 Message-ID: <3F1407BF.9040102@ibr.cs.tu-bs.de> Date: Tue, 15 Jul 2003 15:55:11 +0200 From: =?ISO-8859-1?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig, Germany User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: NMRG Subject: Re: [nmrg] commands on sming snmp mapping document References: <20030701091544.GB1015@iu-bremen.de> In-Reply-To: <20030701091544.GB1015@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: -32.2 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen Schoenwaelder wrote: > Here are some comments on . I will > not list the editorial issues here which I will forward to Frank on > paper but rather focus on the technical issues. Ok. I've done another round of edits that address the editorial minor issues you gave me in paper form and a number of issues in your email upon which this is a reply. Below are the remaining issues that I did not yet work on. > a) There is no section on revising SNMP mapping definitions. Not sure > why we overlooked that until now. > b) [...] we [probably should] change TimeTicks to TimeTicks32, > [then] we [would] have to update this document as well. > d) The description of the node statement should probably say something > regarding the Pointer type. > f) The fact that the scalars' implements statement assigns > sub-identifier starting at 1 causes problems with existing scalar > groups that have all sort of numbering gaps. I guess it is needed > to be able to override it. [Of course, this also applies to the table's implements statement.] > k) Perhaps the NMRG-SMING-SNMP-EXT module should be renamed to > NMRG-SMING-EXT-SNMP so that all SMIng language extension are > grouped together and to reduce confusion by module authors (at > least I got sometimes confused). Slight comments on two of the other issues: > e) The description of zeroDotZero should probably be: > > "A value used as null value for identifiers and pointers." I changed it simply to "A null value used for pointers." Does that make sense? > l) The References section must be split. I suggest to have normative > references [SMIng] and [RFC2119] and to make all other references > informative. Ok. I also moved the ABNF RFC to the normative references, since implementors have to be able to read the SMIng grammar. Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FDfWRH005434; Tue, 15 Jul 2003 15:41:33 +0200 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Jul 2003 06:45:39 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6FDfT89005222; Tue, 15 Jul 2003 06:41:30 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-619.cisco.com [10.82.242.107]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAR08620; Tue, 15 Jul 2003 09:41:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20030715094006.00bb1d38@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Jul 2003 09:40:48 -0400 To: Juergen Schoenwaelder From: Ralph Droms Subject: Re: [nmrg] upcoming meeting Cc: Network Management Research Group In-Reply-To: <200307151307.h6FD7SrA008289@hansa.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-IBRFilter-SpamReport: -19.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-19.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I would like to attend the dna meeting Fri AM. However, if the nmrg is not rescheduled, I'll skip the dna meeting. - Ralph At 03:07 PM 7/15/2003 +0200, Juergen Schoenwaelder wrote: >I have updated the meeting web page to include the latest >information. Looking at the IETF agenda, we have on Friday >morning: > >Hall NO INT dna Detecting Network Attachment BOF >Hall GH OPS capwap Control And Provisioning of Wireless Acc. Points BOF >Hall IK TSV tsvwg Transport Area Working Group * > >How many of the those who intent to participate in the NMRG meeting >are planning to go to one of these meetings? I know that Markus will >say something about SNMP in the capwap meeting. > >If more people are going there (or one of the other meetings mentioned >above), then we might want to start later with the NMRG meeting. >Please let me know quickly what you think so that we can come to a >decision when we start. > >[Note that the people hosting us asked that we arrive as a group > rather than on an individual basis and we should plan accordingly.] > >/js > >-- >Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > >-- >!! 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. Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FDbpRH004519; Tue, 15 Jul 2003 15:37:51 +0200 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6FDbtP18117; Tue, 15 Jul 2003 08:37:56 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jul 2003 15:37:46 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155020176E4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Juergen Schoenwaelder , Network Management Research Group Subject: RE: [nmrg] upcoming meeting Date: Tue, 15 Jul 2003 15:37:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-IBRFilter-SpamReport: -3.3 () QUOTED_EMAIL_TEXT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Another question for those at the NNNMRG meeting.... which hotel(s) are you/we staying. I am at Crowne Plaza and can probably extend till Sunday. But maybe it is nicer to be in same hotel... any preferences? Thanks, Bert > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: dinsdag 15 juli 2003 15:07 > To: Network Management Research Group > Subject: [nmrg] upcoming meeting > > > > I have updated the meeting web page to include the latest > information. Looking at the IETF agenda, we have on Friday > morning: > > Hall NO INT dna Detecting Network Attachment BOF > Hall GH OPS capwap Control And Provisioning of Wireless Acc. > Points BOF > Hall IK TSV tsvwg Transport Area Working Group * > > How many of the those who intent to participate in the NMRG meeting > are planning to go to one of these meetings? I know that Markus will > say something about SNMP in the capwap meeting. > > If more people are going there (or one of the other meetings mentioned > above), then we might want to start later with the NMRG meeting. > Please let me know quickly what you think so that we can come to a > decision when we start. > > [Note that the people hosting us asked that we arrive as a group > rather than on an individual basis and we should plan accordingly.] > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > > -- > !! 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. > Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FDVRRH003394; Tue, 15 Jul 2003 15:31:27 +0200 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6FDVNh10824; Tue, 15 Jul 2003 08:31:23 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jul 2003 15:31:22 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155020176D9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Juergen Schoenwaelder Cc: Network Management Research Group Subject: RE: [nmrg] upcoming meeting Date: Tue, 15 Jul 2003 15:31:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-IBRFilter-SpamReport: -3.3 () QUOTED_EMAIL_TEXT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I will go to Friday morning meetings. I have also heard that potentially IPSP will meet Friday morning (I know that Wes is active in there) Thanks, Bert > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: dinsdag 15 juli 2003 15:07 > To: Network Management Research Group > Subject: [nmrg] upcoming meeting > > > > I have updated the meeting web page to include the latest > information. Looking at the IETF agenda, we have on Friday > morning: > > Hall NO INT dna Detecting Network Attachment BOF > Hall GH OPS capwap Control And Provisioning of Wireless Acc. > Points BOF > Hall IK TSV tsvwg Transport Area Working Group * > > How many of the those who intent to participate in the NMRG meeting > are planning to go to one of these meetings? I know that Markus will > say something about SNMP in the capwap meeting. > > If more people are going there (or one of the other meetings mentioned > above), then we might want to start later with the NMRG meeting. > Please let me know quickly what you think so that we can come to a > decision when we start. > > [Note that the people hosting us asked that we arrive as a group > rather than on an individual basis and we should plan accordingly.] > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > > -- > !! 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. > Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FD7SRI030417 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 15 Jul 2003 15:07:28 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6FD7SSk008292; Tue, 15 Jul 2003 15:07:28 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h6FD7SrA008289; Tue, 15 Jul 2003 15:07:28 +0200 Date: Tue, 15 Jul 2003 15:07:28 +0200 Message-Id: <200307151307.h6FD7SrA008289@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] upcoming 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I have updated the meeting web page to include the latest information. Looking at the IETF agenda, we have on Friday morning: Hall NO INT dna Detecting Network Attachment BOF Hall GH OPS capwap Control And Provisioning of Wireless Acc. Points BOF Hall IK TSV tsvwg Transport Area Working Group * How many of the those who intent to participate in the NMRG meeting are planning to go to one of these meetings? I know that Markus will say something about SNMP in the capwap meeting. If more people are going there (or one of the other meetings mentioned above), then we might want to start later with the NMRG meeting. Please let me know quickly what you think so that we can come to a decision when we start. [Note that the people hosting us asked that we arrive as a group rather than on an individual basis and we should plan accordingly.] /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from ibr.cs.tu-bs.de ([81.160.165.173]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6EBYKRI007880 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 14 Jul 2003 13:34:20 +0200 Message-ID: <3F12952C.50003@ibr.cs.tu-bs.de> Date: Mon, 14 Jul 2003 13:34:04 +0200 From: =?ISO-8859-15?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig, Germany User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] network management research funding text References: <20030708093936.GA1287@iu-bremen.de> <3F0C72EF.50805@ibr.cs.tu-bs.de> <20030710083253.GC660@iu-bremen.de> In-Reply-To: <20030710083253.GC660@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: -32.2 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen Schoenwaelder wrote: >>>3.5.2. Configuration Management >>I think there is quite some overlap with aspects already explained in >>3.5.1. However, I regard it reasonable to differentiate what the >>titles of both subsections denote. (Sorry, I have to concrete suggestion >>for a change.) > > 3.5.1 is a general statement that more work has to be done to manage > networks rather than devices. 3.5.2 is more specific on configuration > management since operators told us that this is the most pressing issue > from their perspective. This section is also more concrete in that it > mentions the need for transaction support across a network of devices. > Does this make sense? I agree that there are different intentions to be expressed by the two sections (and by any of the other sections). Just reading the text from a certain distance (like potential people that are addressed by this document) lets me think that there are some common arguments. The same is true for my initial comment on 3.5.4. >>>3.5.3. Enhanced Monitoring Capabilities > [...] I have added the sentence: > > This requires adequate and scalable data aggregation techniques. > > Does this help? I'm fine with that. > [...] What about this: > > 3.5.4. Autonomous Network Management > > Current approaches to network management do not scale sufficiently, > so network operators often have difficulty operating their ^ plural? > network(s) as successfully and economically as desired. Hence, > more work is needed to improve the automation achieved by network > management systems. This might involve application of control > theory, artificial intelligence, expert systems technology, or > other mechanisms, for example. Either "or other mechanisms" or "for example", not both, I suggest. > Any other suggestions? Sounds good to me. >>>3.5.5. Customer Network Management >>> >>> An open issue related to network management is helping users and >>> others to identify and resolve problems in the network. If a user >>> can't access a web page, it would be useful if the user could find >>> out, easily, without having to run ping and traceroute, whether the >>> problem was that the web server was down, that the network was >>> partitioned due to a link failure, that there was heavy congestion >>> along the path, that the DNS name couldn't be resolved, that the >>> firewall prohibited the access, or something else. >> >>I think this paragraph misses a final sentence, just stating what kind >>of research is required to address this well described problem. > > > You basically need a good model of the network and a reasoning engine > to give users explanation. Another approach would be to have specific > automated diagostic tests which can be triggered by customers and which > generate explanations understandable by customers. Sure, such tools > should not reveal any information that is considered a secret by the > network operator. What about adding the following: > > Applied research is needed how to translate data that exists in a > network or a network management system into terms understandable by > customers. This also requires to be able to determine which > customers are affected and how if something breaks. Of course, > customer network management mechanisms must not reveal any > internals that are considered to be secrets of organization ^the > operating a network. Sounds good to me. >>Maybe, we should have a subsection to address research not only on what >>new ideas should be evolved in the future but also on what we have to >>better understand about the past. The plans on NM traffic measurements >>we had during recent NMRG meetings belong to this kind of research. >>Sorry, again no concrete proposal yet. > > > Can you please write something up? Ok. How do you think about this...? Analysis of Current Network Management Application In the past much work has been spent on the specification and implementation of a network management architecture. However, most administrators use far less components of this architecture than possible. There are only vague estimations about the reasons for this reluctance. A better understanding of what is used for which purpose and what is not for which reasons is highly disirable. This can be done by an automated analysis of network management protocol traffic and applications at operators' sites and enhanced by additional conversations with the operators. Received: from exchbrg.TRI.NET (mail.tecolote.com [65.170.33.20]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6ADx1tk028955 for ; Thu, 10 Jul 2003 15:59:02 +0200 Received: by EXCHBRG with Internet Mail Service (5.5.2656.59) id <3G7VY73R>; Thu, 10 Jul 2003 06:58:59 -0700 Message-ID: <4B65CA92F1EB3E439E43CD87EE029DBE025E13@EXCHVA> From: "VanHorn Tom VA,Tecolote" To: "'nmrg@ibr.cs.tu-bs.de'" Date: Thu, 10 Jul 2003 06:58:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-IBRFilter-SpamReport: 0.6 () MAILTO_TO_SPAM_ADDR X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=0.4 required=5.0 tests=MAILTO_TO_SPAM_ADDR version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] Network Mangement SW Development efforts 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I am doing a research project on Network Management (NM) and scoping the size of the Software (SW) Development and maintenance efforts to support the NM functionality for: Planning & scheduling Allocation of resources, node monitoring Traffic/circuit Analysis/monitoring User interfacing and data receipt and data handling Link management Network performance evaluation Routing traceability Timing services Database management Routing table management (updating, monitoring, link trace) Training Simulation I know there are numerous commercial (COTS) products available to perform some, and or all, of these functions to varying degrees. I also understand that each acquirer integrates the product into their unique operating environment. And this integration usually requires some amout of Glue code to work effectively for them. I am trying to get a handle the scope or effort required to develop the COTS SW that is required to perform these functions and insight into the integration efforts (glue code development). SW COTS and glue code sizing/scope would be quantified in Numbers of Source Lines of Code (SLOC), and or software developer man-months. I had read an article about 2 years ago that stated Microsoft Windows 98 required ~29Million SLOC and windows NT an additional 16Million SLOC. Any information you provide would be extremely helpful. Thanks in advance Tom Van Horn tvanhorn@tecolote.com tvh131@aol.com 703-633-2111 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6A9MoKb002903 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Jul 2003 11:22:50 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6A9MoSk010799; Thu, 10 Jul 2003 11:22:50 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h6A9MoUd010796; Thu, 10 Jul 2003 11:22:50 +0200 Date: Thu, 10 Jul 2003 11:22:50 +0200 Message-Id: <200307100922.h6A9MoUd010796@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Network Management Research Group X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] meeting 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: So far, I have seen only a few requests for meeting time at the upcoming meeting. So there are basically next to house keeping things, I have put two main topics on the agenda: 1) MIB module metrics I have done some experimental work last year to compute metrics that try to capture the complexity of a MIB module. I would like to present what I have done and I hope to get feedback whether such work is useful and if there are other ideas to improve the metrics and to validate them. 2) IETF information model Sharon Chisholm recently posted draft-chisholm-snmp-infomode-00.txt which tries to document pieces of an information model that underlies SNMP MIB modules. We have done some related work where we tried to generate UML models from MIB modules using a heuristic reverse engineering algorithm. I suggest that we use the meeting to discuss these approaches and that we try to see whether we can reach agreement on some parts of the IETF information model. I am still open for other suggestions. But if I do not hear from you, I will focus on these two topics during the next meeting. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h6A8WsKa025462; Thu, 10 Jul 2003 10:32:55 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 9C2A91AC5C; Thu, 10 Jul 2003 10:32:54 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id E60955A9; Thu, 10 Jul 2003 10:32:53 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 8867D82C9; Thu, 10 Jul 2003 10:32:53 +0200 (CEST) Date: Thu, 10 Jul 2003 10:32:53 +0200 From: Juergen Schoenwaelder To: Frank Strau? Cc: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] network management research funding text Message-ID: <20030710083253.GC660@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strau? , research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de References: <20030708093936.GA1287@iu-bremen.de> <3F0C72EF.50805@ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline In-Reply-To: <3F0C72EF.50805@ibr.cs.tu-bs.de> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -33.4 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-33.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 09, 2003 at 09:54:23PM +0200, Frank Strau? wrote: > >------------------------------------------------------------------------ > > > >3.5. Network Management > > > > The Internet had early success in network device monitoring with > > the Simple Network Management Protocol (SNMP) and its associated > > Management Information Base (MIB). There has been comparatively > > less success in managing networks, in contrast to the hierarchical > > What do you mean by "hierarchical"? How about just removing this word? This word was in the original text and this is why it is there. I am fine with taking this out. > > > monitoring of individual devices. Furthermore, there are a number > > of operator requirements not well supported by the current Internet > > management framework. An enhanced network management architecture > > that more fully supports real operational network management needs > > is desirable. > > > > Unfortunately, network management research has historically been > > very underfunded, because it is difficult to get funding bodies to > > recognize this as legitimate networking research. > > > >3.5.1. Managing Networks, Not Devices > > > > At present, there are few or no good tools for managing a whole > > network of instead of isolated devices. Current network management > ^^ fixed > > protocols such as SNMP are fine for reading status of well-defined > > objects from individual boxes. But managing networks instead of > > isolated devices requires to view the network as a large > > distributed system. Research is needed on scalable distributed data > > aggregation mechanisms, scalable distributed event correlation > > algorithms, and distributed and dependable control mechanisms. > > > > Applied research into methods of managing sets of networked devices > > seems worthwhile. Ideally such a management approach would support > > distributed management, rather than being strictly hierarchical. > > > > As an example, the current set of network management tools for > > managing multimedia (voice and video) IP networks is inadequate, and > > research would be useful in this area. The lack of appropriate > > network management tools has also been cited as one of the major > > barriers to the deployment of IP multicast [Diot00, SP03]. > > > >3.5.2. Configuration Management > > > > Operators at the IAB Network Management Workshop [RFC-3535] held in > > 2002 reported that scalable distributed configuration management > > for sets of network devices is a significant challenge today. In > > particular, it is desirable to execute configuration transactions > > across a number of connected devices, which requires protocols that > > support distributed transactions. Furthermore, configuration data > > should be represented in a way which simplifies the processing and > > generation of configurations with standard tools. > > > > Even individual improvements in configuration management for sets > > of networked devices would be very welcome. Such improvements > > would need to include an integrated approach to security for the > > configuration data. > > I think there is quite some overlap with aspects already explained in > 3.5.1. However, I regard it reasonable to differentiate what the > titles of both subsections denote. (Sorry, I have to concrete suggestion > for a change.) 3.5.1 is a general statement that more work has to be done to manage networks rather than devices. 3.5.2 is more specific on configuration management since operators told us that this is the most pressing issue from their perspective. This section is also more concrete in that it mentions the need for transaction support across a network of devices. Does this make sense? > > >3.5.3. Enhanced Monitoring Capabilities > > > > SNMP does not scale very well to monitoring large numbers of > > objects in many devices in different parts of the network. Some > > implementations also show inaccuracies (especially when monitoring > > on shorter time scales) or they lack support for the objects that > > operators are interested in. An alternative approach worth > > exploring is how to provide scalable and distributed monitoring, > > not on individual devices, but instead on groups of devices and > > networks-as-a-whole. > > Sorry, I cannot imagine what you mean by monitoring a network here? > Wouldn't that be comprised of monitoring multiple individual devices > combined with adequate correlation/aggregation? (I don't mind to go > into discussions on solutions on this forum.) Sure, you always at the end talk to devices. However, there is a need to aggregate data in meaninful ways. You really want to have monitoring data on the AS level. Similarily, in IPv6 networks, monitoring all interfaces a la mrtg is kind of useless since you have much more interfaces. I have added the sentence: This requires adequate and scalable data aggregation techniques. Does this help? > > >3.5.4. Improving the Scalability of Network Management > > > > Current approaches to network management do not scale sufficiently, > > so network operators often have difficulty operating their > > network(s) as successfully and economically as desired. Hence, > > more work is needed to improve the scalability of network > > management systems. This might involve application of control > > theory, artificial intelligence, expert systems technology, or > > other mechanisms, for example. > > Again some degree of overlap with 3.5.1, I think. I do not see the overlap with 3.5.1 - perhaps the title of this section is not the best one? A real hype title would perhaps be "Disappearing Network Management" or a bit more conservative "Autonomous Network Management". Any better suggestions? What about this: 3.5.4. Autonomous Network Management Current approaches to network management do not scale sufficiently, so network operators often have difficulty operating their network(s) as successfully and economically as desired. Hence, more work is needed to improve the automation achieved by network management systems. This might involve application of control theory, artificial intelligence, expert systems technology, or other mechanisms, for example. Any other suggestions? > >3.5.5. Customer Network Management > > > > An open issue related to network management is helping users and > > others to identify and resolve problems in the network. If a user > > can't access a web page, it would be useful if the user could find > > out, easily, without having to run ping and traceroute, whether the > > problem was that the web server was down, that the network was > > partitioned due to a link failure, that there was heavy congestion > > along the path, that the DNS name couldn't be resolved, that the > > firewall prohibited the access, or something else. > > I think this paragraph misses a final sentence, just stating what kind > of research is required to address this well described problem. You basically need a good model of the network and a reasoning engine to give users explanation. Another approach would be to have specific automated diagostic tests which can be triggered by customers and which generate explanations understandable by customers. Sure, such tools should not reveal any information that is considered a secret by the network operator. What about adding the following: Applied research is needed how to translate data that exists in a network or a network management system into terms understandable by customers. This also requires to be able to determine which customers are affected and how if something breaks. Of course, customer network management mechanisms must not reveal any internals that are considered to be secrets of organization operating a network. > Maybe, we should have a subsection to address research not only on what > new ideas should be evolved in the future but also on what we have to > better understand about the past. The plans on NM traffic measurements > we had during recent NMRG meetings belong to this kind of research. > Sorry, again no concrete proposal yet. Can you please write something up? [Attached is the revised version of the text.] /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-iab-research-funding-01.txt" 3.5. Network Management The Internet had early success in network device monitoring with the Simple Network Management Protocol (SNMP) and its associated Management Information Base (MIB). There has been comparatively less success in managing networks, in contrast to the monitoring of individual devices. Furthermore, there are a number of operator requirements not well supported by the current Internet management framework. An enhanced network management architecture that more fully supports real operational network management needs is desirable. Unfortunately, network management research has historically been very underfunded, because it is difficult to get funding bodies to recognize this as legitimate networking research. 3.5.1. Managing Networks, Not Devices At present, there are few or no good tools for managing a whole network instead of isolated devices. Current network management protocols such as SNMP are fine for reading status of well-defined objects from individual boxes. But managing networks instead of isolated devices requires to view the network as a large distributed system. Research is needed on scalable distributed data aggregation mechanisms, scalable distributed event correlation algorithms, and distributed and dependable control mechanisms. Applied research into methods of managing sets of networked devices seems worthwhile. Ideally such a management approach would support distributed management, rather than being strictly hierarchical. As an example, the current set of network management tools for managing multimedia (voice and video) IP networks is inadequate, and research would be useful in this area. The lack of appropriate network management tools has also been cited as one of the major barriers to the deployment of IP multicast [Diot00, SP03]. 3.5.2. Configuration Management Operators at the IAB Network Management Workshop [RFC-3535] held in 2002 reported that scalable distributed configuration management for sets of network devices is a significant challenge today. In particular, it is desirable to execute configuration transactions across a number of connected devices, which requires protocols that support distributed transactions. Furthermore, configuration data should be represented in a way which simplifies the processing and generation of configurations with standard tools. Even individual improvements in configuration management for sets of networked devices would be very welcome. Such improvements would need to include an integrated approach to security for the configuration data. 3.5.3. Enhanced Monitoring Capabilities SNMP does not scale very well to monitoring large numbers of objects in many devices in different parts of the network. Some implementations also show inaccuracies (especially when monitoring on shorter time scales) or they lack support for the objects that operators are interested in. An alternative approach worth exploring is how to provide scalable and distributed monitoring, not on individual devices, but instead on groups of devices and networks-as-a-whole. This requires adequate and scalable data aggregation techniques. 3.5.4. Autonomous Network Management Current approaches to network management do not scale sufficiently, so network operators often have difficulty operating their network(s) as successfully and economically as desired. Hence, more work is needed to improve the automation achieved by network management systems. This might involve application of control theory, artificial intelligence, expert systems technology, or other mechanisms, for example. 3.5.5. Customer Network Management An open issue related to network management is helping users and others to identify and resolve problems in the network. If a user can't access a web page, it would be useful if the user could find out, easily, without having to run ping and traceroute, whether the problem was that the web server was down, that the network was partitioned due to a link failure, that there was heavy congestion along the path, that the DNS name couldn't be resolved, that the firewall prohibited the access, or something else. Applied research is needed how to translate data that exists in a network or a network management system into terms understandable by customers. This also requires to be able to determine which customers are affected and how if something breaks. Of course, customer network management mechanisms must not reveal any internals that are considered to be secrets of organization operating a network. --45Z9DzgjV8m4Oswq-- Received: from ibr.cs.tu-bs.de (dagoba.ibr.cs.tu-bs.de [134.169.34.107]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h69JsaKb018869 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 9 Jul 2003 21:54:37 +0200 Message-ID: <3F0C72EF.50805@ibr.cs.tu-bs.de> Date: Wed, 09 Jul 2003 21:54:23 +0200 From: =?ISO-8859-15?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig, Germany User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de CC: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] network management research funding text References: <20030708093936.GA1287@iu-bremen.de> In-Reply-To: <20030708093936.GA1287@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: -32.2 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-31.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen Schoenwaelder wrote: > Below is some text for section 3.5 of the IAB research funding draft. > I basically took the text from > and rearranged it and added a few pieces here and there. I understand > that the idea is to not be comprehensive and so I tried hard to not > add lots of additional research topics people actually work on. > Thanks for picking this document up again! Here are some additional comments... > ------------------------------------------------------------------------ > > 3.5. Network Management > > The Internet had early success in network device monitoring with > the Simple Network Management Protocol (SNMP) and its associated > Management Information Base (MIB). There has been comparatively > less success in managing networks, in contrast to the hierarchical What do you mean by "hierarchical"? How about just removing this word? > monitoring of individual devices. Furthermore, there are a number > of operator requirements not well supported by the current Internet > management framework. An enhanced network management architecture > that more fully supports real operational network management needs > is desirable. > > Unfortunately, network management research has historically been > very underfunded, because it is difficult to get funding bodies to > recognize this as legitimate networking research. > > 3.5.1. Managing Networks, Not Devices > > At present, there are few or no good tools for managing a whole > network of instead of isolated devices. Current network management ^^ > protocols such as SNMP are fine for reading status of well-defined > objects from individual boxes. But managing networks instead of > isolated devices requires to view the network as a large > distributed system. Research is needed on scalable distributed data > aggregation mechanisms, scalable distributed event correlation > algorithms, and distributed and dependable control mechanisms. > > Applied research into methods of managing sets of networked devices > seems worthwhile. Ideally such a management approach would support > distributed management, rather than being strictly hierarchical. > > As an example, the current set of network management tools for > managing multimedia (voice and video) IP networks is inadequate, and > research would be useful in this area. The lack of appropriate > network management tools has also been cited as one of the major > barriers to the deployment of IP multicast [Diot00, SP03]. > > 3.5.2. Configuration Management > > Operators at the IAB Network Management Workshop [RFC-3535] held in > 2002 reported that scalable distributed configuration management > for sets of network devices is a significant challenge today. In > particular, it is desirable to execute configuration transactions > across a number of connected devices, which requires protocols that > support distributed transactions. Furthermore, configuration data > should be represented in a way which simplifies the processing and > generation of configurations with standard tools. > > Even individual improvements in configuration management for sets > of networked devices would be very welcome. Such improvements > would need to include an integrated approach to security for the > configuration data. I think there is quite some overlap with aspects already explained in 3.5.1. However, I regard it reasonable to differentiate what the titles of both subsections denote. (Sorry, I have to concrete suggestion for a change.) > 3.5.3. Enhanced Monitoring Capabilities > > SNMP does not scale very well to monitoring large numbers of > objects in many devices in different parts of the network. Some > implementations also show inaccuracies (especially when monitoring > on shorter time scales) or they lack support for the objects that > operators are interested in. An alternative approach worth > exploring is how to provide scalable and distributed monitoring, > not on individual devices, but instead on groups of devices and > networks-as-a-whole. Sorry, I cannot imagine what you mean by monitoring a network here? Wouldn't that be comprised of monitoring multiple individual devices combined with adequate correlation/aggregation? (I don't mind to go into discussions on solutions on this forum.) > 3.5.4. Improving the Scalability of Network Management > > Current approaches to network management do not scale sufficiently, > so network operators often have difficulty operating their > network(s) as successfully and economically as desired. Hence, > more work is needed to improve the scalability of network > management systems. This might involve application of control > theory, artificial intelligence, expert systems technology, or > other mechanisms, for example. Again some degree of overlap with 3.5.1, I think. > 3.5.5. Customer Network Management > > An open issue related to network management is helping users and > others to identify and resolve problems in the network. If a user > can't access a web page, it would be useful if the user could find > out, easily, without having to run ping and traceroute, whether the > problem was that the web server was down, that the network was > partitioned due to a link failure, that there was heavy congestion > along the path, that the DNS name couldn't be resolved, that the > firewall prohibited the access, or something else. I think this paragraph misses a final sentence, just stating what kind of research is required to address this well described problem. Maybe, we should have a subsection to address research not only on what new ideas should be evolved in the future but also on what we have to better understand about the past. The plans on NM traffic measurements we had during recent NMRG meetings belong to this kind of research. Sorry, again no concrete proposal yet. Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h689dbKa014425 for ; Tue, 8 Jul 2003 11:39:38 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id A6EFF1AC25; Tue, 8 Jul 2003 11:39:37 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id 062231ABF6; Tue, 8 Jul 2003 11:39:37 +0200 (CEST) Received: by james (Postfix, from userid 1000) id CFC7F82B0; Tue, 8 Jul 2003 11:39:36 +0200 (CEST) Date: Tue, 8 Jul 2003 11:39:36 +0200 From: Juergen Schoenwaelder To: research-funding@ietf.org Cc: nmrg@ibr.cs.tu-bs.de Message-ID: <20030708093936.GA1287@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: research-funding@ietf.org, nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.4 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] network management research funding text 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Below is some text for section 3.5 of the IAB research funding draft. I basically took the text from and rearranged it and added a few pieces here and there. I understand that the idea is to not be comprehensive and so I tried hard to not add lots of additional research topics people actually work on. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-iab-research-funding-01.txt" 3.5. Network Management The Internet had early success in network device monitoring with the Simple Network Management Protocol (SNMP) and its associated Management Information Base (MIB). There has been comparatively less success in managing networks, in contrast to the hierarchical monitoring of individual devices. Furthermore, there are a number of operator requirements not well supported by the current Internet management framework. An enhanced network management architecture that more fully supports real operational network management needs is desirable. Unfortunately, network management research has historically been very underfunded, because it is difficult to get funding bodies to recognize this as legitimate networking research. 3.5.1. Managing Networks, Not Devices At present, there are few or no good tools for managing a whole network of instead of isolated devices. Current network management protocols such as SNMP are fine for reading status of well-defined objects from individual boxes. But managing networks instead of isolated devices requires to view the network as a large distributed system. Research is needed on scalable distributed data aggregation mechanisms, scalable distributed event correlation algorithms, and distributed and dependable control mechanisms. Applied research into methods of managing sets of networked devices seems worthwhile. Ideally such a management approach would support distributed management, rather than being strictly hierarchical. As an example, the current set of network management tools for managing multimedia (voice and video) IP networks is inadequate, and research would be useful in this area. The lack of appropriate network management tools has also been cited as one of the major barriers to the deployment of IP multicast [Diot00, SP03]. 3.5.2. Configuration Management Operators at the IAB Network Management Workshop [RFC-3535] held in 2002 reported that scalable distributed configuration management for sets of network devices is a significant challenge today. In particular, it is desirable to execute configuration transactions across a number of connected devices, which requires protocols that support distributed transactions. Furthermore, configuration data should be represented in a way which simplifies the processing and generation of configurations with standard tools. Even individual improvements in configuration management for sets of networked devices would be very welcome. Such improvements would need to include an integrated approach to security for the configuration data. 3.5.3. Enhanced Monitoring Capabilities SNMP does not scale very well to monitoring large numbers of objects in many devices in different parts of the network. Some implementations also show inaccuracies (especially when monitoring on shorter time scales) or they lack support for the objects that operators are interested in. An alternative approach worth exploring is how to provide scalable and distributed monitoring, not on individual devices, but instead on groups of devices and networks-as-a-whole. 3.5.4. Improving the Scalability of Network Management Current approaches to network management do not scale sufficiently, so network operators often have difficulty operating their network(s) as successfully and economically as desired. Hence, more work is needed to improve the scalability of network management systems. This might involve application of control theory, artificial intelligence, expert systems technology, or other mechanisms, for example. 3.5.5. Customer Network Management An open issue related to network management is helping users and others to identify and resolve problems in the network. If a user can't access a web page, it would be useful if the user could find out, easily, without having to run ping and traceroute, whether the problem was that the web server was down, that the network was partitioned due to a link failure, that there was heavy congestion along the path, that the DNS name couldn't be resolved, that the firewall prohibited the access, or something else. --KsGdsel6WgEHnImy-- Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h63FPQKb032703 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Jul 2003 17:25:26 +0200 Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h63FPQSk007081; Thu, 3 Jul 2003 17:25:26 +0200 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) id h63FPQM2007078; Thu, 3 Jul 2003 17:25:26 +0200 From: Frank Strauss To: j.schoenwaelder@iu-bremen.de Cc: shriharsha.hegde@intel.com, ravi.sahita@intel.com, nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] status of the SMIng to COPS-PR mapping References: <20030703134307.GA1805@localhost> Date: 03 Jul 2003 17:25:26 +0200 In-Reply-To: <20030703134307.GA1805@localhost> Message-ID: Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: -16.3 () IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-16.2 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi! Juergen> I like to move the SMIng core, the SMIng module and the SMIng Juergen> SNMP mapping documents to the RFC editor in the not too Juergen> distant future. My understanding is that Frank will provide Juergen> another revision of the SMIng module and the SMIng SNMP Juergen> mapping document to address the issues posted to the NMRG Juergen> list. I can confirm this understanding. :-) Probably on the train to Vienna. Juergen> The question now is whether we can also expect the SMIng Juergen> COPS-PR mapping document to be ready to go with the other Juergen> documents. Please let me know when you will be able to work Juergen> on this. If you do not have the time to work on this, we Juergen> either need to find a volunteer or we decide to move the Juergen> other documents forward without waiting for the COPS-PR Juergen> mapping. -frank Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h63DfwKa020837 for ; Thu, 3 Jul 2003 15:41:58 +0200 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 951A91AB3A; Thu, 3 Jul 2003 15:41:58 +0200 (CEST) Received: from james (unknown [212.201.47.15]) by merkur.iu-bremen.de (Postfix) with ESMTP id EACFE181C1; Thu, 3 Jul 2003 15:41:57 +0200 (CEST) Received: by james (Postfix, from userid 1000) id 8985282AF; Thu, 3 Jul 2003 15:43:07 +0200 (CEST) Date: Thu, 3 Jul 2003 15:43:07 +0200 From: Juergen Schoenwaelder To: shriharsha.hegde@intel.com, ravi.sahita@intel.com Cc: nmrg@ibr.cs.tu-bs.de Message-ID: <20030703134307.GA1805@localhost> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: shriharsha.hegde@intel.com, ravi.sahita@intel.com, nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.4 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] status of the SMIng to COPS-PR mapping 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I like to move the SMIng core, the SMIng module and the SMIng SNMP mapping documents to the RFC editor in the not too distant future. My understanding is that Frank will provide another revision of the SMIng module and the SMIng SNMP mapping document to address the issues posted to the NMRG list. The question now is whether we can also expect the SMIng COPS-PR mapping document to be ready to go with the other documents. Please let me know when you will be able to work on this. If you do not have the time to work on this, we either need to find a volunteer or we decide to move the other documents forward without waiting for the COPS-PR mapping. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from firewall.ftw.tuwien.ac.at (nt-ftw.ftw.tuwien.ac.at [128.130.90.21]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with ESMTP id h62EOV9E002010 for ; Wed, 2 Jul 2003 16:24:31 +0200 Received: from nt_ftw.ftw.tuwien.ac.at by firewall.ftw.tuwien.ac.at via smtpd (for agitator.ibr.cs.tu-bs.de [134.169.34.18]) with ESMTP; Wed, 2 Jul 2003 16:03:14 +0100 Received: by nt-ftw.ftw.at with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 16:20:46 +0200 Message-ID: From: Haidegger@FTW.at To: j.schoenwaelder@iu-bremen.de Cc: nmrg@ibr.cs.tu-bs.de Subject: AW: [nmrg] upcoming nmrg meeting Date: Wed, 2 Jul 2003 16:20:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-IBRFilter-SpamReport: 0.9 () NO_REAL_NAME X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id h62EOV9E002010 X-Spam-Status: No, hits=0.7 required=5.0 tests=NO_REAL_NAME version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Dear Jürgen, It is within walking distance (about 5 minutes, if so much). One just leaves the Austria Center Vienna through the main gate and walks into the direction of the underground (U1). At the bus station, before you cross the street you turn right and pass a chapel, after which you turn right again and just head straight to the TechGate, which also houses ftw (3-rd floor, just ring the bell). This is the appropriate link, which describes the location precisely: http://www.ftw.at/location_en.html Greetings Wolfgang -----Ursprüngliche Nachricht----- Von: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] Gesendet: Dienstag, 01. Juli 2003 17:25 An: Haidegger@FTW.at Cc: nmrg@ibr.cs.tu-bs.de Betreff: RE: [nmrg] upcoming nmrg meeting Wolfgang, can you please let us know what the distance from the FTW to the IETF meeting place (Austria Center Vienna) is? Perhaps you can give travel instructions how people who stay close to the IETF meeting place can reach the FTW. Thanks, /js ----- Forwarded message from "Wijnen, Bert (Bert)" ----- From: "Wijnen, Bert (Bert)" To: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] upcoming nmrg meeting Date: Mon, 30 Jun 2003 16:57:29 +0200 I plan to attend. Is it located close to where IETF is being held, or shoudl we switch hotels as well? Thanks, Bert -- ----- End forwarded message ----- Received: from james.eecs.iu-bremen.de (surfer6.ibr.cs.tu-bs.de [134.169.35.166]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with SMTP id h62E1r9E029532; Wed, 2 Jul 2003 16:01:53 +0200 Received: (nullmailer pid 1372 invoked by uid 1000); Tue, 01 Jul 2003 15:24:51 -0000 Date: Tue, 1 Jul 2003 17:24:51 +0200 From: Juergen Schoenwaelder To: Haidegger@FTW.at Cc: nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] upcoming nmrg meeting Message-ID: <20030701152451.GA1235@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Haidegger@FTW.at, nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.2 required=5.0 tests=DATE_IN_PAST_12_24,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Wolfgang, can you please let us know what the distance from the FTW to the IETF meeting place (Austria Center Vienna) is? Perhaps you can give travel instructions how people who stay close to the IETF meeting place can reach the FTW. Thanks, /js ----- Forwarded message from "Wijnen, Bert (Bert)" ----- From: "Wijnen, Bert (Bert)" To: j.schoenwaelder@iu-bremen.de, nmrg@ibr.cs.tu-bs.de Subject: RE: [nmrg] upcoming nmrg meeting Date: Mon, 30 Jun 2003 16:57:29 +0200 I plan to attend. Is it located close to where IETF is being held, or shoudl we switch hotels as well? Thanks, Bert -- ----- End forwarded message ----- Received: from james.eecs.iu-bremen.de (surfer6.ibr.cs.tu-bs.de [134.169.35.166]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with SMTP id h62E1m9E029476; Wed, 2 Jul 2003 16:01:48 +0200 Received: (nullmailer pid 1021 invoked by uid 1000); Tue, 01 Jul 2003 09:14:26 -0000 Date: Tue, 1 Jul 2003 11:14:26 +0200 From: Juergen Schoenwaelder To: NMRG Message-ID: <20030701091426.GA1015@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: NMRG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.4 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] comments on sming modules document 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Here are some comments on : a) In the introduce, change "modules" to "module" since this revision only contains a single module. b) Add a copyright notice to the MIB module: description "Core type definitions for SMIng. Several type definitions are SMIng versions of similar SMIv2 or SPPI definitions. Copyright (C) The Internet Society (2003). This version of this SMIng module is part of RFC XXXX, see the RFC itself for full legal notices."; (This also applies to SMIng modules in other related documents.) c) In the descriptions of Gauge32 and Gauge64, I suggest to remove the last sentence in brackets since I believe that this clarification does not need to be carried forward in SMIng. d) Capitalize Internet in the description of the IpAddress typedef. e) I suggest to reword the TimeStamp description: description "The value of an associated TimeTicks attribute at which a specific occurrence happened. The specific occurrence must be defined in the description of any attribute defined using this type. When the specific occurrence occurred prior to the last time the associated TimeTicks attribute was zero, then the TimeStamp value is zero. Note that this requires all TimeStamp values to be reset to zero when the value of the associated TimeTicks attribute reaches 497+ days and wraps around to zero. The associated TimeTicks attribute should be specified in the description of any attribute using this type. If no TimeTicks attribute has been specified, the default scalar attribute sysUpTime is used."; The rationale here is to refer to sysUpTime only once and to allow TimeStamps to be used with other time based. (An even better approach might be to have a TimeStamp which does not have the default sysUpTime relationship and a derived TimeStampSysUpTime which has the explicit binding.) f) While thinking about the TimeTicks and TimeStamp objects, I was wondering whether we should rename them to TimeTicks32 and TimeStamp32 and in addition introduce TimeTicks64 and TimeStamp64 so that MIB authors can choose a timer which does not roll-over every 497+ days. g) In the description of DateAndTime, we probably want to make it more obvious that 0 is allowed for month and day fields: 2 3 month 1..12 | 0 3 4 day 1..31 | 0 h) There are references to RFC 854, RFC 2571 and RFC 2279 in the SMIng module which do not appear in the References section. We should probably add them. i) The References section has to be split into normative and informative references. I suggest that [SMIng] is the only real normative reference and the others are informative. j) If you want to keep the URI in the author's addresses section, please change mine to http://www.eecs.iu-bremen.de/ /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from james.eecs.iu-bremen.de (surfer6.ibr.cs.tu-bs.de [134.169.35.166]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.4) with SMTP id h62E1n9E029482; Wed, 2 Jul 2003 16:01:49 +0200 Received: (nullmailer pid 1032 invoked by uid 1000); Tue, 01 Jul 2003 09:15:44 -0000 Date: Tue, 1 Jul 2003 11:15:44 +0200 From: Juergen Schoenwaelder To: NMRG Message-ID: <20030701091544.GB1015@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: NMRG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-IBRFilter-SpamReport: -6.4 () USER_AGENT_MUTT X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-6.4 required=5.0 tests=USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [nmrg] commands on sming snmp mapping document 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.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Here are some comments on . I will not list the editorial issues here which I will forward to Frank on paper but rather focus on the technical issues. a) There is no section on revising SNMP mapping definitions. Not sure why we overlooked that until now. b) Section 3 discusses data type mappings but misses to discuss the Pointer type which we have added back to SMIng. Also, we change TimeTicks to TimeTicks32, we have to update this document as well. c) We should actually cite the SPPI RFC when we refer to the SPPI. d) The description of the node statement should probably say something regarding the Pointer type. e) The description of zeroDotZero should probably be: "A value used as null value for identifiers and pointers." f) The fact that the scalars' implements statement assigns sub-identifier starting at 1 causes problems with existing scalar groups that have all sort of numbering gaps. I guess it is needed to be able to override it. g) The scalars and table usage examples miss a semicolon. h) The NMRG-SMING-SNMP-EXT and the NMRG-SMING-SNMP module header should follow the guidelines and contain a copyright plus a reference to the NMRG with contact information and such. (This may also apply to other SMIng modules.) i) I suggest to remove the ;; EOF comment in the abnf statement of the NMRG-SMING-SNMP module. j) In the same module, I suggest to remove the stuff about agentcaps since we never really got to this. k) Perhaps the NMRG-SMING-SNMP-EXT module should be renamed to NMRG-SMING-EXT-SNMP so that all SMIng language extension are grouped together and to reduce confusion by module authors (at least I got sometimes confused). l) The References section must be split. I suggest to have normative references [SMIng] and [RFC2119] and to make all other references informative. m) The RFC number in reference [RFC3416] is wrong. n) I think appendix A is the same as the abnf statement in one of the SMIng modules and can be removed. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany