From owner-disman@dorothy.peer.com Tue Sep 12 11:56:48 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07514 for ; Tue, 12 Sep 2000 11:56:48 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8CFnFG06619; Tue, 12 Sep 2000 10:49:16 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA27239 for disman-list; Tue, 12 Sep 2000 08:44:29 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA27234 for ; Tue, 12 Sep 2000 08:44:25 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8CFiMK05415 for ; Tue, 12 Sep 2000 10:44:22 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA24797; Tue, 12 Sep 2000 17:45:10 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA26326; Tue, 12 Sep 2000 17:45:10 +0200 Date: Tue, 12 Sep 2000 17:45:10 +0200 Message-Id: <200009121545.RAA26326@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: DISMAN Mailing List In-reply-to: <200009072237.SAA29818@aix43.snmp.com> (message from Steve Moulton on Thu, 07 Sep 2000 18:37:50 -0400) Subject: Re: snmpconf Interim Meeting Notes Day Two References: <200009072237.SAA29818@aix43.snmp.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Steve Moulton writes: Steve> In summary, we are talking about augmenting the schedule MIB Steve> so that we have the start and stop times rather than having Steve> multiple entries. This is a proposed change. The revision of RFC 2591 is currently waiting for some final touches from me. If you have any concrete proposals to enhance the schedule MIB for configuration management purposes, so please speak up quickly. From reading the snmpconf minutes, I do not understand what your proposed change actually looks like. So please come up with some more details quickly and please get the DISMAN WG involved by CC'ing them or moving discussion of the proposed scheduling MIB change to the DISMAN list itself. Thanks, /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Tue Sep 12 12:44:51 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08912 for ; Tue, 12 Sep 2000 12:44:50 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8CGffF21151; Tue, 12 Sep 2000 11:41:41 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA27797 for disman-list; Tue, 12 Sep 2000 09:40:34 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA27747; Tue, 12 Sep 2000 09:33:57 -0700 (PDT) Date: Tue, 12 Sep 2000 09:33:57 -0700 (PDT) From: Randy Presuhn Message-Id: <200009121633.JAA27747@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: "silent" removal from WG mailing list Cc: agentx@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id e8CGffF21151 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08912 Hi - Any suggestions for what the (disman, agentx) mailing list administrator should do in cases like the attached? When traffic bounces, I attempt to notify the postmaster of the relevant domain in order to let them know what's happening. When I drop a subscriber due to bounces, I also notify that domain's postmaster and the WG chair. In cases like this, where mail for a domain's postmaster bounces, is there any further course of action that would be worthwhile? ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- > From MAILER-DAEMON Tue Sep 12 09:18:28 PDT 2000 > Date: Tue, 12 Sep 2000 11:18:24 -0500 (CDT) > From: Mail Delivery Subsystem > Message-Id: <200009121618.e8CGIOj13694@tattler.bmc.com> > To: > Subject: Returned mail: see transcript for details > Auto-Submitted: auto-generated (failure) > > This is a MIME-encapsulated message > > --e8CGIOj13694.968775504/tattler.bmc.com > > The original message was received at Tue, 12 Sep 2000 11:18:22 -0500 (CDT) > from localhost [127.0.0.1] > > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 ... Relaying denied) > > (reason: 550 ... Relaying denied) > > (reason: 550 ... Relaying denied) > > ----- Transcript of session follows ----- > ... while talking to proxy2.cisco.com.: > >>> RCPT To: > <<< 550 ... Relaying denied > 550 5.1.1 ... User unknown > >>> RCPT To: > <<< 550 ... Relaying denied > 550 5.1.1 ... User unknown > >>> RCPT To: > <<< 550 ... Relaying denied > 550 5.1.1 ... User unknown > > --e8CGIOj13694.968775504/tattler.bmc.com > Content-Type: message/delivery-status > > Reporting-MTA: dns; tattler.bmc.com > Received-From-MTA: DNS; localhost > Arrival-Date: Tue, 12 Sep 2000 11:18:22 -0500 (CDT) > > Final-Recipient: RFC822; postmaster@atl.co.uk > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; proxy2.cisco.com > Diagnostic-Code: SMTP; 550 ... Relaying denied > Last-Attempt-Date: Tue, 12 Sep 2000 11:18:24 -0500 (CDT) > > Final-Recipient: RFC822; aleslie@atl.co.uk > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; proxy2.cisco.com > Diagnostic-Code: SMTP; 550 ... Relaying denied > Last-Attempt-Date: Tue, 12 Sep 2000 11:18:24 -0500 (CDT) > > Final-Recipient: RFC822; EinarNN@atl.co.uk > Action: failed > Status: 5.1.1 > Remote-MTA: DNS; proxy2.cisco.com > Diagnostic-Code: SMTP; 550 ... Relaying denied > Last-Attempt-Date: Tue, 12 Sep 2000 11:18:24 -0500 (CDT) > > --e8CGIOj13694.968775504/tattler.bmc.com > Content-Type: message/rfc822 > Content-Transfer-Encoding: 8bit > > Return-Path: > Received: from dorothy.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8CGIMj13684; > Tue, 12 Sep 2000 11:18:22 -0500 (CDT) > Received: (from rpresuhn@localhost) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA27603; > Tue, 12 Sep 2000 09:18:22 -0700 (PDT) > Date: Tue, 12 Sep 2000 09:18:22 -0700 (PDT) > From: Randy Presuhn > Message-Id: <200009121618.JAA27603@dorothy.bmc.com> > To: postmaster@atl.co.uk > Subject: and are bouncing > Cc: EinarNN@atl.co.uk, aleslie@atl.co.uk > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Hi - > > Mail for and from the > IETF disman working group mailing list is bouncing. See the > attached message for details. If these bounces persist, these > addresses will be dropped from this working group mailing list. > > ------------------------------------------------------- > Randy Presuhn randy_presuhn@bmc.com > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 > Fax: +1 408 965-0359 2141 North First Street > http://www.bmc.com/ San José, California 95131 USA > ------------------------------------------------------- > My opinions and BMC's are independent variables. > ------------------------------------------------------- > > > From MAILER-DAEMON Tue Sep 12 08:58:43 PDT 2000 > > Date: Tue, 12 Sep 2000 10:58:41 -0500 (CDT) > > From: Mail Delivery Subsystem > > Message-Id: <200009121558.e8CFwfG06570@tattler.bmc.com> > > To: > > Subject: Returned mail: see transcript for details > > Auto-Submitted: auto-generated (failure) > > > > This is a MIME-encapsulated message > > > > --e8CFwfG06570.968774321/tattler.bmc.com > > > > The original message was received at Tue, 12 Sep 2000 10:48:53 -0500 (CDT) > > from localhost [127.0.0.1] > > > > ----- The following addresses had permanent fatal errors ----- > > > > (reason: 550 ... Relaying denied) > > > > (reason: 550 ... Relaying denied) > > > > ----- Transcript of session follows ----- > > ... while talking to proxy2.cisco.com.: > > >>> RCPT To: > > <<< 550 ... Relaying denied > > 550 5.1.1 ... User unknown > > >>> RCPT To: > > <<< 550 ... Relaying denied > > 550 5.1.1 ... User unknown > > > > --e8CFwfG06570.968774321/tattler.bmc.com > > Content-Type: message/delivery-status > > > > Reporting-MTA: dns; tattler.bmc.com > > Received-From-MTA: DNS; localhost > > Arrival-Date: Tue, 12 Sep 2000 10:48:53 -0500 (CDT) > > > > Final-Recipient: RFC822; aleslie@atl.co.uk > > Action: failed > > Status: 5.1.1 > > Remote-MTA: DNS; proxy2.cisco.com > > Diagnostic-Code: SMTP; 550 ... Relaying denied > > Last-Attempt-Date: Tue, 12 Sep 2000 10:49:12 -0500 (CDT) > > > > Final-Recipient: RFC822; EinarNN@atl.co.uk > > Action: failed > > Status: 5.1.1 > > Remote-MTA: DNS; proxy2.cisco.com > > Diagnostic-Code: SMTP; 550 ... Relaying denied > > Last-Attempt-Date: Tue, 12 Sep 2000 10:49:12 -0500 (CDT) > > > > --e8CFwfG06570.968774321/tattler.bmc.com > > Content-Type: text/rfc822-headers > > > > Return-Path: > > Received: from dorothy.bmc.com (localhost [127.0.0.1]) > > by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8CFmrG06520; > > Tue, 12 Sep 2000 10:48:53 -0500 (CDT) > > Received: (from root@localhost) > > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA27239 > > for disman-list; Tue, 12 Sep 2000 08:44:29 -0700 (PDT) > > Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) > > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA27234 > > for ; Tue, 12 Sep 2000 08:44:25 -0700 (PDT) > > Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) > > by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8CFiMK05415 > > for ; Tue, 12 Sep 2000 10:44:22 -0500 (CDT) > > Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) > > by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA24797; > > Tue, 12 Sep 2000 17:45:10 +0200 (MET DST) > > Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA26326; Tue, 12 Sep 2000 17:45:10 +0200 > > Date: Tue, 12 Sep 2000 17:45:10 +0200 > > Message-Id: <200009121545.RAA26326@henkell.ibr.cs.tu-bs.de> > > From: Juergen Schoenwaelder > > To: snmpconf@snmp.com > > CC: DISMAN Mailing List > > In-reply-to: <200009072237.SAA29818@aix43.snmp.com> (message from Steve > > Moulton on Thu, 07 Sep 2000 18:37:50 -0400) > > Subject: Re: snmpconf Interim Meeting Notes Day Two > > References: <200009072237.SAA29818@aix43.snmp.com> > > Sender: owner-disman@dorothy.peer.com > > Precedence: bulk > > List-Id: IETF disman Working Group mailing list > > > > --e8CFwfG06570.968774321/tattler.bmc.com-- > > > > > > --e8CGIOj13694.968775504/tattler.bmc.com-- > > From owner-disman@dorothy.peer.com Tue Sep 12 12:49:10 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09011 for ; Tue, 12 Sep 2000 12:49:09 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8CGkeO22503; Tue, 12 Sep 2000 11:46:40 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA27869 for disman-list; Tue, 12 Sep 2000 09:45:47 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA27863; Tue, 12 Sep 2000 09:45:42 -0700 (PDT) Date: Tue, 12 Sep 2000 09:45:42 -0700 (PDT) From: Randy Presuhn Message-Id: <200009121645.JAA27863@dorothy.bmc.com> To: snmpconf@snmp.com Subject: Schedule MIB enhancements (Was: Re: snmpconf Interim Meeting Notes Day Two) Cc: disman@dorothy.peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id e8CGkeO22503 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09011 Hi - > Date: Tue, 12 Sep 2000 17:45:10 +0200 > Message-Id: <200009121545.RAA26326@henkell.ibr.cs.tu-bs.de> > From: Juergen Schoenwaelder > To: snmpconf@snmp.com > CC: DISMAN Mailing List > In-reply-to: <200009072237.SAA29818@aix43.snmp.com> (message from Steve > Moulton on Thu, 07 Sep 2000 18:37:50 -0400) > Subject: Re: snmpconf Interim Meeting Notes Day Two > References: <200009072237.SAA29818@aix43.snmp.com> ... > From reading the snmpconf minutes, I do not understand what your > proposed change actually looks like. So please come up with some more > details quickly and please get the DISMAN WG involved by CC'ing them > or moving discussion of the proposed scheduling MIB change to the > DISMAN list itself. ... If there are to be proposed changes to the schedule MIB, please make those proposals NOW. The WG last call on this document was to have ended months ago, and it's just been a matter of editor availability that's kept this from being handed to the AD for presentation to the IESG. If changes are necessary, please spell them out now. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Tue Sep 12 13:18:57 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09912 for ; Tue, 12 Sep 2000 13:18:56 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8CHFFa28336; Tue, 12 Sep 2000 12:15:16 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA29098 for disman-list; Tue, 12 Sep 2000 10:13:33 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA28980 for ; Tue, 12 Sep 2000 10:13:23 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8CHDKJ27889 for ; Tue, 12 Sep 2000 12:13:21 -0500 (CDT) Received: from [24.128.60.156] (h0050e460d16d.ne.mediaone.net [24.128.60.156]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id NAA03728; Tue, 12 Sep 2000 13:13:32 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 12 Sep 2000 13:16:54 -0400 Subject: Re: Schedule MIB enhancements (Was: Re: snmpconf Interim Meeting Notes Day Two) From: Jon Saperia To: CC: Message-ID: In-Reply-To: <200009121645.JAA27863@dorothy.bmc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit on 09/12/2000 12:45 PM, Randy Presuhn at rpresuhn@dorothy.peer.com wrote: > If there are to be proposed changes to the schedule MIB, please > make those proposals NOW. The WG last call on this document was > to have ended months ago, and it's just been a matter of editor > availability that's kept this from being handed to the AD for > presentation to the IESG. If changes are necessary, please > spell them out now. Randy and Juergen, Hongal had been pursuing this issue and we talked a bit about it at the IETF meeting. I do not think there is consensus yet. From the posted minutes, there were the following relevant points: > . When using the schedule MIB, you would need to create a MIB entry > that would point back to the entry that would be started. > Actually you would need two entries in the schedule MIB one for starting > (setting the admin status to enable) and one for stopping > (setting the admin status to disable). We may be able > to add an augments clause to the schedule MIB to pack the > information into one entry. > > . One needs to make sure that the forward and backward pointers > stay in sync. To do this, there should be a one-to-one pairing. > Have two schedule entries pointing to one ifAdminStatus would be > difficult to maintain. > > . If we use the schedule MIB, we need to bear in mind that it has > up to one minute latency after one presses the go button. > > In summary, we are talking about augmenting the schedule MIB so > that we have the start and stop times rather than having multiple > entries. This is a proposed change. You will note from David Partain's note that he is organizing our list of issues and actions. I can ask that we get to this ASAP by can not promise a specific resolution in a specific time. That said, we have the following choices. If time pressure makes it right to move forward with the Schedule MIB then, we will have to work out some other solution. If it is possible to wait until we conclude our interim meeting and post to the mail list, then we might get good input to your effort. Folks, Randy and Juergen have a point about the disman work. When we bring these topics up on this [snmpconf] list we should be sure to cross post them to the disman group. Thanks /jon From owner-disman@dorothy.peer.com Wed Sep 13 04:04:49 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02896 for ; Wed, 13 Sep 2000 04:04:49 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8D81i112238; Wed, 13 Sep 2000 03:01:44 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA16616 for disman-list; Wed, 13 Sep 2000 00:59:13 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA16611 for ; Wed, 13 Sep 2000 00:59:09 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8D7x5H11708 for ; Wed, 13 Sep 2000 02:59:05 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id JAA17266; Wed, 13 Sep 2000 09:59:54 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA15426; Wed, 13 Sep 2000 09:59:53 +0200 Date: Wed, 13 Sep 2000 09:59:53 +0200 Message-Id: <200009130759.JAA15426@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com, disman@dorothy.peer.com In-reply-to: (message from Jon Saperia on Tue, 12 Sep 2000 13:16:54 -0400) Subject: Re: Schedule MIB enhancements (Was: Re: snmpconf Interim Meeting Notes Day Two) References: Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Jon Saperia writes: Jon> Folks, Randy and Juergen have a point about the disman work. When Jon> we bring these topics up on this [snmpconf] list we should be Jon> sure to cross post them to the disman group. I am not really a big fan of extensive cross postings (since I happen to be on both lists anyway). I think a few cross posts to tell people on which list a certain issue is handled is more appropriate. It might be helpful if the chairs of the WGs can actually negotiate how the WGs can best cooperate. For example, if the snmpconf folks can formulate a clear requirement what they need from the schedule MIB, then the disman folks may be able to provide a solution without extensive cross postings in both WG mailing lists. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Wed Sep 13 08:01:10 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05458 for ; Wed, 13 Sep 2000 08:01:10 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8DBwIP10012; Wed, 13 Sep 2000 06:58:18 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA17001 for disman-list; Wed, 13 Sep 2000 04:56:10 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA16996 for ; Wed, 13 Sep 2000 04:56:06 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8DBu3309788 for ; Wed, 13 Sep 2000 06:56:03 -0500 (CDT) Received: from [24.128.60.156] (h0050e460d16d.ne.mediaone.net [24.128.60.156]) by chmls06.mediaone.net (8.8.7/8.8.7) with ESMTP id HAA16839; Wed, 13 Sep 2000 07:56:21 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 13 Sep 2000 07:59:46 -0400 Subject: Re: Schedule MIB enhancements (Was: Re: snmpconf Interim Meeting Notes Day Two) From: Jon Saperia To: CC: Message-ID: In-Reply-To: <200009130759.JAA15426@henkell.ibr.cs.tu-bs.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit on 09/13/2000 3:59 AM, Juergen Schoenwaelder at schoenw@ibr.cs.tu-bs.de wrote: > It might be helpful if the chairs of the WGs can actually negotiate > how the WGs can best cooperate. For example, if the snmpconf folks can > formulate a clear requirement what they need from the schedule MIB, > then the disman folks may be able to provide a solution without > extensive cross postings in both WG mailing lists. > > /js Juergen, I think this is an excellent idea and good way to collect the input for this one. David Partain and I talked about this and would like to propose that the SNMNPCONF WG give you a short set of requirements bullets and a set of ideas about how we could use the schedule MIB with some changes. I will send out a separate note starting this off. /jon From owner-disman@dorothy.peer.com Wed Sep 13 09:36:58 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07829 for ; Wed, 13 Sep 2000 09:36:57 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8DDXuc25380; Wed, 13 Sep 2000 08:33:56 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA17234 for disman-list; Wed, 13 Sep 2000 06:31:22 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA17228; Wed, 13 Sep 2000 06:31:17 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8DDVDP24835; Wed, 13 Sep 2000 08:31:13 -0500 (CDT) Received: from bnatale.acecomm.com (dhcppm9.acec.com [38.249.211.231]) by relay1.acec.com (8.9.3/8.9.3) with ESMTP id JAA15697; Wed, 13 Sep 2000 09:34:24 -0400 (EDT) Message-Id: <5.0.0.25.2.20000913093047.00ac1fc8@plymouth.acec.com> X-Sender: bnatale@plymouth.acec.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 13 Sep 2000 09:32:51 -0400 To: Randy Presuhn From: Bob Natale Subject: Re: "silent" removal from WG mailing list Cc: disman@dorothy.peer.com, agentx@dorothy.peer.com In-Reply-To: <200009121633.JAA27747@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list At 9/12/2000:12:33 PM, Randy Presuhn wrote: Hi Randy, >Any suggestions for what the (disman, agentx) mailing >list administrator should do in cases like the attached? Whatever good-faith fair action involves the least disruption on the list admin's (your!) time. >When traffic bounces, I attempt to notify the postmaster of the >relevant domain in order to let them know what's happening. >When I drop a subscriber due to bounces, I also notify that >domain's postmaster and the WG chair. In cases like this, >where mail for a domain's postmaster bounces, is there any >further course of action that would be worthwhile? I don't think so. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From owner-disman@dorothy.peer.com Thu Sep 14 14:51:33 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20504 for ; Thu, 14 Sep 2000 14:51:33 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8EIhUT06023; Thu, 14 Sep 2000 13:43:30 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA21065 for disman-list; Thu, 14 Sep 2000 10:53:01 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA21057 for disman@dorothy.bmc.com; Thu, 14 Sep 2000 10:52:57 -0700 (PDT) Date: Thu, 14 Sep 2000 10:52:57 -0700 (PDT) From: Randy Presuhn Message-Id: <200009141752.KAA21057@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: nlmLogEngineAddress is broken Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id e8EIhUT06023 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA20504 Hi - As disman working group chair, I'm notifying the WG of a problem and a proposed path forward. Just when we thought it was almost finished, the IESG review of draft-ietf-disman-notif-log-mib-16.txt has revealed a problem, and the document has been tossed back to the working group for repair. History: The object nlmLogEngineAddress was added to the nlmLogTable in December 1999. This object has a syntax of IpAddress. The Problem: IESG review frowns on things which are unnecessarily IPv4-specific. This object's description, as well as the original arguments presented for its addition, make it clear that this object has no requirement to be IPv4-specific. The Proposed Solution: a) add RFC 2851 to the references. b) add IMPORTs for InetAddressType and InetAddress from the MIB in RFC 2851. c) add a new object to the nlmLogTable, nlmLogEngineAddressType, with syntax InetAddressType, and a DESCRIPTION describing its relationship to nlmLogEngineAddress as required by RFC 2851. d) change the syntax of the nlmLogEngineAddress object to InetAddress, updating the DESCRIPTION accordingly with an explanation of its relationship to nlmLogEngineAddressType as required by RFC 2851. e) add nlmLogEngineAddressType to the notificationLogLogGroup. f) any other typographical fixes the editor encounters or has on file. The Process: 1) If you have a problem with this, please speak up NOW. If no objections are posted to this list by September 20, we will procede to the next step. If this deadline is too short and you plan to submit comments, please let me know so that the deadline can be extended to accomodate. 2) During this time, the editor will prepare an updated document. The concrete changes will be posted to the disman working group mailing list as early as is practical. 3) In the absence of objects, the editor will submit the updated document to internet-drafts@ietf.org as soon as possible after September 20. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Thu Sep 14 17:48:48 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26049 for ; Thu, 14 Sep 2000 17:48:48 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8ELiqa13379; Thu, 14 Sep 2000 16:44:52 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA23464 for disman-list; Thu, 14 Sep 2000 14:41:33 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA23458; Thu, 14 Sep 2000 14:41:28 -0700 (PDT) Date: Thu, 14 Sep 2000 14:41:28 -0700 (PDT) From: Randy Presuhn Message-Id: <200009142141.OAA23458@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Fwd: snmpconf Schedule Requirements Cc: hongal@riverstonenet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id e8ELiqa13379 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA26049 Hi - I'm forwarding a post from hongal@riverstonenet.com regarding the snmpconf schedule requirements. I've added hongal@riverstonenet.com to the disman list's "posters" list so that his subsequent posts from that address don't bounce. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- > Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA22994 > for ; Thu, 14 Sep 2000 13:59:40 -0700 (PDT) > Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8EKxXM03211 > for ; Thu, 14 Sep 2000 15:59:34 -0500 (CDT) > Received: from riverstonenet.com by riverstonenet.com (8.8.8+Sun/SMI-SVR4-Yago) > id NAA23468; Thu, 14 Sep 2000 13:57:12 -0700 (PDT) > Message-ID: <39C12367.10B285FF@riverstonenet.com> > Date: Thu, 14 Sep 2000 14:13:43 -0500 > From: Thippanna Hongal > Organization: Riverstone Network Inc. > X-Mailer: Mozilla 4.7 [en] (WinNT; I) > X-Accept-Language: en,Kannada > MIME-Version: 1.0 > To: snmpconf , > "disman@dorothy.peer.com" > Subject: snmpconf Schedule Requirements > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > hi all > > Here is the list of requirement I did compile > to associate time with the policies. > thanks > hongal > > Riverstone Networks Inc,. Santa Clara CA, U.S.A > ---------------------------------------------------------- > SNMP Policy Configuration Schedule Requirements. > > I. Schedule policy execution based on specific start times and running > to > completion. (believe current Schedule MIB does this for us ) > > II. Schedule policy to be active for a duration and then end based on > filter > or action conditions or duration expiration. It is the duration > expiration > that is problematic for the Schedule MIB Module. > > Here follows what we need, so that we can achieve it using and > AUGMENTing > schedule MIB.. > > > 1. The AUGMENTation required for schedule mib of rfc 2591, > to support start and end time of day. > > Requirement a: A field which will say the start time and end time. > The time can use HHMMSS:HHMMSS with the first part > of time representing the start time and the last part > representing the end time. > > Syntax: > 1. The syntax can be HHMMSS:HHMMSS > 2. we can use the 'TIME' convention defined in rfc2445.txt > 3. TDB > > The current schedHour and schedMinute fields are masks > and will permit multiple hours and times and leads to > confusion to use for this purpose. > > > Field 'schedTimeOfDay' with > syntax for string format : HHMMSS:HHMMSS > > > Requirement b: A field which will specify the overall Date and > Time > during which the policy is valid. Its basically a > range of calendar Date and Time > > > The further details on syntax: TDB > Syntax: > 1. This filed can take a syntax of > 'yyyymmddThhmmss/yyyymmddThhmmss' > 2. we can use the 'DATE-TIME' convention defined in rfc2445.txt > 3. TDB > > Field 'schedValidDate' > > Requirement c: A field which will distinguish the time > specified is local time or UTC time. > > The field can take enumerated numbers like, localTime(1), > utcTime(2). > Essentially I propose a field 'schedTimeType' > > Requirement d: Since we have two events, one is the start and > another is end > clearly specified in the schedTimeOfDay, we have > to specify > what is the 'schedValue' to be set during 'start' > and during 'end' times. > > schedStartValue INTEGER > schedEndValue INTEGER > > More Details:TDB > > Requirement e: 'schedType' : > We need a new schedule type : schedType = policy(4) > > This type of schedule specifies that the schedule is of 'level > trigger' type, > meaning it has both start time and end time, and their respective > value to > set. > > > The objects schedValue, > schedHour and > schedMinute > are not used when the schedType == 'policy'. > > Instead the new objects > schedTimeOfDay, > schedValidDate, > schedTimeType, > schedStartValue, > schedEndValue > are used. > > Requirement f: schedType = policyDuration(5) > > This new type is required to schedule policies based on duration. > > The schedInterval is the existing field in the schedule mib which > represents the duration in seconds, > > Objects that are not used > calendar objects: > (schedHour,schedMinute,schedMonth,schedWeekDay,schedDay) > schedValue > > Object that are new and used > schedStartValue > schedEndValue > schedInterval > > This is one time operation, which starts when the policy is enabled > and continues to be in the enabled state until the end of the > duration specified. > > > 2. To put everything together > > the AUGMENTed table has to have > schedTimeOfDay > schedValidDate > schedTimeType > schedStartValue > schedEndValue > > with additional schedType{policy(4),policy-periodic(5)}, > and more descriptions on how it works. > > 3. With this proposal > we can do a complex scheduling where we can specify the overall date > and time > with exact TimeOfDay at which policy has to start and end. With > masks schedMonth,schedWeekDay,schedDay for sched MIB which allows > multiple > entries in it. > > We can do a schedule for example : ' 7days and 4 weeks' > Having said this, we have all the advanced features the scheduler > MIB has. > > > 4. This model is similar to Policy Framework Group model of > policyTimePeriodConditionAuxClass, except for the policyDuration > type or schedule. > > > END > > From owner-disman@dorothy.peer.com Fri Sep 15 05:22:29 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16738 for ; Fri, 15 Sep 2000 05:22:29 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8F9FoK11415; Fri, 15 Sep 2000 04:15:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA02244 for disman-list; Fri, 15 Sep 2000 02:13:20 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA02238; Fri, 15 Sep 2000 02:13:17 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8F9DCI11106; Fri, 15 Sep 2000 04:13:12 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id LAA08984; Fri, 15 Sep 2000 11:14:02 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id LAA15870; Fri, 15 Sep 2000 11:14:01 +0200 Date: Fri, 15 Sep 2000 11:14:01 +0200 Message-Id: <200009150914.LAA15870@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: disman@dorothy.peer.com In-reply-to: <200009141752.KAA21057@dorothy.bmc.com> (message from Randy Presuhn on Thu, 14 Sep 2000 10:52:57 -0700 (PDT)) Subject: Re: nlmLogEngineAddress is broken References: <200009141752.KAA21057@dorothy.bmc.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Randy Presuhn writes: Randy> The Proposed Solution: [...] Randy> c) add a new object to the nlmLogTable, Randy> nlmLogEngineAddressType, with syntax InetAddressType, and a Randy> DESCRIPTION describing its relationship to nlmLogEngineAddress Randy> as required by RFC 2851. Can you please explain the rationale for using IP network layer address rather than transport layer address (aka TDomain/TAddress), which would IMHO be more consistent with SNMP transport mappings in general? What happens if I use SNMPv1 over IPX? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Fri Sep 15 08:53:37 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18990 for ; Fri, 15 Sep 2000 08:53:37 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8FClFa09339; Fri, 15 Sep 2000 07:47:15 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA02578 for disman-list; Fri, 15 Sep 2000 05:44:23 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA02573 for ; Fri, 15 Sep 2000 05:44:19 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8FCiEs08745 for ; Fri, 15 Sep 2000 07:44:14 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id OAA23139; Fri, 15 Sep 2000 14:45:04 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA19761; Fri, 15 Sep 2000 14:45:03 +0200 Date: Fri, 15 Sep 2000 14:45:03 +0200 Message-Id: <200009151245.OAA19761@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com, disman@dorothy.peer.com In-reply-to: <39C12367.10B285FF@riverstonenet.com> (message from Thippanna Hongal on Thu, 14 Sep 2000 14:13:43 -0500) Subject: Re: snmpconf Schedule Requirements References: <39C12367.10B285FF@riverstonenet.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Thippanna Hongal writes: Thippanna> Here is the list of requirement I did compile to associate Thippanna> time with the policies. Thanks for posting this summary. Let me try to rephrase your requirements to see whether I did understand you correctly: The requirement is to support two additional scheduling types. Both new scheduling types schedule time intervals, which means they create a set operation at the beginning of a time interval and at the end of the time interval. It is sufficient if the sets triggered by the scheduler modifies the same integer variable. However, it is necessary to be able to set two different values at the start and the end of the time interval. The first new scheduling type (A) specifies the time interval based on calendar time. The second new scheduling type (B) specifies the start point based on calendar time and the duration of the time interval. (Well, you actually wrote in your email that the second starts immediately when something (the schedTable entry?) is enabled and runs for the duration specified, but the proposed solution you described is not really consistent with this. Anyway, I will call this variation (B').) Is that summary of the requirements correct so far? Now lets look what we have right now in RFC 2591. I believe you can realize all schedules described above as follows with RFC 2591: (A) You create two oneshot schedules in the schedTable, one for the start time and one for the end time. (B) Similar to (A), you create two oneshot schedules in the schedTable, one for the start time and one for the end time. You simply let the manager calculate the end time by adding the time interval to the start time. (B') You generate a single oneshot schedule for the end time and once the manager has calculated the end time based on the current time. (An alternative would be a very slight modification to add a new scheduling type which is basically a periodic schedule which disables itself after the first scheduled event.) Now, from looking at the proposed solution, it looks like you are for some reason uncomfortable with what I have described above. Is it possible to clearly describe why the solutions outlined above do not work or are way too ugly in the snmpconf context? Can you provide examples to demonstrate your points? [There are many issues I have with the proposed solutions. But before discussing this in detail, I would first like to better understand what the problem really is. Maybe there are other solutions that fit better into the design of the current scheduler.] /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Fri Sep 15 12:32:45 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22214 for ; Fri, 15 Sep 2000 12:32:45 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8FGTNw28430; Fri, 15 Sep 2000 11:29:23 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA02931 for disman-list; Fri, 15 Sep 2000 09:28:28 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA02925 for disman@dorothy.bmc.com; Fri, 15 Sep 2000 09:28:24 -0700 (PDT) Date: Fri, 15 Sep 2000 09:28:24 -0700 (PDT) From: Randy Presuhn Message-Id: <200009151628.JAA02925@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: nlmLogEngineAddress is broken Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id e8FGTNw28430 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA22214 Hi - > Date: Fri, 15 Sep 2000 11:14:01 +0200 > Message-Id: <200009150914.LAA15870@henkell.ibr.cs.tu-bs.de> > From: Juergen Schoenwaelder > To: rpresuhn@dorothy.bmc.com > CC: disman@dorothy.bmc.com > In-reply-to: <200009141752.KAA21057@dorothy.bmc.com> (message from Randy > Presuhn on Thu, 14 Sep 2000 10:52:57 -0700 (PDT)) > Subject: Re: nlmLogEngineAddress is broken > References: <200009141752.KAA21057@dorothy.bmc.com> ... > Can you please explain the rationale for using IP network layer > address rather than transport layer address (aka TDomain/TAddress), This was the solution suggested by the reviewer. > which would IMHO be more consistent with SNMP transport mappings in > general? What happens if I use SNMPv1 over IPX? ... What's there now doesn't work for IPX. If the IESG needs IPX support as well, then we should ignore RFC 2851 and use something else. I'd question whether TAddress would be the right thing, since it usually includes port information, which would be misleading for many notification sources. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Fri Sep 15 12:50:32 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22443 for ; Fri, 15 Sep 2000 12:50:32 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8FGm7t02118; Fri, 15 Sep 2000 11:48:07 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA03223 for disman-list; Fri, 15 Sep 2000 09:47:51 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA03216 for ; Fri, 15 Sep 2000 09:47:46 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8FGlfI02027 for ; Fri, 15 Sep 2000 11:47:41 -0500 (CDT) Received: from riverstonenet.com by riverstonenet.com (8.8.8+Sun/SMI-SVR4-Yago) id JAA12901; Fri, 15 Sep 2000 09:45:14 -0700 (PDT) Message-ID: <39C2540C.FB1E280@riverstonenet.com> Date: Fri, 15 Sep 2000 09:53:32 -0700 From: Thippanna Hongal X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: snmpconf@snmp.com CC: disman@dorothy.peer.com Subject: Re: snmpconf Schedule Requirements References: <39C12367.10B285FF@riverstonenet.com> <200009151245.OAA19761@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > >>>>> Thippanna Hongal writes: > > Thippanna> Here is the list of requirement I did compile to associate > Thippanna> time with the policies. > > Thanks for posting this summary. Let me try to rephrase your > requirements to see whether I did understand you correctly: > > The requirement is to support two additional scheduling types. Both > new scheduling types schedule time intervals, which means they create > a set operation at the beginning of a time interval and at the end of > the time interval. The scheduler will operate in the startDateAndTime , and endDateAndTime. It triggers events at StartTime and at EndTime as specified in the schedTimeOfDay and uses masks schedMonth,schedDay, schedDayOfWeek enabling multiple schedules in the selected range of Dates. The picture shown will give better picture what I have in mind. 1. as understood startDateAndTime endDateAndTime |--------------------------------------------------------| T T. 2.as required startDateAndTime endDateAndTime |---|--|---d1---|--|---d2---|--|---d3---|--|---d4---|--|---| T T' T T' T T' T T' T T' T- Trigger indicating the Start of policy T' - Trigger indicating the End of Policy dn- Day n, n = 0..31 > It is sufficient if the sets triggered by the > scheduler modifies the same integer variable. However, it is necessary > to be able to set two different values at the start and the end of the > time interval. > > The first new scheduling type (A) specifies the time interval based on > calendar time. The second new scheduling type (B) specifies the start > point based on calendar time and the duration of the time interval. > > (Well, you actually wrote in your email that the second starts > immediately when something (the schedTable entry?) is enabled and runs > for the duration specified, but the proposed solution you described is > not really consistent with this. Anyway, I will call this variation > (B').) I mean the periodic scheduler time tick start as soon as the schedTable entry is enabled. I have no plans to associate this with Calendar Entry to start with. I am exactly looking for: B' > (An alternative would be a very slight modification to add > a new scheduling type which is basically a periodic schedule > which disables itself after the first scheduled event.) I will again look into the proposed solution, if I need to fix it. > > > Is that summary of the requirements correct so far? > > Now lets look what we have right now in RFC 2591. I believe you can > realize all schedules described above as follows with RFC 2591: > > (A) You create two oneshot schedules in the schedTable, one for > the start time and one for the end time. > > (B) Similar to (A), you create two oneshot schedules in the > schedTable, one for the start time and one for the end time. You > simply let the manager calculate the end time by adding the time > interval to the start time. > > (B') You generate a single oneshot schedule for the end time and once > the manager has calculated the end time based on the current > time. (An alternative would be a very slight modification to add > a new scheduling type which is basically a periodic schedule > which disables itself after the first scheduled event.) > > Now, from looking at the proposed solution, it looks like you are for > some reason uncomfortable with what I have described above. Is it > possible to clearly describe why the solutions outlined above do not > work or are way too ugly in the snmpconf context? Can you provide > examples to demonstrate your points? > > [There are many issues I have with the proposed solutions. But before > discussing this in detail, I would first like to better understand > what the problem really is. Maybe there are other solutions that fit > better into the design of the current scheduler.] > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Fri Sep 15 14:13:20 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23372 for ; Fri, 15 Sep 2000 14:13:20 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8FI9WO17040; Fri, 15 Sep 2000 13:09:32 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA19355 for disman-list; Fri, 15 Sep 2000 11:05:48 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA19349; Fri, 15 Sep 2000 11:05:43 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8FI5WA16328; Fri, 15 Sep 2000 13:05:32 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id UAA12853; Fri, 15 Sep 2000 20:06:18 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id UAA25831; Fri, 15 Sep 2000 20:06:09 +0200 Date: Fri, 15 Sep 2000 20:06:09 +0200 Message-Id: <200009151806.UAA25831@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: disman@dorothy.peer.com In-reply-to: <200009151628.JAA02925@dorothy.bmc.com> (message from Randy Presuhn on Fri, 15 Sep 2000 09:28:24 -0700 (PDT)) Subject: Re: nlmLogEngineAddress is broken References: <200009151628.JAA02925@dorothy.bmc.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Randy Presuhn writes: >> which would IMHO be more consistent with SNMP transport mappings in >> general? What happens if I use SNMPv1 over IPX? Randy> What's there now doesn't work for IPX. Yes - but is this an argument not to fix it? Randy> If the IESG needs IPX support as well, then we should ignore Randy> RFC 2851 and use something else. I'd question whether TAddress Randy> would be the right thing, since it usually includes port Randy> information, which would be misleading for many notification Randy> sources. TAddress still includes the IP address. So its up to the application to ignore the port if it likes to. If we stick to InetAddress, then we dictate that all application reading the log have to ignore the port. (Which fits well into the SNMP philosophy, doesn't it? ;-) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Tue Sep 19 19:01:13 2000 Received: from tattler.bmc.com ([198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26166 for ; Tue, 19 Sep 2000 19:01:13 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8JMrow21573; Tue, 19 Sep 2000 17:53:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA28764 for disman-list; Tue, 19 Sep 2000 15:50:48 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA28758 for disman@dorothy.bmc.com; Tue, 19 Sep 2000 15:50:45 -0700 (PDT) Date: Tue, 19 Sep 2000 15:50:45 -0700 (PDT) From: Randy Presuhn Message-Id: <200009192250.PAA28758@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: nlmLogEngineAddress is broken Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id e8JMrow21573 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26166 Hi - As disman working group chair, based on Jurgen's comments, I propose we resolve the nlmLogEngineAddress issue from the log mib in this way: a) add IMPORTs for TDomain and TAddress from the SNMPv2-TC MIB (RFC 2579). b) add a new object to the nlmLogTable, nlmLogEngineAddressType, with syntax TDomain, and a DESCRIPTION describing its relationship to nlmLogEngineAddress as required by RFC 2579. c) change the syntax of the nlmLogEngineAddress object to TAddress, updating the DESCRIPTION accordingly with an explanation of its relationship to nlmLogEngineAddressType as required by RFC 2579. d) add nlmLogEngineAddressType to the notificationLogLogGroup. e) any other typographical fixes the editor encounters or has on file. The Process: 1) If you have a problem with this, please speak up NOW. If no objections are posted to this list by September 21, we will procede to the next step. If this deadline is too short and you plan to submit comments, please let me know so that the deadline can be extended to accomodate. 2) During this time, the editor will prepare an updated document. The concrete changes will be posted to the disman working group mailing list as early as is practical. 3) In the absence of objections, the editor will submit the updated document to internet-drafts@ietf.org as soon as possible after September 21. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Wed Sep 20 01:49:24 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08211 for ; Wed, 20 Sep 2000 01:49:23 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8K5kOM13541; Wed, 20 Sep 2000 00:46:24 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id WAA26922 for disman-list; Tue, 19 Sep 2000 22:45:39 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA26916; Tue, 19 Sep 2000 22:45:35 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8K5jT413461; Wed, 20 Sep 2000 00:45:29 -0500 (CDT) Received: from cisco.com (sjck-dial-gw5-141.cisco.com [10.19.238.142]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA26598; Tue, 19 Sep 2000 22:46:19 -0700 (PDT) Message-ID: <39C84FB3.BAF2EDAD@cisco.com> Date: Tue, 19 Sep 2000 22:48:35 -0700 From: Ramanathan Kavasseri Reply-To: ramk@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn CC: disman@dorothy.peer.com Subject: Re: nlmLogEngineAddress is broken References: <200009192250.PAA28758@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by sigma.cisco.com id WAA26598 X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.bmc.com id WAA26917 Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id e8K5kOM13541 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA08211 Randy/Juergen, thanks for the clarification - I'll post the updated draft in a few mins. I've changed the draft name to draft-ietf-disman-notif-log-mib-17-edited.txt to indicate that this is is NOT being forwarded to internet-drafts@ietf.org until the changes are approved by the wg. If there's agreement about the changes, I'll rename the draft draft-ietf-disman-notif-log-mib-18.txt and submit that to internet-drafts@ietf.org. Thanks, Ram Randy Presuhn wrote: > > Hi - > > As disman working group chair, based on Jurgen's comments, > I propose we resolve the nlmLogEngineAddress issue from the > log mib in this way: > > a) add IMPORTs for TDomain and TAddress from > the SNMPv2-TC MIB (RFC 2579). > > b) add a new object to the nlmLogTable, > nlmLogEngineAddressType, with syntax TDomain, > and a DESCRIPTION describing its relationship to > nlmLogEngineAddress as required by RFC 2579. > > c) change the syntax of the nlmLogEngineAddress object to > TAddress, updating the DESCRIPTION accordingly > with an explanation of its relationship to > nlmLogEngineAddressType as required by RFC 2579. > > d) add nlmLogEngineAddressType to the notificationLogLogGroup. > > e) any other typographical fixes the editor encounters or > has on file. > > The Process: > > 1) If you have a problem with this, please speak up NOW. > If no objections are posted to this list by September 21, > we will procede to the next step. If this deadline is too > short and you plan to submit comments, please let me know > so that the deadline can be extended to accomodate. > > 2) During this time, the editor will prepare an updated > document. The concrete changes will be posted to > the disman working group mailing list as early as > is practical. > > 3) In the absence of objections, the editor will > submit the updated document to internet-drafts@ietf.org > as soon as possible after September 21. > > ------------------------------------------------------- > Randy Presuhn randy_presuhn@bmc.com > Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 > Fax: +1 408 965-0359 2141 North First Street > http://www.bmc.com/ San José, California 95131 USA > ------------------------------------------------------- > My opinions and BMC's are independent variables. > ------------------------------------------------------- From owner-disman@dorothy.peer.com Wed Sep 20 02:37:47 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15382 for ; Wed, 20 Sep 2000 02:37:46 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8K6XPV19687; Wed, 20 Sep 2000 01:33:25 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA27006 for disman-list; Tue, 19 Sep 2000 23:33:11 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA26999 for ; Tue, 19 Sep 2000 23:32:57 -0700 (PDT) From: ramk@cisco.com Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8K6Wo519596 for ; Wed, 20 Sep 2000 01:32:50 -0500 (CDT) Received: from itech-view5.cisco.com (itech-view5.cisco.com [171.69.63.172]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA27895; Tue, 19 Sep 2000 23:33:42 -0700 (PDT) Received: (ramk@localhost) by itech-view5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA11139; Tue, 19 Sep 2000 22:57:49 -0700 (PDT) Message-Id: <200009200557.WAA11139@itech-view5.cisco.com> Subject: Updated draft of the NOTIFICATION-LOG-MIB To: disman@dorothy.peer.com Date: Tue, 19 Sep 2000 22:57:48 -0700 (PDT) Cc: ramk@cisco.com (Ram Kavasseri) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Please review the latest draft of the notification log mib. It contains the following edits: [Page 1] Reformatted the header so it looks like other disman-wg drafts. Applied Bert's suggestion to reflect current editor/prev author. [Page 1] Updated the copyright notice. [Page 4] Section 3.1.1, para 1. Changed "MUST be modeled as" to "is modeled here as". [Page 8] The various I-D revision caluses should be folded into the "Initial version of the MIB"... [Page 17] Technical change - it was agreed that the value of nlmlogEngineID would be a zero-length string (instead of not being instantiated) for traps in v1 format, or if notifs are recvd from only one engine. Draft updated to reflect this. [Page 17] As requested, nlmLogEngineAddress' DESCRIPTION has been updated, and nlmLogEngineAddressType has been added. Thanks, Ram --------------------------------------------------------------------------- Network Working Group Editor of this version: Internet-Draft Ramanathan R. Kavasseri Expires March 2001 Cisco Systems, Inc. Author of previous version: Bob Stewart 19 September 2000 Notification Log MIB draft-ietf-disman-notif-log-mib-17-edited.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Internet Draft Notification Log MIB 19 September 2000 1. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. Expires 19 March 2001 [Page 2] Internet Draft Notification Log MIB 19 September 2000 A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview Systems that support SNMP often need a mechanism for recording Notification information as a hedge against lost Notifications, whether those are Traps or Informs [RFC1905] that exceed retransmission limits. This MIB therefore provides common infrastructure for other MIBs in the form of a local logging function. It is intended primarily for senders of Notifications but could be used also by receivers. Given the Notification Log MIB, individual MIBs bear less responsibility to record the transient information associated with an event against the possibility that the Notification message is lost, and applications can poll the log to verify that they have not missed important Notifications. 3.1. Environment The overall environmental concerns for the MIB are: o SNMP Engines and Contexts o Security Expires 19 March 2001 [Page 3] Internet Draft Notification Log MIB 19 September 2000 3.1.1. SNMP Engines and Contexts There are two distinct information flows from multiple notification originators that one may log. The first is the notifications that are received (from one or more SNMP engines) for logging as SNMP informs and traps. The other comprises notifications delivered to an SNMP engine at the interface to the notification originator (using a notification mechanism other than SNMP informs or traps). The latter information flow (using a notification mechanism other than SNMP informs or traps) is modeled here as the SNMP engine (which maintains the log) sending a notification to itself. The remainder of this section discusses the handling of the former information flow - notifications (received in the form of SNMP informs or traps) from multiple SNMP engines. As described in the SNMP architecture [RFC2571], a given system may support multiple SNMP engines operating independently of one another, each with its own SNMP engine identification. Furthermore, within the purview of a given engine there may be multiple named management contexts supporting overlapping or disjoint sets of MIB objects and Notifications. Thus, understanding a particular Notification requires knowing the SNMP engine and management context from whence it came. To provide the necessary source information for a logged Notification, the MIB includes objects to record that Notification's source SNMP engine ID and management context name. 3.1.2. Security Security for Notifications is awkward since access control for the objects in the Notification can be checked only where the Notification is created. Thus such checking is possible only for locally-generated Notifications, and even then only when security credentials are available. For the purpose of this discussion, "security credentials" means the input values for the abstract service interface function isAccessAllowed [RFC2571] and using those credentials means conceptually using that function to see that those credentials allow access to the MIB objects in question, operating as for a Notification Originator in [RFC2573]. The Notification Log MIB has the notion of a "named log." By using log names and view-based access control [RFC2575] a network administrator can provide different access for different users. When an application creates a named log the security credentials of the creator stay Expires 19 March 2001 [Page 4] Internet Draft Notification Log MIB 19 September 2000 associated with that log. A managed system with fewer resources MAY disallow the creation of named logs, providing only the default, null-named log. Such a log has no implicit security credentials for Notification object access control and Notifications are put into it with no further checking. When putting locally-generated Notifications into a named log, the managed system MUST use the security credentials associated with that log and MUST apply the same access control rules as described for a Notification Originator in [RFC2573]. The managed system SHOULD NOT apply access control when adding remotely- generated Notifications into either a named log or the default, null- named log. In those cases the security of the information in the log SHOULD be left to the normal, overall access control for the log itself. The Notification Log MIB allows applications to set the maximum number of Notifications that can be logged, using nlmConfigGlobalEntryLimit. Similarly, an application can set the maximum age using nlmConfigGlobalAgeOut, after which older Notifications MAY be timed out. Please be aware that contention between multiple applications trying to set these objects to different values MAY affect the reliability and completeness of data seen by each application, i.e. it is possible that one application may change the value of either of these objects, resulting in some Notifications being deleted before the other applications have had a chance to see them. This could be used to orchestrate a denial-of-service attack. Methods for countering such an attack are for further study. 3.2. Structure The MIB has the following sections: o Configuration -- control over how much the log can hold and what Notifications are to be logged. o Statistics -- indications of logging activity. o Log -- the Notifications themselves. Expires 19 March 2001 [Page 5] Internet Draft Notification Log MIB 19 September 2000 3.2.1. Configuration The configuration section contains objects to manage resource use by the MIB. This section also contains a table to specify what logs exist and how they operate. Deciding which Notifications are to be logged depends on filters defined in the the snmpNotifyFilterTable in the standard SNMP Notification MIB [RFC2573] identified by the initial index (snmpNotifyFilterName) from that table. 3.2.2. Statistics The statistics section contains counters for Notifications logged and discarded, supplying a means to understand the results of log capacity configuration and resource problems. 3.2.3. Log The log contains the Notifications and the objects that came in their variable binding list, indexed by an integer that reflects when the entry was made. An application that wants to collect all logged Notifications or to know if it may have missed any can keep track of the highest index it has retrieved and start from there on its next poll, checking sysUpTime for a discontinuity that would have reset the index and perhaps have lost entries. Variables are in a table indexed by Notification index and variable index within that Notification. The values are kept as a "discriminated union," with one value object per variable. Exactly which value object is instantiated depends on the SNMP data type of the variable, with a separate object of appropriate type for each distinct SNMP data type. An application can thus reconstruct the information from the Notification PDU from what is recorded in the log. 3.3. Example Following is an example configuration of a named log for logging only linkUp and linkDown Notifications. In nlmConfigLogTable: Expires 19 March 2001 [Page 6] Internet Draft Notification Log MIB 19 September 2000 nlmConfigLogFilterName.5."links" = "link-status" nlmConfigLogEntryLimit.5."links" = 0 nlmConfigLogAdminStatus.5."links" = enabled nlmConfigLogOperStatus.5."links" = operational nlmConfigLogStorageType.5."links" = nonVolatile nlmConfigLogEntryStatus.5."links" = active Note that snmpTraps is: iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5 Or numerically: 1.3.6.1.6.3.1.1.5 And linkDown is snmpTraps.3 and linkUp is snmpTraps.4. So to allow the two Notifications in snmpNotifyFilterTable: snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.3 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.3 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.3 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.3 = active snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.4 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.4 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.4 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.4 = active Expires 19 March 2001 [Page 7] Internet Draft Notification Log MIB 19 September 2000 4. Definitions NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, TimeTicks, Counter32, Counter64, IpAddress, Opaque, mib-2 FROM SNMPv2-SMI TimeStamp, DateAndTime, StorageType, RowStatus, TAddress, TDomain FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; notificationLogMIB MODULE-IDENTITY LAST-UPDATED "200009190000Z" -- 19 September 2000 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 527 2446 Email: ramk@cisco.com" DESCRIPTION "The MIB module for logging SNMP Notifications, that is, Traps and Informs." -- Revision History REVISION "200009190000Z" -- 19 September 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC xxxx" ::= { mib-2 xx } -- final assignment by IANA at publication time notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section -- Expires 19 March 2001 [Page 8] Internet Draft Notification Log MIB 19 September 2000 nlmConfigGlobalEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of notification entries that may be held in nlmLogTable for all nlmLogNames added together. A particular setting does not guarantee that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications MUST be discarded to bring the log down to the new limit - thus the value of nlmConfigGlobalEntryLimit MUST take precedence over the values of nlmConfigGlobalAgeOut and nlmConfigLogEntryLimit, even if the Notification being discarded has been present for fewer minutes than the value of nlmConfigGlobalAgeOut, or if the named log has fewer entries than that specified in nlmConfigLogEntryLimit. A value of 0 means no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfig 1 } nlmConfigGlobalAgeOut OBJECT-TYPE SYNTAX Unsigned32 UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of minutes a Notification SHOULD be kept in a log before it is automatically removed. If an application changes the value of nlmConfigGlobalAgeOut, Notifications older than the new time MAY be discarded to meet the new time. A value of 0 means no age out. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." Expires 19 March 2001 [Page 9] Internet Draft Notification Log MIB 19 September 2000 DEFVAL { 1440 } -- 24 hours ::= { nlmConfig 2 } -- -- Basic Log Configuration Table -- nlmConfigLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of logging control entries." ::= { nlmConfig 3 } nlmConfigLogEntry OBJECT-TYPE SYNTAX NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logging control entry. Depending on the entry's storage type entries may be supplied by the system or created and deleted by applications using nlmConfigLogEntryStatus." INDEX { nlmLogName } ::= { nlmConfigLogTable 1 } NlmConfigLogEntry ::= SEQUENCE { nlmLogName SnmpAdminString, nlmConfigLogFilterName SnmpAdminString, nlmConfigLogEntryLimit Unsigned32, nlmConfigLogAdminStatus INTEGER, nlmConfigLogOperStatus INTEGER, nlmConfigLogStorageType StorageType, nlmConfigLogEntryStatus RowStatus } nlmLogName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the log. An implementation may allow multiple named logs, up to some Expires 19 March 2001 [Page 10] Internet Draft Notification Log MIB 19 September 2000 implementation-specific limit (which may be none). A zero-length log name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named logs." ::= { nlmConfigLogEntry 1 } nlmConfigLogFilterName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A value of snmpNotifyFilterProfileName as used as an index into the snmpNotifyFilterTable in the SNMP Notification MIB, specifying the locally or remotely originated Notifications to be filtered out and not logged in this log. A zero-length value or a name that does not identify an existing entry in snmpNotifyFilterTable indicate no Notifications are to be logged in this log." DEFVAL { ''H } ::= { nlmConfigLogEntry 2 } nlmConfigLogEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of notification entries that can be held in nlmLogTable for this named log. A particular setting does not guarantee that that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications are discarded to bring the log down to the new limit. A value of 0 indicates no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfigLogEntry 3 } nlmConfigLogAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } Expires 19 March 2001 [Page 11] Internet Draft Notification Log MIB 19 September 2000 MAX-ACCESS read-create STATUS current DESCRIPTION "Control to enable or disable the log without otherwise disturbing the log's entry. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { enabled } ::= { nlmConfigLogEntry 4 } nlmConfigLogOperStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), operational(2), noFilter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of this log: disabled administratively disabled operational administratively enabled and working noFilter administratively enabled but either nlmConfigLogFilterName is zero length or does not name an existing entry in snmpNotifyFilterTable" ::= { nlmConfigLogEntry 5 } nlmConfigLogStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this conceptual row." ::= { nlmConfigLogEntry 6 } nlmConfigLogEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. Entries may be modified while active. Expires 19 March 2001 [Page 12] Internet Draft Notification Log MIB 19 September 2000 For non-null-named logs, the managed system records the security credentials from the request that sets nlmConfigLogStatus to 'active' and uses that identity to apply access control to the objects in the Notification to decide if that Notification may be logged." ::= { nlmConfigLogEntry 7 } -- -- Statistics Section -- nlmStatsGlobalNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put into the nlmLogTable. This counts a Notification once for each log entry, so a Notification put into multiple logs is counted multiple times." ::= { nlmStats 1 } nlmStatsGlobalNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStats 2 } -- -- Log Statistics Table -- nlmStatsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log statistics entries." ::= { nlmStats 3 } Expires 19 March 2001 [Page 13] Internet Draft Notification Log MIB 19 September 2000 nlmStatsLogEntry OBJECT-TYPE SYNTAX NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log statistics entry." AUGMENTS { nlmConfigLogEntry } ::= { nlmStatsLogTable 1 } NlmStatsLogEntry ::= SEQUENCE { nlmStatsLogNotificationsLogged Counter32, nlmStatsLogNotificationsBumped Counter32 } nlmStatsLogNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put in this named log." ::= { nlmStatsLogEntry 1 } nlmStatsLogNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded from this named log to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStatsLogEntry 2 } -- -- Log Section -- -- -- Log Table -- Expires 19 March 2001 [Page 14] Internet Draft Notification Log MIB 19 September 2000 nlmLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log entries. It is an implementation-specific matter whether entries in this table are preserved across initializations of the management system. In general one would expect that they are not. Note that keeping entries across initializations of the management system leads to some confusion with counters and TimeStamps, since both of those are based on sysUpTime, which resets on management initialization. In this situation, counters apply only after the reset and nlmLogTime for entries made before the reset MUST be set to 0." ::= { nlmLog 1 } nlmLogEntry OBJECT-TYPE SYNTAX NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry. Entries appear in this table when Notifications occur and pass filtering by nlmConfigLogFilterName and access control. They are removed to make way for new entries due to lack of resources or the values of nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, or nlmConfigLogEntryLimit. If adding an entry would exceed nlmConfigGlobalEntryLimit or system resources in general, the oldest entry in any log SHOULD be removed to make room for the new one. If adding an entry would exceed nlmConfigLogEntryLimit the oldest entry in that log SHOULD be removed to make room for the new one. Before the managed system puts a locally-generated Notification into a non-null-named log it assures that the creator of the log has access to the information in the Notification. If not it does not log that Notification in that log." INDEX { nlmLogName, nlmLogIndex } ::= { nlmLogTable 1 } Expires 19 March 2001 [Page 15] Internet Draft Notification Log MIB 19 September 2000 NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogDateAndTime DateAndTime, nlmLogEngineID SnmpEngineID, nlmLogEngineAddress TAddress, nlmLogEngineAddressType TDomain, nlmLogContextEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, nlmLogNotificationID OBJECT IDENTIFIER } nlmLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer for the sole purpose of indexing entries within the named log. When it reaches the maximum value, an extremely unlikely event, the agent wraps the value back to 1." ::= { nlmLogEntry 1 } nlmLogTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the entry was placed in the log. If the entry occurred before the most recent management system initialization this object value MUST be set to zero." ::= { nlmLogEntry 2 } nlmLogDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The local date and time when the entry was logged, instantiated only by systems that have date and time capability." ::= { nlmLogEntry 3 } nlmLogEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only Expires 19 March 2001 [Page 16] Internet Draft Notification Log MIB 19 September 2000 STATUS current DESCRIPTION "The identification of the SNMP engine at which the Notification originated. If the log can contain Notifications from only one engine or the Trap is in SNMPv1 format, this object is a zero-length string." ::= { nlmLogEntry 4 } nlmLogEngineAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport service address of the SNMP engine from which the Notification was received, formatted according to the corresponding value of nlmLogEngineAddressType. This is used to identify the source of an SNMPv1 trap, since an nlmLogEngineId cannot be extracted from the SNMPv1 trap pdu. This object MUST always be instantiated, even if the log can contain Notifications from only one engine. Please be aware that the nlmLogEngineAddress may not uniquely identify the SNMP engine from which the Notification was received. For example, if an SNMP engine uses DHCP or NAT to obtain ip addresses, the address it uses may be shared with other network devices, and hence will not uniquely identify the SNMP engine." ::= { nlmLogEntry 5 } nlmLogEngineAddressType OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the kind of transport service by which a Notification was received from an SNMP engine. nlmLogEngineAddress contains the transport service address of the SNMP engine from which this Notification was received. Possible values for this object are presently found in the Transport Mappings for SNMPv2 document (RFC 1906 [8])." ::= { nlmLogEntry 6 } Expires 19 March 2001 [Page 17] Internet Draft Notification Log MIB 19 September 2000 nlmLogContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "If the Notification was received in a protocol which has a contextEngineID element like SNMPv3, this object has that value. Otherwise its value is a zero-length string." ::= { nlmLogEntry 7 } nlmLogContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the Notification came. For SNMPv1 Traps this is the community string from the Trap." ::= { nlmLogEntry 8 } nlmLogNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifer of the Notification that occurred." ::= { nlmLogEntry 9 } -- -- Log Variable Table -- nlmLogVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with Notification log entries." ::= { nlmLog 2 } nlmLogVariableEntry OBJECT-TYPE SYNTAX NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 19 March 2001 [Page 18] Internet Draft Notification Log MIB 19 September 2000 "A Notification log entry variable. Entries appear in this table when there are variables in the varbind list of a Notification in nlmLogTable." INDEX { nlmLogName, nlmLogIndex, nlmLogVariableIndex } ::= { nlmLogVariableTable 1 } NlmLogVariableEntry ::= SEQUENCE { nlmLogVariableIndex Unsigned32, nlmLogVariableID OBJECT IDENTIFIER, nlmLogVariableValueType INTEGER, nlmLogVariableCounter32Val Counter32, nlmLogVariableUnsigned32Val Unsigned32, nlmLogVariableTimeTicksVal TimeTicks, nlmLogVariableInteger32Val Integer32, nlmLogVariableOctetStringVal OCTET STRING, nlmLogVariableIpAddressVal IpAddress, nlmLogVariableOidVal OBJECT IDENTIFIER, nlmLogVariableCounter64Val Counter64, nlmLogVariableOpaqueVal Opaque } nlmLogVariableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer, starting at 1 for a given nlmLogIndex, for indexing variables within the logged Notification." ::= { nlmLogVariableEntry 1 } nlmLogVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The variable's object identifier." ::= { nlmLogVariableEntry 2 } nlmLogVariableValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8), opaque(9) } MAX-ACCESS read-only Expires 19 March 2001 [Page 19] Internet Draft Notification Log MIB 19 September 2000 STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow must be instantiated, based on this type." ::= { nlmLogVariableEntry 3 } nlmLogVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter32'." ::= { nlmLogVariableEntry 4 } nlmLogVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'unsigned32'." ::= { nlmLogVariableEntry 5 } nlmLogVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'timeTicks'." ::= { nlmLogVariableEntry 6 } nlmLogVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'integer32'." ::= { nlmLogVariableEntry 7 } nlmLogVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'octetString'." ::= { nlmLogVariableEntry 8 } Expires 19 March 2001 [Page 20] Internet Draft Notification Log MIB 19 September 2000 nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'." ::= { nlmLogVariableEntry 9 } nlmLogVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'objectId'." ::= { nlmLogVariableEntry 10 } nlmLogVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter64'." ::= { nlmLogVariableEntry 11 } nlmLogVariableOpaqueVal OBJECT-TYPE SYNTAX Opaque MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'opaque'." ::= { nlmLogVariableEntry 12 } -- -- Conformance -- notificationLogMIBConformance OBJECT IDENTIFIER ::= { notificationLogMIB 3 } notificationLogMIBCompliances OBJECT IDENTIFIER ::= { notificationLogMIBConformance 1 } notificationLogMIBGroups OBJECT IDENTIFIER ::= { notificationLogMIBConformance 2 } -- Compliance Expires 19 March 2001 [Page 21] Internet Draft Notification Log MIB 19 September 2000 notificationLogMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Notification Log MIB." MODULE -- this module MANDATORY-GROUPS { notificationLogConfigGroup, notificationLogStatsGroup, notificationLogLogGroup } OBJECT nlmConfigGlobalEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named logs." GROUP notificationLogDateGroup DESCRIPTION "This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBCompliances 1 } -- Units of Conformance notificationLogConfigGroup OBJECT-GROUP OBJECTS { Expires 19 March 2001 [Page 22] Internet Draft Notification Log MIB 19 September 2000 nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, nlmConfigLogFilterName, nlmConfigLogEntryLimit, nlmConfigLogAdminStatus, nlmConfigLogOperStatus, nlmConfigLogStorageType, nlmConfigLogEntryStatus } STATUS current DESCRIPTION "Notification log configuration management." ::= { notificationLogMIBGroups 1 } notificationLogStatsGroup OBJECT-GROUP OBJECTS { nlmStatsGlobalNotificationsLogged, nlmStatsGlobalNotificationsBumped, nlmStatsLogNotificationsLogged, nlmStatsLogNotificationsBumped } STATUS current DESCRIPTION "Notification log statistics." ::= { notificationLogMIBGroups 2 } notificationLogLogGroup OBJECT-GROUP OBJECTS { nlmLogTime, nlmLogEngineID, nlmLogEngineAddress, nlmLogEngineAddressType, nlmLogContextEngineID, nlmLogContextName, nlmLogNotificationID, nlmLogVariableID, nlmLogVariableValueType, nlmLogVariableCounter32Val, nlmLogVariableUnsigned32Val, nlmLogVariableTimeTicksVal, nlmLogVariableInteger32Val, nlmLogVariableOctetStringVal, nlmLogVariableIpAddressVal, nlmLogVariableOidVal, Expires 19 March 2001 [Page 23] Internet Draft Notification Log MIB 19 September 2000 nlmLogVariableCounter64Val, nlmLogVariableOpaqueVal } STATUS current DESCRIPTION "Notification log data." ::= { notificationLogMIBGroups 3 } notificationLogDateGroup OBJECT-GROUP OBJECTS { nlmLogDateAndTime } STATUS current DESCRIPTION "Conditionally mandatory notification log data. This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBGroups 4 } END Expires 19 March 2001 [Page 24] Internet Draft Notification Log MIB 19 September 2000 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Expires 19 March 2001 [Page 25] Internet Draft Notification Log MIB 19 September 2000 6. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Expires 19 March 2001 [Page 26] Internet Draft Notification Log MIB 19 September 2000 Protocol (SNMPv3)", RFC 2574, April 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1903, January 1996. Expires 19 March 2001 [Page 27] Internet Draft Notification Log MIB 19 September 2000 7. Security Considerations Security issues are discussed in Section 3.1.2. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 Email: ramk@cisco.com Expires 19 March 2001 [Page 28] Internet Draft Notification Log MIB 19 September 2000 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 19 March 2001 [Page 29] Internet Draft Notification Log MIB 19 September 2000 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 3 3.1 Environment ................................................... 3 3.1.1 SNMP Engines and Contexts ................................... 4 3.1.2 Security .................................................... 4 3.2 Structure ..................................................... 5 3.2.1 Configuration ............................................... 6 3.2.2 Statistics .................................................. 6 3.2.3 Log ......................................................... 6 3.3 Example ....................................................... 6 4 Definitions ..................................................... 8 5 Intellectual Property ........................................... 25 6 References ...................................................... 26 7 Security Considerations ......................................... 28 8 Author's Address ................................................ 28 9 Full Copyright Statement ........................................ 29 Expires 19 March 2001 [Page 30] From owner-disman@dorothy.peer.com Wed Sep 20 03:50:42 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16078 for ; Wed, 20 Sep 2000 03:50:41 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8K7llt03401; Wed, 20 Sep 2000 02:47:48 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA27159 for disman-list; Wed, 20 Sep 2000 00:47:08 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA27153; Wed, 20 Sep 2000 00:47:05 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8K7kxn03302; Wed, 20 Sep 2000 02:46:59 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id JAA21026; Wed, 20 Sep 2000 09:47:44 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA02696; Wed, 20 Sep 2000 09:47:44 +0200 Date: Wed, 20 Sep 2000 09:47:44 +0200 Message-Id: <200009200747.JAA02696@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rpresuhn@dorothy.peer.com CC: disman@dorothy.peer.com In-reply-to: <200009192250.PAA28758@dorothy.bmc.com> (message from Randy Presuhn on Tue, 19 Sep 2000 15:50:45 -0700 (PDT)) Subject: Re: nlmLogEngineAddress is broken References: <200009192250.PAA28758@dorothy.bmc.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Randy Presuhn writes: Randy> As disman working group chair, based on Jurgen's comments, I Randy> propose we resolve the nlmLogEngineAddress issue from the log Randy> mib in this way: [...] Sounds good, although I would have called these objects nlmLogEngineTDomain and nlmLogEngineTAddress instead of nlmLogEngineAddressType and nlmLogEngineAddress. Basically because (a) this naming scheme is more consistent with the SNMP-TARGET-MIB and the ENTITY-MIB and (b) because the IANA TAddress document introduces a TAddressType which is an enumeration rather than an OID and using nlmLogEngineAddressType may be a bit confusing down the road. But this is just a suggestion - not an objection. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Wed Sep 20 11:33:17 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25111 for ; Wed, 20 Sep 2000 11:33:17 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8KFT5n26405; Wed, 20 Sep 2000 10:29:05 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA28374 for disman-list; Wed, 20 Sep 2000 08:27:37 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA28368 for disman@dorothy.bmc.com; Wed, 20 Sep 2000 08:27:34 -0700 (PDT) Date: Wed, 20 Sep 2000 08:27:34 -0700 (PDT) From: Randy Presuhn Message-Id: <200009201527.IAA28368@dorothy.bmc.com> To: disman@dorothy.peer.com Subject: Re: nlmLogEngineAddress is broken Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by tattler.bmc.com id e8KFT5n26405 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25111 Hi - > Date: Wed, 20 Sep 2000 09:47:44 +0200 > Message-Id: <200009200747.JAA02696@henkell.ibr.cs.tu-bs.de> > From: Juergen Schoenwaelder > To: rpresuhn@dorothy.bmc.com > CC: disman@dorothy.bmc.com > In-reply-to: <200009192250.PAA28758@dorothy.bmc.com> (message from Randy > Presuhn on Tue, 19 Sep 2000 15:50:45 -0700 (PDT)) > Subject: Re: nlmLogEngineAddress is broken > References: <200009192250.PAA28758@dorothy.bmc.com> ... > Sounds good, although I would have called these objects > nlmLogEngineTDomain and nlmLogEngineTAddress instead of > nlmLogEngineAddressType and nlmLogEngineAddress. > > Basically because (a) this naming scheme is more consistent with the > SNMP-TARGET-MIB and the ENTITY-MIB and (b) because the IANA TAddress > document introduces a TAddressType which is an enumeration rather than > an OID and using nlmLogEngineAddressType may be a bit confusing down > the road. > > But this is just a suggestion - not an objection. ... I have no problem with this suggestion. Ram - when you make this mod, don't forget all the other places in the document (and MIB) where these labels would appear. ------------------------------------------------------- Randy Presuhn randy_presuhn@bmc.com Voice: +1 408 546-1006 BMC Software, Inc. 1-3141 Fax: +1 408 965-0359 2141 North First Street http://www.bmc.com/ San José, California 95131 USA ------------------------------------------------------- My opinions and BMC's are independent variables. ------------------------------------------------------- From owner-disman@dorothy.peer.com Wed Sep 20 15:06:39 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02241 for ; Wed, 20 Sep 2000 15:06:39 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8KIxYX14320; Wed, 20 Sep 2000 13:59:34 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA00794 for disman-list; Wed, 20 Sep 2000 11:58:50 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA00783; Wed, 20 Sep 2000 11:58:46 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8KIwdA14038; Wed, 20 Sep 2000 13:58:39 -0500 (CDT) Received: from cisco.com (dhcp-171-69-66-157.cisco.com [171.69.66.157]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA00943; Wed, 20 Sep 2000 11:59:00 -0700 (PDT) Message-ID: <39C908F3.CDF8A4C6@cisco.com> Date: Wed, 20 Sep 2000 11:58:59 -0700 From: Ram Kavasseri Reply-To: ramk@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: rpresuhn@dorothy.peer.com, disman@dorothy.peer.com Subject: Re: nlmLogEngineAddress is broken References: <200009192250.PAA28758@dorothy.bmc.com> <200009200747.JAA02696@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > > >>>>> Randy Presuhn writes: > > Randy> As disman working group chair, based on Jurgen's comments, I > Randy> propose we resolve the nlmLogEngineAddress issue from the log > Randy> mib in this way: > > [...] > > Sounds good, although I would have called these objects > nlmLogEngineTDomain and nlmLogEngineTAddress instead of > nlmLogEngineAddressType and nlmLogEngineAddress. > > Basically because (a) this naming scheme is more consistent with the > SNMP-TARGET-MIB and the ENTITY-MIB and (b) because the IANA TAddress > document introduces a TAddressType which is an enumeration rather than > an OID and using nlmLogEngineAddressType may be a bit confusing down > the road. > > But this is just a suggestion - not an objection. I like Juergen's suggestion...Any objections to this? Ram > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Thu Sep 21 10:16:51 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06154 for ; Thu, 21 Sep 2000 10:16:50 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8LECRO17538; Thu, 21 Sep 2000 09:12:28 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA24055 for disman-list; Thu, 21 Sep 2000 07:08:09 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA24050 for ; Thu, 21 Sep 2000 07:08:05 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8LE7uf16254 for ; Thu, 21 Sep 2000 09:07:57 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id QAA10350; Thu, 21 Sep 2000 16:08:48 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA08282; Thu, 21 Sep 2000 16:08:48 +0200 Date: Thu, 21 Sep 2000 16:08:48 +0200 Message-Id: <200009211408.QAA08282@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com, disman@dorothy.peer.com In-reply-to: <39C2540C.FB1E280@riverstonenet.com> (message from Thippanna Hongal on Fri, 15 Sep 2000 09:53:32 -0700) Subject: Re: snmpconf Schedule Requirements References: <39C12367.10B285FF@riverstonenet.com> <200009151245.OAA19761@henkell.ibr.cs.tu-bs.de> <39C2540C.FB1E280@riverstonenet.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Thippanna Hongal writes: Thippanna> The scheduler will operate in the startDateAndTime , and Thippanna> endDateAndTime. It triggers events at StartTime and at Thippanna> EndTime as specified in the schedTimeOfDay and uses masks Thippanna> schedMonth,schedDay, schedDayOfWeek enabling multiple Thippanna> schedules in the selected range of Dates. The picture Thippanna> shown will give better picture what I have in mind. [...] Let me check whether I understand what you were saying. You want to have a time interval schedule (defined by a start and an end event) and in addition another time interval schedule which defines the lifetime of the first time interval schedule. In other words, with RFC 2591, you would have two rows, one for the start and one for the end event of the first time interval. You would have four additional rows to turn the first two rows on and off (two rows to turn the other two rows on and two rows to turn the other two rows off). [If there were a mechanism to set multiple variables or to have multiple values, then it would be possible to reduce the total number of rows I think.] /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Fri Sep 22 06:31:55 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04855 for ; Fri, 22 Sep 2000 06:31:55 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8MASMj08148; Fri, 22 Sep 2000 05:28:23 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id DAA02869 for disman-list; Fri, 22 Sep 2000 03:26:22 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id DAA02864 for ; Fri, 22 Sep 2000 03:26:18 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8MAQ9F07872 for ; Fri, 22 Sep 2000 05:26:09 -0500 (CDT) Received: from [63.22.117.100] (1Cust100.tnt6.bos2.da.uu.net [63.22.117.100]) by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id GAA25247; Fri, 22 Sep 2000 06:26:34 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Fri, 22 Sep 2000 06:30:14 -0400 Subject: Re: snmpconf Schedule Requirements From: Jon Saperia To: Juergen Schoenwaelder , CC: Message-ID: In-Reply-To: <200009211408.QAA08282@henkell.ibr.cs.tu-bs.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit on 09/21/2000 10:08 AM, Juergen Schoenwaelder at schoenw@ibr.cs.tu-bs.de wrote: > [If there were a mechanism to set multiple variables or to have > multiple values, then it would be possible to reduce the total > number of rows I think.] Juergen, I do not want to speak for Hongal, but on reading your reply, I too was wondering if we may have ended up with too many rows. Without limiting Hongal's other proposal points I would like to see if we can do a simple duration schedule in one row. Hongal, if you had intended this and I misread, sorry. I see this duration type schedule as having a start time and a duration. Without changing the flexibility of the other items proposed, can we have this simple case? It would have a schedType of duration and a new object, duration would indicate how long the policy was to be in effect. /jon From owner-disman@dorothy.peer.com Fri Sep 22 07:05:44 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05445 for ; Fri, 22 Sep 2000 07:05:44 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8MB2Lu12321; Fri, 22 Sep 2000 06:02:21 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id EAA02931 for disman-list; Fri, 22 Sep 2000 04:01:58 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id EAA02926 for ; Fri, 22 Sep 2000 04:01:54 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8MB1lX12281 for ; Fri, 22 Sep 2000 06:01:47 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id NAA05211; Fri, 22 Sep 2000 13:02:06 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id NAA03987; Fri, 22 Sep 2000 13:02:06 +0200 Date: Fri, 22 Sep 2000 13:02:06 +0200 Message-Id: <200009221102.NAA03987@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: snmpconf@snmp.com CC: snmpconf@snmp.com, disman@dorothy.peer.com In-reply-to: (message from Jon Saperia on Fri, 22 Sep 2000 06:30:14 -0400) Subject: Re: snmpconf Schedule Requirements References: Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> Jon Saperia writes: Jon> Juergen, I do not want to speak for Hongal, but on reading your Jon> reply, I too was wondering if we may have ended up with too many Jon> rows. Jon, I am currently just trying to understand what the additional requirements boil down. I just wanted to figure out what Hongal was asking for, whether it is doable with the current RFC 2591 and what the implications are. Jon> Without limiting Hongal's other proposal points I would like to Jon> see if we can do a simple duration schedule in one row. So your requirements seem to be less than Hongal's requirements. Jon> I see this duration type schedule as having a start time and a Jon> duration. Jon> It would have a schedType of duration and a new object, duration Jon> would indicate how long the policy was to be in effect. I think you also need to have another value which you set on the end of the time interval, right? We probably also need to document the behaviour in some corner cases (e.g. the start time triggers again before the previous start time trigger + duration, or the behaviour in case of time transitions). Jon> Without changing the flexibility of the other items proposed, can Jon> we have this simple case? The DISMAN WG has to make this decision. So please post your thoughts on this proposed RFC 2591 extension. Personally, I am especially interested in the opinion of people who have already implemented RFC 2591. Randy, does it make sense to put out a deadline for people to raise their views so that we actually get to a decision in the near future? /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-disman@dorothy.peer.com Sat Sep 23 09:16:19 2000 Received: from tattler.bmc.com ([198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21398 for ; Sat, 23 Sep 2000 09:16:19 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8NDCH501996; Sat, 23 Sep 2000 08:12:17 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA17150 for disman-list; Sat, 23 Sep 2000 06:09:08 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA17145 for ; Sat, 23 Sep 2000 06:09:05 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8ND8vT01768 for ; Sat, 23 Sep 2000 08:08:57 -0500 (CDT) Received: from [24.128.60.156] (h0050e460d16d.ne.mediaone.net [24.128.60.156]) by chmls20.mediaone.net (8.8.7/8.8.7) with ESMTP id JAA23641; Sat, 23 Sep 2000 09:08:53 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sat, 23 Sep 2000 09:12:35 -0400 Subject: Re: snmpconf Schedule Requirements From: Jon Saperia To: CC: Message-ID: In-Reply-To: <200009221102.NAA03987@henkell.ibr.cs.tu-bs.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit on 09/22/2000 7:02 AM, Juergen Schoenwaelder at schoenw@ibr.cs.tu-bs.de wrote: > >>>>>> Jon Saperia writes: > > Jon> Juergen, I do not want to speak for Hongal, but on reading your > Jon> reply, I too was wondering if we may have ended up with too many > Jon> rows. > > Jon, > > I am currently just trying to understand what the additional > requirements boil down. I just wanted to figure out what Hongal was > asking for, whether it is doable with the current RFC 2591 and what > the implications are. > > Jon> Without limiting Hongal's other proposal points I would like to > Jon> see if we can do a simple duration schedule in one row. > > So your requirements seem to be less than Hongal's requirements. > Please do not interpret it that way at all. I was pointing to one of the requirements that Hongal put forward. Specifically to a schedule that starts at a specified time and runs for a fixed length of length of time. Hongel put forward others that are important as well. I would like to be able to say start at a time and run for 90 mins. Or Under condition A run for 1 hour. I understand these are two different requests. > Jon> I see this duration type schedule as having a start time and a > Jon> duration. > > Jon> It would have a schedType of duration and a new object, duration > Jon> would indicate how long the policy was to be in effect. > > I think you also need to have another value which you set on the end > of the time interval, right? We probably also need to document the > behaviour in some corner cases (e.g. the start time triggers again > before the previous start time trigger + duration, or the behaviour > in case of time transitions). > In the types of schedule that I have described which are a subset of those Hongal proposes, I do not need an end time since that is implicit in duration. My subset should not be interpreted as suggesting Hongals other points are not important, only that I wanted to emphasize issues of particular interest to me. /jon > From owner-disman@dorothy.peer.com Tue Sep 26 22:00:51 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19978 for ; Tue, 26 Sep 2000 22:00:47 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8R1tqY02481; Tue, 26 Sep 2000 20:55:52 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA12308 for disman-list; Tue, 26 Sep 2000 18:52:45 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA12302 for ; Tue, 26 Sep 2000 18:52:30 -0700 (PDT) From: ramk@cisco.com Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8R1qJc02080 for ; Tue, 26 Sep 2000 20:52:19 -0500 (CDT) Received: from wanena1.cisco.com (wanena1.cisco.com [171.69.26.138]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA21961 for ; Tue, 26 Sep 2000 18:53:41 -0700 (PDT) Received: (ramk@localhost) by wanena1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA16202 for disman@dorothy.bmc.com; Tue, 26 Sep 2000 18:53:17 -0700 (PDT) Message-Id: <200009270153.SAA16202@wanena1.cisco.com> Subject: Updated version of draft-ietf-notif-log-mib-17.txt To: disman@dorothy.peer.com Date: Tue, 26 Sep 2000 18:53:16 -0700 (PDT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit As Juergen suggested, I've changed nlmLogEngineAddress and nlmLogEngineAddressType to "nlmLogEngineTAddress" and "nlmLogEngineTDomain" respectively. All occurrences of the above names were corrected in the draft. Please review the new draft, which is included below. As per Bert and Randy's request, I won't submit this draft to internet-drafts@ietf.org until I get the ok to do so. Note that the draft contains the bogus name: "draft-ietf-disman-notif-log-mib-17-edited-ver2.txt" This will be corrected to "draft-ietf-disman-notif-log-mib-18.txt" when I submit the final version to internet-drafts@ietf.org - until then, I need the bogus name to keep track of the revisions that were submitted to disman... Thanks, Ram Network Working Group Editor of this version: Internet-Draft Ramanathan R. Kavasseri Expires March 2001 Cisco Systems, Inc. Author of previous version: Bob Stewart 26 September 2000 Notification Log MIB draft-ietf-disman-notif-log-mib-17-edited-ver2.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Internet Draft Notification Log MIB 26 September 2000 1. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. Expires 26 March 2001 [Page 2] Internet Draft Notification Log MIB 26 September 2000 A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview Systems that support SNMP often need a mechanism for recording Notification information as a hedge against lost Notifications, whether those are Traps or Informs [RFC1905] that exceed retransmission limits. This MIB therefore provides common infrastructure for other MIBs in the form of a local logging function. It is intended primarily for senders of Notifications but could be used also by receivers. Given the Notification Log MIB, individual MIBs bear less responsibility to record the transient information associated with an event against the possibility that the Notification message is lost, and applications can poll the log to verify that they have not missed important Notifications. 3.1. Environment The overall environmental concerns for the MIB are: o SNMP Engines and Contexts o Security Expires 26 March 2001 [Page 3] Internet Draft Notification Log MIB 26 September 2000 3.1.1. SNMP Engines and Contexts There are two distinct information flows from multiple notification originators that one may log. The first is the notifications that are received (from one or more SNMP engines) for logging as SNMP informs and traps. The other comprises notifications delivered to an SNMP engine at the interface to the notification originator (using a notification mechanism other than SNMP informs or traps). The latter information flow (using a notification mechanism other than SNMP informs or traps) is modeled here as the SNMP engine (which maintains the log) sending a notification to itself. The remainder of this section discusses the handling of the former information flow - notifications (received in the form of SNMP informs or traps) from multiple SNMP engines. As described in the SNMP architecture [RFC2571], a given system may support multiple SNMP engines operating independently of one another, each with its own SNMP engine identification. Furthermore, within the purview of a given engine there may be multiple named management contexts supporting overlapping or disjoint sets of MIB objects and Notifications. Thus, understanding a particular Notification requires knowing the SNMP engine and management context from whence it came. To provide the necessary source information for a logged Notification, the MIB includes objects to record that Notification's source SNMP engine ID and management context name. 3.1.2. Security Security for Notifications is awkward since access control for the objects in the Notification can be checked only where the Notification is created. Thus such checking is possible only for locally-generated Notifications, and even then only when security credentials are available. For the purpose of this discussion, "security credentials" means the input values for the abstract service interface function isAccessAllowed [RFC2571] and using those credentials means conceptually using that function to see that those credentials allow access to the MIB objects in question, operating as for a Notification Originator in [RFC2573]. The Notification Log MIB has the notion of a "named log." By using log names and view-based access control [RFC2575] a network administrator can provide different access for different users. When an application creates a named log the security credentials of the creator stay Expires 26 March 2001 [Page 4] Internet Draft Notification Log MIB 26 September 2000 associated with that log. A managed system with fewer resources MAY disallow the creation of named logs, providing only the default, null-named log. Such a log has no implicit security credentials for Notification object access control and Notifications are put into it with no further checking. When putting locally-generated Notifications into a named log, the managed system MUST use the security credentials associated with that log and MUST apply the same access control rules as described for a Notification Originator in [RFC2573]. The managed system SHOULD NOT apply access control when adding remotely- generated Notifications into either a named log or the default, null- named log. In those cases the security of the information in the log SHOULD be left to the normal, overall access control for the log itself. The Notification Log MIB allows applications to set the maximum number of Notifications that can be logged, using nlmConfigGlobalEntryLimit. Similarly, an application can set the maximum age using nlmConfigGlobalAgeOut, after which older Notifications MAY be timed out. Please be aware that contention between multiple applications trying to set these objects to different values MAY affect the reliability and completeness of data seen by each application, i.e. it is possible that one application may change the value of either of these objects, resulting in some Notifications being deleted before the other applications have had a chance to see them. This could be used to orchestrate a denial-of-service attack. Methods for countering such an attack are for further study. 3.2. Structure The MIB has the following sections: o Configuration -- control over how much the log can hold and what Notifications are to be logged. o Statistics -- indications of logging activity. o Log -- the Notifications themselves. Expires 26 March 2001 [Page 5] Internet Draft Notification Log MIB 26 September 2000 3.2.1. Configuration The configuration section contains objects to manage resource use by the MIB. This section also contains a table to specify what logs exist and how they operate. Deciding which Notifications are to be logged depends on filters defined in the the snmpNotifyFilterTable in the standard SNMP Notification MIB [RFC2573] identified by the initial index (snmpNotifyFilterName) from that table. 3.2.2. Statistics The statistics section contains counters for Notifications logged and discarded, supplying a means to understand the results of log capacity configuration and resource problems. 3.2.3. Log The log contains the Notifications and the objects that came in their variable binding list, indexed by an integer that reflects when the entry was made. An application that wants to collect all logged Notifications or to know if it may have missed any can keep track of the highest index it has retrieved and start from there on its next poll, checking sysUpTime for a discontinuity that would have reset the index and perhaps have lost entries. Variables are in a table indexed by Notification index and variable index within that Notification. The values are kept as a "discriminated union," with one value object per variable. Exactly which value object is instantiated depends on the SNMP data type of the variable, with a separate object of appropriate type for each distinct SNMP data type. An application can thus reconstruct the information from the Notification PDU from what is recorded in the log. 3.3. Example Following is an example configuration of a named log for logging only linkUp and linkDown Notifications. In nlmConfigLogTable: Expires 26 March 2001 [Page 6] Internet Draft Notification Log MIB 26 September 2000 nlmConfigLogFilterName.5."links" = "link-status" nlmConfigLogEntryLimit.5."links" = 0 nlmConfigLogAdminStatus.5."links" = enabled nlmConfigLogOperStatus.5."links" = operational nlmConfigLogStorageType.5."links" = nonVolatile nlmConfigLogEntryStatus.5."links" = active Note that snmpTraps is: iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5 Or numerically: 1.3.6.1.6.3.1.1.5 And linkDown is snmpTraps.3 and linkUp is snmpTraps.4. So to allow the two Notifications in snmpNotifyFilterTable: snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.3 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.3 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.3 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.3 = active snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.4 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.4 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.4 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.4 = active Expires 26 March 2001 [Page 7] Internet Draft Notification Log MIB 26 September 2000 4. Definitions NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, TimeTicks, Counter32, Counter64, IpAddress, Opaque, mib-2 FROM SNMPv2-SMI TimeStamp, DateAndTime, StorageType, RowStatus, TAddress, TDomain FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; notificationLogMIB MODULE-IDENTITY LAST-UPDATED "200009260000Z" -- 26 September 2000 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 527 2446 Email: ramk@cisco.com" DESCRIPTION "The MIB module for logging SNMP Notifications, that is, Traps and Informs." -- Revision History REVISION "200009260000Z" -- 26 September 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC xxxx" ::= { mib-2 xx } -- final assignment by IANA at publication time notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section -- Expires 26 March 2001 [Page 8] Internet Draft Notification Log MIB 26 September 2000 nlmConfigGlobalEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of notification entries that may be held in nlmLogTable for all nlmLogNames added together. A particular setting does not guarantee that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications MUST be discarded to bring the log down to the new limit - thus the value of nlmConfigGlobalEntryLimit MUST take precedence over the values of nlmConfigGlobalAgeOut and nlmConfigLogEntryLimit, even if the Notification being discarded has been present for fewer minutes than the value of nlmConfigGlobalAgeOut, or if the named log has fewer entries than that specified in nlmConfigLogEntryLimit. A value of 0 means no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfig 1 } nlmConfigGlobalAgeOut OBJECT-TYPE SYNTAX Unsigned32 UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of minutes a Notification SHOULD be kept in a log before it is automatically removed. If an application changes the value of nlmConfigGlobalAgeOut, Notifications older than the new time MAY be discarded to meet the new time. A value of 0 means no age out. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." Expires 26 March 2001 [Page 9] Internet Draft Notification Log MIB 26 September 2000 DEFVAL { 1440 } -- 24 hours ::= { nlmConfig 2 } -- -- Basic Log Configuration Table -- nlmConfigLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of logging control entries." ::= { nlmConfig 3 } nlmConfigLogEntry OBJECT-TYPE SYNTAX NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logging control entry. Depending on the entry's storage type entries may be supplied by the system or created and deleted by applications using nlmConfigLogEntryStatus." INDEX { nlmLogName } ::= { nlmConfigLogTable 1 } NlmConfigLogEntry ::= SEQUENCE { nlmLogName SnmpAdminString, nlmConfigLogFilterName SnmpAdminString, nlmConfigLogEntryLimit Unsigned32, nlmConfigLogAdminStatus INTEGER, nlmConfigLogOperStatus INTEGER, nlmConfigLogStorageType StorageType, nlmConfigLogEntryStatus RowStatus } nlmLogName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the log. An implementation may allow multiple named logs, up to some Expires 26 March 2001 [Page 10] Internet Draft Notification Log MIB 26 September 2000 implementation-specific limit (which may be none). A zero-length log name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named logs." ::= { nlmConfigLogEntry 1 } nlmConfigLogFilterName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A value of snmpNotifyFilterProfileName as used as an index into the snmpNotifyFilterTable in the SNMP Notification MIB, specifying the locally or remotely originated Notifications to be filtered out and not logged in this log. A zero-length value or a name that does not identify an existing entry in snmpNotifyFilterTable indicate no Notifications are to be logged in this log." DEFVAL { ''H } ::= { nlmConfigLogEntry 2 } nlmConfigLogEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of notification entries that can be held in nlmLogTable for this named log. A particular setting does not guarantee that that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications are discarded to bring the log down to the new limit. A value of 0 indicates no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfigLogEntry 3 } nlmConfigLogAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } Expires 26 March 2001 [Page 11] Internet Draft Notification Log MIB 26 September 2000 MAX-ACCESS read-create STATUS current DESCRIPTION "Control to enable or disable the log without otherwise disturbing the log's entry. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { enabled } ::= { nlmConfigLogEntry 4 } nlmConfigLogOperStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), operational(2), noFilter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of this log: disabled administratively disabled operational administratively enabled and working noFilter administratively enabled but either nlmConfigLogFilterName is zero length or does not name an existing entry in snmpNotifyFilterTable" ::= { nlmConfigLogEntry 5 } nlmConfigLogStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this conceptual row." ::= { nlmConfigLogEntry 6 } nlmConfigLogEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. Entries may be modified while active. Expires 26 March 2001 [Page 12] Internet Draft Notification Log MIB 26 September 2000 For non-null-named logs, the managed system records the security credentials from the request that sets nlmConfigLogStatus to 'active' and uses that identity to apply access control to the objects in the Notification to decide if that Notification may be logged." ::= { nlmConfigLogEntry 7 } -- -- Statistics Section -- nlmStatsGlobalNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put into the nlmLogTable. This counts a Notification once for each log entry, so a Notification put into multiple logs is counted multiple times." ::= { nlmStats 1 } nlmStatsGlobalNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStats 2 } -- -- Log Statistics Table -- nlmStatsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log statistics entries." ::= { nlmStats 3 } Expires 26 March 2001 [Page 13] Internet Draft Notification Log MIB 26 September 2000 nlmStatsLogEntry OBJECT-TYPE SYNTAX NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log statistics entry." AUGMENTS { nlmConfigLogEntry } ::= { nlmStatsLogTable 1 } NlmStatsLogEntry ::= SEQUENCE { nlmStatsLogNotificationsLogged Counter32, nlmStatsLogNotificationsBumped Counter32 } nlmStatsLogNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put in this named log." ::= { nlmStatsLogEntry 1 } nlmStatsLogNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded from this named log to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStatsLogEntry 2 } -- -- Log Section -- -- -- Log Table -- Expires 26 March 2001 [Page 14] Internet Draft Notification Log MIB 26 September 2000 nlmLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log entries. It is an implementation-specific matter whether entries in this table are preserved across initializations of the management system. In general one would expect that they are not. Note that keeping entries across initializations of the management system leads to some confusion with counters and TimeStamps, since both of those are based on sysUpTime, which resets on management initialization. In this situation, counters apply only after the reset and nlmLogTime for entries made before the reset MUST be set to 0." ::= { nlmLog 1 } nlmLogEntry OBJECT-TYPE SYNTAX NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry. Entries appear in this table when Notifications occur and pass filtering by nlmConfigLogFilterName and access control. They are removed to make way for new entries due to lack of resources or the values of nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, or nlmConfigLogEntryLimit. If adding an entry would exceed nlmConfigGlobalEntryLimit or system resources in general, the oldest entry in any log SHOULD be removed to make room for the new one. If adding an entry would exceed nlmConfigLogEntryLimit the oldest entry in that log SHOULD be removed to make room for the new one. Before the managed system puts a locally-generated Notification into a non-null-named log it assures that the creator of the log has access to the information in the Notification. If not it does not log that Notification in that log." INDEX { nlmLogName, nlmLogIndex } ::= { nlmLogTable 1 } Expires 26 March 2001 [Page 15] Internet Draft Notification Log MIB 26 September 2000 NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogDateAndTime DateAndTime, nlmLogEngineID SnmpEngineID, nlmLogEngineTAddress TAddress, nlmLogEngineTDomain TDomain, nlmLogContextEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, nlmLogNotificationID OBJECT IDENTIFIER } nlmLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer for the sole purpose of indexing entries within the named log. When it reaches the maximum value, an extremely unlikely event, the agent wraps the value back to 1." ::= { nlmLogEntry 1 } nlmLogTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the entry was placed in the log. If the entry occurred before the most recent management system initialization this object value MUST be set to zero." ::= { nlmLogEntry 2 } nlmLogDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The local date and time when the entry was logged, instantiated only by systems that have date and time capability." ::= { nlmLogEntry 3 } nlmLogEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only Expires 26 March 2001 [Page 16] Internet Draft Notification Log MIB 26 September 2000 STATUS current DESCRIPTION "The identification of the SNMP engine at which the Notification originated. If the log can contain Notifications from only one engine or the Trap is in SNMPv1 format, this object is a zero-length string." ::= { nlmLogEntry 4 } nlmLogEngineTAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport service address of the SNMP engine from which the Notification was received, formatted according to the corresponding value of nlmLogEngineTDomain. This is used to identify the source of an SNMPv1 trap, since an nlmLogEngineId cannot be extracted from the SNMPv1 trap pdu. This object MUST always be instantiated, even if the log can contain Notifications from only one engine. Please be aware that the nlmLogEngineTAddress may not uniquely identify the SNMP engine from which the Notification was received. For example, if an SNMP engine uses DHCP or NAT to obtain ip addresses, the address it uses may be shared with other network devices, and hence will not uniquely identify the SNMP engine." ::= { nlmLogEntry 5 } nlmLogEngineTDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the kind of transport service by which a Notification was received from an SNMP engine. nlmLogEngineTAddress contains the transport service address of the SNMP engine from which this Notification was received. Possible values for this object are presently found in the Transport Mappings for SNMPv2 document (RFC 1906 [8])." ::= { nlmLogEntry 6 } Expires 26 March 2001 [Page 17] Internet Draft Notification Log MIB 26 September 2000 nlmLogContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "If the Notification was received in a protocol which has a contextEngineID element like SNMPv3, this object has that value. Otherwise its value is a zero-length string." ::= { nlmLogEntry 7 } nlmLogContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the Notification came. For SNMPv1 Traps this is the community string from the Trap." ::= { nlmLogEntry 8 } nlmLogNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifer of the Notification that occurred." ::= { nlmLogEntry 9 } -- -- Log Variable Table -- nlmLogVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with Notification log entries." ::= { nlmLog 2 } nlmLogVariableEntry OBJECT-TYPE SYNTAX NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 26 March 2001 [Page 18] Internet Draft Notification Log MIB 26 September 2000 "A Notification log entry variable. Entries appear in this table when there are variables in the varbind list of a Notification in nlmLogTable." INDEX { nlmLogName, nlmLogIndex, nlmLogVariableIndex } ::= { nlmLogVariableTable 1 } NlmLogVariableEntry ::= SEQUENCE { nlmLogVariableIndex Unsigned32, nlmLogVariableID OBJECT IDENTIFIER, nlmLogVariableValueType INTEGER, nlmLogVariableCounter32Val Counter32, nlmLogVariableUnsigned32Val Unsigned32, nlmLogVariableTimeTicksVal TimeTicks, nlmLogVariableInteger32Val Integer32, nlmLogVariableOctetStringVal OCTET STRING, nlmLogVariableIpAddressVal IpAddress, nlmLogVariableOidVal OBJECT IDENTIFIER, nlmLogVariableCounter64Val Counter64, nlmLogVariableOpaqueVal Opaque } nlmLogVariableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer, starting at 1 for a given nlmLogIndex, for indexing variables within the logged Notification." ::= { nlmLogVariableEntry 1 } nlmLogVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The variable's object identifier." ::= { nlmLogVariableEntry 2 } nlmLogVariableValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8), opaque(9) } MAX-ACCESS read-only Expires 26 March 2001 [Page 19] Internet Draft Notification Log MIB 26 September 2000 STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow must be instantiated, based on this type." ::= { nlmLogVariableEntry 3 } nlmLogVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter32'." ::= { nlmLogVariableEntry 4 } nlmLogVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'unsigned32'." ::= { nlmLogVariableEntry 5 } nlmLogVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'timeTicks'." ::= { nlmLogVariableEntry 6 } nlmLogVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'integer32'." ::= { nlmLogVariableEntry 7 } nlmLogVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'octetString'." ::= { nlmLogVariableEntry 8 } Expires 26 March 2001 [Page 20] Internet Draft Notification Log MIB 26 September 2000 nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'." ::= { nlmLogVariableEntry 9 } nlmLogVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'objectId'." ::= { nlmLogVariableEntry 10 } nlmLogVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter64'." ::= { nlmLogVariableEntry 11 } nlmLogVariableOpaqueVal OBJECT-TYPE SYNTAX Opaque MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'opaque'." ::= { nlmLogVariableEntry 12 } -- -- Conformance -- notificationLogMIBConformance OBJECT IDENTIFIER ::= { notificationLogMIB 3 } notificationLogMIBCompliances OBJECT IDENTIFIER ::= { notificationLogMIBConformance 1 } notificationLogMIBGroups OBJECT IDENTIFIER ::= { notificationLogMIBConformance 2 } -- Compliance Expires 26 March 2001 [Page 21] Internet Draft Notification Log MIB 26 September 2000 notificationLogMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Notification Log MIB." MODULE -- this module MANDATORY-GROUPS { notificationLogConfigGroup, notificationLogStatsGroup, notificationLogLogGroup } OBJECT nlmConfigGlobalEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named logs." GROUP notificationLogDateGroup DESCRIPTION "This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBCompliances 1 } -- Units of Conformance notificationLogConfigGroup OBJECT-GROUP OBJECTS { Expires 26 March 2001 [Page 22] Internet Draft Notification Log MIB 26 September 2000 nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, nlmConfigLogFilterName, nlmConfigLogEntryLimit, nlmConfigLogAdminStatus, nlmConfigLogOperStatus, nlmConfigLogStorageType, nlmConfigLogEntryStatus } STATUS current DESCRIPTION "Notification log configuration management." ::= { notificationLogMIBGroups 1 } notificationLogStatsGroup OBJECT-GROUP OBJECTS { nlmStatsGlobalNotificationsLogged, nlmStatsGlobalNotificationsBumped, nlmStatsLogNotificationsLogged, nlmStatsLogNotificationsBumped } STATUS current DESCRIPTION "Notification log statistics." ::= { notificationLogMIBGroups 2 } notificationLogLogGroup OBJECT-GROUP OBJECTS { nlmLogTime, nlmLogEngineID, nlmLogEngineTAddress, nlmLogEngineTDomain, nlmLogContextEngineID, nlmLogContextName, nlmLogNotificationID, nlmLogVariableID, nlmLogVariableValueType, nlmLogVariableCounter32Val, nlmLogVariableUnsigned32Val, nlmLogVariableTimeTicksVal, nlmLogVariableInteger32Val, nlmLogVariableOctetStringVal, nlmLogVariableIpAddressVal, nlmLogVariableOidVal, Expires 26 March 2001 [Page 23] Internet Draft Notification Log MIB 26 September 2000 nlmLogVariableCounter64Val, nlmLogVariableOpaqueVal } STATUS current DESCRIPTION "Notification log data." ::= { notificationLogMIBGroups 3 } notificationLogDateGroup OBJECT-GROUP OBJECTS { nlmLogDateAndTime } STATUS current DESCRIPTION "Conditionally mandatory notification log data. This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBGroups 4 } END Expires 26 March 2001 [Page 24] Internet Draft Notification Log MIB 26 September 2000 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Expires 26 March 2001 [Page 25] Internet Draft Notification Log MIB 26 September 2000 6. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Expires 26 March 2001 [Page 26] Internet Draft Notification Log MIB 26 September 2000 Protocol (SNMPv3)", RFC 2574, April 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and version 2 of the Internet-standard Network Management Framework", RFC 1903, January 1996. Expires 26 March 2001 [Page 27] Internet Draft Notification Log MIB 26 September 2000 7. Security Considerations Security issues are discussed in Section 3.1.2. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 Email: ramk@cisco.com Expires 26 March 2001 [Page 28] Internet Draft Notification Log MIB 26 September 2000 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 26 March 2001 [Page 29] Internet Draft Notification Log MIB 26 September 2000 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 3 3.1 Environment ................................................... 3 3.1.1 SNMP Engines and Contexts ................................... 4 3.1.2 Security .................................................... 4 3.2 Structure ..................................................... 5 3.2.1 Configuration ............................................... 6 3.2.2 Statistics .................................................. 6 3.2.3 Log ......................................................... 6 3.3 Example ....................................................... 6 4 Definitions ..................................................... 8 5 Intellectual Property ........................................... 25 6 References ...................................................... 26 7 Security Considerations ......................................... 28 8 Author's Address ................................................ 28 9 Full Copyright Statement ........................................ 29 Expires 26 March 2001 [Page 30] From owner-disman@dorothy.peer.com Wed Sep 27 02:57:12 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05915 for ; Wed, 27 Sep 2000 02:57:12 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8R6ohN05003; Wed, 27 Sep 2000 01:50:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA15394 for disman-list; Tue, 26 Sep 2000 23:46:09 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA15389 for ; Tue, 26 Sep 2000 23:46:05 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8R6jtQ04487 for ; Wed, 27 Sep 2000 01:45:55 -0500 (CDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id IAA29835; Wed, 27 Sep 2000 08:46:48 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id IAA01551; Wed, 27 Sep 2000 08:46:48 +0200 Date: Wed, 27 Sep 2000 08:46:48 +0200 Message-Id: <200009270646.IAA01551@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: ramk@cisco.com CC: disman@dorothy.peer.com In-reply-to: <200009270153.SAA16202@wanena1.cisco.com> (ramk@cisco.com) Subject: Re: Updated version of draft-ietf-notif-log-mib-17.txt References: <200009270153.SAA16202@wanena1.cisco.com> Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list >>>>> ramk writes: ramk> As Juergen suggested, I've changed nlmLogEngineAddress and ramk> nlmLogEngineAddressType to "nlmLogEngineTAddress" and ramk> "nlmLogEngineTDomain" respectively. All occurrences of the above ramk> names were corrected in the draft. Looks good to me. I found two minor editorial nits. First, the last reference ramk> [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, ramk> "Coexistence between Version 1 and version 2 of the ramk> Internet-standard Network Management Framework", RFC 1903, ramk> January 1996. is (a) broken and (b) not needed. So my suggestion is to remove it. Second, the description of nlmLogEngineTDomain contains a line that is longer than 76 character. You may want to fix this so that the RFC editor has less work to do. ;-) /js From owner-disman@dorothy.peer.com Wed Sep 27 13:39:26 2000 Received: from tattler.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18234 for ; Wed, 27 Sep 2000 13:39:25 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8RHSCj27625; Wed, 27 Sep 2000 12:28:12 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA17295 for disman-list; Wed, 27 Sep 2000 10:26:13 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA17287 for ; Wed, 27 Sep 2000 10:25:41 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8RHPSS27073 for ; Wed, 27 Sep 2000 12:25:29 -0500 (CDT) Received: from riverstonenet.com by riverstonenet.com (8.8.8+Sun/SMI-SVR4-Yago) id KAA12573; Wed, 27 Sep 2000 10:23:10 -0700 (PDT) Message-ID: <39D214DE.678E8C11@riverstonenet.com> Date: Wed, 27 Sep 2000 10:40:14 -0500 From: Thippanna Hongal Organization: Riverstone Networks Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,Kannada MIME-Version: 1.0 To: snmpconf , "disman@dorothy.peer.com" Subject: snmpconf Upcoming issues mail Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit hi David >We need to get a list of issues on the table for discussion >up to and during the upcoming interim meeting. These issues will >follow this mail as quickly as I can get them assembled. 1. I did sent the requirement list for associating 'time' with policy table both to 'snmpconf' and 'disman' mailing list. This can be another issue to discuss. -- Thanks, hongal ------------------------------------------------------ Thippanna Hongal Software Engineer Tel(O):408 878 6562 Riverstone Networks Inc. 5200 Great America Parkway Santa Clara CA USA 95054 ------------------------------------------------------- From owner-disman@dorothy.peer.com Thu Sep 28 15:20:48 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00179 for ; Thu, 28 Sep 2000 15:20:46 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8SJCd401968; Thu, 28 Sep 2000 14:12:40 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA22740 for disman-list; Thu, 28 Sep 2000 12:06:03 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA22733 for ; Thu, 28 Sep 2000 12:05:59 -0700 (PDT) Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8SJ5iL00288 for ; Thu, 28 Sep 2000 14:05:45 -0500 (CDT) Received: from cisco.com (dhcp-171-69-66-157.cisco.com [171.69.66.157]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA23423; Thu, 28 Sep 2000 12:06:09 -0700 (PDT) Message-ID: <39D396A1.75EDA36B@cisco.com> Date: Thu, 28 Sep 2000 12:06:09 -0700 From: Ram Kavasseri Reply-To: ramk@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: disman@dorothy.peer.com Subject: Re: Updated version of draft-ietf-notif-log-mib-17.txt References: <200009270153.SAA16202@wanena1.cisco.com> <200009270646.IAA01551@henkell.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit Juergen Schoenwaelder wrote: > > >>>>> ramk writes: > > ramk> As Juergen suggested, I've changed nlmLogEngineAddress and > ramk> nlmLogEngineAddressType to "nlmLogEngineTAddress" and > ramk> "nlmLogEngineTDomain" respectively. All occurrences of the above > ramk> names were corrected in the draft. > > Looks good to me. > > I found two minor editorial nits. First, the last reference > > ramk> [RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, > ramk> "Coexistence between Version 1 and version 2 of the > ramk> Internet-standard Network Management Framework", RFC 1903, > ramk> January 1996. > > is (a) broken and (b) not needed. So my suggestion is to remove it. > Second, the description of nlmLogEngineTDomain contains a line that is > longer than 76 character. You may want to fix this so that the RFC > editor has less work to do. ;-) > > /js Done - I'll post the new draft in a few mins. Ram From owner-disman@dorothy.peer.com Thu Sep 28 15:42:10 2000 Received: from tattler.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00595 for ; Thu, 28 Sep 2000 15:42:09 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with ESMTP id e8SJYop06482; Thu, 28 Sep 2000 14:34:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA04344 for disman-list; Thu, 28 Sep 2000 12:33:33 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA04339 for ; Thu, 28 Sep 2000 12:33:15 -0700 (PDT) From: ramk@cisco.com Received: from fw-us-hou1.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.8.6) with SMTP id e8SJX3006111 for ; Thu, 28 Sep 2000 14:33:03 -0500 (CDT) Received: from itech-view5.cisco.com (itech-view5.cisco.com [171.69.63.172]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA04608 for ; Thu, 28 Sep 2000 12:34:00 -0700 (PDT) Received: (ramk@localhost) by itech-view5.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA11006 for disman@dorothy.bmc.com; Thu, 28 Sep 2000 12:14:41 -0700 (PDT) Message-Id: <200009281914.MAA11006@itech-view5.cisco.com> Subject: Updated version of the Notification-Log-MIB To: disman@dorothy.peer.com Date: Thu, 28 Sep 2000 12:14:41 -0700 (PDT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@dorothy.peer.com Precedence: bulk List-Id: IETF disman Working Group mailing list Content-Transfer-Encoding: 7bit This revision contains the following two edits: 1. reference to rfc1903 was removed (it was incorrect, and not used anywhere in the draft) 2. the DESCRIPTION for nlmLogEngineTDomain had a line greater than 76 chars. This has been fixed... Thanks, Ram Kavasseri Network Working Group Editor of this version: Internet-Draft Ramanathan R. Kavasseri Expires March 2001 Cisco Systems, Inc. Author of previous version: Bob Stewart 26 September 2000 Notification Log MIB draft-ietf-disman-notif-log-mib-17-edited-ver3.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the Distributed Management Working Group, . Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Internet Draft Notification Log MIB 26 September 2000 1. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. Expires 26 March 2001 [Page 2] Internet Draft Notification Log MIB 26 September 2000 A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 3. Overview Systems that support SNMP often need a mechanism for recording Notification information as a hedge against lost Notifications, whether those are Traps or Informs [RFC1905] that exceed retransmission limits. This MIB therefore provides common infrastructure for other MIBs in the form of a local logging function. It is intended primarily for senders of Notifications but could be used also by receivers. Given the Notification Log MIB, individual MIBs bear less responsibility to record the transient information associated with an event against the possibility that the Notification message is lost, and applications can poll the log to verify that they have not missed important Notifications. 3.1. Environment The overall environmental concerns for the MIB are: o SNMP Engines and Contexts o Security Expires 26 March 2001 [Page 3] Internet Draft Notification Log MIB 26 September 2000 3.1.1. SNMP Engines and Contexts There are two distinct information flows from multiple notification originators that one may log. The first is the notifications that are received (from one or more SNMP engines) for logging as SNMP informs and traps. The other comprises notifications delivered to an SNMP engine at the interface to the notification originator (using a notification mechanism other than SNMP informs or traps). The latter information flow (using a notification mechanism other than SNMP informs or traps) is modeled here as the SNMP engine (which maintains the log) sending a notification to itself. The remainder of this section discusses the handling of the former information flow - notifications (received in the form of SNMP informs or traps) from multiple SNMP engines. As described in the SNMP architecture [RFC2571], a given system may support multiple SNMP engines operating independently of one another, each with its own SNMP engine identification. Furthermore, within the purview of a given engine there may be multiple named management contexts supporting overlapping or disjoint sets of MIB objects and Notifications. Thus, understanding a particular Notification requires knowing the SNMP engine and management context from whence it came. To provide the necessary source information for a logged Notification, the MIB includes objects to record that Notification's source SNMP engine ID and management context name. 3.1.2. Security Security for Notifications is awkward since access control for the objects in the Notification can be checked only where the Notification is created. Thus such checking is possible only for locally-generated Notifications, and even then only when security credentials are available. For the purpose of this discussion, "security credentials" means the input values for the abstract service interface function isAccessAllowed [RFC2571] and using those credentials means conceptually using that function to see that those credentials allow access to the MIB objects in question, operating as for a Notification Originator in [RFC2573]. The Notification Log MIB has the notion of a "named log." By using log names and view-based access control [RFC2575] a network administrator can provide different access for different users. When an application creates a named log the security credentials of the creator stay Expires 26 March 2001 [Page 4] Internet Draft Notification Log MIB 26 September 2000 associated with that log. A managed system with fewer resources MAY disallow the creation of named logs, providing only the default, null-named log. Such a log has no implicit security credentials for Notification object access control and Notifications are put into it with no further checking. When putting locally-generated Notifications into a named log, the managed system MUST use the security credentials associated with that log and MUST apply the same access control rules as described for a Notification Originator in [RFC2573]. The managed system SHOULD NOT apply access control when adding remotely- generated Notifications into either a named log or the default, null- named log. In those cases the security of the information in the log SHOULD be left to the normal, overall access control for the log itself. The Notification Log MIB allows applications to set the maximum number of Notifications that can be logged, using nlmConfigGlobalEntryLimit. Similarly, an application can set the maximum age using nlmConfigGlobalAgeOut, after which older Notifications MAY be timed out. Please be aware that contention between multiple applications trying to set these objects to different values MAY affect the reliability and completeness of data seen by each application, i.e. it is possible that one application may change the value of either of these objects, resulting in some Notifications being deleted before the other applications have had a chance to see them. This could be used to orchestrate a denial-of-service attack. Methods for countering such an attack are for further study. 3.2. Structure The MIB has the following sections: o Configuration -- control over how much the log can hold and what Notifications are to be logged. o Statistics -- indications of logging activity. o Log -- the Notifications themselves. Expires 26 March 2001 [Page 5] Internet Draft Notification Log MIB 26 September 2000 3.2.1. Configuration The configuration section contains objects to manage resource use by the MIB. This section also contains a table to specify what logs exist and how they operate. Deciding which Notifications are to be logged depends on filters defined in the the snmpNotifyFilterTable in the standard SNMP Notification MIB [RFC2573] identified by the initial index (snmpNotifyFilterName) from that table. 3.2.2. Statistics The statistics section contains counters for Notifications logged and discarded, supplying a means to understand the results of log capacity configuration and resource problems. 3.2.3. Log The log contains the Notifications and the objects that came in their variable binding list, indexed by an integer that reflects when the entry was made. An application that wants to collect all logged Notifications or to know if it may have missed any can keep track of the highest index it has retrieved and start from there on its next poll, checking sysUpTime for a discontinuity that would have reset the index and perhaps have lost entries. Variables are in a table indexed by Notification index and variable index within that Notification. The values are kept as a "discriminated union," with one value object per variable. Exactly which value object is instantiated depends on the SNMP data type of the variable, with a separate object of appropriate type for each distinct SNMP data type. An application can thus reconstruct the information from the Notification PDU from what is recorded in the log. 3.3. Example Following is an example configuration of a named log for logging only linkUp and linkDown Notifications. In nlmConfigLogTable: Expires 26 March 2001 [Page 6] Internet Draft Notification Log MIB 26 September 2000 nlmConfigLogFilterName.5."links" = "link-status" nlmConfigLogEntryLimit.5."links" = 0 nlmConfigLogAdminStatus.5."links" = enabled nlmConfigLogOperStatus.5."links" = operational nlmConfigLogStorageType.5."links" = nonVolatile nlmConfigLogEntryStatus.5."links" = active Note that snmpTraps is: iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5 Or numerically: 1.3.6.1.6.3.1.1.5 And linkDown is snmpTraps.3 and linkUp is snmpTraps.4. So to allow the two Notifications in snmpNotifyFilterTable: snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.3 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.3 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.3 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.3 = active snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.4 = ''H snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.4 = include snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.4 = nonVolatile snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.4 = active Expires 26 March 2001 [Page 7] Internet Draft Notification Log MIB 26 September 2000 4. Definitions NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, TimeTicks, Counter32, Counter64, IpAddress, Opaque, mib-2 FROM SNMPv2-SMI TimeStamp, DateAndTime, StorageType, RowStatus, TAddress, TDomain FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; notificationLogMIB MODULE-IDENTITY LAST-UPDATED "200009260000Z" -- 26 September 2000 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive, San Jose CA 95134-1706. Phone: +1 408 527 2446 Email: ramk@cisco.com" DESCRIPTION "The MIB module for logging SNMP Notifications, that is, Traps and Informs." -- Revision History REVISION "200009260000Z" -- 26 September 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC xxxx" ::= { mib-2 xx } -- final assignment by IANA at publication time notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section -- Expires 26 March 2001 [Page 8] Internet Draft Notification Log MIB 26 September 2000 nlmConfigGlobalEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of notification entries that may be held in nlmLogTable for all nlmLogNames added together. A particular setting does not guarantee that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications MUST be discarded to bring the log down to the new limit - thus the value of nlmConfigGlobalEntryLimit MUST take precedence over the values of nlmConfigGlobalAgeOut and nlmConfigLogEntryLimit, even if the Notification being discarded has been present for fewer minutes than the value of nlmConfigGlobalAgeOut, or if the named log has fewer entries than that specified in nlmConfigLogEntryLimit. A value of 0 means no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfig 1 } nlmConfigGlobalAgeOut OBJECT-TYPE SYNTAX Unsigned32 UNITS "minutes" MAX-ACCESS read-write STATUS current DESCRIPTION "The number of minutes a Notification SHOULD be kept in a log before it is automatically removed. If an application changes the value of nlmConfigGlobalAgeOut, Notifications older than the new time MAY be discarded to meet the new time. A value of 0 means no age out. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." Expires 26 March 2001 [Page 9] Internet Draft Notification Log MIB 26 September 2000 DEFVAL { 1440 } -- 24 hours ::= { nlmConfig 2 } -- -- Basic Log Configuration Table -- nlmConfigLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of logging control entries." ::= { nlmConfig 3 } nlmConfigLogEntry OBJECT-TYPE SYNTAX NlmConfigLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A logging control entry. Depending on the entry's storage type entries may be supplied by the system or created and deleted by applications using nlmConfigLogEntryStatus." INDEX { nlmLogName } ::= { nlmConfigLogTable 1 } NlmConfigLogEntry ::= SEQUENCE { nlmLogName SnmpAdminString, nlmConfigLogFilterName SnmpAdminString, nlmConfigLogEntryLimit Unsigned32, nlmConfigLogAdminStatus INTEGER, nlmConfigLogOperStatus INTEGER, nlmConfigLogStorageType StorageType, nlmConfigLogEntryStatus RowStatus } nlmLogName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the log. An implementation may allow multiple named logs, up to some Expires 26 March 2001 [Page 10] Internet Draft Notification Log MIB 26 September 2000 implementation-specific limit (which may be none). A zero-length log name is reserved for creation and deletion by the managed system, and MUST be used as the default log name by systems that do not support named logs." ::= { nlmConfigLogEntry 1 } nlmConfigLogFilterName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A value of snmpNotifyFilterProfileName as used as an index into the snmpNotifyFilterTable in the SNMP Notification MIB, specifying the locally or remotely originated Notifications to be filtered out and not logged in this log. A zero-length value or a name that does not identify an existing entry in snmpNotifyFilterTable indicate no Notifications are to be logged in this log." DEFVAL { ''H } ::= { nlmConfigLogEntry 2 } nlmConfigLogEntryLimit OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of notification entries that can be held in nlmLogTable for this named log. A particular setting does not guarantee that that much data can be held. If an application changes the limit while there are Notifications in the log, the oldest Notifications are discarded to bring the log down to the new limit. A value of 0 indicates no limit. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { 0 } ::= { nlmConfigLogEntry 3 } nlmConfigLogAdminStatus OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } Expires 26 March 2001 [Page 11] Internet Draft Notification Log MIB 26 September 2000 MAX-ACCESS read-create STATUS current DESCRIPTION "Control to enable or disable the log without otherwise disturbing the log's entry. Please be aware that contention between multiple managers trying to set this object to different values MAY affect the reliability and completeness of data seen by each manager." DEFVAL { enabled } ::= { nlmConfigLogEntry 4 } nlmConfigLogOperStatus OBJECT-TYPE SYNTAX INTEGER { disabled(1), operational(2), noFilter(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The operational status of this log: disabled administratively disabled operational administratively enabled and working noFilter administratively enabled but either nlmConfigLogFilterName is zero length or does not name an existing entry in snmpNotifyFilterTable" ::= { nlmConfigLogEntry 5 } nlmConfigLogStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type of this conceptual row." ::= { nlmConfigLogEntry 6 } nlmConfigLogEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Control for creating and deleting entries. Entries may be modified while active. Expires 26 March 2001 [Page 12] Internet Draft Notification Log MIB 26 September 2000 For non-null-named logs, the managed system records the security credentials from the request that sets nlmConfigLogStatus to 'active' and uses that identity to apply access control to the objects in the Notification to decide if that Notification may be logged." ::= { nlmConfigLogEntry 7 } -- -- Statistics Section -- nlmStatsGlobalNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put into the nlmLogTable. This counts a Notification once for each log entry, so a Notification put into multiple logs is counted multiple times." ::= { nlmStats 1 } nlmStatsGlobalNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStats 2 } -- -- Log Statistics Table -- nlmStatsLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log statistics entries." ::= { nlmStats 3 } Expires 26 March 2001 [Page 13] Internet Draft Notification Log MIB 26 September 2000 nlmStatsLogEntry OBJECT-TYPE SYNTAX NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log statistics entry." AUGMENTS { nlmConfigLogEntry } ::= { nlmStatsLogTable 1 } NlmStatsLogEntry ::= SEQUENCE { nlmStatsLogNotificationsLogged Counter32, nlmStatsLogNotificationsBumped Counter32 } nlmStatsLogNotificationsLogged OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Notifications put in this named log." ::= { nlmStatsLogEntry 1 } nlmStatsLogNotificationsBumped OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of log entries discarded from this named log to make room for a new entry due to lack of resources or the value of nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not include entries discarded due to the value of nlmConfigGlobalAgeOut." ::= { nlmStatsLogEntry 2 } -- -- Log Section -- -- -- Log Table -- Expires 26 March 2001 [Page 14] Internet Draft Notification Log MIB 26 September 2000 nlmLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of Notification log entries. It is an implementation-specific matter whether entries in this table are preserved across initializations of the management system. In general one would expect that they are not. Note that keeping entries across initializations of the management system leads to some confusion with counters and TimeStamps, since both of those are based on sysUpTime, which resets on management initialization. In this situation, counters apply only after the reset and nlmLogTime for entries made before the reset MUST be set to 0." ::= { nlmLog 1 } nlmLogEntry OBJECT-TYPE SYNTAX NlmLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log entry. Entries appear in this table when Notifications occur and pass filtering by nlmConfigLogFilterName and access control. They are removed to make way for new entries due to lack of resources or the values of nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, or nlmConfigLogEntryLimit. If adding an entry would exceed nlmConfigGlobalEntryLimit or system resources in general, the oldest entry in any log SHOULD be removed to make room for the new one. If adding an entry would exceed nlmConfigLogEntryLimit the oldest entry in that log SHOULD be removed to make room for the new one. Before the managed system puts a locally-generated Notification into a non-null-named log it assures that the creator of the log has access to the information in the Notification. If not it does not log that Notification in that log." INDEX { nlmLogName, nlmLogIndex } ::= { nlmLogTable 1 } Expires 26 March 2001 [Page 15] Internet Draft Notification Log MIB 26 September 2000 NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogDateAndTime DateAndTime, nlmLogEngineID SnmpEngineID, nlmLogEngineTAddress TAddress, nlmLogEngineTDomain TDomain, nlmLogContextEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, nlmLogNotificationID OBJECT IDENTIFIER } nlmLogIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer for the sole purpose of indexing entries within the named log. When it reaches the maximum value, an extremely unlikely event, the agent wraps the value back to 1." ::= { nlmLogEntry 1 } nlmLogTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the entry was placed in the log. If the entry occurred before the most recent management system initialization this object value MUST be set to zero." ::= { nlmLogEntry 2 } nlmLogDateAndTime OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "The local date and time when the entry was logged, instantiated only by systems that have date and time capability." ::= { nlmLogEntry 3 } nlmLogEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only Expires 26 March 2001 [Page 16] Internet Draft Notification Log MIB 26 September 2000 STATUS current DESCRIPTION "The identification of the SNMP engine at which the Notification originated. If the log can contain Notifications from only one engine or the Trap is in SNMPv1 format, this object is a zero-length string." ::= { nlmLogEntry 4 } nlmLogEngineTAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport service address of the SNMP engine from which the Notification was received, formatted according to the corresponding value of nlmLogEngineTDomain. This is used to identify the source of an SNMPv1 trap, since an nlmLogEngineId cannot be extracted from the SNMPv1 trap pdu. This object MUST always be instantiated, even if the log can contain Notifications from only one engine. Please be aware that the nlmLogEngineTAddress may not uniquely identify the SNMP engine from which the Notification was received. For example, if an SNMP engine uses DHCP or NAT to obtain ip addresses, the address it uses may be shared with other network devices, and hence will not uniquely identify the SNMP engine." ::= { nlmLogEntry 5 } nlmLogEngineTDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the kind of transport service by which a Notification was received from an SNMP engine. nlmLogEngineTAddress contains the transport service address of the SNMP engine from which this Notification was received. Possible values for this object are presently found in the Transport Mappings for SNMPv2 document (RFC 1906 [8])." ::= { nlmLogEntry 6 } Expires 26 March 2001 [Page 17] Internet Draft Notification Log MIB 26 September 2000 nlmLogContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "If the Notification was received in a protocol which has a contextEngineID element like SNMPv3, this object has that value. Otherwise its value is a zero-length string." ::= { nlmLogEntry 7 } nlmLogContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The name of the SNMP MIB context from which the Notification came. For SNMPv1 Traps this is the community string from the Trap." ::= { nlmLogEntry 8 } nlmLogNotificationID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The NOTIFICATION-TYPE object identifer of the Notification that occurred." ::= { nlmLogEntry 9 } -- -- Log Variable Table -- nlmLogVariableTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of variables to go with Notification log entries." ::= { nlmLog 2 } nlmLogVariableEntry OBJECT-TYPE SYNTAX NlmLogVariableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires 26 March 2001 [Page 18] Internet Draft Notification Log MIB 26 September 2000 "A Notification log entry variable. Entries appear in this table when there are variables in the varbind list of a Notification in nlmLogTable." INDEX { nlmLogName, nlmLogIndex, nlmLogVariableIndex } ::= { nlmLogVariableTable 1 } NlmLogVariableEntry ::= SEQUENCE { nlmLogVariableIndex Unsigned32, nlmLogVariableID OBJECT IDENTIFIER, nlmLogVariableValueType INTEGER, nlmLogVariableCounter32Val Counter32, nlmLogVariableUnsigned32Val Unsigned32, nlmLogVariableTimeTicksVal TimeTicks, nlmLogVariableInteger32Val Integer32, nlmLogVariableOctetStringVal OCTET STRING, nlmLogVariableIpAddressVal IpAddress, nlmLogVariableOidVal OBJECT IDENTIFIER, nlmLogVariableCounter64Val Counter64, nlmLogVariableOpaqueVal Opaque } nlmLogVariableIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer, starting at 1 for a given nlmLogIndex, for indexing variables within the logged Notification." ::= { nlmLogVariableEntry 1 } nlmLogVariableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The variable's object identifier." ::= { nlmLogVariableEntry 2 } nlmLogVariableValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8), opaque(9) } MAX-ACCESS read-only Expires 26 March 2001 [Page 19] Internet Draft Notification Log MIB 26 September 2000 STATUS current DESCRIPTION "The type of the value. One and only one of the value objects that follow must be instantiated, based on this type." ::= { nlmLogVariableEntry 3 } nlmLogVariableCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter32'." ::= { nlmLogVariableEntry 4 } nlmLogVariableUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'unsigned32'." ::= { nlmLogVariableEntry 5 } nlmLogVariableTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'timeTicks'." ::= { nlmLogVariableEntry 6 } nlmLogVariableInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'integer32'." ::= { nlmLogVariableEntry 7 } nlmLogVariableOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'octetString'." ::= { nlmLogVariableEntry 8 } Expires 26 March 2001 [Page 20] Internet Draft Notification Log MIB 26 September 2000 nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'." ::= { nlmLogVariableEntry 9 } nlmLogVariableOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'objectId'." ::= { nlmLogVariableEntry 10 } nlmLogVariableCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'counter64'." ::= { nlmLogVariableEntry 11 } nlmLogVariableOpaqueVal OBJECT-TYPE SYNTAX Opaque MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'opaque'." ::= { nlmLogVariableEntry 12 } -- -- Conformance -- notificationLogMIBConformance OBJECT IDENTIFIER ::= { notificationLogMIB 3 } notificationLogMIBCompliances OBJECT IDENTIFIER ::= { notificationLogMIBConformance 1 } notificationLogMIBGroups OBJECT IDENTIFIER ::= { notificationLogMIBConformance 2 } -- Compliance Expires 26 March 2001 [Page 21] Internet Draft Notification Log MIB 26 September 2000 notificationLogMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Notification Log MIB." MODULE -- this module MANDATORY-GROUPS { notificationLogConfigGroup, notificationLogStatsGroup, notificationLogLogGroup } OBJECT nlmConfigGlobalEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryLimit SYNTAX Unsigned32 (0..4294967295) MIN-ACCESS read-only DESCRIPTION "Implementations may choose a limit and not allow it to be changed or may enforce an upper or lower bound on the limit." OBJECT nlmConfigLogEntryStatus MIN-ACCESS read-only DESCRIPTION "Implementations may disallow the creation of named logs." GROUP notificationLogDateGroup DESCRIPTION "This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBCompliances 1 } -- Units of Conformance notificationLogConfigGroup OBJECT-GROUP OBJECTS { Expires 26 March 2001 [Page 22] Internet Draft Notification Log MIB 26 September 2000 nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, nlmConfigLogFilterName, nlmConfigLogEntryLimit, nlmConfigLogAdminStatus, nlmConfigLogOperStatus, nlmConfigLogStorageType, nlmConfigLogEntryStatus } STATUS current DESCRIPTION "Notification log configuration management." ::= { notificationLogMIBGroups 1 } notificationLogStatsGroup OBJECT-GROUP OBJECTS { nlmStatsGlobalNotificationsLogged, nlmStatsGlobalNotificationsBumped, nlmStatsLogNotificationsLogged, nlmStatsLogNotificationsBumped } STATUS current DESCRIPTION "Notification log statistics." ::= { notificationLogMIBGroups 2 } notificationLogLogGroup OBJECT-GROUP OBJECTS { nlmLogTime, nlmLogEngineID, nlmLogEngineTAddress, nlmLogEngineTDomain, nlmLogContextEngineID, nlmLogContextName, nlmLogNotificationID, nlmLogVariableID, nlmLogVariableValueType, nlmLogVariableCounter32Val, nlmLogVariableUnsigned32Val, nlmLogVariableTimeTicksVal, nlmLogVariableInteger32Val, nlmLogVariableOctetStringVal, nlmLogVariableIpAddressVal, nlmLogVariableOidVal, Expires 26 March 2001 [Page 23] Internet Draft Notification Log MIB 26 September 2000 nlmLogVariableCounter64Val, nlmLogVariableOpaqueVal } STATUS current DESCRIPTION "Notification log data." ::= { notificationLogMIBGroups 3 } notificationLogDateGroup OBJECT-GROUP OBJECTS { nlmLogDateAndTime } STATUS current DESCRIPTION "Conditionally mandatory notification log data. This group is mandatory on systems that keep wall clock date and time and should not be implemented on systems that do not have a wall clock date." ::= { notificationLogMIBGroups 4 } END Expires 26 March 2001 [Page 24] Internet Draft Notification Log MIB 26 September 2000 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Expires 26 March 2001 [Page 25] Internet Draft Notification Log MIB 26 September 2000 6. References [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Expires 26 March 2001 [Page 26] Internet Draft Notification Log MIB 26 September 2000 Protocol (SNMPv3)", RFC 2574, April 1999 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999 Expires 26 March 2001 [Page 27] Internet Draft Notification Log MIB 26 September 2000 7. Security Considerations Security issues are discussed in Section 3.1.2. 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 408 527 2446 Email: ramk@cisco.com Expires 26 March 2001 [Page 28] Internet Draft Notification Log MIB 26 September 2000 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires 26 March 2001 [Page 29] Internet Draft Notification Log MIB 26 September 2000 Table of Contents 1 Abstract ........................................................ 2 2 The SNMP Management Framework ................................... 2 3 Overview ........................................................ 3 3.1 Environment ................................................... 3 3.1.1 SNMP Engines and Contexts ................................... 4 3.1.2 Security .................................................... 4 3.2 Structure ..................................................... 5 3.2.1 Configuration ............................................... 6 3.2.2 Statistics .................................................. 6 3.2.3 Log ......................................................... 6 3.3 Example ....................................................... 6 4 Definitions ..................................................... 8 5 Intellectual Property ........................................... 25 6 References ...................................................... 26 7 Security Considerations ......................................... 28 8 Author's Address ................................................ 28 9 Full Copyright Statement ........................................ 29 Expires 26 March 2001 [Page 30]