Internet Draft Niraj Gopal Document: draft-niraj-tmt-mib-00.txt Cisco Systems, Inc. Expires December 2002 28 June 2002 MIB Table Modifications Tracking 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 Copyright Notice Copyright (C) The Internet Society (2002). 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 management objects used for tracking the modifications in MIB tables on a system. Table of Contents 1. The SNMP Network Management Framework ....................... 2 2. Overview .................................................... 3 3. Terminology ................................................. 4 4. Relationship with Other MIBs ................................ 4 4.1 Event MIB ................................................ 4 4.2 Distributed Management Expression MIB .................... 5 4.3 SNMP Notifications Target MIB ............................ 6 Internet Draft Expires December 2002 [Page 1] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 5. MIB Table Modifications Tracking MIB Definitions ............ 6 5.1 MIB Sections ............................................. 6 5.1.1 Registration ......................................... 6 5.1.2 Notifications Control ................................ 7 5.1.3 History .............................................. 7 5.2 Definitions .............................................. 7 6. Usage Example ............................................... 26 7. Security Considerations ..................................... 28 8. Author's Address ............................................ 29 9. Acknowledgements ............................................ 29 10. References ................................................. 30 11. Full Copyright Statement ................................... 31 1. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: - An overall architecture, described in RFC 2571 [RFC2571]. - 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 RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in 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]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. - 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 Internet Draft Expires December 2002 [Page 2] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 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 Many NMS applications poll SNMP MIB tables at regular intervals to gather data. The amount of data in some tables could be huge depending upon the configuration of the device e.g. a core router can have thousands of entries in the routing table. A lot of bandwidth is used in transferring this large amount of data from the SNMP agent to the NMS. Often times, the NMS finds out that data in the table has not changed since the last poll. This results in bandwidth and CPU wastage. A possible solution to minimize the bandwidth and CPU wastage, and reduce polling, is to have a MIB that keeps track of all the modifications in the data of MIB tables implemented by the SNMP agent on the device being managed. This memo provides this MIB. Table Modifications Tracking MIB allows an NMS to register for "change monitoring" in the tables it is interested in. This MIB then tracks modifications in the registered MIB tables, allowing the NMS to poll a single table to determine if others need to be polled. This MIB keeps track of all modifications, including adding a new row, deletion of a row, and modification of an object in a row. It can also be configured to send change notifications to an NMS. Thus, by polling this table and/or listening to this MIB's notifications, the NMS can find out the MIB tables that have changed since the last poll and choose to poll only those tables instead of polling all the tables at fixed intervals. Modification and other terms related to this MIB are defined in the Internet Draft Expires December 2002 [Page 3] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 following sections. 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. 3. Terminology Modification A change in the conceptual row of a MIB table. It could be the creation of a new row, deletion of an existing row or modification to an object in an existing row. If a single SNMP Set request, CLI command or an internal process state change caused modifications in multiple objects of a single row, only one modification is assumed to have happened and recorded by this MIB. But if multiple SNMP Set requests, CLI commands or internal process state changes modify different objects in one row, multiple modifications are assumed to have happened and recorded. Registration A way of asking the SNMP command responder to keep track of modifications in a given MIB table. 4. Relationship with Other MIBs 4.1. Event MIB The Table Modifications Tracking MIB complements the Event MIB and does not duplicate it as mentioned below: o The Table modifications tracking MIB allows the NMS to register for modifications in NMS specified MIB tables. The Event MIB only allows the objects to be monitored not tables e.g. if NMS is using a wildcarded object to track row additions/deletions in a table and a few rows don't implement that object i.e. the table is sparse, then NMS will miss the modification messages. Internet Draft Expires December 2002 [Page 4] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 Similarly, if the NMS wants to register for row modifications in a table i.e. the NMS wants to find out changes in any MIB object for all the rows in a table, then it would have to create a row in the Trigger table for each and every MIB object in that table. If a NMS in interested in a large number of tables, this scheme does not scale. o The Table Modifications Tracking MIB provides information about the identity of the user that made the modification. o The Table Modifications Tracking MIB provides information about the type of modification that happened i.e. row Modification, rowAddition or rowDeletion. o It provides information about the modification time. o The Table Modifications Tracking MIB provides a count of modifications in each MIB table registered by each NMS. o The Table modifications tracking MIB keeps a history of the modifications made to the registered MIB tables. o The Event MIB can be used to set up an existence test on the history tables of Table Modification Tracking MIB so that the NMS does not have to poll these tables to find modifications in the MIB tables registered with the Table Modifications Tracking MIB. The Event MIB notifications could be used instead. o The Table modification tracking MIB is mainly meant for tracking modifications in the configuration data of the system while Event MIB is generally used for other purposes e.g. monitoring threshold hits on selected objects. The implementation of Table Modifications Tracking MIB can reuse some Event MIB code for overlapping functions. 4.2. Distributed Management Expression MIB The Table Modifications Tracking MIB can track any modifications in the expValueTable, a table of values from evaluated expressions, of the Expression MIB. But, like any other MIB on the system, the implementation of the Expression MIB should supply the changes in its data to the Table Modifications Tracking MIB using some internal API. Internet Draft Expires December 2002 [Page 5] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 4.3. SNMP Notifications Target MIB The Table Modifications Tracking MIB depends on the SNMPv3 Management Target and Notification MIB [RFC2573] for configuring the receivers of notifications generated by this MIB. 5. MIB Table Modifications Tracking MIB Definitions 5.1. MIB Sections The Table Modifications Tracking MIB consists of the following sections: o Registration - specify the MIB tables to watch for modifications in o Notifications Control - Notifications management o History - History of modifications 5.1.1. Registration The Registration section contains MIB objects to enable the NMS to register the MIB tables of interest. Only the modifications in the registered MIB tables will be tracked by this MIB. The tmtSupportedMIBTable contains a list of MIBs whose modifications could be tracked by this MIB. This table is read-only and is initialized by the system. The NMS will have to create an entry in tmtRegistrationTable for each MIB table it is interested in watching modifications. The NMS can also specify the type of modifications it is interested in e.g row creation, deletion etc. In addition, the user can specify the management context name if the registered MIB table is supported in multiple management contexts. The management context can also be specified as a wildcard. It also contains an object to start/stop tracking modifications in the registered MIB table. Multiple NMSes can register the same MIB table for watching same or different modifications types by specifying a unique owner name. If the NMS is not interested in watching changes in certain MIB objects e.g. counter type objects in the registered MIB table, an Internet Draft Expires December 2002 [Page 6] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 entry for each of those objects should be made in the tmtRegExcludeObjTable. 5.1.2. Notifications Control This section allows an NMS to enable/disable sending notifications for modifications in the registered MIB tables. In addition, the NMS can specify the notifications target system for tmtTableRowModified notifications generated by modifications in MIB tables registered by it. 5.1.3. History The History section records the history of modifications in the registered MIB tables. The tmtHistTableModifTable contains information about the count of modifications in a registered MIB table for each NMS. It also contains timestamp information about the last modification done in a registered MIB table. The tmtHistRowModifTable contains all the rows that have been modified in a MIB table registered by a particular NMS. If a single SNMP Set request, CLI command or an internal process state change caused modifications in multiple objects of a single row, only one entry will be created here. But if multiple SNMP Set requests, CLI commands or internal process state changes modify different objects in one row, multiple entries will be created. In addition, the tmtHistRowModifTable contains information about the modification source. The timestamp of the modification is also recorded. 5.2. Definitions TABLE-MODIF-TRACKING-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE, Internet Draft Expires December 2002 [Page 7] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 Counter32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TruthValue, VariablePointer, TimeStamp, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, NOTIFICATION-GROUP, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB Unsigned32 FROM CISCO-TC ciscoMgmt FROM CISCO-SMI; tableModifTrackingMIB MODULE-IDENTITY LAST-UPDATED "200206180000Z" ORGANIZATION "Cisco Systems, Inc." CONTACT-INFO " Niraj Gopal Cisco Systems, Inc. 170 W Tasman Drive San Jose, CA 95134 USA Phone: +1 408-527-3347 E-mail: niraj@cisco.com" DESCRIPTION "The MIB module to track and store the modifications in data of NMS specified MIB tables implemented in an SNMP command responder (traditionally called an SNMP agent). This MIB allows an NMS to register for change monitoring in the tables it is interested in. This MIB then tracks modifications in those registered tables, allowing the NMS to poll one table to determine if others need to be polled. This MIB keeps track of all modifications, including Internet Draft Expires December 2002 [Page 8] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 adding a new row, deletion of a row, and modification of an object in a row. It can also be configured to send change notifications to an NMS." REVISION "200206180000Z" DESCRIPTION "Initial version of this MIB module." ::= { mib-2 xxx } tmtMIBObjects OBJECT IDENTIFIER ::= { tableModifTrackingMIB 1 } -- Subgroups tmtRegistration OBJECT IDENTIFIER ::= { tmtMIBObjects 1 } tmtControl OBJECT IDENTIFIER ::= { tmtMIBObjects 2 } tmtHist OBJECT IDENTIFIER ::= { tmtMIBObjects 3 } -- Textual Conventions ModificationType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The MIB table data modification types that can be found and recorded. This is a bit map, with each bit representing a different modification type as described below: Bit 0 - rowCreation - Indicating creation of a row in a MIB table. Bit 1 - rowDeletion - Representing deletion of a row in a MIB table. Bit 2 - rowModification - Indicating modification to an object in a row in a MIB table. Setting all defined bits to 1 will enable the NMS to track all the modification types." SYNTAX BITS { rowCreation(0), rowDeletion(1), rowModification(2) } -- MIB tables registration table tmtRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF tmtRegistrationEntry MAX-ACCESS not-accessible STATUS current Internet Draft Expires December 2002 [Page 9] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 DESCRIPTION "A table to register the MIB tables for monitoring various modification types e.g addition of new rows, deletion of rows and modification in objects of existing rows. The changes in the registered MIB tables' data will be recorded in tmtHistTableModifTable and tmtHistRowModifTable tables. Only the tables that are present in ctmtSupportedTable can be registered. If an NMS is interested in row modifications in only a few objects in a particular table, it can do that by specifying those objects in tmtRegExcludeObjTable." ::= { tmtRegistration 1 } tmtRegistrationEntry OBJECT-TYPE SYNTAX TmtRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information for tracking changes in data of MIB table specified in this entry. Deleting an entry in tmtRegistrationTable deletes all corresponding entries in tmtHistTableModifTable and tmtHistRowModifTable tables. Entries in this table may not be changed while the corresponding value of tmtRegistrationTrackModifs is 'trackingModifications'." INDEX { tmtRegistrationOwner, tmtRegistrationIndex } ::= { tmtRegistrationTable 1 } TmtRegistrationEntry ::= SEQUENCE { tmtRegistrationOwner SnmpAdminString, tmtRegistrationIndex Unsigned32, tmtRegistrationModifTypeTracked ModificationType, tmtRegistrationTableID OBJECT IDENTIFIER, tmtRegistrationContextName SnmpAdminString, tmtRegistrationCtxtNameWildcard TruthValue, tmtRegistrationMaxRowModifHist Unsigned32, tmtRegistrationTrackModifs INTEGER, tmtRegistrationEntryStatus RowStatus } tmtRegistrationOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) Internet Draft Expires December 2002 [Page 10] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 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. The value of this variable could be name of the NMS user." ::= { tmtRegistrationEntry 1 } tmtRegistrationIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary number that uniquely identifies the entries in this table. To create an entry a management application should pick a random number." ::= { tmtRegistrationEntry 2 } tmtRegistrationModifTypeTracked OBJECT-TYPE SYNTAX ModificationType MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the type of MIB table data modifications that will be recorded. Any other type of MIB table data modifications will be ignored e.g. if the NMS has asked to process rowCreation(1) type of modification only, then rowDeletion(2) and rowModification(3) will be ignored. By default all types of MIB table data modifications are recorded." DEFVAL { { rowCreation, rowDeletion, rowModification } } ::= { tmtRegistrationEntry 3 } tmtRegistrationTableID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The object identifier of the MIB table of interest. The changes in its data will be recorded in tmtHistTableModifTable and tmtHistRowModifTable tables. This must be the OID of the table-defining SEQUENCE OF registration point. A given tmtRegistrationOwner can register a particular MIB Internet Draft Expires December 2002 [Page 11] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 table only once." ::= { tmtRegistrationEntry 4 } tmtRegistrationContextName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-create STATUS current DESCRIPTION "The management context from which to obtain changes in tmtRegistrationTableID. 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, tmtRegistrationCtxtNameWildcard 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 } ::= { tmtRegistrationEntry 5 } tmtRegistrationCtxtNameWildcard OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Control for whether tmtRegistrationContextName is to be treated as fully-specified or wildcarded, with 'true' indicating wildcard." DEFVAL { false } ::= { tmtRegistrationEntry 6 } tmtRegistrationMaxRowModifHist OBJECT-TYPE SYNTAX Unsigned32 (0..500) UNITS "entries" MAX-ACCESS read-create Internet Draft Expires December 2002 [Page 12] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 STATUS current DESCRIPTION "The upper limit on the number of entries that the tmtHistRowModifTable may contain for modifications in the MIB table represented by this entry. A value of 0 will prevent any history from being retained. When the number of entries in tmtHistRowModifTable for a MIB table represented by this entry exceeds this value, the oldest entry will be deleted and a new one will be created." DEFVAL { 1 } ::= { tmtRegistrationEntry 7 } tmtRegistrationTrackModifs OBJECT-TYPE SYNTAX INTEGER { notActive(1), ready(2), start(3), stop(4), trackingModifications(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The control to start/stop tracking modifications. The value is 'notActive' as long as tmtRegistrationEntryStatus is not active. When tmtRegistrationEntryStatus becomes active this object goes to 'ready'. This object can be set to 'start' only when its value is 'ready'. Once it is set to 'start', the MIB begins monitoring modifications for the MIB table represented by this entry and this object goes to 'trackingModifications'. This object can be set to 'stop' only when its value is 'trackingModifications'. Once it is set to 'stop', the MIB stops monitoring modifications for the MIB table represented by this entry and this object goes to 'ready'." ::= { tmtRegistrationEntry 8 } tmtRegistrationEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION Internet Draft Expires December 2002 [Page 13] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 "The control that allows creation, modification, and deletion of entries. For detailed rules see the DESCRIPTION for tmtRegistrationEntry." ::= { tmtRegistrationEntry 9 } tmtRegExcludeObjTable OBJECT-TYPE SYNTAX SEQUENCE OF tmtRegExcludeObjEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table to specify the objects in a registered MIB table, identified in tmtRegistrationTable, that this MIB WILL NOT monitor for modifications. E.g. if an NMS wants to watch changes in all objects in a MIB table except for a few objects, the NMS can specify those objects in this table indicating this MIB should NOT record changes in these objects. The implementation of this MIB may automatically put fast changing MIB objects e.g. Counters in this table so as to avoid a storm of modification records due to fast changing values of these objects. In this case, those entries will be read-only to the NMS." ::= { tmtRegistration 2 } tmtRegExcludeObjEntry OBJECT-TYPE SYNTAX TmtRegExcludeObjEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the MIB object the changes in which WILL NOT be recorded by this MIB. If for a registered MIB, identified in tmtRegistrationTable, there are no entries in this table, this MIB will record changes in all the objects in that table. Entries in this table may not be changed, created or deleted while the corresponding value of tmtRegistrationTrackModifs is 'trackingModifications'." INDEX { tmtRegistrationOwner, tmtRegistrationIndex, tmtRegExcludeObjOID } ::= { tmtRegExcludeObjTable 1 } TmtRegExcludeObjEntry ::= SEQUENCE { tmtRegExcludeObjOID OBJECT IDENTIFIER, Internet Draft Expires December 2002 [Page 14] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 tmtRegExcludeObjEntryStatus RowStatus } tmtRegExcludeObjOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "The object identifier of the MIB object, the changes in which, WILL NOT be recorded by this MIB. Please note that this is an implicit wildcard i.e. by specifying a MIB object here, the changes in all its instances will NOT be recorded by this MIB." ::= { tmtRegExcludeObjEntry 1 } tmtRegExcludeObjEntryStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The control that allows creation, modification, and deletion of entries. For detailed rules see the DESCRIPTION for tmtRegExcludeObjEntry." ::= { tmtRegExcludeObjEntry 2 } tmtSupportedMIBTable OBJECT-TYPE SYNTAX SEQUENCE OF tmtSupportedMIBEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table to specify the list of MIBs, the modifications in which could be tracked by this MIB. This MIB table is read-only and it is always initialized by the SNMP command responder. If a MIB does not exist in this table, no table in that MIB can be registered in the tmtRegistrationTable." ::= { tmtRegistration 3 } tmtSupportedMIBEntry OBJECT-TYPE SYNTAX TmtSupportedMIBEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Indicates the MIB table the changes in which can be tracked by this MIB." INDEX { tmtSupportedMIBOID } Internet Draft Expires December 2002 [Page 15] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 ::= { tmtSupportedMIBTable 1 } TmtSupportedMIBEntry ::= SEQUENCE { tmtSupportedMIBOID OBJECT IDENTIFIER } tmtSupportedMIBOID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The object identifier of the supported MIB. This must be the OID of the MIB-Module-defining MODULE-IDENTITY registration point." ::= { tmtSupportedMIBEntry 1 } -- Notification control table tmtControlNotificationsTable OBJECT-TYPE SYNTAX SEQUENCE OF tmtControlNotificationsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table to control the notifications sent by this MIB." ::= { tmtControl 1 } tmtControlNotificationsEntry OBJECT-TYPE SYNTAX TmtControlNotificationsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Notifications control information for a tmtRegistrationOwner. A new entry is automatically created in this table as soon as the first entry is created for a tmtRegistrationOwner in tmtRegistrationTable. Deleting all entries in tmtRegistrationTable for a particular tmtRegistrationOwner deletes this entry as well." INDEX { tmtRegistrationOwner } ::= { tmtControlNotificationsTable 1 } TmtControlNotificationsEntry ::= SEQUENCE { tmtControlNotificationsEnabled TruthValue, tmtControlNotificationsTarget VariablePointer, Internet Draft Expires December 2002 [Page 16] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 tmtControlNotificationsSent Counter32 } tmtControlNotificationsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether tmtTableRowModified notifications will or will not be sent when data in a MIB table registered by the tmtRegistrationOwner is modified in the SNMP command responder on the device. Disabling notifications does not prevent table modified messages from being added to tmtHistTableModifTable and tmtHistRowModifTable tables." DEFVAL { false } ::= { tmtControlNotificationsEntry 1 } tmtControlNotificationsTarget OBJECT-TYPE SYNTAX VariablePointer MAX-ACCESS read-write STATUS current DESCRIPTION "It points to an instance of snmpTargetAddrTagList object in snmpTargetAddrTable in SNMP-TARGET-MIB. The tmtTableRowModified notifications will be sent to the target specified by the value of this MIB variable. When the notifications are enabled by setting tmtControlNotificationsEnabled to true, this should point to a valid instance of snmpTargetAddrTagList. When notifications are disabled, this variable may or may not exist i.e. this table can be sparse. Each instance of snmpTargetAddrTagList can be associated with at most one tmtRegistrationOwner i.e. two different owners of entries in tmtRegistrationTable cannot have the same notifications target address." ::= { tmtControlNotificationsEntry 2 } tmtControlNotificationsSent OBJECT-TYPE SYNTAX Counter32 UNITS "notifications" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of tmtTableRowModified notifications for changes in the MIB tables registered by tmtRegistrationOwner that have been sent. This number may include notifications that were prevented from being transmitted due to reasons Internet Draft Expires December 2002 [Page 17] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 such as resource limitations and/or non-connectivity. If one is receiving notifications, one can periodically poll this object to determine if any notifications were missed. If so, a poll of tmtHistTableModifTable and tmtHistRowModifTable might be appropriate." ::= { tmtControlNotificationsEntry 3 } -- MIB tables modifications history table tmtHistTableModifTable OBJECT-TYPE SYNTAX SEQUENCE OF tmtHistTableModifEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table listing the MIB tables from the registered MIB tables in tmtRegistrationTable that had their data modified. There will only be one entry per registered MIB table that had a modification in its data. If a registered MIB table had many modifications, tmtHistTableLastModified of the entry corresponding to that registered table will be updated to the time when the last change occurred. This table allows the NMS to find out, in one operation: - If data in a given MIB table for an owner has changed. - If so, when did the last change occur. - And, the count of changes that occurred in the table. (Each SNMP Set request, CLI command or an internal process state change that causes modification in MIB table data is counted as one change. Although they may affect multiple rows in a MIB table.) Using this info the NMS can choose to: - Do nothing if the last change time is older than the time it polled this table last. - Check if the count of changes in the MIB table data is greater than this value at the previous poll plus any modifications done by this NMS. If this is false, it indicates there have been no modifications done by other managers. So, the NMS does not have to do anything. - Look into the tmtHistRowModifTable to find the rows Internet Draft Expires December 2002 [Page 18] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 that have changed since the last poll and only download the newly modified rows. - Or Download the entire table. ::= { tmtHist 1 } tmtHistTableModifEntry OBJECT-TYPE SYNTAX TmtHistTableModifEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for a MIB table registered by an owner that had its data modified." INDEX { tmtRegistrationOwner, tmtRegistrationIndex } ::= { tmtHistTableModifTable 1 } TmtHistTableModifEntry ::= SEQUENCE { tmtHistTableModifCount Counter32, tmtHistTableModifRowMsgsFlushed Counter32, tmtHistTableModifLastModified TimeStamp } tmtHistTableModifCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "It represents the number of modifications in the data of the MIB table represented by tmtRegistrationIndex and tmtRegistrationOwner. A single SNMP Set request, CLI command or an internal process state change that caused change in the MIB data is considered ONE modification. Although they may affect multiple rows in a MIB table. This object can be utilized to determine if the NMS will need to poll the tmtHistRowModifTable to find out if anything has changed. E.g., if the value of this object is 15 at the previous poll by the NMS. The NMS then modified the data in the registered MIB table twice. At the next poll, if the value of this object is greater than 17, then the NMS will know that someone else has also modified the data of this MIB table and it should walk the tmtHistRowModifTable to find out rows that have been modified." ::= { tmtHistTableModifEntry 1 } tmtHistTableModifRowMsgsFlushed OBJECT-TYPE SYNTAX Counter32 Internet Draft Expires December 2002 [Page 19] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 UNITS "messages" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of entries that have been removed from the tmtHistRowModifTable for a MIB table represented by tmtRegistrationIndex and tmtRegistrationOwner in order to make room for new entries. This object can be utilized to determine whether your polling frequency on tmtHistRowModifTable is fast enough and/or the maximum number of entries allowed in the tmtHistRowModifTable for a MIB table represented by tmtRegistrationIndex and tmtRegistrationOwner is large enough such that you are not missing modification messages." ::= { tmtHistTableModifEntry 2 } tmtHistTableModifLastModified OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in thousandth's of a second since the network management portion of the system was last re-initialized) when the last data modification for a MIB table, registered by a particular owner, occurred." ::= { tmtHistTableModifEntry 3 } -- Row modifications history table tmtHistRowModifTable OBJECT-TYPE SYNTAX SEQUENCE OF tmtHistRowModifEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table listing the rows that have been modified in a registered MIB table for a particular owner. The maximum number of entries in this table is controlled by the tmtRegistrationMaxRowModifHist object in the tmtRegistrationTable." ::= { tmtHist 2 } tmtHistRowModifEntry OBJECT-TYPE SYNTAX TmtHistRowModifEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Internet Draft Expires December 2002 [Page 20] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 "A modification in a row of a registered MIB table. If a single SNMP Set request, CLI command or an internal process state change caused modifications in multiple objects of a single row, only one entry will be created here. But if multiple SNMP Set requests, CLI commands or internal process state changes modify different objects in one row, multiple entries will be created." INDEX { tmtRegistrationOwner, tmtRegistrationIndex, tmtHistRowModifIndex } ::= { tmtHistRowModifTable 1 } TmtHistRowModifEntry ::= SEQUENCE { tmtHistRowModifIndex Unsigned32, tmtHistRowModifTimestamp TimeStamp, tmtHistRowModifType ModificationType, tmtHistRowModifInstance OBJECT IDENTIFIER, tmtHistRowModifSource INTEGER, tmtHistRowModifSrcAddressType InetAddressType, tmtHistRowModifSourceAddress InetAddress, tmtHistRowModifTerminalUser SnmpAdminString } tmtHistRowModifIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A monotonically increasing integer for the sole purpose of indexing history entries. When it reaches the maximum value the agent the value back to 1." ::= { tmtHistRowModifEntry 1 } tmtHistRowModifTimestamp OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The The value of sysUpTime when the modification in the row data of a registered MIB table occurred." ::= { tmtHistRowModifEntry 2 } tmtHistRowModifType OBJECT-TYPE SYNTAX ModificationType MAX-ACCESS read-only STATUS current DESCRIPTION Internet Draft Expires December 2002 [Page 21] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 "The type of modification that has occurred in the row data." ::= { tmtHistRowModifEntry 3 } tmtHistRowModifInstance OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the instance of the row that has been modified. For example: if a row with '171.69.0.0' instance in ipRouteTable is added/deleted/modified, this variable will be set to '171.69.0.0'." ::= { tmtHistRowModifEntry 4 } tmtHistRowModifSource OBJECT-TYPE SYNTAX INTEGER { other(1), commandLine(2), snmp(3), internal(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The source of the command that directly or indirectly caused the modification in the data of the row of a registered MIB table. other(1) - None of the types specified below." commandLine(2) - The ubiquitous Command Line Interface. snmp(3) - The Simple Network Management Protocol interface. internal(4) - The MIB data is changed because of changes in the process state e.g., new entries in ipRouteTable are created due to new routes learned by the routing process." ::= { tmtHistRowModifEntry 5 } tmtHistRowModifSrcAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "If tmtHistRowModifSource is 'snmp', this object represents the type of address stored in tmtHistRowModifSourceAddress." Internet Draft Expires December 2002 [Page 22] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 ::= { tmtHistRowModifEntry 6 } tmtHistRowModifSourceAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "If tmtHistRowModifSource is 'snmp', the internet address of the NMS that did the modification in the data of the row of a registered MIB table. The length is zero if not available or not applicable." ::= { tmtHistRowModifEntry 7 } tmtHistRowModifTerminalUser OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..64)) MAX-ACCESS read-only STATUS current DESCRIPTION "If tmtHistRowModifSource is 'commandLine', the name of the logged in user. The length is zero if not available or not applicable." ::= { tmtHistRowModifEntry 8 } -- notifications tmtMIBNotificationsPrefix OBJECT IDENTIFIER ::= { tableModifTrackingMIB 2 } tmtMIBNotifications OBJECT IDENTIFIER ::= { tmtMIBNotificationsPrefix 0 } tmtTableRowModified NOTIFICATION-TYPE OBJECTS { tmtRegistrationTableID, tmtRegistrationContextName, tmtRegistrationCtxtNameWildcard, tmtHistRowModifTimestamp, tmtHistRowModifType, tmtHistRowModifInstance, tmtHistRowModifSource, tmtHistRowModifSrcAddressType, tmtHistRowModifSourceAddress, tmtHistRowModifTerminalUser } STATUS current DESCRIPTION "This notification is sent when the data in a registered MIB table implemented in the SNMP Internet Draft Expires December 2002 [Page 23] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 command responder on the device is modified. This notification can be enabled/disabled by the value set in the tmtControlNotificationsEnabled object." ::= { tmtMIBNotifications 1 } -- conformance information tmtMIBConformance OBJECT IDENTIFIER ::= { tableModifTrackingMIB 3 } tmtMIBCompliances OBJECT IDENTIFIER ::= { tmtMIBConformance 1 } tmtMIBGroups OBJECT IDENTIFIER ::= { tmtMIBConformance 2 } -- compliance statements tmtMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the Cisco Table Modification Tracking MIB." MODULE -- this module MANDATORY-GROUPS { tmtRegistrationGroup, tmtHistoryGroup } GROUP tmtControlGroup DESCRIPTION "This group is required only for entities that support configuration of the notification targets and enabling/disabling of notifications generation." GROUP tmtNotificationsGroup DESCRIPTION "This group is required only for entities that support generation of tmtTableRowModified notifications." ::= { tmtMIBCompliances 1 } -- units of conformance tmtRegistrationGroup OBJECT-GROUP OBJECTS { -- MIB table registration objects tmtRegistrationModifTypeTracked, Internet Draft Expires December 2002 [Page 24] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 tmtRegistrationTableID, tmtRegistrationContextName, tmtRegistrationCtxtNameWildcard, tmtRegistrationMaxRowModifHist, tmtRegistrationTrackModifs, tmtRegistrationEntryStatus, -- Supported MIB objects tmtSupportedMIBOID, -- MIB objects registration objects tmtRegExcludeObjEntryStatus } STATUS current DESCRIPTION "A collection of objects providing the table and MIB objects registration capability." ::= { tmtMIBGroups 1 } tmtControlGroup OBJECT-GROUP OBJECTS { tmtControlNotificationsEnabled, tmtControlNotificationsTarget, tmtControlNotificationsSent } STATUS current DESCRIPTION "A collection of objects providing the control (enable/disable) of Table Modification Tracking MIB notifications." ::= { tmtMIBGroups 2 } tmtHistoryGroup OBJECT-GROUP OBJECTS { -- Table modification history objects tmtHistTableModifCount, tmtHistTableModifRowMsgsFlushed, tmtHistTableModifLastModified, -- Row modification history objects tmtHistRowModifTimestamp, tmtHistRowModifType, tmtHistRowModifInstance, tmtHistRowModifSource, tmtHistRowModifSrcAddressType, tmtHistRowModifSourceAddress, tmtHistRowModifTerminalUser } STATUS current DESCRIPTION "A collection of objects keeping the history Internet Draft Expires December 2002 [Page 25] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 of changes in the data of a MIB table." ::= { tmtMIBGroups 3 } tmtNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS { tmtTableRowModified } STATUS current DESCRIPTION "The notification generated by the Table Modification Tracking MIB." ::= { tmtMIBGroups 4 } END 6. Usage Example This section lists a step by step procedure for an example to monitor modifications in atmTrafficDescrParamTable in ATM-MIB excluding tmTrafficQoSClass and tmTrafficRowStatus objects. For this example, a maximum of 100 row history entries will be kept. 1. The manager chooses a name that will be used to identify the manager and an arbitrary index that will refer to the MIB table that will be monitored. For this example, the name will be "nms" and the index will be "999". 2. Do a walk of the tmtSupportedMIBTable to see if ATM-MIB is supported. If there is no entry for atmTrafficDescrParamTable, the changes cannot be tracked using this MIB otherwise proceed to next step. Sample Output: ctmtSupportedMIBOID.1.3.6.1.2.1.37 = 1.3.6.1.2.1.37 3. Set tmtRegistrationEntryStatus.nms.999 to createAndWait. 4. Set ctmtRegistrationTableID.nms.999 to atmTrafficDescrParamEntry to specify that the NMS is interested in tracking modifications in atmTrafficDescrParamTable. 5. Set ctmtRegistrationMaxRowModifHistory.nms.999 to 100 to specify the maximum number of history messages to be kept by this MIB. 6. Create an entry in ctmtRegExcludeObjTable for tmTrafficQoSClass Internet Draft Expires December 2002 [Page 26] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 and tmTrafficRowStatus to indicate that NMS is not interested in modifications in these objects. E.g. ctmtRegExcludeObjEntryStatus.1.3.6.1.2.1.37.1.5.1.8 = createAndGo ctmtRegExcludeObjEntryStatus.1.3.6.1.2.1.37.1.5.1.9 = createAndGo 7. Set ctmtRegistrationEntryStatus.nms.999 to active. 8. Set ctmtControlNotificationsEnabled.nms to 'true' if the NMS wants notifications for modifications in the registered table. In addition, the NMS can setup a notifications target by setting ctmtControlNotificationsTarget.nms to an appropriate instance of snmpTargetAddrTagList in SNMP-TARGET-MIB. 9. If ctmtRegistrationTrackModifs.nms.999 is 'ready(2)', set it to The value of this object should change to 'trackingModifications(5)'. Monitoring of atmTrafficDescrParamTable can be temporarily halted by setting ctmtRegistrationTrackModifs.nms.999 to 'stop(4)'. Using the following steps the NMS can find out the modifications that happened in the registered table - atmTrafficDescrParamTable. 1. Do a walk of the ctmtHistTableModifTable for 'nms' owner and find out - If data in a given MIB table has changed. If so, when did the last modification occur. - And, the count of modifications that occurred in the table. (Each SNMP Set request, CLI command or an internal process state change that causes modification in MIB table data is counted as one modification. Although they may affect multiple rows in a MIB table.) Sample output: ctmtHistTableModifCount.nms.999 2 ctmtHistTableModifRowMsgsFlushed.nms.999 0 ctmtHistTableModifLastModified.nms.999 21344667 Internet Draft Expires December 2002 [Page 27] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 2. If the last modification in the registered table occurred after the previous poll of ctmtHistTableModifTable go to step 5 else go to step 4. E.g. if the time of last poll of ctmtHistTableModifTable was 21111111, which is less than ctmtHistTableModifLastModified.nms.999 at this poll, NMS should move to step 5. 3. If the count of modifications in the table is greater than the sum of this count at the previous poll of ctmtHistTableModifTable and the modifications to atmTrafficDescrParamTable done by this NMS, go to step 5 else go to step 4. 4. Sleep for the pre-defined polling interval and then go to Step 1. 5. Reaching this step indicates there have been modifications done by other NMSes. So the NMS should do a walk of ctmtHistRowModifTable to get the newly added rows to collect information about the source, time, modification type and the instance of the modified row in atmTrafficDescrParamTable. Sample output: ctmtHistRowModifIndex.nms.999.1 1 ctmtHistRowModifTimestamp.nms.999.1 21333111 ctmtHistRowModifType.nms.999.1 rowAddition ctmtHistRowModifInstance.nms.999.1 96 ctmtHistRowModifSource.nms.999.1 commandLine(2) ctmtHistRowModifSrcAddressType.nms.999.1 unknown(0) ctmtHistRowModifSrcAddress.nms.999.1 ctmtHistRowModifTerminalUser.999.1 akshin ctmtHistRowModifIndex.nms.999.2 2 ctmtHistRowModifTimestamp.nms.999.2 21344667 ctmtHistRowModifType.nms.999.2 rowDeletion ctmtHistRowModifInstance.nms.999.2 1221 ctmtHistRowModifSource.nms.999.2 snmp(3) ctmtHistRowModifSrcAddressType.nms.999.2 ipv4 ctmtHistRowModifSrcAddress.nms.999.2 171.234.12.231 ctmtHistRowModifTerminalUser.999.2 The NMS may de-register the table monitoring request by setting ctmtRegistrationEntryStatus.nms.999 to destroy. Internet Draft Expires December 2002 [Page 28] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 7. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View- based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Table Modifications Tracking MIB implementation must use the security credentials that are present when a row in the tmtRegistrationTable is created to verify if the user has access to the MIB table being registered and should disallow registration of that MIB table if the access is denied. The history of modifications in the MIB tables registered by a NMS/user is kept based on the NMS/user name object index called "Owner Name". By using "Owner Name" and view-based access control [RFC2575] a network administrator can provide different access for different NMSes/users. 8. Author's Address Niraj Gopal Cisco Systems 170 W Tasman Dr. San Jose, CA-95051 USA Phone: +1 408-527-3347 Internet Draft Expires December 2002 [Page 29] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 Email: niraj@cisco.com 9. Acknowledgements Many thanks to Andy Bierman and Ram Kavasseri for detailed feedback on this document. 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] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC1215] 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. Internet Draft Expires December 2002 [Page 30] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 [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. [RFC2981] Kavasseri, R., Stewart, B., "Event MIB", RFC2981, October 2000 [RFC2982] Kavasseri, R., Stewart, B., "Distributed Management Expression MIB", RFC2981, October 2000 11. Full Copyright Statement Copyright (C) The Internet Society (2002). 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 Draft Expires December 2002 [Page 31] Internet Draft MIB Table Modifications Tracking MIB 28 June 2002 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. Internet Draft Expires December 2002 [Page 32]