From mailman-admin@ietf.org Sun Jun 1 13:26:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23625 for ; Sun, 1 Jun 2003 13:26:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51HPiB30902 for ; Sun, 1 Jun 2003 13:25:44 -0400 Date: Sun, 01 Jun 2003 13:25:44 -0400 Message-ID: <20030601172544.11734.45713.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: disman-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, disman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for disman-archive@lists.ietf.org: List Password // URL ---- -------- disman@ietf.org hixour https://www1.ietf.org/mailman/options/disman/disman-archive%40lists.ietf.org From mailnull@www1.ietf.org Tue Jun 3 07:49:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27667 for ; Tue, 3 Jun 2003 07:49:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53BmxO04573 for disman-archive@odin.ietf.org; Tue, 3 Jun 2003 07:48:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BmxB04570 for ; Tue, 3 Jun 2003 07:48:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27624 for ; Tue, 3 Jun 2003 07:48:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NAFx-0004Cs-00 for disman-web-archive@ietf.org; Tue, 03 Jun 2003 07:47:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NAFx-0004Co-00 for disman-web-archive@ietf.org; Tue, 03 Jun 2003 07:47:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BllB04497; Tue, 3 Jun 2003 07:47:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BkaB04422 for ; Tue, 3 Jun 2003 07:46:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27247; Tue, 3 Jun 2003 07:46:33 -0400 (EDT) Message-Id: <200306031146.HAA27247@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-alarm-mib-13.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 07:46:33 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-13.txt Pages : 66 Date : 2003-6-2 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 management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-alarm-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-alarm-mib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-2145411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-2145411.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-admin@ietf.org Tue Jun 3 07:50:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27811 for ; Tue, 3 Jun 2003 07:50:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BllB04497; Tue, 3 Jun 2003 07:47:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h53BkaB04422 for ; Tue, 3 Jun 2003 07:46:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27247; Tue, 3 Jun 2003 07:46:33 -0400 (EDT) Message-Id: <200306031146.HAA27247@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-alarm-mib-13.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 03 Jun 2003 07:46:33 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-13.txt Pages : 66 Date : 2003-6-2 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 management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-alarm-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-alarm-mib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-2145411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-2145411.I-D@ietf.org> --OtherAccess-- --NextPart-- From mailnull@www1.ietf.org Fri Jun 6 09:38:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23171 for ; Fri, 6 Jun 2003 09:38:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56DcVe24470 for disman-archive@odin.ietf.org; Fri, 6 Jun 2003 09:38:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56DcVB24467 for ; Fri, 6 Jun 2003 09:38:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23160 for ; Fri, 6 Jun 2003 09:38:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OHOT-00028D-00 for disman-web-archive@ietf.org; Fri, 06 Jun 2003 09:36:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19OHOS-000286-00 for disman-web-archive@ietf.org; Fri, 06 Jun 2003 09:36:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56DbfB24338; Fri, 6 Jun 2003 09:37:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56DWnB23308 for ; Fri, 6 Jun 2003 09:32:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22871 for ; Fri, 6 Jun 2003 09:32:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OHIw-00022k-00 for disman@ietf.org; Fri, 06 Jun 2003 09:30:51 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19OHIw-00021I-00 for disman@ietf.org; Fri, 06 Jun 2003 09:30:50 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h56DW2P08871 for ; Fri, 6 Jun 2003 08:32:03 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10PX17>; Fri, 6 Jun 2003 15:32:01 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC2930@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Lam, Hing-Kam (Kam)" , "'a_n_huynh@yahoo.com'" , "'David Perkins'" Cc: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] AD review of: draft-ietf-disman-conditionmib-08.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 6 Jun 2003 15:31:57 +0200 Here is my review of rev 8. If you want, we can issue IETF Last Call, and then you may consider these comments as IETF Last Call Comments, that you better address rigth after such an IETF Last Call. More or less serious: - I see IANAItuProbableCauseOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC can take any value of IANAItuProbableCause or 0. IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC module in the Alarm MIB document (see RFC zzzz)." REFERENCE "RFC zzzz - Alarm MIB, Chisholm, S. and D. Romascanu, mmm 2002." -- RFC Ed.: replace zzzz with the RFC number of the Alarm MIB document, -- replace mmm with the actual month, and remove this notice. And so I wonder. That IANA mantained MIB module will be extracted from the document, and after that, the authoritative version will be at the iana web site as follows: http://www.iana.org/assignments/ianaitualarmtc-mib Now putting a url into the REF clause is not good either, but maybe something aka: REFERENCE "IANA-ITU-ALARM-TC MIB module as maintained at the IANA web site. The initial module was also published in RFC zzzz." However, you do want to add that http://www.iana.org/assignments/ianaitualarmtc-mib in the normative references section, cause one must understand it in order to udnerstand your TC and how it is used. - I believe that the arcEntry should include in its DESCRIPTION clause some text about the fact that the indexing can cause OIDs of more than 128 sub-IDs (which are not supported bu SNMPv1, SNMPv2c or SNMPv3). This is caused by OIDs for ResourceId syntax of arcIndex and for arcNotificationId. So some text as to how people can/should avoid an OID of more than 128 sub-IDs shoiuld be added. - arcRowStatus OBJECT-TYPE In the DESCRIPTION clause, pls describe if any objedcts in a row can or cannot be updated while the row is in active state. Such is required as per RFC2579. Questions: - I see arcTITimeInterval OBJECT-TYPE SYNTAX Gauge32 and arcCDTimeInterval OBJECT-TYPE SYNTAX Gauge32 is that a proper syntax for an interval ?? there are a few more of these. - I see two informative references (RFC1213 and RFC2863), but I do not see any citations to it. So are they needed or useful? NITS: - Can you do real pagination? - I see " This document defines the SNMP objects..." I think they are "MIB objects" rather than "SNMP objects" - I see " The ARC MIB defined in" a few times. I think it is better to write "The ARC MIB module ....." - I see: DESCRIPTION "The MIB module describes the objects for controlling a resource in reporting alarm conditions that it detects. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this note REVISION "200304160000Z" DESCRIPTION "Initial version, published as RFC xxxx." -- RFC Ed.: replace xxxx with actual RFC number & remove this note ::={ mib-2 yy } -- to be assigned by IANA -- RFC Ed.: replace yy with IANA-assigned number & remove this note It might be easier if you used xxxx instead of yyyy, After all, these are both going to be the same RFC number, no? bert From disman-admin@ietf.org Fri Jun 6 09:39:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23186 for ; Fri, 6 Jun 2003 09:39:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56DbfB24338; Fri, 6 Jun 2003 09:37:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h56DWnB23308 for ; Fri, 6 Jun 2003 09:32:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22871 for ; Fri, 6 Jun 2003 09:32:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OHIw-00022k-00 for disman@ietf.org; Fri, 06 Jun 2003 09:30:51 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19OHIw-00021I-00 for disman@ietf.org; Fri, 06 Jun 2003 09:30:50 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h56DW2P08871 for ; Fri, 6 Jun 2003 08:32:03 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <2R10PX17>; Fri, 6 Jun 2003 15:32:01 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501BC2930@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Lam, Hing-Kam (Kam)" , "'a_n_huynh@yahoo.com'" , "'David Perkins'" Cc: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] AD review of: draft-ietf-disman-conditionmib-08.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 6 Jun 2003 15:31:57 +0200 Here is my review of rev 8. If you want, we can issue IETF Last Call, and then you may consider these comments as IETF Last Call Comments, that you better address rigth after such an IETF Last Call. More or less serious: - I see IANAItuProbableCauseOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This TC can take any value of IANAItuProbableCause or 0. IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC module in the Alarm MIB document (see RFC zzzz)." REFERENCE "RFC zzzz - Alarm MIB, Chisholm, S. and D. Romascanu, mmm 2002." -- RFC Ed.: replace zzzz with the RFC number of the Alarm MIB document, -- replace mmm with the actual month, and remove this notice. And so I wonder. That IANA mantained MIB module will be extracted from the document, and after that, the authoritative version will be at the iana web site as follows: http://www.iana.org/assignments/ianaitualarmtc-mib Now putting a url into the REF clause is not good either, but maybe something aka: REFERENCE "IANA-ITU-ALARM-TC MIB module as maintained at the IANA web site. The initial module was also published in RFC zzzz." However, you do want to add that http://www.iana.org/assignments/ianaitualarmtc-mib in the normative references section, cause one must understand it in order to udnerstand your TC and how it is used. - I believe that the arcEntry should include in its DESCRIPTION clause some text about the fact that the indexing can cause OIDs of more than 128 sub-IDs (which are not supported bu SNMPv1, SNMPv2c or SNMPv3). This is caused by OIDs for ResourceId syntax of arcIndex and for arcNotificationId. So some text as to how people can/should avoid an OID of more than 128 sub-IDs shoiuld be added. - arcRowStatus OBJECT-TYPE In the DESCRIPTION clause, pls describe if any objedcts in a row can or cannot be updated while the row is in active state. Such is required as per RFC2579. Questions: - I see arcTITimeInterval OBJECT-TYPE SYNTAX Gauge32 and arcCDTimeInterval OBJECT-TYPE SYNTAX Gauge32 is that a proper syntax for an interval ?? there are a few more of these. - I see two informative references (RFC1213 and RFC2863), but I do not see any citations to it. So are they needed or useful? NITS: - Can you do real pagination? - I see " This document defines the SNMP objects..." I think they are "MIB objects" rather than "SNMP objects" - I see " The ARC MIB defined in" a few times. I think it is better to write "The ARC MIB module ....." - I see: DESCRIPTION "The MIB module describes the objects for controlling a resource in reporting alarm conditions that it detects. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this note REVISION "200304160000Z" DESCRIPTION "Initial version, published as RFC xxxx." -- RFC Ed.: replace xxxx with actual RFC number & remove this note ::={ mib-2 yy } -- to be assigned by IANA -- RFC Ed.: replace yy with IANA-assigned number & remove this note It might be easier if you used xxxx instead of yyyy, After all, these are both going to be the same RFC number, no? bert From disman-admin@ietf.org Tue Jun 10 01:55:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02425 for ; Tue, 10 Jun 2003 01:55:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5qSB06565; Tue, 10 Jun 2003 01:52:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5poB06534 for ; Tue, 10 Jun 2003 01:51:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02379 for ; Tue, 10 Jun 2003 01:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pc0u-0001ss-00 for disman@ietf.org; Tue, 10 Jun 2003 01:49:44 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Pc0t-0001sh-00 for disman@ietf.org; Tue, 10 Jun 2003 01:49:43 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5A5pCA17945 for ; Tue, 10 Jun 2003 00:51:13 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Jun 2003 01:51:12 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "Wijnen, Bert (Bert)" , "'a_n_huynh@yahoo.com'" , "'David Perkins'" Cc: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] RE: AD review of: draft-ietf-disman-conditionmib-08.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 01:51:10 -0400 Hi, I prefer to have these comments addressed before issuing an IETF Last Call. However, due to work obligation, I won't be able to start working on version -09 until next week. I hope this is acceptable. Regards, Kam > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Friday, June 06, 2003 9:32 AM > To: Lam, Hing-Kam (Kam); 'a_n_huynh@yahoo.com'; 'David Perkins' > Cc: Disman (E-mail) (E-mail) > Subject: AD review of: draft-ietf-disman-conditionmib-08.txt > > > Here is my review of rev 8. > > If you want, we can issue IETF Last Call, and then you may > consider these comments as IETF Last Call Comments, that you > better address rigth after such an IETF Last Call. > > More or less serious: > > - I see > IANAItuProbableCauseOrZero ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This TC can take any value of IANAItuProbableCause or 0. > IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC > module in the Alarm MIB document (see RFC zzzz)." > REFERENCE > "RFC zzzz - Alarm MIB, Chisholm, S. and D. Romascanu, > mmm 2002." > -- RFC Ed.: replace zzzz with the RFC number of the Alarm > MIB document, > -- replace mmm with the actual month, and remove > this notice. > And so I wonder. That IANA mantained MIB module will be > extracted from > the document, and after that, the authoritative version will be at > the iana web site as follows: > http://www.iana.org/assignments/ianaitualarmtc-mib > Now putting a url into the REF clause is not good either, but maybe > something aka: > REFERENCE > "IANA-ITU-ALARM-TC MIB module as maintained at the > IANA web site. > The initial module was also published in RFC zzzz." > However, you do want to add that > http://www.iana.org/assignments/ianaitualarmtc-mib > in the normative references section, cause one must > understand it in > order to udnerstand your TC and how it is used. > > - I believe that the arcEntry should include in its DESCRIPTION clause > some text about the fact that the indexing can cause OIDs of more > than 128 sub-IDs (which are not supported bu SNMPv1, > SNMPv2c or SNMPv3). > This is caused by OIDs for ResourceId syntax of arcIndex and for > arcNotificationId. So some text as to how people can/should avoid > an OID of more than 128 sub-IDs shoiuld be added. > > - arcRowStatus OBJECT-TYPE > In the DESCRIPTION clause, pls describe if any objedcts in a row can > or cannot be updated while the row is in active state. Such > is required > as per RFC2579. > > Questions: > - I see > arcTITimeInterval OBJECT-TYPE > SYNTAX Gauge32 > and > arcCDTimeInterval OBJECT-TYPE > SYNTAX Gauge32 > is that a proper syntax for an interval ?? > there are a few more of these. > > - I see two informative references (RFC1213 and RFC2863), but I do not > see any citations to it. So are they needed or useful? > > NITS: > > - Can you do real pagination? > > - I see " This document defines the SNMP objects..." > I think they are "MIB objects" rather than "SNMP objects" > > - I see " The ARC MIB defined in" a few times. > I think it is better to write "The ARC MIB module ....." > > - I see: > DESCRIPTION > "The MIB module describes the objects for > controlling a resource > in reporting alarm conditions that it detects. > > Copyright (C) The Internet Society (2003). This version > of this MIB module is part of RFC yyyy; see the RFC > itself for full legal notices." > -- RFC Ed.: replace yyyy with actual RFC number & remove this note > REVISION "200304160000Z" > DESCRIPTION > "Initial version, published as RFC xxxx." > -- RFC Ed.: replace xxxx with actual RFC number & remove this note > ::={ mib-2 yy } -- to be assigned by IANA > -- RFC Ed.: replace yy with IANA-assigned number & remove this note > It might be easier if you used xxxx instead of yyyy, After all, > these are both going to be the same RFC number, no? > > bert > From mailnull@www1.ietf.org Tue Jun 10 01:57:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02461 for ; Tue, 10 Jun 2003 01:57:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A5ugW06669 for disman-archive@odin.ietf.org; Tue, 10 Jun 2003 01:56:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5ugB06666 for ; Tue, 10 Jun 2003 01:56:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02443 for ; Tue, 10 Jun 2003 01:56:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pc5c-0001u2-00 for disman-web-archive@ietf.org; Tue, 10 Jun 2003 01:54:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Pc5b-0001ty-00 for disman-web-archive@ietf.org; Tue, 10 Jun 2003 01:54:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5qSB06565; Tue, 10 Jun 2003 01:52:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5A5poB06534 for ; Tue, 10 Jun 2003 01:51:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02379 for ; Tue, 10 Jun 2003 01:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pc0u-0001ss-00 for disman@ietf.org; Tue, 10 Jun 2003 01:49:44 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Pc0t-0001sh-00 for disman@ietf.org; Tue, 10 Jun 2003 01:49:43 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h5A5pCA17945 for ; Tue, 10 Jun 2003 00:51:13 -0500 (CDT) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Jun 2003 01:51:12 -0400 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "Wijnen, Bert (Bert)" , "'a_n_huynh@yahoo.com'" , "'David Perkins'" Cc: "Disman (E-mail) (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Disman] RE: AD review of: draft-ietf-disman-conditionmib-08.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 10 Jun 2003 01:51:10 -0400 Hi, I prefer to have these comments addressed before issuing an IETF Last Call. However, due to work obligation, I won't be able to start working on version -09 until next week. I hope this is acceptable. Regards, Kam > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Friday, June 06, 2003 9:32 AM > To: Lam, Hing-Kam (Kam); 'a_n_huynh@yahoo.com'; 'David Perkins' > Cc: Disman (E-mail) (E-mail) > Subject: AD review of: draft-ietf-disman-conditionmib-08.txt > > > Here is my review of rev 8. > > If you want, we can issue IETF Last Call, and then you may > consider these comments as IETF Last Call Comments, that you > better address rigth after such an IETF Last Call. > > More or less serious: > > - I see > IANAItuProbableCauseOrZero ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This TC can take any value of IANAItuProbableCause or 0. > IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC > module in the Alarm MIB document (see RFC zzzz)." > REFERENCE > "RFC zzzz - Alarm MIB, Chisholm, S. and D. Romascanu, > mmm 2002." > -- RFC Ed.: replace zzzz with the RFC number of the Alarm > MIB document, > -- replace mmm with the actual month, and remove > this notice. > And so I wonder. That IANA mantained MIB module will be > extracted from > the document, and after that, the authoritative version will be at > the iana web site as follows: > http://www.iana.org/assignments/ianaitualarmtc-mib > Now putting a url into the REF clause is not good either, but maybe > something aka: > REFERENCE > "IANA-ITU-ALARM-TC MIB module as maintained at the > IANA web site. > The initial module was also published in RFC zzzz." > However, you do want to add that > http://www.iana.org/assignments/ianaitualarmtc-mib > in the normative references section, cause one must > understand it in > order to udnerstand your TC and how it is used. > > - I believe that the arcEntry should include in its DESCRIPTION clause > some text about the fact that the indexing can cause OIDs of more > than 128 sub-IDs (which are not supported bu SNMPv1, > SNMPv2c or SNMPv3). > This is caused by OIDs for ResourceId syntax of arcIndex and for > arcNotificationId. So some text as to how people can/should avoid > an OID of more than 128 sub-IDs shoiuld be added. > > - arcRowStatus OBJECT-TYPE > In the DESCRIPTION clause, pls describe if any objedcts in a row can > or cannot be updated while the row is in active state. Such > is required > as per RFC2579. > > Questions: > - I see > arcTITimeInterval OBJECT-TYPE > SYNTAX Gauge32 > and > arcCDTimeInterval OBJECT-TYPE > SYNTAX Gauge32 > is that a proper syntax for an interval ?? > there are a few more of these. > > - I see two informative references (RFC1213 and RFC2863), but I do not > see any citations to it. So are they needed or useful? > > NITS: > > - Can you do real pagination? > > - I see " This document defines the SNMP objects..." > I think they are "MIB objects" rather than "SNMP objects" > > - I see " The ARC MIB defined in" a few times. > I think it is better to write "The ARC MIB module ....." > > - I see: > DESCRIPTION > "The MIB module describes the objects for > controlling a resource > in reporting alarm conditions that it detects. > > Copyright (C) The Internet Society (2003). This version > of this MIB module is part of RFC yyyy; see the RFC > itself for full legal notices." > -- RFC Ed.: replace yyyy with actual RFC number & remove this note > REVISION "200304160000Z" > DESCRIPTION > "Initial version, published as RFC xxxx." > -- RFC Ed.: replace xxxx with actual RFC number & remove this note > ::={ mib-2 yy } -- to be assigned by IANA > -- RFC Ed.: replace yy with IANA-assigned number & remove this note > It might be easier if you used xxxx instead of yyyy, After all, > these are both going to be the same RFC number, no? > > bert > From mailnull@www1.ietf.org Wed Jun 11 08:00:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04137 for ; Wed, 11 Jun 2003 08:00:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BBxhR32441 for disman-archive@odin.ietf.org; Wed, 11 Jun 2003 07:59:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBxhB32438 for ; Wed, 11 Jun 2003 07:59:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04099 for ; Wed, 11 Jun 2003 07:59:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q4ES-0006tG-00 for disman-web-archive@ietf.org; Wed, 11 Jun 2003 07:57:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Q4ES-0006tC-00 for disman-web-archive@ietf.org; Wed, 11 Jun 2003 07:57:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBwgB32372; Wed, 11 Jun 2003 07:58:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBs2B32206 for ; Wed, 11 Jun 2003 07:54:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03691; Wed, 11 Jun 2003 07:53:59 -0400 (EDT) Message-Id: <200306111153.HAA03691@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-alarm-mib-14.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Jun 2003 07:53:59 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-14.txt Pages : 66 Date : 2003-6-10 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 management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-alarm-mib-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-alarm-mib-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-10110658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-10110658.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-admin@ietf.org Wed Jun 11 08:00:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04153 for ; Wed, 11 Jun 2003 08:00:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBwgB32372; Wed, 11 Jun 2003 07:58:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5BBs2B32206 for ; Wed, 11 Jun 2003 07:54:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03691; Wed, 11 Jun 2003 07:53:59 -0400 (EDT) Message-Id: <200306111153.HAA03691@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-alarm-mib-14.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 11 Jun 2003 07:53:59 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Alarm MIB Author(s) : S. Chisholm, D. Romascanu Filename : draft-ietf-disman-alarm-mib-14.txt Pages : 66 Date : 2003-6-10 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 management objects used for defining and storing alarms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-alarm-mib-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-alarm-mib-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-alarm-mib-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-10110658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-alarm-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-alarm-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-10110658.I-D@ietf.org> --OtherAccess-- --NextPart-- From mailnull@www1.ietf.org Thu Jun 12 13:38:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20339 for ; Thu, 12 Jun 2003 13:38:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CHcOb10905 for disman-archive@odin.ietf.org; Thu, 12 Jun 2003 13:38:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHcOm10902 for ; Thu, 12 Jun 2003 13:38:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20309 for ; Thu, 12 Jun 2003 13:38:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QVzj-0004d5-00 for disman-web-archive@ietf.org; Thu, 12 Jun 2003 13:36:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QVzj-0004d1-00 for disman-web-archive@ietf.org; Thu, 12 Jun 2003 13:36:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHbGm10281; Thu, 12 Jun 2003 13:37:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CGsvm06630 for ; Thu, 12 Jun 2003 12:54:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18504 for ; Thu, 12 Jun 2003 12:54:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QVJh-0004AT-00 for disman@ietf.org; Thu, 12 Jun 2003 12:52:49 -0400 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 19QVJg-0004AP-00 for disman@ietf.org; Thu, 12 Jun 2003 12:52:48 -0400 Received: from h-68-164-31-27.snvacaid.covad.net ([68.164.31.27] helo=oemcomputer) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19QVLi-0003WP-00 for disman@ietf.org; Thu, 12 Jun 2003 09:54:54 -0700 Message-ID: <010001c33102$77fbeb80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Should Disman meet in Vienna? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 09:48:36 -0700 Hi - Here's a status update, some helpful hints, and a question. Please forgive the length of this post. The alarm documents are rapidly cycling back and forth between the editors and our AD, fixing things as required by http://www.ietf.org/ietf/1id-guidelines.txt http://www.ietf.org/ID-nits.html http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt It would have been nice if we had taken care of this stuff before WG last call, but we'll just have to keep that in mind for the future. I've seen practically no discussion of any of the other disman WG documents: updates to expression, event, log, or script MIBs. I have not received any requests for consideration of new topics, nor have I seen any discussion on the WG mailing list that would indicate interest. The deadline for scheduling WG sessions in Vienna is fast approaching. Paul Hoffman offers this advice for folks considering attending the face-to-face meetings: > - Newcomers can learn a lot ahead of time by reading the Tao of the > IETF at . The newcomer orientation on > Sunday (this year, at 1PM) is useful, but it is even more useful if > they have read the Tao first. > > - It is a good idea to at least skim the WG archives for the past > four months before the meeting to help prevent rehashing items that > have already been decided and to help focus on items that need more > review. > > - Similarly, it is a good idea to re-read the WG's charter before the > meeting. Heck, many WG chairs could get value from this... > > - Many IETF areas have area-wide meetings. People who are interested > in more than just one WG can get a feel for what is happening in > other areas by going to these meetings. > > - The "Note Well" notice is serious. It can be found at > , and will be given on paper in > the registration packets. Now, here's the question: would it be productive for the disman WG to meet in Vienna? I currently do not see a need to do so, but I'm willing to be persuaded by discussion on this list or the appearance of relevant internet drafts. Possibilities might include: - substantive progress on updates to any of the WG's published RFCs - substantive discussion / proposals for new work Randy, disman WG chair, who'd really like a good reason to see if he can find the best Konditorei in Vienna. :-) From disman-admin@ietf.org Thu Jun 12 13:38:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20359 for ; Thu, 12 Jun 2003 13:38:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CHbGm10281; Thu, 12 Jun 2003 13:37:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CGsvm06630 for ; Thu, 12 Jun 2003 12:54:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18504 for ; Thu, 12 Jun 2003 12:54:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QVJh-0004AT-00 for disman@ietf.org; Thu, 12 Jun 2003 12:52:49 -0400 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 19QVJg-0004AP-00 for disman@ietf.org; Thu, 12 Jun 2003 12:52:48 -0400 Received: from h-68-164-31-27.snvacaid.covad.net ([68.164.31.27] helo=oemcomputer) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19QVLi-0003WP-00 for disman@ietf.org; Thu, 12 Jun 2003 09:54:54 -0700 Message-ID: <010001c33102$77fbeb80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Should Disman meet in Vienna? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 09:48:36 -0700 Hi - Here's a status update, some helpful hints, and a question. Please forgive the length of this post. The alarm documents are rapidly cycling back and forth between the editors and our AD, fixing things as required by http://www.ietf.org/ietf/1id-guidelines.txt http://www.ietf.org/ID-nits.html http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt It would have been nice if we had taken care of this stuff before WG last call, but we'll just have to keep that in mind for the future. I've seen practically no discussion of any of the other disman WG documents: updates to expression, event, log, or script MIBs. I have not received any requests for consideration of new topics, nor have I seen any discussion on the WG mailing list that would indicate interest. The deadline for scheduling WG sessions in Vienna is fast approaching. Paul Hoffman offers this advice for folks considering attending the face-to-face meetings: > - Newcomers can learn a lot ahead of time by reading the Tao of the > IETF at . The newcomer orientation on > Sunday (this year, at 1PM) is useful, but it is even more useful if > they have read the Tao first. > > - It is a good idea to at least skim the WG archives for the past > four months before the meeting to help prevent rehashing items that > have already been decided and to help focus on items that need more > review. > > - Similarly, it is a good idea to re-read the WG's charter before the > meeting. Heck, many WG chairs could get value from this... > > - Many IETF areas have area-wide meetings. People who are interested > in more than just one WG can get a feel for what is happening in > other areas by going to these meetings. > > - The "Note Well" notice is serious. It can be found at > , and will be given on paper in > the registration packets. Now, here's the question: would it be productive for the disman WG to meet in Vienna? I currently do not see a need to do so, but I'm willing to be persuaded by discussion on this list or the appearance of relevant internet drafts. Possibilities might include: - substantive progress on updates to any of the WG's published RFCs - substantive discussion / proposals for new work Randy, disman WG chair, who'd really like a good reason to see if he can find the best Konditorei in Vienna. :-) From mailnull@www1.ietf.org Fri Jun 13 05:18:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26150 for ; Fri, 13 Jun 2003 05:18:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5D9HxK23118 for disman-archive@odin.ietf.org; Fri, 13 Jun 2003 05:17:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D9Hxm23115 for ; Fri, 13 Jun 2003 05:17:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26138 for ; Fri, 13 Jun 2003 05:17:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qkez-00034S-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 05:15:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qkey-00034P-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 05:15:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CM83a29690; Thu, 12 Jun 2003 18:08:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CM7lm29619 for ; Thu, 12 Jun 2003 18:07:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28980 for ; Thu, 12 Jun 2003 18:07:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QaCP-0006Wk-00 for disman@ietf.org; Thu, 12 Jun 2003 18:05:37 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19QaCO-0006Vx-00 for disman@ietf.org; Thu, 12 Jun 2003 18:05:36 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5CM7Cwc001538; Thu, 12 Jun 2003 15:07:12 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIB68638; Thu, 12 Jun 2003 15:02:05 -0700 (PDT) Message-ID: <3EE8F98F.9050102@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: "Disman (E-mail)" Subject: Re: [Disman] Should Disman meet in Vienna? References: <010001c33102$77fbeb80$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 15:07:11 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Hi - > > Here's a status update, some helpful hints, and a question. > Please forgive the length of this post. > > The alarm documents are rapidly cycling back and forth between > the editors and our AD, fixing things as required by > http://www.ietf.org/ietf/1id-guidelines.txt > http://www.ietf.org/ID-nits.html > http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt > It would have been nice if we had taken care of this stuff before WG last call, > but we'll just have to keep that in mind for the future. > > I've seen practically no discussion of any of the other disman WG > documents: updates to expression, event, log, or script MIBs. > I've been miles behind in my editing work. Apologies for that. I'll post these docs by the end of the week... Ram > I have not received any requests for consideration of new topics, > nor have I seen any discussion on the WG mailing list that would > indicate interest. > > The deadline for scheduling WG sessions in Vienna is fast approaching. > > Paul Hoffman offers this advice for folks considering attending > the face-to-face meetings: > > >>- Newcomers can learn a lot ahead of time by reading the Tao of the >>IETF at . The newcomer orientation on >>Sunday (this year, at 1PM) is useful, but it is even more useful if >>they have read the Tao first. >> >>- It is a good idea to at least skim the WG archives for the past >>four months before the meeting to help prevent rehashing items that >>have already been decided and to help focus on items that need more >>review. >> >>- Similarly, it is a good idea to re-read the WG's charter before the >>meeting. Heck, many WG chairs could get value from this... >> >>- Many IETF areas have area-wide meetings. People who are interested >>in more than just one WG can get a feel for what is happening in >>other areas by going to these meetings. >> >>- The "Note Well" notice is serious. It can be found at >>, and will be given on paper in >>the registration packets. > > > Now, here's the question: would it be productive for the disman WG > to meet in Vienna? I currently do not see a need to do so, but I'm > willing to be persuaded by discussion on this list or the appearance > of relevant internet drafts. Possibilities might include: > - substantive progress on updates to any of the WG's published RFCs > - substantive discussion / proposals for new work > > Randy, disman WG chair, who'd really like a good reason to see if > he can find the best Konditorei in Vienna. :-) > > From disman-admin@ietf.org Fri Jun 13 05:18:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26165 for ; Fri, 13 Jun 2003 05:18:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CM83a29690; Thu, 12 Jun 2003 18:08:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5CM7lm29619 for ; Thu, 12 Jun 2003 18:07:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28980 for ; Thu, 12 Jun 2003 18:07:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QaCP-0006Wk-00 for disman@ietf.org; Thu, 12 Jun 2003 18:05:37 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19QaCO-0006Vx-00 for disman@ietf.org; Thu, 12 Jun 2003 18:05:36 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5CM7Cwc001538; Thu, 12 Jun 2003 15:07:12 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIB68638; Thu, 12 Jun 2003 15:02:05 -0700 (PDT) Message-ID: <3EE8F98F.9050102@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: "Disman (E-mail)" Subject: Re: [Disman] Should Disman meet in Vienna? References: <010001c33102$77fbeb80$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 12 Jun 2003 15:07:11 -0700 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Hi - > > Here's a status update, some helpful hints, and a question. > Please forgive the length of this post. > > The alarm documents are rapidly cycling back and forth between > the editors and our AD, fixing things as required by > http://www.ietf.org/ietf/1id-guidelines.txt > http://www.ietf.org/ID-nits.html > http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01.txt > It would have been nice if we had taken care of this stuff before WG last call, > but we'll just have to keep that in mind for the future. > > I've seen practically no discussion of any of the other disman WG > documents: updates to expression, event, log, or script MIBs. > I've been miles behind in my editing work. Apologies for that. I'll post these docs by the end of the week... Ram > I have not received any requests for consideration of new topics, > nor have I seen any discussion on the WG mailing list that would > indicate interest. > > The deadline for scheduling WG sessions in Vienna is fast approaching. > > Paul Hoffman offers this advice for folks considering attending > the face-to-face meetings: > > >>- Newcomers can learn a lot ahead of time by reading the Tao of the >>IETF at . The newcomer orientation on >>Sunday (this year, at 1PM) is useful, but it is even more useful if >>they have read the Tao first. >> >>- It is a good idea to at least skim the WG archives for the past >>four months before the meeting to help prevent rehashing items that >>have already been decided and to help focus on items that need more >>review. >> >>- Similarly, it is a good idea to re-read the WG's charter before the >>meeting. Heck, many WG chairs could get value from this... >> >>- Many IETF areas have area-wide meetings. People who are interested >>in more than just one WG can get a feel for what is happening in >>other areas by going to these meetings. >> >>- The "Note Well" notice is serious. It can be found at >>, and will be given on paper in >>the registration packets. > > > Now, here's the question: would it be productive for the disman WG > to meet in Vienna? I currently do not see a need to do so, but I'm > willing to be persuaded by discussion on this list or the appearance > of relevant internet drafts. Possibilities might include: > - substantive progress on updates to any of the WG's published RFCs > - substantive discussion / proposals for new work > > Randy, disman WG chair, who'd really like a good reason to see if > he can find the best Konditorei in Vienna. :-) > > From disman-admin@ietf.org Fri Jun 13 12:59:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12627 for ; Fri, 13 Jun 2003 12:59:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGV1a27153; Fri, 13 Jun 2003 12:31:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGUlm27116 for ; Fri, 13 Jun 2003 12:30:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11255 for ; Fri, 13 Jun 2003 12:30:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QrPp-0006WK-00 for disman@ietf.org; Fri, 13 Jun 2003 12:28:37 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 19QrPo-0006WH-00 for disman@ietf.org; Fri, 13 Jun 2003 12:28:36 -0400 Received: from h-68-165-65-37.snvacaid.covad.net ([68.165.65.37] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19QrRs-0001c2-00; Fri, 13 Jun 2003 09:30:44 -0700 Message-ID: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Cc: "Ram Kavasseri" , "Sharon Chisholm" , , "Wes Hardaker" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] To-do items left over from San Francisco Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 09:24:20 -0700 Hi - I looked through the minutes from our meeting in San Francisco, and it looks like the following items remain to be done: | 1. Sharon Chisholm tasked with drafting a "Thank You" message to the | ITU-T Liaison, and sending the draft to the DISMAN wg. Sharon? | 8. For Script MIB and Schedule MIB - Randy to look at a questionnaire | for implementation requests on these MIBs. Mea culpa. | 9. Remops MIB - if anyone is interested in assiting with edits, to | contact RP on the disman mailing list. | | 10. Octet String in Remops MIB for payload - has a constraint related to | ipv4 - computes | pkt size - ipv4 hdr size. Need description clarification on what the | object should do (return an error or silently truncate payload size) | when transport type is ipv6 - Randy Presuhn suggested silently | truncating. Need further | discussion on the mailing list. This action item is assigned to Randy | Presunhn. Juergen Quittek accepted the job of handling the edits. Juergen, where are we? | 10. Ram Kavasseri to initiate thread on taking Expression MIB to | historic status. This happened, but I don't feel like we really reached much of a conlusion. The current practice is to produce an informational RFC to explain a decision to reclassify a document as "historic". I didn't see a massive outpouring of volunteer effort to produce such a document, so I'd rather spend our editor cycles on things that clearly have a higher priority. | 12. Need interoperability results (for event and notif-log mibs) summary | on wg mailing list. | Ram Kavasseri to drive the interoperability test effort. Results |need to be posted to the wg by May. Ram? | 13. NetSNMP implements the EVENT-MIB - this MIB is the target of | internal polling | for NetSNMP apps. Wes Hardaker to provide pointers on how to set up a | copy | of NetSNMP running the EVENT-MIB for interoperability testing. Wes? | 14. Sharon to check and report back on implementations of log MIB at | Nortel. Sharon? | 15. Updates for Expr, Event, Notif-Log MIB expected by April 1st. | Editor needs to look at latest version of ID nits doc, the update to the | RFC authors | guidelines - for the ARC MIB update, as well as the latest guidelines | for MIB reviewers. Ram has already responded on this; beware the fast-approaching i-d cutoff. | 16. Ram to repost implementation requests for the event, expression and | notif-log mibs on the disman wg. Ram? If any of these are already done, please let me know. If any of the items that I thought was done isn't, I'd like to know about that as well. Randy From mailnull@www1.ietf.org Fri Jun 13 13:01:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12782 for ; Fri, 13 Jun 2003 13:01:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DH0dv04800 for disman-archive@odin.ietf.org; Fri, 13 Jun 2003 13:00:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DH0cm04797 for ; Fri, 13 Jun 2003 13:00:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12733 for ; Fri, 13 Jun 2003 13:00:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qrsh-0006pj-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 12:58:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qrsh-0006pg-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 12:58:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGV1a27153; Fri, 13 Jun 2003 12:31:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGUlm27116 for ; Fri, 13 Jun 2003 12:30:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11255 for ; Fri, 13 Jun 2003 12:30:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QrPp-0006WK-00 for disman@ietf.org; Fri, 13 Jun 2003 12:28:37 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 19QrPo-0006WH-00 for disman@ietf.org; Fri, 13 Jun 2003 12:28:36 -0400 Received: from h-68-165-65-37.snvacaid.covad.net ([68.165.65.37] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19QrRs-0001c2-00; Fri, 13 Jun 2003 09:30:44 -0700 Message-ID: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Cc: "Ram Kavasseri" , "Sharon Chisholm" , , "Wes Hardaker" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] To-do items left over from San Francisco Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 09:24:20 -0700 Hi - I looked through the minutes from our meeting in San Francisco, and it looks like the following items remain to be done: | 1. Sharon Chisholm tasked with drafting a "Thank You" message to the | ITU-T Liaison, and sending the draft to the DISMAN wg. Sharon? | 8. For Script MIB and Schedule MIB - Randy to look at a questionnaire | for implementation requests on these MIBs. Mea culpa. | 9. Remops MIB - if anyone is interested in assiting with edits, to | contact RP on the disman mailing list. | | 10. Octet String in Remops MIB for payload - has a constraint related to | ipv4 - computes | pkt size - ipv4 hdr size. Need description clarification on what the | object should do (return an error or silently truncate payload size) | when transport type is ipv6 - Randy Presuhn suggested silently | truncating. Need further | discussion on the mailing list. This action item is assigned to Randy | Presunhn. Juergen Quittek accepted the job of handling the edits. Juergen, where are we? | 10. Ram Kavasseri to initiate thread on taking Expression MIB to | historic status. This happened, but I don't feel like we really reached much of a conlusion. The current practice is to produce an informational RFC to explain a decision to reclassify a document as "historic". I didn't see a massive outpouring of volunteer effort to produce such a document, so I'd rather spend our editor cycles on things that clearly have a higher priority. | 12. Need interoperability results (for event and notif-log mibs) summary | on wg mailing list. | Ram Kavasseri to drive the interoperability test effort. Results |need to be posted to the wg by May. Ram? | 13. NetSNMP implements the EVENT-MIB - this MIB is the target of | internal polling | for NetSNMP apps. Wes Hardaker to provide pointers on how to set up a | copy | of NetSNMP running the EVENT-MIB for interoperability testing. Wes? | 14. Sharon to check and report back on implementations of log MIB at | Nortel. Sharon? | 15. Updates for Expr, Event, Notif-Log MIB expected by April 1st. | Editor needs to look at latest version of ID nits doc, the update to the | RFC authors | guidelines - for the ARC MIB update, as well as the latest guidelines | for MIB reviewers. Ram has already responded on this; beware the fast-approaching i-d cutoff. | 16. Ram to repost implementation requests for the event, expression and | notif-log mibs on the disman wg. Ram? If any of these are already done, please let me know. If any of the items that I thought was done isn't, I'd like to know about that as well. Randy From disman-admin@ietf.org Fri Jun 13 14:37:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17577 for ; Fri, 13 Jun 2003 14:37:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DI31a10380; Fri, 13 Jun 2003 14:03:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DI26m09536 for ; Fri, 13 Jun 2003 14:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15902 for ; Fri, 13 Jun 2003 14:02:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsqB-0007jg-00 for disman@ietf.org; Fri, 13 Jun 2003 13:59:55 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QsqA-0007jR-00 for disman@ietf.org; Fri, 13 Jun 2003 13:59:54 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5DI1MVI066902; Fri, 13 Jun 2003 20:01:24 +0200 (CEST) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D730AAD0E6; Fri, 13 Jun 2003 19:47:49 +0200 (CEST) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Cc: Ram Kavasseri , Sharon Chisholm , Wes Hardaker Message-ID: <4275788.1055534615@[10.1.1.26]> In-Reply-To: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> References: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Disman] Re: To-do items left over from San Francisco Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 20:03:36 +0200 Content-Transfer-Encoding: 7bit Hi Randy, -- Randy Presuhn wrote on 13 June 2003 09:24 -0700: > Hi - > > I looked through the minutes from our meeting in San Francisco, and > it looks like the following items remain to be done: > >| 1. Sharon Chisholm tasked with drafting a "Thank You" message to the >| ITU-T Liaison, and sending the draft to the DISMAN wg. > > Sharon? > >| 8. For Script MIB and Schedule MIB - Randy to look at a questionnaire >| for implementation requests on these MIBs. > > Mea culpa. > >| 9. Remops MIB - if anyone is interested in assiting with edits, to >| contact RP on the disman mailing list. >| >| 10. Octet String in Remops MIB for payload - has a constraint related to >| ipv4 - computes >| pkt size - ipv4 hdr size. Need description clarification on what the >| object should do (return an error or silently truncate payload size) >| when transport type is ipv6 - Randy Presuhn suggested silently >| truncating. Need further >| discussion on the mailing list. This action item is assigned to Randy >| Presunhn. > > Juergen Quittek accepted the job of handling > the edits. Juergen, where are we? I collected all remops issues from the mailing list since publication of the RFC incluing the issue on the RFC errata web page. I will reply on your suggestion in a separate message. Juergen >| 10. Ram Kavasseri to initiate thread on taking Expression MIB to >| historic status. > > This happened, but I don't feel like we really reached much of > a conlusion. The current practice is to produce an informational > RFC to explain a decision to reclassify a document as "historic". > I didn't see a massive outpouring of volunteer effort to produce > such a document, so I'd rather spend our editor cycles on things > that clearly have a higher priority. > >| 12. Need interoperability results (for event and notif-log mibs) summary >| on wg mailing list. >| Ram Kavasseri to drive the interoperability test effort. Results >| need to be posted to the wg by May. > > Ram? > >| 13. NetSNMP implements the EVENT-MIB - this MIB is the target of >| internal polling >| for NetSNMP apps. Wes Hardaker to provide pointers on how to set up a >| copy >| of NetSNMP running the EVENT-MIB for interoperability testing. > > Wes? > >| 14. Sharon to check and report back on implementations of log MIB at >| Nortel. > > Sharon? > >| 15. Updates for Expr, Event, Notif-Log MIB expected by April 1st. >| Editor needs to look at latest version of ID nits doc, the update to the >| RFC authors >| guidelines - for the ARC MIB update, as well as the latest guidelines >| for MIB reviewers. > > Ram has already responded on this; beware the fast-approaching i-d cutoff. > >| 16. Ram to repost implementation requests for the event, expression and >| notif-log mibs on the disman wg. > > Ram? > > If any of these are already done, please let me know. > If any of the items that I thought was done isn't, I'd like > to know about that as well. > > Randy > > From disman-admin@ietf.org Fri Jun 13 14:37:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17597 for ; Fri, 13 Jun 2003 14:37:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHX1a28573; Fri, 13 Jun 2003 13:33:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHWam26907 for ; Fri, 13 Jun 2003 13:32:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14905 for ; Fri, 13 Jun 2003 13:32:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsNc-0007Rs-00 for disman@ietf.org; Fri, 13 Jun 2003 13:30:25 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19QsNb-0007RM-00 for disman@ietf.org; Fri, 13 Jun 2003 13:30:24 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5DHVrjc018608; Fri, 13 Jun 2003 10:31:53 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIC41482; Fri, 13 Jun 2003 10:26:39 -0700 (PDT) Message-ID: <3EEA0A88.9030507@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: "Disman (E-mail)" , Sharon Chisholm , quittek@ccrle.nec.de, Wes Hardaker Subject: Re: [Disman] To-do items left over from San Francisco References: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 10:31:52 -0700 Content-Transfer-Encoding: 7bit I was about to post the revised event mib draft, but realized that I don't have Bob Stewart's latest contact information. The info in the draft still points to "Cisco Systems, Inc.", which isn't true anymore. Anyone have a more upto-date address? Or an alternative suggestion? Ram Randy Presuhn wrote: > Hi - > > I looked through the minutes from our meeting in San Francisco, and > it looks like the following items remain to be done: > > | 1. Sharon Chisholm tasked with drafting a "Thank You" message to the > | ITU-T Liaison, and sending the draft to the DISMAN wg. > > Sharon? > > | 8. For Script MIB and Schedule MIB - Randy to look at a questionnaire > | for implementation requests on these MIBs. > > Mea culpa. > > | 9. Remops MIB - if anyone is interested in assiting with edits, to > | contact RP on the disman mailing list. > | > | 10. Octet String in Remops MIB for payload - has a constraint related to > | ipv4 - computes > | pkt size - ipv4 hdr size. Need description clarification on what the > | object should do (return an error or silently truncate payload size) > | when transport type is ipv6 - Randy Presuhn suggested silently > | truncating. Need further > | discussion on the mailing list. This action item is assigned to Randy > | Presunhn. > > Juergen Quittek accepted the job of handling > the edits. Juergen, where are we? > > | 10. Ram Kavasseri to initiate thread on taking Expression MIB to > | historic status. > > This happened, but I don't feel like we really reached much of > a conlusion. The current practice is to produce an informational > RFC to explain a decision to reclassify a document as "historic". > I didn't see a massive outpouring of volunteer effort to produce > such a document, so I'd rather spend our editor cycles on things > that clearly have a higher priority. > > | 12. Need interoperability results (for event and notif-log mibs) summary > | on wg mailing list. > | Ram Kavasseri to drive the interoperability test effort. Results > |need to be posted to the wg by May. > > Ram? > > | 13. NetSNMP implements the EVENT-MIB - this MIB is the target of > | internal polling > | for NetSNMP apps. Wes Hardaker to provide pointers on how to set up a > | copy > | of NetSNMP running the EVENT-MIB for interoperability testing. > > Wes? > > | 14. Sharon to check and report back on implementations of log MIB at > | Nortel. > > Sharon? > > | 15. Updates for Expr, Event, Notif-Log MIB expected by April 1st. > | Editor needs to look at latest version of ID nits doc, the update to the > | RFC authors > | guidelines - for the ARC MIB update, as well as the latest guidelines > | for MIB reviewers. > > Ram has already responded on this; beware the fast-approaching i-d cutoff. > > | 16. Ram to repost implementation requests for the event, expression and > | notif-log mibs on the disman wg. > > Ram? > > If any of these are already done, please let me know. > If any of the items that I thought was done isn't, I'd like > to know about that as well. > > Randy > > From disman-admin@ietf.org Fri Jun 13 14:37:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17601 for ; Fri, 13 Jun 2003 14:37:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIM1a20848; Fri, 13 Jun 2003 14:22:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DILPm20571 for ; Fri, 13 Jun 2003 14:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16695 for ; Fri, 13 Jun 2003 14:21:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qt8s-00008v-00 for disman@ietf.org; Fri, 13 Jun 2003 14:19:14 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 19Qt8r-00008s-00 for disman@ietf.org; Fri, 13 Jun 2003 14:19:13 -0400 Received: from h-68-165-65-37.snvacaid.covad.net ([68.165.65.37] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19QtAw-0003CA-00 for disman@ietf.org; Fri, 13 Jun 2003 11:21:22 -0700 Message-ID: <002001c331d7$6fb3f460$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Regarding -00- disman documents Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 11:13:05 -0700 Hi - If you're planning to produce an internet draft with a filename that looks like "draft-ietf-disman-*-00.txt", I need to know about it posthaste so that I can provide the list of expected drafts to the secretariat. Randy From disman-admin@ietf.org Fri Jun 13 14:38:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17645 for ; Fri, 13 Jun 2003 14:38:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIF1a17373; Fri, 13 Jun 2003 14:15:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIE7m16780 for ; Fri, 13 Jun 2003 14:14:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16550 for ; Fri, 13 Jun 2003 14:14:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qt1n-00006K-00 for disman@ietf.org; Fri, 13 Jun 2003 14:11:55 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 19Qt1i-00006H-00 for disman@ietf.org; Fri, 13 Jun 2003 14:11:55 -0400 Received: from h-68-165-65-37.snvacaid.covad.net ([68.165.65.37] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Qt3n-0007I2-00 for disman@ietf.org; Fri, 13 Jun 2003 11:13:59 -0700 Message-ID: <001001c331d6$6f0a1540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> <4275788.1055534615@[10.1.1.26]> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Re: To-do items left over from San Francisco Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 11:05:55 -0700 Hi - > From: "Juergen Quittek" > To: "Randy Presuhn" ; "Disman (E-mail)" > Cc: "Ram Kavasseri" ; "Sharon Chisholm" ; "Wes Hardaker" > Sent: Friday, June 13, 2003 11:03 AM > Subject: Re: To-do items left over from San Francisco .... > >| 10. Octet String in Remops MIB for payload - has a constraint related to > >| ipv4 - computes > >| pkt size - ipv4 hdr size. Need description clarification on what the > >| object should do (return an error or silently truncate payload size) > >| when transport type is ipv6 - Randy Presuhn suggested silently > >| truncating. Need further > >| discussion on the mailing list. This action item is assigned to Randy > >| Presunhn. > > > > Juergen Quittek accepted the job of handling > > the edits. Juergen, where are we? > > I collected all remops issues from the mailing list since > publication of the RFC incluing the issue on the RFC errata > web page. > > I will reply on your suggestion in a separate message. ... Great! Thanks for the quick response. Randy From mailnull@www1.ietf.org Fri Jun 13 14:39:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17788 for ; Fri, 13 Jun 2003 14:39:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DIcqi13291 for disman-archive@odin.ietf.org; Fri, 13 Jun 2003 14:38:52 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIcnm11702 for ; Fri, 13 Jun 2003 14:38:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17745 for ; Fri, 13 Jun 2003 14:38:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QtPh-0000JK-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 14:36:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QtPh-0000JG-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 14:36:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DI31a10380; Fri, 13 Jun 2003 14:03:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DI26m09536 for ; Fri, 13 Jun 2003 14:02:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15902 for ; Fri, 13 Jun 2003 14:02:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsqB-0007jg-00 for disman@ietf.org; Fri, 13 Jun 2003 13:59:55 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QsqA-0007jR-00 for disman@ietf.org; Fri, 13 Jun 2003 13:59:54 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5DI1MVI066902; Fri, 13 Jun 2003 20:01:24 +0200 (CEST) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D730AAD0E6; Fri, 13 Jun 2003 19:47:49 +0200 (CEST) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Cc: Ram Kavasseri , Sharon Chisholm , Wes Hardaker Message-ID: <4275788.1055534615@[10.1.1.26]> In-Reply-To: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> References: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Disman] Re: To-do items left over from San Francisco Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 20:03:36 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Randy, -- Randy Presuhn wrote on 13 June 2003 09:24 -0700: > Hi - > > I looked through the minutes from our meeting in San Francisco, and > it looks like the following items remain to be done: > >| 1. Sharon Chisholm tasked with drafting a "Thank You" message to the >| ITU-T Liaison, and sending the draft to the DISMAN wg. > > Sharon? > >| 8. For Script MIB and Schedule MIB - Randy to look at a questionnaire >| for implementation requests on these MIBs. > > Mea culpa. > >| 9. Remops MIB - if anyone is interested in assiting with edits, to >| contact RP on the disman mailing list. >| >| 10. Octet String in Remops MIB for payload - has a constraint related to >| ipv4 - computes >| pkt size - ipv4 hdr size. Need description clarification on what the >| object should do (return an error or silently truncate payload size) >| when transport type is ipv6 - Randy Presuhn suggested silently >| truncating. Need further >| discussion on the mailing list. This action item is assigned to Randy >| Presunhn. > > Juergen Quittek accepted the job of handling > the edits. Juergen, where are we? I collected all remops issues from the mailing list since publication of the RFC incluing the issue on the RFC errata web page. I will reply on your suggestion in a separate message. Juergen >| 10. Ram Kavasseri to initiate thread on taking Expression MIB to >| historic status. > > This happened, but I don't feel like we really reached much of > a conlusion. The current practice is to produce an informational > RFC to explain a decision to reclassify a document as "historic". > I didn't see a massive outpouring of volunteer effort to produce > such a document, so I'd rather spend our editor cycles on things > that clearly have a higher priority. > >| 12. Need interoperability results (for event and notif-log mibs) summary >| on wg mailing list. >| Ram Kavasseri to drive the interoperability test effort. Results >| need to be posted to the wg by May. > > Ram? > >| 13. NetSNMP implements the EVENT-MIB - this MIB is the target of >| internal polling >| for NetSNMP apps. Wes Hardaker to provide pointers on how to set up a >| copy >| of NetSNMP running the EVENT-MIB for interoperability testing. > > Wes? > >| 14. Sharon to check and report back on implementations of log MIB at >| Nortel. > > Sharon? > >| 15. Updates for Expr, Event, Notif-Log MIB expected by April 1st. >| Editor needs to look at latest version of ID nits doc, the update to the >| RFC authors >| guidelines - for the ARC MIB update, as well as the latest guidelines >| for MIB reviewers. > > Ram has already responded on this; beware the fast-approaching i-d cutoff. > >| 16. Ram to repost implementation requests for the event, expression and >| notif-log mibs on the disman wg. > > Ram? > > If any of these are already done, please let me know. > If any of the items that I thought was done isn't, I'd like > to know about that as well. > > Randy > > From mailnull@www1.ietf.org Fri Jun 13 14:39:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17848 for ; Fri, 13 Jun 2003 14:39:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DIcv015543 for disman-archive@odin.ietf.org; Fri, 13 Jun 2003 14:38:57 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIcrm14376 for ; Fri, 13 Jun 2003 14:38:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17754 for ; Fri, 13 Jun 2003 14:38:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QtPl-0000Jb-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 14:36:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QtPk-0000JV-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 14:36:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DID0a15888; Fri, 13 Jun 2003 14:13:00 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIChm15511 for ; Fri, 13 Jun 2003 14:12:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16489 for ; Fri, 13 Jun 2003 14:12:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qt0S-00005c-00 for disman@ietf.org; Fri, 13 Jun 2003 14:10:32 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 19Qt0R-00005Y-00 for disman@ietf.org; Fri, 13 Jun 2003 14:10:31 -0400 Received: from h-68-165-65-37.snvacaid.covad.net ([68.165.65.37] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Qt2S-000516-00 for disman@ietf.org; Fri, 13 Jun 2003 11:12:36 -0700 Message-ID: <000b01c331d6$3e1790c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> <3EEA0A88.9030507@cisco.com> Subject: Re: [Disman] To-do items left over from San Francisco X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 11:04:32 -0700 Hi - > From: "Ramanathan Kavasseri" > To: "Randy Presuhn" > Cc: "Disman (E-mail)" ; "Sharon Chisholm" ; ; "Wes Hardaker" > Sent: Friday, June 13, 2003 10:31 AM > Subject: Re: [Disman] To-do items left over from San Francisco > > I was about to post the revised event mib draft, but realized > that I don't have Bob Stewart's latest contact information. > > The info in the draft still points to "Cisco Systems, Inc.", > which isn't true anymore. > > Anyone have a more upto-date address? Or an alternative suggestion? ... I think the solution adopted in http://www.ietf.org/rfc/rfc3410.txt is fine. Randy From mailnull@www1.ietf.org Fri Jun 13 14:39:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17849 for ; Fri, 13 Jun 2003 14:39:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DIcur14597 for disman-archive@odin.ietf.org; Fri, 13 Jun 2003 14:38:56 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIcqm13687 for ; Fri, 13 Jun 2003 14:38:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17748 for ; Fri, 13 Jun 2003 14:38:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QtPk-0000JQ-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 14:36:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QtPj-0000JN-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 14:36:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHX1a28573; Fri, 13 Jun 2003 13:33:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHWam26907 for ; Fri, 13 Jun 2003 13:32:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14905 for ; Fri, 13 Jun 2003 13:32:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsNc-0007Rs-00 for disman@ietf.org; Fri, 13 Jun 2003 13:30:25 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19QsNb-0007RM-00 for disman@ietf.org; Fri, 13 Jun 2003 13:30:24 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5DHVrjc018608; Fri, 13 Jun 2003 10:31:53 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIC41482; Fri, 13 Jun 2003 10:26:39 -0700 (PDT) Message-ID: <3EEA0A88.9030507@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn CC: "Disman (E-mail)" , Sharon Chisholm , quittek@ccrle.nec.de, Wes Hardaker Subject: Re: [Disman] To-do items left over from San Francisco References: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 10:31:52 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was about to post the revised event mib draft, but realized that I don't have Bob Stewart's latest contact information. The info in the draft still points to "Cisco Systems, Inc.", which isn't true anymore. Anyone have a more upto-date address? Or an alternative suggestion? Ram Randy Presuhn wrote: > Hi - > > I looked through the minutes from our meeting in San Francisco, and > it looks like the following items remain to be done: > > | 1. Sharon Chisholm tasked with drafting a "Thank You" message to the > | ITU-T Liaison, and sending the draft to the DISMAN wg. > > Sharon? > > | 8. For Script MIB and Schedule MIB - Randy to look at a questionnaire > | for implementation requests on these MIBs. > > Mea culpa. > > | 9. Remops MIB - if anyone is interested in assiting with edits, to > | contact RP on the disman mailing list. > | > | 10. Octet String in Remops MIB for payload - has a constraint related to > | ipv4 - computes > | pkt size - ipv4 hdr size. Need description clarification on what the > | object should do (return an error or silently truncate payload size) > | when transport type is ipv6 - Randy Presuhn suggested silently > | truncating. Need further > | discussion on the mailing list. This action item is assigned to Randy > | Presunhn. > > Juergen Quittek accepted the job of handling > the edits. Juergen, where are we? > > | 10. Ram Kavasseri to initiate thread on taking Expression MIB to > | historic status. > > This happened, but I don't feel like we really reached much of > a conlusion. The current practice is to produce an informational > RFC to explain a decision to reclassify a document as "historic". > I didn't see a massive outpouring of volunteer effort to produce > such a document, so I'd rather spend our editor cycles on things > that clearly have a higher priority. > > | 12. Need interoperability results (for event and notif-log mibs) summary > | on wg mailing list. > | Ram Kavasseri to drive the interoperability test effort. Results > |need to be posted to the wg by May. > > Ram? > > | 13. NetSNMP implements the EVENT-MIB - this MIB is the target of > | internal polling > | for NetSNMP apps. Wes Hardaker to provide pointers on how to set up a > | copy > | of NetSNMP running the EVENT-MIB for interoperability testing. > > Wes? > > | 14. Sharon to check and report back on implementations of log MIB at > | Nortel. > > Sharon? > > | 15. Updates for Expr, Event, Notif-Log MIB expected by April 1st. > | Editor needs to look at latest version of ID nits doc, the update to the > | RFC authors > | guidelines - for the ARC MIB update, as well as the latest guidelines > | for MIB reviewers. > > Ram has already responded on this; beware the fast-approaching i-d cutoff. > > | 16. Ram to repost implementation requests for the event, expression and > | notif-log mibs on the disman wg. > > Ram? > > If any of these are already done, please let me know. > If any of the items that I thought was done isn't, I'd like > to know about that as well. > > Randy > > From mailnull@www1.ietf.org Fri Jun 13 14:39:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17865 for ; Fri, 13 Jun 2003 14:39:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DIcwt16551 for disman-archive@odin.ietf.org; Fri, 13 Jun 2003 14:38:58 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIcsm15003 for ; Fri, 13 Jun 2003 14:38:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17760 for ; Fri, 13 Jun 2003 14:38:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QtPm-0000Jp-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 14:36:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QtPl-0000Ji-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 14:36:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIF1a17373; Fri, 13 Jun 2003 14:15:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIE7m16780 for ; Fri, 13 Jun 2003 14:14:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16550 for ; Fri, 13 Jun 2003 14:14:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qt1n-00006K-00 for disman@ietf.org; Fri, 13 Jun 2003 14:11:55 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 19Qt1i-00006H-00 for disman@ietf.org; Fri, 13 Jun 2003 14:11:55 -0400 Received: from h-68-165-65-37.snvacaid.covad.net ([68.165.65.37] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Qt3n-0007I2-00 for disman@ietf.org; Fri, 13 Jun 2003 11:13:59 -0700 Message-ID: <001001c331d6$6f0a1540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> <4275788.1055534615@[10.1.1.26]> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Re: To-do items left over from San Francisco Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 11:05:55 -0700 Hi - > From: "Juergen Quittek" > To: "Randy Presuhn" ; "Disman (E-mail)" > Cc: "Ram Kavasseri" ; "Sharon Chisholm" ; "Wes Hardaker" > Sent: Friday, June 13, 2003 11:03 AM > Subject: Re: To-do items left over from San Francisco .... > >| 10. Octet String in Remops MIB for payload - has a constraint related to > >| ipv4 - computes > >| pkt size - ipv4 hdr size. Need description clarification on what the > >| object should do (return an error or silently truncate payload size) > >| when transport type is ipv6 - Randy Presuhn suggested silently > >| truncating. Need further > >| discussion on the mailing list. This action item is assigned to Randy > >| Presunhn. > > > > Juergen Quittek accepted the job of handling > > the edits. Juergen, where are we? > > I collected all remops issues from the mailing list since > publication of the RFC incluing the issue on the RFC errata > web page. > > I will reply on your suggestion in a separate message. ... Great! Thanks for the quick response. Randy From mailnull@www1.ietf.org Fri Jun 13 15:26:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17859 for ; Fri, 13 Jun 2003 14:39:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DIcvx16133 for disman-archive@odin.ietf.org; Fri, 13 Jun 2003 14:38:57 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIcsm14489 for ; Fri, 13 Jun 2003 14:38:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17751 for ; Fri, 13 Jun 2003 14:38:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QtPl-0000JY-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 14:36:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QtPk-0000JS-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 14:36:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIM1a20848; Fri, 13 Jun 2003 14:22:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DILPm20571 for ; Fri, 13 Jun 2003 14:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16695 for ; Fri, 13 Jun 2003 14:21:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qt8s-00008v-00 for disman@ietf.org; Fri, 13 Jun 2003 14:19:14 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 19Qt8r-00008s-00 for disman@ietf.org; Fri, 13 Jun 2003 14:19:13 -0400 Received: from h-68-165-65-37.snvacaid.covad.net ([68.165.65.37] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19QtAw-0003CA-00 for disman@ietf.org; Fri, 13 Jun 2003 11:21:22 -0700 Message-ID: <002001c331d7$6fb3f460$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Regarding -00- disman documents Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 11:13:05 -0700 Hi - If you're planning to produce an internet draft with a filename that looks like "draft-ietf-disman-*-00.txt", I need to know about it posthaste so that I can provide the list of expected drafts to the secretariat. Randy From disman-admin@ietf.org Fri Jun 13 15:26:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17604 for ; Fri, 13 Jun 2003 14:37:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DID0a15888; Fri, 13 Jun 2003 14:13:00 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DIChm15511 for ; Fri, 13 Jun 2003 14:12:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16489 for ; Fri, 13 Jun 2003 14:12:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qt0S-00005c-00 for disman@ietf.org; Fri, 13 Jun 2003 14:10:32 -0400 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 19Qt0R-00005Y-00 for disman@ietf.org; Fri, 13 Jun 2003 14:10:31 -0400 Received: from h-68-165-65-37.snvacaid.covad.net ([68.165.65.37] helo=oemcomputer) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Qt2S-000516-00 for disman@ietf.org; Fri, 13 Jun 2003 11:12:36 -0700 Message-ID: <000b01c331d6$3e1790c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> <3EEA0A88.9030507@cisco.com> Subject: Re: [Disman] To-do items left over from San Francisco X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 11:04:32 -0700 Hi - > From: "Ramanathan Kavasseri" > To: "Randy Presuhn" > Cc: "Disman (E-mail)" ; "Sharon Chisholm" ; ; "Wes Hardaker" > Sent: Friday, June 13, 2003 10:31 AM > Subject: Re: [Disman] To-do items left over from San Francisco > > I was about to post the revised event mib draft, but realized > that I don't have Bob Stewart's latest contact information. > > The info in the draft still points to "Cisco Systems, Inc.", > which isn't true anymore. > > Anyone have a more upto-date address? Or an alternative suggestion? ... I think the solution adopted in http://www.ietf.org/rfc/rfc3410.txt is fine. Randy From disman-admin@ietf.org Fri Jun 13 20:58:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00317 for ; Fri, 13 Jun 2003 20:58:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNL0a00429; Fri, 13 Jun 2003 19:21:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNKTm00396 for ; Fri, 13 Jun 2003 19:20:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28152 for ; Fri, 13 Jun 2003 19:20:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QxoJ-0002Fs-00 for disman@ietf.org; Fri, 13 Jun 2003 19:18:19 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QxoI-0002FR-00 for disman@ietf.org; Fri, 13 Jun 2003 19:18:18 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5DNJuVI070974; Sat, 14 Jun 2003 01:19:57 +0200 (CEST) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C739DAD1FD; Sat, 14 Jun 2003 01:06:22 +0200 (CEST) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] Regarding -00- disman documents Message-ID: <23391535.1055553731@[10.1.1.26]> In-Reply-To: <002001c331d7$6fb3f460$7f1afea9@oemcomputer> References: <002001c331d7$6fb3f460$7f1afea9@oemcomputer> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 14 Jun 2003 01:22:12 +0200 Content-Transfer-Encoding: 7bit Randy, I plan to submit draft-ietf-disman-remops-mib-v2-00.txt until the 23rd, although there is no real need to meet the deadline without a disman session in Vienna. Juergen -- Randy Presuhn wrote on 13 June 2003 11:13 -0700: > Hi - > > If you're planning to produce an internet draft with a filename > that looks like "draft-ietf-disman-*-00.txt", I need to know > about it posthaste so that I can provide the list of expected > drafts to the secretariat. > > Randy > > From mailnull@www1.ietf.org Fri Jun 13 20:59:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00357 for ; Fri, 13 Jun 2003 20:59:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E0wsi07197 for disman-archive@odin.ietf.org; Fri, 13 Jun 2003 20:58:54 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E0wsm07194 for ; Fri, 13 Jun 2003 20:58:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00351 for ; Fri, 13 Jun 2003 20:58:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QzLX-0002p2-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 20:56:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QzLW-0002oz-00 for disman-web-archive@ietf.org; Fri, 13 Jun 2003 20:56:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNL0a00429; Fri, 13 Jun 2003 19:21:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DNKTm00396 for ; Fri, 13 Jun 2003 19:20:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28152 for ; Fri, 13 Jun 2003 19:20:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QxoJ-0002Fs-00 for disman@ietf.org; Fri, 13 Jun 2003 19:18:19 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19QxoI-0002FR-00 for disman@ietf.org; Fri, 13 Jun 2003 19:18:18 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5DNJuVI070974; Sat, 14 Jun 2003 01:19:57 +0200 (CEST) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C739DAD1FD; Sat, 14 Jun 2003 01:06:22 +0200 (CEST) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] Regarding -00- disman documents Message-ID: <23391535.1055553731@[10.1.1.26]> In-Reply-To: <002001c331d7$6fb3f460$7f1afea9@oemcomputer> References: <002001c331d7$6fb3f460$7f1afea9@oemcomputer> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 14 Jun 2003 01:22:12 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randy, I plan to submit draft-ietf-disman-remops-mib-v2-00.txt until the 23rd, although there is no real need to meet the deadline without a disman session in Vienna. Juergen -- Randy Presuhn wrote on 13 June 2003 11:13 -0700: > Hi - > > If you're planning to produce an internet draft with a filename > that looks like "draft-ietf-disman-*-00.txt", I need to know > about it posthaste so that I can provide the list of expected > drafts to the secretariat. > > Randy > > From disman-admin@ietf.org Sat Jun 14 02:52:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20285 for ; Sat, 14 Jun 2003 02:52:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMp1a30311; Fri, 13 Jun 2003 18:51:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMoWm30236 for ; Fri, 13 Jun 2003 18:50:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26953; Fri, 13 Jun 2003 18:49:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QxKM-0001wW-00; Fri, 13 Jun 2003 18:47:22 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19QxKJ-0001wG-00; Fri, 13 Jun 2003 18:47:19 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5DMmcmu004685; Fri, 13 Jun 2003 15:48:40 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIC76213; Fri, 13 Jun 2003 15:43:22 -0700 (PDT) Message-ID: <3EEA54C5.6090001@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts CC: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Disman] Please accept draft-ietf-disman-notif-log-mib-v2-02.txt for posting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 15:48:37 -0700 Content-Transfer-Encoding: 7bit Please accept draft-ietf-disman-notif-log-mib-v2-02.txt for posting as an internet-draft. Thank you, Ram Kavasseri Disman Working Group R. Kavasseri Internet Draft Cisco Systems, Inc. Document: draft-ietf-disman-notif-log-mib-v2-02.txt B. Stewart Expiration Date: December 2003 Retired June 2003 Notification Log MIB 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 (2003). All Rights Reserved. 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 Simple Internet Draft Notification Log MIB 13 June 2003 Network Management Protocol (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. Expires December 2003 [Page 2] Internet Draft Notification Log MIB 13 June 2003 Table of Contents 1 The SNMP Management Framework ................................. 2 2 Overview ...................................................... 3 2.1 Environment ................................................. 3 2.1.1 SNMP Engines and Contexts ................................. 4 2.1.2 Security .................................................. 4 2.2 Structure ................................................... 5 2.2.1 Configuration ............................................. 5 2.2.2 Statistics ................................................ 6 2.2.3 Log ....................................................... 6 2.3 Example ..................................................... 6 3 Definitions ................................................... 7 4 Intellectual Property ......................................... 23 5 References .................................................... 23 6 Security Considerations ....................................... 25 7 Author's Address .............................................. 25 8 Full Copyright Statement ...................................... 26 1. 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], STD 58, RFC 2579 [RFC2579] and STD 58, 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 Expires December 2003 [Page 3] Internet Draft Notification Log MIB 13 June 2003 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]. 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. 2. 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. 2.1. Environment The overall environmental concerns for the MIB are: Expires December 2003 [Page 4] Internet Draft Notification Log MIB 13 June 2003 o SNMP Engines and Contexts o Security Expires December 2003 [Page 5] Internet Draft Notification Log MIB 13 June 2003 2.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. 2.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 Expires December 2003 [Page 6] Internet Draft Notification Log MIB 13 June 2003 administrator can provide different access for different users. When an application creates a named log the security credentials of the creator stay associated with that log. Expires December 2003 [Page 7] Internet Draft Notification Log MIB 13 June 2003 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. 2.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. 2.2.1. Configuration The configuration section contains objects to manage resource use by the MIB. Expires December 2003 [Page 8] Internet Draft Notification Log MIB 13 June 2003 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. 2.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. 2.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. 2.3. Example Following is an example configuration of a named log for logging only linkUp and linkDown Notifications. In nlmConfigLogTable: 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 Expires December 2003 [Page 9] Internet Draft Notification Log MIB 13 June 2003 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 3. 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 "200306130000Z" -- 13 June 2003 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Expires December 2003 [Page 10] Internet Draft Notification Log MIB 13 June 2003 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. Copyright (C) The Internet Society 2003. This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this note -- Revision History REVISION "200306130000Z" -- 13 June 2003 DESCRIPTION "Added copyright statement to the MIB module description." REVISION "200011270000Z" -- 27 November 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC 3014" ::= { mib-2 92 } notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section -- 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 Expires December 2003 [Page 11] Internet Draft Notification Log MIB 13 June 2003 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." DEFVAL { 1440 } -- 24 hours ::= { nlmConfig 2 } -- -- Basic Log Configuration Table -- nlmConfigLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogEntry Expires December 2003 [Page 12] Internet Draft Notification Log MIB 13 June 2003 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 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 Expires December 2003 [Page 13] Internet Draft Notification Log MIB 13 June 2003 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) } 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 } Expires December 2003 [Page 14] Internet Draft Notification Log MIB 13 June 2003 ::= { 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. 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 -- Expires December 2003 [Page 15] Internet Draft Notification Log MIB 13 June 2003 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 } nlmStatsLogEntry OBJECT-TYPE SYNTAX NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log statistics entry." AUGMENTS { nlmConfigLogEntry } ::= { nlmStatsLogTable 1 } NlmStatsLogEntry ::= SEQUENCE { Expires December 2003 [Page 16] Internet Draft Notification Log MIB 13 June 2003 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 -- 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. Expires December 2003 [Page 17] Internet Draft Notification Log MIB 13 June 2003 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 } NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogDateAndTime DateAndTime, nlmLogEngineID SnmpEngineID, nlmLogEngineTAddress TAddress, nlmLogEngineTDomain TDomain, nlmLogContextEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, nlmLogNotificationID OBJECT IDENTIFIER Expires December 2003 [Page 18] Internet Draft Notification Log MIB 13 June 2003 } 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 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 } Expires December 2003 [Page 19] Internet Draft Notification Log MIB 13 June 2003 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 } 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 } Expires December 2003 [Page 20] Internet Draft Notification Log MIB 13 June 2003 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 identifier 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 "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, Expires December 2003 [Page 21] Internet Draft Notification Log MIB 13 June 2003 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 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 Expires December 2003 [Page 22] Internet Draft Notification Log MIB 13 June 2003 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 } nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'. Although this seems to be unfriendly for IPv6, we have to recognize that there are a number of older MIBs that do contain an IPv4 format address, known Expires December 2003 [Page 23] Internet Draft Notification Log MIB 13 June 2003 as IpAddress. IPv6 addresses are represented using TAddress or InetAddress, and so the underlying datatype is OCTET STRING, and their value would be stored in the nlmLogVariableOctetStringVal column." ::= { 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 December 2003 [Page 24] Internet Draft Notification Log MIB 13 June 2003 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 December 2003 [Page 25] Internet Draft Notification Log MIB 13 June 2003 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, nlmLogVariableCounter64Val, Expires December 2003 [Page 26] Internet Draft Notification Log MIB 13 June 2003 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 4. 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. 5. References Expires December 2003 [Page 27] Internet Draft Notification Log MIB 13 June 2003 [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] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. Expires December 2003 [Page 28] Internet Draft Notification Log MIB 13 June 2003 [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 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. Expires December 2003 [Page 29] Internet Draft Notification Log MIB 13 June 2003 [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. 6. Security Considerations Security issues are discussed in Section 2.1.2. 7. Authors' Addresses 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 December 2003 [Page 30] Internet Draft Notification Log MIB 13 June 2003 8. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 December 2003 [Page 31] From mailnull@www1.ietf.org Sat Jun 14 02:54:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20325 for ; Sat, 14 Jun 2003 02:54:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E6rpX09920 for disman-archive@odin.ietf.org; Sat, 14 Jun 2003 02:53:51 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E6rom09916 for ; Sat, 14 Jun 2003 02:53:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20303 for ; Sat, 14 Jun 2003 02:53:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R4sz-00054S-00 for disman-web-archive@ietf.org; Sat, 14 Jun 2003 02:51:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R4sy-00054P-00 for disman-web-archive@ietf.org; Sat, 14 Jun 2003 02:51:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMp1a30311; Fri, 13 Jun 2003 18:51:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMoWm30236 for ; Fri, 13 Jun 2003 18:50:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26953; Fri, 13 Jun 2003 18:49:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QxKM-0001wW-00; Fri, 13 Jun 2003 18:47:22 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19QxKJ-0001wG-00; Fri, 13 Jun 2003 18:47:19 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5DMmcmu004685; Fri, 13 Jun 2003 15:48:40 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIC76213; Fri, 13 Jun 2003 15:43:22 -0700 (PDT) Message-ID: <3EEA54C5.6090001@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts CC: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Disman] Please accept draft-ietf-disman-notif-log-mib-v2-02.txt for posting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 15:48:37 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please accept draft-ietf-disman-notif-log-mib-v2-02.txt for posting as an internet-draft. Thank you, Ram Kavasseri Disman Working Group R. Kavasseri Internet Draft Cisco Systems, Inc. Document: draft-ietf-disman-notif-log-mib-v2-02.txt B. Stewart Expiration Date: December 2003 Retired June 2003 Notification Log MIB 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 (2003). All Rights Reserved. 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 Simple Internet Draft Notification Log MIB 13 June 2003 Network Management Protocol (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. Expires December 2003 [Page 2] Internet Draft Notification Log MIB 13 June 2003 Table of Contents 1 The SNMP Management Framework ................................. 2 2 Overview ...................................................... 3 2.1 Environment ................................................. 3 2.1.1 SNMP Engines and Contexts ................................. 4 2.1.2 Security .................................................. 4 2.2 Structure ................................................... 5 2.2.1 Configuration ............................................. 5 2.2.2 Statistics ................................................ 6 2.2.3 Log ....................................................... 6 2.3 Example ..................................................... 6 3 Definitions ................................................... 7 4 Intellectual Property ......................................... 23 5 References .................................................... 23 6 Security Considerations ....................................... 25 7 Author's Address .............................................. 25 8 Full Copyright Statement ...................................... 26 1. 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], STD 58, RFC 2579 [RFC2579] and STD 58, 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 Expires December 2003 [Page 3] Internet Draft Notification Log MIB 13 June 2003 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]. 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. 2. 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. 2.1. Environment The overall environmental concerns for the MIB are: Expires December 2003 [Page 4] Internet Draft Notification Log MIB 13 June 2003 o SNMP Engines and Contexts o Security Expires December 2003 [Page 5] Internet Draft Notification Log MIB 13 June 2003 2.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. 2.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 Expires December 2003 [Page 6] Internet Draft Notification Log MIB 13 June 2003 administrator can provide different access for different users. When an application creates a named log the security credentials of the creator stay associated with that log. Expires December 2003 [Page 7] Internet Draft Notification Log MIB 13 June 2003 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. 2.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. 2.2.1. Configuration The configuration section contains objects to manage resource use by the MIB. Expires December 2003 [Page 8] Internet Draft Notification Log MIB 13 June 2003 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. 2.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. 2.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. 2.3. Example Following is an example configuration of a named log for logging only linkUp and linkDown Notifications. In nlmConfigLogTable: 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 Expires December 2003 [Page 9] Internet Draft Notification Log MIB 13 June 2003 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 3. 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 "200306130000Z" -- 13 June 2003 ORGANIZATION "IETF Distributed Management Working Group" CONTACT-INFO "Ramanathan Kavasseri Expires December 2003 [Page 10] Internet Draft Notification Log MIB 13 June 2003 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. Copyright (C) The Internet Society 2003. This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this note -- Revision History REVISION "200306130000Z" -- 13 June 2003 DESCRIPTION "Added copyright statement to the MIB module description." REVISION "200011270000Z" -- 27 November 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC 3014" ::= { mib-2 92 } notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } -- -- Configuration Section -- 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 Expires December 2003 [Page 11] Internet Draft Notification Log MIB 13 June 2003 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." DEFVAL { 1440 } -- 24 hours ::= { nlmConfig 2 } -- -- Basic Log Configuration Table -- nlmConfigLogTable OBJECT-TYPE SYNTAX SEQUENCE OF NlmConfigLogEntry Expires December 2003 [Page 12] Internet Draft Notification Log MIB 13 June 2003 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 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 Expires December 2003 [Page 13] Internet Draft Notification Log MIB 13 June 2003 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) } 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 } Expires December 2003 [Page 14] Internet Draft Notification Log MIB 13 June 2003 ::= { 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. 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 -- Expires December 2003 [Page 15] Internet Draft Notification Log MIB 13 June 2003 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 } nlmStatsLogEntry OBJECT-TYPE SYNTAX NlmStatsLogEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A Notification log statistics entry." AUGMENTS { nlmConfigLogEntry } ::= { nlmStatsLogTable 1 } NlmStatsLogEntry ::= SEQUENCE { Expires December 2003 [Page 16] Internet Draft Notification Log MIB 13 June 2003 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 -- 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. Expires December 2003 [Page 17] Internet Draft Notification Log MIB 13 June 2003 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 } NlmLogEntry ::= SEQUENCE { nlmLogIndex Unsigned32, nlmLogTime TimeStamp, nlmLogDateAndTime DateAndTime, nlmLogEngineID SnmpEngineID, nlmLogEngineTAddress TAddress, nlmLogEngineTDomain TDomain, nlmLogContextEngineID SnmpEngineID, nlmLogContextName SnmpAdminString, nlmLogNotificationID OBJECT IDENTIFIER Expires December 2003 [Page 18] Internet Draft Notification Log MIB 13 June 2003 } 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 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 } Expires December 2003 [Page 19] Internet Draft Notification Log MIB 13 June 2003 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 } 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 } Expires December 2003 [Page 20] Internet Draft Notification Log MIB 13 June 2003 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 identifier 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 "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, Expires December 2003 [Page 21] Internet Draft Notification Log MIB 13 June 2003 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 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 Expires December 2003 [Page 22] Internet Draft Notification Log MIB 13 June 2003 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 } nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'. Although this seems to be unfriendly for IPv6, we have to recognize that there are a number of older MIBs that do contain an IPv4 format address, known Expires December 2003 [Page 23] Internet Draft Notification Log MIB 13 June 2003 as IpAddress. IPv6 addresses are represented using TAddress or InetAddress, and so the underlying datatype is OCTET STRING, and their value would be stored in the nlmLogVariableOctetStringVal column." ::= { 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 December 2003 [Page 24] Internet Draft Notification Log MIB 13 June 2003 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 December 2003 [Page 25] Internet Draft Notification Log MIB 13 June 2003 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, nlmLogVariableCounter64Val, Expires December 2003 [Page 26] Internet Draft Notification Log MIB 13 June 2003 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 4. 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. 5. References Expires December 2003 [Page 27] Internet Draft Notification Log MIB 13 June 2003 [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] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. Expires December 2003 [Page 28] Internet Draft Notification Log MIB 13 June 2003 [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 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. Expires December 2003 [Page 29] Internet Draft Notification Log MIB 13 June 2003 [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. 6. Security Considerations Security issues are discussed in Section 2.1.2. 7. Authors' Addresses 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 December 2003 [Page 30] Internet Draft Notification Log MIB 13 June 2003 8. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 December 2003 [Page 31] From disman-admin@ietf.org Sat Jun 14 02:58:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20453 for ; Sat, 14 Jun 2003 02:58:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMn1a30172; Fri, 13 Jun 2003 18:49:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMm6m30141 for ; Fri, 13 Jun 2003 18:48:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26854; Fri, 13 Jun 2003 18:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QxI0-0001vQ-00; Fri, 13 Jun 2003 18:44:56 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19QxHw-0001vE-00; Fri, 13 Jun 2003 18:44:52 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5DMkSje009611; Fri, 13 Jun 2003 15:46:29 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIC75991; Fri, 13 Jun 2003 15:41:12 -0700 (PDT) Message-ID: <3EEA5443.1030600@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts CC: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Disman] Please accept draft-ietf-disman-express-mib-v2-03.txt for posting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 15:46:27 -0700 Content-Transfer-Encoding: 7bit Please accept draft-ietf-disman-express-mib-v2-03.txt for posting as an Internet-Draft. Thanks, Ram Kavasseri Disman Working Group R. Kavasseri Internet Draft Cisco Systems, Inc. Document: draft-ietf-disman-express-mib-v2-03.txt B. Stewart Expiration Date: December 2003 Retired June 2003 Distributed Management Expression MIB 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 (2003). All Rights Reserved. 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 managing expressions of MIB objects. The results of these expressions become Internet Draft Expression MIB 13 June 2003 MIB objects usable like any other MIB object, such as for the test condition for declaring an event. 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. Table of Contents 1 The SNMP Management Framework ............................... 2 2 Overview .................................................... 3 2.1 Usage ..................................................... 4 2.2 Persistence ............................................... 4 2.3 Operation ................................................. 4 2.3.1 Sampling ................................................ 5 2.3.2 Wildcards ............................................... 5 2.3.3 Evaluation .............................................. 5 2.3.4 Value Identification .................................... 6 2.4 Subsets ................................................... 6 2.4.1 No Wildcards ............................................ 6 2.4.2 No Deltas ............................................... 7 2.5 Structure ................................................. 7 2.5.1 Resource ................................................ 7 2.5.2 Definition .............................................. 7 2.5.3 Value ................................................... 8 2.6 Examples .................................................. 8 2.6.1 Wildcarding ............................................. 8 2.6.2 Calculation and Conditional ............................. 10 3 Definitions ................................................. 12 4 Intellectual Property ....................................... 36 5 Acknowledgements ............................................ 37 6 References .................................................. 37 7 Security Considerations ..................................... 38 8 Author's Address ............................................ 40 9 Editor's Address ............................................ 40 10 Full Copyright Statement ................................... 41 1. 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 Expires December 2003 [Page 2] Internet Draft Expression MIB 13 June 2003 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], STD 58, RFC 2579 [RFC2579] and STD 58, 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]. Expires December 2003 [Page 3] Internet Draft Expression MIB 13 June 2003 o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. 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. 2. Overview Users of MIBs often desire MIB objects that MIB designers have not provided. Furthermore, such needs vary from one management philosophy to another. Rather than fill more and more MIBs with standardized objects, the Expression MIB supports externally defined expressions of existing MIB objects. In the Expression MIB the results of an evaluated expression are MIB objects that may be used like any other MIB objects. These custom- defined objects are thus usable anywhere any other MIB object can be used. For example, they can be used by a management application directly or referenced from another MIB, such as the Event MIB [MIBEventMIB]. They can even be used by the Expression MIB itself, forming expressions of expressions. The Expression MIB is instrumentation for a relatively powerful, complex, high-level application, considerably different from simple instrumentation for a communication driver or a protocol. The MIB is appropriate in a relatively powerful, resource-rich managed system and not necessarily in a severely limited environment. Nevertheless, due to dependencies from the Event MIB [RFC2981] and the need to support as low-end a system as possible, the Expression Expires December 2003 [Page 4] Internet Draft Expression MIB 13 June 2003 MIB can be somewhat stripped down for lower-power, lower-resource implementations, as described in the Subsets section, below. Implementation of the Expression MIB in a managed system led to the addition of objects that may not have been necessary in an application environment with complete knowledge of compiled MIB definitions. This is appropriate since implementation must be possible within typical managed systems with some constraints on system resources. 2.1. Usage On managed systems that can afford the overhead, the Expression MIB is a way to create new, customized MIB objects for monitoring. Although these can save some network traffic and overhead on management systems, that is often not a good tradeoff for objects that are simply to be recorded or displayed. An example of a use of the Expression MIB would be to provide custom objects for the Event MIB [RFC2981]. A complex expression can evaluate to a rate of flow or a boolean and thus be subject to testing as an event trigger, resulting in an SNMP notification. Without these capabilities such monitoring would be limited to the objects in predefined MIBs. The Expression MIB thus supports powerful tools for the network manager faced with the monitoring of large, complex systems that can support a significant level of self management. 2.2. Persistence Although like most MIBs this one has no explicit controls for the persistence of the values set in configuring an expression, a robust, polite implementation would certainly not force its managing applications to reconfigure it whenever it resets. Again, as with most MIBs, it is implementation specific how a system provides and manages such persistence. To speculate, one could imagine, for example, that persistence depended on the context in which the expression was configured, or perhaps system-specific characteristics of the expression's owner. Or perhaps everything in a MIB such as this one, which is clearly aimed at persistent configuration, is automatically part of a system's other persistent configuration. 2.3. Operation Expires December 2003 [Page 5] Internet Draft Expression MIB 13 June 2003 Most of the operation of the MIB is described or implied in the object definitions but a few highlights bear mentioning here. Expires December 2003 [Page 6] Internet Draft Expression MIB 13 June 2003 2.3.1. Sampling The MIB supports three types of object sampling for the MIB objects that make up the expression: absolute, delta, and changed. Absolute samples are simply the value of the MIB object at the time it is sampled. Absolute samples are not sufficient for expressions of counters, as counters have meaning only as a delta (difference) from one sample to the next. Thus objects may be sampled as deltas. Delta sampling requires the application to maintain state for the value at the last sample, and to do continuous sampling whether or not anyone is looking at the results. It thus creates constant overhead. Changed sampling is a simple fallout of delta sampling where rather than a difference the result is a boolean indicating whether or not the object changed value since the last sample. 2.3.2. Wildcards Wildcards allow the application of a single expression to multiple instances of the same MIB object. The definer of the expression indicates this choice and provides a partial object identifier, with some or all of the instance portion left off. The application then does the equivalent of GetNext to obtain the object values, thus discovering the instances. All wildcarded objects in an expression must have the same semantics for the missing portion of their object identifiers. Otherwise, any successful evaluation of the wildcarded expression would be the result of the accidental matching of the wildcarded portion of the object identifiers in the expression. Such an evaluation will likely produce results which are not meaningful. The expression can be evaluated only for those instances where all the objects in the expression are available with the same value for the wildcarded portion of the instance. 2.3.3. Evaluation There are two important aspects of evaluation that may not be obvious: what objects and when. What objects get used in the evaluation depends on the type of Expires December 2003 [Page 7] Internet Draft Expression MIB 13 June 2003 request and whether or not the expression contains wildcarded objects. If the request was a Get, that locks down the instances to Expires December 2003 [Page 8] Internet Draft Expression MIB 13 June 2003 be used. If the request was a GetNext or GetBulk, the application must work its way up to the next full set of objects for the expression. Evaluation of expressions happens at two possible times, depending on the sampling method (delta or absolute) used to evaluate the expression. If there are no delta or change values in an expression, the evaluation occurs on demand, i.e. when a requester attempts to read the value of the expression. In this case all requesters get a freshly calculated value. For expressions with delta or change values, evaluation goes on continuously, every sample period. In this case requesters get the value as of the last sample period. For any given sample period of a given expression, only those instances exist that provided a full set of object values. It may be possible that a delta expression which was evaluated successfully for one sample period may not be successfully evaluated in the next sample period. This may, for example, be due to missing instances for some or all of the objects in the expression. In such cases, the value from the previous sample period (with the successful evaluation) must not be carried forward to the next sample period (with the failed evaluation). 2.3.4. Value Identification Values resulting from expression evaluation are identified with a combination of the object identifier (OID) for the data type from expValueTable (such as expValueCounter32Val), the expression owner, the expression name, and an OID fragment. The OID fragment is not an entire OID beginning with iso.dod.org (1.3.6). Rather it begins with 0.0. The remainder is either another 0 when there is no wildcarding or the instance that satisfied the wildcard if there is wildcarding. 2.4. Subsets To pare down the Expression MIBs complexity and use of resources an implementor can leave out various parts. 2.4.1. No Wildcards Leaving out wildcarding significantly reduces the complexity of Expires December 2003 [Page 9] Internet Draft Expression MIB 13 June 2003 retrieving values to evaluate expressions and the processing required to do so. Such an implementation would allow expressions made up of Expires December 2003 [Page 10] Internet Draft Expression MIB 13 June 2003 individual MIB objects but would not be suitable for expressions applied across large tables as each instance in the table would require a separate expression definition. Furthermore it would not be suitable for tables with arbitrary, dynamic instances, as expressions definitions could not predict what instance values to use. An implementation without wildcards might be useful for a self- managing system with small tables or few dynamic instances, or one that can do calculations only for a few key objects. 2.4.2. No Deltas Leaving out delta processing significantly reduces state that must be kept and the burden of ongoing processing even when no one is looking at the results. Unfortunately it also makes expressions on counters unusable, as counters have meaning only as deltas. An implementation without deltas might be useful for a severely limited, self-managing system that has no need for expressions or events on counters. Although conceivable, such systems would be rare. 2.5. Structure The MIB has the following sections: o Resource -- management of the MIB's use of system resources. o Definition -- definition of expressions. o Value -- values of evaluated expressions. 2.5.1. Resource The resource section has objects to manage resource usage by wildcarded delta expressions, a potential major consumer of CPU and memory. 2.5.2. Definition The definition section contains the tables that define expressions. The expression table, indexed by expression owner and expression Expires December 2003 [Page 11] Internet Draft Expression MIB 13 June 2003 name, contains those parameters that apply to the entire expression, such as the expression itself, the data type of the result, and the sampling interval if it contains delta or change values. The object table, indexed by expression owner, expression name and object index within each expression, contains the parameters that apply to the individual objects that go into the expression, including the object identifier, sample type, discontinuity indicator, and such. 2.5.3. Value The value section contains the values of evaluated expressions. The value table, indexed by expression owner, expression name and instance fragment contains a "discriminated union" of evaluated expression results. For a given expression only one of the columns is instantiated, depending on the result data type for the expression. The instance fragment is a constant or the final section of the object identifier that filled in a wildcard. 2.6. Examples The examples refer to tables and objects defined below in the MIB itself. They may well make more sense after reading those definitions. 2.6.1. Wildcarding An expression may use wildcarded MIB objects that result in multiple values for the expression. To specify a wildcarded MIB object a management application leaves off part or all of the instance portion of the object identifier, and sets expObjectWildcard to true(1) for that object. For our example we'll use a counter of total blessings from a table of people. Another table, indexed by town and person has blessings just from that town. So the index clauses are: personEntry OBJECT-TYPE ... INDEX { personIndex } And: Expires December 2003 [Page 12] Internet Draft Expression MIB 13 June 2003 townPersonEntry OBJECT-TYPE ... INDEX { townIndex, personIndex } Expires December 2003 [Page 13] Internet Draft Expression MIB 13 June 2003 In our friendly application we may have entered our expression as: 100 * townPersonBlessings.976.* / personBlessings.* What goes in expExpression is: 100*$1/$2 For example purposes we'll use some slightly far-fetched OIDs. The People MIB is 1.3.6.1.99.7 and the Town MIB is 1.3.6.1.99.11, so for our two counters the OIDs are: personBlessings 1.3.6.1.99.7.1.3.1.4 townPersonBlessings 1.3.6.1.99.11.1.2.1.9 The rule for wildcards is that all the wildcarded parts have to match exactly. In this case that means we have to hardwire the town and only the personIndex can be wildcarded. So our values for expObjectID are: 1.3.6.1.99.7.1.3.1.4 1.3.6.1.99.11.1.2.1.9.976 We're hardwired to townIndex 976 and personIndex is allowed to vary. The value of expExpressionPrefix can be either of those two counter OIDs (including the instance fragment in the second case), since either of them takes you to a MIB definition where you can look at the INDEX clause and figure out what's been left off. What's been left off doesn't have to work out to be the same object, but it does have to work out to be the same values (semantics) for the result to make sense. Note that the managed system can not typically check such semantics and if given nonsense will return nonsense. If we have people numbered 6, 19, and 42 in town number 976, the successive values of expValueInstance will be: 0.0.6 0.0.19 0.0.42 So there will be three values in expValueTable, with those OIDs as the expValueInstance part of their indexing. Expires December 2003 [Page 14] Internet Draft Expression MIB 13 June 2003 2.6.2. Calculation and Conditional The following formula for line utilization of a half-duplex link is adapted from [PracPersp]. utilization = (ifInOctets + ifOutOctets) * 800 / seconds / ifSpeed The expression results in the percentage line utilization per second. The total octets are multiplied by 8 to get bits and 100 to scale up the percentage as an integer. The following Expression MIB object values implement this as an expression for all ifIndexes that directly represent actual hardware. Since the octet counters are Counter32 values, they must be delta sampled to be meaningful. The sample period is 6 seconds but for accuracy and independence is calculated as a delta of sysUpTime. The expObjectTable entry for ifInOctets has an expObjectConditional that checks for being a hardware interface. Only one object in the expression needs that check associated, since it applies to the whole expression. Since ifConnectorPresent is a TruthValue with values of 1 or 2 rather than 0 and non-zero, it must also be in an expression rather than used directly for the conditional. The interface-specific discontinuity indicator is supplied only for ifInOctets since invalidating that sample will invalidate an attempt at evaluation, effectively invalidating ifOutOctets as well (correctly, because it has the same indicator). For notational clarity, in the rest of this document, a string in quotes as part of the object instance indicates the value that would actually be one subidentifier per byte. The objects all belong to owner "me". Also for clarity OIDs are expressed as the object descriptor and instance. In fact they must be supplied numerically, with all subidentifiers in place before the part for the particular object and instance. What the user would set in expExpressionTable: expExpression.2."me".4."hard" = "$1==1" expExpressionValueType.2."me".4."hard" = unsigned32 expExpressionEntryStatus.2."me"4."hard" = 'active' Expires December 2003 [Page 15] Internet Draft Expression MIB 13 June 2003 expExpression.2."me".4."util" = "($1+$2)*800/$4/$3" expExpressionValueType.2."me".4."util" = integer32 expExpressionDeltaInterval.2."me".4."util" = 6 expExpressionEntryStatus.2."me"4."util" = 'active' What the user would set in expObjectTable: expObjectID.2."me".4."hard".1 = ifConnectorPresent expObjectWildcard.2."me".4."hard".1 = 'true' expObjectSampleType.2."me".4."hard".1 = 'absoluteValue' expObjectEntryStatus.2."me".4."hard".1 = 'active' expObjectID.2."me".4."util".1 = ifInOctets expObjectWildcard.2."me".4."util".1 = 'true' expObjectSampleType.2."me".4."util".1 = 'deltaValue' expObjectConditional.2."me".4."util".1 = expValueUnsigned32Val.2."me".4."hard".0.0 expObjectConditionalWildcard.2."me".4."util".1 = 'true' expObjectDiscontinuityID.2."me".4."util".1 = ifCounterDiscontinuityTime expObjectDiscontinuityIDWildcard.2."me".4."util".1 = 'true' expObjectEntryStatus.2."me".4."util".1 = 'active' expObjectID.2."me".4."util".2 = ifOutOctets expObjectWildcard.2."me".4."util".2 = 'true' expObjectSampleType.2."me".4."util".2 = 'deltaValue' expObjectEntryStatus.2."me".4."util".2 = 'active' expObjectID.2."me".4."util".3 = ifSpeed expObjectWildcard.2."me".4."util".3 = 'true' expObjectSampleType.2."me".4."util".3 = 'absoluteValue' expObjectEntryStatus.2."me".4."util".3 = 'active' expObjectID.2."me".4."util".4 = sysUpTime.0 expObjectWildcard.2."me".4."util".4 = 'false' expObjectSampleType.2."me".4."util".4 = 'deltaValue' expObjectEntryStatus.2."me".4."util".4 = 'active' These settings will result in populating one column of expValueTable: expValueInteger32Val.2."me".4."util".0.0.? The subidentifier represented by "?" above represents one subidentifier that takes on a value of ifIndex and identifies a row for each ifIndex value where ifConnectorPresent is 'true' and the Expires December 2003 [Page 16] Internet Draft Expression MIB 13 June 2003 interface was present for two samples to provide a delta. Expires December 2003 [Page 17] Internet Draft Expression MIB 13 June 2003 This value could in turn be used as an event threshold [RFC2981] to watch for overutilization of all hardware network connections. 3. Definitions DISMAN-EXPRESSION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Gauge32, Unsigned32, Counter32, Counter64, IpAddress, TimeTicks, mib-2, zeroDotZero FROM SNMPv2-SMI RowStatus, TruthValue, TimeStamp FROM SNMPv2-TC sysUpTime FROM SNMPv2-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; dismanExpressionMIB MODULE-IDENTITY LAST-UPDATED "200306130000Z" -- 13 June 2003 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 defining expressions of MIB objects for management purposes. Copyright (C) The Internet Society 2003. This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this note -- Revision History REVISION "200306130000Z" -- 13 June 2003 DESCRIPTION "Added copyright statement to the MIB module description." REVISION "200111140000Z" -- 14 November 2001 DESCRIPTION "Updated the DESCRIPTION clause of expValueIpAddressVal, and removed the SIZE restriction of expValueOctetStringVal." REVISION "200010160000Z" -- 16 October 2000 Expires December 2003 [Page 18] Internet Draft Expression MIB 13 June 2003 DESCRIPTION "This is the initial version of this MIB. Published as RFC 2982" ::= { mib-2 90 } dismanExpressionMIBObjects OBJECT IDENTIFIER ::= { dismanExpressionMIB 1 } expResource OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 1 } expDefine OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 2 } expValue OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 3 } -- -- Resource Control -- expResourceDeltaMinimum OBJECT-TYPE SYNTAX Integer32 (-1 | 1..600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum expExpressionDeltaInterval this system will accept. A system may use the larger values of this minimum to lessen the impact of constantly computing deltas. For larger delta sampling intervals the system samples less often and suffers less overhead. This object provides a way to enforce such lower overhead for all expressions created after it is set. The value -1 indicates that expResourceDeltaMinimum is irrelevant as the system will not accept 'deltaValue' as a value for expObjectSampleType. Unless explicitly resource limited, a system's value for this object should be 1, allowing as small as a 1 second interval for ongoing delta sampling. Changing this value will not invalidate an existing setting of expObjectSampleType." ::= { expResource 1 } expResourceDeltaWildcardInstanceMaximum OBJECT-TYPE SYNTAX Unsigned32 UNITS "instances" Expires December 2003 [Page 19] Internet Draft Expression MIB 13 June 2003 MAX-ACCESS read-write STATUS current DESCRIPTION "For every instance of a deltaValue object, one dynamic instance entry is needed for holding the instance value from the previous sample, i.e. to maintain state. This object limits maximum number of dynamic instance entries this system will support for wildcarded delta objects in expressions. For a given delta expression, the number of dynamic instances is the number of values that meet all criteria to exist times the number of delta values in the expression. A value of 0 indicates no preset limit, that is, the limit is dynamic based on system operation and resources. Unless explicitly resource limited, a system's value for this object should be 0. Changing this value will not eliminate or inhibit existing delta wildcard instance objects but will prevent the creation of more such objects. An attempt to allocate beyond the limit results in expErrorCode being tooManyWildcardValues for that evaluation attempt." ::= { expResource 2 } expResourceDeltaWildcardInstances OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active instance entries as defined for expResourceDeltaWildcardInstanceMaximum." ::= { expResource 3 } expResourceDeltaWildcardInstancesHigh OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest value of expResourceDeltaWildcardInstances that has occurred since initialization of the managed Expires December 2003 [Page 20] Internet Draft Expression MIB 13 June 2003 system." ::= { expResource 4 } expResourceDeltaWildcardInstanceResourceLacks OBJECT-TYPE SYNTAX Counter32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this system could not evaluate an expression because that would have created a value instance in excess of expResourceDeltaWildcardInstanceMaximum." ::= { expResource 5 } -- -- Definition -- -- Expression Definition Table -- expExpressionTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpExpressionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of expression definitions." ::= { expDefine 1 } expExpressionEntry OBJECT-TYPE SYNTAX ExpExpressionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single expression. New expressions can be created using expExpressionEntryStatus. To create an expression first create the named entry in this table. Then use expExpressionName to populate expObjectTable. For expression evaluation to succeed all related entries in expExpressionTable and expObjectTable must be 'active'. If these conditions are not met the corresponding values in expValue simply are not instantiated. Deleting an entry deletes all related entries in expObjectTable Expires December 2003 [Page 21] Internet Draft Expression MIB 13 June 2003 and expErrorTable. Because of the relationships among the multiple tables for an expression (expExpressionTable, expObjectTable, and expValueTable) and the SNMP rules for independence in setting object values, it is necessary to do final error checking when an expression is evaluated, that is, when one of its instances in expValueTable is read or a delta interval expires. Earlier checking need not be done and an implementation may not impose any ordering on the creation of objects related to an expression. To maintain security of MIB information, when creating a new row in this table, the managed system must record the security credentials of the requester. These security credentials are the parameters necessary as inputs to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. When obtaining the objects that make up the expression, the system must (conceptually) use isAccessAllowed to ensure that it does not violate security. The evaluation of the expression takes place under the security credentials of the creator of its expExpressionEntry. Values of read-write objects in this table may be changed at any time." INDEX { expExpressionOwner, expExpressionName } ::= { expExpressionTable 1 } ExpExpressionEntry ::= SEQUENCE { expExpressionOwner SnmpAdminString, expExpressionName SnmpAdminString, expExpression OCTET STRING, expExpressionValueType INTEGER, expExpressionComment SnmpAdminString, expExpressionDeltaInterval Integer32, expExpressionPrefix OBJECT IDENTIFIER, expExpressionErrors Counter32, expExpressionEntryStatus RowStatus } expExpressionOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current Expires December 2003 [Page 22] Internet Draft Expression MIB 13 June 2003 DESCRIPTION "The owner of this entry. The exact semantics of this string are subject to the security policy defined by the security administrator." ::= { expExpressionEntry 1 } expExpressionName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the expression. This is locally unique, within the scope of an expExpressionOwner." ::= { expExpressionEntry 2 } expExpression OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "The expression to be evaluated. This object is the same as a DisplayString (RFC 1903) except for its maximum length. Except for the variable names the expression is in ANSI C syntax. Only the subset of ANSI C operators and functions listed here is allowed. Variables are expressed as a dollar sign ('$') and an integer that corresponds to an expObjectIndex. An example of a valid expression is: ($1-$5)*100 Expressions must not be recursive, that is although an expression may use the results of another expression, it must not contain any variable that is directly or indirectly a result of its own evaluation. The managed system must check for recursive expressions. The only allowed operators are: ( ) - (unary) + - * / % & | ^ << >> ~ Expires December 2003 [Page 23] Internet Draft Expression MIB 13 June 2003 ! && || == != > >= < <= Note the parentheses are included for parenthesizing the expression, not for casting data types. The only constant types defined are: int (32-bit signed) long (64-bit signed) unsigned int unsigned long hexadecimal character string oid The default type for a positive integer is int unless it is too large in which case it is long. All but oid are as defined for ANSI C. Note that a hexadecimal constant may end up as a scalar or an array of 8-bit integers. A string constant is enclosed in double quotes and may contain back-slashed individual characters as in ANSI C. An oid constant comprises 32-bit, unsigned integers and at least one period, for example: 0. .0 1.3.6.1 No additional leading or trailing subidentifiers are automatically added to an OID constant. The constant is taken as expressed. Integer-typed objects are treated as 32- or 64-bit, signed or unsigned integers, as appropriate. The results of mixing them are as for ANSI C, including the type of the result. Note that a 32-bit value is thus promoted to 64 bits only in an operation with a 64-bit value. There is no provision for larger values to handle overflow. Relative to SNMP data types, a resulting value becomes unsigned when calculating it uses any unsigned value, including a counter. To force the final value to be of Expires December 2003 [Page 24] Internet Draft Expression MIB 13 June 2003 data type counter the expression must explicitly use the counter32() or counter64() function (defined below). OCTET STRINGS and OBJECT IDENTIFIERs are treated as one-dimensioned arrays of unsigned 8-bit integers and unsigned 32-bit integers, respectively. IpAddresses are treated as 32-bit, unsigned integers in network byte order, that is, the hex version of 255.0.0.0 is 0xff000000. Conditional expressions result in a 32-bit, unsigned integer of value 0 for false or 1 for true. When an arbitrary value is used as a boolean 0 is false and non-zero is true. Rules for the resulting data type from an operation, based on the operator: For << and >> the result is the same as the left hand operand. For &&, ||, ==, !=, <, <=, >, and >= the result is always Unsigned32. For unary - the result is always Integer32. For +, -, *, /, %, &, |, and ^ the result is promoted according to the following rules, in order from most to least preferred: If left hand and right hand operands are the same type, use that. If either side is Counter64, use that. If either side is IpAddress, use that. If either side is TimeTicks, use that. If either side is Counter32, use that. Otherwise use Unsigned32. The following rules say what operators apply with what data types. Any combination not explicitly defined does not work. For all operators any of the following can be the left hand or Expires December 2003 [Page 25] Internet Draft Expression MIB 13 June 2003 right hand operand: Integer32, Counter32, Unsigned32, Counter64. The operators +, -, *, /, %, <, <=, >, and >= work with TimeTicks. The operators &, |, and ^ work with IpAddress. The operators << and >> work with IpAddress but only as the left hand operand. The + operator performs a concatenation of two OCTET STRINGs or two OBJECT IDENTIFIERs. The operators &, | perform bitwise operations on OCTET STRINGs. If the OCTET STRING happens to be a DisplayString the results may be meaningless, but the agent system does not check this as some such systems do not have this information. The operators << and >> perform bitwise operations on OCTET STRINGs appearing as the left hand operand. The only functions defined are: counter32 counter64 arraySection stringBegins stringEnds stringContains oidBegins oidEnds oidContains average maximum minimum sum exists The following function definitions indicate their parameters by naming the data type of the parameter in the parameter's position in the parameter list. The parameter must be of the type indicated and generally may be a constant, a MIB object, a function, or an expression. counter32(integer) - wrapped around an integer value counter32 Expires December 2003 [Page 26] Internet Draft Expression MIB 13 June 2003 forces Counter32 as a data type. counter64(integer) - similar to counter32 except that the resulting data type is 'counter64'. arraySection(array, integer, integer) - selects a piece of an array (i.e. part of an OCTET STRING or OBJECT IDENTIFIER). The integer arguments are in the range 0 to 4,294,967,295. The first is an initial array index (one-dimensioned) and the second is an ending array index. A value of 0 indicates first or last element, respectively. If the first element is larger than the array length the result is 0 length. If the second integer is less than or equal to the first, the result is 0 length. If the second is larger than the array length it indicates last element. stringBegins/Ends/Contains(octetString, octetString) - looks for the second string (which can be a string constant) in the first and returns the one-dimensioned arrayindex where the match began. A return value of 0 indicates no match (i.e. boolean false). oidBegins/Ends/Contains(oid, oid) - looks for the second OID (which can be an OID constant) in the first and returns the the one-dimensioned index where the match began. A return value of 0 indicates no match (i.e. boolean false). average/maximum/minimum(integer) - calculates the average, minimum, or maximum value of the integer valued object over multiple sample times. If the object disappears for any sample period, the accumulation and the resulting value object cease to exist until the object reappears at which point the calculation starts over. sum(integerObject*) - sums all available values of the wildcarded integer object, resulting in an integer scalar. Must be used with caution as it wraps on overflow with no notification. exists(anyTypeObject) - verifies the object instance exists. A return value of 0 indicates NoSuchInstance (i.e. boolean false)." ::= { expExpressionEntry 3 } expExpressionValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), Expires December 2003 [Page 27] Internet Draft Expression MIB 13 June 2003 integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the expression value. One and only one of the value objects in expValueTable will be instantiated to match this type. If the result of the expression can not be made into this type, an invalidOperandType error will occur." DEFVAL { counter32 } ::= { expExpressionEntry 4 } expExpressionComment OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A comment to explain the use or meaning of the expression." DEFVAL { ''H } ::= { expExpressionEntry 5 } expExpressionDeltaInterval OBJECT-TYPE SYNTAX Integer32 (0..86400) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Sampling interval for objects in this expression with expObjectSampleType 'deltaValue'. This object has no effect if the the expression has no deltaValue objects. A value of 0 indicates no automated sampling. In this case the delta is the difference from the last time the expression was evaluated. Note that this is subject to unpredictable delta times in the face of retries or multiple managers. A value greater than zero is the number of seconds between automated samples. Until the delta interval has expired once the delta for the object is effectively not instantiated and evaluating Expires December 2003 [Page 28] Internet Draft Expression MIB 13 June 2003 the expression has results as if the object itself were not instantiated. Note that delta values potentially consume large amounts of system CPU and memory. Delta state and processing must continue constantly even if the expression is not being used. That is, the expression is being evaluated every delta interval, even if no application is reading those values. For wildcarded objects this can be substantial overhead. Note that delta intervals, external expression value sampling intervals and delta intervals for expressions within other expressions can have unusual interactions as they are impossible to synchronize accurately. In general one interval embedded below another must be enough shorter that the higher sample sees relatively smooth, predictable behavior. So, for example, to avoid the higher level getting the same sample twice, the lower level should sample at least twice as fast as the higher level does." DEFVAL { 0 } ::= { expExpressionEntry 6 } expExpressionPrefix OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object prefix to assist an application in determining the instance indexing to use in expValueTable, relieving the application of the need to scan the expObjectTable to determine such a prefix. See expObjectTable for information on wildcarded objects. If the expValueInstance portion of the value OID may be treated as a scalar (that is, normally, 0) the value of expExpressionPrefix is zero length, that is, no OID at all. Note that zero length implies a null OID, not the OID 0.0. Otherwise, the value of expExpressionPrefix is the expObjectID value of any one of the wildcarded objects for the expression. This is sufficient, as the remainder, that is, the instance fragment relevant to instancing the values, must be the same for all wildcarded objects in the expression." ::= { expExpressionEntry 7 } Expires December 2003 [Page 29] Internet Draft Expression MIB 13 June 2003 expExpressionErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of errors encountered while evaluating this expression. Note that an object in the expression not being accessible, is not considered an error. An example of an inaccessible object is when the object is excluded from the view of the user whose security credentials are used in the expression evaluation. In such cases, it is a legitimate condition that causes the corresponding expression value not to be instantiated." ::= { expExpressionEntry 8 } expExpressionEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries." ::= { expExpressionEntry 9 } -- -- Expression Error Table -- expErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of expression errors." ::= { expDefine 2 } expErrorEntry OBJECT-TYPE SYNTAX ExpErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about errors in processing an expression. Entries appear in this table only when there is a matching Expires December 2003 [Page 30] Internet Draft Expression MIB 13 June 2003 expExpressionEntry and then only when there has been an error for that expression as reflected by the error codes defined for expErrorCode." INDEX { expExpressionOwner, expExpressionName } ::= { expErrorTable 1 } ExpErrorEntry ::= SEQUENCE { expErrorTime TimeStamp, expErrorIndex Integer32, expErrorCode INTEGER, expErrorInstance OBJECT IDENTIFIER } expErrorTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time an error caused a failure to evaluate this expression." ::= { expErrorEntry 1 } expErrorIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The one-dimensioned character array index into expExpression for where the error occurred. The value zero indicates irrelevance." ::= { expErrorEntry 2 } expErrorCode OBJECT-TYPE SYNTAX INTEGER { invalidSyntax(1), undefinedObjectIndex(2), unrecognizedOperator(3), unrecognizedFunction(4), invalidOperandType(5), unmatchedParenthesis(6), tooManyWildcardValues(7), recursion(8), deltaTooShort(9), resourceUnavailable(10), divideByZero(11) Expires December 2003 [Page 31] Internet Draft Expression MIB 13 June 2003 } MAX-ACCESS read-only STATUS current DESCRIPTION "The error that occurred. In the following explanations the expected timing of the error is in parentheses. 'S' means the error occurs on a Set request. 'E' means the error occurs on the attempt to evaluate the expression either due to Get from expValueTable or in ongoing delta processing. invalidSyntax the value sent for expExpression is not valid Expression MIB expression syntax (S) undefinedObjectIndex an object reference ($n) in expExpression does not have a matching instance in expObjectTable (E) unrecognizedOperator the value sent for expExpression held an unrecognized operator (S) unrecognizedFunction the value sent for expExpression held an unrecognized function name (S) invalidOperandType an operand in expExpression is not the right type for the associated operator or result (SE) unmatchedParenthesis the value sent for expExpression is not correctly parenthesized (S) tooManyWildcardValues evaluating the expression exceeded the limit set by expResourceDeltaWildcardInstanceMaximum (E) recursion through some chain of embedded expressions the expression invokes itself (E) deltaTooShort the delta for the next evaluation passed before the system could evaluate the present sample (E) resourceUnavailable some resource, typically dynamic memory, was unavailable (SE) divideByZero an attempt to divide by zero occurred (E) For the errors that occur when the attempt is made to set expExpression Set request fails with the SNMP error code 'wrongValue'. Such failures refer to the most recent failure to Set expExpression, not to the present value of expExpression which must be either unset or syntactically correct. Expires December 2003 [Page 32] Internet Draft Expression MIB 13 June 2003 Errors that occur during evaluation for a Get* operation return the SNMP error code 'genErr' except for 'tooManyWildcardValues' and 'resourceUnavailable' which return the SNMP error code 'resourceUnavailable'." ::= { expErrorEntry 3 } expErrorInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The expValueInstance being evaluated when the error occurred. A zero-length indicates irrelevance." ::= { expErrorEntry 4 } -- -- Object Table -- expObjectTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of object definitions for each expExpression. Wildcarding instance IDs: It is legal to omit all or part of the instance portion for some or all of the objects in an expression. (See the DESCRIPTION of expObjectID for details. However, note that if more than one object in the same expression is wildcarded in this way, they all must be objects where that portion of the instance is the same. In other words, all objects may be in the same SEQUENCE or in different SEQUENCEs but with the same semantic index value (e.g., a value of ifIndex) for the wildcarded portion." ::= { expDefine 3 } expObjectEntry OBJECT-TYPE SYNTAX ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about an object. An application uses Expires December 2003 [Page 33] Internet Draft Expression MIB 13 June 2003 expObjectEntryStatus to create entries in this table while in the process of defining an expression. Values of read-create objects in this table may be changed at any time." INDEX { expExpressionOwner, expExpressionName, expObjectIndex } ::= { expObjectTable 1 } ExpObjectEntry ::= SEQUENCE { expObjectIndex Unsigned32, expObjectID OBJECT IDENTIFIER, expObjectIDWildcard TruthValue, expObjectSampleType INTEGER, expObjectDeltaDiscontinuityID OBJECT IDENTIFIER, expObjectDiscontinuityIDWildcard TruthValue, expObjectDiscontinuityIDType INTEGER, expObjectConditional OBJECT IDENTIFIER, expObjectConditionalWildcard TruthValue, expObjectEntryStatus RowStatus } expObjectIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Within an expression, a unique, numeric identification for an object. Prefixed with a dollar sign ('$') this is used to reference the object in the corresponding expExpression." ::= { expObjectEntry 1 } expObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of this object. The OID may be fully qualified, meaning it includes a complete instance identifier part (e.g., ifInOctets.1 or sysUpTime.0), or it may not be fully qualified, meaning it may lack all or part of the instance identifier. If the expObjectID is not fully qualified, then expObjectWildcard must be set to true(1). The value of the expression will be multiple values, as if done for a GetNext sweep of the object. Expires December 2003 [Page 34] Internet Draft Expression MIB 13 June 2003 An object here may itself be the result of an expression but recursion is not allowed. NOTE: The simplest implementations of this MIB may not allow wildcards." ::= { expObjectEntry 2 } expObjectIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjecID of this row is a wildcard object. False indicates that expObjectID is fully instanced. If all expObjectWildcard values for a given expression are FALSE, expExpressionPrefix will reflect a scalar object (i.e. will be 0.0). NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 3 } expObjectSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2), changedValue(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The method of sampling the selected variable. An 'absoluteValue' is simply the present value of the object. A 'deltaValue' is the present value minus the previous value, which was sampled expExpressionDeltaInterval seconds ago. This is intended primarily for use with SNMP counters, which are meaningless as an 'absoluteValue', but may be used with any integer-based value. A 'changedValue' is a boolean for whether the present value is different from the previous value. It is applicable to any data type and results in an Unsigned32 with value 1 if the object's value is changed and 0 if not. In all other respects it is as a 'deltaValue' and all statements and operation regarding delta values apply to changed values. Expires December 2003 [Page 35] Internet Draft Expression MIB 13 June 2003 When an expression contains both delta and absolute values the absolute values are obtained at the end of the delta period." DEFVAL { absoluteValue } ::= { expObjectEntry 4 } sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } expObjectDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or DateAndTime object that indicates a discontinuity in the value at expObjectID. This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'. The OID may be for a leaf object (e.g. sysUpTime.0) or may be wildcarded to match expObjectID. This object supports normal checking for a discontinuity in a counter. Note that if this object does not point to sysUpTime discontinuity checking must still check sysUpTime for an overall discontinuity. If the object identified is not accessible no discontinuity check will be made." DEFVAL { sysUpTimeInstance } ::= { expObjectEntry 5 } expObjectDiscontinuityIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjectDeltaDiscontinuityID of this row is a wildcard object. False indicates that expObjectDeltaDiscontinuityID is fully instanced. This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'. Expires December 2003 [Page 36] Internet Draft Expression MIB 13 June 2003 NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 6 } expObjectDiscontinuityIDType OBJECT-TYPE SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value 'timeTicks' indicates the expObjectDeltaDiscontinuityID of this row is of syntax TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. The value 'dateAndTime indicates syntax DateAndTime. This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'." DEFVAL { timeTicks } ::= { expObjectEntry 7 } expObjectConditional OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of an object that overrides whether the instance of expObjectID is to be considered usable. If the value of the object at expObjectConditional is 0 or not instantiated, the object at expObjectID is treated as if it is not instantiated. In other words, expObjectConditional is a filter that controls whether or not to use the value at expObjectID. The OID may be for a leaf object (e.g. sysObjectID.0) or may be wildcarded to match expObjectID. If expObject is wildcarded and expObjectID in the same row is not, the wild portion of expObjectConditional must match the wildcarding of the rest of the expression. If no object in the expression is wildcarded but expObjectConditional is, use the lexically first instance (if any) of expObjectConditional. If the value of expObjectConditional is 0.0 operation is as if the value pointed to by expObjectConditional is a non-zero (true) value. Expires December 2003 [Page 37] Internet Draft Expression MIB 13 June 2003 Note that expObjectConditional can not trivially use an object of syntax TruthValue, since the underlying value is not 0 or 1." DEFVAL { zeroDotZero } ::= { expObjectEntry 8 } expObjectConditionalWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjectConditional of this row is a wildcard object. False indicates that expObjectConditional is fully instanced. NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 9 } expObjectEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries. Objects in this table may be changed while expObjectEntryStatus is in any state." ::= { expObjectEntry 10 } -- -- Expression Value Table -- expValueTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpValueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of values from evaluated expressions." ::= { expValue 1 } expValueEntry OBJECT-TYPE SYNTAX ExpValueEntry Expires December 2003 [Page 38] Internet Draft Expression MIB 13 June 2003 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single value from an evaluated expression. For a given instance, only one 'Val' object in the conceptual row will be instantiated, that is, the one with the appropriate type for the value. For values that contain no objects of expObjectSampleType 'deltaValue' or 'changedValue', reading a value from the table causes the evaluation of the expression for that value. For those that contain a 'deltaValue' or 'changedValue' the value read is as of the last sampling interval. If in the attempt to evaluate the expression one or more of the necessary objects is not available, the corresponding entry in this table is effectively not instantiated. To maintain security of MIB information, when creating a new row in this table, the managed system must record the security credentials of the requester. These security credentials are the parameters necessary as inputs to isAccessAllowed from [RFC2571]. When obtaining the objects that make up the expression, the system must (conceptually) use isAccessAllowed to ensure that it does not violate security. The evaluation of that expression takes place under the security credentials of the creator of its expExpressionEntry. To maintain security of MIB information, expression evaluation must take place using security credentials for the implied Gets of the objects in the expression as inputs (conceptually) to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. These are the security credentials of the creator of the corresponding expExpressionEntry." INDEX { expExpressionOwner, expExpressionName, IMPLIED expValueInstance } ::= { expValueTable 1 } ExpValueEntry ::= SEQUENCE { expValueInstance OBJECT IDENTIFIER, expValueCounter32Val Counter32, expValueUnsigned32Val Unsigned32, expValueTimeTicksVal TimeTicks, expValueInteger32Val Integer32, expValueIpAddressVal IpAddress, Expires December 2003 [Page 39] Internet Draft Expression MIB 13 June 2003 expValueOctetStringVal OCTET STRING, expValueOidVal OBJECT IDENTIFIER, expValueCounter64Val Counter64 } expValueInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The final instance portion of a value's OID according to the wildcarding in instances of expObjectID for the expression. The prefix of this OID fragment is 0.0, leading to the following behavior. If there is no wildcarding, the value is 0.0.0. In other words, there is one value which standing alone would have been a scalar with a 0 at the end of its OID. If there is wildcarding, the value is 0.0 followed by a value that the wildcard can take, thus defining one value instance for each real, possible value of the wildcard. So, for example, if the wildcard worked out to be an ifIndex, there is an expValueInstance for each applicable ifIndex." ::= { expValueEntry 1 } expValueCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'counter32'." ::= { expValueEntry 2 } expValueUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'unsigned32'." ::= { expValueEntry 3 } expValueTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only Expires December 2003 [Page 40] Internet Draft Expression MIB 13 June 2003 STATUS current DESCRIPTION "The value when expExpressionValueType is 'timeTicks'." ::= { expValueEntry 4 } expValueInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'integer32'." ::= { expValueEntry 5 } expValueIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'ipAddress'. This object type is necessary to support values represented using the IpAddress type, which is limited to IPv4. IPv6 addressess are represented using the OCTET STRING type, and would thus show up as instances of expValueOctetStringVal." ::= { expValueEntry 6 } expValueOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'octetString'." ::= { expValueEntry 7 } expValueOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'objectId'." ::= { expValueEntry 8 } expValueCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only Expires December 2003 [Page 41] Internet Draft Expression MIB 13 June 2003 STATUS current DESCRIPTION "The value when expExpressionValueType is 'counter64'." ::= { expValueEntry 9 } -- -- Conformance -- dismanExpressionMIBConformance OBJECT IDENTIFIER ::= { dismanExpressionMIB 3 } dismanExpressionMIBCompliances OBJECT IDENTIFIER ::= { dismanExpressionMIBConformance 1 } dismanExpressionMIBGroups OBJECT IDENTIFIER ::= { dismanExpressionMIBConformance 2 } -- Compliance dismanExpressionMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Expression MIB." MODULE -- this module MANDATORY-GROUPS { dismanExpressionResourceGroup, dismanExpressionDefinitionGroup, dismanExpressionValueGroup } OBJECT expResourceDeltaMinimum SYNTAX Integer32 (-1 | 60..600) DESCRIPTION "Implementation need not allow deltas or it may implement them and restrict them to higher values." OBJECT expObjectSampleType WRITE-SYNTAX INTEGER { absoluteValue(1) } DESCRIPTION "Implementation may disallow deltas calculation or change detection." OBJECT expObjectIDWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION Expires December 2003 [Page 42] Internet Draft Expression MIB 13 June 2003 "Implementation may allow wildcards." OBJECT expObjectDiscontinuityIDWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION "Implementation need not allow wildcards." OBJECT expObjectConditionalWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION "Implementation need not allow deltas wildcards." ::= { dismanExpressionMIBCompliances 1 } -- Units of Conformance dismanExpressionResourceGroup OBJECT-GROUP OBJECTS { expResourceDeltaMinimum, expResourceDeltaWildcardInstanceMaximum, expResourceDeltaWildcardInstances, expResourceDeltaWildcardInstancesHigh, expResourceDeltaWildcardInstanceResourceLacks } STATUS current DESCRIPTION "Expression definition resource management." ::= { dismanExpressionMIBGroups 1 } dismanExpressionDefinitionGroup OBJECT-GROUP OBJECTS { expExpression, expExpressionValueType, expExpressionComment, expExpressionDeltaInterval, expExpressionPrefix, expExpressionErrors, expExpressionEntryStatus, expErrorTime, expErrorIndex, expErrorCode, expErrorInstance, expObjectID, Expires December 2003 [Page 43] Internet Draft Expression MIB 13 June 2003 expObjectIDWildcard, expObjectSampleType, expObjectDeltaDiscontinuityID, expObjectDiscontinuityIDWildcard, expObjectDiscontinuityIDType, expObjectConditional, expObjectConditionalWildcard, expObjectEntryStatus } STATUS current DESCRIPTION "Expression definition." ::= { dismanExpressionMIBGroups 2 } dismanExpressionValueGroup OBJECT-GROUP OBJECTS { expValueCounter32Val, expValueUnsigned32Val, expValueTimeTicksVal, expValueInteger32Val, expValueIpAddressVal, expValueOctetStringVal, expValueOidVal, expValueCounter64Val } STATUS current DESCRIPTION "Expression value." ::= { dismanExpressionMIBGroups 3 } END 4. 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 Expires December 2003 [Page 44] Internet Draft Expression MIB 13 June 2003 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. 5. Acknowledgements This MIB contains considerable contributions from the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), and colleagues at Cisco who did the first implementation. 6. References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture 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] Rose, M., "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. Expires December 2003 [Page 45] Internet Draft Expression MIB 13 June 2003 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. Expires December 2003 [Page 46] Internet Draft Expression MIB 13 June 2003 [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 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. [RFC2981] Stewart, B., "Event MIB", RFC 2981, October 2000. [PracPersp] Leinwand, A. and K. Fang, "Network Management: A Practical Perspective", Addison-Wesley Publishing Company, Inc., 1993. 7. Security Considerations Expires December 2003 [Page 47] Internet Draft Expression MIB 13 June 2003 Expression MIB security involves two perspectives: protection of expressions from tampering or unauthorized use of resources, and protection of the objects used to calculate the expressions. Security of expression definitions and results depends on the expression owner (expExpressionOwner). With view-based access control [RFC2575] a network manager can control who has what level of access to what expressions. Access control for the objects within the expression depends on the security credentials of the expression creator. These are the security credentials used to get the objects necessary to evaluate the expression. They are the security credentials that were used to set the expExpressionEntryStatus object for that expression to 'active', as recorded by the managed system. This means that the results of an expression could potentially be made available to someone who does not have access to the raw data that went into them. This could be either legitimate or a security violation, depending on the specific situation and security policy. To facilitate the provisioning of access control by a security administrator for this MIB itself using the View-Based Access Control Model (VACM) defined in RFC 2575 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. Expires December 2003 [Page 48] Internet Draft Expression MIB 13 June 2003 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. 9. Editor's Address 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 December 2003 [Page 49] Internet Draft Expression MIB 13 June 2003 10. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 December 2003 [Page 50] From mailnull@www1.ietf.org Sat Jun 14 03:00:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20559 for ; Sat, 14 Jun 2003 03:00:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E705110171 for disman-archive@odin.ietf.org; Sat, 14 Jun 2003 03:00:05 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E705m10168 for ; Sat, 14 Jun 2003 03:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20526 for ; Sat, 14 Jun 2003 03:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R4z2-00057O-00 for disman-web-archive@ietf.org; Sat, 14 Jun 2003 02:57:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R4z1-00057L-00 for disman-web-archive@ietf.org; Sat, 14 Jun 2003 02:57:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMn1a30172; Fri, 13 Jun 2003 18:49:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMm6m30141 for ; Fri, 13 Jun 2003 18:48:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26854; Fri, 13 Jun 2003 18:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QxI0-0001vQ-00; Fri, 13 Jun 2003 18:44:56 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19QxHw-0001vE-00; Fri, 13 Jun 2003 18:44:52 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5DMkSje009611; Fri, 13 Jun 2003 15:46:29 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIC75991; Fri, 13 Jun 2003 15:41:12 -0700 (PDT) Message-ID: <3EEA5443.1030600@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts CC: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Disman] Please accept draft-ietf-disman-express-mib-v2-03.txt for posting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 15:46:27 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please accept draft-ietf-disman-express-mib-v2-03.txt for posting as an Internet-Draft. Thanks, Ram Kavasseri Disman Working Group R. Kavasseri Internet Draft Cisco Systems, Inc. Document: draft-ietf-disman-express-mib-v2-03.txt B. Stewart Expiration Date: December 2003 Retired June 2003 Distributed Management Expression MIB 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 (2003). All Rights Reserved. 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 managing expressions of MIB objects. The results of these expressions become Internet Draft Expression MIB 13 June 2003 MIB objects usable like any other MIB object, such as for the test condition for declaring an event. 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. Table of Contents 1 The SNMP Management Framework ............................... 2 2 Overview .................................................... 3 2.1 Usage ..................................................... 4 2.2 Persistence ............................................... 4 2.3 Operation ................................................. 4 2.3.1 Sampling ................................................ 5 2.3.2 Wildcards ............................................... 5 2.3.3 Evaluation .............................................. 5 2.3.4 Value Identification .................................... 6 2.4 Subsets ................................................... 6 2.4.1 No Wildcards ............................................ 6 2.4.2 No Deltas ............................................... 7 2.5 Structure ................................................. 7 2.5.1 Resource ................................................ 7 2.5.2 Definition .............................................. 7 2.5.3 Value ................................................... 8 2.6 Examples .................................................. 8 2.6.1 Wildcarding ............................................. 8 2.6.2 Calculation and Conditional ............................. 10 3 Definitions ................................................. 12 4 Intellectual Property ....................................... 36 5 Acknowledgements ............................................ 37 6 References .................................................. 37 7 Security Considerations ..................................... 38 8 Author's Address ............................................ 40 9 Editor's Address ............................................ 40 10 Full Copyright Statement ................................... 41 1. 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 Expires December 2003 [Page 2] Internet Draft Expression MIB 13 June 2003 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], STD 58, RFC 2579 [RFC2579] and STD 58, 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]. Expires December 2003 [Page 3] Internet Draft Expression MIB 13 June 2003 o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. 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. 2. Overview Users of MIBs often desire MIB objects that MIB designers have not provided. Furthermore, such needs vary from one management philosophy to another. Rather than fill more and more MIBs with standardized objects, the Expression MIB supports externally defined expressions of existing MIB objects. In the Expression MIB the results of an evaluated expression are MIB objects that may be used like any other MIB objects. These custom- defined objects are thus usable anywhere any other MIB object can be used. For example, they can be used by a management application directly or referenced from another MIB, such as the Event MIB [MIBEventMIB]. They can even be used by the Expression MIB itself, forming expressions of expressions. The Expression MIB is instrumentation for a relatively powerful, complex, high-level application, considerably different from simple instrumentation for a communication driver or a protocol. The MIB is appropriate in a relatively powerful, resource-rich managed system and not necessarily in a severely limited environment. Nevertheless, due to dependencies from the Event MIB [RFC2981] and the need to support as low-end a system as possible, the Expression Expires December 2003 [Page 4] Internet Draft Expression MIB 13 June 2003 MIB can be somewhat stripped down for lower-power, lower-resource implementations, as described in the Subsets section, below. Implementation of the Expression MIB in a managed system led to the addition of objects that may not have been necessary in an application environment with complete knowledge of compiled MIB definitions. This is appropriate since implementation must be possible within typical managed systems with some constraints on system resources. 2.1. Usage On managed systems that can afford the overhead, the Expression MIB is a way to create new, customized MIB objects for monitoring. Although these can save some network traffic and overhead on management systems, that is often not a good tradeoff for objects that are simply to be recorded or displayed. An example of a use of the Expression MIB would be to provide custom objects for the Event MIB [RFC2981]. A complex expression can evaluate to a rate of flow or a boolean and thus be subject to testing as an event trigger, resulting in an SNMP notification. Without these capabilities such monitoring would be limited to the objects in predefined MIBs. The Expression MIB thus supports powerful tools for the network manager faced with the monitoring of large, complex systems that can support a significant level of self management. 2.2. Persistence Although like most MIBs this one has no explicit controls for the persistence of the values set in configuring an expression, a robust, polite implementation would certainly not force its managing applications to reconfigure it whenever it resets. Again, as with most MIBs, it is implementation specific how a system provides and manages such persistence. To speculate, one could imagine, for example, that persistence depended on the context in which the expression was configured, or perhaps system-specific characteristics of the expression's owner. Or perhaps everything in a MIB such as this one, which is clearly aimed at persistent configuration, is automatically part of a system's other persistent configuration. 2.3. Operation Expires December 2003 [Page 5] Internet Draft Expression MIB 13 June 2003 Most of the operation of the MIB is described or implied in the object definitions but a few highlights bear mentioning here. Expires December 2003 [Page 6] Internet Draft Expression MIB 13 June 2003 2.3.1. Sampling The MIB supports three types of object sampling for the MIB objects that make up the expression: absolute, delta, and changed. Absolute samples are simply the value of the MIB object at the time it is sampled. Absolute samples are not sufficient for expressions of counters, as counters have meaning only as a delta (difference) from one sample to the next. Thus objects may be sampled as deltas. Delta sampling requires the application to maintain state for the value at the last sample, and to do continuous sampling whether or not anyone is looking at the results. It thus creates constant overhead. Changed sampling is a simple fallout of delta sampling where rather than a difference the result is a boolean indicating whether or not the object changed value since the last sample. 2.3.2. Wildcards Wildcards allow the application of a single expression to multiple instances of the same MIB object. The definer of the expression indicates this choice and provides a partial object identifier, with some or all of the instance portion left off. The application then does the equivalent of GetNext to obtain the object values, thus discovering the instances. All wildcarded objects in an expression must have the same semantics for the missing portion of their object identifiers. Otherwise, any successful evaluation of the wildcarded expression would be the result of the accidental matching of the wildcarded portion of the object identifiers in the expression. Such an evaluation will likely produce results which are not meaningful. The expression can be evaluated only for those instances where all the objects in the expression are available with the same value for the wildcarded portion of the instance. 2.3.3. Evaluation There are two important aspects of evaluation that may not be obvious: what objects and when. What objects get used in the evaluation depends on the type of Expires December 2003 [Page 7] Internet Draft Expression MIB 13 June 2003 request and whether or not the expression contains wildcarded objects. If the request was a Get, that locks down the instances to Expires December 2003 [Page 8] Internet Draft Expression MIB 13 June 2003 be used. If the request was a GetNext or GetBulk, the application must work its way up to the next full set of objects for the expression. Evaluation of expressions happens at two possible times, depending on the sampling method (delta or absolute) used to evaluate the expression. If there are no delta or change values in an expression, the evaluation occurs on demand, i.e. when a requester attempts to read the value of the expression. In this case all requesters get a freshly calculated value. For expressions with delta or change values, evaluation goes on continuously, every sample period. In this case requesters get the value as of the last sample period. For any given sample period of a given expression, only those instances exist that provided a full set of object values. It may be possible that a delta expression which was evaluated successfully for one sample period may not be successfully evaluated in the next sample period. This may, for example, be due to missing instances for some or all of the objects in the expression. In such cases, the value from the previous sample period (with the successful evaluation) must not be carried forward to the next sample period (with the failed evaluation). 2.3.4. Value Identification Values resulting from expression evaluation are identified with a combination of the object identifier (OID) for the data type from expValueTable (such as expValueCounter32Val), the expression owner, the expression name, and an OID fragment. The OID fragment is not an entire OID beginning with iso.dod.org (1.3.6). Rather it begins with 0.0. The remainder is either another 0 when there is no wildcarding or the instance that satisfied the wildcard if there is wildcarding. 2.4. Subsets To pare down the Expression MIBs complexity and use of resources an implementor can leave out various parts. 2.4.1. No Wildcards Leaving out wildcarding significantly reduces the complexity of Expires December 2003 [Page 9] Internet Draft Expression MIB 13 June 2003 retrieving values to evaluate expressions and the processing required to do so. Such an implementation would allow expressions made up of Expires December 2003 [Page 10] Internet Draft Expression MIB 13 June 2003 individual MIB objects but would not be suitable for expressions applied across large tables as each instance in the table would require a separate expression definition. Furthermore it would not be suitable for tables with arbitrary, dynamic instances, as expressions definitions could not predict what instance values to use. An implementation without wildcards might be useful for a self- managing system with small tables or few dynamic instances, or one that can do calculations only for a few key objects. 2.4.2. No Deltas Leaving out delta processing significantly reduces state that must be kept and the burden of ongoing processing even when no one is looking at the results. Unfortunately it also makes expressions on counters unusable, as counters have meaning only as deltas. An implementation without deltas might be useful for a severely limited, self-managing system that has no need for expressions or events on counters. Although conceivable, such systems would be rare. 2.5. Structure The MIB has the following sections: o Resource -- management of the MIB's use of system resources. o Definition -- definition of expressions. o Value -- values of evaluated expressions. 2.5.1. Resource The resource section has objects to manage resource usage by wildcarded delta expressions, a potential major consumer of CPU and memory. 2.5.2. Definition The definition section contains the tables that define expressions. The expression table, indexed by expression owner and expression Expires December 2003 [Page 11] Internet Draft Expression MIB 13 June 2003 name, contains those parameters that apply to the entire expression, such as the expression itself, the data type of the result, and the sampling interval if it contains delta or change values. The object table, indexed by expression owner, expression name and object index within each expression, contains the parameters that apply to the individual objects that go into the expression, including the object identifier, sample type, discontinuity indicator, and such. 2.5.3. Value The value section contains the values of evaluated expressions. The value table, indexed by expression owner, expression name and instance fragment contains a "discriminated union" of evaluated expression results. For a given expression only one of the columns is instantiated, depending on the result data type for the expression. The instance fragment is a constant or the final section of the object identifier that filled in a wildcard. 2.6. Examples The examples refer to tables and objects defined below in the MIB itself. They may well make more sense after reading those definitions. 2.6.1. Wildcarding An expression may use wildcarded MIB objects that result in multiple values for the expression. To specify a wildcarded MIB object a management application leaves off part or all of the instance portion of the object identifier, and sets expObjectWildcard to true(1) for that object. For our example we'll use a counter of total blessings from a table of people. Another table, indexed by town and person has blessings just from that town. So the index clauses are: personEntry OBJECT-TYPE ... INDEX { personIndex } And: Expires December 2003 [Page 12] Internet Draft Expression MIB 13 June 2003 townPersonEntry OBJECT-TYPE ... INDEX { townIndex, personIndex } Expires December 2003 [Page 13] Internet Draft Expression MIB 13 June 2003 In our friendly application we may have entered our expression as: 100 * townPersonBlessings.976.* / personBlessings.* What goes in expExpression is: 100*$1/$2 For example purposes we'll use some slightly far-fetched OIDs. The People MIB is 1.3.6.1.99.7 and the Town MIB is 1.3.6.1.99.11, so for our two counters the OIDs are: personBlessings 1.3.6.1.99.7.1.3.1.4 townPersonBlessings 1.3.6.1.99.11.1.2.1.9 The rule for wildcards is that all the wildcarded parts have to match exactly. In this case that means we have to hardwire the town and only the personIndex can be wildcarded. So our values for expObjectID are: 1.3.6.1.99.7.1.3.1.4 1.3.6.1.99.11.1.2.1.9.976 We're hardwired to townIndex 976 and personIndex is allowed to vary. The value of expExpressionPrefix can be either of those two counter OIDs (including the instance fragment in the second case), since either of them takes you to a MIB definition where you can look at the INDEX clause and figure out what's been left off. What's been left off doesn't have to work out to be the same object, but it does have to work out to be the same values (semantics) for the result to make sense. Note that the managed system can not typically check such semantics and if given nonsense will return nonsense. If we have people numbered 6, 19, and 42 in town number 976, the successive values of expValueInstance will be: 0.0.6 0.0.19 0.0.42 So there will be three values in expValueTable, with those OIDs as the expValueInstance part of their indexing. Expires December 2003 [Page 14] Internet Draft Expression MIB 13 June 2003 2.6.2. Calculation and Conditional The following formula for line utilization of a half-duplex link is adapted from [PracPersp]. utilization = (ifInOctets + ifOutOctets) * 800 / seconds / ifSpeed The expression results in the percentage line utilization per second. The total octets are multiplied by 8 to get bits and 100 to scale up the percentage as an integer. The following Expression MIB object values implement this as an expression for all ifIndexes that directly represent actual hardware. Since the octet counters are Counter32 values, they must be delta sampled to be meaningful. The sample period is 6 seconds but for accuracy and independence is calculated as a delta of sysUpTime. The expObjectTable entry for ifInOctets has an expObjectConditional that checks for being a hardware interface. Only one object in the expression needs that check associated, since it applies to the whole expression. Since ifConnectorPresent is a TruthValue with values of 1 or 2 rather than 0 and non-zero, it must also be in an expression rather than used directly for the conditional. The interface-specific discontinuity indicator is supplied only for ifInOctets since invalidating that sample will invalidate an attempt at evaluation, effectively invalidating ifOutOctets as well (correctly, because it has the same indicator). For notational clarity, in the rest of this document, a string in quotes as part of the object instance indicates the value that would actually be one subidentifier per byte. The objects all belong to owner "me". Also for clarity OIDs are expressed as the object descriptor and instance. In fact they must be supplied numerically, with all subidentifiers in place before the part for the particular object and instance. What the user would set in expExpressionTable: expExpression.2."me".4."hard" = "$1==1" expExpressionValueType.2."me".4."hard" = unsigned32 expExpressionEntryStatus.2."me"4."hard" = 'active' Expires December 2003 [Page 15] Internet Draft Expression MIB 13 June 2003 expExpression.2."me".4."util" = "($1+$2)*800/$4/$3" expExpressionValueType.2."me".4."util" = integer32 expExpressionDeltaInterval.2."me".4."util" = 6 expExpressionEntryStatus.2."me"4."util" = 'active' What the user would set in expObjectTable: expObjectID.2."me".4."hard".1 = ifConnectorPresent expObjectWildcard.2."me".4."hard".1 = 'true' expObjectSampleType.2."me".4."hard".1 = 'absoluteValue' expObjectEntryStatus.2."me".4."hard".1 = 'active' expObjectID.2."me".4."util".1 = ifInOctets expObjectWildcard.2."me".4."util".1 = 'true' expObjectSampleType.2."me".4."util".1 = 'deltaValue' expObjectConditional.2."me".4."util".1 = expValueUnsigned32Val.2."me".4."hard".0.0 expObjectConditionalWildcard.2."me".4."util".1 = 'true' expObjectDiscontinuityID.2."me".4."util".1 = ifCounterDiscontinuityTime expObjectDiscontinuityIDWildcard.2."me".4."util".1 = 'true' expObjectEntryStatus.2."me".4."util".1 = 'active' expObjectID.2."me".4."util".2 = ifOutOctets expObjectWildcard.2."me".4."util".2 = 'true' expObjectSampleType.2."me".4."util".2 = 'deltaValue' expObjectEntryStatus.2."me".4."util".2 = 'active' expObjectID.2."me".4."util".3 = ifSpeed expObjectWildcard.2."me".4."util".3 = 'true' expObjectSampleType.2."me".4."util".3 = 'absoluteValue' expObjectEntryStatus.2."me".4."util".3 = 'active' expObjectID.2."me".4."util".4 = sysUpTime.0 expObjectWildcard.2."me".4."util".4 = 'false' expObjectSampleType.2."me".4."util".4 = 'deltaValue' expObjectEntryStatus.2."me".4."util".4 = 'active' These settings will result in populating one column of expValueTable: expValueInteger32Val.2."me".4."util".0.0.? The subidentifier represented by "?" above represents one subidentifier that takes on a value of ifIndex and identifies a row for each ifIndex value where ifConnectorPresent is 'true' and the Expires December 2003 [Page 16] Internet Draft Expression MIB 13 June 2003 interface was present for two samples to provide a delta. Expires December 2003 [Page 17] Internet Draft Expression MIB 13 June 2003 This value could in turn be used as an event threshold [RFC2981] to watch for overutilization of all hardware network connections. 3. Definitions DISMAN-EXPRESSION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Gauge32, Unsigned32, Counter32, Counter64, IpAddress, TimeTicks, mib-2, zeroDotZero FROM SNMPv2-SMI RowStatus, TruthValue, TimeStamp FROM SNMPv2-TC sysUpTime FROM SNMPv2-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; dismanExpressionMIB MODULE-IDENTITY LAST-UPDATED "200306130000Z" -- 13 June 2003 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 defining expressions of MIB objects for management purposes. Copyright (C) The Internet Society 2003. This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this note -- Revision History REVISION "200306130000Z" -- 13 June 2003 DESCRIPTION "Added copyright statement to the MIB module description." REVISION "200111140000Z" -- 14 November 2001 DESCRIPTION "Updated the DESCRIPTION clause of expValueIpAddressVal, and removed the SIZE restriction of expValueOctetStringVal." REVISION "200010160000Z" -- 16 October 2000 Expires December 2003 [Page 18] Internet Draft Expression MIB 13 June 2003 DESCRIPTION "This is the initial version of this MIB. Published as RFC 2982" ::= { mib-2 90 } dismanExpressionMIBObjects OBJECT IDENTIFIER ::= { dismanExpressionMIB 1 } expResource OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 1 } expDefine OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 2 } expValue OBJECT IDENTIFIER ::= { dismanExpressionMIBObjects 3 } -- -- Resource Control -- expResourceDeltaMinimum OBJECT-TYPE SYNTAX Integer32 (-1 | 1..600) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum expExpressionDeltaInterval this system will accept. A system may use the larger values of this minimum to lessen the impact of constantly computing deltas. For larger delta sampling intervals the system samples less often and suffers less overhead. This object provides a way to enforce such lower overhead for all expressions created after it is set. The value -1 indicates that expResourceDeltaMinimum is irrelevant as the system will not accept 'deltaValue' as a value for expObjectSampleType. Unless explicitly resource limited, a system's value for this object should be 1, allowing as small as a 1 second interval for ongoing delta sampling. Changing this value will not invalidate an existing setting of expObjectSampleType." ::= { expResource 1 } expResourceDeltaWildcardInstanceMaximum OBJECT-TYPE SYNTAX Unsigned32 UNITS "instances" Expires December 2003 [Page 19] Internet Draft Expression MIB 13 June 2003 MAX-ACCESS read-write STATUS current DESCRIPTION "For every instance of a deltaValue object, one dynamic instance entry is needed for holding the instance value from the previous sample, i.e. to maintain state. This object limits maximum number of dynamic instance entries this system will support for wildcarded delta objects in expressions. For a given delta expression, the number of dynamic instances is the number of values that meet all criteria to exist times the number of delta values in the expression. A value of 0 indicates no preset limit, that is, the limit is dynamic based on system operation and resources. Unless explicitly resource limited, a system's value for this object should be 0. Changing this value will not eliminate or inhibit existing delta wildcard instance objects but will prevent the creation of more such objects. An attempt to allocate beyond the limit results in expErrorCode being tooManyWildcardValues for that evaluation attempt." ::= { expResource 2 } expResourceDeltaWildcardInstances OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active instance entries as defined for expResourceDeltaWildcardInstanceMaximum." ::= { expResource 3 } expResourceDeltaWildcardInstancesHigh OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest value of expResourceDeltaWildcardInstances that has occurred since initialization of the managed Expires December 2003 [Page 20] Internet Draft Expression MIB 13 June 2003 system." ::= { expResource 4 } expResourceDeltaWildcardInstanceResourceLacks OBJECT-TYPE SYNTAX Counter32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this system could not evaluate an expression because that would have created a value instance in excess of expResourceDeltaWildcardInstanceMaximum." ::= { expResource 5 } -- -- Definition -- -- Expression Definition Table -- expExpressionTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpExpressionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of expression definitions." ::= { expDefine 1 } expExpressionEntry OBJECT-TYPE SYNTAX ExpExpressionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single expression. New expressions can be created using expExpressionEntryStatus. To create an expression first create the named entry in this table. Then use expExpressionName to populate expObjectTable. For expression evaluation to succeed all related entries in expExpressionTable and expObjectTable must be 'active'. If these conditions are not met the corresponding values in expValue simply are not instantiated. Deleting an entry deletes all related entries in expObjectTable Expires December 2003 [Page 21] Internet Draft Expression MIB 13 June 2003 and expErrorTable. Because of the relationships among the multiple tables for an expression (expExpressionTable, expObjectTable, and expValueTable) and the SNMP rules for independence in setting object values, it is necessary to do final error checking when an expression is evaluated, that is, when one of its instances in expValueTable is read or a delta interval expires. Earlier checking need not be done and an implementation may not impose any ordering on the creation of objects related to an expression. To maintain security of MIB information, when creating a new row in this table, the managed system must record the security credentials of the requester. These security credentials are the parameters necessary as inputs to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. When obtaining the objects that make up the expression, the system must (conceptually) use isAccessAllowed to ensure that it does not violate security. The evaluation of the expression takes place under the security credentials of the creator of its expExpressionEntry. Values of read-write objects in this table may be changed at any time." INDEX { expExpressionOwner, expExpressionName } ::= { expExpressionTable 1 } ExpExpressionEntry ::= SEQUENCE { expExpressionOwner SnmpAdminString, expExpressionName SnmpAdminString, expExpression OCTET STRING, expExpressionValueType INTEGER, expExpressionComment SnmpAdminString, expExpressionDeltaInterval Integer32, expExpressionPrefix OBJECT IDENTIFIER, expExpressionErrors Counter32, expExpressionEntryStatus RowStatus } expExpressionOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current Expires December 2003 [Page 22] Internet Draft Expression MIB 13 June 2003 DESCRIPTION "The owner of this entry. The exact semantics of this string are subject to the security policy defined by the security administrator." ::= { expExpressionEntry 1 } expExpressionName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The name of the expression. This is locally unique, within the scope of an expExpressionOwner." ::= { expExpressionEntry 2 } expExpression OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..1024)) MAX-ACCESS read-create STATUS current DESCRIPTION "The expression to be evaluated. This object is the same as a DisplayString (RFC 1903) except for its maximum length. Except for the variable names the expression is in ANSI C syntax. Only the subset of ANSI C operators and functions listed here is allowed. Variables are expressed as a dollar sign ('$') and an integer that corresponds to an expObjectIndex. An example of a valid expression is: ($1-$5)*100 Expressions must not be recursive, that is although an expression may use the results of another expression, it must not contain any variable that is directly or indirectly a result of its own evaluation. The managed system must check for recursive expressions. The only allowed operators are: ( ) - (unary) + - * / % & | ^ << >> ~ Expires December 2003 [Page 23] Internet Draft Expression MIB 13 June 2003 ! && || == != > >= < <= Note the parentheses are included for parenthesizing the expression, not for casting data types. The only constant types defined are: int (32-bit signed) long (64-bit signed) unsigned int unsigned long hexadecimal character string oid The default type for a positive integer is int unless it is too large in which case it is long. All but oid are as defined for ANSI C. Note that a hexadecimal constant may end up as a scalar or an array of 8-bit integers. A string constant is enclosed in double quotes and may contain back-slashed individual characters as in ANSI C. An oid constant comprises 32-bit, unsigned integers and at least one period, for example: 0. .0 1.3.6.1 No additional leading or trailing subidentifiers are automatically added to an OID constant. The constant is taken as expressed. Integer-typed objects are treated as 32- or 64-bit, signed or unsigned integers, as appropriate. The results of mixing them are as for ANSI C, including the type of the result. Note that a 32-bit value is thus promoted to 64 bits only in an operation with a 64-bit value. There is no provision for larger values to handle overflow. Relative to SNMP data types, a resulting value becomes unsigned when calculating it uses any unsigned value, including a counter. To force the final value to be of Expires December 2003 [Page 24] Internet Draft Expression MIB 13 June 2003 data type counter the expression must explicitly use the counter32() or counter64() function (defined below). OCTET STRINGS and OBJECT IDENTIFIERs are treated as one-dimensioned arrays of unsigned 8-bit integers and unsigned 32-bit integers, respectively. IpAddresses are treated as 32-bit, unsigned integers in network byte order, that is, the hex version of 255.0.0.0 is 0xff000000. Conditional expressions result in a 32-bit, unsigned integer of value 0 for false or 1 for true. When an arbitrary value is used as a boolean 0 is false and non-zero is true. Rules for the resulting data type from an operation, based on the operator: For << and >> the result is the same as the left hand operand. For &&, ||, ==, !=, <, <=, >, and >= the result is always Unsigned32. For unary - the result is always Integer32. For +, -, *, /, %, &, |, and ^ the result is promoted according to the following rules, in order from most to least preferred: If left hand and right hand operands are the same type, use that. If either side is Counter64, use that. If either side is IpAddress, use that. If either side is TimeTicks, use that. If either side is Counter32, use that. Otherwise use Unsigned32. The following rules say what operators apply with what data types. Any combination not explicitly defined does not work. For all operators any of the following can be the left hand or Expires December 2003 [Page 25] Internet Draft Expression MIB 13 June 2003 right hand operand: Integer32, Counter32, Unsigned32, Counter64. The operators +, -, *, /, %, <, <=, >, and >= work with TimeTicks. The operators &, |, and ^ work with IpAddress. The operators << and >> work with IpAddress but only as the left hand operand. The + operator performs a concatenation of two OCTET STRINGs or two OBJECT IDENTIFIERs. The operators &, | perform bitwise operations on OCTET STRINGs. If the OCTET STRING happens to be a DisplayString the results may be meaningless, but the agent system does not check this as some such systems do not have this information. The operators << and >> perform bitwise operations on OCTET STRINGs appearing as the left hand operand. The only functions defined are: counter32 counter64 arraySection stringBegins stringEnds stringContains oidBegins oidEnds oidContains average maximum minimum sum exists The following function definitions indicate their parameters by naming the data type of the parameter in the parameter's position in the parameter list. The parameter must be of the type indicated and generally may be a constant, a MIB object, a function, or an expression. counter32(integer) - wrapped around an integer value counter32 Expires December 2003 [Page 26] Internet Draft Expression MIB 13 June 2003 forces Counter32 as a data type. counter64(integer) - similar to counter32 except that the resulting data type is 'counter64'. arraySection(array, integer, integer) - selects a piece of an array (i.e. part of an OCTET STRING or OBJECT IDENTIFIER). The integer arguments are in the range 0 to 4,294,967,295. The first is an initial array index (one-dimensioned) and the second is an ending array index. A value of 0 indicates first or last element, respectively. If the first element is larger than the array length the result is 0 length. If the second integer is less than or equal to the first, the result is 0 length. If the second is larger than the array length it indicates last element. stringBegins/Ends/Contains(octetString, octetString) - looks for the second string (which can be a string constant) in the first and returns the one-dimensioned arrayindex where the match began. A return value of 0 indicates no match (i.e. boolean false). oidBegins/Ends/Contains(oid, oid) - looks for the second OID (which can be an OID constant) in the first and returns the the one-dimensioned index where the match began. A return value of 0 indicates no match (i.e. boolean false). average/maximum/minimum(integer) - calculates the average, minimum, or maximum value of the integer valued object over multiple sample times. If the object disappears for any sample period, the accumulation and the resulting value object cease to exist until the object reappears at which point the calculation starts over. sum(integerObject*) - sums all available values of the wildcarded integer object, resulting in an integer scalar. Must be used with caution as it wraps on overflow with no notification. exists(anyTypeObject) - verifies the object instance exists. A return value of 0 indicates NoSuchInstance (i.e. boolean false)." ::= { expExpressionEntry 3 } expExpressionValueType OBJECT-TYPE SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), Expires December 2003 [Page 27] Internet Draft Expression MIB 13 June 2003 integer32(4), ipAddress(5), octetString(6), objectId(7), counter64(8) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the expression value. One and only one of the value objects in expValueTable will be instantiated to match this type. If the result of the expression can not be made into this type, an invalidOperandType error will occur." DEFVAL { counter32 } ::= { expExpressionEntry 4 } expExpressionComment OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A comment to explain the use or meaning of the expression." DEFVAL { ''H } ::= { expExpressionEntry 5 } expExpressionDeltaInterval OBJECT-TYPE SYNTAX Integer32 (0..86400) UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Sampling interval for objects in this expression with expObjectSampleType 'deltaValue'. This object has no effect if the the expression has no deltaValue objects. A value of 0 indicates no automated sampling. In this case the delta is the difference from the last time the expression was evaluated. Note that this is subject to unpredictable delta times in the face of retries or multiple managers. A value greater than zero is the number of seconds between automated samples. Until the delta interval has expired once the delta for the object is effectively not instantiated and evaluating Expires December 2003 [Page 28] Internet Draft Expression MIB 13 June 2003 the expression has results as if the object itself were not instantiated. Note that delta values potentially consume large amounts of system CPU and memory. Delta state and processing must continue constantly even if the expression is not being used. That is, the expression is being evaluated every delta interval, even if no application is reading those values. For wildcarded objects this can be substantial overhead. Note that delta intervals, external expression value sampling intervals and delta intervals for expressions within other expressions can have unusual interactions as they are impossible to synchronize accurately. In general one interval embedded below another must be enough shorter that the higher sample sees relatively smooth, predictable behavior. So, for example, to avoid the higher level getting the same sample twice, the lower level should sample at least twice as fast as the higher level does." DEFVAL { 0 } ::= { expExpressionEntry 6 } expExpressionPrefix OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "An object prefix to assist an application in determining the instance indexing to use in expValueTable, relieving the application of the need to scan the expObjectTable to determine such a prefix. See expObjectTable for information on wildcarded objects. If the expValueInstance portion of the value OID may be treated as a scalar (that is, normally, 0) the value of expExpressionPrefix is zero length, that is, no OID at all. Note that zero length implies a null OID, not the OID 0.0. Otherwise, the value of expExpressionPrefix is the expObjectID value of any one of the wildcarded objects for the expression. This is sufficient, as the remainder, that is, the instance fragment relevant to instancing the values, must be the same for all wildcarded objects in the expression." ::= { expExpressionEntry 7 } Expires December 2003 [Page 29] Internet Draft Expression MIB 13 June 2003 expExpressionErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of errors encountered while evaluating this expression. Note that an object in the expression not being accessible, is not considered an error. An example of an inaccessible object is when the object is excluded from the view of the user whose security credentials are used in the expression evaluation. In such cases, it is a legitimate condition that causes the corresponding expression value not to be instantiated." ::= { expExpressionEntry 8 } expExpressionEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries." ::= { expExpressionEntry 9 } -- -- Expression Error Table -- expErrorTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of expression errors." ::= { expDefine 2 } expErrorEntry OBJECT-TYPE SYNTAX ExpErrorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about errors in processing an expression. Entries appear in this table only when there is a matching Expires December 2003 [Page 30] Internet Draft Expression MIB 13 June 2003 expExpressionEntry and then only when there has been an error for that expression as reflected by the error codes defined for expErrorCode." INDEX { expExpressionOwner, expExpressionName } ::= { expErrorTable 1 } ExpErrorEntry ::= SEQUENCE { expErrorTime TimeStamp, expErrorIndex Integer32, expErrorCode INTEGER, expErrorInstance OBJECT IDENTIFIER } expErrorTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime the last time an error caused a failure to evaluate this expression." ::= { expErrorEntry 1 } expErrorIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The one-dimensioned character array index into expExpression for where the error occurred. The value zero indicates irrelevance." ::= { expErrorEntry 2 } expErrorCode OBJECT-TYPE SYNTAX INTEGER { invalidSyntax(1), undefinedObjectIndex(2), unrecognizedOperator(3), unrecognizedFunction(4), invalidOperandType(5), unmatchedParenthesis(6), tooManyWildcardValues(7), recursion(8), deltaTooShort(9), resourceUnavailable(10), divideByZero(11) Expires December 2003 [Page 31] Internet Draft Expression MIB 13 June 2003 } MAX-ACCESS read-only STATUS current DESCRIPTION "The error that occurred. In the following explanations the expected timing of the error is in parentheses. 'S' means the error occurs on a Set request. 'E' means the error occurs on the attempt to evaluate the expression either due to Get from expValueTable or in ongoing delta processing. invalidSyntax the value sent for expExpression is not valid Expression MIB expression syntax (S) undefinedObjectIndex an object reference ($n) in expExpression does not have a matching instance in expObjectTable (E) unrecognizedOperator the value sent for expExpression held an unrecognized operator (S) unrecognizedFunction the value sent for expExpression held an unrecognized function name (S) invalidOperandType an operand in expExpression is not the right type for the associated operator or result (SE) unmatchedParenthesis the value sent for expExpression is not correctly parenthesized (S) tooManyWildcardValues evaluating the expression exceeded the limit set by expResourceDeltaWildcardInstanceMaximum (E) recursion through some chain of embedded expressions the expression invokes itself (E) deltaTooShort the delta for the next evaluation passed before the system could evaluate the present sample (E) resourceUnavailable some resource, typically dynamic memory, was unavailable (SE) divideByZero an attempt to divide by zero occurred (E) For the errors that occur when the attempt is made to set expExpression Set request fails with the SNMP error code 'wrongValue'. Such failures refer to the most recent failure to Set expExpression, not to the present value of expExpression which must be either unset or syntactically correct. Expires December 2003 [Page 32] Internet Draft Expression MIB 13 June 2003 Errors that occur during evaluation for a Get* operation return the SNMP error code 'genErr' except for 'tooManyWildcardValues' and 'resourceUnavailable' which return the SNMP error code 'resourceUnavailable'." ::= { expErrorEntry 3 } expErrorInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The expValueInstance being evaluated when the error occurred. A zero-length indicates irrelevance." ::= { expErrorEntry 4 } -- -- Object Table -- expObjectTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of object definitions for each expExpression. Wildcarding instance IDs: It is legal to omit all or part of the instance portion for some or all of the objects in an expression. (See the DESCRIPTION of expObjectID for details. However, note that if more than one object in the same expression is wildcarded in this way, they all must be objects where that portion of the instance is the same. In other words, all objects may be in the same SEQUENCE or in different SEQUENCEs but with the same semantic index value (e.g., a value of ifIndex) for the wildcarded portion." ::= { expDefine 3 } expObjectEntry OBJECT-TYPE SYNTAX ExpObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about an object. An application uses Expires December 2003 [Page 33] Internet Draft Expression MIB 13 June 2003 expObjectEntryStatus to create entries in this table while in the process of defining an expression. Values of read-create objects in this table may be changed at any time." INDEX { expExpressionOwner, expExpressionName, expObjectIndex } ::= { expObjectTable 1 } ExpObjectEntry ::= SEQUENCE { expObjectIndex Unsigned32, expObjectID OBJECT IDENTIFIER, expObjectIDWildcard TruthValue, expObjectSampleType INTEGER, expObjectDeltaDiscontinuityID OBJECT IDENTIFIER, expObjectDiscontinuityIDWildcard TruthValue, expObjectDiscontinuityIDType INTEGER, expObjectConditional OBJECT IDENTIFIER, expObjectConditionalWildcard TruthValue, expObjectEntryStatus RowStatus } expObjectIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Within an expression, a unique, numeric identification for an object. Prefixed with a dollar sign ('$') this is used to reference the object in the corresponding expExpression." ::= { expObjectEntry 1 } expObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of this object. The OID may be fully qualified, meaning it includes a complete instance identifier part (e.g., ifInOctets.1 or sysUpTime.0), or it may not be fully qualified, meaning it may lack all or part of the instance identifier. If the expObjectID is not fully qualified, then expObjectWildcard must be set to true(1). The value of the expression will be multiple values, as if done for a GetNext sweep of the object. Expires December 2003 [Page 34] Internet Draft Expression MIB 13 June 2003 An object here may itself be the result of an expression but recursion is not allowed. NOTE: The simplest implementations of this MIB may not allow wildcards." ::= { expObjectEntry 2 } expObjectIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjecID of this row is a wildcard object. False indicates that expObjectID is fully instanced. If all expObjectWildcard values for a given expression are FALSE, expExpressionPrefix will reflect a scalar object (i.e. will be 0.0). NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 3 } expObjectSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2), changedValue(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The method of sampling the selected variable. An 'absoluteValue' is simply the present value of the object. A 'deltaValue' is the present value minus the previous value, which was sampled expExpressionDeltaInterval seconds ago. This is intended primarily for use with SNMP counters, which are meaningless as an 'absoluteValue', but may be used with any integer-based value. A 'changedValue' is a boolean for whether the present value is different from the previous value. It is applicable to any data type and results in an Unsigned32 with value 1 if the object's value is changed and 0 if not. In all other respects it is as a 'deltaValue' and all statements and operation regarding delta values apply to changed values. Expires December 2003 [Page 35] Internet Draft Expression MIB 13 June 2003 When an expression contains both delta and absolute values the absolute values are obtained at the end of the delta period." DEFVAL { absoluteValue } ::= { expObjectEntry 4 } sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } expObjectDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or DateAndTime object that indicates a discontinuity in the value at expObjectID. This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'. The OID may be for a leaf object (e.g. sysUpTime.0) or may be wildcarded to match expObjectID. This object supports normal checking for a discontinuity in a counter. Note that if this object does not point to sysUpTime discontinuity checking must still check sysUpTime for an overall discontinuity. If the object identified is not accessible no discontinuity check will be made." DEFVAL { sysUpTimeInstance } ::= { expObjectEntry 5 } expObjectDiscontinuityIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjectDeltaDiscontinuityID of this row is a wildcard object. False indicates that expObjectDeltaDiscontinuityID is fully instanced. This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'. Expires December 2003 [Page 36] Internet Draft Expression MIB 13 June 2003 NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 6 } expObjectDiscontinuityIDType OBJECT-TYPE SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value 'timeTicks' indicates the expObjectDeltaDiscontinuityID of this row is of syntax TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. The value 'dateAndTime indicates syntax DateAndTime. This object is instantiated only if expObjectSampleType is 'deltaValue' or 'changedValue'." DEFVAL { timeTicks } ::= { expObjectEntry 7 } expObjectConditional OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of an object that overrides whether the instance of expObjectID is to be considered usable. If the value of the object at expObjectConditional is 0 or not instantiated, the object at expObjectID is treated as if it is not instantiated. In other words, expObjectConditional is a filter that controls whether or not to use the value at expObjectID. The OID may be for a leaf object (e.g. sysObjectID.0) or may be wildcarded to match expObjectID. If expObject is wildcarded and expObjectID in the same row is not, the wild portion of expObjectConditional must match the wildcarding of the rest of the expression. If no object in the expression is wildcarded but expObjectConditional is, use the lexically first instance (if any) of expObjectConditional. If the value of expObjectConditional is 0.0 operation is as if the value pointed to by expObjectConditional is a non-zero (true) value. Expires December 2003 [Page 37] Internet Draft Expression MIB 13 June 2003 Note that expObjectConditional can not trivially use an object of syntax TruthValue, since the underlying value is not 0 or 1." DEFVAL { zeroDotZero } ::= { expObjectEntry 8 } expObjectConditionalWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A true value indicates the expObjectConditional of this row is a wildcard object. False indicates that expObjectConditional is fully instanced. NOTE: The simplest implementations of this MIB may not allow wildcards." DEFVAL { false } ::= { expObjectEntry 9 } expObjectEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation/deletion of entries. Objects in this table may be changed while expObjectEntryStatus is in any state." ::= { expObjectEntry 10 } -- -- Expression Value Table -- expValueTable OBJECT-TYPE SYNTAX SEQUENCE OF ExpValueEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of values from evaluated expressions." ::= { expValue 1 } expValueEntry OBJECT-TYPE SYNTAX ExpValueEntry Expires December 2003 [Page 38] Internet Draft Expression MIB 13 June 2003 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single value from an evaluated expression. For a given instance, only one 'Val' object in the conceptual row will be instantiated, that is, the one with the appropriate type for the value. For values that contain no objects of expObjectSampleType 'deltaValue' or 'changedValue', reading a value from the table causes the evaluation of the expression for that value. For those that contain a 'deltaValue' or 'changedValue' the value read is as of the last sampling interval. If in the attempt to evaluate the expression one or more of the necessary objects is not available, the corresponding entry in this table is effectively not instantiated. To maintain security of MIB information, when creating a new row in this table, the managed system must record the security credentials of the requester. These security credentials are the parameters necessary as inputs to isAccessAllowed from [RFC2571]. When obtaining the objects that make up the expression, the system must (conceptually) use isAccessAllowed to ensure that it does not violate security. The evaluation of that expression takes place under the security credentials of the creator of its expExpressionEntry. To maintain security of MIB information, expression evaluation must take place using security credentials for the implied Gets of the objects in the expression as inputs (conceptually) to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. These are the security credentials of the creator of the corresponding expExpressionEntry." INDEX { expExpressionOwner, expExpressionName, IMPLIED expValueInstance } ::= { expValueTable 1 } ExpValueEntry ::= SEQUENCE { expValueInstance OBJECT IDENTIFIER, expValueCounter32Val Counter32, expValueUnsigned32Val Unsigned32, expValueTimeTicksVal TimeTicks, expValueInteger32Val Integer32, expValueIpAddressVal IpAddress, Expires December 2003 [Page 39] Internet Draft Expression MIB 13 June 2003 expValueOctetStringVal OCTET STRING, expValueOidVal OBJECT IDENTIFIER, expValueCounter64Val Counter64 } expValueInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The final instance portion of a value's OID according to the wildcarding in instances of expObjectID for the expression. The prefix of this OID fragment is 0.0, leading to the following behavior. If there is no wildcarding, the value is 0.0.0. In other words, there is one value which standing alone would have been a scalar with a 0 at the end of its OID. If there is wildcarding, the value is 0.0 followed by a value that the wildcard can take, thus defining one value instance for each real, possible value of the wildcard. So, for example, if the wildcard worked out to be an ifIndex, there is an expValueInstance for each applicable ifIndex." ::= { expValueEntry 1 } expValueCounter32Val OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'counter32'." ::= { expValueEntry 2 } expValueUnsigned32Val OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'unsigned32'." ::= { expValueEntry 3 } expValueTimeTicksVal OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only Expires December 2003 [Page 40] Internet Draft Expression MIB 13 June 2003 STATUS current DESCRIPTION "The value when expExpressionValueType is 'timeTicks'." ::= { expValueEntry 4 } expValueInteger32Val OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'integer32'." ::= { expValueEntry 5 } expValueIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'ipAddress'. This object type is necessary to support values represented using the IpAddress type, which is limited to IPv4. IPv6 addressess are represented using the OCTET STRING type, and would thus show up as instances of expValueOctetStringVal." ::= { expValueEntry 6 } expValueOctetStringVal OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'octetString'." ::= { expValueEntry 7 } expValueOidVal OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value when expExpressionValueType is 'objectId'." ::= { expValueEntry 8 } expValueCounter64Val OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only Expires December 2003 [Page 41] Internet Draft Expression MIB 13 June 2003 STATUS current DESCRIPTION "The value when expExpressionValueType is 'counter64'." ::= { expValueEntry 9 } -- -- Conformance -- dismanExpressionMIBConformance OBJECT IDENTIFIER ::= { dismanExpressionMIB 3 } dismanExpressionMIBCompliances OBJECT IDENTIFIER ::= { dismanExpressionMIBConformance 1 } dismanExpressionMIBGroups OBJECT IDENTIFIER ::= { dismanExpressionMIBConformance 2 } -- Compliance dismanExpressionMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Expression MIB." MODULE -- this module MANDATORY-GROUPS { dismanExpressionResourceGroup, dismanExpressionDefinitionGroup, dismanExpressionValueGroup } OBJECT expResourceDeltaMinimum SYNTAX Integer32 (-1 | 60..600) DESCRIPTION "Implementation need not allow deltas or it may implement them and restrict them to higher values." OBJECT expObjectSampleType WRITE-SYNTAX INTEGER { absoluteValue(1) } DESCRIPTION "Implementation may disallow deltas calculation or change detection." OBJECT expObjectIDWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION Expires December 2003 [Page 42] Internet Draft Expression MIB 13 June 2003 "Implementation may allow wildcards." OBJECT expObjectDiscontinuityIDWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION "Implementation need not allow wildcards." OBJECT expObjectConditionalWildcard WRITE-SYNTAX INTEGER { false(2) } DESCRIPTION "Implementation need not allow deltas wildcards." ::= { dismanExpressionMIBCompliances 1 } -- Units of Conformance dismanExpressionResourceGroup OBJECT-GROUP OBJECTS { expResourceDeltaMinimum, expResourceDeltaWildcardInstanceMaximum, expResourceDeltaWildcardInstances, expResourceDeltaWildcardInstancesHigh, expResourceDeltaWildcardInstanceResourceLacks } STATUS current DESCRIPTION "Expression definition resource management." ::= { dismanExpressionMIBGroups 1 } dismanExpressionDefinitionGroup OBJECT-GROUP OBJECTS { expExpression, expExpressionValueType, expExpressionComment, expExpressionDeltaInterval, expExpressionPrefix, expExpressionErrors, expExpressionEntryStatus, expErrorTime, expErrorIndex, expErrorCode, expErrorInstance, expObjectID, Expires December 2003 [Page 43] Internet Draft Expression MIB 13 June 2003 expObjectIDWildcard, expObjectSampleType, expObjectDeltaDiscontinuityID, expObjectDiscontinuityIDWildcard, expObjectDiscontinuityIDType, expObjectConditional, expObjectConditionalWildcard, expObjectEntryStatus } STATUS current DESCRIPTION "Expression definition." ::= { dismanExpressionMIBGroups 2 } dismanExpressionValueGroup OBJECT-GROUP OBJECTS { expValueCounter32Val, expValueUnsigned32Val, expValueTimeTicksVal, expValueInteger32Val, expValueIpAddressVal, expValueOctetStringVal, expValueOidVal, expValueCounter64Val } STATUS current DESCRIPTION "Expression value." ::= { dismanExpressionMIBGroups 3 } END 4. 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 Expires December 2003 [Page 44] Internet Draft Expression MIB 13 June 2003 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. 5. Acknowledgements This MIB contains considerable contributions from the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), and colleagues at Cisco who did the first implementation. 6. References [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture 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] Rose, M., "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. Expires December 2003 [Page 45] Internet Draft Expression MIB 13 June 2003 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. Expires December 2003 [Page 46] Internet Draft Expression MIB 13 June 2003 [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 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. [RFC2981] Stewart, B., "Event MIB", RFC 2981, October 2000. [PracPersp] Leinwand, A. and K. Fang, "Network Management: A Practical Perspective", Addison-Wesley Publishing Company, Inc., 1993. 7. Security Considerations Expires December 2003 [Page 47] Internet Draft Expression MIB 13 June 2003 Expression MIB security involves two perspectives: protection of expressions from tampering or unauthorized use of resources, and protection of the objects used to calculate the expressions. Security of expression definitions and results depends on the expression owner (expExpressionOwner). With view-based access control [RFC2575] a network manager can control who has what level of access to what expressions. Access control for the objects within the expression depends on the security credentials of the expression creator. These are the security credentials used to get the objects necessary to evaluate the expression. They are the security credentials that were used to set the expExpressionEntryStatus object for that expression to 'active', as recorded by the managed system. This means that the results of an expression could potentially be made available to someone who does not have access to the raw data that went into them. This could be either legitimate or a security violation, depending on the specific situation and security policy. To facilitate the provisioning of access control by a security administrator for this MIB itself using the View-Based Access Control Model (VACM) defined in RFC 2575 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. Expires December 2003 [Page 48] Internet Draft Expression MIB 13 June 2003 8. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. 9. Editor's Address 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 December 2003 [Page 49] Internet Draft Expression MIB 13 June 2003 10. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 December 2003 [Page 50] From disman-admin@ietf.org Sat Jun 14 03:26:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20959 for ; Sat, 14 Jun 2003 03:26:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMJ1a27590; Fri, 13 Jun 2003 18:19:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMI7m27502 for ; Fri, 13 Jun 2003 18:18:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26115; Fri, 13 Jun 2003 18:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qwox-0001kc-00; Fri, 13 Jun 2003 18:14:55 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19Qwov-0001kW-00; Fri, 13 Jun 2003 18:14:53 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5DMGUI2022246; Fri, 13 Jun 2003 15:16:31 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIC73001; Fri, 13 Jun 2003 15:11:10 -0700 (PDT) Message-ID: <3EEA4D38.6060606@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts@ietf.org CC: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Disman] Please accept draft-ietf-disman-event-mib-03.txt for posting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 15:16:24 -0700 Content-Transfer-Encoding: 7bit Please accept draft-ietf-disman-event-mib-v2-03.txt for posting as an internet draft. Thank you, Ram Kavasseri Disman Working Group R. Kavasseri Internet Draft Cisco Systems, Inc. Document: draft-ietf-disman-event-mib-v2-03.txt B. Stewart Expiration Date: December 2003 Retired June 2003 Event MIB 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 (2003). All Rights Reserved. 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 that can be used to manage and monitor MIB objects and take action through events. Internet Draft Distributed Management Event MIB 13 June 2003 The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. 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. Table of Contents 1 The SNMP Management Framework ............................... 2 2 Overview .................................................... 3 3 Relationship to Other MIBs .................................. 3 4 MIB Sections ................................................ 4 5 Operation ................................................... 5 6 Security .................................................... 7 7 Definitions ................................................. 7 8 Intellectual Property ....................................... 47 9 Acknowledgements ............................................ 47 10 References ................................................. 47 11 Security Considerations .................................... 49 12 Author's Address ........................................... 49 13 Editor's Address ........................................... 49 14 Full Copyright Statement ................................... 50 1. 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], STD 58, RFC 2579 [RFC2579] and STD 58, 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 Expires December 2003 [Page 2] Internet Draft Distributed Management Event MIB 13 June 2003 [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]. 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. Expires December 2003 [Page 3] Internet Draft Distributed Management Event MIB 13 June 2003 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. It may not be possible to meaningfully monitor Counter64 objects using an SMIv1 version of the MIB. 2. Overview With network sizes well beyond the ability of people to manage them directly, automated, distributed management is vital. An important aspect of such management is the ability of a system to monitor itself or for some other system to monitor it. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. The MIB is intended to suit either a relatively powerful manager or mid- level manager, as well as a somewhat more limited self-managing system. 3. Relationship to Other MIBs The Event MIB is based on extensive experience with the RMON MIB [RFC1757] and provides a superset of the capabilities of the RMON alarm and event groups. Conceptually, the key extension is the ability to allow alarms to be generated for MIB objects that are on another network element. The Event MIB calls "triggers" what the RMON MIB called "alarms," but the concepts are the same. Event MIB triggers maintain the RMON handling of thresholds and add the concept of booleans. Event MIB events maintain the RMON concept of sending an SNMP notification in response to a trigger and add the concept of setting a MIB object. The Event MIB is the successor and update to SNMPv2's Manager-to- Manager MIB [RFC1451] which was declared Historic pending this work. The Event MIB depends on the services of the SNMPv3 Management Target and Notification MIBs [RFC2573]. Expires December 2003 [Page 4] Internet Draft Distributed Management Event MIB 13 June 2003 The Event MIB is nicely complemented by the Distributed Management Expression MIB [RFC2982], which is the expected source of boolean objects to monitor. Note that there is considerable overlap between the wildcard and delta sample capabilities of the Event and Expression MIBs. A carefully-planned implementation might well use common code to provide the overlapping functions. 4. MIB Sections The MIB has four sections: triggers, objects, events, and notifications. Triggers define the conditions that lead to events. Events may cause notifications. The trigger table lists what objects are to be monitored and how and relates each trigger to an event. It has supplementary, companion tables for additional objects that depend on the type of test done for the trigger. The objects table lists objects that can be added to notifications based on the trigger, the trigger test type, or the event that resulted in the notification. The event table defines what happens when an event is triggered: sending a notification, setting a MIB object or both. It has supplementary, companion tables for additional objects that depend on the action taken. The notification section defines a set of generic notifications to go with the events and for Event MIB error handling, and it defines a set of objects to put in those notifications. The following diagram describes the relationships between the tables in the Event MIB. Expires December 2003 [Page 5] Internet Draft Distributed Management Event MIB 13 June 2003 +-----------------------------+ | mteTriggerEntry | subclassed by: | { mteOwner, |---+ | IMPLIED mteTriggerName } | +-- mteTriggerDeltaEntry | | | | | +-- mteTriggerExistenceEntry | | | | | +-- mteTriggerBooleanEntry | | | | | +-- mteTriggerThresholdEntry | | | mteTrigger*Event -------------------------------->+ | | | | mteTriggerObjects ------------------>+ | +-----------------------------+ | | | | +-----------------------------+ V | | mteObjectsEntry | | | | { mteOwner, |<-------------+ | | mteObjectsName, | | | mteObjectsIndex } | | +-----------------------------+ | V +---------------------------+ | | mteEventEntry |<----------------------------+ | { mteOwner, | | IMPLIED mteEventName } | | | | mteEventAction---> + (condition) +---------------------------+ | V +---------------------------+ | +--------------------------+ | mteEventNotificationEntry | | | mteEventSetEntry | | { mteOwner, |<--+-->| { mteOwner, | | IMPLIED mteEventName } | | IMPLIED mteEventName } | +---------------------------+ +---------------------------+ 5. Operation The Event MIB is instrumentation for a distributed management application that monitors MIB objects. In its simplest form this application monitors individual, local MIB objects, just as an RMON probe fulfills the functions implied by RMON's alarm and event operation. Additionally the application can monitor remote objects and wildcarded groups of objects. Expires December 2003 [Page 6] Internet Draft Distributed Management Event MIB 13 June 2003 Remote monitoring uses the tag service of the Management Target MIB [RFC2573] to select and access remote systems as an ordinary SNMP- based management application. Local monitoring may be via a more intimate, local interface which may, for example, bypass SNMP encoding but otherwise is functionally identical to remote SNMP operation, including the application of access control. A self- management only system MAY not implement remote monitoring. Wildcards indicate that the application SHOULD use a GetNext-type operation to find the zero or more instances implied by a truncated object identifier, just like an ordinary SNMP-based management application. Each instance of a wildcard is treated as if it were a separate entry, that is the instances of a wildcarded object are independent of one another. For example, a wild-carded object may trigger an event, and result in the setting of another wildcarded object. The instance that satisfied the trigger function is used to perform the set function. All of this takes place independently of any additional instances that may fill the wildcard. Error handling is by notification. These error notifications SHOULD be enabled only for the diagnosis of problems indicated by error counters. If minimizing the probability of notification loss is a concern they SHOULD be transmitted as Inform PDUs as described in the [SNMP-TARGET-MIB] or directed to a log as described in the Notification Log MIB [rfcNotificationLogMIB]. Note that this does not mean the Notification Log MIB is REQUIRED, since in fact notifications usually are not lost, but that the Notification Log MIB can be helpful with this as well as other MIBs that include notifications. Although like most MIBs this one has no explicit controls for the persistence of the values set in configuring events, a robust, polite implementation would certainly not force its managing applications to reconfigure it whenever it resets. Again, as with most MIBs, it is implementation-specific how a system provides and manages such persistence. To speculate, one could imagine, for example, that persistence depended on the context in which the expression was configured, or perhaps system-specific characteristics of the expression's owner. Or perhaps everything in a MIB such as this one, which is clearly aimed at persistent configuration, is automatically part of a system's other persistent configuration. Expires December 2003 [Page 7] Internet Draft Distributed Management Event MIB 13 June 2003 6. Security Security of Event MIB entries depends on SNMPv3 access control for the entire MIB or for subsets based on entry owner names. Security of monitored objects for remote access depends on the Management Target MIB [RFC2573]. Security for local access can depend on the Management Target MIB or on recording appropriate security credentials of the creator of an entry and using those to access the local objects. These security credentials are the parameters necessary as inputs to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. When accessing local objects without using a local target tag, the system MUST (conceptually) use isAccessAllowed to ensure that it does not violate security. To facilitate the provisioning of access control by a security administrator for this MIB itself using the View-Based Access Control Model (VACM) defined in RFC 2275 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. If a security administrator were to employ such an approach, all entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same sub-identifiers (except for the "column" sub-identifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column sub-identifier. More elaborate configurations are possible. 7. Definitions DISMAN-EVENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, NOTIFICATION-TYPE, Counter32, Expires December 2003 [Page 8] Internet Draft Distributed Management Event MIB 13 June 2003 Gauge32, mib-2, zeroDotZero FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF sysUpTime FROM SNMPv2-MIB SnmpTagValue FROM SNMP-TARGET-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; dismanEventMIB MODULE-IDENTITY LAST-UPDATED "200306130000Z" -- 13 June 2003 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 526 4527 Email: ramk@cisco.com" DESCRIPTION "The MIB module for defining event triggers and actions for network management purposes. Copyright (C) The Internet Society 2003. This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this note -- Revision History REVISION "200306130000Z" -- 13 June 2003 DESCRIPTION "Added copyright statement to the MIB module description." REVISION "200111140000Z" -- 14 November 2001 DESCRIPTION "Updated the DESCRIPTION clauses of mteEventEntryStatus, mteTriggerEnabled and mteTriggerEntryStatus." REVISION "200010160000Z" -- 16 October 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC 2981" ::= { mib-2 88 } dismanEventMIBObjects OBJECT IDENTIFIER ::= { dismanEventMIB 1 } -- Management Triggered Event (MTE) objects mteResource OBJECT IDENTIFIER ::= { dismanEventMIBObjects 1 } Expires December 2003 [Page 9] Internet Draft Distributed Management Event MIB 13 June 2003 mteTrigger OBJECT IDENTIFIER ::= { dismanEventMIBObjects 2 } mteObjects OBJECT IDENTIFIER ::= { dismanEventMIBObjects 3 } mteEvent OBJECT IDENTIFIER ::= { dismanEventMIBObjects 4 } -- -- Textual Conventions -- FailureReason ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Reasons for failures in an attempt to perform a management request. The first group of errors, numbered less than 0, are related to problems in sending the request. The existence of a particular error code here does not imply that all implementations are capable of sensing that error and returning that code. The second group, numbered greater than 0, are copied directly from SNMP protocol operations and are intended to carry exactly the meanings defined for the protocol as returned in an SNMP response. localResourceLack some local resource such as memory lacking or mteResourceSampleInstanceMaximum exceeded badDestination unrecognized domain name or otherwise invalid destination address destinationUnreachable can't get to destination address noResponse no response to SNMP request badType the data syntax of a retrieved object as not as expected sampleOverrun another sample attempt occurred before the previous one completed" SYNTAX INTEGER { localResourceLack(-1), badDestination(-2), destinationUnreachable(-3), noResponse(-4), badType(-5), sampleOverrun(-6), Expires December 2003 [Page 10] Internet Draft Distributed Management Event MIB 13 June 2003 noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4), genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18) } -- -- Resource Control Section -- mteResourceSampleMinimum OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum mteTriggerFrequency this system will accept. A system may use the larger values of this minimum to lessen the impact of constant sampling. For larger sampling intervals the system samples less often and suffers less overhead. This object provides a way to enforce such lower overhead for all triggers created after it is set. Unless explicitly resource limited, a system's value for this object SHOULD be 1, allowing as small as a 1 second interval for ongoing trigger sampling. Changing this value will not invalidate an existing setting of mteTriggerFrequency." ::= { mteResource 1 } Expires December 2003 [Page 11] Internet Draft Distributed Management Event MIB 13 June 2003 mteResourceSampleInstanceMaximum OBJECT-TYPE SYNTAX Unsigned32 UNITS "instances" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of instance entries this system will support for sampling. These are the entries that maintain state, one for each instance of each sampled object as selected by mteTriggerValueID. Note that wildcarded objects result in multiple instances of this state. A value of 0 indicates no preset limit, that is, the limit is dynamic based on system operation and resources. Unless explicitly resource limited, a system's value for this object SHOULD be 0. Changing this value will not eliminate or inhibit existing sample state but could prevent allocation of additional state information." ::= { mteResource 2 } mteResourceSampleInstances OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active instance entries as defined for mteResourceSampleInstanceMaximum." ::= { mteResource 3 } mteResourceSampleInstancesHigh OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest value of mteResourceSampleInstances that has occurred since initialization of the management system." ::= { mteResource 4 } Expires December 2003 [Page 12] Internet Draft Distributed Management Event MIB 13 June 2003 mteResourceSampleInstanceLacks OBJECT-TYPE SYNTAX Counter32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this system could not take a new sample because that allocation would have exceeded the limit set by mteResourceSampleInstanceMaximum." ::= { mteResource 5 } -- -- Trigger Section -- -- Counters mteTriggerFailures OBJECT-TYPE SYNTAX Counter32 UNITS "failures" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an attempt to check for a trigger condition has failed. This counts individually for each attempt in a group of targets or each attempt for a wildcarded object." ::= { mteTrigger 1 } -- -- Trigger Table -- mteTriggerTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information." ::= { mteTrigger 2 } mteTriggerEntry OBJECT-TYPE SYNTAX MteTriggerEntry MAX-ACCESS not-accessible STATUS current Expires December 2003 [Page 13] Internet Draft Distributed Management Event MIB 13 June 2003 DESCRIPTION "Information about a single trigger. Applications create and delete entries using mteTriggerEntryStatus." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerTable 1 } MteTriggerEntry ::= SEQUENCE { mteOwner SnmpAdminString, mteTriggerName SnmpAdminString, mteTriggerComment SnmpAdminString, mteTriggerTest BITS, mteTriggerSampleType INTEGER, mteTriggerValueID OBJECT IDENTIFIER, mteTriggerValueIDWildcard TruthValue, mteTriggerTargetTag SnmpTagValue, mteTriggerContextName SnmpAdminString, mteTriggerContextNameWildcard TruthValue, mteTriggerFrequency Unsigned32, mteTriggerObjectsOwner SnmpAdminString, mteTriggerObjects SnmpAdminString, mteTriggerEnabled TruthValue, mteTriggerEntryStatus RowStatus, mteTriggerEntryStorageType StorageType } mteOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The owner of this entry. The exact semantics of this string are subject to the security policy defined by the security administrator." ::= { mteTriggerEntry 1 } mteTriggerName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the trigger within the scope of mteOwner." ::= { mteTriggerEntry 2 } mteTriggerComment OBJECT-TYPE Expires December 2003 [Page 14] Internet Draft Distributed Management Event MIB 13 June 2003 SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A description of the trigger's function and use." DEFVAL { ''H } ::= { mteTriggerEntry 3 } mteTriggerTest OBJECT-TYPE SYNTAX BITS { existence(0), boolean(1), threshold(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of trigger test to perform. For 'boolean' and 'threshold' tests, the object at mteTriggerValueID MUST evaluate to an integer, that is, anything that ends up encoded for transmission (that is, in BER, not ASN.1) as an integer. For 'existence', the specific test is as selected by mteTriggerExistenceTest. When an object appears, vanishes or changes value, the trigger fires. If the object's appearance caused the trigger firing, the object MUST vanish before the trigger can be fired again for it, and vice versa. If the trigger fired due to a change in the object's value, it will be fired again on every successive value change for that object. For 'boolean', the specific test is as selected by mteTriggerBooleanTest. If the test result is true the trigger fires. The trigger will not fire again until the value has become false and come back to true. For 'threshold' the test works as described below for mteTriggerThresholdStartup, mteTriggerThresholdRising, and mteTriggerThresholdFalling. Note that combining 'boolean' and 'threshold' tests on the same object may be somewhat redundant." DEFVAL { { boolean } } ::= { mteTriggerEntry 4 } mteTriggerSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } MAX-ACCESS read-create STATUS current Expires December 2003 [Page 15] Internet Draft Distributed Management Event MIB 13 June 2003 DESCRIPTION "The type of sampling to perform. An 'absoluteValue' sample requires only a single sample to be meaningful, and is exactly the value of the object at mteTriggerValueID at the sample time. A 'deltaValue' requires two samples to be meaningful and is thus not available for testing until the second and subsequent samples after the object at mteTriggerValueID is first found to exist. It is the difference between the two samples. For unsigned values it is always positive, based on unsigned arithmetic. For signed values it can be positive or negative. For SNMP counters to be meaningful they should be sampled as a 'deltaValue'. For 'deltaValue' mteTriggerDeltaTable contains further parameters. If only 'existence' is set in mteTriggerTest this object has no meaning." DEFVAL { absoluteValue } ::= { mteTriggerEntry 5 } mteTriggerValueID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of the MIB object to sample to see if the trigger should fire. This may be wildcarded by truncating all or part of the instance portion, in which case the value is obtained as if with a GetNext function, checking multiple values if they exist. If such wildcarding is applied, mteTriggerValueIDWildcard must be 'true' and if not it must be 'false'. Bad object identifiers or a mismatch between truncating the identifier and the value of mteTriggerValueIDWildcard result in operation as one would expect when providing the wrong identifier to a Get or GetNext operation. The Get will fail or get the wrong object. The GetNext will indeed get whatever Expires December 2003 [Page 16] Internet Draft Distributed Management Event MIB 13 June 2003 is next, proceeding until it runs past the initial part of the identifier and perhaps many unintended objects for confusing results. If the value syntax of those objects is not usable, that results in a 'badType' error that terminates the scan. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time." DEFVAL { zeroDotZero } ::= { mteTriggerEntry 6 } mteTriggerValueIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteTriggerValueID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteTriggerEntry 7 } mteTriggerTargetTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "The tag for the target(s) from which to obtain the condition for a trigger check. A length of 0 indicates the local system. In this case, access to the objects indicated by mteTriggerValueID is under the security credentials of the requester that set mteTriggerEntryStatus to 'active'. Those credentials are the input parameters for isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. Otherwise access rights are checked according to the security parameters resulting from the tag." DEFVAL { ''H } ::= { mteTriggerEntry 8 } mteTriggerContextName OBJECT-TYPE SYNTAX SnmpAdminString Expires December 2003 [Page 17] Internet Draft Distributed Management Event MIB 13 June 2003 MAX-ACCESS read-create STATUS current DESCRIPTION "The management context from which to obtain mteTriggerValueID. This may be wildcarded by leaving characters off the end. For example use 'Repeater' to wildcard to 'Repeater1', 'Repeater2', 'Repeater-999.87b', and so on. To indicate such wildcarding is intended, mteTriggerContextNameWildcard must be 'true'. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time. Operation of this feature assumes that the local system has a list of available contexts against which to apply the wildcard. If the objects are being read from the local system, this is clearly the system's own list of contexts. For a remote system a local version of such a list is not defined by any current standard and may not be available, so this function MAY not be supported." DEFVAL { ''H } ::= { mteTriggerEntry 9 } mteTriggerContextNameWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteTriggerContextName is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteTriggerEntry 10 } mteTriggerFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds to wait between trigger samples. To encourage consistency in sampling, the interval is measured Expires December 2003 [Page 18] Internet Draft Distributed Management Event MIB 13 June 2003 from the beginning of one check to the beginning of the next and the timer is restarted immediately when it expires, not when the check completes. If the next sample begins before the previous one completed the system may either attempt to make the check or treat this as an error condition with the error 'sampleOverrun'. A frequency of 0 indicates instantaneous recognition of the condition. This is not possible in many cases, but may be supported in cases where it makes sense and the system is able to do so. This feature allows the MIB to be used in implementations where such interrupt-driven behavior is possible and is not likely to be supported for all MIB objects even then since such sampling generally has to be tightly integrated into low-level code. Systems that can support this SHOULD document those cases where it can be used. In cases where it can not, setting this object to 0 should be disallowed." DEFVAL { 600 } ::= { mteTriggerEntry 11 } mteTriggerObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "To go with mteTriggerObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerEntry 12 } mteTriggerObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger. A list of objects may also be added based on the event or on the value of mteTriggerTest. Expires December 2003 [Page 19] Internet Draft Distributed Management Event MIB 13 June 2003 A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerEntry 13 } mteTriggerEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A control to allow a trigger to be configured but not used. When the value is 'false' the trigger is not sampled. Whenever the value goes from 'false' to 'true', the trigger is treated as being initialized. That is, no history is kept of any trigger sample values from previous times when this control may have been enabled. If this object is set to 'true' when its value is already 'true', the operation has no effect; that is, the trigger is not re-initialized, and there is no error." DEFVAL { false } ::= { mteTriggerEntry 14 } mteTriggerEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry may not be modified except to modify the value of mteTriggerEnabled or to delete the entry." ::= { mteTriggerEntry 15 } mteTriggerEntryStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row, except for mteTriggerEnabled. " DEFVAL { nonVolatile } Expires December 2003 [Page 20] Internet Draft Distributed Management Event MIB 13 June 2003 ::= { mteTriggerEntry 16 } -- -- Trigger Delta Table -- mteTriggerDeltaTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerDeltaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for delta sampling." ::= { mteTrigger 3 } mteTriggerDeltaEntry OBJECT-TYPE SYNTAX MteTriggerDeltaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single trigger's delta sampling. Entries automatically exist in this this table for each mteTriggerEntry that has mteTriggerSampleType set to 'deltaValue'." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerDeltaTable 1 } MteTriggerDeltaEntry ::= SEQUENCE { mteTriggerDeltaDiscontinuityID OBJECT IDENTIFIER, mteTriggerDeltaDiscontinuityIDWildcard TruthValue, mteTriggerDeltaDiscontinuityIDType INTEGER } sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } mteTriggerDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or DateAndTime object that indicates a discontinuity in the value at mteTriggerValueID. The OID may be for a leaf object (e.g. sysUpTime.0) or may be wildcarded to match mteTriggerValueID. Expires December 2003 [Page 21] Internet Draft Distributed Management Event MIB 13 June 2003 This object supports normal checking for a discontinuity in a counter. Note that if this object does not point to sysUpTime discontinuity checking MUST still check sysUpTime for an overall discontinuity. If the object identified is not accessible the sample attempt is in error, with the error code as from an SNMP request. Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the value syntax of those objects is not usable, that results in an error that terminates the sample with a 'badType' error code." DEFVAL { sysUpTimeInstance } ::= { mteTriggerDeltaEntry 1 } mteTriggerDeltaDiscontinuityIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether mteTriggerDeltaDiscontinuityID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard. Note that the value of this object will be the same as that of the corresponding instance of mteTriggerValueIDWildcard when the corresponding mteTriggerSampleType is 'deltaValue'." DEFVAL { false } ::= { mteTriggerDeltaEntry 2 } mteTriggerDeltaDiscontinuityIDType OBJECT-TYPE SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value 'timeTicks' indicates the mteTriggerDeltaDiscontinuityID of this row is of syntax TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. The value 'dateAndTime' indicates syntax DateAndTime." DEFVAL { timeTicks } ::= { mteTriggerDeltaEntry 3 } -- Expires December 2003 [Page 22] Internet Draft Distributed Management Event MIB 13 June 2003 -- Trigger Existence Table -- mteTriggerExistenceTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerExistenceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for existence triggers." ::= { mteTrigger 4 } mteTriggerExistenceEntry OBJECT-TYPE SYNTAX MteTriggerExistenceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single existence trigger. Entries automatically exist in this this table for each mteTriggerEntry that has 'existence' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerExistenceTable 1 } MteTriggerExistenceEntry ::= SEQUENCE { mteTriggerExistenceTest BITS, mteTriggerExistenceStartup BITS, mteTriggerExistenceObjectsOwner SnmpAdminString, mteTriggerExistenceObjects SnmpAdminString, mteTriggerExistenceEventOwner SnmpAdminString, mteTriggerExistenceEvent SnmpAdminString } mteTriggerExistenceTest OBJECT-TYPE SYNTAX BITS { present(0), absent(1), changed(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of existence test to perform. The trigger fires when the object at mteTriggerValueID is seen to go from present to absent, from absent to present, or to have it's value changed, depending on which tests are selected: present(0) - when this test is selected, the trigger fires when the mteTriggerValueID object goes from absent to present. Expires December 2003 [Page 23] Internet Draft Distributed Management Event MIB 13 June 2003 absent(1) - when this test is selected, the trigger fires when the mteTriggerValueID object goes from present to absent. changed(2) - when this test is selected, the trigger fires the mteTriggerValueID object value changes. Once the trigger has fired for either presence or absence it will not fire again for that state until the object has been to the other state. " DEFVAL { { present, absent } } ::= { mteTriggerExistenceEntry 1 } mteTriggerExistenceStartup OBJECT-TYPE SYNTAX BITS { present(0), absent(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether an event may be triggered when this entry is first set to 'active' and the test specified by mteTriggerExistenceTest is true. Setting an option causes that trigger to fire when its test is true." DEFVAL { { present, absent } } ::= { mteTriggerExistenceEntry 2 } mteTriggerExistenceObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerExistenceObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 3 } mteTriggerExistenceObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. Expires December 2003 [Page 24] Internet Draft Distributed Management Event MIB 13 June 2003 A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 4 } mteTriggerExistenceEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerExistenceEvent, the mteOwner of an event entry from the mteEventTable." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 5 } mteTriggerExistenceEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'existence' and this trigger fires. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 6 } -- -- Trigger Boolean Table -- mteTriggerBooleanTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerBooleanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for boolean triggers." ::= { mteTrigger 5 } mteTriggerBooleanEntry OBJECT-TYPE SYNTAX MteTriggerBooleanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single boolean trigger. Entries automatically exist in this this table for each mteTriggerEntry Expires December 2003 [Page 25] Internet Draft Distributed Management Event MIB 13 June 2003 that has 'boolean' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerBooleanTable 1 } MteTriggerBooleanEntry ::= SEQUENCE { mteTriggerBooleanComparison INTEGER, mteTriggerBooleanValue Integer32, mteTriggerBooleanStartup TruthValue, mteTriggerBooleanObjectsOwner SnmpAdminString, mteTriggerBooleanObjects SnmpAdminString, mteTriggerBooleanEventOwner SnmpAdminString, mteTriggerBooleanEvent SnmpAdminString } mteTriggerBooleanComparison OBJECT-TYPE SYNTAX INTEGER { unequal(1), equal(2), less(3), lessOrEqual(4), greater(5), greaterOrEqual(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of boolean comparison to perform. The value at mteTriggerValueID is compared to mteTriggerBooleanValue, so for example if mteTriggerBooleanComparison is 'less' the result would be true if the value at mteTriggerValueID is less than the value of mteTriggerBooleanValue." DEFVAL { unequal } ::= { mteTriggerBooleanEntry 1 } mteTriggerBooleanValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value to use for the test specified by mteTriggerBooleanTest." DEFVAL { 0 } ::= { mteTriggerBooleanEntry 2 } mteTriggerBooleanStartup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current Expires December 2003 [Page 26] Internet Draft Distributed Management Event MIB 13 June 2003 DESCRIPTION "Control for whether an event may be triggered when this entry is first set to 'active' or a new instance of the object at mteTriggerValueID is found and the test specified by mteTriggerBooleanComparison is true. In that case an event is triggered if mteTriggerBooleanStartup is 'true'." DEFVAL { true } ::= { mteTriggerBooleanEntry 3 } mteTriggerBooleanObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerBooleanObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 4 } mteTriggerBooleanObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 5 } mteTriggerBooleanEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerBooleanEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 6 } Expires December 2003 [Page 27] Internet Draft Distributed Management Event MIB 13 June 2003 mteTriggerBooleanEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'boolean' and this trigger fires. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 7 } -- -- Trigger Threshold Table -- mteTriggerThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for threshold triggers." ::= { mteTrigger 6 } mteTriggerThresholdEntry OBJECT-TYPE SYNTAX MteTriggerThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single threshold trigger. Entries automatically exist in this table for each mteTriggerEntry that has 'threshold' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerThresholdTable 1 } MteTriggerThresholdEntry ::= SEQUENCE { mteTriggerThresholdStartup INTEGER, mteTriggerThresholdRising Integer32, mteTriggerThresholdFalling Integer32, mteTriggerThresholdDeltaRising Integer32, mteTriggerThresholdDeltaFalling Integer32, mteTriggerThresholdObjectsOwner SnmpAdminString, mteTriggerThresholdObjects SnmpAdminString, mteTriggerThresholdRisingEventOwner SnmpAdminString, mteTriggerThresholdRisingEvent SnmpAdminString, Expires December 2003 [Page 28] Internet Draft Distributed Management Event MIB 13 June 2003 mteTriggerThresholdFallingEventOwner SnmpAdminString, mteTriggerThresholdFallingEvent SnmpAdminString, mteTriggerThresholdDeltaRisingEventOwner SnmpAdminString, mteTriggerThresholdDeltaRisingEvent SnmpAdminString, mteTriggerThresholdDeltaFallingEventOwner SnmpAdminString, mteTriggerThresholdDeltaFallingEvent SnmpAdminString } mteTriggerThresholdStartup OBJECT-TYPE SYNTAX INTEGER { rising(1), falling(2), risingOrFalling(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The event that may be triggered when this entry is first set to 'active' and a new instance of the object at mteTriggerValueID is found. If the first sample after this instance becomes active is greater than or equal to mteTriggerThresholdRising and mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling', then one mteTriggerThresholdRisingEvent is triggered for that instance. If the first sample after this entry becomes active is less than or equal to mteTriggerThresholdFalling and mteTriggerThresholdStartup is equal to 'falling' or 'risingOrFalling', then one mteTriggerThresholdRisingEvent is triggered for that instance." DEFVAL { risingOrFalling } ::= { mteTriggerThresholdEntry 1 } mteTriggerThresholdRising OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, one mteTriggerThresholdRisingEvent is triggered. That event is also triggered if the first sample after this entry becomes active is greater than or equal to this threshold and mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling'. Expires December 2003 [Page 29] Internet Draft Distributed Management Event MIB 13 June 2003 After a rising event is generated, another such event is not triggered until the sampled value falls below this threshold and reaches mteTriggerThresholdFalling." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 2 } mteTriggerThresholdFalling OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, one mteTriggerThresholdFallingEvent is triggered. That event is also triggered if the first sample after this entry becomes active is less than or equal to this threshold and mteTriggerThresholdStartup is equal to 'falling' or 'risingOrFalling'. After a falling event is generated, another such event is not triggered until the sampled value rises above this threshold and reaches mteTriggerThresholdRising." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 3 } mteTriggerThresholdDeltaRising OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the delta value (difference) between the current sampled value (value(n)) and the previous sampled value (value(n-1)) is greater than or equal to this threshold, and the delta value calculated at the last sampling interval (i.e. value(n-1) - value(n-2)) was less than this threshold, one mteTriggerThresholdDeltaRisingEvent is triggered. That event is also triggered if the first delta value calculated after this entry becomes active, i.e. value(2) - value(1), where value(1) Expires December 2003 [Page 30] Internet Draft Distributed Management Event MIB 13 June 2003 is the first sample taken of that instance, is greater than or equal to this threshold. After a rising event is generated, another such event is not triggered until the delta value falls below this threshold and reaches mteTriggerThresholdDeltaFalling." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 4 } mteTriggerThresholdDeltaFalling OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the delta value (difference) between the current sampled value (value(n)) and the previous sampled value (value(n-1)) is less than or equal to this threshold, and the delta value calculated at the last sampling interval (i.e. value(n-1) - value(n-2)) was greater than this threshold, one mteTriggerThresholdDeltaFallingEvent is triggered. That event is also triggered if the first delta value calculated after this entry becomes active, i.e. value(2) - value(1), where value(1) is the first sample taken of that instance, is less than or equal to this threshold. After a falling event is generated, another such event is not triggered until the delta value falls below this threshold and reaches mteTriggerThresholdDeltaRising." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 5 } mteTriggerThresholdObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 6 } mteTriggerThresholdObjects OBJECT-TYPE Expires December 2003 [Page 31] Internet Draft Distributed Management Event MIB 13 June 2003 SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 7 } mteTriggerThresholdRisingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdRisingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 8 } mteTriggerThresholdRisingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdRising. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 9 } mteTriggerThresholdFallingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdFallingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } Expires December 2003 [Page 32] Internet Draft Distributed Management Event MIB 13 June 2003 ::= { mteTriggerThresholdEntry 10 } mteTriggerThresholdFallingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdFalling. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 11 } mteTriggerThresholdDeltaRisingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdDeltaRisingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 12 } mteTriggerThresholdDeltaRisingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdDeltaRising. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 13 } mteTriggerThresholdDeltaFallingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdDeltaFallingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 14 } Expires December 2003 [Page 33] Internet Draft Distributed Management Event MIB 13 June 2003 mteTriggerThresholdDeltaFallingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdDeltaFalling. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 15 } -- -- Objects Table -- mteObjectsTable OBJECT-TYPE SYNTAX SEQUENCE OF MteObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that can be added to notifications based on the trigger, trigger test, or event, as pointed to by entries in those tables." ::= { mteObjects 1 } mteObjectsEntry OBJECT-TYPE SYNTAX MteObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A group of objects. Applications create and delete entries using mteObjectsEntryStatus. When adding objects to a notification they are added in the lexical order of their index in this table. Those associated with a trigger come first, then trigger test, then event." INDEX { mteOwner, mteObjectsName, mteObjectsIndex } ::= { mteObjectsTable 1 } MteObjectsEntry ::= SEQUENCE { mteObjectsName SnmpAdminString, mteObjectsIndex Unsigned32, mteObjectsID OBJECT IDENTIFIER, mteObjectsIDWildcard TruthValue, Expires December 2003 [Page 34] Internet Draft Distributed Management Event MIB 13 June 2003 mteObjectsEntryStatus RowStatus, mteObjectsEntryStorageType Storagetype } mteObjectsName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for a group of objects." ::= { mteObjectsEntry 1 } mteObjectsIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer for the purpose of identifying individual objects within a mteObjectsName group. Objects within a group are placed in the notification in the numerical order of this index. Groups are placed in the notification in the order of the selections for overall trigger, trigger test, and event. Within trigger test they are in the same order as the numerical values of the bits defined for mteTriggerTest. Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the object is not available it is omitted from the notification." ::= { mteObjectsEntry 2 } mteObjectsID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of a MIB object to add to a Notification that results from the firing of a trigger. Expires December 2003 [Page 35] Internet Draft Distributed Management Event MIB 13 June 2003 This may be wildcarded by truncating all or part of the instance portion, in which case the instance portion of the OID for obtaining this object will be the same as that used in obtaining the mteTriggerValueID that fired. If such wildcarding is applied, mteObjectsIDWildcard must be 'true' and if not it must be 'false'. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time." DEFVAL { zeroDotZero } ::= { mteObjectsEntry 3 } mteObjectsIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteObjectsID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteObjectsEntry 4 } mteObjectsEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry MAY not be modified except to delete it." ::= { mteObjectsEntry 5 } mteObjectsEntryStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { mteObectsEntry 6 } Expires December 2003 [Page 36] Internet Draft Distributed Management Event MIB 13 June 2003 -- -- Event Section -- -- Counters mteEventFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an attempt to invoke an event has failed. This counts individually for each attempt in a group of targets or each attempt for a wildcarded trigger object." ::= { mteEvent 1 } -- -- Event Table -- mteEventTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event action information." ::= { mteEvent 2 } mteEventEntry OBJECT-TYPE SYNTAX MteEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event. Applications create and delete entries using mteEventEntryStatus." INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventTable 1 } MteEventEntry ::= SEQUENCE { mteEventName SnmpAdminString, mteEventComment SnmpAdminString, mteEventActions BITS, mteEventEnabled TruthValue, mteEventEntryStatus RowStatus, Expires December 2003 [Page 37] Internet Draft Distributed Management Event MIB 13 June 2003 mteEventEntryStorageType StorageType } mteEventName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the event." ::= { mteEventEntry 1 } mteEventComment OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A description of the event's function and use." DEFVAL { ''H } ::= { mteEventEntry 2 } mteEventActions OBJECT-TYPE SYNTAX BITS { notification(0), set(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "The actions to perform when this event occurs. For 'notification', Traps and/or Informs are sent according to the configuration in the SNMP Notification MIB. For 'set', an SNMP Set operation is performed according to control values in this entry." DEFVAL { {} } -- No bits set. ::= { mteEventEntry 3 } mteEventEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A control to allow an event to be configured but not used. When the value is 'false' the event does not execute even if triggered." DEFVAL { false } Expires December 2003 [Page 38] Internet Draft Distributed Management Event MIB 13 June 2003 ::= { mteEventEntry 4 } mteEventEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry MAY not be modified except to modify the value of mteEventEnabled or to delete the entry." ::= { mteEventEntry 5 } mteEventEntryStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { mteEventEntry 6 } -- -- Event Notification Table -- mteEventNotificationTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information about notifications to be sent as a consequence of management events." ::= { mteEvent 3 } mteEventNotificationEntry OBJECT-TYPE SYNTAX MteEventNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event's notification. Entries automatically exist in this this table for each mteEventEntry that has 'notification' set in mteEventActions." Expires December 2003 [Page 39] Internet Draft Distributed Management Event MIB 13 June 2003 INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventNotificationTable 1 } MteEventNotificationEntry ::= SEQUENCE { mteEventNotification OBJECT IDENTIFIER, mteEventNotificationObjectsOwner SnmpAdminString, mteEventNotificationObjects SnmpAdminString } mteEventNotification OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The object identifier from the NOTIFICATION-TYPE for the notification to use if mteEventActions has 'notification' set." DEFVAL { zeroDotZero } ::= { mteEventNotificationEntry 1 } mteEventNotificationObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteEventNotificationObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteEventNotificationEntry 2 } mteEventNotificationObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable if mteEventActions has 'notification' set. These objects are to be added to any Notification generated by this event. Objects may also be added based on the trigger that stimulated the event. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteEventNotificationEntry 3 } Expires December 2003 [Page 40] Internet Draft Distributed Management Event MIB 13 June 2003 -- -- Event Set Table -- mteEventSetTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event action information." ::= { mteEvent 4 } mteEventSetEntry OBJECT-TYPE SYNTAX MteEventSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event's set option. Entries automatically exist in this this table for each mteEventEntry that has 'set' set in mteEventActions." INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventSetTable 1 } MteEventSetEntry ::= SEQUENCE { mteEventSetObject OBJECT IDENTIFIER, mteEventSetObjectWildcard TruthValue, mteEventSetValue Integer32, mteEventSetTargetTag SnmpTagValue, mteEventSetContextName SnmpAdminString, mteEventSetContextNameWildcard TruthValue } mteEventSetObject OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The object identifier from the MIB object to set if mteEventActions has 'set' set. This object identifier may be wildcarded by leaving sub-identifiers off the end, in which case nteEventSetObjectWildCard must be 'true'. If mteEventSetObject is wildcarded the instance used to set the Expires December 2003 [Page 41] Internet Draft Distributed Management Event MIB 13 June 2003 object to which it points is the same as the instance from the value of mteTriggerValueID that triggered the event. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time. Bad object identifiers or a mismatch between truncating the identifier and the value of mteSetObjectWildcard result in operation as one would expect when providing the wrong identifier to a Set operation. The Set will fail or set the wrong object. If the value syntax of the destination object is not correct, the Set fails with the normal SNMP error code." DEFVAL { zeroDotZero } ::= { mteEventSetEntry 1 } mteEventSetObjectWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control over whether mteEventSetObject is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard if mteEventActions has 'set' set." DEFVAL { false } ::= { mteEventSetEntry 2 } mteEventSetValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value to which to set the object at mteEventSetObject if mteEventActions has 'set' set." DEFVAL { 0 } ::= { mteEventSetEntry 3 } mteEventSetTargetTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-write STATUS current DESCRIPTION Expires December 2003 [Page 42] Internet Draft Distributed Management Event MIB 13 June 2003 "The tag for the target(s) at which to set the object at mteEventSetObject to mteEventSetValue if mteEventActions has 'set' set. Systems limited to self management MAY reject a non-zero length for the value of this object. A length of 0 indicates the local system. In this case, access to the objects indicated by mteEventSetObject is under the security credentials of the requester that set mteTriggerEntryStatus to 'active'. Those credentials are the input parameters for isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. Otherwise access rights are checked according to the security parameters resulting from the tag." DEFVAL { ''H } ::= { mteEventSetEntry 4 } mteEventSetContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "The management context in which to set mteEventObjectID. if mteEventActions has 'set' set. This may be wildcarded by leaving characters off the end. To indicate such wildcarding mteEventSetContextNameWildcard must be 'true'. If this context name is wildcarded the value used to complete the wildcarding of mteTriggerContextName will be appended." DEFVAL { ''H } ::= { mteEventSetEntry 5 } mteEventSetContextNameWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether mteEventSetContextName is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard if mteEventActions has 'set' set." DEFVAL { false } Expires December 2003 [Page 43] Internet Draft Distributed Management Event MIB 13 June 2003 ::= { mteEventSetEntry 6 } -- -- Notifications -- dismanEventMIBNotificationPrefix OBJECT IDENTIFIER ::= { dismanEventMIB 2 } dismanEventMIBNotifications OBJECT IDENTIFIER ::= { dismanEventMIBNotificationPrefix 0 } dismanEventMIBNotificationObjects OBJECT IDENTIFIER ::= { dismanEventMIBNotificationPrefix 1 } -- -- Notification Objects -- mteHotTrigger OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The name of the trigger causing the notification." ::= { dismanEventMIBNotificationObjects 1 } mteHotTargetName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The SNMP Target MIB's snmpTargetAddrName related to the notification." ::= { dismanEventMIBNotificationObjects 2 } mteHotContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The context name related to the notification. This MUST be as fully-qualified as possible, including filling in wildcard information determined in processing." ::= { dismanEventMIBNotificationObjects 3 } mteHotOID OBJECT-TYPE Expires December 2003 [Page 44] Internet Draft Distributed Management Event MIB 13 June 2003 SYNTAX OBJECT IDENTIFIER MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The object identifier of the destination object related to the notification. This MUST be as fully-qualified as possible, including filling in wildcard information determined in processing. For a trigger-related notification this is from mteTriggerValueID. For a set failure this is from mteEventSetObject." ::= { dismanEventMIBNotificationObjects 4 } mteHotValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the object at mteTriggerValueID when a trigger fired." ::= { dismanEventMIBNotificationObjects 5 } mteFailedReason OBJECT-TYPE SYNTAX FailureReason MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The reason for the failure of an attempt to check for a trigger condition or set an object in response to an event." ::= { dismanEventMIBNotificationObjects 6 } -- -- Notifications -- mteTriggerFired NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION Expires December 2003 [Page 45] Internet Draft Distributed Management Event MIB 13 June 2003 "Notification that the trigger indicated by the object instances has fired, for triggers with mteTriggerType 'boolean' or 'existence'." ::= { dismanEventMIBNotifications 1 } mteTriggerRising NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the rising threshold was met for triggers with mteTriggerType 'threshold'." ::= { dismanEventMIBNotifications 2 } mteTriggerFalling NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the falling threshold was met for triggers with mteTriggerType 'threshold'." ::= { dismanEventMIBNotifications 3 } mteTriggerFailure NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteFailedReason } STATUS current DESCRIPTION "Notification that an attempt to check a trigger has failed. The network manager must enable this notification only with a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { dismanEventMIBNotifications 4 } Expires December 2003 [Page 46] Internet Draft Distributed Management Event MIB 13 June 2003 mteEventSetFailure NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteFailedReason } STATUS current DESCRIPTION "Notification that an attempt to do a set in response to an event has failed. The network manager must enable this notification only with a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { dismanEventMIBNotifications 5 } -- -- Conformance -- dismanEventMIBConformance OBJECT IDENTIFIER ::= { dismanEventMIB 3 } dismanEventMIBCompliances OBJECT IDENTIFIER ::= { dismanEventMIBConformance 1 } dismanEventMIBGroups OBJECT IDENTIFIER ::= { dismanEventMIBConformance 2 } -- Compliance dismanEventMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Event MIB." MODULE -- this module MANDATORY-GROUPS { dismanEventResourceGroup, dismanEventTriggerGroup, dismanEventObjectsGroup, dismanEventEventGroup, dismanEventNotificationObjectGroup, dismanEventNotificationGroup } Expires December 2003 [Page 47] Internet Draft Distributed Management Event MIB 13 June 2003 OBJECT mteTriggerTargetTag MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus limiting monitoring to the local system or pre-configured remote systems." OBJECT mteEventSetTargetTag MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus limiting setting to the local system or pre-configured remote systems." OBJECT mteTriggerValueIDWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteTriggerContextNameWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteObjectsIDWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteEventSetContextNameWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." ::= { dismanEventMIBCompliances 1 } -- Units of Conformance dismanEventResourceGroup OBJECT-GROUP OBJECTS { Expires December 2003 [Page 48] Internet Draft Distributed Management Event MIB 13 June 2003 mteResourceSampleMinimum, mteResourceSampleInstanceMaximum, mteResourceSampleInstances, mteResourceSampleInstancesHigh, mteResourceSampleInstanceLacks } STATUS current DESCRIPTION "Event resource status and control objects." ::= { dismanEventMIBGroups 1 } dismanEventTriggerGroup OBJECT-GROUP OBJECTS { mteTriggerFailures, mteTriggerComment, mteTriggerTest, mteTriggerSampleType, mteTriggerValueID, mteTriggerValueIDWildcard, mteTriggerTargetTag, mteTriggerContextName, mteTriggerContextNameWildcard, mteTriggerFrequency, mteTriggerObjectsOwner, mteTriggerObjects, mteTriggerEnabled, mteTriggerEntryStatus, mteTriggerDeltaDiscontinuityID, mteTriggerDeltaDiscontinuityIDWildcard, mteTriggerDeltaDiscontinuityIDType, mteTriggerExistenceTest, mteTriggerExistenceStartup, mteTriggerExistenceObjectsOwner, mteTriggerExistenceObjects, mteTriggerExistenceEventOwner, mteTriggerExistenceEvent, mteTriggerBooleanComparison, mteTriggerBooleanValue, mteTriggerBooleanStartup, mteTriggerBooleanObjectsOwner, mteTriggerBooleanObjects, mteTriggerBooleanEventOwner, Expires December 2003 [Page 49] Internet Draft Distributed Management Event MIB 13 June 2003 mteTriggerBooleanEvent, mteTriggerThresholdStartup, mteTriggerThresholdObjectsOwner, mteTriggerThresholdObjects, mteTriggerThresholdRising, mteTriggerThresholdFalling, mteTriggerThresholdDeltaRising, mteTriggerThresholdDeltaFalling, mteTriggerThresholdRisingEventOwner, mteTriggerThresholdRisingEvent, mteTriggerThresholdFallingEventOwner, mteTriggerThresholdFallingEvent, mteTriggerThresholdDeltaRisingEventOwner, mteTriggerThresholdDeltaRisingEvent, mteTriggerThresholdDeltaFallingEventOwner, mteTriggerThresholdDeltaFallingEvent } STATUS current DESCRIPTION "Event triggers." ::= { dismanEventMIBGroups 2 } dismanEventObjectsGroup OBJECT-GROUP OBJECTS { mteObjectsID, mteObjectsIDWildcard, mteObjectsEntryStatus } STATUS current DESCRIPTION "Supplemental objects." ::= { dismanEventMIBGroups 3 } dismanEventEventGroup OBJECT-GROUP OBJECTS { mteEventFailures, mteEventComment, mteEventActions, mteEventEnabled, mteEventEntryStatus, mteEventNotification, mteEventNotificationObjectsOwner, Expires December 2003 [Page 50] Internet Draft Distributed Management Event MIB 13 June 2003 mteEventNotificationObjects, mteEventSetObject, mteEventSetObjectWildcard, mteEventSetValue, mteEventSetTargetTag, mteEventSetContextName, mteEventSetContextNameWildcard } STATUS current DESCRIPTION "Events." ::= { dismanEventMIBGroups 4 } dismanEventNotificationObjectGroup OBJECT-GROUP OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue, mteFailedReason } STATUS current DESCRIPTION "Notification objects." ::= { dismanEventMIBGroups 5 } dismanEventNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { mteTriggerFired, mteTriggerRising, mteTriggerFalling, mteTriggerFailure, mteEventSetFailure } STATUS current DESCRIPTION "Notifications." ::= { dismanEventMIBGroups 6 } END Expires December 2003 [Page 51] Internet Draft Distributed Management Event MIB 13 June 2003 8. 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. 9. Acknowledgements This MIB contains considerable contributions from the RMON MIB, the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), the Distributed Management Working Group, and colleagues at Cisco. 10. 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] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. Expires December 2003 [Page 52] Internet Draft Distributed Management Event MIB 13 June 2003 [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 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. Expires December 2003 [Page 53] Internet Draft Distributed Management Event MIB 13 June 2003 [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. [RFC2981] Stewart, B., "Event MIB", RFC 2981, October 2000. [RFC1757] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, February 1995. [RFC1451] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Manager-to- Manager Management Information Base", RFC 1451, April 1993. [RFC2982] Stewart, B., "Distributed Management Expression MIB", RFC 2982, October 2000. [LOG-MIB] Stewart, B., "Notification Log MIB", Work in Progress. 11. Security Considerations Security issues are discussed in the Security section and in the DESCRIPTION clauses of relevant objects. 12. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. 13. Editor's Address Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Expires December 2003 [Page 54] Internet Draft Distributed Management Event MIB 13 June 2003 Phone: +1 408 527 2446 EMail: ramk@cisco.com Expires December 2003 [Page 55] Internet Draft Distributed Management Event MIB 13 June 2003 14. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 December 2003 [Page 56] From mailnull@www1.ietf.org Sat Jun 14 03:28:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20993 for ; Sat, 14 Jun 2003 03:28:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5E7Ret11986 for disman-archive@odin.ietf.org; Sat, 14 Jun 2003 03:27:40 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5E7Rem11982 for ; Sat, 14 Jun 2003 03:27:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20979 for ; Sat, 14 Jun 2003 03:27:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R5Pk-0005ET-00 for disman-web-archive@ietf.org; Sat, 14 Jun 2003 03:25:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19R5Pj-0005EQ-00 for disman-web-archive@ietf.org; Sat, 14 Jun 2003 03:25:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMJ1a27590; Fri, 13 Jun 2003 18:19:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DMI7m27502 for ; Fri, 13 Jun 2003 18:18:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26115; Fri, 13 Jun 2003 18:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qwox-0001kc-00; Fri, 13 Jun 2003 18:14:55 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19Qwov-0001kW-00; Fri, 13 Jun 2003 18:14:53 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5DMGUI2022246; Fri, 13 Jun 2003 15:16:31 -0700 (PDT) Received: from cisco.com (dhcp-128-107-166-145.cisco.com [128.107.166.145]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIC73001; Fri, 13 Jun 2003 15:11:10 -0700 (PDT) Message-ID: <3EEA4D38.6060606@cisco.com> From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts@ietf.org CC: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Disman] Please accept draft-ietf-disman-event-mib-03.txt for posting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Jun 2003 15:16:24 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please accept draft-ietf-disman-event-mib-v2-03.txt for posting as an internet draft. Thank you, Ram Kavasseri Disman Working Group R. Kavasseri Internet Draft Cisco Systems, Inc. Document: draft-ietf-disman-event-mib-v2-03.txt B. Stewart Expiration Date: December 2003 Retired June 2003 Event MIB 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 (2003). All Rights Reserved. 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 that can be used to manage and monitor MIB objects and take action through events. Internet Draft Distributed Management Event MIB 13 June 2003 The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. 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. Table of Contents 1 The SNMP Management Framework ............................... 2 2 Overview .................................................... 3 3 Relationship to Other MIBs .................................. 3 4 MIB Sections ................................................ 4 5 Operation ................................................... 5 6 Security .................................................... 7 7 Definitions ................................................. 7 8 Intellectual Property ....................................... 47 9 Acknowledgements ............................................ 47 10 References ................................................. 47 11 Security Considerations .................................... 49 12 Author's Address ........................................... 49 13 Editor's Address ........................................... 49 14 Full Copyright Statement ................................... 50 1. 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], STD 58, RFC 2579 [RFC2579] and STD 58, 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 Expires December 2003 [Page 2] Internet Draft Distributed Management Event MIB 13 June 2003 [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]. 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. Expires December 2003 [Page 3] Internet Draft Distributed Management Event MIB 13 June 2003 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. It may not be possible to meaningfully monitor Counter64 objects using an SMIv1 version of the MIB. 2. Overview With network sizes well beyond the ability of people to manage them directly, automated, distributed management is vital. An important aspect of such management is the ability of a system to monitor itself or for some other system to monitor it. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met. The MIB is intended to suit either a relatively powerful manager or mid- level manager, as well as a somewhat more limited self-managing system. 3. Relationship to Other MIBs The Event MIB is based on extensive experience with the RMON MIB [RFC1757] and provides a superset of the capabilities of the RMON alarm and event groups. Conceptually, the key extension is the ability to allow alarms to be generated for MIB objects that are on another network element. The Event MIB calls "triggers" what the RMON MIB called "alarms," but the concepts are the same. Event MIB triggers maintain the RMON handling of thresholds and add the concept of booleans. Event MIB events maintain the RMON concept of sending an SNMP notification in response to a trigger and add the concept of setting a MIB object. The Event MIB is the successor and update to SNMPv2's Manager-to- Manager MIB [RFC1451] which was declared Historic pending this work. The Event MIB depends on the services of the SNMPv3 Management Target and Notification MIBs [RFC2573]. Expires December 2003 [Page 4] Internet Draft Distributed Management Event MIB 13 June 2003 The Event MIB is nicely complemented by the Distributed Management Expression MIB [RFC2982], which is the expected source of boolean objects to monitor. Note that there is considerable overlap between the wildcard and delta sample capabilities of the Event and Expression MIBs. A carefully-planned implementation might well use common code to provide the overlapping functions. 4. MIB Sections The MIB has four sections: triggers, objects, events, and notifications. Triggers define the conditions that lead to events. Events may cause notifications. The trigger table lists what objects are to be monitored and how and relates each trigger to an event. It has supplementary, companion tables for additional objects that depend on the type of test done for the trigger. The objects table lists objects that can be added to notifications based on the trigger, the trigger test type, or the event that resulted in the notification. The event table defines what happens when an event is triggered: sending a notification, setting a MIB object or both. It has supplementary, companion tables for additional objects that depend on the action taken. The notification section defines a set of generic notifications to go with the events and for Event MIB error handling, and it defines a set of objects to put in those notifications. The following diagram describes the relationships between the tables in the Event MIB. Expires December 2003 [Page 5] Internet Draft Distributed Management Event MIB 13 June 2003 +-----------------------------+ | mteTriggerEntry | subclassed by: | { mteOwner, |---+ | IMPLIED mteTriggerName } | +-- mteTriggerDeltaEntry | | | | | +-- mteTriggerExistenceEntry | | | | | +-- mteTriggerBooleanEntry | | | | | +-- mteTriggerThresholdEntry | | | mteTrigger*Event -------------------------------->+ | | | | mteTriggerObjects ------------------>+ | +-----------------------------+ | | | | +-----------------------------+ V | | mteObjectsEntry | | | | { mteOwner, |<-------------+ | | mteObjectsName, | | | mteObjectsIndex } | | +-----------------------------+ | V +---------------------------+ | | mteEventEntry |<----------------------------+ | { mteOwner, | | IMPLIED mteEventName } | | | | mteEventAction---> + (condition) +---------------------------+ | V +---------------------------+ | +--------------------------+ | mteEventNotificationEntry | | | mteEventSetEntry | | { mteOwner, |<--+-->| { mteOwner, | | IMPLIED mteEventName } | | IMPLIED mteEventName } | +---------------------------+ +---------------------------+ 5. Operation The Event MIB is instrumentation for a distributed management application that monitors MIB objects. In its simplest form this application monitors individual, local MIB objects, just as an RMON probe fulfills the functions implied by RMON's alarm and event operation. Additionally the application can monitor remote objects and wildcarded groups of objects. Expires December 2003 [Page 6] Internet Draft Distributed Management Event MIB 13 June 2003 Remote monitoring uses the tag service of the Management Target MIB [RFC2573] to select and access remote systems as an ordinary SNMP- based management application. Local monitoring may be via a more intimate, local interface which may, for example, bypass SNMP encoding but otherwise is functionally identical to remote SNMP operation, including the application of access control. A self- management only system MAY not implement remote monitoring. Wildcards indicate that the application SHOULD use a GetNext-type operation to find the zero or more instances implied by a truncated object identifier, just like an ordinary SNMP-based management application. Each instance of a wildcard is treated as if it were a separate entry, that is the instances of a wildcarded object are independent of one another. For example, a wild-carded object may trigger an event, and result in the setting of another wildcarded object. The instance that satisfied the trigger function is used to perform the set function. All of this takes place independently of any additional instances that may fill the wildcard. Error handling is by notification. These error notifications SHOULD be enabled only for the diagnosis of problems indicated by error counters. If minimizing the probability of notification loss is a concern they SHOULD be transmitted as Inform PDUs as described in the [SNMP-TARGET-MIB] or directed to a log as described in the Notification Log MIB [rfcNotificationLogMIB]. Note that this does not mean the Notification Log MIB is REQUIRED, since in fact notifications usually are not lost, but that the Notification Log MIB can be helpful with this as well as other MIBs that include notifications. Although like most MIBs this one has no explicit controls for the persistence of the values set in configuring events, a robust, polite implementation would certainly not force its managing applications to reconfigure it whenever it resets. Again, as with most MIBs, it is implementation-specific how a system provides and manages such persistence. To speculate, one could imagine, for example, that persistence depended on the context in which the expression was configured, or perhaps system-specific characteristics of the expression's owner. Or perhaps everything in a MIB such as this one, which is clearly aimed at persistent configuration, is automatically part of a system's other persistent configuration. Expires December 2003 [Page 7] Internet Draft Distributed Management Event MIB 13 June 2003 6. Security Security of Event MIB entries depends on SNMPv3 access control for the entire MIB or for subsets based on entry owner names. Security of monitored objects for remote access depends on the Management Target MIB [RFC2573]. Security for local access can depend on the Management Target MIB or on recording appropriate security credentials of the creator of an entry and using those to access the local objects. These security credentials are the parameters necessary as inputs to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. When accessing local objects without using a local target tag, the system MUST (conceptually) use isAccessAllowed to ensure that it does not violate security. To facilitate the provisioning of access control by a security administrator for this MIB itself using the View-Based Access Control Model (VACM) defined in RFC 2275 [RFC2575] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. If a security administrator were to employ such an approach, all entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same sub-identifiers (except for the "column" sub-identifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column sub-identifier. More elaborate configurations are possible. 7. Definitions DISMAN-EVENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, NOTIFICATION-TYPE, Counter32, Expires December 2003 [Page 8] Internet Draft Distributed Management Event MIB 13 June 2003 Gauge32, mib-2, zeroDotZero FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF sysUpTime FROM SNMPv2-MIB SnmpTagValue FROM SNMP-TARGET-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; dismanEventMIB MODULE-IDENTITY LAST-UPDATED "200306130000Z" -- 13 June 2003 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 526 4527 Email: ramk@cisco.com" DESCRIPTION "The MIB module for defining event triggers and actions for network management purposes. Copyright (C) The Internet Society 2003. This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this note -- Revision History REVISION "200306130000Z" -- 13 June 2003 DESCRIPTION "Added copyright statement to the MIB module description." REVISION "200111140000Z" -- 14 November 2001 DESCRIPTION "Updated the DESCRIPTION clauses of mteEventEntryStatus, mteTriggerEnabled and mteTriggerEntryStatus." REVISION "200010160000Z" -- 16 October 2000 DESCRIPTION "This is the initial version of this MIB. Published as RFC 2981" ::= { mib-2 88 } dismanEventMIBObjects OBJECT IDENTIFIER ::= { dismanEventMIB 1 } -- Management Triggered Event (MTE) objects mteResource OBJECT IDENTIFIER ::= { dismanEventMIBObjects 1 } Expires December 2003 [Page 9] Internet Draft Distributed Management Event MIB 13 June 2003 mteTrigger OBJECT IDENTIFIER ::= { dismanEventMIBObjects 2 } mteObjects OBJECT IDENTIFIER ::= { dismanEventMIBObjects 3 } mteEvent OBJECT IDENTIFIER ::= { dismanEventMIBObjects 4 } -- -- Textual Conventions -- FailureReason ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Reasons for failures in an attempt to perform a management request. The first group of errors, numbered less than 0, are related to problems in sending the request. The existence of a particular error code here does not imply that all implementations are capable of sensing that error and returning that code. The second group, numbered greater than 0, are copied directly from SNMP protocol operations and are intended to carry exactly the meanings defined for the protocol as returned in an SNMP response. localResourceLack some local resource such as memory lacking or mteResourceSampleInstanceMaximum exceeded badDestination unrecognized domain name or otherwise invalid destination address destinationUnreachable can't get to destination address noResponse no response to SNMP request badType the data syntax of a retrieved object as not as expected sampleOverrun another sample attempt occurred before the previous one completed" SYNTAX INTEGER { localResourceLack(-1), badDestination(-2), destinationUnreachable(-3), noResponse(-4), badType(-5), sampleOverrun(-6), Expires December 2003 [Page 10] Internet Draft Distributed Management Event MIB 13 June 2003 noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4), genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18) } -- -- Resource Control Section -- mteResourceSampleMinimum OBJECT-TYPE SYNTAX Integer32 (1..2147483647) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The minimum mteTriggerFrequency this system will accept. A system may use the larger values of this minimum to lessen the impact of constant sampling. For larger sampling intervals the system samples less often and suffers less overhead. This object provides a way to enforce such lower overhead for all triggers created after it is set. Unless explicitly resource limited, a system's value for this object SHOULD be 1, allowing as small as a 1 second interval for ongoing trigger sampling. Changing this value will not invalidate an existing setting of mteTriggerFrequency." ::= { mteResource 1 } Expires December 2003 [Page 11] Internet Draft Distributed Management Event MIB 13 June 2003 mteResourceSampleInstanceMaximum OBJECT-TYPE SYNTAX Unsigned32 UNITS "instances" MAX-ACCESS read-write STATUS current DESCRIPTION "The maximum number of instance entries this system will support for sampling. These are the entries that maintain state, one for each instance of each sampled object as selected by mteTriggerValueID. Note that wildcarded objects result in multiple instances of this state. A value of 0 indicates no preset limit, that is, the limit is dynamic based on system operation and resources. Unless explicitly resource limited, a system's value for this object SHOULD be 0. Changing this value will not eliminate or inhibit existing sample state but could prevent allocation of additional state information." ::= { mteResource 2 } mteResourceSampleInstances OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active instance entries as defined for mteResourceSampleInstanceMaximum." ::= { mteResource 3 } mteResourceSampleInstancesHigh OBJECT-TYPE SYNTAX Gauge32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The highest value of mteResourceSampleInstances that has occurred since initialization of the management system." ::= { mteResource 4 } Expires December 2003 [Page 12] Internet Draft Distributed Management Event MIB 13 June 2003 mteResourceSampleInstanceLacks OBJECT-TYPE SYNTAX Counter32 UNITS "instances" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times this system could not take a new sample because that allocation would have exceeded the limit set by mteResourceSampleInstanceMaximum." ::= { mteResource 5 } -- -- Trigger Section -- -- Counters mteTriggerFailures OBJECT-TYPE SYNTAX Counter32 UNITS "failures" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an attempt to check for a trigger condition has failed. This counts individually for each attempt in a group of targets or each attempt for a wildcarded object." ::= { mteTrigger 1 } -- -- Trigger Table -- mteTriggerTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information." ::= { mteTrigger 2 } mteTriggerEntry OBJECT-TYPE SYNTAX MteTriggerEntry MAX-ACCESS not-accessible STATUS current Expires December 2003 [Page 13] Internet Draft Distributed Management Event MIB 13 June 2003 DESCRIPTION "Information about a single trigger. Applications create and delete entries using mteTriggerEntryStatus." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerTable 1 } MteTriggerEntry ::= SEQUENCE { mteOwner SnmpAdminString, mteTriggerName SnmpAdminString, mteTriggerComment SnmpAdminString, mteTriggerTest BITS, mteTriggerSampleType INTEGER, mteTriggerValueID OBJECT IDENTIFIER, mteTriggerValueIDWildcard TruthValue, mteTriggerTargetTag SnmpTagValue, mteTriggerContextName SnmpAdminString, mteTriggerContextNameWildcard TruthValue, mteTriggerFrequency Unsigned32, mteTriggerObjectsOwner SnmpAdminString, mteTriggerObjects SnmpAdminString, mteTriggerEnabled TruthValue, mteTriggerEntryStatus RowStatus, mteTriggerEntryStorageType StorageType } mteOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The owner of this entry. The exact semantics of this string are subject to the security policy defined by the security administrator." ::= { mteTriggerEntry 1 } mteTriggerName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the trigger within the scope of mteOwner." ::= { mteTriggerEntry 2 } mteTriggerComment OBJECT-TYPE Expires December 2003 [Page 14] Internet Draft Distributed Management Event MIB 13 June 2003 SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A description of the trigger's function and use." DEFVAL { ''H } ::= { mteTriggerEntry 3 } mteTriggerTest OBJECT-TYPE SYNTAX BITS { existence(0), boolean(1), threshold(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of trigger test to perform. For 'boolean' and 'threshold' tests, the object at mteTriggerValueID MUST evaluate to an integer, that is, anything that ends up encoded for transmission (that is, in BER, not ASN.1) as an integer. For 'existence', the specific test is as selected by mteTriggerExistenceTest. When an object appears, vanishes or changes value, the trigger fires. If the object's appearance caused the trigger firing, the object MUST vanish before the trigger can be fired again for it, and vice versa. If the trigger fired due to a change in the object's value, it will be fired again on every successive value change for that object. For 'boolean', the specific test is as selected by mteTriggerBooleanTest. If the test result is true the trigger fires. The trigger will not fire again until the value has become false and come back to true. For 'threshold' the test works as described below for mteTriggerThresholdStartup, mteTriggerThresholdRising, and mteTriggerThresholdFalling. Note that combining 'boolean' and 'threshold' tests on the same object may be somewhat redundant." DEFVAL { { boolean } } ::= { mteTriggerEntry 4 } mteTriggerSampleType OBJECT-TYPE SYNTAX INTEGER { absoluteValue(1), deltaValue(2) } MAX-ACCESS read-create STATUS current Expires December 2003 [Page 15] Internet Draft Distributed Management Event MIB 13 June 2003 DESCRIPTION "The type of sampling to perform. An 'absoluteValue' sample requires only a single sample to be meaningful, and is exactly the value of the object at mteTriggerValueID at the sample time. A 'deltaValue' requires two samples to be meaningful and is thus not available for testing until the second and subsequent samples after the object at mteTriggerValueID is first found to exist. It is the difference between the two samples. For unsigned values it is always positive, based on unsigned arithmetic. For signed values it can be positive or negative. For SNMP counters to be meaningful they should be sampled as a 'deltaValue'. For 'deltaValue' mteTriggerDeltaTable contains further parameters. If only 'existence' is set in mteTriggerTest this object has no meaning." DEFVAL { absoluteValue } ::= { mteTriggerEntry 5 } mteTriggerValueID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of the MIB object to sample to see if the trigger should fire. This may be wildcarded by truncating all or part of the instance portion, in which case the value is obtained as if with a GetNext function, checking multiple values if they exist. If such wildcarding is applied, mteTriggerValueIDWildcard must be 'true' and if not it must be 'false'. Bad object identifiers or a mismatch between truncating the identifier and the value of mteTriggerValueIDWildcard result in operation as one would expect when providing the wrong identifier to a Get or GetNext operation. The Get will fail or get the wrong object. The GetNext will indeed get whatever Expires December 2003 [Page 16] Internet Draft Distributed Management Event MIB 13 June 2003 is next, proceeding until it runs past the initial part of the identifier and perhaps many unintended objects for confusing results. If the value syntax of those objects is not usable, that results in a 'badType' error that terminates the scan. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time." DEFVAL { zeroDotZero } ::= { mteTriggerEntry 6 } mteTriggerValueIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteTriggerValueID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteTriggerEntry 7 } mteTriggerTargetTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "The tag for the target(s) from which to obtain the condition for a trigger check. A length of 0 indicates the local system. In this case, access to the objects indicated by mteTriggerValueID is under the security credentials of the requester that set mteTriggerEntryStatus to 'active'. Those credentials are the input parameters for isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. Otherwise access rights are checked according to the security parameters resulting from the tag." DEFVAL { ''H } ::= { mteTriggerEntry 8 } mteTriggerContextName OBJECT-TYPE SYNTAX SnmpAdminString Expires December 2003 [Page 17] Internet Draft Distributed Management Event MIB 13 June 2003 MAX-ACCESS read-create STATUS current DESCRIPTION "The management context from which to obtain mteTriggerValueID. This may be wildcarded by leaving characters off the end. For example use 'Repeater' to wildcard to 'Repeater1', 'Repeater2', 'Repeater-999.87b', and so on. To indicate such wildcarding is intended, mteTriggerContextNameWildcard must be 'true'. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time. Operation of this feature assumes that the local system has a list of available contexts against which to apply the wildcard. If the objects are being read from the local system, this is clearly the system's own list of contexts. For a remote system a local version of such a list is not defined by any current standard and may not be available, so this function MAY not be supported." DEFVAL { ''H } ::= { mteTriggerEntry 9 } mteTriggerContextNameWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteTriggerContextName is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteTriggerEntry 10 } mteTriggerFrequency OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds to wait between trigger samples. To encourage consistency in sampling, the interval is measured Expires December 2003 [Page 18] Internet Draft Distributed Management Event MIB 13 June 2003 from the beginning of one check to the beginning of the next and the timer is restarted immediately when it expires, not when the check completes. If the next sample begins before the previous one completed the system may either attempt to make the check or treat this as an error condition with the error 'sampleOverrun'. A frequency of 0 indicates instantaneous recognition of the condition. This is not possible in many cases, but may be supported in cases where it makes sense and the system is able to do so. This feature allows the MIB to be used in implementations where such interrupt-driven behavior is possible and is not likely to be supported for all MIB objects even then since such sampling generally has to be tightly integrated into low-level code. Systems that can support this SHOULD document those cases where it can be used. In cases where it can not, setting this object to 0 should be disallowed." DEFVAL { 600 } ::= { mteTriggerEntry 11 } mteTriggerObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "To go with mteTriggerObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerEntry 12 } mteTriggerObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger. A list of objects may also be added based on the event or on the value of mteTriggerTest. Expires December 2003 [Page 19] Internet Draft Distributed Management Event MIB 13 June 2003 A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerEntry 13 } mteTriggerEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A control to allow a trigger to be configured but not used. When the value is 'false' the trigger is not sampled. Whenever the value goes from 'false' to 'true', the trigger is treated as being initialized. That is, no history is kept of any trigger sample values from previous times when this control may have been enabled. If this object is set to 'true' when its value is already 'true', the operation has no effect; that is, the trigger is not re-initialized, and there is no error." DEFVAL { false } ::= { mteTriggerEntry 14 } mteTriggerEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry may not be modified except to modify the value of mteTriggerEnabled or to delete the entry." ::= { mteTriggerEntry 15 } mteTriggerEntryStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row, except for mteTriggerEnabled. " DEFVAL { nonVolatile } Expires December 2003 [Page 20] Internet Draft Distributed Management Event MIB 13 June 2003 ::= { mteTriggerEntry 16 } -- -- Trigger Delta Table -- mteTriggerDeltaTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerDeltaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for delta sampling." ::= { mteTrigger 3 } mteTriggerDeltaEntry OBJECT-TYPE SYNTAX MteTriggerDeltaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single trigger's delta sampling. Entries automatically exist in this this table for each mteTriggerEntry that has mteTriggerSampleType set to 'deltaValue'." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerDeltaTable 1 } MteTriggerDeltaEntry ::= SEQUENCE { mteTriggerDeltaDiscontinuityID OBJECT IDENTIFIER, mteTriggerDeltaDiscontinuityIDWildcard TruthValue, mteTriggerDeltaDiscontinuityIDType INTEGER } sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } mteTriggerDeltaDiscontinuityID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or DateAndTime object that indicates a discontinuity in the value at mteTriggerValueID. The OID may be for a leaf object (e.g. sysUpTime.0) or may be wildcarded to match mteTriggerValueID. Expires December 2003 [Page 21] Internet Draft Distributed Management Event MIB 13 June 2003 This object supports normal checking for a discontinuity in a counter. Note that if this object does not point to sysUpTime discontinuity checking MUST still check sysUpTime for an overall discontinuity. If the object identified is not accessible the sample attempt is in error, with the error code as from an SNMP request. Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the value syntax of those objects is not usable, that results in an error that terminates the sample with a 'badType' error code." DEFVAL { sysUpTimeInstance } ::= { mteTriggerDeltaEntry 1 } mteTriggerDeltaDiscontinuityIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether mteTriggerDeltaDiscontinuityID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard. Note that the value of this object will be the same as that of the corresponding instance of mteTriggerValueIDWildcard when the corresponding mteTriggerSampleType is 'deltaValue'." DEFVAL { false } ::= { mteTriggerDeltaEntry 2 } mteTriggerDeltaDiscontinuityIDType OBJECT-TYPE SYNTAX INTEGER { timeTicks(1), timeStamp(2), dateAndTime(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value 'timeTicks' indicates the mteTriggerDeltaDiscontinuityID of this row is of syntax TimeTicks. The value 'timeStamp' indicates syntax TimeStamp. The value 'dateAndTime' indicates syntax DateAndTime." DEFVAL { timeTicks } ::= { mteTriggerDeltaEntry 3 } -- Expires December 2003 [Page 22] Internet Draft Distributed Management Event MIB 13 June 2003 -- Trigger Existence Table -- mteTriggerExistenceTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerExistenceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for existence triggers." ::= { mteTrigger 4 } mteTriggerExistenceEntry OBJECT-TYPE SYNTAX MteTriggerExistenceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single existence trigger. Entries automatically exist in this this table for each mteTriggerEntry that has 'existence' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerExistenceTable 1 } MteTriggerExistenceEntry ::= SEQUENCE { mteTriggerExistenceTest BITS, mteTriggerExistenceStartup BITS, mteTriggerExistenceObjectsOwner SnmpAdminString, mteTriggerExistenceObjects SnmpAdminString, mteTriggerExistenceEventOwner SnmpAdminString, mteTriggerExistenceEvent SnmpAdminString } mteTriggerExistenceTest OBJECT-TYPE SYNTAX BITS { present(0), absent(1), changed(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of existence test to perform. The trigger fires when the object at mteTriggerValueID is seen to go from present to absent, from absent to present, or to have it's value changed, depending on which tests are selected: present(0) - when this test is selected, the trigger fires when the mteTriggerValueID object goes from absent to present. Expires December 2003 [Page 23] Internet Draft Distributed Management Event MIB 13 June 2003 absent(1) - when this test is selected, the trigger fires when the mteTriggerValueID object goes from present to absent. changed(2) - when this test is selected, the trigger fires the mteTriggerValueID object value changes. Once the trigger has fired for either presence or absence it will not fire again for that state until the object has been to the other state. " DEFVAL { { present, absent } } ::= { mteTriggerExistenceEntry 1 } mteTriggerExistenceStartup OBJECT-TYPE SYNTAX BITS { present(0), absent(1) } MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether an event may be triggered when this entry is first set to 'active' and the test specified by mteTriggerExistenceTest is true. Setting an option causes that trigger to fire when its test is true." DEFVAL { { present, absent } } ::= { mteTriggerExistenceEntry 2 } mteTriggerExistenceObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerExistenceObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 3 } mteTriggerExistenceObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. Expires December 2003 [Page 24] Internet Draft Distributed Management Event MIB 13 June 2003 A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 4 } mteTriggerExistenceEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerExistenceEvent, the mteOwner of an event entry from the mteEventTable." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 5 } mteTriggerExistenceEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'existence' and this trigger fires. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerExistenceEntry 6 } -- -- Trigger Boolean Table -- mteTriggerBooleanTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerBooleanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for boolean triggers." ::= { mteTrigger 5 } mteTriggerBooleanEntry OBJECT-TYPE SYNTAX MteTriggerBooleanEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single boolean trigger. Entries automatically exist in this this table for each mteTriggerEntry Expires December 2003 [Page 25] Internet Draft Distributed Management Event MIB 13 June 2003 that has 'boolean' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerBooleanTable 1 } MteTriggerBooleanEntry ::= SEQUENCE { mteTriggerBooleanComparison INTEGER, mteTriggerBooleanValue Integer32, mteTriggerBooleanStartup TruthValue, mteTriggerBooleanObjectsOwner SnmpAdminString, mteTriggerBooleanObjects SnmpAdminString, mteTriggerBooleanEventOwner SnmpAdminString, mteTriggerBooleanEvent SnmpAdminString } mteTriggerBooleanComparison OBJECT-TYPE SYNTAX INTEGER { unequal(1), equal(2), less(3), lessOrEqual(4), greater(5), greaterOrEqual(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "The type of boolean comparison to perform. The value at mteTriggerValueID is compared to mteTriggerBooleanValue, so for example if mteTriggerBooleanComparison is 'less' the result would be true if the value at mteTriggerValueID is less than the value of mteTriggerBooleanValue." DEFVAL { unequal } ::= { mteTriggerBooleanEntry 1 } mteTriggerBooleanValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value to use for the test specified by mteTriggerBooleanTest." DEFVAL { 0 } ::= { mteTriggerBooleanEntry 2 } mteTriggerBooleanStartup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current Expires December 2003 [Page 26] Internet Draft Distributed Management Event MIB 13 June 2003 DESCRIPTION "Control for whether an event may be triggered when this entry is first set to 'active' or a new instance of the object at mteTriggerValueID is found and the test specified by mteTriggerBooleanComparison is true. In that case an event is triggered if mteTriggerBooleanStartup is 'true'." DEFVAL { true } ::= { mteTriggerBooleanEntry 3 } mteTriggerBooleanObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerBooleanObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 4 } mteTriggerBooleanObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 5 } mteTriggerBooleanEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerBooleanEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 6 } Expires December 2003 [Page 27] Internet Draft Distributed Management Event MIB 13 June 2003 mteTriggerBooleanEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'boolean' and this trigger fires. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerBooleanEntry 7 } -- -- Trigger Threshold Table -- mteTriggerThresholdTable OBJECT-TYPE SYNTAX SEQUENCE OF MteTriggerThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event trigger information for threshold triggers." ::= { mteTrigger 6 } mteTriggerThresholdEntry OBJECT-TYPE SYNTAX MteTriggerThresholdEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single threshold trigger. Entries automatically exist in this table for each mteTriggerEntry that has 'threshold' set in mteTriggerTest." INDEX { mteOwner, IMPLIED mteTriggerName } ::= { mteTriggerThresholdTable 1 } MteTriggerThresholdEntry ::= SEQUENCE { mteTriggerThresholdStartup INTEGER, mteTriggerThresholdRising Integer32, mteTriggerThresholdFalling Integer32, mteTriggerThresholdDeltaRising Integer32, mteTriggerThresholdDeltaFalling Integer32, mteTriggerThresholdObjectsOwner SnmpAdminString, mteTriggerThresholdObjects SnmpAdminString, mteTriggerThresholdRisingEventOwner SnmpAdminString, mteTriggerThresholdRisingEvent SnmpAdminString, Expires December 2003 [Page 28] Internet Draft Distributed Management Event MIB 13 June 2003 mteTriggerThresholdFallingEventOwner SnmpAdminString, mteTriggerThresholdFallingEvent SnmpAdminString, mteTriggerThresholdDeltaRisingEventOwner SnmpAdminString, mteTriggerThresholdDeltaRisingEvent SnmpAdminString, mteTriggerThresholdDeltaFallingEventOwner SnmpAdminString, mteTriggerThresholdDeltaFallingEvent SnmpAdminString } mteTriggerThresholdStartup OBJECT-TYPE SYNTAX INTEGER { rising(1), falling(2), risingOrFalling(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "The event that may be triggered when this entry is first set to 'active' and a new instance of the object at mteTriggerValueID is found. If the first sample after this instance becomes active is greater than or equal to mteTriggerThresholdRising and mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling', then one mteTriggerThresholdRisingEvent is triggered for that instance. If the first sample after this entry becomes active is less than or equal to mteTriggerThresholdFalling and mteTriggerThresholdStartup is equal to 'falling' or 'risingOrFalling', then one mteTriggerThresholdRisingEvent is triggered for that instance." DEFVAL { risingOrFalling } ::= { mteTriggerThresholdEntry 1 } mteTriggerThresholdRising OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, one mteTriggerThresholdRisingEvent is triggered. That event is also triggered if the first sample after this entry becomes active is greater than or equal to this threshold and mteTriggerThresholdStartup is equal to 'rising' or 'risingOrFalling'. Expires December 2003 [Page 29] Internet Draft Distributed Management Event MIB 13 June 2003 After a rising event is generated, another such event is not triggered until the sampled value falls below this threshold and reaches mteTriggerThresholdFalling." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 2 } mteTriggerThresholdFalling OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, one mteTriggerThresholdFallingEvent is triggered. That event is also triggered if the first sample after this entry becomes active is less than or equal to this threshold and mteTriggerThresholdStartup is equal to 'falling' or 'risingOrFalling'. After a falling event is generated, another such event is not triggered until the sampled value rises above this threshold and reaches mteTriggerThresholdRising." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 3 } mteTriggerThresholdDeltaRising OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the delta value (difference) between the current sampled value (value(n)) and the previous sampled value (value(n-1)) is greater than or equal to this threshold, and the delta value calculated at the last sampling interval (i.e. value(n-1) - value(n-2)) was less than this threshold, one mteTriggerThresholdDeltaRisingEvent is triggered. That event is also triggered if the first delta value calculated after this entry becomes active, i.e. value(2) - value(1), where value(1) Expires December 2003 [Page 30] Internet Draft Distributed Management Event MIB 13 June 2003 is the first sample taken of that instance, is greater than or equal to this threshold. After a rising event is generated, another such event is not triggered until the delta value falls below this threshold and reaches mteTriggerThresholdDeltaFalling." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 4 } mteTriggerThresholdDeltaFalling OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "A threshold value to check against if mteTriggerType is 'threshold'. When the delta value (difference) between the current sampled value (value(n)) and the previous sampled value (value(n-1)) is less than or equal to this threshold, and the delta value calculated at the last sampling interval (i.e. value(n-1) - value(n-2)) was greater than this threshold, one mteTriggerThresholdDeltaFallingEvent is triggered. That event is also triggered if the first delta value calculated after this entry becomes active, i.e. value(2) - value(1), where value(1) is the first sample taken of that instance, is less than or equal to this threshold. After a falling event is generated, another such event is not triggered until the delta value falls below this threshold and reaches mteTriggerThresholdDeltaRising." DEFVAL { 0 } ::= { mteTriggerThresholdEntry 5 } mteTriggerThresholdObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 6 } mteTriggerThresholdObjects OBJECT-TYPE Expires December 2003 [Page 31] Internet Draft Distributed Management Event MIB 13 June 2003 SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable. These objects are to be added to any Notification resulting from the firing of this trigger for this test. A list of objects may also be added based on the overall trigger, the event or other settings in mteTriggerTest. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 7 } mteTriggerThresholdRisingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdRisingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 8 } mteTriggerThresholdRisingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdRising. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 9 } mteTriggerThresholdFallingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdFallingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } Expires December 2003 [Page 32] Internet Draft Distributed Management Event MIB 13 June 2003 ::= { mteTriggerThresholdEntry 10 } mteTriggerThresholdFallingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdFalling. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 11 } mteTriggerThresholdDeltaRisingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdDeltaRisingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 12 } mteTriggerThresholdDeltaRisingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdDeltaRising. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 13 } mteTriggerThresholdDeltaFallingEventOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteTriggerThresholdDeltaFallingEvent, the mteOwner of an event entry from mteEventTable." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 14 } Expires December 2003 [Page 33] Internet Draft Distributed Management Event MIB 13 June 2003 mteTriggerThresholdDeltaFallingEvent OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteEventName of the event to invoke when mteTriggerType is 'threshold' and this trigger fires based on mteTriggerThresholdDeltaFalling. A length of 0 indicates no event." DEFVAL { ''H } ::= { mteTriggerThresholdEntry 15 } -- -- Objects Table -- mteObjectsTable OBJECT-TYPE SYNTAX SEQUENCE OF MteObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of objects that can be added to notifications based on the trigger, trigger test, or event, as pointed to by entries in those tables." ::= { mteObjects 1 } mteObjectsEntry OBJECT-TYPE SYNTAX MteObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A group of objects. Applications create and delete entries using mteObjectsEntryStatus. When adding objects to a notification they are added in the lexical order of their index in this table. Those associated with a trigger come first, then trigger test, then event." INDEX { mteOwner, mteObjectsName, mteObjectsIndex } ::= { mteObjectsTable 1 } MteObjectsEntry ::= SEQUENCE { mteObjectsName SnmpAdminString, mteObjectsIndex Unsigned32, mteObjectsID OBJECT IDENTIFIER, mteObjectsIDWildcard TruthValue, Expires December 2003 [Page 34] Internet Draft Distributed Management Event MIB 13 June 2003 mteObjectsEntryStatus RowStatus, mteObjectsEntryStorageType Storagetype } mteObjectsName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for a group of objects." ::= { mteObjectsEntry 1 } mteObjectsIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer for the purpose of identifying individual objects within a mteObjectsName group. Objects within a group are placed in the notification in the numerical order of this index. Groups are placed in the notification in the order of the selections for overall trigger, trigger test, and event. Within trigger test they are in the same order as the numerical values of the bits defined for mteTriggerTest. Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the object is not available it is omitted from the notification." ::= { mteObjectsEntry 2 } mteObjectsID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of a MIB object to add to a Notification that results from the firing of a trigger. Expires December 2003 [Page 35] Internet Draft Distributed Management Event MIB 13 June 2003 This may be wildcarded by truncating all or part of the instance portion, in which case the instance portion of the OID for obtaining this object will be the same as that used in obtaining the mteTriggerValueID that fired. If such wildcarding is applied, mteObjectsIDWildcard must be 'true' and if not it must be 'false'. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time." DEFVAL { zeroDotZero } ::= { mteObjectsEntry 3 } mteObjectsIDWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether mteObjectsID is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { mteObjectsEntry 4 } mteObjectsEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry MAY not be modified except to delete it." ::= { mteObjectsEntry 5 } mteObjectsEntryStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { mteObectsEntry 6 } Expires December 2003 [Page 36] Internet Draft Distributed Management Event MIB 13 June 2003 -- -- Event Section -- -- Counters mteEventFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an attempt to invoke an event has failed. This counts individually for each attempt in a group of targets or each attempt for a wildcarded trigger object." ::= { mteEvent 1 } -- -- Event Table -- mteEventTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event action information." ::= { mteEvent 2 } mteEventEntry OBJECT-TYPE SYNTAX MteEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event. Applications create and delete entries using mteEventEntryStatus." INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventTable 1 } MteEventEntry ::= SEQUENCE { mteEventName SnmpAdminString, mteEventComment SnmpAdminString, mteEventActions BITS, mteEventEnabled TruthValue, mteEventEntryStatus RowStatus, Expires December 2003 [Page 37] Internet Draft Distributed Management Event MIB 13 June 2003 mteEventEntryStorageType StorageType } mteEventName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A locally-unique, administratively assigned name for the event." ::= { mteEventEntry 1 } mteEventComment OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "A description of the event's function and use." DEFVAL { ''H } ::= { mteEventEntry 2 } mteEventActions OBJECT-TYPE SYNTAX BITS { notification(0), set(1) } MAX-ACCESS read-create STATUS current DESCRIPTION "The actions to perform when this event occurs. For 'notification', Traps and/or Informs are sent according to the configuration in the SNMP Notification MIB. For 'set', an SNMP Set operation is performed according to control values in this entry." DEFVAL { {} } -- No bits set. ::= { mteEventEntry 3 } mteEventEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "A control to allow an event to be configured but not used. When the value is 'false' the event does not execute even if triggered." DEFVAL { false } Expires December 2003 [Page 38] Internet Draft Distributed Management Event MIB 13 June 2003 ::= { mteEventEntry 4 } mteEventEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation and deletion of entries. Once made active an entry MAY not be modified except to modify the value of mteEventEnabled or to delete the entry." ::= { mteEventEntry 5 } mteEventEntryStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row. Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects in the row. " DEFVAL { nonVolatile } ::= { mteEventEntry 6 } -- -- Event Notification Table -- mteEventNotificationTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of information about notifications to be sent as a consequence of management events." ::= { mteEvent 3 } mteEventNotificationEntry OBJECT-TYPE SYNTAX MteEventNotificationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event's notification. Entries automatically exist in this this table for each mteEventEntry that has 'notification' set in mteEventActions." Expires December 2003 [Page 39] Internet Draft Distributed Management Event MIB 13 June 2003 INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventNotificationTable 1 } MteEventNotificationEntry ::= SEQUENCE { mteEventNotification OBJECT IDENTIFIER, mteEventNotificationObjectsOwner SnmpAdminString, mteEventNotificationObjects SnmpAdminString } mteEventNotification OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The object identifier from the NOTIFICATION-TYPE for the notification to use if mteEventActions has 'notification' set." DEFVAL { zeroDotZero } ::= { mteEventNotificationEntry 1 } mteEventNotificationObjectsOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "To go with mteEventNotificationObjects, the mteOwner of a group of objects from mteObjectsTable." DEFVAL { ''H } ::= { mteEventNotificationEntry 2 } mteEventNotificationObjects OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-write STATUS current DESCRIPTION "The mteObjectsName of a group of objects from mteObjectsTable if mteEventActions has 'notification' set. These objects are to be added to any Notification generated by this event. Objects may also be added based on the trigger that stimulated the event. A length of 0 indicates no additional objects." DEFVAL { ''H } ::= { mteEventNotificationEntry 3 } Expires December 2003 [Page 40] Internet Draft Distributed Management Event MIB 13 June 2003 -- -- Event Set Table -- mteEventSetTable OBJECT-TYPE SYNTAX SEQUENCE OF MteEventSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of management event action information." ::= { mteEvent 4 } mteEventSetEntry OBJECT-TYPE SYNTAX MteEventSetEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single event's set option. Entries automatically exist in this this table for each mteEventEntry that has 'set' set in mteEventActions." INDEX { mteOwner, IMPLIED mteEventName } ::= { mteEventSetTable 1 } MteEventSetEntry ::= SEQUENCE { mteEventSetObject OBJECT IDENTIFIER, mteEventSetObjectWildcard TruthValue, mteEventSetValue Integer32, mteEventSetTargetTag SnmpTagValue, mteEventSetContextName SnmpAdminString, mteEventSetContextNameWildcard TruthValue } mteEventSetObject OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The object identifier from the MIB object to set if mteEventActions has 'set' set. This object identifier may be wildcarded by leaving sub-identifiers off the end, in which case nteEventSetObjectWildCard must be 'true'. If mteEventSetObject is wildcarded the instance used to set the Expires December 2003 [Page 41] Internet Draft Distributed Management Event MIB 13 June 2003 object to which it points is the same as the instance from the value of mteTriggerValueID that triggered the event. Each instance that fills the wildcard is independent of any additional instances, that is, wildcarded objects operate as if there were a separate table entry for each instance that fills the wildcard without having to actually predict all possible instances ahead of time. Bad object identifiers or a mismatch between truncating the identifier and the value of mteSetObjectWildcard result in operation as one would expect when providing the wrong identifier to a Set operation. The Set will fail or set the wrong object. If the value syntax of the destination object is not correct, the Set fails with the normal SNMP error code." DEFVAL { zeroDotZero } ::= { mteEventSetEntry 1 } mteEventSetObjectWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control over whether mteEventSetObject is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard if mteEventActions has 'set' set." DEFVAL { false } ::= { mteEventSetEntry 2 } mteEventSetValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The value to which to set the object at mteEventSetObject if mteEventActions has 'set' set." DEFVAL { 0 } ::= { mteEventSetEntry 3 } mteEventSetTargetTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-write STATUS current DESCRIPTION Expires December 2003 [Page 42] Internet Draft Distributed Management Event MIB 13 June 2003 "The tag for the target(s) at which to set the object at mteEventSetObject to mteEventSetValue if mteEventActions has 'set' set. Systems limited to self management MAY reject a non-zero length for the value of this object. A length of 0 indicates the local system. In this case, access to the objects indicated by mteEventSetObject is under the security credentials of the requester that set mteTriggerEntryStatus to 'active'. Those credentials are the input parameters for isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. Otherwise access rights are checked according to the security parameters resulting from the tag." DEFVAL { ''H } ::= { mteEventSetEntry 4 } mteEventSetContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "The management context in which to set mteEventObjectID. if mteEventActions has 'set' set. This may be wildcarded by leaving characters off the end. To indicate such wildcarding mteEventSetContextNameWildcard must be 'true'. If this context name is wildcarded the value used to complete the wildcarding of mteTriggerContextName will be appended." DEFVAL { ''H } ::= { mteEventSetEntry 5 } mteEventSetContextNameWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Control for whether mteEventSetContextName is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard if mteEventActions has 'set' set." DEFVAL { false } Expires December 2003 [Page 43] Internet Draft Distributed Management Event MIB 13 June 2003 ::= { mteEventSetEntry 6 } -- -- Notifications -- dismanEventMIBNotificationPrefix OBJECT IDENTIFIER ::= { dismanEventMIB 2 } dismanEventMIBNotifications OBJECT IDENTIFIER ::= { dismanEventMIBNotificationPrefix 0 } dismanEventMIBNotificationObjects OBJECT IDENTIFIER ::= { dismanEventMIBNotificationPrefix 1 } -- -- Notification Objects -- mteHotTrigger OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The name of the trigger causing the notification." ::= { dismanEventMIBNotificationObjects 1 } mteHotTargetName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The SNMP Target MIB's snmpTargetAddrName related to the notification." ::= { dismanEventMIBNotificationObjects 2 } mteHotContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The context name related to the notification. This MUST be as fully-qualified as possible, including filling in wildcard information determined in processing." ::= { dismanEventMIBNotificationObjects 3 } mteHotOID OBJECT-TYPE Expires December 2003 [Page 44] Internet Draft Distributed Management Event MIB 13 June 2003 SYNTAX OBJECT IDENTIFIER MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The object identifier of the destination object related to the notification. This MUST be as fully-qualified as possible, including filling in wildcard information determined in processing. For a trigger-related notification this is from mteTriggerValueID. For a set failure this is from mteEventSetObject." ::= { dismanEventMIBNotificationObjects 4 } mteHotValue OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the object at mteTriggerValueID when a trigger fired." ::= { dismanEventMIBNotificationObjects 5 } mteFailedReason OBJECT-TYPE SYNTAX FailureReason MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The reason for the failure of an attempt to check for a trigger condition or set an object in response to an event." ::= { dismanEventMIBNotificationObjects 6 } -- -- Notifications -- mteTriggerFired NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION Expires December 2003 [Page 45] Internet Draft Distributed Management Event MIB 13 June 2003 "Notification that the trigger indicated by the object instances has fired, for triggers with mteTriggerType 'boolean' or 'existence'." ::= { dismanEventMIBNotifications 1 } mteTriggerRising NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the rising threshold was met for triggers with mteTriggerType 'threshold'." ::= { dismanEventMIBNotifications 2 } mteTriggerFalling NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue } STATUS current DESCRIPTION "Notification that the falling threshold was met for triggers with mteTriggerType 'threshold'." ::= { dismanEventMIBNotifications 3 } mteTriggerFailure NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteFailedReason } STATUS current DESCRIPTION "Notification that an attempt to check a trigger has failed. The network manager must enable this notification only with a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { dismanEventMIBNotifications 4 } Expires December 2003 [Page 46] Internet Draft Distributed Management Event MIB 13 June 2003 mteEventSetFailure NOTIFICATION-TYPE OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteFailedReason } STATUS current DESCRIPTION "Notification that an attempt to do a set in response to an event has failed. The network manager must enable this notification only with a certain fear and trembling, as it can easily crowd out more important information. It should be used only to help diagnose a problem that has appeared in the error counters and can not be found otherwise." ::= { dismanEventMIBNotifications 5 } -- -- Conformance -- dismanEventMIBConformance OBJECT IDENTIFIER ::= { dismanEventMIB 3 } dismanEventMIBCompliances OBJECT IDENTIFIER ::= { dismanEventMIBConformance 1 } dismanEventMIBGroups OBJECT IDENTIFIER ::= { dismanEventMIBConformance 2 } -- Compliance dismanEventMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Event MIB." MODULE -- this module MANDATORY-GROUPS { dismanEventResourceGroup, dismanEventTriggerGroup, dismanEventObjectsGroup, dismanEventEventGroup, dismanEventNotificationObjectGroup, dismanEventNotificationGroup } Expires December 2003 [Page 47] Internet Draft Distributed Management Event MIB 13 June 2003 OBJECT mteTriggerTargetTag MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus limiting monitoring to the local system or pre-configured remote systems." OBJECT mteEventSetTargetTag MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus limiting setting to the local system or pre-configured remote systems." OBJECT mteTriggerValueIDWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteTriggerContextNameWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteObjectsIDWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." OBJECT mteEventSetContextNameWildcard MIN-ACCESS read-only DESCRIPTION "Write access is not required, thus allowing the system not to implement wildcarding." ::= { dismanEventMIBCompliances 1 } -- Units of Conformance dismanEventResourceGroup OBJECT-GROUP OBJECTS { Expires December 2003 [Page 48] Internet Draft Distributed Management Event MIB 13 June 2003 mteResourceSampleMinimum, mteResourceSampleInstanceMaximum, mteResourceSampleInstances, mteResourceSampleInstancesHigh, mteResourceSampleInstanceLacks } STATUS current DESCRIPTION "Event resource status and control objects." ::= { dismanEventMIBGroups 1 } dismanEventTriggerGroup OBJECT-GROUP OBJECTS { mteTriggerFailures, mteTriggerComment, mteTriggerTest, mteTriggerSampleType, mteTriggerValueID, mteTriggerValueIDWildcard, mteTriggerTargetTag, mteTriggerContextName, mteTriggerContextNameWildcard, mteTriggerFrequency, mteTriggerObjectsOwner, mteTriggerObjects, mteTriggerEnabled, mteTriggerEntryStatus, mteTriggerDeltaDiscontinuityID, mteTriggerDeltaDiscontinuityIDWildcard, mteTriggerDeltaDiscontinuityIDType, mteTriggerExistenceTest, mteTriggerExistenceStartup, mteTriggerExistenceObjectsOwner, mteTriggerExistenceObjects, mteTriggerExistenceEventOwner, mteTriggerExistenceEvent, mteTriggerBooleanComparison, mteTriggerBooleanValue, mteTriggerBooleanStartup, mteTriggerBooleanObjectsOwner, mteTriggerBooleanObjects, mteTriggerBooleanEventOwner, Expires December 2003 [Page 49] Internet Draft Distributed Management Event MIB 13 June 2003 mteTriggerBooleanEvent, mteTriggerThresholdStartup, mteTriggerThresholdObjectsOwner, mteTriggerThresholdObjects, mteTriggerThresholdRising, mteTriggerThresholdFalling, mteTriggerThresholdDeltaRising, mteTriggerThresholdDeltaFalling, mteTriggerThresholdRisingEventOwner, mteTriggerThresholdRisingEvent, mteTriggerThresholdFallingEventOwner, mteTriggerThresholdFallingEvent, mteTriggerThresholdDeltaRisingEventOwner, mteTriggerThresholdDeltaRisingEvent, mteTriggerThresholdDeltaFallingEventOwner, mteTriggerThresholdDeltaFallingEvent } STATUS current DESCRIPTION "Event triggers." ::= { dismanEventMIBGroups 2 } dismanEventObjectsGroup OBJECT-GROUP OBJECTS { mteObjectsID, mteObjectsIDWildcard, mteObjectsEntryStatus } STATUS current DESCRIPTION "Supplemental objects." ::= { dismanEventMIBGroups 3 } dismanEventEventGroup OBJECT-GROUP OBJECTS { mteEventFailures, mteEventComment, mteEventActions, mteEventEnabled, mteEventEntryStatus, mteEventNotification, mteEventNotificationObjectsOwner, Expires December 2003 [Page 50] Internet Draft Distributed Management Event MIB 13 June 2003 mteEventNotificationObjects, mteEventSetObject, mteEventSetObjectWildcard, mteEventSetValue, mteEventSetTargetTag, mteEventSetContextName, mteEventSetContextNameWildcard } STATUS current DESCRIPTION "Events." ::= { dismanEventMIBGroups 4 } dismanEventNotificationObjectGroup OBJECT-GROUP OBJECTS { mteHotTrigger, mteHotTargetName, mteHotContextName, mteHotOID, mteHotValue, mteFailedReason } STATUS current DESCRIPTION "Notification objects." ::= { dismanEventMIBGroups 5 } dismanEventNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { mteTriggerFired, mteTriggerRising, mteTriggerFalling, mteTriggerFailure, mteEventSetFailure } STATUS current DESCRIPTION "Notifications." ::= { dismanEventMIBGroups 6 } END Expires December 2003 [Page 51] Internet Draft Distributed Management Event MIB 13 June 2003 8. 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. 9. Acknowledgements This MIB contains considerable contributions from the RMON MIB, the Distributed Management Design Team (Andy Bierman, Maria Greene, Bob Stewart, and Steve Waldbusser), the Distributed Management Working Group, and colleagues at Cisco. 10. 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] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. Expires December 2003 [Page 52] Internet Draft Distributed Management Event MIB 13 June 2003 [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 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. Expires December 2003 [Page 53] Internet Draft Distributed Management Event MIB 13 June 2003 [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. [RFC2981] Stewart, B., "Event MIB", RFC 2981, October 2000. [RFC1757] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, February 1995. [RFC1451] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Manager-to- Manager Management Information Base", RFC 1451, April 1993. [RFC2982] Stewart, B., "Distributed Management Expression MIB", RFC 2982, October 2000. [LOG-MIB] Stewart, B., "Notification Log MIB", Work in Progress. 11. Security Considerations Security issues are discussed in the Security section and in the DESCRIPTION clauses of relevant objects. 12. Author's Address Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. 13. Editor's Address Ramanathan Kavasseri Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Expires December 2003 [Page 54] Internet Draft Distributed Management Event MIB 13 June 2003 Phone: +1 408 527 2446 EMail: ramk@cisco.com Expires December 2003 [Page 55] Internet Draft Distributed Management Event MIB 13 June 2003 14. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 December 2003 [Page 56] From mailnull@www1.ietf.org Mon Jun 16 13:14:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21379 for ; Mon, 16 Jun 2003 13:14:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GHDoL19653 for disman-archive@odin.ietf.org; Mon, 16 Jun 2003 13:13:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GHDom19650 for ; Mon, 16 Jun 2003 13:13:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21369 for ; Mon, 16 Jun 2003 13:13:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RxW1-0004A6-00 for disman-web-archive@ietf.org; Mon, 16 Jun 2003 13:11:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19RxW0-0004A2-00 for disman-web-archive@ietf.org; Mon, 16 Jun 2003 13:11:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDx1a04473; Mon, 16 Jun 2003 09:59:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDwmm04459 for ; Mon, 16 Jun 2003 09:58:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14073 for ; Mon, 16 Jun 2003 09:58:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RuTH-0002nC-00 for disman@ietf.org; Mon, 16 Jun 2003 09:56:31 -0400 Received: from adsl-66-127-127-227.dsl.scrm01.pacbell.net ([66.127.127.227] helo=wanderer.hardakers.net ident=[7aTKeb4O/uspNZzUVxQN4VnSQ9SYGmz6]) by ietf-mx with esmtp (Exim 4.12) id 19RuTG-0002n6-00 for disman@ietf.org; Mon, 16 Jun 2003 09:56:30 -0400 Received: by wanderer.hardakers.net (Postfix, from userid 274) id 69F8756852; Mon, 16 Jun 2003 06:58:36 -0700 (PDT) To: "Randy Presuhn" Cc: "Disman (E-mail)" , "Ram Kavasseri" , "Sharon Chisholm" , References: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories In-Reply-To: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> (Randy Presuhn's message of "Fri, 13 Jun 2003 09:24:20 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Disman] Re: To-do items left over from San Francisco Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Jun 2003 06:58:36 -0700 >>>>> On Fri, 13 Jun 2003 09:24:20 -0700, "Randy Presuhn" said: Randy> | 13. NetSNMP implements the EVENT-MIB - this MIB is the target Randy> | of internal polling for NetSNMP apps. Wes Hardaker to provide Randy> | pointers on how to set up a copy of NetSNMP running the Randy> | EVENT-MIB for interoperability testing. Randy> Wes? Download a copy from http://www.Net-SNMP.org/download/ tar xzf net-snmp-5.0.8.tar.gz cd net-snmp-5.0.8 ./configure --with-mibs="disman/event-mib" make make install net-snmp-config --create-snmpv3-user [answer questions about creating your first user] snmpd At which point the snmp agent is up and running and the disman-event-mib objects (most of them) should be configurable. Note that the main-branch of the CVS server has additional code not available in 5.0.8 to support the custom notification generation. 5.0.8 only includes support for generating the mteHotTrigger trap. Also, note that the snmpd.conf manual page contains information on how to set up the snmpd.conf file to include event monitoring using "boolean like" expressions in the snmpd.conf file. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From disman-admin@ietf.org Mon Jun 16 13:14:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21395 for ; Mon, 16 Jun 2003 13:14:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDx1a04473; Mon, 16 Jun 2003 09:59:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GDwmm04459 for ; Mon, 16 Jun 2003 09:58:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14073 for ; Mon, 16 Jun 2003 09:58:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RuTH-0002nC-00 for disman@ietf.org; Mon, 16 Jun 2003 09:56:31 -0400 Received: from adsl-66-127-127-227.dsl.scrm01.pacbell.net ([66.127.127.227] helo=wanderer.hardakers.net ident=[7aTKeb4O/uspNZzUVxQN4VnSQ9SYGmz6]) by ietf-mx with esmtp (Exim 4.12) id 19RuTG-0002n6-00 for disman@ietf.org; Mon, 16 Jun 2003 09:56:30 -0400 Received: by wanderer.hardakers.net (Postfix, from userid 274) id 69F8756852; Mon, 16 Jun 2003 06:58:36 -0700 (PDT) To: "Randy Presuhn" Cc: "Disman (E-mail)" , "Ram Kavasseri" , "Sharon Chisholm" , References: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories In-Reply-To: <013c01c331c8$3eef5b80$7f1afea9@oemcomputer> (Randy Presuhn's message of "Fri, 13 Jun 2003 09:24:20 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Disman] Re: To-do items left over from San Francisco Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Jun 2003 06:58:36 -0700 >>>>> On Fri, 13 Jun 2003 09:24:20 -0700, "Randy Presuhn" said: Randy> | 13. NetSNMP implements the EVENT-MIB - this MIB is the target Randy> | of internal polling for NetSNMP apps. Wes Hardaker to provide Randy> | pointers on how to set up a copy of NetSNMP running the Randy> | EVENT-MIB for interoperability testing. Randy> Wes? Download a copy from http://www.Net-SNMP.org/download/ tar xzf net-snmp-5.0.8.tar.gz cd net-snmp-5.0.8 ./configure --with-mibs="disman/event-mib" make make install net-snmp-config --create-snmpv3-user [answer questions about creating your first user] snmpd At which point the snmp agent is up and running and the disman-event-mib objects (most of them) should be configurable. Note that the main-branch of the CVS server has additional code not available in 5.0.8 to support the custom notification generation. 5.0.8 only includes support for generating the mteHotTrigger trap. Also, note that the snmpd.conf manual page contains information on how to set up the snmpd.conf file to include event monitoring using "boolean like" expressions in the snmpd.conf file. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From disman-admin@ietf.org Mon Jun 16 16:57:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01993 for ; Mon, 16 Jun 2003 16:57:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGW1a16212; Mon, 16 Jun 2003 12:32:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGVgm16198 for ; Mon, 16 Jun 2003 12:31:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20027 for ; Mon, 16 Jun 2003 12:31:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RwrG-0003qE-00 for disman@ietf.org; Mon, 16 Jun 2003 12:29:26 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 19RwrF-0003qA-00 for disman@ietf.org; Mon, 16 Jun 2003 12:29:25 -0400 Received: from h-68-164-78-80.snvacaid.covad.net ([68.164.78.80] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19RwtQ-0004u4-00 for disman@ietf.org; Mon, 16 Jun 2003 09:31:40 -0700 Message-ID: <00ec01c33423$ecc2e080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <002001c331d7$6fb3f460$7f1afea9@oemcomputer> <23391535.1055553731@[10.1.1.26]> Subject: Re: [Disman] Regarding -00- disman documents X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Jun 2003 09:25:39 -0700 Hi - Thanks, I've notified the secretariat. Randy > From: "Juergen Quittek" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Friday, June 13, 2003 4:22 PM > Subject: Re: [Disman] Regarding -00- disman documents > > Randy, > > I plan to submit draft-ietf-disman-remops-mib-v2-00.txt > until the 23rd, although there is no real need to meet the > deadline without a disman session in Vienna. > > Juergen > > -- Randy Presuhn wrote on 13 June 2003 11:13 -0700: > > > Hi - > > > > If you're planning to produce an internet draft with a filename > > that looks like "draft-ietf-disman-*-00.txt", I need to know > > about it posthaste so that I can provide the list of expected > > drafts to the secretariat. > > > > Randy > > > > > > From mailnull@www1.ietf.org Mon Jun 16 16:59:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02029 for ; Mon, 16 Jun 2003 16:59:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GKwdP02984 for disman-archive@odin.ietf.org; Mon, 16 Jun 2003 16:58:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GKwcm02981 for ; Mon, 16 Jun 2003 16:58:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02020 for ; Mon, 16 Jun 2003 16:58:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S11Z-0006hS-00 for disman-web-archive@ietf.org; Mon, 16 Jun 2003 16:56:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19S11Z-0006hP-00 for disman-web-archive@ietf.org; Mon, 16 Jun 2003 16:56:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGW1a16212; Mon, 16 Jun 2003 12:32:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GGVgm16198 for ; Mon, 16 Jun 2003 12:31:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20027 for ; Mon, 16 Jun 2003 12:31:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RwrG-0003qE-00 for disman@ietf.org; Mon, 16 Jun 2003 12:29:26 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 19RwrF-0003qA-00 for disman@ietf.org; Mon, 16 Jun 2003 12:29:25 -0400 Received: from h-68-164-78-80.snvacaid.covad.net ([68.164.78.80] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19RwtQ-0004u4-00 for disman@ietf.org; Mon, 16 Jun 2003 09:31:40 -0700 Message-ID: <00ec01c33423$ecc2e080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <002001c331d7$6fb3f460$7f1afea9@oemcomputer> <23391535.1055553731@[10.1.1.26]> Subject: Re: [Disman] Regarding -00- disman documents X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 16 Jun 2003 09:25:39 -0700 Hi - Thanks, I've notified the secretariat. Randy > From: "Juergen Quittek" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Friday, June 13, 2003 4:22 PM > Subject: Re: [Disman] Regarding -00- disman documents > > Randy, > > I plan to submit draft-ietf-disman-remops-mib-v2-00.txt > until the 23rd, although there is no real need to meet the > deadline without a disman session in Vienna. > > Juergen > > -- Randy Presuhn wrote on 13 June 2003 11:13 -0700: > > > Hi - > > > > If you're planning to produce an internet draft with a filename > > that looks like "draft-ietf-disman-*-00.txt", I need to know > > about it posthaste so that I can provide the list of expected > > drafts to the secretariat. > > > > Randy > > > > > > From disman-admin@ietf.org Tue Jun 17 13:52:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28170 for ; Tue, 17 Jun 2003 13:52:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBd1a20232; Tue, 17 Jun 2003 07:39:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBcAm20189 for ; Tue, 17 Jun 2003 07:38:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07699; Tue, 17 Jun 2003 07:38:09 -0400 (EDT) Message-Id: <200306171138.HAA07699@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-event-mib-v2-02.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Jun 2003 07:38:09 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Event MIB Author(s) : R. Kavasseri, B. Stewart Filename : draft-ietf-disman-event-mib-v2-02.txt Pages : 56 Date : 2003-6-16 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 that can be used to manage and monitor MIB objects and take action through events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-event-mib-v2-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-event-mib-v2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-event-mib-v2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-event-mib-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-event-mib-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075109.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-admin@ietf.org Tue Jun 17 13:53:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28243 for ; Tue, 17 Jun 2003 13:53:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBd2a20240; Tue, 17 Jun 2003 07:39:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBcFm20193 for ; Tue, 17 Jun 2003 07:38:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07716; Tue, 17 Jun 2003 07:38:14 -0400 (EDT) Message-Id: <200306171138.HAA07716@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-notif-log-mib-v2-01.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Jun 2003 07:38:13 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Notification Log MIB Author(s) : R. Kavasseri, B. Stewart Filename : draft-ietf-disman-notif-log-mib-v2-01.txt Pages : 31 Date : 2003-6-16 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 Simple Network Management Protocol (SNMP) Notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-notif-log-mib-v2-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-notif-log-mib-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-notif-log-mib-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-notif-log-mib-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-notif-log-mib-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075118.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-admin@ietf.org Tue Jun 17 13:58:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28504 for ; Tue, 17 Jun 2003 13:58:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBd1a20222; Tue, 17 Jun 2003 07:39:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBc5m20167 for ; Tue, 17 Jun 2003 07:38:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07683; Tue, 17 Jun 2003 07:38:04 -0400 (EDT) Message-Id: <200306171138.HAA07683@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-express-mib-v2-02.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Jun 2003 07:38:04 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Distributed Management Expression MIB Author(s) : R. Kavasseri, B. Stewart Filename : draft-ietf-disman-express-mib-v2-02.txt Pages : 50 Date : 2003-6-16 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 managing expressions of MIB objects. The results of these expressions become MIB objects usable like any other MIB object, such as for the test condition for declaring an event. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-express-mib-v2-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-express-mib-v2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-express-mib-v2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-express-mib-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-express-mib-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075057.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Jun 17 14:15:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29832 for ; Tue, 17 Jun 2003 14:15:53 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFOA12579 for disman-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKcs-0001IA-Cx for disman-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:52:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28115 for ; Tue, 17 Jun 2003 13:52:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKac-0002CZ-00 for disman-web-archive@ietf.org; Tue, 17 Jun 2003 13:49:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKac-0002CV-00 for disman-web-archive@ietf.org; Tue, 17 Jun 2003 13:49:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBd1a20232; Tue, 17 Jun 2003 07:39:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBcAm20189 for ; Tue, 17 Jun 2003 07:38:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07699; Tue, 17 Jun 2003 07:38:09 -0400 (EDT) Message-Id: <200306171138.HAA07699@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-event-mib-v2-02.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Jun 2003 07:38:09 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Event MIB Author(s) : R. Kavasseri, B. Stewart Filename : draft-ietf-disman-event-mib-v2-02.txt Pages : 56 Date : 2003-6-16 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 that can be used to manage and monitor MIB objects and take action through events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-event-mib-v2-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-event-mib-v2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-event-mib-v2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-event-mib-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-event-mib-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075109.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Jun 17 14:15:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29861 for ; Tue, 17 Jun 2003 14:15:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFPi12696 for disman-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKhw-0001fq-BG for disman-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:57:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28423 for ; Tue, 17 Jun 2003 13:57:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKfg-0002Hi-00 for disman-web-archive@ietf.org; Tue, 17 Jun 2003 13:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKff-0002Hf-00 for disman-web-archive@ietf.org; Tue, 17 Jun 2003 13:55:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBd1a20222; Tue, 17 Jun 2003 07:39:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBc5m20167 for ; Tue, 17 Jun 2003 07:38:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07683; Tue, 17 Jun 2003 07:38:04 -0400 (EDT) Message-Id: <200306171138.HAA07683@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-express-mib-v2-02.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Jun 2003 07:38:04 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Distributed Management Expression MIB Author(s) : R. Kavasseri, B. Stewart Filename : draft-ietf-disman-express-mib-v2-02.txt Pages : 50 Date : 2003-6-16 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 managing expressions of MIB objects. The results of these expressions become MIB objects usable like any other MIB object, such as for the test condition for declaring an event. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-express-mib-v2-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-express-mib-v2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-express-mib-v2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-express-mib-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-express-mib-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075057.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Jun 17 14:15:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29859 for ; Tue, 17 Jun 2003 14:15:54 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIFOg12647 for disman-archive@odin.ietf.org; Tue, 17 Jun 2003 14:15:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKdw-0001NX-Ah for disman-web-archive@optimus.ietf.org; Tue, 17 Jun 2003 13:53:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28218 for ; Tue, 17 Jun 2003 13:53:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SKbg-0002E1-00 for disman-web-archive@ietf.org; Tue, 17 Jun 2003 13:50:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SKbg-0002Dy-00 for disman-web-archive@ietf.org; Tue, 17 Jun 2003 13:50:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBd2a20240; Tue, 17 Jun 2003 07:39:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5HBcFm20193 for ; Tue, 17 Jun 2003 07:38:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07716; Tue, 17 Jun 2003 07:38:14 -0400 (EDT) Message-Id: <200306171138.HAA07716@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-notif-log-mib-v2-01.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 17 Jun 2003 07:38:13 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Notification Log MIB Author(s) : R. Kavasseri, B. Stewart Filename : draft-ietf-disman-notif-log-mib-v2-01.txt Pages : 31 Date : 2003-6-16 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 Simple Network Management Protocol (SNMP) Notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-notif-log-mib-v2-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-notif-log-mib-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-notif-log-mib-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-notif-log-mib-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-notif-log-mib-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075118.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-admin@ietf.org Wed Jun 18 04:34:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24098 for ; Wed, 18 Jun 2003 04:34:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYOH-00068Z-F6; Wed, 18 Jun 2003 04:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYOC-00068O-0g for disman@optimus.ietf.org; Wed, 18 Jun 2003 04:33:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23974 for ; Wed, 18 Jun 2003 04:33:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SYLw-0001Lp-00 for disman@ietf.org; Wed, 18 Jun 2003 04:31:36 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19SYLv-0001KK-00 for disman@ietf.org; Wed, 18 Jun 2003 04:31:35 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5I8XIVI050673; Wed, 18 Jun 2003 10:33:19 +0200 (CEST) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 75AEBADF01; Wed, 18 Jun 2003 10:19:03 +0200 (CEST) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] RFC 2595: pingCtlDataSize Message-ID: <122065721.1055932542@[10.1.1.128]> In-Reply-To: <001701c2f3c7$dfae9fc0$7f1afea9@oemcomputer> References: <001701c2f3c7$dfae9fc0$7f1afea9@oemcomputer> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 18 Jun 2003 10:35:42 +0200 Content-Transfer-Encoding: 7bit Hi Randy, -- Randy Presuhn wrote on 26 March 2003 10:45 -0800: > Hi - > > This is action item #10 from the minutes of our session in > San Francisco. > > Currently, RFC 2925 says: > pingCtlDataSize OBJECT-TYPE > SYNTAX Unsigned32 (0..65507) > UNITS "octets" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Specifies the size of the data portion to be > transmitted in a ping operation in octets. A ping > request is usually an ICMP message encoded > into an IP packet. An IP packet has a maximum size > of 65535 octets. Subtracting the size of the ICMP > or UDP header (both 8 octets) and the size of the IP > header (20 octets) yields a maximum size of 65507 > octets." > DEFVAL { 0 } > ::= { pingCtlEntry 5 } > > This has caused some concern that the MIB isn't right for > IPv6. As a technical contributor, I'd like to propose the > following as a clarification, and would selcome feedback, > especially from those who have implemented this in IPv6 > environments: > > DESCRIPTION > "Specifies the size of the data portion to be > transmitted in a ping operation in octets. A ping > request is usually an ICMP message encoded > into an IP packet. An IPv4 packet has a maximum size > of 65535 octets. Subtracting the size of the ICMP > or UDP header (both 8 octets) and the size of the IP > header (20 octets) yields a maximum size of 65507 > octets for IPv4 environments. If the protocol > implied by the value of pingCtlTargetAddressType > further limits the size of the data portion, the > data is silently truncated to meet those constraints, > without affecting the value reported by this object." Your phrasing is still focussed on IPv4. What about the following? DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping operation in octets. Whether or not this value can be applied depends on the selected implementation method for performing a ping operation indicated by pingCtlType in the same conceptual row. If the used method allows to apply the value contained in this object, than it MUST be applied. Otherwise, other data sizes can be chosen for the ping request. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." Cheers, Juergen > > Again, since I haven't implemented this, I'd really welcome > feedback on this proposal from those who have. > > Randy Presuhn > > > > > From exim@www1.ietf.org Wed Jun 18 04:34:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24113 for ; Wed, 18 Jun 2003 04:34:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I8YF723632 for disman-archive@odin.ietf.org; Wed, 18 Jun 2003 04:34:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYOV-000695-M2 for disman-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 04:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24020 for ; Wed, 18 Jun 2003 04:34:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SYMF-0001MN-00 for disman-web-archive@ietf.org; Wed, 18 Jun 2003 04:31:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19SYMF-0001MK-00 for disman-web-archive@ietf.org; Wed, 18 Jun 2003 04:31:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYOH-00068Z-F6; Wed, 18 Jun 2003 04:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SYOC-00068O-0g for disman@optimus.ietf.org; Wed, 18 Jun 2003 04:33:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23974 for ; Wed, 18 Jun 2003 04:33:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SYLw-0001Lp-00 for disman@ietf.org; Wed, 18 Jun 2003 04:31:36 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19SYLv-0001KK-00 for disman@ietf.org; Wed, 18 Jun 2003 04:31:35 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5I8XIVI050673; Wed, 18 Jun 2003 10:33:19 +0200 (CEST) Received: from [10.1.1.128] (n-quittek.office [10.1.1.128]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 75AEBADF01; Wed, 18 Jun 2003 10:19:03 +0200 (CEST) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] RFC 2595: pingCtlDataSize Message-ID: <122065721.1055932542@[10.1.1.128]> In-Reply-To: <001701c2f3c7$dfae9fc0$7f1afea9@oemcomputer> References: <001701c2f3c7$dfae9fc0$7f1afea9@oemcomputer> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 18 Jun 2003 10:35:42 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Randy, -- Randy Presuhn wrote on 26 March 2003 10:45 -0800: > Hi - > > This is action item #10 from the minutes of our session in > San Francisco. > > Currently, RFC 2925 says: > pingCtlDataSize OBJECT-TYPE > SYNTAX Unsigned32 (0..65507) > UNITS "octets" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Specifies the size of the data portion to be > transmitted in a ping operation in octets. A ping > request is usually an ICMP message encoded > into an IP packet. An IP packet has a maximum size > of 65535 octets. Subtracting the size of the ICMP > or UDP header (both 8 octets) and the size of the IP > header (20 octets) yields a maximum size of 65507 > octets." > DEFVAL { 0 } > ::= { pingCtlEntry 5 } > > This has caused some concern that the MIB isn't right for > IPv6. As a technical contributor, I'd like to propose the > following as a clarification, and would selcome feedback, > especially from those who have implemented this in IPv6 > environments: > > DESCRIPTION > "Specifies the size of the data portion to be > transmitted in a ping operation in octets. A ping > request is usually an ICMP message encoded > into an IP packet. An IPv4 packet has a maximum size > of 65535 octets. Subtracting the size of the ICMP > or UDP header (both 8 octets) and the size of the IP > header (20 octets) yields a maximum size of 65507 > octets for IPv4 environments. If the protocol > implied by the value of pingCtlTargetAddressType > further limits the size of the data portion, the > data is silently truncated to meet those constraints, > without affecting the value reported by this object." Your phrasing is still focussed on IPv4. What about the following? DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping operation in octets. Whether or not this value can be applied depends on the selected implementation method for performing a ping operation indicated by pingCtlType in the same conceptual row. If the used method allows to apply the value contained in this object, than it MUST be applied. Otherwise, other data sizes can be chosen for the ping request. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." Cheers, Juergen > > Again, since I haven't implemented this, I'd really welcome > feedback on this proposal from those who have. > > Randy Presuhn > > > > > From disman-admin@ietf.org Thu Jun 19 13:19:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02268 for ; Thu, 19 Jun 2003 13:19:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T33t-00077S-1m; Thu, 19 Jun 2003 13:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T33g-000779-FU for disman@optimus.ietf.org; Thu, 19 Jun 2003 13:18:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02225 for ; Thu, 19 Jun 2003 13:18:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T31N-0007TY-00 for disman@ietf.org; Thu, 19 Jun 2003 13:16:25 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 19T31N-0007TU-00 for disman@ietf.org; Thu, 19 Jun 2003 13:16:25 -0400 Received: from h-68-165-65-107.snvacaid.covad.net ([68.165.65.107] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19T33d-0006WD-00 for disman@ietf.org; Thu, 19 Jun 2003 10:18:45 -0700 Message-ID: <025901c33685$f2904fc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <001701c2f3c7$dfae9fc0$7f1afea9@oemcomputer> <122065721.1055932542@[10.1.1.128]> Subject: Re: [Disman] RFC 2595: pingCtlDataSize X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 10:12:22 -0700 Hi - > From: "Juergen Quittek" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, June 18, 2003 1:35 AM > Subject: Re: [Disman] RFC 2595: pingCtlDataSize ... > Your phrasing is still focussed on IPv4. What about the following? > > DESCRIPTION > "Specifies the size of the data portion to be > transmitted in a ping operation in octets. Whether or > not this value can be applied depends on the selected > implementation method for performing a ping operation > indicated by pingCtlType in the same conceptual row. > If the used method allows to apply the value contained > in this object, than it MUST be applied. Otherwise, > other data sizes can be chosen for the ping request. I think the sentence beginning with "otherwise" is too vague. It's not clear who would do the chosing of those "other data sizes." Perhaps we could say something like If the specified size is not appropriate for the chosen ping method, the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. > The maximum value for this object was computed by > substracting the smallest possible IP header size of > 20 octets (IPv4 header with no options) and the UDP > header size of 8 octets from the maximum IP packet size. > An IP packet has a maximum size of 65535 octets > (excluding IPv6 Jumbograms)." ... I have no problem with this. Others? Randy From exim@www1.ietf.org Thu Jun 19 13:19:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02283 for ; Thu, 19 Jun 2003 13:19:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHJ4O27414 for disman-archive@odin.ietf.org; Thu, 19 Jun 2003 13:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T33w-000785-8i for disman-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:19:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02243 for ; Thu, 19 Jun 2003 13:19:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T31d-0007Tv-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 13:16:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T31c-0007Tr-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 13:16:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T33t-00077S-1m; Thu, 19 Jun 2003 13:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T33g-000779-FU for disman@optimus.ietf.org; Thu, 19 Jun 2003 13:18:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02225 for ; Thu, 19 Jun 2003 13:18:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T31N-0007TY-00 for disman@ietf.org; Thu, 19 Jun 2003 13:16:25 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 19T31N-0007TU-00 for disman@ietf.org; Thu, 19 Jun 2003 13:16:25 -0400 Received: from h-68-165-65-107.snvacaid.covad.net ([68.165.65.107] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19T33d-0006WD-00 for disman@ietf.org; Thu, 19 Jun 2003 10:18:45 -0700 Message-ID: <025901c33685$f2904fc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <001701c2f3c7$dfae9fc0$7f1afea9@oemcomputer> <122065721.1055932542@[10.1.1.128]> Subject: Re: [Disman] RFC 2595: pingCtlDataSize X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 10:12:22 -0700 Hi - > From: "Juergen Quittek" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, June 18, 2003 1:35 AM > Subject: Re: [Disman] RFC 2595: pingCtlDataSize ... > Your phrasing is still focussed on IPv4. What about the following? > > DESCRIPTION > "Specifies the size of the data portion to be > transmitted in a ping operation in octets. Whether or > not this value can be applied depends on the selected > implementation method for performing a ping operation > indicated by pingCtlType in the same conceptual row. > If the used method allows to apply the value contained > in this object, than it MUST be applied. Otherwise, > other data sizes can be chosen for the ping request. I think the sentence beginning with "otherwise" is too vague. It's not clear who would do the chosing of those "other data sizes." Perhaps we could say something like If the specified size is not appropriate for the chosen ping method, the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. > The maximum value for this object was computed by > substracting the smallest possible IP header size of > 20 octets (IPv4 header with no options) and the UDP > header size of 8 octets from the maximum IP packet size. > An IP packet has a maximum size of 65535 octets > (excluding IPv6 Jumbograms)." ... I have no problem with this. Others? Randy From disman-admin@ietf.org Thu Jun 19 13:38:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03812 for ; Thu, 19 Jun 2003 13:38:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3MG-0000SW-JZ; Thu, 19 Jun 2003 13:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3MC-0000Rw-P3 for disman@optimus.ietf.org; Thu, 19 Jun 2003 13:37:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03724 for ; Thu, 19 Jun 2003 13:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Jt-00002Q-00 for disman@ietf.org; Thu, 19 Jun 2003 13:35:33 -0400 Received: from fed1mtao06.cox.net ([68.6.19.125]) by ietf-mx with esmtp (Exim 4.12) id 19T3Js-000015-00 for disman@ietf.org; Thu, 19 Jun 2003 13:35:32 -0400 Received: from francisco ([68.6.35.7]) by fed1mtao06.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20030619173720.CVCY3273.fed1mtao06.cox.net@francisco> for ; Thu, 19 Jun 2003 13:37:20 -0400 Reply-To: From: "Dale Francisco" To: "Disman \(E-mail\)" Subject: RE: [Disman] RFC 2595: pingCtlDataSize Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <025901c33685$f2904fc0$7f1afea9@oemcomputer> Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 10:41:11 -0700 Content-Transfer-Encoding: 7bit A stylistic quibble: How about replacing this sentence > If the used method allows to apply the value contained ^^^^^^^^^^^ ^^^^^^^^ > in this object, than it MUST be applied. ^^^^ with this one: If the method used allows applying the value contained in this object, then it MUST be applied. From exim@www1.ietf.org Thu Jun 19 13:38:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03827 for ; Thu, 19 Jun 2003 13:38:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHc2m01804 for disman-archive@odin.ietf.org; Thu, 19 Jun 2003 13:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3MI-0000T1-4l for disman-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:38:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03737 for ; Thu, 19 Jun 2003 13:37:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Jz-00002q-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 13:35:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3Jy-00002n-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 13:35:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3MG-0000SW-JZ; Thu, 19 Jun 2003 13:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3MC-0000Rw-P3 for disman@optimus.ietf.org; Thu, 19 Jun 2003 13:37:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03724 for ; Thu, 19 Jun 2003 13:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Jt-00002Q-00 for disman@ietf.org; Thu, 19 Jun 2003 13:35:33 -0400 Received: from fed1mtao06.cox.net ([68.6.19.125]) by ietf-mx with esmtp (Exim 4.12) id 19T3Js-000015-00 for disman@ietf.org; Thu, 19 Jun 2003 13:35:32 -0400 Received: from francisco ([68.6.35.7]) by fed1mtao06.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20030619173720.CVCY3273.fed1mtao06.cox.net@francisco> for ; Thu, 19 Jun 2003 13:37:20 -0400 Reply-To: From: "Dale Francisco" To: "Disman \(E-mail\)" Subject: RE: [Disman] RFC 2595: pingCtlDataSize Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <025901c33685$f2904fc0$7f1afea9@oemcomputer> Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 10:41:11 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A stylistic quibble: How about replacing this sentence > If the used method allows to apply the value contained ^^^^^^^^^^^ ^^^^^^^^ > in this object, than it MUST be applied. ^^^^ with this one: If the method used allows applying the value contained in this object, then it MUST be applied. From disman-admin@ietf.org Thu Jun 19 13:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04066 for ; Thu, 19 Jun 2003 13:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3PD-0000cy-EB; Thu, 19 Jun 2003 13:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3P9-0000cH-BR for disman@optimus.ietf.org; Thu, 19 Jun 2003 13:40:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03983 for ; Thu, 19 Jun 2003 13:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Mq-000075-00 for disman@ietf.org; Thu, 19 Jun 2003 13:38:36 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 19T3Mp-00006z-00 for disman@ietf.org; Thu, 19 Jun 2003 13:38:35 -0400 Received: from h-68-165-65-107.snvacaid.covad.net ([68.165.65.107] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19T3P4-0002gx-00 for disman@ietf.org; Thu, 19 Jun 2003 10:40:54 -0700 Message-ID: <029701c33689$00d6c340$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Disman in Vienna? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 10:34:14 -0700 Hi - I have not heard from anyone saying that the disman WG should meet in Vienna. The WG scheduling cut-off is tomorrow, so if you think we need to meet, please post to this list without delay. Randy From exim@www1.ietf.org Thu Jun 19 13:41:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04085 for ; Thu, 19 Jun 2003 13:41:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHf4D02562 for disman-archive@odin.ietf.org; Thu, 19 Jun 2003 13:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3PE-0000fF-QQ for disman-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:41:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04008 for ; Thu, 19 Jun 2003 13:41:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Mv-00007j-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 13:38:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3Mv-00007f-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 13:38:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3PD-0000cy-EB; Thu, 19 Jun 2003 13:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3P9-0000cH-BR for disman@optimus.ietf.org; Thu, 19 Jun 2003 13:40:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03983 for ; Thu, 19 Jun 2003 13:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Mq-000075-00 for disman@ietf.org; Thu, 19 Jun 2003 13:38:36 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 19T3Mp-00006z-00 for disman@ietf.org; Thu, 19 Jun 2003 13:38:35 -0400 Received: from h-68-165-65-107.snvacaid.covad.net ([68.165.65.107] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19T3P4-0002gx-00 for disman@ietf.org; Thu, 19 Jun 2003 10:40:54 -0700 Message-ID: <029701c33689$00d6c340$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Disman in Vienna? Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 10:34:14 -0700 Hi - I have not heard from anyone saying that the disman WG should meet in Vienna. The WG scheduling cut-off is tomorrow, so if you think we need to meet, please post to this list without delay. Randy From disman-admin@ietf.org Thu Jun 19 13:44:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04245 for ; Thu, 19 Jun 2003 13:44:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3S5-0000y5-Au; Thu, 19 Jun 2003 13:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3S0-0000xQ-Hi for disman@optimus.ietf.org; Thu, 19 Jun 2003 13:43:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04234 for ; Thu, 19 Jun 2003 13:43:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Ph-0000Am-00 for disman@ietf.org; Thu, 19 Jun 2003 13:41:33 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 19T3Pg-0000Aj-00 for disman@ietf.org; Thu, 19 Jun 2003 13:41:32 -0400 Received: from h-68-165-65-107.snvacaid.covad.net ([68.165.65.107] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19T3Rx-0007IK-00 for disman@ietf.org; Thu, 19 Jun 2003 10:43:53 -0700 Message-ID: <029c01c33689$6a290b00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] RFC 2595: pingCtlDataSize X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 10:37:11 -0700 Hi - > From: "Dale Francisco" > To: "Disman (E-mail)" > Sent: Thursday, June 19, 2003 10:41 AM > Subject: RE: [Disman] RFC 2595: pingCtlDataSize > > A stylistic quibble: How about replacing > this sentence > > > If the used method allows to apply the value contained > ^^^^^^^^^^^ ^^^^^^^^ > > in this object, than it MUST be applied. > ^^^^ > > with this one: > > If the method used allows applying the value contained > in this object, then it MUST be applied. > Looks good to me. My only concern (and this might be over-engineering) is that it needs to be clear is that the limitation needs to be inherent to the ping method, and not not just an implementor's whims. Randy From exim@www1.ietf.org Thu Jun 19 13:44:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04260 for ; Thu, 19 Jun 2003 13:44:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHi2A03761 for disman-archive@odin.ietf.org; Thu, 19 Jun 2003 13:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3S6-0000ya-JD for disman-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:44:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04238 for ; Thu, 19 Jun 2003 13:44:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Pn-0000As-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 13:41:39 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3Pm-0000Ap-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 13:41:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3S5-0000y5-Au; Thu, 19 Jun 2003 13:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3S0-0000xQ-Hi for disman@optimus.ietf.org; Thu, 19 Jun 2003 13:43:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04234 for ; Thu, 19 Jun 2003 13:43:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3Ph-0000Am-00 for disman@ietf.org; Thu, 19 Jun 2003 13:41:33 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 19T3Pg-0000Aj-00 for disman@ietf.org; Thu, 19 Jun 2003 13:41:32 -0400 Received: from h-68-165-65-107.snvacaid.covad.net ([68.165.65.107] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19T3Rx-0007IK-00 for disman@ietf.org; Thu, 19 Jun 2003 10:43:53 -0700 Message-ID: <029c01c33689$6a290b00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] RFC 2595: pingCtlDataSize X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 10:37:11 -0700 Hi - > From: "Dale Francisco" > To: "Disman (E-mail)" > Sent: Thursday, June 19, 2003 10:41 AM > Subject: RE: [Disman] RFC 2595: pingCtlDataSize > > A stylistic quibble: How about replacing > this sentence > > > If the used method allows to apply the value contained > ^^^^^^^^^^^ ^^^^^^^^ > > in this object, than it MUST be applied. > ^^^^ > > with this one: > > If the method used allows applying the value contained > in this object, then it MUST be applied. > Looks good to me. My only concern (and this might be over-engineering) is that it needs to be clear is that the limitation needs to be inherent to the ping method, and not not just an implementor's whims. Randy From disman-admin@ietf.org Thu Jun 19 13:59:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05214 for ; Thu, 19 Jun 2003 13:59:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3gb-00025j-7z; Thu, 19 Jun 2003 13:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3gT-00025Y-1m for disman@optimus.ietf.org; Thu, 19 Jun 2003 13:58:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05172 for ; Thu, 19 Jun 2003 13:58:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3e9-0000Ps-00 for disman@ietf.org; Thu, 19 Jun 2003 13:56:30 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19T3e9-0000Pc-00 for disman@ietf.org; Thu, 19 Jun 2003 13:56:29 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5JHwTVI016760; Thu, 19 Jun 2003 19:58:29 +0200 (CEST) Received: from [10.1.1.28] (dial04.office [10.1.1.28]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6726FAF078; Thu, 19 Jun 2003 19:43:49 +0200 (CEST) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] RFC 2595: pingCtlDataSize Message-ID: <242365242.1056052842@[10.1.1.28]> In-Reply-To: <025901c33685$f2904fc0$7f1afea9@oemcomputer> References: <025901c33685$f2904fc0$7f1afea9@oemcomputer> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 20:00:43 +0200 Content-Transfer-Encoding: 7bit Randy, -- Randy Presuhn wrote on 19 June 2003 10:12 -0700: > Hi - > >> From: "Juergen Quittek" >> To: "Randy Presuhn" ; "Disman (E-mail)" >> Sent: Wednesday, June 18, 2003 1:35 AM >> Subject: Re: [Disman] RFC 2595: pingCtlDataSize > ... >> Your phrasing is still focussed on IPv4. What about the following? >> >> DESCRIPTION >> "Specifies the size of the data portion to be >> transmitted in a ping operation in octets. Whether or >> not this value can be applied depends on the selected >> implementation method for performing a ping operation >> indicated by pingCtlType in the same conceptual row. >> If the used method allows to apply the value contained >> in this object, than it MUST be applied. Otherwise, >> other data sizes can be chosen for the ping request. > > I think the sentence beginning with "otherwise" is too vague. > It's not clear who would do the chosing of those "other data > sizes." Perhaps we could say something like > > If the specified size is not appropriate for the chosen ping > method, the implementation SHOULD use whatever > size (appropriate to the method) is closest to the specified size. I agree. This wording is stronger, because it recommends to take the closest sizes. Juergen > >> The maximum value for this object was computed by >> substracting the smallest possible IP header size of >> 20 octets (IPv4 header with no options) and the UDP >> header size of 8 octets from the maximum IP packet size. >> An IP packet has a maximum size of 65535 octets >> (excluding IPv6 Jumbograms)." > ... > > I have no problem with this. Others? > > Randy > > > From exim@www1.ietf.org Thu Jun 19 13:59:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05229 for ; Thu, 19 Jun 2003 13:59:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JHx4A08138 for disman-archive@odin.ietf.org; Thu, 19 Jun 2003 13:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3ge-00027B-Qv for disman-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 13:59:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05189 for ; Thu, 19 Jun 2003 13:59:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3eL-0000QM-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 13:56:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3eL-0000QJ-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 13:56:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3gb-00025j-7z; Thu, 19 Jun 2003 13:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3gT-00025Y-1m for disman@optimus.ietf.org; Thu, 19 Jun 2003 13:58:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05172 for ; Thu, 19 Jun 2003 13:58:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3e9-0000Ps-00 for disman@ietf.org; Thu, 19 Jun 2003 13:56:30 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19T3e9-0000Pc-00 for disman@ietf.org; Thu, 19 Jun 2003 13:56:29 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5JHwTVI016760; Thu, 19 Jun 2003 19:58:29 +0200 (CEST) Received: from [10.1.1.28] (dial04.office [10.1.1.28]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6726FAF078; Thu, 19 Jun 2003 19:43:49 +0200 (CEST) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] RFC 2595: pingCtlDataSize Message-ID: <242365242.1056052842@[10.1.1.28]> In-Reply-To: <025901c33685$f2904fc0$7f1afea9@oemcomputer> References: <025901c33685$f2904fc0$7f1afea9@oemcomputer> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 20:00:43 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randy, -- Randy Presuhn wrote on 19 June 2003 10:12 -0700: > Hi - > >> From: "Juergen Quittek" >> To: "Randy Presuhn" ; "Disman (E-mail)" >> Sent: Wednesday, June 18, 2003 1:35 AM >> Subject: Re: [Disman] RFC 2595: pingCtlDataSize > ... >> Your phrasing is still focussed on IPv4. What about the following? >> >> DESCRIPTION >> "Specifies the size of the data portion to be >> transmitted in a ping operation in octets. Whether or >> not this value can be applied depends on the selected >> implementation method for performing a ping operation >> indicated by pingCtlType in the same conceptual row. >> If the used method allows to apply the value contained >> in this object, than it MUST be applied. Otherwise, >> other data sizes can be chosen for the ping request. > > I think the sentence beginning with "otherwise" is too vague. > It's not clear who would do the chosing of those "other data > sizes." Perhaps we could say something like > > If the specified size is not appropriate for the chosen ping > method, the implementation SHOULD use whatever > size (appropriate to the method) is closest to the specified size. I agree. This wording is stronger, because it recommends to take the closest sizes. Juergen > >> The maximum value for this object was computed by >> substracting the smallest possible IP header size of >> 20 octets (IPv4 header with no options) and the UDP >> header size of 8 octets from the maximum IP packet size. >> An IP packet has a maximum size of 65535 octets >> (excluding IPv6 Jumbograms)." > ... > > I have no problem with this. Others? > > Randy > > > From disman-admin@ietf.org Thu Jun 19 14:04:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05689 for ; Thu, 19 Jun 2003 14:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3lQ-0002R1-UZ; Thu, 19 Jun 2003 14:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3kv-0002Ql-SB for disman@optimus.ietf.org; Thu, 19 Jun 2003 14:03:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05580 for ; Thu, 19 Jun 2003 14:03:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3ic-0000WA-00 for disman@ietf.org; Thu, 19 Jun 2003 14:01:06 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19T3ib-0000Vo-00 for disman@ietf.org; Thu, 19 Jun 2003 14:01:06 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5JI36VI016813; Thu, 19 Jun 2003 20:03:06 +0200 (CEST) Received: from [10.1.1.28] (dial04.office [10.1.1.28]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C2942AF08C; Thu, 19 Jun 2003 19:48:25 +0200 (CEST) From: Juergen Quittek To: "-- Randy Presuhn wrote on 19 June 2003 10:12 -0700:"@ccrle.nec.de, "> If the specified size is not appropriate for the chosen ping"@ccrle.nec.de, "> method"@ccrle.nec.de, "the implementation SHOULD use whatever"@ccrle.nec.de, "> size (appropriate to the method) is closest to the specified size."@ccrle.nec.de, Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] RFC 2595: pingCtlDataSize Message-ID: <242641780.1056053118@[10.1.1.28]> In-Reply-To: <029c01c33689$6a290b00$7f1afea9@oemcomputer> References: <029c01c33689$6a290b00$7f1afea9@oemcomputer> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 20:05:19 +0200 Content-Transfer-Encoding: 7bit Randy, -- Randy Presuhn wrote on 19 June 2003 10:37 -0700: > Hi - > >> From: "Dale Francisco" >> To: "Disman (E-mail)" >> Sent: Thursday, June 19, 2003 10:41 AM >> Subject: RE: [Disman] RFC 2595: pingCtlDataSize >> > >> A stylistic quibble: How about replacing >> this sentence >> >> > If the used method allows to apply the value contained >> ^^^^^^^^^^^ ^^^^^^^^ >> > in this object, than it MUST be applied. >> ^^^^ >> >> with this one: >> >> If the method used allows applying the value contained >> in this object, then it MUST be applied. >> > > Looks good to me. My only concern (and this might be > over-engineering) is that it needs to be clear is that the > limitation needs to be inherent to the ping method, and > not not just an implementor's whims. > > Randy I like Dale's suggestion. I think the wording you suggested for the case that the value cannot be applied makes it (almost completely) clear that a limitation of the method is addressed: -- Randy Presuhn wrote on 19 June 2003 10:12 -0700: > If the specified size is not appropriate for the chosen ping > method, the implementation SHOULD use whatever > size (appropriate to the method) is closest to the specified size. Juergen From exim@www1.ietf.org Thu Jun 19 14:04:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05706 for ; Thu, 19 Jun 2003 14:04:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JI42s09401 for disman-archive@odin.ietf.org; Thu, 19 Jun 2003 14:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3lS-0002RY-2Y for disman-web-archive@optimus.ietf.org; Thu, 19 Jun 2003 14:04:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05619 for ; Thu, 19 Jun 2003 14:03:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3j8-0000XM-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 14:01:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19T3j8-0000XJ-00 for disman-web-archive@ietf.org; Thu, 19 Jun 2003 14:01:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3lQ-0002R1-UZ; Thu, 19 Jun 2003 14:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T3kv-0002Ql-SB for disman@optimus.ietf.org; Thu, 19 Jun 2003 14:03:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05580 for ; Thu, 19 Jun 2003 14:03:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19T3ic-0000WA-00 for disman@ietf.org; Thu, 19 Jun 2003 14:01:06 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19T3ib-0000Vo-00 for disman@ietf.org; Thu, 19 Jun 2003 14:01:06 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5JI36VI016813; Thu, 19 Jun 2003 20:03:06 +0200 (CEST) Received: from [10.1.1.28] (dial04.office [10.1.1.28]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C2942AF08C; Thu, 19 Jun 2003 19:48:25 +0200 (CEST) From: Juergen Quittek To: "-- Randy Presuhn wrote on 19 June 2003 10:12 -0700:"@ccrle.nec.de, "> If the specified size is not appropriate for the chosen ping"@ccrle.nec.de, "> method"@ccrle.nec.de, "the implementation SHOULD use whatever"@ccrle.nec.de, "> size (appropriate to the method) is closest to the specified size."@ccrle.nec.de, Randy Presuhn , "Disman (E-mail)" Subject: Re: [Disman] RFC 2595: pingCtlDataSize Message-ID: <242641780.1056053118@[10.1.1.28]> In-Reply-To: <029c01c33689$6a290b00$7f1afea9@oemcomputer> References: <029c01c33689$6a290b00$7f1afea9@oemcomputer> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 19 Jun 2003 20:05:19 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randy, -- Randy Presuhn wrote on 19 June 2003 10:37 -0700: > Hi - > >> From: "Dale Francisco" >> To: "Disman (E-mail)" >> Sent: Thursday, June 19, 2003 10:41 AM >> Subject: RE: [Disman] RFC 2595: pingCtlDataSize >> > >> A stylistic quibble: How about replacing >> this sentence >> >> > If the used method allows to apply the value contained >> ^^^^^^^^^^^ ^^^^^^^^ >> > in this object, than it MUST be applied. >> ^^^^ >> >> with this one: >> >> If the method used allows applying the value contained >> in this object, then it MUST be applied. >> > > Looks good to me. My only concern (and this might be > over-engineering) is that it needs to be clear is that the > limitation needs to be inherent to the ping method, and > not not just an implementor's whims. > > Randy I like Dale's suggestion. I think the wording you suggested for the case that the value cannot be applied makes it (almost completely) clear that a limitation of the method is addressed: -- Randy Presuhn wrote on 19 June 2003 10:12 -0700: > If the specified size is not appropriate for the chosen ping > method, the implementation SHOULD use whatever > size (appropriate to the method) is closest to the specified size. Juergen From disman-admin@ietf.org Fri Jun 20 14:27:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23128 for ; Fri, 20 Jun 2003 14:27:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQbF-0001SM-9x; Fri, 20 Jun 2003 14:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQai-0001NV-DY for disman@optimus.ietf.org; Fri, 20 Jun 2003 14:26:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22638; Fri, 20 Jun 2003 14:26:25 -0400 (EDT) Message-Id: <200306201826.OAA22638@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-00.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 14:26:24 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Author(s) : J. Quittek, K. White Filename : draft-ietf-disman-remops-mib-v2-00.txt Pages : 74 Date : 2003-6-20 This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-remops-mib-v2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-20140050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-remops-mib-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140050.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Fri Jun 20 14:27:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23151 for ; Fri, 20 Jun 2003 14:27:41 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KIREL06297 for disman-archive@odin.ietf.org; Fri, 20 Jun 2003 14:27:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQbR-0001dU-SE for disman-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 14:27:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22873 for ; Fri, 20 Jun 2003 14:27:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TQbO-00000B-00 for disman-web-archive@ietf.org; Fri, 20 Jun 2003 14:27:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TQbO-000007-00 for disman-web-archive@ietf.org; Fri, 20 Jun 2003 14:27:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQbF-0001SM-9x; Fri, 20 Jun 2003 14:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQai-0001NV-DY for disman@optimus.ietf.org; Fri, 20 Jun 2003 14:26:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22638; Fri, 20 Jun 2003 14:26:25 -0400 (EDT) Message-Id: <200306201826.OAA22638@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: disman@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-00.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 14:26:24 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Author(s) : J. Quittek, K. White Filename : draft-ietf-disman-remops-mib-v2-00.txt Pages : 74 Date : 2003-6-20 This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-remops-mib-v2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-20140050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-remops-mib-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140050.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-admin@ietf.org Fri Jun 20 16:03:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05776 for ; Fri, 20 Jun 2003 16:03:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TS68-0007Bm-TF; Fri, 20 Jun 2003 16:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TS5O-0007BP-JZ for disman@optimus.ietf.org; Fri, 20 Jun 2003 16:02:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05668 for ; Fri, 20 Jun 2003 16:02:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TS5N-0002eO-00 for disman@ietf.org; Fri, 20 Jun 2003 16:02:13 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 19TS5M-0002eK-00 for disman@ietf.org; Fri, 20 Jun 2003 16:02:12 -0400 Received: from h-69-3-243-204.snvacaid.covad.net ([69.3.243.204] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19TS5L-0003t0-00 for disman@ietf.org; Fri, 20 Jun 2003 13:02:12 -0700 Message-ID: <01a101c33765$9bc7e820$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: I-D ACTION:draft-baker-liaisons-00.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 12:53:23 -0700 Hi - Since this working group has worked closely with other organizations, such as ITU-T and the DMTF, I figured you might find this of interest, since it proposes some substantial changes in how liaisons are handled. Please send any feedback you have to the authors. (Don't forget that one of the leftover items from our last meeting is a response to the ITU folk!) Randy > From: > To: > Sent: Friday, June 20, 2003 11:28 AM > Subject: I-D ACTION:draft-baker-liaisons-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Procedure for handling liaison statements from and to > various standards bodies > Author(s) : F. Baker > Filename : draft-baker-liaisons-00.txt > Pages : 19 > Date : 2003-6-20 > > This document describes the procedure for proper handling of incoming > liaison statements from other standards development organizations > (SDOs), consortia, and industry fora, and for generating liaison > statements to be transmitted from IETF/ISOC to other SDOs, consortia > and industry fora. This procedure allows IETF to effectively > collaborate with other organizations in the international standards > community. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-baker-liaisons-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-baker-liaisons-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From exim@www1.ietf.org Fri Jun 20 16:03:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05791 for ; Fri, 20 Jun 2003 16:03:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KK37k27737 for disman-archive@odin.ietf.org; Fri, 20 Jun 2003 16:03:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TS6F-0007DI-Bi for disman-web-archive@optimus.ietf.org; Fri, 20 Jun 2003 16:03:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05742 for ; Fri, 20 Jun 2003 16:03:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TS6E-0002fR-00 for disman-web-archive@ietf.org; Fri, 20 Jun 2003 16:03:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19TS6D-0002fO-00 for disman-web-archive@ietf.org; Fri, 20 Jun 2003 16:03:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TS68-0007Bm-TF; Fri, 20 Jun 2003 16:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TS5O-0007BP-JZ for disman@optimus.ietf.org; Fri, 20 Jun 2003 16:02:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05668 for ; Fri, 20 Jun 2003 16:02:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TS5N-0002eO-00 for disman@ietf.org; Fri, 20 Jun 2003 16:02:13 -0400 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 19TS5M-0002eK-00 for disman@ietf.org; Fri, 20 Jun 2003 16:02:12 -0400 Received: from h-69-3-243-204.snvacaid.covad.net ([69.3.243.204] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19TS5L-0003t0-00 for disman@ietf.org; Fri, 20 Jun 2003 13:02:12 -0700 Message-ID: <01a101c33765$9bc7e820$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: I-D ACTION:draft-baker-liaisons-00.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 20 Jun 2003 12:53:23 -0700 Hi - Since this working group has worked closely with other organizations, such as ITU-T and the DMTF, I figured you might find this of interest, since it proposes some substantial changes in how liaisons are handled. Please send any feedback you have to the authors. (Don't forget that one of the leftover items from our last meeting is a response to the ITU folk!) Randy > From: > To: > Sent: Friday, June 20, 2003 11:28 AM > Subject: I-D ACTION:draft-baker-liaisons-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Procedure for handling liaison statements from and to > various standards bodies > Author(s) : F. Baker > Filename : draft-baker-liaisons-00.txt > Pages : 19 > Date : 2003-6-20 > > This document describes the procedure for proper handling of incoming > liaison statements from other standards development organizations > (SDOs), consortia, and industry fora, and for generating liaison > statements to be transmitted from IETF/ISOC to other SDOs, consortia > and industry fora. This procedure allows IETF to effectively > collaborate with other organizations in the international standards > community. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baker-liaisons-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-baker-liaisons-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-baker-liaisons-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From disman-admin@ietf.org Mon Jun 23 16:01:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08156 for ; Mon, 23 Jun 2003 16:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UXUr-000267-85; Mon, 23 Jun 2003 16:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UXUD-00025T-CZ for disman@optimus.ietf.org; Mon, 23 Jun 2003 16:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08123 for ; Mon, 23 Jun 2003 16:00:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UXUB-0005Lm-00 for disman@ietf.org; Mon, 23 Jun 2003 16:00:19 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19UXTz-0005L7-00 for disman@ietf.org; Mon, 23 Jun 2003 16:00:08 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5NJxXVI086101 for ; Mon, 23 Jun 2003 21:59:34 +0200 (CEST) Received: from [10.1.1.27] (dial03.office [10.1.1.27]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B3091A7CAC for ; Mon, 23 Jun 2003 21:43:25 +0200 (CEST) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1056405502@[10.1.1.27]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Disman] update of RFC 2925 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Jun 2003 21:58:22 +0200 Content-Transfer-Encoding: 7bit I posted an update of RFC 2925 in draft-ietf-disman-remops-mib-v2-00.txt. It addresses all issues that has been raised on the mailing list since publication of the RFC and it addresses some updates required because referenced RFCs were updated themselves. Please see the full list of changes below. I still did not review Section 3 "Structure of the MIBs" ans Section 5 "Security Considerations" as carefully as I would have liked to. Please have a look at the document and send me your comments. I intend to post another version two weeks after the IETF meeting. See you there, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de ########################################################################## ====================================================================== Changes in draft-ietf-disman-remops-mib-v2-00.txt compared to RFC 2925 ====================================================================== ======================================================================== 1. typo in description of pingTestCompleted ======================================================================== Problem Description: ------------------------------------------------------------------------ >From RFC Errata web page Reported by: Randy Presuhn; rpresuhn@dorothy.bmc.com Date: Tue, 26 Mar 2002 15:16:54 -0800 In Section 4.1: "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object is set to testCompletion(4)." Should be: "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object is set to testCompletion(2)." ======================================================================== Suggested solution: ------------------------------------------------------------------------ obvious ======================================================================== Status: solution committed ======================================================================== ======================================================================== 2. description of pingCtlDataSize ignores IPv6 ======================================================================== Problem Description: ------------------------------------------------------------------------ Currently, RFC 2925 says: pingCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping operation in octets. A ping request is usually an ICMP message encoded into an IP packet. An IP packet has a maximum size of 65535 octets. Subtracting the size of the ICMP or UDP header (both 8 octets) and the size of the IP header (20 octets) yields a maximum size of 65507 octets." DEFVAL { 0 } ::= { pingCtlEntry 5 } This has caused some concern that the MIB isn't right for IPv6. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace description by "Specifies the size of the data portion to be transmitted in a ping operation in octets. Whether or not this value can be applied depends on the selected implementation method for performing a ping operation indicated by pingCtlType in the same conceptual row. If the method used allows applying the value contained in this object, then it MUST be applied. If the specified size is not appropriate for the chosen ping method, the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 3. description of traceRouteCtlDataSize ignores IPv6 ======================================================================== Problem Description: ------------------------------------------------------------------------ Currently, RFC 2925 says: traceRouteCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion of a traceroute request in octets. A traceroute request is essentially transmitted by encoding a UDP datagram into a IP packet. So subtracting the size of a UDP header (8 octets) and the size of a IP header (20 octets) yields a maximum of 65507 octets." DEFVAL { 0 } ::= { traceRouteCtlEntry 6 } This has caused some concern that the MIB isn't right for IPv6. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace description by "Specifies the size of the data portion of a traceroute request in octets. If the RECOMMENDED traceroute method (UDP datagrams as probes) is used, then the value contained in this object MUST be applied. If another traceroute method is used for which the specified size is not appropriate, then the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 4. SNMP boilerplate outdated ======================================================================== Problem Description: ------------------------------------------------------------------------ Section 2 on "The Internet-Standard Management Framework" is outdated. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace with new one. This implies an update of the reference section. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 5. References need to be split in normative and informational ones. ======================================================================== Problem Description: ------------------------------------------------------------------------ clear ======================================================================== Suggested solution: ------------------------------------------------------------------------ 7. Normative References [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. 8. Informative References [RFC2119] S. Bradner "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC862] J. Postel "Echo Protocol", STD 20, RFC 862, May 1983. [RFC792] J. Postel "Internet Control Message Protocol", RFC 792, September 1981. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3415] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 6. clarify structure of Section 1 "Introduction" ======================================================================== Problem Description: ------------------------------------------------------------------------ The structure of the introduction would be clearer if subsections were used. ======================================================================== Suggested solution: ------------------------------------------------------------------------ insert subsection headers 1.1. Ping 1.2. Traceroute 1.3. Lookup 1.4. Remote Operations ======================================================================== Status: solution committed ======================================================================== ======================================================================== 7. context of remote operations explanation not clear ======================================================================== Problem Description: ------------------------------------------------------------------------ At the end of Section 1 "Introduction" the remote operations scenario is described. The description starts without explaining the context. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "Consider the following diagram:" by "The MIB modules defined in this document allow a management station to initiate ping, traceroute and lookup operations remotely. The basic scenario is illustrated by the following diagram." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 8. diagram explaining remote operations scenario ======================================================================== Problem Description: ------------------------------------------------------------------------ The diagram at the end of Section 1 "Introduction" +--------------------------------------------------------------------+ | | | Remote ping, traceroute, Actual ping, traceroute, | | +-----+or Lookup op. +------+or Lookup op. +------+ | | |Local|---------------->|Remote|---------------->|Target| | | | Host| | Host | | Host | | | +-----+ +------+ +------+ | | | | | +--------------------------------------------------------------------+ uses "local host" and "remote host". In order to align it with the SNMP management framework, these terms should be replaced by "management station" or "managed node", respectively. also it would increase clarity if the remote initiation of operations was separated from reciving results. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace diagram by +-------+ +-------+ +-------+ | |---------->| | | | | | initiate | |---------->| | | Mgmt. | operation |Managed| perform |Target | |Station| remotely | Node | operation | Host | | | | | | | | |<----------| | | | +-------+ receive +-------+ +-------+ result of operation and update text in following paragraph accordingly. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 9. RFC 2575 (VACM) obsoleted ======================================================================== Problem Description: ------------------------------------------------------------------------ RFC 2575 (VACM) is referenced several times in the document. RFC 2575 has been obsoleted by RFC 3415. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace RFC 2575 by RFC 3415 in text, MIBs and reference sections. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 10. obsoleted RFCs metioned in IPORT sections ======================================================================== Problem Description: ------------------------------------------------------------------------ RFC 2571 imported by DISMAN-PING-MIB is obsoleted by RFC 3411. RFC 2571 imported by DISMAN-TRACEROUTE-MIB is obsoleted by RFC 3411. RFC 2571 imported by DISMAN-NSLOOKUP-MIB is obsoleted by RFC 3411. RFC 2851 imported by DISMAN-PING-MIB is obsoleted by RFC 3291. RFC 2851 imported by DISMAN-TRACEROUTE-MIB is obsoleted by RFC 3291. RFC 2851 imported by DISMAN-NSLOOKUP-MIB is obsoleted by RFC 3291. ======================================================================== Suggested solution: ------------------------------------------------------------------------ The comment in DISMAN-PING-MIB IMPORT section needs to be updated. The comment in DISMAN-TRACEROUTE-MIB IMPORT section needs to be updated. The comment in DISMAN-NSLOOKUP-MIB IMPORT section needs to be updated. The comment in DISMAN-PING-MIB IMPORT section needs to be updated. The comment in DISMAN-TRACEROUTE-MIB IMPORT section needs to be updated. The comment in DISMAN-NSLOOKUP-MIB IMPORT section needs to be updated. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 11. Update contact info in MIB modules ======================================================================== Problem Description: ------------------------------------------------------------------------ So far Kenneth served as contact. Now Juergen edits the docuemnt and takes over. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace Kenneth by Juergen in all three MIB modules. ======================================================================== Status: solution committed ======================================================================== From exim@www1.ietf.org Mon Jun 23 16:01:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08174 for ; Mon, 23 Jun 2003 16:01:42 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NK1Eg08233 for disman-archive@odin.ietf.org; Mon, 23 Jun 2003 16:01:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UXV4-00028i-5n for disman-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 16:01:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08151 for ; Mon, 23 Jun 2003 16:01:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UXV2-0005MK-00 for disman-web-archive@ietf.org; Mon, 23 Jun 2003 16:01:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UXUw-0005MF-00 for disman-web-archive@ietf.org; Mon, 23 Jun 2003 16:01:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UXUr-000267-85; Mon, 23 Jun 2003 16:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UXUD-00025T-CZ for disman@optimus.ietf.org; Mon, 23 Jun 2003 16:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08123 for ; Mon, 23 Jun 2003 16:00:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UXUB-0005Lm-00 for disman@ietf.org; Mon, 23 Jun 2003 16:00:19 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19UXTz-0005L7-00 for disman@ietf.org; Mon, 23 Jun 2003 16:00:08 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h5NJxXVI086101 for ; Mon, 23 Jun 2003 21:59:34 +0200 (CEST) Received: from [10.1.1.27] (dial03.office [10.1.1.27]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B3091A7CAC for ; Mon, 23 Jun 2003 21:43:25 +0200 (CEST) From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1056405502@[10.1.1.27]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Disman] update of RFC 2925 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 23 Jun 2003 21:58:22 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I posted an update of RFC 2925 in draft-ietf-disman-remops-mib-v2-00.txt. It addresses all issues that has been raised on the mailing list since publication of the RFC and it addresses some updates required because referenced RFCs were updated themselves. Please see the full list of changes below. I still did not review Section 3 "Structure of the MIBs" ans Section 5 "Security Considerations" as carefully as I would have liked to. Please have a look at the document and send me your comments. I intend to post another version two weeks after the IETF meeting. See you there, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de ########################################################################## ====================================================================== Changes in draft-ietf-disman-remops-mib-v2-00.txt compared to RFC 2925 ====================================================================== ======================================================================== 1. typo in description of pingTestCompleted ======================================================================== Problem Description: ------------------------------------------------------------------------ >From RFC Errata web page Reported by: Randy Presuhn; rpresuhn@dorothy.bmc.com Date: Tue, 26 Mar 2002 15:16:54 -0800 In Section 4.1: "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object is set to testCompletion(4)." Should be: "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object is set to testCompletion(2)." ======================================================================== Suggested solution: ------------------------------------------------------------------------ obvious ======================================================================== Status: solution committed ======================================================================== ======================================================================== 2. description of pingCtlDataSize ignores IPv6 ======================================================================== Problem Description: ------------------------------------------------------------------------ Currently, RFC 2925 says: pingCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping operation in octets. A ping request is usually an ICMP message encoded into an IP packet. An IP packet has a maximum size of 65535 octets. Subtracting the size of the ICMP or UDP header (both 8 octets) and the size of the IP header (20 octets) yields a maximum size of 65507 octets." DEFVAL { 0 } ::= { pingCtlEntry 5 } This has caused some concern that the MIB isn't right for IPv6. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace description by "Specifies the size of the data portion to be transmitted in a ping operation in octets. Whether or not this value can be applied depends on the selected implementation method for performing a ping operation indicated by pingCtlType in the same conceptual row. If the method used allows applying the value contained in this object, then it MUST be applied. If the specified size is not appropriate for the chosen ping method, the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 3. description of traceRouteCtlDataSize ignores IPv6 ======================================================================== Problem Description: ------------------------------------------------------------------------ Currently, RFC 2925 says: traceRouteCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion of a traceroute request in octets. A traceroute request is essentially transmitted by encoding a UDP datagram into a IP packet. So subtracting the size of a UDP header (8 octets) and the size of a IP header (20 octets) yields a maximum of 65507 octets." DEFVAL { 0 } ::= { traceRouteCtlEntry 6 } This has caused some concern that the MIB isn't right for IPv6. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace description by "Specifies the size of the data portion of a traceroute request in octets. If the RECOMMENDED traceroute method (UDP datagrams as probes) is used, then the value contained in this object MUST be applied. If another traceroute method is used for which the specified size is not appropriate, then the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 4. SNMP boilerplate outdated ======================================================================== Problem Description: ------------------------------------------------------------------------ Section 2 on "The Internet-Standard Management Framework" is outdated. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace with new one. This implies an update of the reference section. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 5. References need to be split in normative and informational ones. ======================================================================== Problem Description: ------------------------------------------------------------------------ clear ======================================================================== Suggested solution: ------------------------------------------------------------------------ 7. Normative References [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. 8. Informative References [RFC2119] S. Bradner "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC862] J. Postel "Echo Protocol", STD 20, RFC 862, May 1983. [RFC792] J. Postel "Internet Control Message Protocol", RFC 792, September 1981. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3415] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 6. clarify structure of Section 1 "Introduction" ======================================================================== Problem Description: ------------------------------------------------------------------------ The structure of the introduction would be clearer if subsections were used. ======================================================================== Suggested solution: ------------------------------------------------------------------------ insert subsection headers 1.1. Ping 1.2. Traceroute 1.3. Lookup 1.4. Remote Operations ======================================================================== Status: solution committed ======================================================================== ======================================================================== 7. context of remote operations explanation not clear ======================================================================== Problem Description: ------------------------------------------------------------------------ At the end of Section 1 "Introduction" the remote operations scenario is described. The description starts without explaining the context. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "Consider the following diagram:" by "The MIB modules defined in this document allow a management station to initiate ping, traceroute and lookup operations remotely. The basic scenario is illustrated by the following diagram." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 8. diagram explaining remote operations scenario ======================================================================== Problem Description: ------------------------------------------------------------------------ The diagram at the end of Section 1 "Introduction" +--------------------------------------------------------------------+ | | | Remote ping, traceroute, Actual ping, traceroute, | | +-----+or Lookup op. +------+or Lookup op. +------+ | | |Local|---------------->|Remote|---------------->|Target| | | | Host| | Host | | Host | | | +-----+ +------+ +------+ | | | | | +--------------------------------------------------------------------+ uses "local host" and "remote host". In order to align it with the SNMP management framework, these terms should be replaced by "management station" or "managed node", respectively. also it would increase clarity if the remote initiation of operations was separated from reciving results. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace diagram by +-------+ +-------+ +-------+ | |---------->| | | | | | initiate | |---------->| | | Mgmt. | operation |Managed| perform |Target | |Station| remotely | Node | operation | Host | | | | | | | | |<----------| | | | +-------+ receive +-------+ +-------+ result of operation and update text in following paragraph accordingly. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 9. RFC 2575 (VACM) obsoleted ======================================================================== Problem Description: ------------------------------------------------------------------------ RFC 2575 (VACM) is referenced several times in the document. RFC 2575 has been obsoleted by RFC 3415. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace RFC 2575 by RFC 3415 in text, MIBs and reference sections. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 10. obsoleted RFCs metioned in IPORT sections ======================================================================== Problem Description: ------------------------------------------------------------------------ RFC 2571 imported by DISMAN-PING-MIB is obsoleted by RFC 3411. RFC 2571 imported by DISMAN-TRACEROUTE-MIB is obsoleted by RFC 3411. RFC 2571 imported by DISMAN-NSLOOKUP-MIB is obsoleted by RFC 3411. RFC 2851 imported by DISMAN-PING-MIB is obsoleted by RFC 3291. RFC 2851 imported by DISMAN-TRACEROUTE-MIB is obsoleted by RFC 3291. RFC 2851 imported by DISMAN-NSLOOKUP-MIB is obsoleted by RFC 3291. ======================================================================== Suggested solution: ------------------------------------------------------------------------ The comment in DISMAN-PING-MIB IMPORT section needs to be updated. The comment in DISMAN-TRACEROUTE-MIB IMPORT section needs to be updated. The comment in DISMAN-NSLOOKUP-MIB IMPORT section needs to be updated. The comment in DISMAN-PING-MIB IMPORT section needs to be updated. The comment in DISMAN-TRACEROUTE-MIB IMPORT section needs to be updated. The comment in DISMAN-NSLOOKUP-MIB IMPORT section needs to be updated. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 11. Update contact info in MIB modules ======================================================================== Problem Description: ------------------------------------------------------------------------ So far Kenneth served as contact. Now Juergen edits the docuemnt and takes over. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace Kenneth by Juergen in all three MIB modules. ======================================================================== Status: solution committed ======================================================================== From disman-admin@ietf.org Wed Jun 25 15:06:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26137 for ; Wed, 25 Jun 2003 15:06:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFai-0002Wi-M6; Wed, 25 Jun 2003 15:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFRD-0001nb-4s for disman@optimus.ietf.org; Wed, 25 Jun 2003 14:59:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25346 for ; Wed, 25 Jun 2003 14:55:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VFQw-0006Ab-00 for disman@ietf.org; Wed, 25 Jun 2003 14:55:54 -0400 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 19VFQC-0006A3-00 for disman@ietf.org; Wed, 25 Jun 2003 14:55:13 -0400 Received: from h-68-164-18-233.snvacaid.covad.net ([68.164.18.233] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19VFN6-0005TP-00; Wed, 25 Jun 2003 11:51:56 -0700 Message-ID: <001801c33b49$fba5bbe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Peter Wery" , , , , , , , , , , , , , , , , Cc: , , , , , , , , , , , "Disman \(E-mail\)" References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Re: SG 15 Representatives at IETF #57 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 11:45:42 -0700 Hi - Thank you for the notification. The disman working group is not scheduled to meet in Vienna. Randy Presuhn, IETF Disman WG chair. > From: "Peter Wery" > To: ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; > Cc: ; ; ; ; ; ; ; ; ; ; > Sent: Wednesday, June 25, 2003 11:46 AM > Subject: SG 15 Representatives at IETF #57 > > Gentlemen, > > in line with the provisions of the 'IETF and ITU-T Collaboration Guidelines' > (RFC 3356, clause 3.2.2), please be advised that the following people plan > to participate (registration fees apply) in your WGs at the upcoming IETF # > 57 (13-18 July 2003, Vienna, Austria): > > - Wesam Alanqar in his role as 'SG 15 Representative to IETF ccamp and ipo' > - Jonathan Sadler in his role as 'SG 15 Representative to IETF gsmp' > - Kam Lam in his role as 'SG 15 Representative to IETF on Transport > Network Management', i.e. > WGs atommib, hubmib, ifmib, disman, snmpv3 > - Steve Trowbridge (Vice-Chairman of SG 15) in his role as Chairman of ITU-T > WP 3/15 (OTN > Structure), i.e. relevant to IETF ccamp, ipo, mpls, ppvpn, tewg and other > sub-IP related activities. > > These SG 15 people may also present Liaison Statements from SG 15 as > appropriate. > > Regards, > > Peter Wery > Chairman ITU-T Study Group 15 > > T: +1 613 763 7603 > F: +1 613 763 2697 > E: wery@nortelnetworks.com > > > > From exim@www1.ietf.org Wed Jun 25 15:08:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26337 for ; Wed, 25 Jun 2003 15:08:21 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5PJ7rB11152 for disman-archive@odin.ietf.org; Wed, 25 Jun 2003 15:07:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFcX-0002tn-Ko for disman-web-archive@optimus.ietf.org; Wed, 25 Jun 2003 15:07:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26078 for ; Wed, 25 Jun 2003 15:06:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VFaz-0006Ml-00 for disman-web-archive@ietf.org; Wed, 25 Jun 2003 15:06:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VFat-0006MJ-00 for disman-web-archive@ietf.org; Wed, 25 Jun 2003 15:06:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFai-0002Wi-M6; Wed, 25 Jun 2003 15:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VFRD-0001nb-4s for disman@optimus.ietf.org; Wed, 25 Jun 2003 14:59:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25346 for ; Wed, 25 Jun 2003 14:55:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VFQw-0006Ab-00 for disman@ietf.org; Wed, 25 Jun 2003 14:55:54 -0400 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 19VFQC-0006A3-00 for disman@ietf.org; Wed, 25 Jun 2003 14:55:13 -0400 Received: from h-68-164-18-233.snvacaid.covad.net ([68.164.18.233] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19VFN6-0005TP-00; Wed, 25 Jun 2003 11:51:56 -0700 Message-ID: <001801c33b49$fba5bbe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Peter Wery" , , , , , , , , , , , , , , , , Cc: , , , , , , , , , , , "Disman \(E-mail\)" References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Re: SG 15 Representatives at IETF #57 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 25 Jun 2003 11:45:42 -0700 Hi - Thank you for the notification. The disman working group is not scheduled to meet in Vienna. Randy Presuhn, IETF Disman WG chair. > From: "Peter Wery" > To: ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; > Cc: ; ; ; ; ; ; ; ; ; ; > Sent: Wednesday, June 25, 2003 11:46 AM > Subject: SG 15 Representatives at IETF #57 > > Gentlemen, > > in line with the provisions of the 'IETF and ITU-T Collaboration Guidelines' > (RFC 3356, clause 3.2.2), please be advised that the following people plan > to participate (registration fees apply) in your WGs at the upcoming IETF # > 57 (13-18 July 2003, Vienna, Austria): > > - Wesam Alanqar in his role as 'SG 15 Representative to IETF ccamp and ipo' > - Jonathan Sadler in his role as 'SG 15 Representative to IETF gsmp' > - Kam Lam in his role as 'SG 15 Representative to IETF on Transport > Network Management', i.e. > WGs atommib, hubmib, ifmib, disman, snmpv3 > - Steve Trowbridge (Vice-Chairman of SG 15) in his role as Chairman of ITU-T > WP 3/15 (OTN > Structure), i.e. relevant to IETF ccamp, ipo, mpls, ppvpn, tewg and other > sub-IP related activities. > > These SG 15 people may also present Liaison Statements from SG 15 as > appropriate. > > Regards, > > Peter Wery > Chairman ITU-T Study Group 15 > > T: +1 613 763 7603 > F: +1 613 763 2697 > E: wery@nortelnetworks.com > > > >