idnits 2.17.1 draft-ietf-snmpv3-appl-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 67 longer pages, the longest (page 3) being 60 lines 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 22 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([SNMP-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 576: '...P manageable, it MUST use the manageme...' RFC 2119 keyword, line 833: '...e SNMP manageable, it MUST use the MIB...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2733 has weird spacing: '...tyLevel auth...' == Line 2734 has weird spacing: '...tDomain snmp...' == Line 2740 has weird spacing: '...tyLevel priv...' == Line 2743 has weird spacing: '...tDomain snmp...' -- 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 (August 1997) is 9751 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) == Unused Reference: 'RFC1157' is defined on line 2611, but no explicit reference was found in the text == Unused Reference: 'RFC1213' is defined on line 2617, but no explicit reference was found in the text == Unused Reference: 'RFC1902' is defined on line 2623, but no explicit reference was found in the text == Unused Reference: 'RFC1903' is defined on line 2630, but no explicit reference was found in the text == Unused Reference: 'SNMP-MPD' is defined on line 2663, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 2669, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) -- Duplicate reference: RFC1905, mentioned in 'RFC1907', was also mentioned in 'RFC1905'. ** Obsolete normative reference: RFC 1905 (ref. 'RFC1907') (Obsoleted by RFC 3416) -- Duplicate reference: RFC1905, mentioned in 'RFC1908', was also mentioned in 'RFC1907'. ** Obsolete normative reference: RFC 1905 (ref. 'RFC1908') (Obsoleted by RFC 3416) == Outdated reference: A later version (-06) exists of draft-ietf-snmpv3-next-gen-arch-04 == Outdated reference: A later version (-05) exists of draft-ietf-snmpv3-mpc-03 == Outdated reference: A later version (-04) exists of draft-ietf-snmpv3-acm-02 Summary: 19 errors (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft SNMPv3 Applications August 1997 3 SNMPv3 Applications 5 August 1, 1997 7 9 David B. Levi 10 SNMP Research, Inc. 11 levi@snmp.com 13 Paul Meyer 14 Secure Computing Corporation 15 paul_meyer@securecomputing.com 17 Bob Stewart 18 Cisco Systems 19 bstewart@cisco.com 21 Status of this Memo 23 This document is an Internet-Draft. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as ``work in progress.'' 33 To learn the current status of any Internet-Draft, please check the 34 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 35 Directories on ds.internic.net (US East Coast), nic.nordu.net 36 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 37 Rim). 39 1. Abstract 41 This memo describes the various types of SNMP applications which make 42 use of an SNMP engine as described in [SNMP-ARCH]. There are five 43 types of application described herein: 45 - Applications which initiate SNMP Get, GetNext, GetBulk, and/or 46 Set requests, called 'command generators'. 48 - Applications which respond to SNMP Get, GetNext, GetBulk, 49 and/or Set requests, called 'command responders'. 51 - Applications which generate notifications, called 52 'notification originators'. 54 - Applications which receive notifications, called 'notification 55 receivers'. 57 - Applications which forward SNMP Get, GetNext, GetBulk, and/or 58 Set requests or notifications, called 'proxy forwarders'. 60 This memo also defines MIBs for specifying targets of management 61 operations, for notification filtering, and for proxy forwarding. 63 2. Overview 65 This document describes the five types of SNMP applications: 67 - Applications which initiate SNMP Get, GetNext, GetBulk, and/or 68 Set requests, called 'command generators'. 70 - Applications which respond to SNMP Get, GetNext, GetBulk, 71 and/or Set requests, called 'command responders'. 73 - Applications which generate notifications, called 74 'notification originators'. 76 - Applications which receive notifications, called 'notification 77 receivers'. 79 - Applications which forward SNMP Get, GetNext, GetBulk, and/or 80 Set requests or notifications, called 'proxy forwarder'. 82 Note that there are no restrictions on which types of applications 83 may be associated with a particular SNMP engine. For example, a 84 single SNMP engine may in fact be associated with both command 85 generator and command responder applications. 87 2.1. Command Generators 89 A command generator application initiates SNMP Get, GetNext, GetBulk, 90 and/or Set requests, as well as processing the response to a request 91 which it generated. 93 2.2. Command Responders 95 A command responder application receives SNMP Get, GetNext, GetBulk, 96 and/or Set requests for which the contextEngineID is equal to that of 97 the local engine through which the request was received. The command 98 responder will perform the appropriate protocol operation, using 99 access control, and will generate a response message to be sent to 100 the request's originator. 102 2.3. Notification Originators 104 A notification originator conceptually monitors a system for 105 particular events or conditions, and generates Trap and/or Inform 106 messages based on these events or conditions. A notification 107 originator must have a mechanism for determining where to send 108 messages, and what SNMP version and security parameters to use when 109 sending messages. A mechanism and MIB for this purpose is provided 110 in this document. 112 2.4. Notification Receivers 114 A notification receiver application listens for notification 115 messages, and generates response messages when a message containing 116 an Inform PDU is received. 118 2.5. Proxy Forwarder 120 A proxy forwarder application forwards SNMP messages. Note that 121 implementation of a proxy forwarder application is optional. The 122 sections describing proxy (4.5, 5.3, and 8) may be skipped for 123 implementations that do not include a proxy forwarder application. 125 The term "proxy" has historically been used very loosely, with 126 multiple different meanings. These different meanings include (among 127 others): 129 (1) the forwarding of SNMP requests to other SNMP entities without 130 regard for what managed object types are being accessed; for 131 example, in order to forward an SNMP request from one transport 132 domain to another, or to translate SNMP requests of one version 133 into SNMP requests of another version; 135 (2) the translation of SNMP requests into operations of some non-SNMP 136 management protocol; and 138 (3) support for aggregated managed objects where the value of one 139 managed object instance depends upon the values of multiple other 140 (remote) items of management information. 142 Each of these scenarios can be advantageous; for example, support for 143 aggregation of management information can significantly reduce the 144 bandwidth requirements of large-scale management activities. 145 However, using a single term to cover multiple different scenarios 146 causes confusion. 148 To avoid such confusion, this document uses the term "proxy" with a 149 much more tightly defined meaning. The term "proxy" is used in this 150 document to refer to a proxy forwarder application which forwards 151 either SNMP requests, notifications, and responses without regard for 152 what managed objects are contained within requests or notifications. 153 This definition is most closely related to the first definition 154 above. Note however that in the SNMP architecture [SNMP-ARCH], a 155 proxy forwarder is actually an application, and need not be 156 associated with what is traditionally thought of as an SNMP agent. 158 Specifically, the distinction between a traditional SNMP agent and a 159 "proxy forwarder application" is simple: 161 - a proxy forwarder application forwards requests and/or 162 notifications on to other SNMP engines according to the 163 context, and irrespective of the specific managed object types 164 being accessed, and forwards the response to such previously 165 forwarded messages back to the SNMP engine from which the 166 original message was received; 168 - in contrast, the command responder application that is part of 169 what is traditionally thought of as an SNMP agent, and which 170 processes SNMP requests according to the (names of the) 171 individual managed object types and instances being accessed, 172 is NOT a proxy forwarder application from the perspective of 173 this document. 175 Thus, when a proxy forwarder application forwards a request or 176 notification for a particular context, not only is the information on 177 how to forward the request specifically associated with that context, 178 but the proxy forwarder application has no need of a detailed 179 definition of a MIB view (since the proxy forwarder application 180 forwards the request irrespective of the managed object types). 182 In contrast, a command responder application must have the detailed 183 definition of the MIB view, and even if it needs to issue requests to 184 other SNMP entities, that need is dependent on the individual managed 185 object instances being accessed (i.e., not only on the context). 187 3. Management Targets 189 Some types of applications (in particular notification generators and 190 proxy forwarders) require a mechanism for determining where and how 191 to send generated messages. This document provides a mechanism and 192 MIB for this purpose. The set of information that describes where 193 and how to send a message is called a 'Management Target', and 194 consists of two kinds of information: 196 - Destination information, consisting of a transport domain and 197 a transport address. This is also termed a transport 198 endpoint. 200 - SNMP information, consisting of message processing model, 201 security model, level of security, and security name 202 information. 204 There can be a many-to-many relationship between these two types of 205 information. That is, there may be multiple transport endpoints 206 associated with a particular set of SNMP information, or a particular 207 transport endpoint may be associated with several sets of SNMP 208 information. 210 A management target is defined as the combination of a single set of 211 SNMP information and a single transport endpoint. Management targets 212 are grouped according to their SNMP information. That is, each 213 distinct set of SNMP information may be associated with multiple 214 transport endpoints. The set of management targets which are defined 215 by a distinct set of SNMP information are considered to be members of 216 the same management target group. For example, the following 217 contains two management target groups, each of which contains three 218 management targets: 220 (version=snmpv3, secmodel=usm, secname=joe, udp=128.1.2.3:162) 221 (version=snmpv3, secmodel=usm, secname=joe, udp=128.1.3.5:162) 222 (version=snmpv3, secmodel=usm, secname=joe, udp=128.1.4.7:162) 223 (version=snmpv3, secmodel=usm, secname=martha, udp=128.1.2.3:162) 224 (version=snmpv3, secmodel=usm, secname=martha, udp=128.1.3.5:162) 225 (version=snmpv3, secmodel=usm, secname=martha, udp=128.1.4.7:162) 227 An application will generally make use of some subset of the entire 228 set of management targets which are configured. 230 4. Elements Of Procedure 232 The following sections describe the procedures followed by each type 233 of application when generating messages for transmission or when 234 processing received messages. Applications communicate with the 235 Message Processing Subsystem using the abstract service interfaces 236 defined in [SNMP-ARCH]. 238 4.1. Command Generators 240 A command generator initiates an SNMP request by calling the Message 241 Processing Subsystem using the following abstract service interface: 243 statusInformation = -- sendPduHandle if success 244 -- errorIndication if failure 245 sendPdu( 246 IN transportDomain -- transport domain to be used 247 IN transportAddress -- destination network address 248 IN messageProcessingModel -- typically, SNMP version 249 IN securityModel -- Security Model to use 250 IN securityName -- on behalf of this principal 251 IN securityLevel -- Level of Security requested 252 IN contextEngineID -- data from/at this entity 253 IN contextName -- data from/in this context 254 IN pduVersion -- the version of the PDU 255 IN PDU -- SNMP Protocol Data Unit 256 IN expectResponse -- TRUE or FALSE 257 ) 259 Where: 261 - The transportDomain is that of the destination of the message. 263 - The transportAddress is the destination of the message. 265 - The messageProcessingModel indicates which Message Processing 266 Subsystem the application wishes to use. 268 - The securityModel is the security model that the application 269 wishes to use. 271 - The securityName is whatever the security model wishes to use. 273 - The securityLevel is the security level that the application 274 wishes to use. 276 - The contextEngineID is provided by the command generator if it 277 wishes to explicitly specify the location of the management 278 information it is requesting. 280 - The contextName is provided by the command generator if it 281 wishes to explicitly specify the local context name for the 282 management information it is requesting. The command 283 generator may omit this parameter, in which case the default 284 context is used. 286 - The pduVersion indicates the version of the PDU to be sent. 288 - The PDU is a value contructed by the command generator 289 containing the management operation that the command generator 290 wishes to perform. 292 - The expectResponse argument indicates that a response is 293 expected. 295 The result of the sendPdu interface indicates whether the PDU was 296 successfully sent. If it was successfully sent, the returned value 297 will be a sendPduHandle. The command generator should store the 298 sendPduHandle so that it can correlate a response to the original 299 request. 301 The Message Processing Subsystem is responsible for delivering the 302 response to a particular request to the correct command generator 303 application. The abstract service interface used is: 305 processResponsePdu( -- process Response PDU 306 IN messageProcessingModel -- typically, SNMP version 307 IN securityModel -- Security Model in use 308 IN securityName -- on behalf of this principal 309 IN securityLevel -- Level of Security 310 IN contextEngineID -- data from/at this SNMP entity 311 IN contextName -- data from/in this context 312 IN pduVersion -- the version of the PDU 313 IN PDU -- SNMP Protocol Data Unit 314 IN statusInformation -- success or errorIndication 315 IN sendPduHandle -- handle from sendPDU 316 ) 318 Where: 320 - The messageProcessingModel is the value from the received 321 response. 323 - The securityModel is the value from the received response. 325 - The securityName is the value from the received response. 327 - The securityLevel is the value from the received response. 329 - The contextEngineID is the value from the received response. 331 - The contextName is the value from the received response. 333 - The pduVersion indicates the version of the PDU in the 334 received response. 336 - The PDU is the value from the received response. 338 - The statusInformation indicates success or failure in 339 receiving the response. 341 - The sendPduHandle is the value returned by the sendPdu call 342 which generated the original request to which this is a 343 response. 345 The procedure when a command generator receives a response is as 346 follows: 348 (1) The operation type is determined from the ASN.1 tag value 349 associated with the PDU parameter. The operation type should 350 always be a Response PDU (the Message Processing Subsystem should 351 never call a command generator application using the 352 processResponsePdu interface for any other type of message). 354 (2) The request-id, error-status, error-index, and variable-bindings 355 are extracted from the PDU and saved. 357 (3) At this point, it is up to the application as to how to continue 358 processing the PDU. 360 4.2. Command Responders 362 Before a command responder application can process messages, it must 363 first associate itself with an SNMP engine. The abstract service 364 interface used for this purpose is: 366 statusInformation = -- success or errorIndication 367 registerContextEngineID( 368 IN contextEngineID -- take responsibility for this one 369 IN pduType -- the pduType(s) to be registered 370 ) 372 Where: 374 - The statusInformation indications success or failure of the 375 registration attempt. 377 - The contextEngineID is equal to the snmpEngineID of the SNMP 378 engine with which the command responder is registering. 380 - The pduType indicates a Get, GetNext, GetBulk, or Set pdu. 382 Note that if another command responder application is already 383 registered with an SNMP engine, any further attempts to register with 384 the same contextEngineID and pduType will be ignored. This implies 385 that separate command responder applications could register 386 separately for the various pdu types. However, in practice this is 387 undesirable, and only a single command responder application should 388 be registered with an SNMP engine at any given time. 390 A command responder application can disassociate with an SNMP engine 391 using the following abstract service interface: 393 unregisterContextEngineID( 394 IN contextEngineID -- give up responsibility for this one 395 IN pduType -- the pduType(s) to be unregistered 396 ) 398 Where: 400 - The contextEngineID is equal to the snmpEngineID of the SNMP 401 engine with which the command responder is cancelling the 402 registration. 404 - The pduType indicates a Get, GetNext, GetBulk, or Set pdu. 406 Once the command responder has registered with the SNMP engine, it 407 waits to receive SNMP messages. The abstract service interface used 408 for receiving messages is: 410 processPdu( -- process Request/Notification PDU 411 IN messageProcessingModel -- typically, SNMP version 412 IN securityModel -- Security Model in use 413 IN securityName -- on behalf of this principal 414 IN securityLevel -- Level of Security 415 IN contextEngineID -- data from/at this SNMP entity 416 IN contextName -- data from/in this context 417 IN pduVersion -- the version of the PDU 418 IN PDU -- SNMP Protocol Data Unit 419 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 420 IN stateReference -- reference to state information 421 ) -- needed when sending a response 423 Where: 425 - The messageProcessingModel indicates which Message Processing 426 subsystem received and processed the message. 428 - The securityModel is the value from the received message. 430 - The securityName is the value from the received message. 432 - The securityLevel is the value from the received message. 434 - The contextEngineID is the value from the received message. 436 - The contextName is the value from the received message. 438 - The pduVerion indicates the version of the PDU in the received 439 message. 441 - The PDU is the value from the received message. 443 - The maxSizeResponseScopedPDU is the value from the received 444 message. 446 - The stateReference is a value assigned by the Message 447 Processing Subsystem, which caches information about each 448 received request message. The stateReference is a reference 449 to this cached information. This value must be returned to 450 the Message Processing Subsystem in order to generate a 451 response. 453 The procedure when a message is received is as follows. 455 (1) The operation type is determined from the ASN.1 tag value 456 associated with the PDU parameter. The operation type should 457 always be a Get, GetNext, GetBulk, or Set. 459 (2) The request-id is extracted from the PDU and saved. 461 (3) If the SNMPv2 operation type is GetBulk, the non-repeaters and 462 max-repetitions values are extracted from the PDU and saved. 464 (4) The variable-bindings are extracted from the PDU and saved. 466 (5) The management operation represented by the SNMPv2 operation type 467 is performed with respect to the relevant MIB view within the 468 context named by the contextName, according to the procedures set 469 forth in [RFC1905]. The relevant MIB view is determined by the 470 securityLevel, securityModel, contextName, securityName, and SNMPv2 471 operation type. To determine whether a particular object instance 472 is within the relevant MIB view, the following abstract service 473 interface is called: 475 statusInformation = -- success or errorIndication 476 isAccessAllowed( 477 IN securityModel -- Security Model in use 478 IN securityName -- principal who wants to access 479 IN securityLevel -- Level of Security 480 IN viewType -- read, write, or notify view 481 IN contextName -- context containing variableName 482 IN variableName -- OID for the managed object 483 ) 485 Where: 487 - The securityModel is the value from the received message. 489 - The securityName is the value from the received message. 491 - The securityLevel is the value from the received message. 493 - The viewType indicates whether the pdu type is a read or write 494 operation. 496 - The contextName is the value from the received message. 498 - The variableName is the object instance of the variable for 499 which access rights are to be checked. 501 Normally, the result of the management operation will be a new PDU 502 value, and processing will continue in step (6) below. However, if 503 at any time during the processing of the management operation, the 504 context named by the contextName parameter is unavailable, 505 processing of the management operation is halted, no result PDU is 506 generated, the snmpUnavailableContexts counter is incremented, and 507 control is passed to step (6) below. 509 (6) The Message Processing Subsystem is called to generate a response 510 or report message. The abstract service interface is: 512 returnResponsePdu( 513 IN messageProcessingModel -- typically, SNMP version 514 IN securityModel -- Security Model in use 515 IN securityName -- on behalf of this principal 516 IN securityLevel -- same as on incoming request 517 IN contextEngineID -- data from/at this SNMP entity 518 IN contextName -- data from/in this context 519 IN pduVersion -- the version of the PDU 520 IN PDU -- SNMP Protocol Data Unit 521 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 522 IN stateReference -- reference to state information 523 -- as presented with the request 524 IN statusInformation -- success or errorIndication 525 ) -- error counter OID/value if error 527 Where: 529 - The messageProcessingModel is the value from the processPdu 530 call. 532 - The securityModel is the value from the processPdu call. 534 - The securityName is the value from the processPdu call. 536 - The securityLevel is the value from the processPdu call. 538 - The contextEngineID is the value from the processPdu call. 540 - The contextName is the value from the processPdu call. 542 - The pduVersion indicates the version of the PDU to be 543 returned. If no result PDU was generated, the pduVersion is 544 an undefined value. 546 - The PDU is the result generated in step (5) above. If no 547 result PDU was generated, the PDU is an undefined value. 549 - The maxSizeResponseScopedPDU is a local value indicating the 550 maximum size of a ScopedPDU that the application can accept. 552 - The stateReference is the value from the processPdu call. 554 - The statusInformation either contains an indication that no 555 error occured and that a response should be generated, or 556 contains an indication that an error occured along with the 557 OID and counter value of the snmpUnavailableContexts object. 559 Note that a command responder application should always call the 560 returnResponsePdu abstract service interface, even in the event of an 561 error such as a resource allocation error. In the event of such an 562 error, the PDU value passed to returnResponsePdu should contain 563 appropriate values for errorStatus and errorIndex. 565 4.3. Notification Originators 567 A notification originator application generates SNMP notification 568 messages. A notification message can contain either an SNMPv2-Trap 569 PDU or an Inform PDU. However, a particular implementation is not 570 required to be capable of generating both types of messages. 572 Notification originator applications require a mechanism for 573 identifying the management targets to which notifications should be 574 sent. The particular mechanism used is implementation dependent, 575 however, if an implementation makes the configuration of management 576 targets SNMP manageable, it MUST use the management target MIB 577 described in this document. 579 When a notification originator wishes to generate a notification, it 580 must first determine in which context the information to be conveyed 581 in the notification exists, i.e., it must determine the 582 contextEngineID and contextName. It must then determine the set of 583 management targets to which the notification should be sent, and the 584 grouping of these management targets. The application must also 585 determine, for each group of management targets, whether the 586 notification message should contain an SNMPv2-Trap PDU or Inform PDU, 587 and if it is to contain an Inform PDU, the number of retries and 588 retransmission algorithm. 590 The mechanism by which a notification originator determines this 591 information is implementation dependent. Once the application has 592 determined this information, the following procedure is performed for 593 each group of management targets: 595 (1) Any appropriate filtering mechanisms are applied to determine 596 whether the notification should be sent to the management targets 597 in this group. If such filtering mechanisms determine that the 598 notification should not be sent, processing continues with the next 599 group of management targets. Otherwise, 601 (2) The appropriate set of variable-bindings is retrieved from local 602 MIB instrumentation within the relevant MIB view. The relevant MIB 603 view is determined by the securityLevel, securityModel, 604 contextName, and securityName of the management target. To 605 determine whether a particular object instance is within the 606 relevant MIB view, the isAccessAllowed abstract service interface 607 is used, in the same manner as described in the preceeding section. 608 If the statusInformation returned by isAccessAllowed does not 609 indicate accessAllowed, the notification is not sent to any of the 610 management targets within this group. 612 (3) A PDU is constructed using a locally unique request-id value, an 613 operation type of Trap or Inform, an error-status and error-index 614 value of 0, and the variable-bindings supplied previously in step 615 (2). 617 (4) If the notification should contain an SNMPv2-Trap PDU for this 618 group, then for each management target in the group, the Message 619 Processing Subsystem is called using the following abstract service 620 interface: 622 statusInformation = -- sendPduHandle if success 623 -- errorIndication if failure 624 sendPdu( 625 IN transportDomain -- transport domain to be used 626 IN transportAddress -- destination network address 627 IN messageProcessingModel -- typically, SNMP version 628 IN securityModel -- Security Model to use 629 IN securityName -- on behalf of this principal 630 IN securityLevel -- Level of Security requested 631 IN contextEngineID -- data from/at this entity 632 IN contextName -- data from/in this context 633 IN pduVersion -- the version of the PDU 634 IN PDU -- SNMP Protocol Data Unit 635 IN expectResponse -- TRUE or FALSE 636 ) 638 Where: 640 - The transportDomain is that of the management target. 642 - The transportAddress is that of the management target. 644 - The messageProcessingModel is that of the management target. 646 - The securityModel is that of the management target. 648 - The securityName is that of the management target. 650 - The securityLevel is that of the management target. 652 - The contextEngineID is the value originally determined for the 653 notification. 655 - The contextName is the value originally determined for the 656 notification. 658 - The pduVersion is the version of the PDU to be sent. 660 - The PDU is the value constructed in step (3) above. 662 - The expectResponse argument indicates that no response is 663 expected. 665 Otherwise, 667 (5) If the notification should contain an Inform PDU for this group, 668 then: 670 a) For each management target in the group, the Message 671 Processing Subsystem is called using the sendPdu abstract 672 service interface as described in step (4) above, except that 673 the expectResponse arguments indicates that a response is 674 expected. 676 b) The application caches information about the management 677 target group. 679 c) If a response is received within an appropriate time interval 680 from any one transport endpoint within the group, the 681 notification is considered acknowledged for this group, the 682 cached information is deleted, and any further responses to 683 this Inform are ignored. Otherwise, 685 d) If a response is not received within an appropriate time 686 period, information about the management target group is 687 retrieved from the cache, and steps a) through d) are 688 repeated. The number of times these steps are repeated is as 689 previously determined. If this retry count is exceeded, the 690 acknowledgement of the notification is considered to have 691 failed, and processing of the notification for this group of 692 management targets is halted. 694 Responses to Inform PDU notifications will be received via the 695 processResponsePDU abstract service interface. 697 4.4. Notification Receivers 699 Notification receiver applications receive SNMP Notification messages 700 from the Message Processing Subsystem. Before any messages can be 701 received, the notification receiver must register with the Message 702 Processing Subsystem using the registerContextEngineID abstract 703 service interface. The parameters used are: 705 - The contextEngineID is an undefined 'wildcard' value. 706 Notifications are delivered to a registered notification 707 receiver regardless of the contextEngineID contained in the 708 notification message. 710 - The pduType indicates either SNMPv2-Trap PDUs or Inform PDUs, 711 or both. 713 Once the notification receiver has registered with the Message 714 Processing Subsystem, messages are received using the processPdu 715 abstract service interface. Parameters are: 717 - The messageProcessingModel indicates which Message Processing 718 subsystem received and processed the message. 720 - The securityModel is the value from the received message. 722 - The securityName is the value from the received message. 724 - The securityLevel is the value from the received message. 726 - The contextEngineID is the value from the received message. 728 - The contextName is the value from the received message. 730 - The pduVerion indicates the version of the PDU in the received 731 message. 733 - The PDU is the value from the received message. 735 - The maxSizeResponseScopedPDU is the value from the received 736 message. 738 - If the message contains an SNMPv2-Trap PDU, the stateReference 739 is undefined and unused. Otherwise, the stateReference is a 740 value assigned by the Message Processing Subsystem which 741 references cached information about the notification. This 742 value must be returned to the Message Processing Subsystem in 743 order to generate a response. 745 When an SNMPv2-Trap PDU is delivered to a notification receiver 746 application, it first extracts the SNMP operation type, request-id, 747 error-status, error-index, and variable-bindings from the PDU. After 748 this, processing depends on the particular implementation. 750 When an Inform PDU is received, the notification receiver application 751 follows the following procedure: 753 (1) The SNMPv2 operation type, request-id, error-status, error-index, 754 and variable-bindings are extracted from the PDU. 756 (2) A Response PDU is constructed using the extracted request-id and 757 variable-bindings, and with error-status and error-index both set 758 to 0. 760 (3) The Message Processing Subsystem is called to generate a response 761 message using the returnResponsePdu abstract service interface. 762 Parameters are: 764 - The messageProcessingModel is the value from the processPdu 765 call. 767 - The securityModel is the value from the processPdu call. 769 - The securityName is the value from the processPdu call. 771 - The securityLevel is the value from the processPdu call. 773 - The contextEngineID is the value from the processPdu call. 775 - The contextName is the value from the processPdu call. 777 - The pduVersion indicates the version of the PDU to be 778 returned. 780 - The PDU is the result generated in step (2) above. 782 - The maxSizeResponseScopedPDU is a local value indicating the 783 maximum size of a ScopedPDU that the application can accept. 785 - The stateReference is the value from the processPdu call. 787 - The statusInformation indicates that no error occured and that 788 a response should be generated. 790 Note that there may be multiple notification receiver applications 791 associated with a particular SNMP engine. Despite this, only a 792 single response should be generated when an Inform PDU is received. 793 The mechanism to ensure this is implementation specific. One 794 strategy to accomplish this is to simply let the Message Processing 795 Subsystem delete the stateReference when the first response is 796 generated. Subsequent attempts to send the response will fail 797 because the stateReference no longer exists within the Message 798 Processing Subsystem. 800 4.5. Proxy Forwarders 802 A proxy forwarder application deals with forwarding messages which 803 contain Get, GetNext, GetBulk, Set, SNMPv2-Trap, Inform, and Response 804 PDUs. Of these PDU types, the first four (Get, GetNext, GetBulk, 805 Set) deal with requesting or modifying information located within a 806 particular context, and the next two (SNMPv2-Trap, Inform) deal with 807 notifications concerning information located within a particular 808 context. A proxy forwarder application treats these two situations 809 slightly different. Forwarding of Response PDUs always occurs as a 810 result of receiving a response to a previously forwarded message. 812 In the first situation, the proxy forwarder's role is ultimately to 813 deliver a request for management information to the SNMP engine which 814 has access to that information, and to deliver the response 815 containing the information back to the SNMP engine which initiated 816 the request. The context information in a request is used to 817 determine which SNMP engine has access to the requested information, 818 and this is used to determine where and how to forward the request. 820 In the second situation, the proxy forwarder's role is to determine 821 which SNMP engines should receive notification about management 822 information from a particular location. The context information in a 823 notification message determines the location to which the information 824 contained in the notification applies. This is used to determine 825 which SNMP engines should receive notification about this 826 information. 828 When forwarding messages, a proxy forwarder application must perform 829 a translation of incoming management target information into outgoing 830 management target information. How this translation is performed is 831 implementation specific. In many cases, this will be driven by a 832 preconfigured translation table. If a proxy forwarder application 833 makes the contents of this table SNMP manageable, it MUST use the MIB 834 defined in this document. 836 4.5.1. Request Forwarding 838 There are two phases for request forwarding. First the incoming 839 request needs to be passed through the proxy application. Then the 840 resulting resonse needs to be passed back. These phases are 841 described in the following two sections. 843 4.5.1.1. Processing an Incoming Request 845 A proxy forwarder application that wishes to forward request messages 846 must first register with the Message Processing Subsystem using the 847 registerContextEngineID abstract service interface. The proxy 848 forwarder must register each contextEngineID for which it wishes to 849 forward messages, as well as for each pduType. Note that as the 850 configuration of a proxy forwarder is changed, the particular 851 contextEngineID values for which it is forwarding may change. The 852 proxy forwarder should call the registerContextEngineID and 853 unregisterContextEngineID abstract service interfaces as needed to 854 reflect its current configuration. 856 A proxy forwarder application should never attempt to register a 857 value of contextEngineID which is equal to the snmpEngineID of the 858 SNMP engine to which the proxy forwarder is associated. 860 Once the proxy forwarder has registered for the appropriate 861 contextEngineId values, it can start processing messages. The 862 following procedure is used: 864 (1) A message is received using the processPdu abstract service 865 interface. The incoming management target information received 866 from the processPdu interface is translated into outgoing 867 management target information. Note that this translation may vary 868 for different values of contextEngineID and/or contextName. The 869 translation should result in a single management target. 871 (2) If appropriate outgoing management target information cannot be 872 found, the proxy forwarder increments the snmpProxyDrops counter 873 [RFC1907], and then calls the Message Processing Subsystem using 874 the returnResponsePdu abstract service interface. Parameters are: 876 - The messageProcessingModel is the value from the processPdu 877 call. 879 - The securityModel is the value from the processPdu call. 881 - The securityName is the value from the processPdu call. 883 - The securityLevel is the value from the processPdu call. 885 - The contextEngineID is the value from the processPdu call. 887 - The contextName is the value from the processPdu call. 889 - The pduVersion is an undefined value. 891 - The PDU is an undefined value. 893 - The maxSizeResponseScopedPDU is a local value indicating the 894 maximum size of a ScopedPDU that the application can accept. 896 - The stateReference is the value from the processPdu call. 898 - The statusInformation indicates that an error occured and that 899 an snmpProxyDrops Report message should be generated. 901 Processing of the message stops at this point. Otherwise, 903 (3) A new PDU is constructed. A unique value of request-id should be 904 used in the new PDU (this value will enable a subsequent response 905 message to be correlated with this request). The remainder of the 906 new PDU is identical to the received PDU, unless the incoming SNMP 907 version is SNMPv1 and the outgoing SNMP version is SNMPv2 or 908 SNMPv3, or vice-versa, in which case the proxy forwarder must apply 909 the translation rules as documented in [RFC1908]. 911 (4) The proxy forwarder calls the Message Processing Subsystem to 912 generate the forwarded message, using the sendPdu abstract service 913 interface. The parameters are: 915 - The transportDomain is that of the outgoing management target. 917 - The transportAddress is that of the outgoing management 918 target. 920 - The messageProcessingModel is that of the outgoing management 921 target. 923 - The securityModel is that of the outgoing management target. 925 - The securityName is that of the outgoing management target. 927 - The securityLevel is that of the outgoing management target. 929 - The contextEngineID is the value originally received. 931 - The contextName is the value originally received. 933 - The pduVersion is the version of the PDU to be sent. 935 - The PDU is the value constructed in step (3) above. 937 - The expectResponse argument indicates that a response is 938 expected. If the sendPdu call is unsuccessful, the proxy 939 forwarder performs the steps described in (2) above. 940 Otherwise: 942 (5) The proxy forwarder caches the contextEngineId, contextName, 943 stateReference, incoming management target information, outgoing 944 management information, and any other information needed to match 945 an incoming response to the forwarded request. If this information 946 cannot be cached (possibly due to a lack of resources), the proxy 947 forwarder performs the steps described in (2) above. Otherwise: 949 (6) Processing of the request stops until a response to the forwarded 950 request is received, or until an appropriate time interval has 951 expired. If this time interval expires before a response has been 952 received, the cached information about this request is removed, and 953 the proxy forwarder performs the steps described in (2) above using 954 the cached information. 956 4.5.1.2. Processing an Incoming Response 958 A proxy forwarder follows the following procedure when an incoming 959 response is received: 961 (1) The incoming response is received using the processPdu interface. 962 The proxy forwarder uses the received parameters to locate an entry 963 in its cache of pending forwarded requests. This is done by 964 matching the received parameters with the cached values of 965 contextEngineID, contextName, outgoing management target 966 information, and the request-id contained in the received PDU (the 967 proxy forwarder must extract the request-id for this purpose). If 968 an appropriate cache entry cannot be found, processing of the 969 response is halted. Otherwise: 971 (2) The cache information is extracted, and removed from the cache. 973 (3) If the incoming SNMP version is SNMPv1 and the outgoing SNMP 974 version is SNMPv2 or SNMPv3, or vice-versa, the proxy forwarder 975 must apply the translation rules documented in [RFC1908]. 977 (4) The proxy forwarder calls the Message Processing Subsystem using 978 the returnResponsePdu abstract service interface. Parameters are: 980 - The messageProcessingModel indicates the MessageProcessing 981 subsystem from which the original incoming message was 982 received. 984 - The securityModel is that of the original incoming management 985 target extracted from the cache. 987 - The securityName is that of the original incoming management 988 target extracted from the cache. 990 - The securityLevel is that of the original incoming management 991 target extracted from the cache. 993 - The contextEngineID is the value extracted from the cache. 995 - The contextName is the value extracted from the cache. 997 - The pduVersion indicates the version of the PDU to be 998 returned. 1000 - The PDU is the (possibly translated) Response PDU. 1002 - The maxSizeResponseScopedPDU is a local value indicating the 1003 maximum size of a ScopedPDU that the application can accept. 1005 - The stateReference is the value extracted from the cache. 1007 - The statusInformation indicates that no error occured and that 1008 a Response PDU message should be generated. 1010 4.5.2. Notification Forwarding 1012 A proxy forwarder receives notifications in the same manner as a 1013 notification receiver application, using the processPdu abstract 1014 service interface. The following procedure is used when a 1015 notification is received: 1017 (1) The incoming management target information received from the 1018 processPdu interface is translated into outgoing management target 1019 information. Note that this translation may vary for different 1020 values of contextEngineId and/or contextName. The translation may 1021 result in one or more management target groups, each of which may 1022 contain multiple management targets. 1024 (2) If appropriate outgoing management target information cannot be 1025 found and the notification was a Trap, processing of the 1026 notification is halted. If appropriate outgoing management target 1027 information cannot be found and the notification was an Inform, the 1028 proxy forwarder increments the snmpProxyDrops object, and calls the 1029 Message Processing Subsystem using the returnResponsePdu abstract 1030 service interface. The parameters are: 1032 - The messageProcessingModel is the received value. 1034 - The securityModel is the received value. 1036 - The securityName is the received value. 1038 - The securityLevel is the received value. 1040 - The contextEngineID is the received value. 1042 - The contextName is the received value. 1044 - The pduVersion is an undefined and unused value. 1046 - The PDU is an undefined and unused value. 1048 - The maxSizeResponseScopedPDU is a local value indicating the 1049 maximum size of a ScopedPDU that the application can accept. 1051 - The stateReference is the received value. 1053 - The statusInformation indicates that an error occured and that 1054 a Report message should be generated. 1056 Processing of the message stops at this point. Otherwise, 1058 (3) The proxy forwarder generates a notification using the procedures 1059 described in the preceeding section on Notification Originators, 1060 with the following exceptions: 1062 - The contextEngineID and contextName values from the original 1063 received notification are used. 1065 - The outgoing management targets previously determined are 1066 used. 1068 - No filtering mechanisms are applied. 1070 - The variable-bindings from the original received notification 1071 are used, rather than retrieving variable-bindings from local 1072 MIB instrumentation. In particular, no access-control is 1073 applied to these variable-bindings. 1075 - If for any of the outgoing management targets, the incoming 1076 SNMP version is SNMPv1 and the outgoing SNMP version is SNMPv2 1077 or SNMPv3, the proxy forwarder must apply the translation 1078 rules as documented in [RFC1908]. 1080 - If for any of the outgoing management targets, the incoming 1081 SNMP version is SNMPv2 or SNMPv3, and the outgoing SNMP 1082 version is SNMPv1, this outgoing management target is not used 1083 when generating the forwarded notifications. 1085 (4) If the original received notification contains an SNMPv2-Trap PDU, 1086 processing of the notification is now completed. Otherwise, the 1087 original received notification must contain an Inform PDU, and 1088 processing continues. 1090 (5) If the forwarded notifications included any Inform PDUs, processing 1091 continues when the procedures described in the section for 1092 Notification Originators determine that either: 1094 - None of the generated notifications containing Inform PDUs 1095 have been successfully acknowledged within the longest of the 1096 time intervals, in which case processing of the original 1097 notification is halted, or, 1099 - At least one of the generated notifications containing Inform 1100 PDUs is successfully acknowledged, in which case a response to 1101 the original received notification containing an Inform PDU is 1102 generated as described in the following steps. 1104 (6) A Response PDU is constructed, using the values of request-id and 1105 variable-bindings from the original received Inform PDU, and 1106 error-status and error-index values of 0. 1108 (7) The Message Processing Subsystem is called using the 1109 returnResponsePdu abstract service interface. Parameters are: 1111 - The messageProcessingModel is the originally received value. 1113 - The securityModel is the originally received value. 1115 - The securityName is the originally received value. 1117 - The securityLevel is the originally received value. 1119 - The contextEngineID is the originally received value. 1121 - The contextName is the originally received value. 1123 - The pduVersion indicates the version of the PDU constructed in 1124 step (6) above. 1126 - The PDU is the value constructed in step (6) above. 1128 - The maxSizeResponseScopedPDU is a local value indicating the 1129 maximum size of a ScopedPDU that the application can accept. 1131 - The stateReference is the originally received value. 1133 - The statusInformation indicates that no error occured and that 1134 a Response PDU message should be generated. 1136 5. The Structure of the MIBs 1138 There are three separate MIBs described in this document, the 1139 management target MIB, the notification MIB, and the proxy MIB. The 1140 following sections describe the structure of these three MIBs. 1142 5.1. The Management Target MIB 1144 This MIB contains objects for defining management targets. It 1145 consists of one scalar, two tables, and conformance/compliance 1146 statements. 1148 The scalar, snmpTargetAddressSpinLock, is used by managers when 1149 creating new rows in the snmpTargetAddrTable. 1151 The first table, the snmpTargetAddrTable, contains information about 1152 transport domains/addresses. The table is indexed by an 1153 SnmpAdminString type object and an integer type object. This allows 1154 domains/addresses to be organized into groups. 1156 The second table, the snmpTargetTable, contains information about 1157 SNMP version and security information to be used when sending 1158 messages to a particular group of transport domains/addresses. 1160 5.1.1. Definitions 1162 SNMPV3-TARGET-MIB DEFINITIONS ::= BEGIN 1164 IMPORTS 1165 MODULE-IDENTITY, 1166 OBJECT-TYPE, 1167 OBJECT-IDENTITY, 1168 Integer32 1169 FROM SNMPv2-SMI 1171 TDomain, 1172 TAddress, 1173 TruthValue, 1174 TimeInterval, 1175 RowStatus, 1176 StorageType 1177 FROM SNMPv2-TC 1179 SnmpSecurityModel, 1180 SnmpMessageProcessingModel, 1181 SnmpSecurityLevel, 1182 SnmpAdminString 1183 FROM SNMP-FRAMEWORK-MIB 1185 MODULE-COMPLIANCE, 1186 OBJECT-GROUP 1187 FROM SNMPv2-CONF; 1189 snmpTargetMIB MODULE-IDENTITY 1190 LAST-UPDATED "9707140000Z" 1191 ORGANIZATION "IETF SNMPv3 Working Group" 1192 CONTACT-INFO 1193 "David B. Levi 1194 SNMP Research, Inc. 1195 3001 Kimberlin Heights Road 1196 Knoxville, TN 37920-9716 1197 Tel: +1 423 573 1434 1198 E-mail: levi@snmp.com 1200 Paul Meyer 1201 Secure Computing Corporation 1202 2675 Long Lake Road 1203 Roseville, MN 55113 1204 Tel: +1 612 628 1592 1205 E-mail: paul_meyer@securecomputing.com 1207 Bob Stewart 1208 Cisco Systems, Inc. 1209 170 West Tasman Drive 1210 San Jose, CA 95134-1706 1211 Tel: +1 603 654 6923 1212 E-mail: bstewart@cisco.com" 1213 DESCRIPTION 1214 "This MIB module defines a MIB which provides mechanisms to 1215 remotely configure the parameters used by an SNMPv3 entity 1216 for the generation of notifications." 1217 REVISION "9707140000Z" 1218 DESCRIPTION 1219 "The initial revision." 1220 ::= { snmpModules 11 } -- TBD 1222 snmpTargetObjects OBJECT IDENTIFIER ::= { snmpTargetMIB 1 } 1223 snmpTargetConformance OBJECT IDENTIFIER ::= { snmpTargetMIB 2 } 1225 -- ------------------------------------------------------------------ 1226 -- 1227 -- The snmpTargetObjects group 1228 -- 1229 -- ------------------------------------------------------------------ 1231 snmpTargetAddressSpinLock OBJECT-TYPE 1232 SYNTAX TestAndIncr 1233 MAX-ACCESS read-write 1234 STATUS current 1235 DESCRIPTION 1236 "This object is used to facilitate creation of rows in the 1237 snmpTargetAddrTable. There are two situations where an 1238 SNMP entity may wish to create a new row, when a new group 1239 of addresses must be created, and when an address must be 1240 added to an existing group. 1242 When an SNMP entity wishes to create a new group of 1243 addresses, it should follow the following procedure: 1244 a) Retrieve the value of this object. 1245 b) Retrieve all existing index values of 1246 snmpTargetAddrName (this can be accomplished 1247 by retrieving all instances of any accessible 1248 columnar object in the snmpTargetAddrTable). 1249 c) Retrieve the value of this object. If the value is 1250 not equal to the last retrieved value, go back to 1251 step b). 1252 d) Select a new unique index value for 1253 snmpTargetAddrName, and an arbitrary value for 1254 snmpTargetAddrSubIndex. Attempt a set request 1255 containing these varbinds: 1256 - The last retrieved value of this object. 1257 - An instance of the snmpTargetAddrRowStatus 1258 object whose indices are equal to the selected 1259 index values of snmpTargetAddrName and 1260 snmpTargetAddrSubIndex. 1261 - Additional varbinds for initializing other 1262 columnar objects in the row. 1263 If this set fails, the SNMP entity may return to 1264 step a) and try again. 1266 When an SNMP entity wishes to create a new address within 1267 an existing group of addresses, it should follow the 1268 following procedure: 1269 a) Retrieve all existing values of 1270 snmpTargetAddrSubIndex corresponding to the desired 1271 index value of snmpTargetAddrName. (this can be 1272 accomplished by retrieving all instances of any 1273 accessible columnar object in the 1274 snmpTargetAddrTable whose index begins with the 1275 desired index value of snmpTargetAddrName). 1276 b) Select a new value for snmpTargetAddrSubIndex. 1277 Attempt a set request containing these varbinds: 1278 - An instance of the snmpTargetAddrRowStatus 1279 object whose indices are equal to the desired 1280 index value of snmpTargetAddrName and the 1281 selected index value of snmpTargetAddrSubIndex. 1282 - Additional varbinds for initializing other 1283 columnar objects in the row. 1284 If this set fails, the SNMP entity may return to 1285 step a) and try again." 1286 ::= { snmpTargetObjects 1 } 1288 snmpTargetAddrTable OBJECT-TYPE 1289 SYNTAX SEQUENCE OF SnmpV3TargetAddrEntry 1290 MAX-ACCESS not-accessible 1291 STATUS current 1292 DESCRIPTION 1293 "A table of transport addresses to be used in the generation 1294 of SNMP messages. Addresses are organized into groups. 1295 Every member of a group shares a common snmpTargetAddrName." 1296 ::= { snmpTargetObjects 2 } 1298 snmpTargetAddrEntry OBJECT-TYPE 1299 SYNTAX SnmpV3TargetAddrEntry 1300 MAX-ACCESS not-accessible 1301 STATUS current 1302 DESCRIPTION 1303 "A transport address to be used in the generation 1304 of SNMP operations." 1305 INDEX { snmpTargetAddrName, snmpTargetAddrSubIndex } 1306 ::= { snmpTargetAddrTable 1 } 1308 SnmpV3TargetAddrEntry ::= SEQUENCE { 1309 snmpTargetAddrSubIndex Integer32, 1310 snmpTargetAddrTDomain TDomain, 1311 snmpTargetAddrTAddress TAddress, 1312 snmpTargetAddrTimeout TimeInterval, 1313 snmpTargetAddrStorageType StorageType, 1314 snmpTargetAddrRowStatus RowStatus 1315 } 1317 snmpTargetAddrSubIndex OBJECT-TYPE 1318 SYNTAX Integer32 (1..2147483647) 1319 MAX-ACCESS not-accessible 1320 STATUS current 1321 DESCRIPTION 1322 "The locally arbitrary, but unique identifier associated 1323 an snmpTargetAddrEntry within a group of entries in the 1324 snmpTargetAddrTable." 1325 ::= { snmpTargetAddrEntry 1 } 1327 snmpTargetAddrTDomain OBJECT-TYPE 1328 SYNTAX TDomain 1329 MAX-ACCESS read-create 1330 STATUS current 1331 DESCRIPTION 1332 "This object indicates the transport type of the address 1333 contained in the snmpTargetAddrTAddress object." 1334 ::= { snmpTargetAddrEntry 2 } 1336 snmpTargetAddrTAddress OBJECT-TYPE 1337 SYNTAX TAddress 1338 MAX-ACCESS read-create 1339 STATUS current 1340 DESCRIPTION 1341 "This object contains a transport address. The format of 1342 this address depends on the value of the 1343 snmpTargetAddrTDomain object." 1344 ::= { snmpTargetAddrEntry 3 } 1346 snmpTargetAddrTimeout OBJECT-TYPE 1347 SYNTAX TimeInterval 1348 MAX-ACCESS read-create 1349 STATUS current 1350 DESCRIPTION 1351 "This object should reflect the expected round trip time 1352 for communicating with the transport address defined by 1353 this row. When a message is sent to this address, and 1354 a response (if one is expected) is not received within 1355 this time period, an implementation may assume that the 1356 response will not be delivered. 1358 Note that the time interval that an application waits 1359 for a response may actually be derived from the value 1360 of this object. The method for deriving the actual time 1361 interval is implementation dependent. One such method 1362 is to derive the expected round trip time based on a 1363 particular retransmission algorithm and on the number 1364 of timeouts which have occured. The type of message may 1365 also be considered when deriving expected round trip 1366 times for retransmissions. For example, if a message is 1367 being sent with a securityLevel that indicates both 1368 authentication and privacy, the derived value may be 1369 increased to compensate for extra processing time spent 1370 during authentication and encryption processing." 1371 DEFVAL { 1500 } 1372 ::= { snmpTargetAddrEntry 4 } 1374 snmpTargetAddrStorageType OBJECT-TYPE 1375 SYNTAX StorageType 1376 MAX-ACCESS read-create 1377 STATUS current 1378 DESCRIPTION 1379 "The storage type for this conceptual row." 1380 ::= { snmpTargetAddrEntry 5 } 1382 snmpTargetAddrRowStatus OBJECT-TYPE 1383 SYNTAX RowStatus 1384 MAX-ACCESS read-create 1385 STATUS current 1386 DESCRIPTION 1387 "The status of this conceptual row. 1389 Until instances of all corresponding columns are 1390 appropriately configured, the value of the 1391 corresponding instance of the snmpTargetAddrRowStatus 1392 column is 'notReady'. 1394 In particular, a newly created row cannot be made 1395 active until the corresponding snmpTargetAddrTDomain 1396 and snmpTargetAddrTAddress have both been set." 1397 ::= { snmpTargetAddrEntry 6 } 1399 snmpTargetTable OBJECT-TYPE 1400 SYNTAX SEQUENCE OF SnmpV3TargetEntry 1401 MAX-ACCESS not-accessible 1402 STATUS current 1403 DESCRIPTION 1404 "A table of management target information to be used 1405 in the generation of SNMP messages." 1406 ::= { snmpTargetObjects 3 } 1408 snmpTargetEntry OBJECT-TYPE 1409 SYNTAX SnmpV3TargetEntry 1410 MAX-ACCESS not-accessible 1411 STATUS current 1412 DESCRIPTION 1413 "A set of management target information." 1414 INDEX { snmpTargetName } 1415 ::= { snmpTargetTable 1 } 1416 SnmpV3TargetEntry ::= SEQUENCE { 1417 snmpTargetName SnmpAdminString, 1418 snmpTargetAddrName SnmpAdminString, 1419 snmpTargetMessageProcessingModel SnmpMessageProcessingModel, 1420 snmpTargetSecurityModel SnmpSecurityModel, 1421 snmpTargetSecurityName SnmpAdminString, 1422 snmpTargetSecurityLevel SnmpSecurityLevel, 1423 snmpTargetRetryCount Integer32, 1424 snmpTargetStorageType StorageType, 1425 snmpTargetRowStatus RowStatus 1426 } 1428 snmpTargetName OBJECT-TYPE 1429 SYNTAX SnmpAdminString 1430 MAX-ACCESS not-accessible 1431 STATUS current 1432 DESCRIPTION 1433 "The locally arbitrary, but unique identifier associated 1434 with this snmpTargetEntry." 1435 ::= { snmpTargetEntry 1 } 1437 snmpTargetAddrName OBJECT-TYPE 1438 SYNTAX SnmpAdminString 1439 MAX-ACCESS read-create 1440 STATUS current 1441 DESCRIPTION 1442 "The group of addresses to which management operations will 1443 be sent when using this set of security parameters. The 1444 value of this object refers to a group of addresses 1445 in the snmpTargetAddrTable." 1446 ::= { snmpTargetEntry 2 } 1448 snmpTargetMessageProcessingModel OBJECT-TYPE 1449 SYNTAX SnmpMessageProcessingModel 1450 MAX-ACCESS read-create 1451 STATUS current 1452 DESCRIPTION 1453 "The Message Processing Model to be used when generating 1454 SNMP messages using this entry." 1455 ::= { snmpTargetEntry 3 } 1457 snmpTargetSecurityModel OBJECT-TYPE 1458 SYNTAX SnmpSecurityModel 1459 MAX-ACCESS read-create 1460 STATUS current 1461 DESCRIPTION 1462 "The Security Model to be used when generating SNMP 1463 messages using this entry." 1464 ::= { snmpTargetEntry 4 } 1466 snmpTargetSecurityName OBJECT-TYPE 1467 SYNTAX SnmpAdminString 1468 MAX-ACCESS read-create 1469 STATUS current 1470 DESCRIPTION 1471 "The securityName which identifies the Principal on 1472 whose behalf SNMP messages will be generated using 1473 this entry." 1474 ::= { snmpTargetEntry 5 } 1476 snmpTargetSecurityLevel OBJECT-TYPE 1477 SYNTAX SnmpSecurityLevel 1478 MAX-ACCESS read-create 1479 STATUS current 1480 DESCRIPTION 1481 "The Level of Security to be used when generating 1482 SNMP messages using this entry." 1483 ::= { snmpTargetEntry 6 } 1485 snmpTargetRetryCount OBJECT-TYPE 1486 SYNTAX Integer32 (0..2147483647) 1487 MAX-ACCESS read-create 1488 STATUS current 1489 DESCRIPTION 1490 "This object specifies a default number of retries to be 1491 attempted when a response is not received for a generated 1492 message. The number of retries is an indication of how 1493 important delivery of a particular message is considered. 1494 An application may provide its own retry count, in which 1495 case the value of this object is ignored." 1496 DEFVAL { 3 } 1497 ::= { snmpTargetEntry 7 } 1499 snmpTargetStorageType OBJECT-TYPE 1500 SYNTAX StorageType 1501 MAX-ACCESS read-create 1502 STATUS current 1503 DESCRIPTION 1504 "The storage type for this conceptual row." 1505 ::= { snmpTargetEntry 8 } 1507 snmpTargetRowStatus OBJECT-TYPE 1508 SYNTAX RowStatus 1509 MAX-ACCESS read-create 1510 STATUS current 1511 DESCRIPTION 1512 "The status of this conceptual row. 1514 Until instances of all corresponding columns are 1515 appropriately configured, the value of the 1516 corresponding instance of the snmpTargetRowStatus 1517 column is 'notReady'. 1519 In particular, a newly created row cannot be made 1520 active until the corresponding 1521 snmpTargetMessageProcessingModel, 1522 snmpTargetSecurityModel, snmpTargetSecurityName, 1523 and snmpTargetSecurityLevel have all been set." 1524 ::= { snmpTargetEntry 9 } 1526 snmpTargetDefaultRetryAlgorithm OBJECT-TYPE 1527 SYNTAX INTEGER { 1528 constant(1), 1529 linearBackOff(2), 1530 exponentialBackOff(3), 1531 randomBackOff(4) 1532 } 1533 MAX-ACCESS read-create 1534 STATUS current 1535 DESCRIPTION 1536 "This object specifies a default algorithm to be used 1537 when adjusting timeout times when retransmitting a 1538 request whose response was not received in a timely 1539 manner. An application may provide its own 1540 retransmission algorithm, in which case the value of 1541 this object is ignored. 1543 Can we really predict all the algorithms that people might want to use? 1545 There are alternatives to making this be an enumerated integer. 1547 One alternative is to make it be a set of 6 parameters for a quadratic 1548 equation which would be used to recalculate retry intervals, i.e.,: 1549 interval(n) = ((A1 / A2) * interval(n-1) * interval(n-1)) + 1550 ((B1 / B2) * interval(n-1)) + 1551 (C1 / C2) 1552 The advantage to this is that a manager can define a wide range of 1553 algorithms, and the agent does not need to support a specific set 1554 of algorithms. 1556 Another alternative is to identify retransmission algorithms by OID rather 1557 than by integer. The advantage to using OIDs is that we can define 1558 additional algorithms later. If we do this, we can either make this object 1559 be an OID, or we can have a table that maps the OIDs to integers, and have 1560 the value of this object point at one of the entries in the mapping table. 1561 The advantage to a mapping table is that it allows a manager to discover 1562 what algorithms an agent supports. 1563 " 1564 ::= { snmpTargetObjects 4 } 1566 -- ------------------------------------------------------------------ 1567 -- 1568 -- Conformance information 1569 -- 1570 -- ------------------------------------------------------------------ 1572 snmpTargetCompliances OBJECT IDENTIFIER ::= 1573 { snmpTargetConformance 1 } 1574 snmpTargetGroups OBJECT IDENTIFIER ::= 1575 { snmpTargetConformance 2 } 1577 -- ------------------------------------------------------------------ 1578 -- 1579 -- Compliance statements 1580 -- 1581 -- ------------------------------------------------------------------ 1583 snmpTargetBasicGroup OBJECT-GROUP 1584 OBJECTS { 1585 snmpTargetAddressSpinLock, 1586 snmpTargetAddrTDomain, 1587 snmpTargetAddrTAddress, 1588 snmpTargetAddrStorageType, 1589 snmpTargetAddrRowStatus, 1590 snmpTargetAddrName, 1591 snmpTargetMessageProcessingModel, 1592 snmpTargetSecurityModel, 1593 snmpTargetSecurityName, 1594 snmpTargetSecurityLevel, 1595 snmpTargetStorageType, 1596 snmpTargetRowStatus 1597 } 1598 STATUS current 1599 DESCRIPTION 1600 "A collection of objects providing basic remote 1601 configuration of management targets." 1602 ::= { snmpTargetGroups 1 } 1603 snmpTargetResponseGroup OBJECT-GROUP 1604 OBJECTS { 1605 snmpTargetAddrTimeout, 1606 snmpTargetRetryCount, 1607 snmpTargetDefaultRetryAlgorithm 1608 } 1609 STATUS current 1610 DESCRIPTION 1611 "A collection of objects providing remote configuration 1612 of management targets for applications which generate 1613 SNMP messages for which a response message would be 1614 expected." 1615 ::= { snmpTargetGroups 2 } 1617 END 1618 5.2. The Notification MIB 1620 This MIB contains three tables. The first table, the 1621 snmpNotifyTargetTable, simply augments the snmpTargetTable with a 1622 single object which is used to determine whether a particular 1623 management target should be used for generating notifications, and 1624 the type of notification to be generated. The second table sparsely 1625 augments the snmpNotifyTargetTable with a single object. This object 1626 is used to associate a set of filters with a particular management 1627 target. The third table defines filters which are used to limit the 1628 number of notifications which are generated using particular 1629 management targets. 1631 5.2.1. Definitions 1633 SNMPV3-NOTIFICATION-MIB DEFINITIONS ::= BEGIN 1635 IMPORTS 1636 MODULE-IDENTITY, 1637 OBJECT-TYPE, 1638 OBJECT-IDENTITY, 1639 Integer32 1640 FROM SNMPv2-SMI 1642 TDomain, 1643 TAddress, 1644 TruthValue, 1645 TimeInterval, 1646 RowStatus, 1647 StorageType 1648 FROM SNMPv2-TC 1650 SnmpSecurityModel, 1651 SnmpSecurityLevel, 1652 SnmpAdminString 1653 FROM SNMP-FRAMEWORK-MIB 1655 snmpTargetEntry, 1656 snmpTargetName 1657 FROM SNMPV3-TARGET-MIB 1659 MODULE-COMPLIANCE, 1660 OBJECT-GROUP 1661 FROM SNMPv2-CONF; 1663 snmpNotificationMIB MODULE-IDENTITY 1664 LAST-UPDATED "9707140000Z" 1665 ORGANIZATION "IETF SNMPv3 Working Group" 1666 CONTACT-INFO 1667 "David B. Levi 1668 SNMP Research, Inc. 1669 3001 Kimberlin Heights Road 1670 Knoxville, TN 37920-9716 1671 Tel: +1 423 573 1434 1672 E-mail: levi@snmp.com 1674 Paul Meyer 1675 Secure Computing Corporation 1676 2675 Long Lake Road 1677 Roseville, MN 55113 1678 Tel: +1 612 628 1592 1679 E-mail: paul_meyer@securecomputing.com 1681 Bob Stewart 1682 Cisco Systems, Inc. 1683 170 West Tasman Drive 1684 San Jose, CA 95134-1706 1685 Tel: +1 603 654 6923 1686 E-mail: bstewart@cisco.com" 1687 DESCRIPTION 1688 "This MIB module defines a MIB which provides mechanisms 1689 to remotely configure management targets used by an 1690 SNMPv3 entity." 1691 REVISION "9707140000Z" 1692 DESCRIPTION 1693 "The initial revision." 1694 ::= { snmpModules 12 } -- TBD 1696 snmpNotifyObjects OBJECT IDENTIFIER ::= 1697 { snmpNotificationMIB 1 } 1698 snmpNotifyConformance OBJECT IDENTIFIER ::= 1699 { snmpNotificationMIB 2 } 1701 -- ------------------------------------------------------------------ 1702 -- 1703 -- The snmpNotifyObjects group 1704 -- 1705 -- ------------------------------------------------------------------ 1707 snmpNotifyTargetTable OBJECT-TYPE 1708 SYNTAX SEQUENCE OF SnmpV3NotifyTargetEntry 1709 MAX-ACCESS not-accessible 1710 STATUS current 1711 DESCRIPTION 1712 "This table is used to select management targets which should 1713 receive notifications, as well as the type of notification 1714 which should be sent to each selected management target." 1715 ::= { snmpNotifyObjects 1 } 1717 snmpNotifyTargetEntry OBJECT-TYPE 1718 SYNTAX SnmpV3NotifyTargetEntry 1719 MAX-ACCESS not-accessible 1720 STATUS current 1721 DESCRIPTION 1722 "An entry in this table determines whether the corresponding 1723 entry in the snmpTargetTable should be used when generating 1724 notifications." 1725 AUGMENTS { snmpTargetEntry } 1726 ::= { snmpNotifyTargetTable 1 } 1728 SnmpV3NotifyTargetEntry ::= SEQUENCE { 1729 snmpNotifyTargetType INTEGER 1730 } 1732 snmpNotifyTargetType OBJECT-TYPE 1733 SYNTAX INTEGER { 1734 trap(1), 1735 inform(2), 1736 nothing(3) 1737 } 1738 MAX-ACCESS read-create 1739 STATUS current 1740 DESCRIPTION 1741 "This object determines whether a particular entry in 1742 the snmpTargetTable should be used when generating 1743 notifications. It also determines the type of 1744 notifications generated using a particular entry. 1745 If the value of this object is trap(1), 1746 then the entry will be used to generate messages 1747 containing SNMPv2-Trap PDUs. If the value is 1748 inform(2), then the entry will be used to generate 1749 messages containing Inform PDUs. If the value is 1750 nothing(3), then the entry is not used to generate 1751 notifications. 1753 Note that the default value for this object is 1754 nothing(3). This ensures that if an entry is created 1755 for a purpose other than notification generation, 1756 whoever creates the row need not do anything special 1757 to prevent the use of the entry when generating 1758 notifications. 1760 Also note that if an SNMP entity only supports 1761 generation of traps (and not informs), then this 1762 object need not be supported, and its value is 1763 assumed to be trap(1)." 1764 DEFVAL { nothing } 1765 ::= { snmpNotifyTargetEntry 1 } 1767 snmpNotifyFilterProfileTable OBJECT-TYPE 1768 SYNTAX SEQUENCE OF SnmpV3NotifyFilterProfileEntry 1769 MAX-ACCESS not-accessible 1770 STATUS current 1771 DESCRIPTION 1772 "This table is used to select management targets which 1773 should receive notifications, as well as the type of 1774 notification which should be sent to each selected 1775 management target." 1776 ::= { snmpNotifyObjects 2 } 1778 snmpNotifyFilterProfileEntry OBJECT-TYPE 1779 SYNTAX SnmpV3NotifyFilterProfileEntry 1780 MAX-ACCESS not-accessible 1781 STATUS current 1782 DESCRIPTION 1783 "An entry in this table indicates the name of the filter 1784 profile to be used when generating notifications using 1785 the corresponding entry in the snmpTargetTable." 1786 INDEX { snmpTargetName } 1787 ::= { snmpNotifyFilterProfileTable 1 } 1789 SnmpV3NotifyFilterProfileEntry ::= SEQUENCE { 1790 snmpNotifyFilterProfileName SnmpAdminString 1791 snmpNotifyFilterProfileStorageType StorageType 1792 snmpNotifyFilterProfileRowStatus RowStatus 1793 } 1795 snmpNotifyFilterProfileName OBJECT-TYPE 1796 SYNTAX SnmpAdminString 1797 MAX-ACCESS read-create 1798 STATUS current 1799 DESCRIPTION 1800 "The name of the filter profile to be used when generating 1801 notifications using the corresponding entry in the 1802 snmpTargetTable." 1803 ::= { snmpNotifyFilterProfileEntry 1 } 1804 snmpNotifyFilterProfileStorageType OBJECT-TYPE 1805 SYNTAX StorageType 1806 MAX-ACCESS read-create 1807 STATUS current 1808 DESCRIPTION 1809 "The storage type of this conceptual row." 1810 ::= { snmpNotifyFilterProfileEntry 2 } 1812 snmpNotifyFilterProfileRowStatus OBJECT-TYPE 1813 SYNTAX RowStatus 1814 MAX-ACCESS read-create 1815 STATUS current 1816 DESCRIPTION 1817 "The status of this conceptual row." 1818 ::= { snmpNotifyFilterProfileEntry 3 } 1820 snmpNotifyFilterTable OBJECT-TYPE 1821 SYNTAX SEQUENCE OF SnmpV3NotifyFilterEntry 1822 MAX-ACCESS not-accessible 1823 STATUS current 1824 DESCRIPTION 1825 "The table of filter profiles. Filter profiles are used 1826 to determine whether particular management targets should 1827 receive particular notifications. 1829 When a notification is generated, it must be compared 1830 with the filters associated with each management target 1831 which is configured to receive notifications. If the 1832 notification is matched by a filter, it is not sent to 1833 the management target with which the filter is 1834 associated." 1835 ::= { snmpNotifyObjects 3 } 1837 snmpNotifyFilterEntry OBJECT-TYPE 1838 SYNTAX SnmpV3NotifyFilterEntry 1839 MAX-ACCESS not-accessible 1840 STATUS current 1841 DESCRIPTION 1842 "An element of a filter profile." 1843 INDEX { snmpNotifyFilterProfileName, 1844 IMPLIED snmpNotifyFilterSubtree } 1845 ::= { snmpNotifyFilterTable 1 } 1847 SnmpV3NotifyFilterEntry ::= SEQUENCE { 1848 snmpNotifyFilterSubtree OBJECT IDENTIFIER, 1849 snmpNotifyFilterMask OCTET STRING, 1850 snmpNotifyFilterType INTEGER, 1851 snmpNotifyFilterStorageType StorageType, 1852 snmpNotifyFilterRowStatus RowStatus 1853 } 1855 snmpNotifyFilterSubtree OBJECT-TYPE 1856 SYNTAX OBJECT IDENTIFIER 1857 MAX-ACCESS not-accessible 1858 STATUS current 1859 DESCRIPTION 1860 "The MIB subtree which, when combined with the corresponding 1861 instance of snmpNotifyFilterMask, defines a family of 1862 subtrees which are included in or excluded from the 1863 filter profile." 1864 ::= { snmpNotifyFilterEntry 1 } 1866 snmpNotifyFilterMask OBJECT-TYPE 1867 SYNTAX OCTET STRING (SIZE(0..16)) 1868 MAX-ACCESS read-create 1869 STATUS current 1870 DESCRIPTION 1871 "The bit mask which, in combination with the corresponding 1872 instance of snmpNotifyFilterSubtree, defines a family of 1873 subtrees which are included in or excluded from the 1874 filter profile. 1876 Each bit of this bit mask corresponds to a 1877 sub-identifier of snmpNotifyFilterSubtree, with the 1878 most significant bit of the i-th octet of this octet 1879 string value (extended if necessary, see below) 1880 corresponding to the (8*i - 7)-th sub-identifier, and 1881 the least significant bit of the i-th octet of this 1882 octet string corresponding to the (8*i)-th 1883 sub-identifier, where i is in the range 1 through 16. 1885 Each bit of this bit mask specifies whether or not 1886 the corresponding sub-identifiers must match when 1887 determining if an OBJECT IDENTIFIER matches this 1888 family of filter subtrees; a '1' indicates that an 1889 exact match must occur; a '0' indicates 'wild card', 1890 i.e., any sub-identifier value matches. 1892 Thus, the OBJECT IDENTIFIER X of an object instance 1893 is contained in a family of filter subtrees if, for 1894 each sub-identifier of the value of 1895 snmpNotifyFilterSubtree, either: 1897 the i-th bit of snmpNotifyFilterMask is 0, or 1898 the i-th sub-identifier of X is equal to the i-th 1899 sub-identifier of the value of 1900 snmpNotifyFilterSubtree. 1902 If the value of this bit mask is M bits long and 1903 there are more than M sub-identifiers in the 1904 corresponding instance of snmpNotifyFilterSubtree, 1905 then the bit mask is extended with 1's to be the 1906 required length. 1908 Note that when the value of this object is the 1909 zero-length string, this extension rule results in 1910 a mask of all-1's being used (i.e., no 'wild card'), 1911 and the family of filter subtrees is the one 1912 subtree uniquely identified by the corresponding 1913 instance of snmpNotifyFilterSubtree." 1914 DEFVAL { ''H } 1915 ::= { snmpNotifyFilterEntry 2 } 1917 snmpNotifyFilterType OBJECT-TYPE 1918 SYNTAX INTEGER { 1919 included(1), 1920 excluded(2) 1921 } 1922 MAX-ACCESS read-create 1923 STATUS current 1924 DESCRIPTION 1925 "This object indicates whether the family of filter subtrees 1926 defined by this entry are included in or excluded from a 1927 filter." 1928 DEFVAL { included } 1929 ::= { snmpNotifyFilterEntry 3 } 1931 snmpNotifyFilterStorageType OBJECT-TYPE 1932 SYNTAX StorageType 1933 MAX-ACCESS read-create 1934 STATUS current 1935 DESCRIPTION 1936 "The storage type of this conceptual row." 1937 ::= { snmpNotifyFilterEntry 4 } 1939 snmpNotifyFilterRowStatus OBJECT-TYPE 1940 SYNTAX RowStatus 1941 MAX-ACCESS read-create 1942 STATUS current 1943 DESCRIPTION 1944 "The status of this conceptual row." 1945 ::= { snmpNotifyFilterEntry 5 } 1947 -- ------------------------------------------------------------------ 1948 -- 1949 -- Conformance information 1950 -- 1951 -- ------------------------------------------------------------------ 1953 snmpNotifyCompliances OBJECT IDENTIFIER ::= 1954 { snmpNotifyConformance 1 } 1955 snmpNotifyGroups OBJECT IDENTIFIER ::= 1956 { snmpNotifyConformance 2 } 1958 -- ------------------------------------------------------------------ 1959 -- 1960 -- Compliance statements 1961 -- 1962 -- ------------------------------------------------------------------ 1964 snmpNotifyBasicCompliance MODULE-COMPLIANCE 1965 STATUS current 1966 DESCRIPTION 1967 "The compliance statement for minimal SNMP entities which 1968 implement only SNMP Traps and read-create operations on 1969 only the snmpTargetAddrTable." 1970 MODULE SNMPV3-TARGET-MIB 1971 MANDATORY-GROUPS { snmpTargetBasicGroup } 1973 OBJECT snmpTargetAddrName 1974 MIN-ACCESS read-only 1975 DESCRIPTION 1976 "Read-write and read-create access are not required." 1978 OBJECT snmpTargetMessageProcessingModel 1979 MIN-ACCESS read-only 1980 DESCRIPTION 1981 "Read-write and read-create access are not required." 1983 OBJECT snmpTargetSecurityModel 1984 MIN-ACCESS read-only 1985 DESCRIPTION 1986 "Read-write and read-create access are not required." 1988 OBJECT snmpTargetSecurityName 1989 MIN-ACCESS read-only 1990 DESCRIPTION 1991 "Read-write and read-create access are not required." 1992 OBJECT snmpTargetSecurityLevel 1993 MIN-ACCESS read-only 1994 DESCRIPTION 1995 "Read-write and read-create access are not required." 1997 OBJECT snmpTargetStorageType 1998 SYNTAX INTEGER { 1999 readOnly(5) 2000 } 2001 MIN-ACCESS read-only 2002 DESCRIPTION 2003 "Read-write and read-create access are not required. 2004 Support of the values other(1), volatile(2), 2005 nonVolatile(3), and permanent(4) is not required." 2007 OBJECT snmpTargetRowStatus 2008 SYNTAX INTEGER { 2009 active(1) 2010 } 2011 MIN-ACCESS read-only 2012 DESCRIPTION 2013 "Read-write and read-create access are not required. 2014 Support of the values notInService(2), notReady(3), 2015 createAndGo(4), createAndWait(5), and destroy(6) is 2016 not required." 2018 ::= { snmpNotifyCompliances 1 } 2020 snmpNotifyBasicWithFiltersCompliance MODULE-COMPLIANCE 2021 STATUS current 2022 DESCRIPTION 2023 "The compliance statement for SNMP entities which implement 2024 SNMP Traps with filtering, and read-create operations on 2025 all related tables." 2026 MODULE SNMPV3-TARGET-MIB 2027 MANDATORY-GROUPS { snmpTargetBasicGroup } 2028 MODULE -- This Module 2029 MANDATORY-GROUPS { snmpNotifyFilterGroup } 2030 ::= { snmpNotifyCompliances 2 } 2032 snmpNotifyFullCompliance MODULE-COMPLIANCE 2033 STATUS current 2034 DESCRIPTION 2035 "The compliance statement for SNMP entities which either 2036 implement only SNMP Informs, or both SNMP Traps and SNMP 2037 Informs, plus filtering and read-create operations on 2038 all related tables." 2039 MODULE SNMPV3-TARGET-MIB 2040 MANDATORY-GROUPS { snmpTargetBasicGroup, 2041 snmpTargetResponseGroup } 2042 MODULE -- This Module 2043 MANDATORY-GROUPS { snmpNotifyTypeGroup, 2044 snmpNotifyFilterGroup } 2045 ::= { snmpNotifyCompliances 3 } 2047 snmpNotifyTypeGroup OBJECT-GROUP 2048 OBJECTS { 2049 snmpNotifyTargetType 2050 } 2051 STATUS current 2052 DESCRIPTION 2053 "An object for selecting which management targets are used 2054 for generating notifications, and the type of notification 2055 to be generated for each selected management target." 2056 ::= { snmpNotifyGroups 1 } 2058 snmpNotifyFilterGroup OBJECT-GROUP 2059 OBJECTS { 2060 snmpNotifyFilterProfileName, 2061 snmpNotifyFilterMask, 2062 snmpNotifyFilterType, 2063 snmpNotifyFilterStorageType, 2064 snmpNotifyFilterRowStatus 2065 } 2066 STATUS current 2067 DESCRIPTION 2068 "A collection of objects providing remote configuration of 2069 management targets, including row creation in the 2070 snmpTargetTable." 2071 ::= { snmpNotifyGroups 3 } 2073 END 2074 5.3. The Proxy MIB 2076 The MIB contains a single scalar and a single table. The scalar 2077 object, snmpProxyNextIndex, is used by managers when creating new 2078 entries in the table. The table, snmpProxyTable, is used to define 2079 translations between management targets for use when forwarding 2080 messages. 2082 5.3.1. Definitions 2084 SNMPV3-PROXY-MIB DEFINITIONS ::= BEGIN 2086 IMPORTS 2087 MODULE-IDENTITY, 2088 OBJECT-TYPE, 2089 OBJECT-IDENTITY, 2090 Integer32 2091 FROM SNMPv2-SMI 2093 TDomain, 2094 TAddress, 2095 TruthValue, 2096 TimeInterval, 2097 RowStatus, 2098 StorageType 2099 FROM SNMPv2-TC 2101 SnmpEngineID, 2102 SnmpSecurityModel, 2103 SnmpSecurityLevel, 2104 SnmpAdminString 2105 FROM SNMP-FRAMEWORK-MIB 2107 MODULE-COMPLIANCE, 2108 OBJECT-GROUP 2109 FROM SNMPv2-CONF; 2111 snmpProxyMIB MODULE-IDENTITY 2112 LAST-UPDATED "9706140000Z" 2113 ORGANIZATION "IETF SNMPv3 Working Group" 2114 CONTACT-INFO 2115 "David B. Levi 2116 SNMP Research, Inc. 2117 3001 Kimberlin Heights Road 2118 Knoxville, TN 37920-9716 2119 Tel: +1 423 573 1434 2120 E-mail: levi@snmp.com 2122 Paul Meyer 2123 Secure Computing Corporation 2124 2675 Long Lake Road 2125 Roseville, MN 55113 2126 Tel: +1 612 628 1592 2127 E-mail: paul_meyer@securecomputing.com 2129 Bob Stewart 2130 Cisco Systems, Inc. 2131 170 West Tasman Drive 2132 San Jose, CA 95134-1706 2133 Tel: +1 603 654 6923 2134 E-mail: bstewart@cisco.com" 2135 DESCRIPTION 2136 "This MIB module defines a MIB which provides mechanisms to 2137 remotely configure the parameters used by an SNMPv3 entity 2138 for the generation of notifications." 2139 REVISION "9707140000Z" 2140 DESCRIPTION 2141 "The initial revision." 2142 ::= { snmpModules 13 } -- TBD 2144 snmpProxyObjects OBJECT IDENTIFIER ::= { snmpProxyMIB 1 } 2145 snmpProxyConformance OBJECT IDENTIFIER ::= { snmpProxyMIB 2 } 2147 -- ------------------------------------------------------------------ 2148 -- 2149 -- The snmpProxyObjects group 2150 -- 2151 -- ------------------------------------------------------------------ 2153 snmpProxyNextIndex OBJECT-TYPE 2154 SYNTAX Integer32 (1..2147483647) 2155 MAX-ACCESS read-write 2156 STATUS current 2157 DESCRIPTION 2158 "This object is used to facilitate creation of rows in the 2159 snmpProxyTable. Its value when read is equal to an unused 2160 value of snmpProxyIndex. When a manager wishes to create 2161 a row in the snmpProxyTable, it should first retrieve the 2162 value of this object, and then set the instance of 2163 snmpProxyRowStatus whose snmpProxyIndex value is 2164 equal to the retrieved value to either createAndWait or 2165 createAndGo." 2166 ::= { snmpProxyObjects 1 } 2167 snmpProxyTable OBJECT-TYPE 2168 SYNTAX SEQUENCE OF SnmpV3ProxyEntry 2169 MAX-ACCESS not-accessible 2170 STATUS current 2171 DESCRIPTION 2172 "The table of translation parameters used by proxy forwarder 2173 applications for forwarding SNMP messages." 2174 ::= { snmpProxyObjects 2 } 2176 snmpProxyEntry OBJECT-TYPE 2177 SYNTAX SnmpV3ProxyEntry 2178 MAX-ACCESS not-accessible 2179 STATUS current 2180 DESCRIPTION 2181 "A set of translation parameters used by a proxy forwarder 2182 application for forwarding SNMP messages." 2183 INDEX { snmpProxyIndex } 2184 ::= { snmpProxyTable 1 } 2186 SnmpV3ProxyEntry ::= SEQUENCE { 2187 snmpProxyIndex Integer32, 2188 snmpProxyType INTEGER, 2189 snmpProxyContextEngineID SnmpEngineID, 2190 snmpProxyContextName SnmpAdminString, 2191 snmpProxyTargetIn SnmpAdminString, 2192 snmpProxyTargetOut SnmpAdminString, 2193 snmpProxyStorageType StorageType, 2194 snmpProxyRowStatus RowStatus 2195 } 2197 snmpProxyIndex OBJECT-TYPE 2198 SYNTAX Integer32 (1..2147483647) 2199 MAX-ACCESS not-accessible 2200 STATUS current 2201 DESCRIPTION 2202 "The locally arbitrary, but unique identifier associated 2203 with this snmpProxyEntry." 2204 ::= { snmpProxyEntry 1 } 2206 snmpProxyType OBJECT-TYPE 2207 SYNTAX INTEGER { 2208 read(1), 2209 write(2), 2210 trap(3), 2211 inform(4) 2212 } 2213 MAX-ACCESS not-accessible 2214 STATUS current 2215 DESCRIPTION 2216 "The type of message that may be forwarded using 2217 the translation parameters defined by this entry." 2218 ::= { snmpProxyEntry 2 } 2220 snmpProxyContextEngineID OBJECT-TYPE 2221 SYNTAX SnmpEngineID 2222 MAX-ACCESS read-create 2223 STATUS current 2224 DESCRIPTION 2225 "The contextEngineID contained in messages that 2226 may be forwarded using the translation parameters 2227 defined by this entry." 2228 ::= { snmpProxyEntry 3 } 2230 snmpProxyContextName OBJECT-TYPE 2231 SYNTAX SnmpAdminString 2232 MAX-ACCESS read-create 2233 STATUS current 2234 DESCRIPTION 2235 "The contextName contained in messages that may be 2236 forwarded using the translation parameters defined 2237 by this entry." 2238 ::= { snmpProxyEntry 4 } 2240 snmpProxyTargetIn OBJECT-TYPE 2241 SYNTAX SnmpAdminString 2242 MAX-ACCESS read-create 2243 STATUS current 2244 DESCRIPTION 2245 "This object selects a set of management targets defined 2246 in the snmpTargetTable (in the SNMPV3-TARGET-MIB)." 2247 ::= { snmpProxyEntry 5 } 2249 snmpProxyTargetOut OBJECT-TYPE 2250 SYNTAX SnmpAdminString 2251 MAX-ACCESS read-create 2252 STATUS current 2253 DESCRIPTION 2254 "This object selects a management target defined in the 2255 snmpTargetTable (in the SNMPV3-TARGET-MIB). Only the 2256 first transport address/domain as selected by the 2257 snmpTargetAddrName object is identified by 2258 snmpProxyTargetOut (i.e. the lexicographically smallest 2259 instance in the snmpTargetAddrTable whose 2260 snmpTargetAddrName is equal to the snmpTargetAddrName 2261 object is used for proxy forwarding)." 2262 ::= { snmpProxyEntry 6 } 2264 snmpProxyStorageType OBJECT-TYPE 2265 SYNTAX StorageType 2266 MAX-ACCESS read-create 2267 STATUS current 2268 DESCRIPTION 2269 "The storage type of this conceptual row." 2270 ::= { snmpProxyEntry 7 } 2272 snmpProxyRowStatus OBJECT-TYPE 2273 SYNTAX RowStatus 2274 MAX-ACCESS read-create 2275 STATUS current 2276 DESCRIPTION 2277 "The status of this conceptual row." 2278 ::= { snmpProxyEntry 8 } 2280 -- ------------------------------------------------------------------ 2281 -- 2282 -- Conformance information 2283 -- 2284 -- ------------------------------------------------------------------ 2286 snmpProxyCompliances OBJECT IDENTIFIER ::= 2287 { snmpProxyConformance 1 } 2288 snmpProxyGroups OBJECT IDENTIFIER ::= 2289 { snmpProxyConformance 2 } 2291 -- ------------------------------------------------------------------ 2292 -- 2293 -- Compliance statements 2294 -- 2295 -- ------------------------------------------------------------------ 2297 snmpProxyCompliance MODULE-COMPLIANCE 2298 STATUS current 2299 DESCRIPTION 2300 "The compliance statement for SNMP entities which include 2301 a proxy forwarding application." 2302 MODULE SNMPV3-TARGET-MIB 2303 MANDATORY-GROUPS { snmpTargetBasicGroup, 2304 snmpTargetResponseGroup } 2305 MODULE -- This Module 2306 MANDATORY-GROUPS { snmpProxyGroup } 2307 ::= { snmpProxyCompliances 1 } 2308 snmpProxyGroup OBJECT-GROUP 2309 OBJECTS { 2310 snmpProxyNextIndex, 2311 snmpProxyType, 2312 snmpProxyContextEngineID, 2313 snmpProxyContextName, 2314 snmpProxyTargetIn, 2315 snmpProxyTargetOut, 2316 snmpProxyStorageType, 2317 snmpProxyRowStatus 2318 } 2319 STATUS current 2320 DESCRIPTION 2321 "A collection of objects providing remote configuration of 2322 management target translation parameters for use by 2323 proxy forwarder applications." 2324 ::= { snmpProxyGroups 3 } 2326 END 2327 6. Identification of Management Targets in Notification Originators 2329 This section describes the mechanisms used by a notification 2330 originator application when using the MIB described in this document 2331 to determine the set of management targets to be used when generating 2332 a notification. 2334 A notification originator uses the snmpTargetTable to find the groups 2335 of management targets to be used for generating notifications. Each 2336 active entry in this table, for which the corresponding value of 2337 snmpNotifyTargetType is trap(1) or inform(2), identifies a group of 2338 management targets to be used for notification generation. Note that 2339 if an SNMP Entity's only use of the snmpTargetTable is for generation 2340 of messages containing SNMPv2-Trap PDUs, the snmpNotifyTargetType 2341 object is not required to be implemented. In this case, the value of 2342 snmpNotifyTargetType is always assumed to be trap(1). 2344 Each such entry contains a pointer to the snmpTargetAddrTable 2345 (snmpTargetAddrName). This pointer identifies zero or more transport 2346 endpoints, defined in the snmpTargetAddrTable. If there are zero 2347 transport endpoints identified, the group of management targets is 2348 empty, and should be ignored. Otherwise, each transport endpoint, 2349 paired with the SNMP information from the snmpTargetTable, identifies 2350 a single management target within the group. 2352 The decision as to whether a notification should contain an SNMPv2- 2353 Trap or Inform PDU is determined by the value of the 2354 snmpNotifyTargetType object. If the value of this object is trap(1), 2355 the notification should contain an SNMPv2-Trap PDU. If the value of 2356 this object is inform(2), then the notification should contain an 2357 Inform PDU, and the number of retries for the Inform is the value of 2358 snmpTargetRetryCount. Note that the exception to these rules is when 2359 the snmpTargetMessageProcessingModel object indicates SNMPv1. In 2360 this case, the notification is sent as a Trap if the value of 2361 snmpNotifyTargetType is either trap(1) or inform(2). 2363 7. Notification Filtering 2365 This section describes the mechanisms used by a notification 2366 originator application when using the MIB described in this document 2367 to filter generation of notifications. 2369 A notification originator uses the snmpNotifyFilterTable to filter 2370 notifications. A notification filter profile may be associated with 2371 a group of management targets identified by a particular entry in the 2372 snmpTargetTable. The associated filter profile is identified by an 2373 entry in the snmpNotifyFilterProfileTable whose index is equal to the 2374 index of the entry in the snmpTargetTable. If no such entry exists 2375 in the snmpNotifyFilterProfileTable, no filtering is performed for 2376 that group of management targets. 2378 If such an entry does exist, the value of snmpNotifyFilterProfileName 2379 of the entry is compared with the corresponding portion of the index 2380 of all active entries in the snmpNotifyFilterTable. All such entries 2381 for which this comparison results in an exact match are used for 2382 filtering the notification. If no such entries exist, no filtering 2383 is performed, and the notification may be sent to all management 2384 targets in the group. 2386 Otherwise, if matching entries do exist, the notification may be sent 2387 if the NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this 2388 is the value of the element of the variable bindings whose name is 2389 snmpTrapOID.0, i.e. the second variable binding), and all of the 2390 object instances to be included in the variable-bindings of the 2391 notification, are not specifically excluded by the matching entries. 2393 Each set of snmpNotifyFilterTable entries is divided into two 2394 collections of filter subtrees: the included filter subtrees, and 2395 the excluded filter subtrees. The snmpNotifyFilterType object 2396 defines the collection to which each matching entry belongs. 2398 To determine whether a particular notification name or object 2399 instance is excluded by the set of matching entries, compare the 2400 notification name's or object instance's OBJECT IDENTIFIER with each 2401 of the matching entries. If none match, then the notification name 2402 or object instance is considered excluded, and the notification 2403 should not be sent to this group of management targets. If one or 2404 more match, then the notification name or object instance is included 2405 or excluded, according to the value of snmpNotifyFilterType in the 2406 entry whose value of snmpNotifyFilterSubtree has the most sub- 2407 identifiers. If multiple entries match and have the same number of 2408 sub-identifiers, then the lexicographically greatest instance of 2409 snmpNotifyFilterType among those which match determines the inclusion 2410 or exclusion. 2412 A notification name's or object instance's OBJECT IDENTIFIER X 2413 matches an entry in the snmpNotifyFilterTable when the number of 2414 sub-identifiers in X is at least as many as in the value of 2415 snmpNotifyFilterSubtree for the entry, and each sub-identifier in the 2416 value of snmpNotifyFilterSubtree matches its corresponding sub- 2417 identifier in X. Two sub-identifiers match either if the 2418 corresponding bit of snmpNotifyFilterMask is zero (the 'wild card' 2419 value), or if the two sub-identifiers are equal. 2421 8. Management Target Translation in Proxy Forwarder Applications 2423 This section describes the mechanisms used by a proxy forwarder 2424 application when using the MIB described in this document to 2425 translate incoming management target information into outgoing 2426 management target information for the purpose of forwarding messages. 2427 There are actually two mechanisms a proxy forwarder may use, one for 2428 forwarding request messages, and one for forwarding notification 2429 messages. 2431 8.1. Management Target Translation for Request Forwarding 2433 When forwarding request messages, the proxy forwarder will select a 2434 single entry in the snmpProxyTable. To select this entry, it will 2435 perform the following comparisons: 2437 - The snmpProxyType must be read(1) if the request is a Get, 2438 GetNext, or GetBulk request. The snmpProxyType must be 2439 write(2) if the request is a Set request. 2441 - The contextEngineId and contextName must equal the 2442 snmpProxyContextEngineID and snmpProxyContextName objects. 2444 - The snmpProxyTargetIn object identifies an entry in the 2445 snmpTargetTable. The snmp version, securityLevel, security 2446 model, and securityName must match the values of 2447 snmpTargetMessageProcessingModel, snmpTargetSecurityModel, 2448 snmpTargetSecurityName, and snmpTargetSecurityLevel of the 2449 identified entry in the snmpTargetTable. 2451 - The identified entry in the snmpTargetTable contains a pointer 2452 to the snmpTargetAddrTable. This pointer refers to zero or 2453 more entries in the snmpTargetAddrTable. If there are no such 2454 entries, this comparison need not succeed. If there is at 2455 least one such entry, the transport domain and address from 2456 which the request was received must match the 2457 snmpTargetAddrTDomain and snmpTargetAddrTAddress values of at 2458 least one of these entries. 2460 There may be multiple entries in the snmpProxyTable for which these 2461 comparisons succeed. The entry whose snmpProxyIndex has the smallest 2462 value and for which the comparisons succeed will be selected by the 2463 proxy forwarder. 2465 The outgoing management information is identified by the value of the 2466 snmpProxyTargetOut object of the selected entry. This object 2467 identifies an entry in the snmpTargetTable. The 2468 snmpTargetMessageProcessingModel, snmpTargetSecurityModel, 2469 snmpTargetSecurityName, and snmpTargetSecurityLevel of this entry are 2470 used as one part of the management target. The other part of the 2471 management target is a transport endpoint, which is identified by the 2472 value of the snmpTargetAddrName member of the snmpTargetTable entry. 2473 This value may identify zero or more entries in the 2474 snmpTargetAddrTable. If there are no entries identified, the 2475 selected snmpProxyTable entry is invalid, and the proxy forwarder 2476 should look for another snmpProxyTable entry to use. Otherwise, the 2477 snmpTargetAddrTable entry with the smallest value of 2478 snmpTargetAddrSubIndex is used as the transport endpoint. 2480 8.2. Management Target Translation for Notification Forwarding 2482 When forwarding notification messages, the proxy forwarder will 2483 select multiple entries in the snmpProxyTable. To select these 2484 entries, it will perform the following comparisons: 2486 - The snmpProxyType must be trap(3) if the notification is a 2487 Trap. The snmpProxyType must be inform(4) if the request is 2488 an Inform. 2490 - The contextEngineId and contextName must equal the 2491 snmpProxyContextEngineID and snmpProxyContextName objects. 2493 - The snmpProxyTargetIn object identifies an entry in the 2494 snmpTargetTable. The snmp version, securityLevel, security 2495 model, and securityName must match the values of 2496 snmpTargetMessageProcessingModel, snmpTargetSecurityModel, 2497 snmpTargetSecurityName, and snmpTargetSecurityLevel of the 2498 identified entry in the snmpTargetTable. 2500 - The identified entry in the snmpTargetTable contains a pointer 2501 to the snmpTargetAddrTable. This pointer refers to zero or 2502 more entries in the snmpTargetAddrTable. If there are no such 2503 entries, this comparison need not succeed. If there is at 2504 least one such entry, the transport domain and address from 2505 which the request was received must match the 2506 snmpTargetAddrTDomain and snmpTargetAddrTAddress values of at 2507 least one of these entries. 2509 All entries for which these comparisons succeed are selected. The 2510 set of outgoing management targets to be used for generating 2511 forwarded notifications is identified by the value of the 2512 snmpProxyTargetOut object of all selected entries. These values 2513 identify entries in the snmpTargetTable. All such entries are used 2514 for generating forwarded notifications. The snmpTargetNotification 2515 object is ignored when generating forwarded notifications in a proxy 2516 forwarder application. 2518 9. Security Considerations 2520 Should have some discussion about notification generation 2521 applications which provide variable bindings when generating a 2522 notification, rather than omitting them and letting the engine get 2523 them from the LPM. Applications that do this should be careful not 2524 to disclose anything that they shouldn't. 2526 10. Editor's Address 2528 David B. Levi 2529 SNMP Research, Inc. 2530 3001 Kimberlin Heights Road 2531 Knoxville, TN 37920-9716 2532 U.S.A. 2533 Phone: +1 423 573 1434 2534 EMail: levi@snmp.com 2536 Paul Meyer 2537 Secure Computing Corporation 2538 2675 Long Lake Road 2539 Roseville, MN 55113 2540 U.S.A. 2541 Phone: +1 612 628 1592 2542 EMail: paul_meyer@securecomputing.com 2544 Bob Stewart 2545 Cisco Systems, Inc. 2546 170 West Tasman Drive 2547 San Jose, CA 95134-1706 2548 U.S.A. 2549 Phone: +1 603 654 6923 2550 EMail: bstewart@cisco.com 2552 11. Acknowledgments 2554 This document is the result of the efforts of the SNMPv3 Working 2555 Group. Some special thanks are in order to the following SNMPv3 WG 2556 members: 2558 Dave Battle (SNMP Research, Inc.) 2559 Uri Blumenthal (IBM T.J. Watson Research Center) 2560 Jeff Case (SNMP Research, Inc.) 2561 John Curran (BBN) 2562 T. Max Devlin (Hi-TECH Connections) 2563 John Flick (Hewlett Packard) 2564 David Harrington (Cabletron Systems Inc.) 2565 N.C. Hien (IBM T.J. Watson Research Center) 2566 Dave Levi (SNMP Research, Inc.) 2567 Louis A Mamakos (UUNET Technologies Inc.) 2568 Paul Meyer (Secure Computing Corporation) 2569 Keith McCloghrie (Cisco Systems) 2570 Russ Mundy (Trusted Information Systems, Inc.) 2571 Bob Natale (ACE*COMM Corporation) 2572 Mike O'Dell (UUNET Technologies Inc.) 2573 Dave Perkins (DeskTalk) 2574 Peter Polkinghorne (Brunel University) 2575 Randy Presuhn (BMC Software, Inc.) 2576 David Reid (SNMP Research, Inc.) 2577 Shawn Routhier (Epilogue) 2578 Juergen Schoenwaelder (TU Braunschweig) 2579 Bob Stewart (Cisco Systems) 2580 Bert Wijnen (IBM T.J. Watson Research Center) 2582 The document is based on recommendations of the IETF Security and 2583 Administrative Framework Evolution for SNMP Advisory Team. Members of 2584 that Advisory Team were: 2586 David Harrington (Cabletron Systems Inc.) 2587 Jeff Johnson (Cisco Systems) 2588 David Levi (SNMP Research Inc.) 2589 John Linn (Openvision) 2590 Russ Mundy (Trusted Information Systems) chair 2591 Shawn Routhier (Epilogue) 2592 Glenn Waters (Nortel) 2593 Bert Wijnen (IBM T. J. Watson Research Center) 2595 As recommended by the Advisory Team and the SNMPv3 Working Group 2596 Charter, the design incorporates as much as practical from previous 2597 RFCs and drafts. As a result, special thanks are due to the authors 2598 of previous designs known as SNMPv2u and SNMPv2*: 2600 Jeff Case (SNMP Research, Inc.) 2601 David Harrington (Cabletron Systems Inc.) 2602 David Levi (SNMP Research, Inc.) 2603 Keith McCloghrie (Cisco Systems) 2604 Brian O'Keefe (Hewlett Packard) 2605 Marshall T. Rose (Dover Beach Consulting) 2606 Jon Saperia (BGS Systems Inc.) 2607 Steve Waldbusser (International Network Services) 2608 Glenn W. Waters (Bell-Northern Research Ltd.) 2609 12. References 2611 [RFC1157] 2612 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2613 Management Protocol", RFC 1157, SNMP Research, Performance Systems 2614 International, Performance Systems International, MIT Laboratory 2615 for Computer Science, May 1990. 2617 [RFC1213] 2618 McCloghrie, K., and M. Rose, Editors, "Management Information Base 2619 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 2620 RFC 1213, Hughes LAN Systems, Performance Systems International, 2621 March 1991. 2623 [RFC1902] 2624 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2625 Waldbusser, "Structure of Management Information for Version 2 of 2626 the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP 2627 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2628 International Network Services, January 1996. 2630 [RFC1903] 2631 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2632 Waldbusser, "Textual Conventions for Version 2 of the Simple 2633 Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., 2634 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 2635 Network Services, January 1996. 2637 [RFC1905] 2638 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2639 Waldbusser, "Protocol Operations for Version 2 of the Simple 2640 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 2641 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 2642 Network Services, January 1996. 2644 [RFC1907] 2645 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2646 Waldbusser, "Management Information Base for Version 2 of the 2647 Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP 2648 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2649 International Network Services, January 1996. 2651 [RFC1908] 2652 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2653 Waldbusser, "Coexistence between Version 1 and Version 2 of the 2654 Internet-standard Network Management Framework", RFC1905, SNMP 2655 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2656 International Network Services, January 1996. 2658 [SNMP-ARCH] 2659 The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An 2660 Architecture for Describing SNMP Management Frameworks", draft- 2661 ietf-snmpv3-next-gen-arch-04.txt, August 1997. 2663 [SNMP-MPD] 2664 The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., 2665 "Message Processing and Dispatching for the Simple Network 2666 Management Protocol (SNMP)", draft-ietf-snmpv3-mpc-03.txt, August 2667 1997. 2669 [SNMP-ACM] 2670 The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McClogrie, K., 2671 "View-based Access Control Model for the Simple Network Management 2672 Protocol (SNMP)", draft-ietf-snmpv3-acm-02.txt, August 1997. 2674 APPENDIX A - Trap Configuration Example 2676 This section describes an example configuration for a Notification 2677 Generator application which implements the 2678 snmpNotifyMinimalCompliance level. The example configuration 2679 specifies that the Notification Generator should send notifications 2680 to 3 separate managers, using authentication and no privacy for the 2681 first 2 managers, and using both authentication and privacy for the 2682 third manager. 2684 The configuration consists of three rows in the snmpTargetAddrTable, 2685 and two rows in the snmpTargetTable. 2687 * snmpTargetAddrName = "AuthNoPrivTargetAddresses" 2688 * snmpTargetAddrSubIndex = 1 2689 snmpTargetAddrTDomain = snmpUDPDomain 2690 snmpTargetAddrTAddress = 128.1.2.3:162 2691 snmpTargetAddrStorageType = readOnly(5) 2692 snmpTargetAddrRowStatus = active(1) 2694 * snmpTargetAddrName = "AuthNoPrivTargetAddresses" 2695 * snmpTargetAddrSubIndex = 2 2696 snmpTargetAddrTDomain = snmpUDPDomain 2697 snmpTargetAddrTAddress = 128.2.4.6:162 2698 snmpTargetAddrStorageType = readOnly(5) 2699 snmpTargetAddrRowStatus = active(1) 2700 * snmpTargetAddrName = "AuthPrivTargetAddresses" 2701 * snmpTargetAddrSubIndex = 1 2702 snmpTargetAddrTDomain = snmpUDPDomain 2703 snmpTargetAddrTAddress = 128.1.5.9:162 2704 snmpTargetAddrStorageType = readOnly(5) 2705 snmpTargetAddrRowStatus = active(1) 2707 * snmpTargetName = "AuthNoPrivTarget" 2708 snmpTargetAddrName = "AuthNoPrivTargetAddresses" 2709 snmpTargetMessageProcessingModel = 3 2710 snmpTargetSecurityModel = 3 (USM) 2711 snmpTargetSecurityName = "joe" 2712 snmpTargetSecurityLevel = auth(2) 2713 snmpTargetStorageType = readOnly(5) 2714 snmpTargetRowStatus = active(1) 2716 * snmpTargetName = "AuthPrivTarget" 2717 snmpTargetAddrName = "AuthPrivTargetAddresses" 2718 snmpTargetMessageProcessingModel = 3 2719 snmpTargetSecurityModel = 3 (USM) 2720 snmpTargetSecurityName = "bob" 2721 snmpTargetSecurityLevel = priv(3) 2722 snmpTargetStorageType = readOnly(5) 2723 snmpTargetRowStatus = active(1) 2725 These entries define two separate management target groups. The 2726 first group contains two management targets: 2728 first target second target 2729 ------------ ------------- 2730 snmpVersion SNMPv3 SNMPv3 2731 securityModel 3 (USM) 3 (USM) 2732 securityName "joe" "joe" 2733 securityLevel auth(2) auth(2) 2734 transportDomain snmpUDPDomain snmpUDPDomain 2735 transportAddress 128.1.2.3:162 128.2.4.6:162 2737 And the second group contains a single management target: 2739 snmpVersion SNMPv3 2740 securityLevel priv(3) 2741 securityModel 3 (USM) 2742 securityName "bob" 2743 transportDomain snmpUDPDomain 2744 transportAddress 128.1.5.9:162 2745 Table of Contents 2747 1 Abstract ..................................................... 2 2748 2 Overview ..................................................... 3 2749 2.1 Command Generators ......................................... 3 2750 2.2 Command Responders ......................................... 3 2751 2.3 Notification Originators ................................... 3 2752 2.4 Notification Receivers ..................................... 4 2753 2.5 Proxy Forwarder ............................................ 4 2754 3 Management Targets ........................................... 5 2755 4 Elements Of Procedure ........................................ 6 2756 4.1 Command Generators ......................................... 7 2757 4.2 Command Responders ......................................... 10 2758 4.3 Notification Originators ................................... 15 2759 4.4 Notification Receivers ..................................... 18 2760 4.5 Proxy Forwarders ........................................... 21 2761 4.5.1 Request Forwarding ....................................... 21 2762 4.5.1.1 Processing an Incoming Request ......................... 22 2763 4.5.1.2 Processing an Incoming Response ........................ 24 2764 4.5.2 Notification Forwarding .................................. 25 2765 5 The Structure of the MIBs .................................... 29 2766 5.1 The Management Target MIB .................................. 29 2767 5.1.1 Definitions .............................................. 29 2768 5.2 The Notification MIB ....................................... 40 2769 5.2.1 Definitions .............................................. 40 2770 5.3 The Proxy MIB .............................................. 50 2771 5.3.1 Definitions .............................................. 50 2772 6 Identification of Management Targets in Notification Origi- 2773 nators .................................................... 56 2774 7 Notification Filtering ....................................... 57 2775 8 Management Target Translation in Proxy Forwarder Applica- 2776 tions ..................................................... 59 2777 8.1 Management Target Translation for Request Forwarding ....... 59 2778 8.2 Management Target Translation for Notification Forwarding 2779 ........................................................... 60 2780 9 Security Considerations ...................................... 62 2781 10 Editor's Address ............................................ 62 2782 11 Acknowledgments ............................................. 62 2783 12 References .................................................. 65 2784 Appendix A Trap Configuration Example .......................... 66