idnits 2.17.1 draft-ietf-disman-notif-log-mib-v2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 36 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 516 has weird spacing: '...isabled admin...' == Line 518 has weird spacing: '...ational adm...' == Line 520 has weird spacing: '...oFilter admin...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7621 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 766 ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Disman Working Group R. Kavasseri 3 Internet Draft Cisco Systems, Inc. 4 Document: draft-ietf-disman-notif-log-mib-v2-01.txt B. Stewart 5 Expiration Date: December 2003 Retired 6 June 2003 8 Notification Log MIB 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this document is unlimited. Please send comments to 32 the Distributed Management Working Group, . 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This memo defines a portion of the Management Information Base (MIB) 41 for use with network management protocols in the Internet community. 42 In particular, it describes managed objects used for logging Simple 43 Network Management Protocol (SNMP) Notifications. 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119. 49 Table of Contents 51 1 The SNMP Management Framework ................................. 2 52 2 Overview ...................................................... 3 53 2.1 Environment ................................................. 3 54 2.1.1 SNMP Engines and Contexts ................................. 4 55 2.1.2 Security .................................................. 4 56 2.2 Structure ................................................... 5 57 2.2.1 Configuration ............................................. 5 58 2.2.2 Statistics ................................................ 6 59 2.2.3 Log ....................................................... 6 60 2.3 Example ..................................................... 6 61 3 Definitions ................................................... 7 62 4 Intellectual Property ......................................... 23 63 5 References .................................................... 23 64 6 Security Considerations ....................................... 25 65 7 Author's Address .............................................. 25 66 8 Full Copyright Statement ...................................... 26 68 1. The SNMP Management Framework 70 The SNMP Management Framework presently consists of five major 71 components: 73 o An overall architecture, described in RFC 2571 [RFC2571]. 75 o Mechanisms for describing and naming objects and events for the 76 purpose of management. The first version of this Structure of 77 Management Information (SMI) is called SMIv1 and described in 78 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 79 1215 [RFC1215]. The second version, called SMIv2, is described 80 in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 81 STD 58, RFC 2580 [RFC2580]. 83 o Message protocols for transferring management information. The 84 first version of the SNMP message protocol is called SNMPv1 and 85 described in STD 15, RFC 1157 [RFC1157]. A second version of 86 the SNMP message protocol, which is not an Internet standards 87 track protocol, is called SNMPv2c and described in RFC 1901 88 [RFC1901] and RFC 1906 [RFC1906]. The third version of the 89 message protocol is called SNMPv3 and described in RFC 1906 90 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 92 o Protocol operations for accessing management information. The 93 first set of protocol operations and associated PDU formats is 94 described in STD 15, RFC 1157 [RFC1157]. A second set of 95 protocol operations and associated PDU formats is described in 96 RFC 1905 [RFC1905]. 98 o A set of fundamental applications described in RFC 2573 99 [RFC2573] and the view-based access control mechanism described 100 in RFC 2575 [RFC2575]. 102 A more detailed introduction to the current SNMP Management Framework 103 can be found in RFC 2570 [RFC2570]. 105 Managed objects are accessed via a virtual information store, termed 106 the Management Information Base or MIB. Objects in the MIB are 107 defined using the mechanisms defined in the SMI. 109 This memo specifies a MIB module that is compliant to the SMIv2. A 110 MIB conforming to the SMIv1 can be produced through the appropriate 111 translations. The resulting translated MIB must be semantically 112 equivalent, except where objects or events are omitted because no 113 translation is possible (use of Counter64). Some machine readable 114 information in SMIv2 will be converted into textual descriptions in 115 SMIv1 during the translation process. However, this loss of machine 116 readable information is not considered to change the semantics of the 117 MIB. 119 2. Overview 121 Systems that support SNMP often need a mechanism for recording 122 Notification information as a hedge against lost Notifications, 123 whether those are Traps or Informs [RFC1905] that exceed 124 retransmission limits. This MIB therefore provides common 125 infrastructure for other MIBs in the form of a local logging 126 function. It is intended primarily for senders of Notifications but 127 could be used also by receivers. 129 Given the Notification Log MIB, individual MIBs bear less 130 responsibility to record the transient information associated with an 131 event against the possibility that the Notification message is lost, 132 and applications can poll the log to verify that they have not missed 133 important Notifications. 135 2.1. Environment 137 The overall environmental concerns for the MIB are: 139 o SNMP Engines and Contexts 141 o Security 143 2.1.1. SNMP Engines and Contexts 145 There are two distinct information flows from multiple notification 146 originators that one may log. The first is the notifications that 147 are received (from one or more SNMP engines) for logging as SNMP 148 informs and traps. The other comprises notifications delivered to an 149 SNMP engine at the interface to the notification originator (using a 150 notification mechanism other than SNMP informs or traps). The latter 151 information flow (using a notification mechanism other than SNMP 152 informs or traps) is modeled here as the SNMP engine (which maintains 153 the log) sending a notification to itself. The remainder of this 154 section discusses the handling of the former information flow - 155 notifications (received in the form of SNMP informs or traps) from 156 multiple SNMP engines. 158 As described in the SNMP architecture [RFC2571], a given system may 159 support multiple SNMP engines operating independently of one another, 160 each with its own SNMP engine identification. Furthermore, within 161 the purview of a given engine there may be multiple named management 162 contexts supporting overlapping or disjoint sets of MIB objects and 163 Notifications. Thus, understanding a particular Notification 164 requires knowing the SNMP engine and management context from whence 165 it came. 167 To provide the necessary source information for a logged 168 Notification, the MIB includes objects to record that Notification's 169 source SNMP engine ID and management context name. 171 2.1.2. Security 173 Security for Notifications is awkward since access control for the 174 objects in the Notification can be checked only where the 175 Notification is created. Thus such checking is possible only for 176 locally-generated Notifications, and even then only when security 177 credentials are available. 179 For the purpose of this discussion, "security credentials" means the 180 input values for the abstract service interface function 181 isAccessAllowed [RFC2571] and using those credentials means 182 conceptually using that function to see that those credentials allow 183 access to the MIB objects in question, operating as for a 184 Notification Originator in [RFC2573]. 186 The Notification Log MIB has the notion of a "named log." By using 187 log names and view-based access control [RFC2575] a network 188 administrator can provide different access for different users. When 189 an application creates a named log the security credentials of the 190 creator stay associated with that log. 192 A managed system with fewer resources MAY disallow the creation of 193 named logs, providing only the default, null-named log. Such a log 194 has no implicit security credentials for Notification object access 195 control and Notifications are put into it with no further checking. 197 When putting locally-generated Notifications into a named log, the 198 managed system MUST use the security credentials associated with that 199 log and MUST apply the same access control rules as described for a 200 Notification Originator in [RFC2573]. 202 The managed system SHOULD NOT apply access control when adding 203 remotely-generated Notifications into either a named log or the 204 default, null-named log. In those cases the security of the 205 information in the log SHOULD be left to the normal, overall access 206 control for the log itself. 208 The Notification Log MIB allows applications to set the maximum 209 number of Notifications that can be logged, using 210 nlmConfigGlobalEntryLimit. Similarly, an application can set the 211 maximum age using nlmConfigGlobalAgeOut, after which older 212 Notifications MAY be timed out. Please be aware that contention 213 between multiple applications trying to set these objects to 214 different values MAY affect the reliability and completeness of data 215 seen by each application, i.e., it is possible that one application 216 may change the value of either of these objects, resulting in some 217 Notifications being deleted before the other applications have had a 218 chance to see them. This could be used to orchestrate a denial-of- 219 service attack. Methods for countering such an attack are for 220 further study. 222 2.2. Structure 224 The MIB has the following sections: 226 o Configuration -- control over how much the log can hold and 227 what Notifications are to be logged. 229 o Statistics -- indications of logging activity. 231 o Log -- the Notifications themselves. 233 2.2.1. Configuration 235 The configuration section contains objects to manage resource use by 236 the MIB. 238 This section also contains a table to specify what logs exist and how 239 they operate. Deciding which Notifications are to be logged depends 240 on filters defined in the the snmpNotifyFilterTable in the standard 241 SNMP Notification MIB [RFC2573] identified by the initial index 242 (snmpNotifyFilterName) from that table. 244 2.2.2. Statistics 246 The statistics section contains counters for Notifications logged and 247 discarded, supplying a means to understand the results of log 248 capacity configuration and resource problems. 250 2.2.3. Log 252 The log contains the Notifications and the objects that came in their 253 variable binding list, indexed by an integer that reflects when the 254 entry was made. An application that wants to collect all logged 255 Notifications or to know if it may have missed any can keep track of 256 the highest index it has retrieved and start from there on its next 257 poll, checking sysUpTime for a discontinuity that would have reset 258 the index and perhaps have lost entries. 260 Variables are in a table indexed by Notification index and variable 261 index within that Notification. The values are kept as a 262 "discriminated union," with one value object per variable. Exactly 263 which value object is instantiated depends on the SNMP data type of 264 the variable, with a separate object of appropriate type for each 265 distinct SNMP data type. 267 An application can thus reconstruct the information from the 268 Notification PDU from what is recorded in the log. 270 2.3. Example 272 Following is an example configuration of a named log for logging only 273 linkUp and linkDown Notifications. 275 In nlmConfigLogTable: 277 nlmConfigLogFilterName.5."links" = "link-status" 278 nlmConfigLogEntryLimit.5."links" = 0 279 nlmConfigLogAdminStatus.5."links" = enabled 280 nlmConfigLogOperStatus.5."links" = operational 281 nlmConfigLogStorageType.5."links" = nonVolatile 282 nlmConfigLogEntryStatus.5."links" = active 284 Note that snmpTraps is: 286 iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.5 288 Or numerically: 290 1.3.6.1.6.3.1.1.5 292 And linkDown is snmpTraps.3 and linkUp is snmpTraps.4. 294 So to allow the two Notifications in snmpNotifyFilterTable: 296 snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.3 = ''H 297 snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.3 = include 298 snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.3 299 = nonVolatile 300 snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.3 301 = active 303 snmpNotifyFilterMask.11."link-status".1.3.6.1.6.3.1.1.5.4 = ''H 304 snmpNotifyFilterType.11."link-status".1.3.6.1.6.3.1.1.5.4 = include 305 snmpNotifyFilterStorageType.11."link-status".1.3.6.1.6.3.1.1.5.4 306 = nonVolatile 307 snmpNotifyFilterRowStatus.11."link-status".1.3.6.1.6.3.1.1.5.4 308 = active 310 3. Definitions 312 NOTIFICATION-LOG-MIB DEFINITIONS ::= BEGIN 314 IMPORTS 315 MODULE-IDENTITY, OBJECT-TYPE, 316 Integer32, Unsigned32, 317 TimeTicks, Counter32, Counter64, 318 IpAddress, Opaque, mib-2 FROM SNMPv2-SMI 319 TimeStamp, DateAndTime, 320 StorageType, RowStatus, 321 TAddress, TDomain FROM SNMPv2-TC 322 SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB 323 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 325 notificationLogMIB MODULE-IDENTITY 326 LAST-UPDATED "200306130000Z" -- 13 June 2003 327 ORGANIZATION "IETF Distributed Management Working Group" 328 CONTACT-INFO "Ramanathan Kavasseri 329 Cisco Systems, Inc. 330 170 West Tasman Drive, 331 San Jose CA 95134-1706. 332 Phone: +1 408 527 2446 333 Email: ramk@cisco.com" 334 DESCRIPTION 335 "The MIB module for logging SNMP Notifications, that is, Traps 336 and Informs. 338 Copyright (C) The Internet Society 2003. This version of this 339 MIB module is part of RFC yyyy; see the RFC itself for full 340 legal notices." 341 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 343 -- Revision History 344 REVISION "200306130000Z" -- 13 June 2003 345 DESCRIPTION "Added copyright statement to the MIB module 346 description." 348 REVISION "200011270000Z" -- 27 November 2000 349 DESCRIPTION "This is the initial version of this MIB. 350 Published as RFC 3014" 351 ::= { mib-2 92 } 353 notificationLogMIBObjects OBJECT IDENTIFIER ::= { notificationLogMIB 1 } 355 nlmConfig OBJECT IDENTIFIER ::= { notificationLogMIBObjects 1 } 356 nlmStats OBJECT IDENTIFIER ::= { notificationLogMIBObjects 2 } 357 nlmLog OBJECT IDENTIFIER ::= { notificationLogMIBObjects 3 } 359 -- 360 -- Configuration Section 361 -- 363 nlmConfigGlobalEntryLimit OBJECT-TYPE 364 SYNTAX Unsigned32 365 MAX-ACCESS read-write 366 STATUS current 367 DESCRIPTION 368 "The maximum number of notification entries that may be held 369 in nlmLogTable for all nlmLogNames added together. A particular 370 setting does not guarantee that much data can be held. 372 If an application changes the limit while there are 373 Notifications in the log, the oldest Notifications MUST be 374 discarded to bring the log down to the new limit - thus the 375 value of nlmConfigGlobalEntryLimit MUST take precedence over 376 the values of nlmConfigGlobalAgeOut and nlmConfigLogEntryLimit, 377 even if the Notification being discarded has been present for 378 fewer minutes than the value of nlmConfigGlobalAgeOut, or if 379 the named log has fewer entries than that specified in 380 nlmConfigLogEntryLimit. 382 A value of 0 means no limit. 384 Please be aware that contention between multiple managers 385 trying to set this object to different values MAY affect the 386 reliability and completeness of data seen by each manager." 387 DEFVAL { 0 } 388 ::= { nlmConfig 1 } 390 nlmConfigGlobalAgeOut OBJECT-TYPE 391 SYNTAX Unsigned32 392 UNITS "minutes" 393 MAX-ACCESS read-write 394 STATUS current 395 DESCRIPTION 396 "The number of minutes a Notification SHOULD be kept in a log 397 before it is automatically removed. 399 If an application changes the value of nlmConfigGlobalAgeOut, 400 Notifications older than the new time MAY be discarded to meet the 401 new time. 403 A value of 0 means no age out. 405 Please be aware that contention between multiple managers 406 trying to set this object to different values MAY affect the 407 reliability and completeness of data seen by each manager." 408 DEFVAL { 1440 } -- 24 hours 409 ::= { nlmConfig 2 } 411 -- 412 -- Basic Log Configuration Table 413 -- 415 nlmConfigLogTable OBJECT-TYPE 416 SYNTAX SEQUENCE OF NlmConfigLogEntry 417 MAX-ACCESS not-accessible 418 STATUS current 419 DESCRIPTION 420 "A table of logging control entries." 421 ::= { nlmConfig 3 } 423 nlmConfigLogEntry OBJECT-TYPE 424 SYNTAX NlmConfigLogEntry 425 MAX-ACCESS not-accessible 426 STATUS current 427 DESCRIPTION 428 "A logging control entry. Depending on the entry's storage type 429 entries may be supplied by the system or created and deleted by 430 applications using nlmConfigLogEntryStatus." 431 INDEX { nlmLogName } 432 ::= { nlmConfigLogTable 1 } 434 NlmConfigLogEntry ::= SEQUENCE { 435 nlmLogName SnmpAdminString, 436 nlmConfigLogFilterName SnmpAdminString, 437 nlmConfigLogEntryLimit Unsigned32, 438 nlmConfigLogAdminStatus INTEGER, 439 nlmConfigLogOperStatus INTEGER, 440 nlmConfigLogStorageType StorageType, 441 nlmConfigLogEntryStatus RowStatus 442 } 444 nlmLogName OBJECT-TYPE 445 SYNTAX SnmpAdminString (SIZE(0..32)) 446 MAX-ACCESS not-accessible 447 STATUS current 448 DESCRIPTION 449 "The name of the log. 451 An implementation may allow multiple named logs, up to some 452 implementation-specific limit (which may be none). A 453 zero-length log name is reserved for creation and deletion by 454 the managed system, and MUST be used as the default log name by 455 systems that do not support named logs." 456 ::= { nlmConfigLogEntry 1 } 458 nlmConfigLogFilterName OBJECT-TYPE 459 SYNTAX SnmpAdminString (SIZE(0..32)) 460 MAX-ACCESS read-create 461 STATUS current 462 DESCRIPTION 463 "A value of snmpNotifyFilterProfileName as used as an index 464 into the snmpNotifyFilterTable in the SNMP Notification MIB, 465 specifying the locally or remotely originated Notifications 466 to be filtered out and not logged in this log. 468 A zero-length value or a name that does not identify an 469 existing entry in snmpNotifyFilterTable indicate no 470 Notifications are to be logged in this log." 471 DEFVAL { ''H } 472 ::= { nlmConfigLogEntry 2 } 474 nlmConfigLogEntryLimit OBJECT-TYPE 475 SYNTAX Unsigned32 476 MAX-ACCESS read-create 477 STATUS current 478 DESCRIPTION 479 "The maximum number of notification entries that can be held in 480 nlmLogTable for this named log. A particular setting does not 481 guarantee that that much data can be held. 483 If an application changes the limit while there are 484 Notifications in the log, the oldest Notifications are discarded 485 to bring the log down to the new limit. 487 A value of 0 indicates no limit. 489 Please be aware that contention between multiple managers 490 trying to set this object to different values MAY affect the 491 reliability and completeness of data seen by each manager." 492 DEFVAL { 0 } 493 ::= { nlmConfigLogEntry 3 } 495 nlmConfigLogAdminStatus OBJECT-TYPE 496 SYNTAX INTEGER { enabled(1), disabled(2) } 497 MAX-ACCESS read-create 498 STATUS current 499 DESCRIPTION 500 "Control to enable or disable the log without otherwise 501 disturbing the log's entry. 503 Please be aware that contention between multiple managers 504 trying to set this object to different values MAY affect the 505 reliability and completeness of data seen by each manager." 506 DEFVAL { enabled } 507 ::= { nlmConfigLogEntry 4 } 509 nlmConfigLogOperStatus OBJECT-TYPE 510 SYNTAX INTEGER { disabled(1), operational(2), noFilter(3) } 511 MAX-ACCESS read-only 512 STATUS current 513 DESCRIPTION 514 "The operational status of this log: 516 disabled administratively disabled 518 operational administratively enabled and working 520 noFilter administratively enabled but either 521 nlmConfigLogFilterName is zero length 522 or does not name an existing entry in 523 snmpNotifyFilterTable" 524 ::= { nlmConfigLogEntry 5 } 526 nlmConfigLogStorageType OBJECT-TYPE 527 SYNTAX StorageType 528 MAX-ACCESS read-create 529 STATUS current 530 DESCRIPTION 531 "The storage type of this conceptual row." 532 ::= { nlmConfigLogEntry 6 } 534 nlmConfigLogEntryStatus OBJECT-TYPE 535 SYNTAX RowStatus 536 MAX-ACCESS read-create 537 STATUS current 538 DESCRIPTION 539 "Control for creating and deleting entries. Entries may be 540 modified while active. 542 For non-null-named logs, the managed system records the security 543 credentials from the request that sets nlmConfigLogStatus 544 to 'active' and uses that identity to apply access control to 545 the objects in the Notification to decide if that Notification 546 may be logged." 547 ::= { nlmConfigLogEntry 7 } 549 -- 550 -- Statistics Section 551 -- 552 nlmStatsGlobalNotificationsLogged OBJECT-TYPE 553 SYNTAX Counter32 554 UNITS "notifications" 555 MAX-ACCESS read-only 556 STATUS current 557 DESCRIPTION 558 "The number of Notifications put into the nlmLogTable. This 559 counts a Notification once for each log entry, so a Notification 560 put into multiple logs is counted multiple times." 561 ::= { nlmStats 1 } 563 nlmStatsGlobalNotificationsBumped OBJECT-TYPE 564 SYNTAX Counter32 565 UNITS "notifications" 566 MAX-ACCESS read-only 567 STATUS current 568 DESCRIPTION 569 "The number of log entries discarded to make room for a new entry 570 due to lack of resources or the value of nlmConfigGlobalEntryLimit 571 or nlmConfigLogEntryLimit. This does not include entries discarded 572 due to the value of nlmConfigGlobalAgeOut." 573 ::= { nlmStats 2 } 575 -- 576 -- Log Statistics Table 577 -- 579 nlmStatsLogTable OBJECT-TYPE 580 SYNTAX SEQUENCE OF NlmStatsLogEntry 581 MAX-ACCESS not-accessible 582 STATUS current 583 DESCRIPTION 584 "A table of Notification log statistics entries." 585 ::= { nlmStats 3 } 587 nlmStatsLogEntry OBJECT-TYPE 588 SYNTAX NlmStatsLogEntry 589 MAX-ACCESS not-accessible 590 STATUS current 591 DESCRIPTION 592 "A Notification log statistics entry." 593 AUGMENTS { nlmConfigLogEntry } 594 ::= { nlmStatsLogTable 1 } 596 NlmStatsLogEntry ::= SEQUENCE { 597 nlmStatsLogNotificationsLogged Counter32, 598 nlmStatsLogNotificationsBumped Counter32 599 } 601 nlmStatsLogNotificationsLogged OBJECT-TYPE 602 SYNTAX Counter32 603 UNITS "notifications" 604 MAX-ACCESS read-only 605 STATUS current 606 DESCRIPTION 607 "The number of Notifications put in this named log." 608 ::= { nlmStatsLogEntry 1 } 610 nlmStatsLogNotificationsBumped OBJECT-TYPE 611 SYNTAX Counter32 612 UNITS "notifications" 613 MAX-ACCESS read-only 614 STATUS current 615 DESCRIPTION 616 "The number of log entries discarded from this named log to make 617 room for a new entry due to lack of resources or the value of 618 nlmConfigGlobalEntryLimit or nlmConfigLogEntryLimit. This does not 619 include entries discarded due to the value of 620 nlmConfigGlobalAgeOut." 621 ::= { nlmStatsLogEntry 2 } 623 -- 624 -- Log Section 625 -- 627 -- 628 -- Log Table 629 -- 631 nlmLogTable OBJECT-TYPE 632 SYNTAX SEQUENCE OF NlmLogEntry 633 MAX-ACCESS not-accessible 634 STATUS current 635 DESCRIPTION 636 "A table of Notification log entries. 638 It is an implementation-specific matter whether entries in this 639 table are preserved across initializations of the management 640 system. In general one would expect that they are not. 642 Note that keeping entries across initializations of the 643 management system leads to some confusion with counters and 644 TimeStamps, since both of those are based on sysUpTime, which 645 resets on management initialization. In this situation, 646 counters apply only after the reset and nlmLogTime for entries 647 made before the reset MUST be set to 0." 648 ::= { nlmLog 1 } 650 nlmLogEntry OBJECT-TYPE 651 SYNTAX NlmLogEntry 652 MAX-ACCESS not-accessible 653 STATUS current 654 DESCRIPTION 655 "A Notification log entry. 657 Entries appear in this table when Notifications occur and pass 658 filtering by nlmConfigLogFilterName and access control. They are 659 removed to make way for new entries due to lack of resources or 660 the values of nlmConfigGlobalEntryLimit, nlmConfigGlobalAgeOut, or 661 nlmConfigLogEntryLimit. 663 If adding an entry would exceed nlmConfigGlobalEntryLimit or system 664 resources in general, the oldest entry in any log SHOULD be removed 665 to make room for the new one. 667 If adding an entry would exceed nlmConfigLogEntryLimit the oldest 668 entry in that log SHOULD be removed to make room for the new one. 670 Before the managed system puts a locally-generated Notification 671 into a non-null-named log it assures that the creator of the log 672 has access to the information in the Notification. If not it 673 does not log that Notification in that log." 674 INDEX { nlmLogName, nlmLogIndex } 675 ::= { nlmLogTable 1 } 677 NlmLogEntry ::= SEQUENCE { 678 nlmLogIndex Unsigned32, 679 nlmLogTime TimeStamp, 680 nlmLogDateAndTime DateAndTime, 681 nlmLogEngineID SnmpEngineID, 682 nlmLogEngineTAddress TAddress, 683 nlmLogEngineTDomain TDomain, 684 nlmLogContextEngineID SnmpEngineID, 685 nlmLogContextName SnmpAdminString, 686 nlmLogNotificationID OBJECT IDENTIFIER 688 } 690 nlmLogIndex OBJECT-TYPE 691 SYNTAX Unsigned32 (1..4294967295) 692 MAX-ACCESS not-accessible 693 STATUS current 694 DESCRIPTION 695 "A monotonically increasing integer for the sole purpose of 696 indexing entries within the named log. When it reaches the 697 maximum value, an extremely unlikely event, the agent wraps the 698 value back to 1." 699 ::= { nlmLogEntry 1 } 701 nlmLogTime OBJECT-TYPE 702 SYNTAX TimeStamp 703 MAX-ACCESS read-only 704 STATUS current 705 DESCRIPTION 706 "The value of sysUpTime when the entry was placed in the log. If 707 the entry occurred before the most recent management system 708 initialization this object value MUST be set to zero." 709 ::= { nlmLogEntry 2 } 711 nlmLogDateAndTime OBJECT-TYPE 712 SYNTAX DateAndTime 713 MAX-ACCESS read-only 714 STATUS current 715 DESCRIPTION 716 "The local date and time when the entry was logged, instantiated 717 only by systems that have date and time capability." 718 ::= { nlmLogEntry 3 } 720 nlmLogEngineID OBJECT-TYPE 721 SYNTAX SnmpEngineID 722 MAX-ACCESS read-only 723 STATUS current 724 DESCRIPTION 725 "The identification of the SNMP engine at which the Notification 726 originated. 728 If the log can contain Notifications from only one engine 729 or the Trap is in SNMPv1 format, this object is a zero-length 730 string." 731 ::= { nlmLogEntry 4 } 733 nlmLogEngineTAddress OBJECT-TYPE 734 SYNTAX TAddress 735 MAX-ACCESS read-only 736 STATUS current 737 DESCRIPTION 738 "The transport service address of the SNMP engine from which the 739 Notification was received, formatted according to the corresponding 740 value of nlmLogEngineTDomain. This is used to identify the source 741 of an SNMPv1 trap, since an nlmLogEngineId cannot be extracted 742 from the SNMPv1 trap pdu. 744 This object MUST always be instantiated, even if the log 745 can contain Notifications from only one engine. 747 Please be aware that the nlmLogEngineTAddress may not uniquely 748 identify the SNMP engine from which the Notification was received. 749 For example, if an SNMP engine uses DHCP or NAT to obtain 750 ip addresses, the address it uses may be shared with other 751 network devices, and hence will not uniquely identify the 752 SNMP engine." 753 ::= { nlmLogEntry 5 } 755 nlmLogEngineTDomain OBJECT-TYPE 756 SYNTAX TDomain 757 MAX-ACCESS read-only 758 STATUS current 759 DESCRIPTION 760 "Indicates the kind of transport service by which a Notification 761 was received from an SNMP engine. nlmLogEngineTAddress contains 762 the transport service address of the SNMP engine from which 763 this Notification was received. 765 Possible values for this object are presently found in the 766 Transport Mappings for SNMPv2 document (RFC 1906 [8])." 767 ::= { nlmLogEntry 6 } 769 nlmLogContextEngineID OBJECT-TYPE 770 SYNTAX SnmpEngineID 771 MAX-ACCESS read-only 772 STATUS current 773 DESCRIPTION 774 "If the Notification was received in a protocol which has a 775 contextEngineID element like SNMPv3, this object has that value. 776 Otherwise its value is a zero-length string." 777 ::= { nlmLogEntry 7 } 779 nlmLogContextName OBJECT-TYPE 780 SYNTAX SnmpAdminString 781 MAX-ACCESS read-only 782 STATUS current 783 DESCRIPTION 784 "The name of the SNMP MIB context from which the Notification came. 785 For SNMPv1 Traps this is the community string from the Trap." 786 ::= { nlmLogEntry 8 } 788 nlmLogNotificationID OBJECT-TYPE 789 SYNTAX OBJECT IDENTIFIER 790 MAX-ACCESS read-only 791 STATUS current 792 DESCRIPTION 793 "The NOTIFICATION-TYPE object identifier of the Notification that 794 occurred." 795 ::= { nlmLogEntry 9 } 797 -- 798 -- Log Variable Table 799 -- 801 nlmLogVariableTable OBJECT-TYPE 802 SYNTAX SEQUENCE OF NlmLogVariableEntry 803 MAX-ACCESS not-accessible 804 STATUS current 805 DESCRIPTION 806 "A table of variables to go with Notification log entries." 807 ::= { nlmLog 2 } 809 nlmLogVariableEntry OBJECT-TYPE 810 SYNTAX NlmLogVariableEntry 811 MAX-ACCESS not-accessible 812 STATUS current 813 DESCRIPTION 814 "A Notification log entry variable. 816 Entries appear in this table when there are variables in 817 the varbind list of a Notification in nlmLogTable." 818 INDEX { nlmLogName, nlmLogIndex, nlmLogVariableIndex } 819 ::= { nlmLogVariableTable 1 } 821 NlmLogVariableEntry ::= SEQUENCE { 822 nlmLogVariableIndex Unsigned32, 823 nlmLogVariableID OBJECT IDENTIFIER, 824 nlmLogVariableValueType INTEGER, 825 nlmLogVariableCounter32Val Counter32, 826 nlmLogVariableUnsigned32Val Unsigned32, 827 nlmLogVariableTimeTicksVal TimeTicks, 828 nlmLogVariableInteger32Val Integer32, 829 nlmLogVariableOctetStringVal OCTET STRING, 830 nlmLogVariableIpAddressVal IpAddress, 831 nlmLogVariableOidVal OBJECT IDENTIFIER, 832 nlmLogVariableCounter64Val Counter64, 833 nlmLogVariableOpaqueVal Opaque 834 } 836 nlmLogVariableIndex OBJECT-TYPE 837 SYNTAX Unsigned32 (1..4294967295) 838 MAX-ACCESS not-accessible 839 STATUS current 840 DESCRIPTION 841 "A monotonically increasing integer, starting at 1 for a given 842 nlmLogIndex, for indexing variables within the logged 843 Notification." 844 ::= { nlmLogVariableEntry 1 } 846 nlmLogVariableID OBJECT-TYPE 847 SYNTAX OBJECT IDENTIFIER 848 MAX-ACCESS read-only 849 STATUS current 850 DESCRIPTION 851 "The variable's object identifier." 852 ::= { nlmLogVariableEntry 2 } 854 nlmLogVariableValueType OBJECT-TYPE 855 SYNTAX INTEGER { counter32(1), unsigned32(2), timeTicks(3), 856 integer32(4), ipAddress(5), octetString(6), 857 objectId(7), counter64(8), opaque(9) } 858 MAX-ACCESS read-only 859 STATUS current 860 DESCRIPTION 861 "The type of the value. One and only one of the value 862 objects that follow must be instantiated, based on this type." 863 ::= { nlmLogVariableEntry 3 } 865 nlmLogVariableCounter32Val OBJECT-TYPE 866 SYNTAX Counter32 867 MAX-ACCESS read-only 868 STATUS current 869 DESCRIPTION 870 "The value when nlmLogVariableType is 'counter32'." 871 ::= { nlmLogVariableEntry 4 } 873 nlmLogVariableUnsigned32Val OBJECT-TYPE 874 SYNTAX Unsigned32 875 MAX-ACCESS read-only 876 STATUS current 877 DESCRIPTION 878 "The value when nlmLogVariableType is 'unsigned32'." 879 ::= { nlmLogVariableEntry 5 } 881 nlmLogVariableTimeTicksVal OBJECT-TYPE 882 SYNTAX TimeTicks 883 MAX-ACCESS read-only 884 STATUS current 885 DESCRIPTION 886 "The value when nlmLogVariableType is 'timeTicks'." 887 ::= { nlmLogVariableEntry 6 } 889 nlmLogVariableInteger32Val OBJECT-TYPE 890 SYNTAX Integer32 891 MAX-ACCESS read-only 892 STATUS current 893 DESCRIPTION 894 "The value when nlmLogVariableType is 'integer32'." 895 ::= { nlmLogVariableEntry 7 } 897 nlmLogVariableOctetStringVal OBJECT-TYPE 898 SYNTAX OCTET STRING 899 MAX-ACCESS read-only 900 STATUS current 901 DESCRIPTION 902 "The value when nlmLogVariableType is 'octetString'." 903 ::= { nlmLogVariableEntry 8 } 905 nlmLogVariableIpAddressVal OBJECT-TYPE 906 SYNTAX IpAddress 907 MAX-ACCESS read-only 908 STATUS current 909 DESCRIPTION 910 "The value when nlmLogVariableType is 'ipAddress'. 911 Although this seems to be unfriendly for IPv6, we 912 have to recognize that there are a number of older 913 MIBs that do contain an IPv4 format address, known 914 as IpAddress. 916 IPv6 addresses are represented using TAddress or 917 InetAddress, and so the underlying datatype is 918 OCTET STRING, and their value would be stored in 919 the nlmLogVariableOctetStringVal column." 920 ::= { nlmLogVariableEntry 9 } 922 nlmLogVariableOidVal OBJECT-TYPE 923 SYNTAX OBJECT IDENTIFIER 924 MAX-ACCESS read-only 925 STATUS current 926 DESCRIPTION 927 "The value when nlmLogVariableType is 'objectId'." 928 ::= { nlmLogVariableEntry 10 } 930 nlmLogVariableCounter64Val OBJECT-TYPE 931 SYNTAX Counter64 932 MAX-ACCESS read-only 933 STATUS current 934 DESCRIPTION 935 "The value when nlmLogVariableType is 'counter64'." 936 ::= { nlmLogVariableEntry 11 } 938 nlmLogVariableOpaqueVal OBJECT-TYPE 939 SYNTAX Opaque 940 MAX-ACCESS read-only 941 STATUS current 942 DESCRIPTION 943 "The value when nlmLogVariableType is 'opaque'." 944 ::= { nlmLogVariableEntry 12 } 946 -- 947 -- Conformance 948 -- 950 notificationLogMIBConformance OBJECT IDENTIFIER ::= 951 { notificationLogMIB 3 } 952 notificationLogMIBCompliances OBJECT IDENTIFIER ::= 953 { notificationLogMIBConformance 1 } 954 notificationLogMIBGroups OBJECT IDENTIFIER ::= 955 { notificationLogMIBConformance 2 } 957 -- Compliance 958 notificationLogMIBCompliance MODULE-COMPLIANCE 959 STATUS current 960 DESCRIPTION 961 "The compliance statement for entities which implement 962 the Notification Log MIB." 963 MODULE -- this module 964 MANDATORY-GROUPS { 965 notificationLogConfigGroup, 966 notificationLogStatsGroup, 967 notificationLogLogGroup 968 } 970 OBJECT nlmConfigGlobalEntryLimit 971 SYNTAX Unsigned32 (0..4294967295) 972 MIN-ACCESS read-only 973 DESCRIPTION 974 "Implementations may choose a limit and not allow it to be 975 changed or may enforce an upper or lower bound on the 976 limit." 978 OBJECT nlmConfigLogEntryLimit 979 SYNTAX Unsigned32 (0..4294967295) 980 MIN-ACCESS read-only 981 DESCRIPTION 982 "Implementations may choose a limit and not allow it to be 983 changed or may enforce an upper or lower bound on the 984 limit." 986 OBJECT nlmConfigLogEntryStatus 987 MIN-ACCESS read-only 988 DESCRIPTION 989 "Implementations may disallow the creation of named logs." 991 GROUP notificationLogDateGroup 992 DESCRIPTION 993 "This group is mandatory on systems that keep wall clock 994 date and time and should not be implemented on systems that 995 do not have a wall clock date." 997 ::= { notificationLogMIBCompliances 1 } 999 -- Units of Conformance 1001 notificationLogConfigGroup OBJECT-GROUP 1002 OBJECTS { 1003 nlmConfigGlobalEntryLimit, 1004 nlmConfigGlobalAgeOut, 1005 nlmConfigLogFilterName, 1006 nlmConfigLogEntryLimit, 1007 nlmConfigLogAdminStatus, 1008 nlmConfigLogOperStatus, 1009 nlmConfigLogStorageType, 1010 nlmConfigLogEntryStatus 1011 } 1012 STATUS current 1013 DESCRIPTION 1014 "Notification log configuration management." 1015 ::= { notificationLogMIBGroups 1 } 1017 notificationLogStatsGroup OBJECT-GROUP 1018 OBJECTS { 1019 nlmStatsGlobalNotificationsLogged, 1020 nlmStatsGlobalNotificationsBumped, 1021 nlmStatsLogNotificationsLogged, 1022 nlmStatsLogNotificationsBumped 1023 } 1024 STATUS current 1025 DESCRIPTION 1026 "Notification log statistics." 1027 ::= { notificationLogMIBGroups 2 } 1029 notificationLogLogGroup OBJECT-GROUP 1030 OBJECTS { 1031 nlmLogTime, 1032 nlmLogEngineID, 1033 nlmLogEngineTAddress, 1034 nlmLogEngineTDomain, 1035 nlmLogContextEngineID, 1036 nlmLogContextName, 1037 nlmLogNotificationID, 1038 nlmLogVariableID, 1039 nlmLogVariableValueType, 1040 nlmLogVariableCounter32Val, 1041 nlmLogVariableUnsigned32Val, 1042 nlmLogVariableTimeTicksVal, 1043 nlmLogVariableInteger32Val, 1044 nlmLogVariableOctetStringVal, 1045 nlmLogVariableIpAddressVal, 1046 nlmLogVariableOidVal, 1047 nlmLogVariableCounter64Val, 1048 nlmLogVariableOpaqueVal 1049 } 1050 STATUS current 1051 DESCRIPTION 1052 "Notification log data." 1053 ::= { notificationLogMIBGroups 3 } 1055 notificationLogDateGroup OBJECT-GROUP 1056 OBJECTS { 1057 nlmLogDateAndTime 1058 } 1059 STATUS current 1060 DESCRIPTION 1061 "Conditionally mandatory notification log data. 1062 This group is mandatory on systems that keep wall 1063 clock date and time and should not be implemented 1064 on systems that do not have a wall clock date." 1065 ::= { notificationLogMIBGroups 4 } 1067 END 1069 4. Intellectual Property 1071 The IETF takes no position regarding the validity or scope of any 1072 intellectual property or other rights that might be claimed to 1073 pertain to the implementation or use of the technology described in 1074 this document or the extent to which any license under such rights 1075 might or might not be available; neither does it represent that it 1076 has made any effort to identify any such rights. Information on the 1077 IETF's procedures with respect to rights in standards-track and 1078 standards-related documentation can be found in BCP-11. Copies of 1079 claims of rights made available for publication and any assurances of 1080 licenses to be made available, or the result of an attempt made to 1081 obtain a general license or permission for the use of such 1082 proprietary rights by implementors or users of this specification can 1083 be obtained from the IETF Secretariat. 1085 The IETF invites any interested party to bring to its attention any 1086 copyrights, patents or patent applications, or other proprietary 1087 rights which may cover technology that may be required to practice 1088 this standard. Please address the information to the IETF Executive 1089 Director. 1091 5. References 1093 [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An 1094 Architecture for Describing SNMP Management Frameworks", 1095 RFC 2571, April 1999. 1097 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification 1098 of Management Information for TCP/IP-based Internets", 1099 STD 16, RFC 1155, May 1990. 1101 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", 1102 STD 16, RFC 1212, March 1991. 1104 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 1105 the SNMP", RFC 1215, March 1991. 1107 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1108 Rose, M. and S. Waldbusser, "Structure of Management 1109 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1110 1999. 1112 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1113 Rose, M. and S. Waldbusser, "Textual Conventions for 1114 SMIv2", STD 58, RFC 2579, April 1999. 1116 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1117 Rose, M. and S. Waldbusser, "Conformance Statements for 1118 SMIv2", STD 58, RFC 2580, April 1999. 1120 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, 1121 "Simple Network Management Protocol", STD 15, RFC 1157, 1122 May 1990. 1124 [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 1125 "Introduction to Community-based SNMPv2", RFC 1901, 1126 January 1996. 1128 [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 1129 "Transport Mappings for Version 2 of the Simple Network 1130 Management Protocol (SNMPv2)", RFC 1906, January 1996. 1132 [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, 1133 "Message Processing and Dispatching for the Simple 1134 Network Management Protocol (SNMP)", RFC 2572, April 1135 1999. 1137 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model 1138 (USM) for version 3 of the Simple Network Management 1139 Protocol (SNMPv3)", RFC 2574, April 1999. 1141 [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 1142 "Protocol Operations for Version 2 of the Simple Network 1143 Management Protocol (SNMPv2)", RFC 1905, January 1996. 1145 [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 1146 Applications", RFC 2573, April 1999. 1148 [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 1149 Access Control Model (VACM) for the Simple Network 1150 Management Protocol (SNMP)", RFC 2575, April 1999. 1152 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, 1153 "Introduction to Version 3 of the Internet-standard 1154 Network Management Framework", RFC 2570, April 1999. 1156 6. Security Considerations 1158 Security issues are discussed in Section 2.1.2. 1160 7. Authors' Addresses 1162 Bob Stewart 1163 Cisco Systems, Inc. 1164 170 West Tasman Drive 1165 San Jose, CA 95134-1706 1166 U.S.A. 1168 Ramanathan Kavasseri 1169 Cisco Systems, Inc. 1170 170 West Tasman Drive 1171 San Jose, CA 95134-1706 1172 U.S.A. 1174 Phone: +1 408 527 2446 1175 EMail: ramk@cisco.com 1177 8. Full Copyright Statement 1179 Copyright (C) The Internet Society (2003). All Rights Reserved. 1181 This document and translations of it may be copied and furnished to 1182 others, and derivative works that comment on or otherwise explain it 1183 or assist in its implementation may be prepared, copied, published 1184 and distributed, in whole or in part, without restriction of any 1185 kind, provided that the above copyright notice and this paragraph are 1186 included on all such copies and derivative works. However, this 1187 document itself may not be modified in any way, such as by removing 1188 the copyright notice or references to the Internet Society or other 1189 Internet organizations, except as needed for the purpose of 1190 developing Internet standards in which case the procedures for 1191 copyrights defined in the Internet Standards process must be 1192 followed, or as required to translate it into languages other than 1193 English. 1195 The limited permissions granted above are perpetual and will not be 1196 revoked by the Internet Society or its successors or assigns. 1198 This document and the information contained herein is provided on an 1199 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1200 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1201 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1202 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1203 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.