idnits 2.17.1 draft-ietf-snmpv3-appl-00.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-03-29) 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 61 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 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([SNMPV3-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 553: '...P manageable, it MUST use the manageme...' RFC 2119 keyword, line 789: '...e SNMP manageable, it MUST use the MIB...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2508 has weird spacing: '...tDomain snmp...' == Line 2517 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 (July 18, 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 2358, but no explicit reference was found in the text == Unused Reference: 'RFC1213' is defined on line 2364, but no explicit reference was found in the text == Unused Reference: 'RFC1902' is defined on line 2370, but no explicit reference was found in the text == Unused Reference: 'RFC1903' is defined on line 2377, but no explicit reference was found in the text == Unused Reference: 'SNMPV3-MPC' is defined on line 2410, but no explicit reference was found in the text == Unused Reference: 'SNMPV3-ACM' is defined on line 2416, 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-02 == Outdated reference: A later version (-06) exists of draft-ietf-snmpv3-next-gen-arch-02 -- Duplicate reference: draft-ietf-snmpv3-next-gen-arch, mentioned in 'SNMPV3-MPC', was also mentioned in 'SNMPV3-ARCH'. == Outdated reference: A later version (-06) exists of draft-ietf-snmpv3-next-gen-arch-02 -- Duplicate reference: draft-ietf-snmpv3-next-gen-arch, mentioned in 'SNMPV3-ACM', was also mentioned in 'SNMPV3-MPC'. Summary: 19 errors (**), 0 flaws (~~), 14 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft SNMPv3 Applications July 1997 4 SNMPv3 Applications 6 July 18, 1997 8 10 David B. Levi 11 SNMP Research, Inc. 12 levi@snmp.com 14 Paul Meyer 15 Secure Computing Corporation 16 paul_meyer@securecomputing.com 18 Bob Stewart 19 Cisco Systems 20 bstewart@cisco.com 22 Status of this Memo 24 This document is an Internet-Draft. Internet-Drafts are working 25 documents of the Internet Engineering Task Force (IETF), its areas, 26 and its working groups. Note that other groups may also distribute 27 working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as ``work in progress.'' 34 To learn the current status of any Internet-Draft, please check the 35 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 36 Directories on ds.internic.net (US East Coast), nic.nordu.net 37 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 38 Rim). 40 1. Abstract 42 This memo describes the various types of SNMP applications which make 43 use of an SNMP engine as described in [SNMPV3-ARCH]. There are five 44 types of application described herein: 46 - Applications which initiate SNMP Get, GetNext, GetBulk, and/or 47 Set requests, called 'command generators'. 49 - Applications which respond to SNMP Get, GetNext, GetBulk, 50 and/or Set requests, called 'command responders'. 52 - Applications which generate notifications, called 53 'notification originators'. 55 - Applications which receive notifications, called 'notification 56 receivers'. 58 - Applications which forward SNMP Get, GetNext, GetBulk, and/or 59 Set requests or notifications, called 'proxy forwarders'. 61 This memo also defines MIBs for specifying targets of management 62 operations, for notification filtering, and for proxy forwarding. 64 2. Overview 66 Traditionally there are two types of applications in SNMP, managers 67 and agents. However, it is useful to further divide these types of 68 applications in order to define an overall architecture for SNMP. 69 This document describes the five types of SNMP applications: 71 - Applications which initiate SNMP Get, GetNext, GetBulk, and/or 72 Set requests, called 'command generators'. 74 - Applications which respond to SNMP Get, GetNext, GetBulk, 75 and/or Set requests, called 'command responders'. 77 - Applications which generate notifications, called 78 'notification originators'. 80 - Applications which receive notifications, called 'notification 81 receivers'. 83 - Applications which forward SNMP Get, GetNext, GetBulk, and/or 84 Set requests or notifications, called 'proxy forwarder'. 86 Note that an agent, in the traditional meaning, can be thought of as 87 a combination of a command responder application, a notification 88 generator application, and the SNMP engine associated with these 89 applications. Likewise, a manager, in the traditional meaning, can 90 be thought of as a combination of a command generator application, a 91 notification receiver application, and the SNMP engine associated 92 with these applications. However, there are no restrictions on the 93 types of applications that may be associated with a particular SNMP 94 engine. For example, a single SNMP engine may in fact be associated 95 with both command generator and command responder applications. 97 2.1. Command Generators 99 A command generator application initiates SNMP Get, GetNext, GetBulk, 100 and/or Set requests, as well as processing the response to a request 101 which it generated. 103 2.2. Command Responders 105 A command responder application receives SNMP Get, GetNext, GetBulk, 106 and/or Set requests for which the contextEngineID is equal to that of 107 the local engine through which the request was received. The command 108 responder will perform the appropriate protocol operation, using 109 access control, and will generate a response message to be sent to 110 the request's originator. 112 2.3. Notification Originators 114 A notification originator conceptually monitors a system for 115 particular events or conditions, and generates Trap and/or Inform 116 messages based on these events or conditions. A notification 117 originator must have a mechanism for determining where to send 118 messages, and what SNMP information to use when sending messages. A 119 mechanism and MIB for this purpose is provided in this document. 121 2.4. Notification Receivers 123 A notification receiver application listens for notification 124 messages, and generates response messages when a message containing 125 an Inform PDU is received. 127 2.5. Proxy Forwarder 129 A proxy forwarder application forwards SNMP messages. Note that 130 implementation of a proxy forwarder application is optional. The 131 sections describing proxy (4.5, 5.3, and 8) may be skipped for 132 implementations that do not include a proxy forwarder application. 134 The term "proxy" has historically been used very loosely, with 135 multiple different meanings. These different meanings include (among 136 others): 138 (1) the forwarding of SNMP requests to other SNMP agents without regard 139 for what managed object types are being accessed; for example, in 140 order to forward an SNMP request from one transport domain to 141 another, or to translate SNMP requests of one version into SNMP 142 requests of another version; 144 (2) the translation of SNMP requests into operations of some non-SNMP 145 management protocol; and 147 (3) support for aggregated managed objects where the value of one 148 managed object instance depends upon the values of multiple other 149 (remote) items of management information. 151 Each of these scenarios can be advantageous; for example, support for 152 aggregation of management information can significantly reduce the 153 bandwidth requirements of large-scale management activities. 154 However, using a single term to cover multiple different scenarios 155 causes confusion. 157 To avoid such confusion, this document uses the term "proxy" with a 158 much more tightly defined meaning. The term "proxy" is used in this 159 document to refer to a proxy forwarder application which forwards 160 either SNMP requests or notifications without regard for what managed 161 objects are contained within requests or notifications. This 162 definition is most closely related to the first definition above. 163 Note however that in the SNMPv3 architecture, a proxy forwarder is 164 actually an application, and need not actually be an SNMP agent. 166 Specifically, the distinction between a regular SNMP agent and a 167 "proxy forwarder application" is simple: 169 - a proxy forwarder application forwards requests and/or 170 notifications on to other SNMP engines according to the 171 context, and irrespective of the specific managed object types 172 being accessed, and forwards the response to such previously 173 forwarded messages back to the SNMP engine from which the 174 original message was received; 176 - in contrast, the command responder application that is part of 177 an SNMP agent processes SNMP requests according to the (names 178 of the) individual managed object types and instances being 179 accessed, is NOT a proxy forwarder application from the 180 perspective of this document. 182 Thus, when a proxy forwarder application forwards a request or 183 notification for a particular context, not only is the information on 184 how to forward the request specifically associated with that context, 185 but the proxy forwarder application has no need of a detailed 186 definition of a MIB view (since the proxy forwarder application 187 forwards the request irrespective of the managed object types). 189 In contrast, an SNMP agent must have the detailed definition of the 190 MIB view, and even if it needs to issue requests to other agents, 191 that need is dependent on the individual managed object instances 192 being accessed (i.e., not only on the context). 194 3. Management Targets 196 Some types of applications (in particular notification generators and 197 proxy forwarders) require a mechanism for determining where and how 198 to send generated messages. This document provides a mechanism and 199 MIB for this purpose. The set of information that describes where 200 and how to send a message is called a 'Management Target', and 201 consists of two kinds of information: 203 - Destination information, consisting of a transport domain and 204 a transport address. This is also termed a transport 205 endpoint. 207 - SNMP information, consisting of message processing model, 208 security model, level of security, and security name 209 information. 211 There can be a many-to-many relationship between these two types of 212 information. That is, there may be multiple transport endpoints 213 associated with a particular set of SNMP information, or a particular 214 transport endpoint may be associated with several sets of SNMP 215 information. 217 A management target is defined as the combination of a single set of 218 SNMP information and a single transport endpoint. Management targets 219 are grouped according to their SNMP information. That is, each 220 distinct set of SNMP information may be associated with multiple 221 transport endpoints. The set of management targets which are defined 222 by a distinct set of SNMP information are considered to be members of 223 the same management target group. For example, the following 224 contains two management target groups, each of which contains three 225 management targets: 227 (version=snmpv3, secmodel=usm, secname=joe, udp=128.1.2.3:162) 228 (version=snmpv3, secmodel=usm, secname=joe, udp=128.1.3.5:162) 229 (version=snmpv3, secmodel=usm, secname=joe, udp=128.1.4.7:162) 230 (version=snmpv3, secmodel=usm, secname=martha, udp=128.1.2.3:162) 231 (version=snmpv3, secmodel=usm, secname=martha, udp=128.1.3.5:162) 232 (version=snmpv3, secmodel=usm, secname=martha, udp=128.1.4.7:162) 234 An application will generally make use of some subset of the entire 235 set of management targets which are configured. 237 4. Elements Of Procedure 239 The following sections describe the procedures followed by each type 240 of application when generating messages for transmission or when 241 processing received messages. Applications communicate with the 242 Message Processing Subsystem using the abstract service interfaces 243 defined in [SNMPV3-ARCH]. 245 4.1. Command Generators 247 A command generator initiates an SNMP request by calling the Message 248 Processing Subsystem using the following abstract service interface: 250 sendPdu ( 251 transportDomain 252 transportAddress 253 messageProcessingModel 254 securityModel 255 securityName 256 LoS 257 contextEngineID 258 contextName 259 PDU 260 expectResponse 261 ) 263 Where: 265 - The transportDomain is that of the destination of the message. 267 - The transportAddress is the destination of the message. 269 - The messageProcessingModel indicates which Message Processing 270 Subsystem the application wishes to use. 272 - The securityModel is the security model that the application 273 wishes to use. 275 - The securityName is whatever the security model wishes to use. 277 - The LoS is the security level that the application wishes to 278 use. 280 - The contextEngineID is provided by the command generator if it 281 wishes to explicitly specify the location of the management 282 information it is requesting. The command generator may omit 283 this parameter, in which case the Message Processing Subsystem 284 should use the engineID of the SNMP engine to which the 285 request is to be sent. 287 - The contextName is provided by the command generator if it 288 wishes to explicitly specify the location of the management 289 information it is requesting. The command generator may omit 290 this parameter, in which case the default context is used. 292 - The PDU is the value constructed in the previous step. 294 - The expectResponse argument indicates that a response is 295 expected. 297 The Message Processing Subsystem is responsible for delivering the 298 response to a particular request to the correct command generator 299 application. The abstract service interface used is: 301 processResponsePdu ( 302 contextEngineID 303 contextName 304 PDU 305 LoS 306 statusInformation 307 ) 309 Where: 311 - The contextEngineID is the value from the received response. 313 - The contextName is the value from the received response. 315 - The PDU is the value from the received response. 317 - The LoS is the value from the received response. 319 - The statusInformation indicates success or failure in 320 receiving the response. 322 The procedure when a command generator receives a response is as 323 follows: 325 (1) The SNMPv2 operation type is determined from the ASN.1 tag value 326 associated with the PDU parameter. The operation type should 327 always be a Response (the Message Processing Subsystem should never 328 call a command generator application using the processResponsePdu 329 interface for any other type of message). 331 (2) The request-id, error-status, error-index, and variable-bindings 332 are extracted from the PDU and saved. 334 (3) At this point, it is up to the application as to how to continue 335 processing the PDU. 337 4.2. Command Responders 339 Before a command responder application can process messages, it must 340 first associate itself with an SNMP engine. The abstract service 341 interface used for this purpose is: 343 statusInformation = 344 registerContextEngineID ( 345 contextEngineID 346 pduType 347 ) 349 Where: 351 - The statusInformation indications success or failure of the 352 registration attempt. 354 - The contextEngineID is equal to the snmpEngineID of the SNMP 355 engine with which the command responder is registering. 357 - The pduType indicates a Get, GetNext, GetBulk, or Set pdu. 359 Note that if another command responder application is already 360 registered with an SNMP engine, any further attempts to register with 361 the same contextEngineID and pduType will be ignored. This implies 362 that separate command responder applications could register 363 separately for the various pdu types. However, in practice this is 364 undesirable, and only a single command responder application should 365 be registered with an SNMP engine at any given time. 367 A command responder application can disassociate with an SNMP engine 368 using the following abstract service interface: 370 unregisterContextEngineID ( 371 contextEngineID 372 pduType 373 ) 375 Where: 377 - The contextEngineID is equal to the snmpEngineID of the SNMP 378 engine with which the command responder is cancelling the 379 registration. 381 - The pduType indicates a Get, GetNext, GetBulk, or Set pdu. 383 Once the command responder has registered with the SNMP engine, it 384 waits to receive SNMP messages. The abstract service interface used 385 for receiving messages is: 387 processPdu ( 388 contextEngineID 389 contextName 390 PDU 391 maxSizeResponseScopedPDU 392 securityModel 393 securityName 394 LoS 395 stateReference 396 ) 398 Where: 400 - The contextEngineID is the value from the received message. 402 - The contextName is the value from the received message. 404 - The PDU is the value from the received message. 406 - The maxSizeResponseScopedPDU is the value from the received 407 message. 409 - The securityModel is the value from the received message. 411 - The securityName is the value from the received message. 413 - The LoS is the value from the received message. 415 - The stateReference is a value assigned by the Message 416 Processing Subsystem. This subsystem caches information about 417 each received request message. The stateReference is a 418 reference to this cached information. This value must be 419 returned to the Message Processing Subsystem in order to 420 generate a response. 422 The procedure when a message is received is as follows. 424 (1) The SNMPv2 operation type is determined from the ASN.1 tag value 425 associated with the PDU parameter. The operation type should 426 always be a Get, GetNext, GetBulk, or Set (the Message Processing 427 Subsystem should never call a command responder application using 428 the processPdu interface for any other type of PDU). 430 (2) The request-id is extracted from the PDU and saved. 432 (3) If the SNMPv2 operation type is GetBulk, the non-repeaters and 433 max-repetitions values are extracted from the PDU and saved. 435 (4) The variable-bindings are extracted from the PDU and saved. 437 (5) The management operation represented by the SNMPv2 operation type 438 is performed with respect to the relevant MIB view within the 439 context named by the contextName, according to the procedures set 440 forth in [RFC1905]. The relevant MIB view is determined by the 441 LoS, securityModel, contextName, securityName, and SNMPv2 operation 442 type. To determine whether a particular object instance is within 443 the relevant MIB view, the following abstract service interface is 444 called: 446 statusInformation = 447 isAccessAllowed ( 448 securityModel 449 securityName 450 LoS 451 viewType 452 contextName 453 variableName 454 ) 456 Where: 458 - The securityModel is the value from the received message. 460 - The securityName is the value from the received message. 462 - The LoS is the value from the received message. 464 - The viewType indicates whether the pdu type is a read or write 465 operation. 467 - The contextName is the value from the received message. 469 - The variableName is the object instance of the variable for 470 which access rights are to be checked. 472 Normally, the result of the management operation will be a new PDU 473 value, and processing will continue in the next step. However, 474 there are two conditions under which a new PDU value will not be 475 generated: 477 - If at any time during the processing of the management 478 operation, the context named by the contextName parameter is 479 unavailable, processing of the management operation is halted, 480 no result PDU is generated, the snmpUnavailableContexts 481 counter is incremented, and control is passed to the next 482 step. 484 - The isAccessAllowed abstract service interface is conceptually 485 called for each object in the variable-bindings (and possibly 486 multiple times for a single variable-bindings in the case of a 487 GetNext or GetBulk PDU). At any point, if the returned 488 statusInformation indicates an error, result indicates an 489 error, processing of the management operation is halted, no 490 result PDU is generated, the snmpUnavailableViews counter is 491 incremented, and control is passed to the next step. 493 (6) The Message Processing Subsystem is called to generate a response 494 or report message. The abstract service interface is: 496 returnResponsePdu ( 497 contextEngineID 498 contextName 499 PDU 500 maxSizeResponseScopedPDU 501 securityModel 502 securityName 503 LoS 504 stateReference 505 statusInformation 506 ) 508 Where: 510 - The contextEngineID is the value from the processPdu call. 512 - The contextName is the value from the processPdu call. 514 - The PDU is the result generated in the previous step. If no 515 result PDU was generated, the PDU is an undefined value. 517 - The maxSizeResponseScopedPDU is a local value indicating the 518 maximum size of a ScopedPDU that the application can accept. 520 - The securityModel is the value from the processPdu call. 522 - The securityName is the value from the processPdu call. 524 - The LoS is the value from the processPdu call. 526 - The stateReference is the value from the processPdu call. 528 - The statusInformation either contains an indication that no 529 error occured and that a response should be generated, or 530 contains an indication that an error occured along with the 531 OID and counter value needed to generate a Report PDU. In the 532 latter case, the OID and counter value are that of the counter 533 that was incremented in the previous step 534 (snmpUnavailableContexts or snmpUnavailableViews). 536 Note that a command responder application should always call the 537 returnResponsePdu abstract service interface, even in the event of an 538 error such as a resource allocation error. In the event of such an 539 error, the PDU value passed to returnResponsePdu should contain 540 appropriate values for errorStatus and errorIndex. 542 4.3. Notification Originators 544 A notification originator application generates SNMP notification 545 messages. A notification message can contain either an SNMPv2-Trap 546 PDU or an Inform PDU. However, a particular implementation is not 547 required to be capable of generating both types of messages. 549 Notification originator applications require a mechanism for 550 identifying the management targets to which notifications should be 551 sent. The particular mechanism used is implementation dependent, 552 however, if an implementation makes the configuration of management 553 targets SNMP manageable, it MUST use the management target MIB 554 described in this document. 556 When a notification originator wishes to generate a notification, it 557 must first determine the contextEngineID and contextName of the 558 location where the information to be conveyed in the notification 559 exists. It must then determine the set of management targets to 560 which the notification should be sent, and the grouping of these 561 management targets. The application must also determine, for each 562 group of management targets, whether the notification message should 563 contain an SNMPv2-Trap PDU or Inform PDU, and if it is to contain an 564 Inform PDU, the number of retries and retransmission algorithm. 566 The mechanism by which a notification originator determines this 567 information is implementation dependent. Once the application has 568 determined this information, the following procedure is performed for 569 each group of management targets: 571 (1) Any appropriate filtering mechanisms are applied to determine 572 whether the notification should be sent to the management targets 573 in this group. If such filtering mechanisms determine that the 574 notification should not be sent, processing continues with the next 575 group of management targets. Otherwise, 577 (2) The appropriate set of variable-bindings is retrieved from local 578 MIB instrumentation within the relevant MIB view. The relevant MIB 579 view is determined by the LoS, securityModel, contextName, and 580 securityName of the management target. To determine whether a 581 particular object instance is within the relevant MIB view, the 582 isAccessAllowed abstract service interface is used, in the same 583 manner as described in the preceeding section. If the 584 statusInformation returned by isAccessAllowed does not indicate 585 accessAllowed, the notification is not sent to any of the 586 management targets within this group. 588 (3) A PDU is constructed using a locally unique request-id value, an 589 operation type of Trap or Inform, an error-status and error-index 590 value of 0, and the variable-bindings found in the previous step. 592 (4) If the notification should be contain an SNMPv2-Trap PDU for this 593 group, then for each management target in the group, the Message 594 Processing Subsystem is called using the following abstract service 595 interface: 597 sendPdu ( 598 transportDomain 599 transportAddress 600 messageProcessingModel 601 securityModel 602 securityName 603 LoS 604 contextEngineID 605 contextName 606 PDU 607 expectResponse 608 ) 610 Where: 612 - The transportDomain is that of the management target. 614 - The transportAddress is that of the management target. 616 - The messageProcessingModel is that of the management target. 618 - The securityModel is that of the management target. 620 - The securityName is that of the management target. 622 - The LoS is that of the management target. 624 - The contextEngineID is the value originally determined for the 625 notification. 627 - The contextName is the value originally determined for the 628 notification. 630 - The PDU is the value constructed in the previous step. 632 - The expectResponse argument indicates that no response is 633 expected. 635 Otherwise, 637 (5) If the notification should contain an Inform PDU for this group, 638 then: 640 a) For each management target in the group, the Message 641 Processing Subsystem is called using the sendPdu abstract 642 service interface as described in the previous step, except 643 that the expectResponse arguments indicates that a response is 644 expected. 646 b) The application caches information about the management 647 target group. 649 c) If a response is received within an appropriate time interval 650 from any one transport endpoint within the group, the 651 notification is considered acknowledged for this group, the 652 cached information is deleted, and any further responses to 653 this Inform are ignored. Otherwise, 655 d) If a response is not received within an appropriate time 656 period, information about the management target group is 657 retrieved from the cache, and steps a) through d) are 658 repeated. The number of times these steps are repeated is as 659 previously determined. If this retry count is exceeded, the 660 acknowledgement of the notification is considered to have 661 failed, and processing of the notification for this group of 662 management targets is halted. 664 Responses to Inform PDU notifications will be received via the 665 processResponsePDU abstract service interface. 667 4.4. Notification Receivers 669 Notification receiver applications receive SNMP Notification messages 670 from the Message Processing Subsystem. Before any messages can be 671 received, the notification receiver must register with the Message 672 Processing Subsystem using the registerContextEngineID abstract 673 service interface. The parameters used are: 675 - The contextEngineID is an undefined 'wildcard' value. 676 Notifications are delivered to a registered notification 677 receiver regardless of the contextEngineID contains in the 678 notification message. 680 - The pduType indicates either SNMPv2-Trap PDUs or Inform PDUs, 681 or both. 683 Once the notification receiver has registered with the Message 684 Processing Subsystem, messages are received using the processPdu 685 abstract service interface. Parameters are: 687 - The contextEngineID is the value from the received message. 689 - The contextName is the value from the received message. 691 - The PDU is the value from the received message. 693 - The maxSizeResponseScopedPDU is the value from the received 694 message. 696 - The securityModel is the value from the received message. 698 - The securityName is the value from the received message. 700 - The LoS is the value from the received message. 702 - If the message contains an SNMPv2-Trap PDU, the stateReference 703 is undefined and unused. Otherwise, the stateReference is a 704 value assigned by the Message Processing Subsystem which 705 references cached information about the notification. This 706 value must be returned to the Message Processing Subsystem in 707 order to generate a response. 709 When an SNMPv2-Trap PDU is delivered to a notification receiver 710 application, it first extracts the SNMP operation type, request-id, 711 error-status, error-index, and variable-bindings from the PDU. After 712 this, processing depends on the particular implementation. 714 When an Inform PDU is received, the notification receiver application 715 follows the following procedure: 717 (1) The SNMPv2 operation type, request-id, error-status, error-index, 718 and variable-bindings are extracted from the PDU. 720 (2) A Response PDU is constructed using the extracted request-id and 721 variable-bindings, and with error-status and error-index both set 722 to 0. 724 (3) The Message Processing Subsystem is called to generate a response 725 message using the returnResponsePdu abstract service interface. 726 Parameters are: 728 - The contextEngineID is the value from the processPdu call. 730 - The contextName is the value from the processPdu call. 732 - The PDU is the result generated in the previous step. 734 - The maxSizeResponseScopedPDU is a local value indicating the 735 maximum size of a ScopedPDU that the application can accept. 737 - The securityModel is the value from the processPdu call. 739 - The securityName is the value from the processPdu call. 741 - The LoS is the value from the processPdu call. 743 - The stateReference is the value from the processPdu call. 745 - The statusInformation indicates that no error occured and that 746 a response should be generated. 748 Note that there may be multiple notification receiver applications 749 associated with a particular SNMP engine. Despite this, only a 750 single response should be generated when an Inform PDU is received. 751 The mechanism to ensure this is implementation specific. One 752 strategy to accomplish this is to simply let the Message Processing 753 Subsystem delete the stateReference when the first response is 754 generated. Subsequent attempts to send the response will fail 755 because the stateReference no longer exists within the Message 756 Processing Subsystem. 758 4.5. Proxy Forwarders 760 A proxy forwarder application deals with forwarding messages which 761 contain Get, GetNext, GetBulk, Set, SNMPv2-Trap, and Inform PDUs. Of 762 these PDU types, the first four (Get, GetNext, GetBulk, Set) deal 763 with requesting or modifying information located within a particular 764 context, and the last two (Trap, Inform) deal with notifications 765 concerning information located within a particular context. A proxy 766 forwarder application treats these two situations slightly different. 768 In the first situation, the proxy forwarder's role is ultimately to 769 deliver a request for management information to the SNMP engine which 770 has access to that information, and to deliver the response 771 containing the information back to the SNMP engine which initiated 772 the request. The context information in a request is used to 773 determine which SNMP engine has access to the requested information, 774 and this is used to determine where and how to forward the request. 776 In the second situation, the proxy forwarder's role is to determine 777 which SNMP engines should receive notification about management 778 information from a particular location. The context information in a 779 notification message determines the location to which the information 780 contained in the notification applies. This is used to determine 781 which SNMP engines should receive notification about this 782 information. 784 When forwarding messages, a proxy forwarder application must perform 785 a translation of incoming management target information into outgoing 786 management target information. How this translation is performed is 787 implementation specific. In many cases, this will be driven by a 788 preconfigured translation table. If a proxy forwarder application 789 makes the contents of this table SNMP manageable, it MUST use the MIB 790 defined in this document. 792 4.5.1. Request Forwarding 794 There are two phases for request forwarding, processing an incoming 795 request, and processing and incoming response. These are described 796 in the following two sections. 798 4.5.1.1. Processing an Incoming Request 800 A proxy forwarder application that wishes to forward request messages 801 must first register with the Message Processing Subsystem using the 802 registerContextEngineID abstract service interface. The proxy 803 forwarder must register each contextEngineID for which it wishes to 804 forward messages, as well as for each pduType. Note that as the 805 configuration of a proxy forwarder is changed, the particular 806 contextEngineID values for which it is forwarding may change. The 807 proxy forwarder should call the registerContextEngineID and 808 unregisterContextEngineID abstract service interfaces as needed to 809 reflect its current configuration. 811 A proxy forwarder application should never attempt to register a 812 value of contextEngineID which is equal to the snmpEngineID of the 813 SNMP engine to which the proxy forwarder is associated. 815 Once the proxy forwarder has registered for the appropriate 816 contextEngineId values, it can start processing messages. The 817 following procedure is used: 819 (1) A message is received using the processPdu abstract service 820 interface. The incoming management target information received 821 from the processPdu interface is translated into outgoing 822 management target information. Note that this translation may vary 823 for different values of contextEngineID and/or contextName. The 824 translation should result in a single management target. 826 (2) If appropriate outgoing management target information cannot be 827 found, the proxy forwarder increments the snmpProxyDrops counter 828 [RFC1907], and then calls the Message Processing Subsystem using 829 the returnResponsePdu abstract service interface. Parameters are: 831 - The contextEngineID is the value from the processPdu call. 833 - The contextName is the value from the processPdu call. 835 - The PDU is an undefined value. 837 - The maxSizeResponseScopedPDU is a local value indicating the 838 maximum size of a ScopedPDU that the application can accept. 840 - The securityModel is the value from the processPdu call. 842 - The securityName is the value from the processPdu call. 844 - The LoS is the value from the processPdu call. 846 - The stateReference is the value from the processPdu call. 848 - The statusInformation indicates that an error occured and that 849 an snmpProxyDrops Report message should be generated. 851 Processing of the message stops at this point. Otherwise, 853 (3) A new PDU is constructed. A unique value of request-id should be 854 used in the new PDU (this value will enable a subsequent response 855 message to be correlated with this request). The remainder of the 856 new PDU is identical to the received PDU, unless the incoming SNMP 857 version is SNMPv1 and the outgoing SNMP version is SNMPv2 or 858 SNMPv3, or vice-versa, in which case the proxy forwarder must apply 859 the translation rules as documented in [RFC1908]. 861 (4) The proxy forwarder calls the Message Processing Subsystem to 862 generate the forwarded message, using the sendPdu abstract service 863 interface. The parameters are: 865 - The transportDomain is that of the outgoing management target. 867 - The transportAddress is that of the outgoing management 868 target. 870 - The messageProcessingModel is that of the outgoing management 871 target. 873 - The securityModel is that of the outgoing management target. 875 - The securityName is that of the outgoing management target. 877 - The LoS is that of the outgoing management target. 879 - The contextEngineID is the value originally received. 881 - The contextName is the value originally received. 883 - The PDU is the value constructed in the previous step. 885 - The expectResponse argument indicates that a response is 886 expected. If the sendPdu call is unsuccessful, the proxy 887 forwarder performs the steps described in (2) above. 888 Otherwise: 890 (5) The proxy forwarder caches the contextEngineId, contextName, 891 stateReference, incoming management target information, outgoing 892 management information, and any other information needed to match 893 an incoming response to the forwarded request. If this information 894 cannot be cached (possibly due to a lack of resources), the proxy 895 forwarder performs the steps described in (2) above. Otherwise: 897 (6) Processing of the request stops until a response to the forwarded 898 request is received, or until an appropriate time interval has 899 expired. If this time interval expires before a response has been 900 received, the cached information about this request is removed, and 901 the proxy forwarder performs the steps described in (2) above using 902 the cached information. 904 4.5.1.2. Processing an Incoming Response 906 A proxy forwarder follows the following procedure when an incoming 907 response is received: 909 (1) The incoming response is received using the processPdu interface. 910 The proxy forwarder uses the received parameters to locate an entry 911 in its cache of pending forwarded requests. This is done by 912 matching the received parameters with the cached values of 913 contextEngineID, contextName, outgoing management target 914 information, and the request-id contained in the received PDU (the 915 proxy forwarder must extract the request-id for this purpose). If 916 an appropriate cache entry cannot be found, processing of the 917 response is halted. Otherwise: 919 (2) The cache information is extracted, and removed from the cache. 921 (3) If the incoming SNMP version is SNMPv1 and the outgoing SNMP 922 version is SNMPv2 or SNMPv3, or vice-versa, the proxy forwarder 923 must apply the translation rules documented in [RFC1908]. 925 (4) The proxy forwarder calls the Message Processing Subsystem using 926 the returnResponsePdu abstract service interface. Parameters are: 928 - The contextEngineID is the value extracted from the cache. 930 - The contextName is the value extracted from the cache. 932 - The PDU is the (possibly translated) Response PDU. 934 - The maxSizeResponseScopedPDU is a local value indicating the 935 maximum size of a ScopedPDU that the application can accept. 937 - The securityModel is that of the original incoming management 938 target extracted from the cache. 940 - The securityName is that of the original incoming management 941 target extracted from the cache. 943 - The LoS is that of the original incoming management target 944 extracted from the cache. 946 - The stateReference is the value extracted from the cache. 948 - The statusInformation indicates that no error occured and that 949 a Response message should be generated. 951 4.5.2. Notification Forwarding 953 A proxy forwarder receives notifications in the same manner as a 954 notification receiver application, using the processPdu abstract 955 service interface. The following procedure is used when a 956 notification is received: 958 (1) The incoming management target information received from the 959 processPdu interface is translated into outgoing management target 960 information. Note that this translation may vary for different 961 values of contextEngineId and/or contextName. The translation may 962 result in one or more management target groups, each of which may 963 contain multiple management targets. 965 (2) If appropriate outgoing management target information cannot be 966 found and the notification was a Trap, processing of the 967 notification is halted. If appropriate outgoing management target 968 information cannot be found and the notification was an Inform, the 969 proxy forwarder increments the snmpProxyDrops object, and calls the 970 Message Processing Subsystem using the returnResponsePdu abstract 971 service interface. The parameters are: 973 - The contextEngineID is the received value. 975 - The contextName is the received value. 977 - The PDU is an undefined and unused value. 979 - The maxSizeResponseScopedPDU is a local value indicating the 980 maximum size of a ScopedPDU that the application can accept. 982 - The securityModel is the received value. 984 - The securityName is the received value. 986 - The LoS is the received value. 988 - The stateReference is the received value. 990 - The statusInformation indicates that an error occured and that 991 a Report message should be generated. 993 Processing of the message stops at this point. Otherwise, 995 (3) The proxy forwarder generates a notification using the procedures 996 described in the preceeding section on Notification Originators, 997 with the following exceptions: 999 - The contextEngineID and contextName values from the original 1000 received notification are used. 1002 - The outgoing management targets previously determined are 1003 used. 1005 - No filtering mechanisms are applied. 1007 - The variable-bindings from the original received notification 1008 are used, rather than retrieving variable-bindings from local 1009 MIB instrumentation. In particular, no access-control is 1010 applied to these variable-bindings. 1012 - If for any of the outgoing management targets, the incoming 1013 SNMP version is SNMPv1 and the outgoing SNMP version is SNMPv2 1014 or SNMPv3, the proxy forwarder must apply the translation 1015 rules as documented in [RFC1908]. 1017 - If for any of the outgoing management targets, the incoming 1018 SNMP version is SNMPv2 or SNMPv3, and the outgoing SNMP 1019 version is SNMPv1, this outgoing management target is not used 1020 when generating the forwarded notifications. 1022 (4) If the original received notification contains an SNMPv2-Trap PDU, 1023 processing of the notification is now completed. Otherwise, the 1024 original received notification must contain an Inform PDU, and 1025 processing continues. 1027 (5) If the forwarded notifications included any Inform PDUs, processing 1028 continues when the procedures described in the section for 1029 Notification Originators determine that either: 1031 - None of the generated notifications containing Inform PDUs 1032 have been successfully acknowledged within the longest of the 1033 time intervals, in which case processing of the original 1034 notification is halted and an snmpProxyDrops Report PDU is 1035 generated, or, 1037 - At least one of the generated notifications containing Inform 1038 PDUs is successfully acknowledged, in which case a response to 1039 the original received notification containing an Inform PDU is 1040 generated as described in the following steps. 1042 (6) A Response pdu is constructed, using the values of request-id and 1043 variable-bindings from the original received Inform PDU, and 1044 error-status and error-index values of 0. 1046 (7) The Message Processing Subsystem is called using the 1047 returnResponsePdu abstract service interface. Parameters are: 1049 - The contextEngineID is the originally received value. 1051 - The contextName is the originally received value. 1053 - The PDU is the value constructed in the previous step. 1055 - The maxSizeResponseScopedPDU is a local value indicating the 1056 maximum size of a ScopedPDU that the application can accept. 1058 - The securityModel is the originally received value. 1060 - The securityName is the originally received value. 1062 - The LoS is the originally received value. 1064 - The stateReference is the originally received value. 1066 - The statusInformation indicates that no error occured and that 1067 a Response message should be generated. 1069 5. The Structure of the MIBs 1071 There are three separate MIBs described in this document, the 1072 management target MIB, the notification MIB, and the proxy MIB. The 1073 following sections describe the structure of these three MIBs. 1075 5.1. The Management Target MIB 1077 This MIB contains objects for defining management targets. It 1078 consists of one scalar, two tables, and conformance/compliance 1079 statements. 1081 The scalar, snmpTargetAddressSpinLock, is used by managers when 1082 creating new rows in the snmpTargetAddrTable. 1084 The first table, the snmpTargetAddrTable, contains information about 1085 transport domains/addresses. The table is indexed by an 1086 SnmpAdminString type object and an integer type object. This allows 1087 domains/addresses to be organized into groups. 1089 The second table, the snmpTargetTable, contains information about 1090 SNMP version and security information to be used when sending 1091 messages to a particular group of transport domains/addresses. 1093 5.1.1. Definitions 1095 SNMPV3-TARGET-MIB DEFINITIONS ::= BEGIN 1097 IMPORTS 1098 MODULE-IDENTITY, 1099 OBJECT-TYPE, 1100 OBJECT-IDENTITY, 1101 Integer32 1102 FROM SNMPv2-SMI 1104 TDomain, 1105 TAddress, 1106 TruthValue, 1107 TimeInterval, 1108 RowStatus, 1109 StorageType 1110 FROM SNMPv2-TC 1112 SnmpSecurityModel, 1113 SnmpLoS, 1114 SnmpAdminString 1115 FROM SNMP-FRAMEWORK-MIB 1117 MODULE-COMPLIANCE, 1118 OBJECT-GROUP 1119 FROM SNMPv2-CONF; 1121 snmpTargetMIB MODULE-IDENTITY 1122 LAST-UPDATED "9707140000Z" 1123 ORGANIZATION "IETF SNMPv3 Working Group" 1124 CONTACT-INFO 1125 "David B. Levi 1126 SNMP Research, Inc. 1127 3001 Kimberlin Heights Road 1128 Knoxville, TN 37920-9716 1129 Tel: +1 423 573 1434 1130 E-mail: levi@snmp.com 1132 Paul Meyer 1133 Secure Computing Corporation 1134 2675 Long Lake Road 1135 Roseville, MN 55113 1136 Tel: +1 612 628 1592 1137 E-mail: paul_meyer@securecomputing.com 1139 Bob Stewart 1140 Cisco Systems 1141 ???? 1142 ???? 1143 Tel: +1 603 654 6923 1144 E-mail: bstewart@cisco.com" 1145 DESCRIPTION 1146 "This MIB module defines a MIB which provides mechanisms to 1147 remotely configure the parameters used by an SNMPv3 entity 1148 for the generation of notifications." 1149 REVISION "9707140000Z" 1150 DESCRIPTION 1151 "The initial revision." 1152 ::= { snmpModules 11 } -- TBD 1154 snmpTargetObjects OBJECT IDENTIFIER ::= { snmpTargetMIB 1 } 1155 snmpTargetConformance OBJECT IDENTIFIER ::= { snmpTargetMIB 2 } 1157 -- ------------------------------------------------------------------ 1158 -- 1159 -- The snmpTargetObjects group 1160 -- 1161 -- ------------------------------------------------------------------ 1163 snmpTargetAddressSpinLock OBJECT-TYPE 1164 SYNTAX TestAndIncr 1165 MAX-ACCESS read-write 1166 STATUS current 1167 DESCRIPTION 1168 "This object is used to facilitate creation of rows in the 1169 snmpTargetAddrTable. There are two situations where an 1170 SNMP entity may wish to create a new row, when a new group 1171 of addresses must be created, and when an address must be 1172 added to an existing group. 1174 When an SNMP entity wishes to create a new group of 1175 addresses, it should follow the following procedure: 1176 a) Retrieve the value of this object. 1177 b) Retrieve all existing index values of 1178 snmpTargetAddrName (this can be accomplished 1179 by retrieving all instances of any columnar 1180 object in the snmpTargetAddrTable). 1181 c) Retrieve the value of this object. If the value is 1182 not equal to the last retrieved value, go back to 1183 step b). 1184 d) Select a new unique index value for 1185 snmpTargetAddrName, and an arbitrary value for 1186 snmpTargetAddrSubIndex. Attempt a set request 1187 containing these varbinds: 1188 - The last retrieved value of this object. 1189 - An instance of the snmpTargetAddrRowStatus 1190 object whose indices are equal to the selected 1191 index values of snmpTargetAddrName and 1192 snmpTargetAddrSubIndex. 1193 - Additional varbinds for initializing other 1194 columnar objects in the row. 1195 If this set fails, the SNMP entity may return to 1196 step a) and try again. 1198 When an SNMP entity wishes to create a new address within 1199 an existing group of addresses, it should follow the 1200 following procedure: 1201 a) Retrieve all existing values of 1202 snmpTargetAddrSubIndex corresponding to the desired 1203 index value of snmpTargetAddrName. (this can be 1204 accomplished by retrieving all instances of any 1205 columnar object in the snmpTargetAddrTable whose 1206 index begins with the desired index value of 1207 snmpTargetAddrName). 1209 b) Select a new value for snmpTargetAddrSubIndex. 1210 Attempt a set request containing these varbinds: 1211 - An instance of the snmpTargetAddrRowStatus 1212 object whose indices are equal to the desired 1213 index value of snmpTargetAddrName and the 1214 selected index value of snmpTargetAddrSubIndex. 1215 - Additional varbinds for initializing other 1216 columnar objects in the row. 1217 If this set fails, the SNMP entity may return to 1218 step a) and try again." 1219 ::= { snmpTargetObjects 1 } 1221 snmpTargetAddrTable OBJECT-TYPE 1222 SYNTAX SEQUENCE OF SnmpV3TargetAddrEntry 1223 MAX-ACCESS not-accessible 1224 STATUS current 1225 DESCRIPTION 1226 "" 1227 ::= { snmpTargetObjects 2 } 1229 snmpTargetAddrEntry OBJECT-TYPE 1230 SYNTAX SnmpV3TargetAddrEntry 1231 MAX-ACCESS not-accessible 1232 STATUS current 1233 DESCRIPTION 1234 "" 1235 INDEX { snmpTargetAddrName, snmpTargetAddrSubIndex } 1236 ::= { snmpTargetAddrTable 1 } 1238 SnmpV3TargetAddrEntry ::= SEQUENCE { 1239 snmpTargetAddrSubIndex Integer32, 1240 snmpTargetAddrTDomain TDomain, 1241 snmpTargetAddrTAddress TAddress, 1242 snmpTargetAddrTimeout TimeInterval, 1243 snmpTargetAddrStorageType StorageType, 1244 snmpTargetAddrRowStatus RowStatus 1245 } 1247 snmpTargetAddrSubIndex OBJECT-TYPE 1248 SYNTAX Integer32 (1..2147483647) 1249 MAX-ACCESS not-accessible 1250 STATUS current 1251 DESCRIPTION 1252 "The locally arbitrary, but unique identifier associated 1253 an snmpTargetAddrEntry within a group of entries in the 1254 snmpTargetAddrTable." 1255 ::= { snmpTargetAddrEntry 1 } 1256 snmpTargetAddrTDomain OBJECT-TYPE 1257 SYNTAX TDomain 1258 MAX-ACCESS read-create 1259 STATUS current 1260 DESCRIPTION 1261 "This object indicates the transport type of the address 1262 contained in the snmpTargetAddrTAddress object." 1263 ::= { snmpTargetAddrEntry 2 } 1265 snmpTargetAddrTAddress OBJECT-TYPE 1266 SYNTAX TAddress 1267 MAX-ACCESS read-create 1268 STATUS current 1269 DESCRIPTION 1270 "This object contains a transport address. The format of 1271 this address depends on the value of the 1272 snmpTargetAddrTDomain object." 1273 ::= { snmpTargetAddrEntry 3 } 1275 snmpTargetAddrTimeout OBJECT-TYPE 1276 SYNTAX TimeInterval 1277 MAX-ACCESS read-create 1278 STATUS current 1279 DESCRIPTION 1280 "This object should reflect the expected round trip time 1281 for communicating with the transport address defined by 1282 this row. When a message is sent to this address, and 1283 a response (if one is expected) is not received within 1284 this time period, an implementation may assume that the 1285 response will not be delivered. 1287 Note that the time interval that an application waits 1288 for a response may actually be derived from the value 1289 of this object. The method for deriving the actual time 1290 interval is implementation dependent. One such method 1291 is to derive the expected round trip time based on a 1292 particular retransmission algorithm and on the number 1293 of timeouts which have occured. The type of message may 1294 also be considered when deriving expected round trip 1295 times for retransmissions. For example, if a message is 1296 being sent with an LoS that indicates both 1297 authentication and privacy, the derived value may be 1298 increased to compensate for extra processing time spent 1299 during authentication and encryption processing." 1300 DEFVAL { 1500 } 1301 ::= { snmpTargetAddrEntry 4 } 1302 snmpTargetAddrStorageType OBJECT-TYPE 1303 SYNTAX StorageType 1304 MAX-ACCESS read-create 1305 STATUS current 1306 DESCRIPTION 1307 "" 1308 ::= { snmpTargetAddrEntry 5 } 1310 snmpTargetAddrRowStatus OBJECT-TYPE 1311 SYNTAX RowStatus 1312 MAX-ACCESS read-create 1313 STATUS current 1314 DESCRIPTION 1315 "" 1316 ::= { snmpTargetAddrEntry 6 } 1318 snmpTargetTable OBJECT-TYPE 1319 SYNTAX SEQUENCE OF SnmpV3TargetEntry 1320 MAX-ACCESS not-accessible 1321 STATUS current 1322 DESCRIPTION 1323 "" 1324 ::= { snmpTargetObjects 3 } 1326 snmpTargetEntry OBJECT-TYPE 1327 SYNTAX SnmpV3TargetEntry 1328 MAX-ACCESS not-accessible 1329 STATUS current 1330 DESCRIPTION 1331 "" 1332 INDEX { snmpTargetName } 1333 ::= { snmpTargetTable 1 } 1335 SnmpV3TargetEntry ::= SEQUENCE { 1336 snmpTargetName SnmpAdminString, 1337 snmpTargetAddrName SnmpAdminString, 1338 snmpTargetMessageProcessingModel INTEGER, 1339 snmpTargetSecurityModel SnmpSecurityModel, 1340 snmpTargetSecurityName SnmpAdminString, 1341 snmpTargetLoS SnmpLoS, 1342 snmpTargetRetryCount Integer32, 1343 snmpTargetStorageType StorageType, 1344 snmpTargetRowStatus RowStatus 1345 } 1347 snmpTargetName OBJECT-TYPE 1348 SYNTAX SnmpAdminString 1349 MAX-ACCESS not-accessible 1350 STATUS current 1351 DESCRIPTION 1352 "The locally arbitrary, but unique identifier associated 1353 with this snmpTargetEntry." 1354 ::= { snmpTargetEntry 1 } 1356 snmpTargetAddrName OBJECT-TYPE 1357 SYNTAX SnmpAdminString 1358 MAX-ACCESS read-create 1359 STATUS current 1360 DESCRIPTION 1361 "The group of addresses to which management operations will 1362 be sent when using this set of security parameters." 1363 ::= { snmpTargetEntry 2 } 1365 snmpTargetMessageProcessingModel OBJECT-TYPE 1366 SYNTAX INTEGER (SIZE(0..64)) 1367 MAX-ACCESS read-create 1368 STATUS current 1369 DESCRIPTION 1370 "" 1371 ::= { snmpTargetEntry 3 } 1373 snmpTargetSecurityModel OBJECT-TYPE 1374 SYNTAX SnmpSecurityModel 1375 MAX-ACCESS read-create 1376 STATUS current 1377 DESCRIPTION 1378 "" 1379 ::= { snmpTargetEntry 4 } 1381 snmpTargetSecurityName OBJECT-TYPE 1382 SYNTAX SnmpAdminString 1383 MAX-ACCESS read-create 1384 STATUS current 1385 DESCRIPTION 1386 "" 1387 ::= { snmpTargetEntry 5 } 1389 snmpTargetLoS OBJECT-TYPE 1390 SYNTAX SnmpLoS 1391 MAX-ACCESS read-create 1392 STATUS current 1393 DESCRIPTION 1394 "" 1395 ::= { snmpTargetEntry 6 } 1396 snmpTargetRetryCount OBJECT-TYPE 1397 SYNTAX Integer32 (0..2147483647) 1398 MAX-ACCESS read-create 1399 STATUS current 1400 DESCRIPTION 1401 "This object specifies a default number of retries to be 1402 attempted when a response is not received for a generated 1403 message. The number of retries is an indication of how 1404 important delivery of a particular message is considered. 1405 An application may provide its own retry count, in which 1406 case the value of this object is ignored." 1407 ::= { snmpTargetEntry 7 } 1409 snmpTargetStorageType OBJECT-TYPE 1410 SYNTAX StorageType 1411 MAX-ACCESS read-create 1412 STATUS current 1413 DESCRIPTION 1414 "" 1415 ::= { snmpTargetEntry 8 } 1417 snmpTargetRowStatus OBJECT-TYPE 1418 SYNTAX RowStatus 1419 MAX-ACCESS read-create 1420 STATUS current 1421 DESCRIPTION 1422 "" 1423 ::= { snmpTargetEntry 9 } 1425 snmpTargetDefaultRetryAlgorithm OBJECT-TYPE 1426 SYNTAX INTEGER { 1427 constant(1), 1428 linearBackOff(2), 1429 exponentialBackOff(3), 1430 randomBackOff(4) 1431 } 1432 MAX-ACCESS read-create 1433 STATUS current 1434 DESCRIPTION 1435 "This object specifies a default algorithm to be used 1436 when adjusting timeout times when retransmitting a 1437 request whose response was not received in a timely 1438 manner. An application may provide its own 1439 retransmission algorithm, in which case the value of 1440 this object is ignored. 1442 Can we really predict all the algorithms that people might want to use? 1443 There are alternatives to making this be an enumerated integer. 1445 One alternative is to make it be a set of 6 parameters for a quadratic 1446 equation which would be used to recalculate retry intervals, i.e.,: 1447 interval(n) = ((A1 / A2) * interval(n-1) * interval(n-1)) + 1448 ((B1 / B2) * interval(n-1)) + 1449 (C1 / C2) 1450 The advantage to this is that a manager can define a wide range of 1451 algorithms, and the agent does not need to support a specific set 1452 of algorithms. 1454 Another alternative is to identify retransmission algorithms by OID rather 1455 than by integer. The advantage to using OIDs is that we can define 1456 additional algorithms later. If we do this, we can either make this object 1457 be an OID, or we can have a table that maps the OIDs to integers, and have 1458 the value of this object point at one of the entries in the mapping table. 1459 The advantage to a mapping table is that it allows a manager to discover 1460 what algorithms an agent supports. 1461 " 1462 ::= { snmpTargetObjects 4 } 1464 -- ------------------------------------------------------------------ 1465 -- 1466 -- Conformance information 1467 -- 1468 -- ------------------------------------------------------------------ 1470 snmpTargetCompliances OBJECT IDENTIFIER ::= 1471 { snmpTargetConformance 1 } 1472 snmpTargetGroups OBJECT IDENTIFIER ::= 1473 { snmpTargetConformance 2 } 1475 -- ------------------------------------------------------------------ 1476 -- 1477 -- Compliance statements 1478 -- 1479 -- ------------------------------------------------------------------ 1481 snmpTargetBasicCompliance MODULE-COMPLIANCE 1482 STATUS current 1483 DESCRIPTION 1484 "The compliance statement for SNMP entities which require 1485 remote configuration of management targets." 1486 MODULE -- this module 1487 MANDATORY-GROUPS { snmpTargetBasicGroup } 1488 ::= { snmpTargetCompliances 1 } 1489 snmpTargetFullCompliance MODULE-COMPLIANCE 1490 STATUS current 1491 DESCRIPTION 1492 "The compliance statement for SNMP entities which require 1493 remote configuration of management targets." 1494 MODULE -- this module 1495 MANDATORY-GROUPS { snmpTargetBasicGroup } 1496 ::= { snmpTargetCompliances 2 } 1498 snmpTargetReadCreateCompliance MODULE-COMPLIANCE 1499 STATUS current 1500 DESCRIPTION 1501 "The compliance statement for SNMP entities which require 1502 remote configuration of management targets." 1503 MODULE -- this module 1504 MANDATORY-GROUPS { snmpTargetBasicGroup } 1505 ::= { snmpTargetCompliances 3 } 1507 snmpTargetBasicGroup OBJECT-GROUP 1508 OBJECTS { 1509 snmpTargetAddressSpinLock, 1510 snmpTargetAddrTDomain, 1511 snmpTargetAddrTAddress, 1512 snmpTargetAddrStorageType, 1513 snmpTargetAddrRowStatus, 1514 snmpTargetAddrName, 1515 snmpTargetMessageProcessingModel, 1516 snmpTargetSecurityModel, 1517 snmpTargetSecurityName, 1518 snmpTargetLoS, 1519 snmpTargetStorageType, 1520 snmpTargetRowStatus 1521 } 1522 STATUS current 1523 DESCRIPTION 1524 "A collection of objects providing basic remote 1525 configuration of management targets." 1526 ::= { snmpTargetGroups 1 } 1528 snmpTargetResponseGroup OBJECT-GROUP 1529 OBJECTS { 1530 snmpTargetAddrTimeout, 1531 snmpTargetRetryCount, 1532 snmpTargetDefaultRetryAlgorithm 1533 } 1534 STATUS current 1535 DESCRIPTION 1536 "A collection of objects providing remote configuration 1537 of management targets for applications which generate 1538 Get, GetNext, GetBulk, Set, or Inform requests." 1539 ::= { snmpTargetGroups 2 } 1541 END 1542 5.2. The Notification MIB 1544 This MIB contains three tables. The first table, the 1545 snmpNotifyTargetTable, simply augments the snmpTargetTable with a 1546 single object which is used to determine whether a particular 1547 management target should be used for generating notifications, and 1548 the type of notification to be generated. The second table sparsely 1549 augments the snmpNotifyTargetTable with a single object. This object 1550 is used to associate a set of filters with a particular management 1551 target. The third table defines filters which are used to limit the 1552 number of notifications which are generated using particular 1553 management targets. 1555 5.2.1. Definitions 1557 SNMPV3-NOTIFICATION-MIB DEFINITIONS ::= BEGIN 1559 IMPORTS 1560 MODULE-IDENTITY, 1561 OBJECT-TYPE, 1562 OBJECT-IDENTITY, 1563 Integer32 1564 FROM SNMPv2-SMI 1566 TDomain, 1567 TAddress, 1568 TruthValue, 1569 TimeInterval, 1570 RowStatus, 1571 StorageType 1572 FROM SNMPv2-TC 1574 SnmpSecurityModel, 1575 SnmpLoS, 1576 SnmpAdminString 1577 FROM SNMP-FRAMEWORK-MIB 1579 snmpTargetEntry, 1580 snmpTargetName 1581 FROM SNMPV3-TARGET-MIB 1583 MODULE-COMPLIANCE, 1584 OBJECT-GROUP 1585 FROM SNMPv2-CONF; 1587 snmpNotificationMIB MODULE-IDENTITY 1588 LAST-UPDATED "9707140000Z" 1589 ORGANIZATION "IETF SNMPv3 Working Group" 1590 CONTACT-INFO 1591 "David B. Levi 1592 SNMP Research, Inc. 1593 3001 Kimberlin Heights Road 1594 Knoxville, TN 37920-9716 1595 Tel: +1 423 573 1434 1596 E-mail: levi@snmp.com 1598 Paul Meyer 1599 Secure Computing Corporation 1600 2675 Long Lake Road 1601 Roseville, MN 55113 1602 Tel: +1 612 628 1592 1603 E-mail: paul_meyer@securecomputing.com 1605 Bob Stewart 1606 Cisco Systems 1607 ???? 1608 ???? 1609 Tel: +1 603 654 6923 1610 E-mail: bstewart@cisco.com" 1611 DESCRIPTION 1612 "This MIB module defines a MIB which provides mechanisms 1613 to remotely configure management targets used by an 1614 SNMPv3 entity." 1615 REVISION "9707140000Z" 1616 DESCRIPTION 1617 "The initial revision." 1618 ::= { snmpModules 12 } -- TBD 1620 snmpNotifyObjects OBJECT IDENTIFIER ::= 1621 { snmpNotificationMIB 1 } 1622 snmpNotifyConformance OBJECT IDENTIFIER ::= 1623 { snmpNotificationMIB 2 } 1625 -- ------------------------------------------------------------------ 1626 -- 1627 -- The snmpNotifyObjects group 1628 -- 1629 -- ------------------------------------------------------------------ 1631 snmpNotifyTargetTable OBJECT-TYPE 1632 SYNTAX SEQUENCE OF SnmpV3NotifyTargetEntry 1633 MAX-ACCESS not-accessible 1634 STATUS current 1635 DESCRIPTION 1636 "This table is used to select management targets which should 1637 receive notifications, as well as the type of notification 1638 which should be sent to each selected management target." 1639 ::= { snmpNotifyObjects 1 } 1641 snmpNotifyTargetEntry OBJECT-TYPE 1642 SYNTAX SnmpV3NotifyTargetEntry 1643 MAX-ACCESS not-accessible 1644 STATUS current 1645 DESCRIPTION 1646 "" 1647 AUGMENTS { snmpTargetEntry } 1648 ::= { snmpNotifyTargetTable 1 } 1650 SnmpV3NotifyTargetEntry ::= SEQUENCE { 1651 snmpNotifyTargetType INTEGER 1652 } 1654 snmpNotifyTargetType OBJECT-TYPE 1655 SYNTAX INTEGER { 1656 trap(1), 1657 inform(2), 1658 nothing(3) 1659 } 1660 MAX-ACCESS read-create 1661 STATUS current 1662 DESCRIPTION 1663 "This object determines whether a particular entry in 1664 the snmpTargetTable should be used for generating 1665 notifications, and the type of notification to be 1666 generated. If the value of this object is trap(1), 1667 then the entry will be used to generate messages 1668 containing SNMPv2-Trap PDUs. If the value is 1669 inform(2), then the entry will be used to generate 1670 messages containing Inform PDUs. If the value is 1671 nothing(3), then the entry is not used to generate 1672 notifications. 1674 Note that the default value for this object is 1675 nothing(3). This ensures that if an entry is created 1676 for a purpose other than notification generation, 1677 whoever creates the row need not do anything special 1678 to prevent the use of the entry when generating 1679 notifications. 1681 Also note that if an SNMP entity only supports 1682 generation of traps (and not informs), then this 1683 object need not be supported, and its value is 1684 assumed to be trap(1)." 1685 DEFVAL { nothing } 1686 ::= { snmpNotifyTargetEntry 1 } 1688 snmpNotifyFilterProfileTable OBJECT-TYPE 1689 SYNTAX SEQUENCE OF SnmpV3NotifyFilterProfileEntry 1690 MAX-ACCESS not-accessible 1691 STATUS current 1692 DESCRIPTION 1693 "This table is used to select management targets which 1694 should receive notifications, as well as the type of 1695 notification which should be sent to each selected 1696 management target." 1697 ::= { snmpNotifyObjects 2 } 1699 snmpNotifyFilterProfileEntry OBJECT-TYPE 1700 SYNTAX SnmpV3NotifyFilterProfileEntry 1701 MAX-ACCESS not-accessible 1702 STATUS current 1703 DESCRIPTION 1704 "" 1705 INDEX { snmpTargetName } 1706 ::= { snmpNotifyFilterProfileTable 1 } 1708 SnmpV3NotifyFilterProfileEntry ::= SEQUENCE { 1709 snmpNotifyFilterProfileName SnmpAdminString 1710 } 1712 snmpNotifyFilterProfileName OBJECT-TYPE 1713 SYNTAX SnmpAdminString 1714 MAX-ACCESS read-create 1715 STATUS current 1716 DESCRIPTION 1717 "" 1718 ::= { snmpNotifyFilterProfileEntry 1 } 1720 snmpNotifyFilterTable OBJECT-TYPE 1721 SYNTAX SEQUENCE OF SnmpV3NotifyFilterEntry 1722 MAX-ACCESS not-accessible 1723 STATUS current 1724 DESCRIPTION 1725 "This table is used to select management targets which 1726 should receive notifications." 1727 ::= { snmpNotifyObjects 3 } 1728 snmpNotifyFilterEntry OBJECT-TYPE 1729 SYNTAX SnmpV3NotifyFilterEntry 1730 MAX-ACCESS not-accessible 1731 STATUS current 1732 DESCRIPTION 1733 "" 1734 INDEX { snmpNotifyFilterProfileName, 1735 IMPLIED snmpNotifyFilterSubtree } 1736 ::= { snmpNotifyFilterTable 1 } 1738 SnmpV3NotifyFilterEntry ::= SEQUENCE { 1739 snmpNotifyFilterSubtree OBJECT IDENTIFIER, 1740 snmpNotifyFilterMask OCTET STRING, 1741 snmpNotifyFilterType INTEGER, 1742 snmpNotifyFilterStorageType StorageType, 1743 snmpNotifyFilterRowStatus RowStatus 1744 } 1746 snmpNotifyFilterSubtree OBJECT-TYPE 1747 SYNTAX OBJECT IDENTIFIER 1748 MAX-ACCESS not-accessible 1749 STATUS current 1750 DESCRIPTION 1751 "" 1752 ::= { snmpNotifyFilterEntry 1 } 1754 snmpNotifyFilterMask OBJECT-TYPE 1755 SYNTAX OCTET STRING (SIZE(0..16)) 1756 MAX-ACCESS read-create 1757 STATUS current 1758 DESCRIPTION 1759 "" 1760 ::= { snmpNotifyFilterEntry 2 } 1762 snmpNotifyFilterType OBJECT-TYPE 1763 SYNTAX INTEGER { 1764 included(1), 1765 excluded(2) 1766 } 1767 MAX-ACCESS read-create 1768 STATUS current 1769 DESCRIPTION 1770 "" 1771 ::= { snmpNotifyFilterEntry 3 } 1773 snmpNotifyFilterStorageType OBJECT-TYPE 1774 SYNTAX StorageType 1775 MAX-ACCESS read-create 1776 STATUS current 1777 DESCRIPTION 1778 "" 1779 ::= { snmpNotifyFilterEntry 4 } 1781 snmpNotifyFilterRowStatus OBJECT-TYPE 1782 SYNTAX RowStatus 1783 MAX-ACCESS read-create 1784 STATUS current 1785 DESCRIPTION 1786 "" 1787 ::= { snmpNotifyFilterEntry 5 } 1789 -- ------------------------------------------------------------------ 1790 -- 1791 -- Conformance information 1792 -- 1793 -- ------------------------------------------------------------------ 1795 snmpNotifyCompliances OBJECT IDENTIFIER ::= 1796 { snmpNotifyConformance 1 } 1797 snmpNotifyGroups OBJECT IDENTIFIER ::= 1798 { snmpNotifyConformance 2 } 1800 -- ------------------------------------------------------------------ 1801 -- 1802 -- Compliance statements 1803 -- 1804 -- ------------------------------------------------------------------ 1806 snmpNotifyMinimalCompliance MODULE-COMPLIANCE 1807 STATUS current 1808 DESCRIPTION 1809 "The compliance statement for minimal SNMP entities which 1810 implement only SNMP Traps and read-create operations on 1811 only the snmpTargetAddrTable." 1812 MODULE SNMPV3-TARGET-MIB 1813 MANDATORY-GROUPS { snmpTargetBasicGroup } 1815 OBJECT snmpTargetAddrName 1816 MIN-ACCESS read-only 1817 DESCRIPTION 1818 "Read-write and read-create access are not required." 1820 OBJECT snmpTargetMessageProcessingModel 1821 MIN-ACCESS read-only 1822 DESCRIPTION 1823 "Read-write and read-create access are not required." 1825 OBJECT snmpTargetSecurityModel 1826 MIN-ACCESS read-only 1827 DESCRIPTION 1828 "Read-write and read-create access are not required." 1830 OBJECT snmpTargetSecurityName 1831 MIN-ACCESS read-only 1832 DESCRIPTION 1833 "Read-write and read-create access are not required." 1835 OBJECT snmpTargetLoS 1836 MIN-ACCESS read-only 1837 DESCRIPTION 1838 "Read-write and read-create access are not required." 1840 OBJECT snmpTargetStorageType 1841 SYNTAX INTEGER { 1842 readOnly(5) 1843 } 1844 MIN-ACCESS read-only 1845 DESCRIPTION 1846 "Read-write and read-create access are not required. 1847 Support of the values other(1), volatile(2), 1848 nonVolatile(3), and permanent(4) is not required." 1850 OBJECT snmpTargetRowStatus 1851 SYNTAX INTEGER { 1852 active(1) 1853 } 1854 MIN-ACCESS read-only 1855 DESCRIPTION 1856 "Read-write and read-create access are not required. 1857 Support of the values notInService(2), notReady(3), 1858 createAndGo(4), createAndWait(5), and destroy(6) is 1859 not required." 1861 ::= { snmpNotifyCompliances 1 } 1863 snmpNotifyBasicCompliance MODULE-COMPLIANCE 1864 STATUS current 1865 DESCRIPTION 1866 "The compliance statement for SNMP entities which implement 1867 SNMP Traps with filtering, and read-create operations on 1868 all related tables." 1869 MODULE SNMPV3-TARGET-MIB 1870 MANDATORY-GROUPS { snmpTargetBasicGroup } 1871 MODULE -- This Module 1872 MANDATORY-GROUPS { snmpNotifyFilterGroup } 1873 ::= { snmpNotifyCompliances 2 } 1875 snmpNotifyCompleteCompliance MODULE-COMPLIANCE 1876 STATUS current 1877 DESCRIPTION 1878 "The compliance statement for SNMP entities which either 1879 implement only SNMP Informs, or both SNMP Traps and SNMP 1880 Informs, plus filtering and read-create operations on 1881 all related tables." 1882 MODULE SNMPV3-TARGET-MIB 1883 MANDATORY-GROUPS { snmpTargetBasicGroup, 1884 snmpTargetResponseGroup } 1885 MODULE -- This Module 1886 MANDATORY-GROUPS { snmpNotifyTypeGroup, 1887 snmpNotifyFilterGroup } 1888 ::= { snmpNotifyCompliances 3 } 1890 snmpNotifyTypeGroup OBJECT-GROUP 1891 OBJECTS { 1892 snmpNotifyTargetType 1893 } 1894 STATUS current 1895 DESCRIPTION 1896 "An object for selecting which management targets are used 1897 for generating notifications, and the type of notification 1898 to be generated for each selected management target." 1899 ::= { snmpNotifyGroups 1 } 1901 snmpNotifyFilterGroup OBJECT-GROUP 1902 OBJECTS { 1903 snmpNotifyFilterProfileName, 1904 snmpNotifyFilterMask, 1905 snmpNotifyFilterType, 1906 snmpNotifyFilterStorageType, 1907 snmpNotifyFilterRowStatus 1908 } 1909 STATUS current 1910 DESCRIPTION 1911 "A collection of objects providing remote configuration of 1912 management targets, including row creation in the 1913 snmpTargetTable." 1914 ::= { snmpNotifyGroups 3 } 1915 END 1916 5.3. The Proxy MIB 1918 The MIB contains a single scalar and a single table. The scalar 1919 object, snmpProxyNextIndex, is used by managers when creating new 1920 entries in the table. The table, snmpProxyTable, is used to define 1921 translations between management targets for use when forwarding 1922 messages. 1924 5.3.1. Definitions 1926 SNMPV3-PROXY-MIB DEFINITIONS ::= BEGIN 1928 IMPORTS 1929 MODULE-IDENTITY, 1930 OBJECT-TYPE, 1931 OBJECT-IDENTITY, 1932 Integer32 1933 FROM SNMPv2-SMI 1935 TDomain, 1936 TAddress, 1937 TruthValue, 1938 TimeInterval, 1939 RowStatus, 1940 StorageType 1941 FROM SNMPv2-TC 1943 SnmpEngineID, 1944 SnmpSecurityModel, 1945 SnmpLoS, 1946 SnmpAdminString 1947 FROM SNMP-FRAMEWORK-MIB 1949 MODULE-COMPLIANCE, 1950 OBJECT-GROUP 1951 FROM SNMPv2-CONF; 1953 snmpProxyMIB MODULE-IDENTITY 1954 LAST-UPDATED "9706140000Z" 1955 ORGANIZATION "IETF SNMPv3 Working Group" 1956 CONTACT-INFO 1957 "David B. Levi 1958 SNMP Research, Inc. 1959 3001 Kimberlin Heights Road 1960 Knoxville, TN 37920-9716 1961 Tel: +1 423 573 1434 1962 E-mail: levi@snmp.com 1964 Paul Meyer 1965 Secure Computing Corporation 1966 2675 Long Lake Road 1967 Roseville, MN 55113 1968 Tel: +1 612 628 1592 1969 E-mail: paul_meyer@securecomputing.com 1971 Bob Stewart 1972 Cisco Systems 1973 ???? 1974 ???? 1975 Tel: +1 603 654 6923 1976 E-mail: bstewart@cisco.com" 1977 DESCRIPTION 1978 "This MIB module defines a MIB which provides mechanisms to 1979 remotely configure the parameters used by an SNMPv3 entity 1980 for the generation of notifications." 1981 REVISION "9707140000Z" 1982 DESCRIPTION 1983 "The initial revision." 1984 ::= { snmpModules 13 } -- TBD 1986 snmpProxyObjects OBJECT IDENTIFIER ::= { snmpProxyMIB 1 } 1987 snmpProxyConformance OBJECT IDENTIFIER ::= { snmpProxyMIB 2 } 1989 -- ------------------------------------------------------------------ 1990 -- 1991 -- The snmpProxyObjects group 1992 -- 1993 -- ------------------------------------------------------------------ 1995 snmpProxyNextIndex OBJECT-TYPE 1996 SYNTAX Integer32 (1..2147483647) 1997 MAX-ACCESS read-write 1998 STATUS current 1999 DESCRIPTION 2000 "This object is used to facilitate creation of rows in the 2001 snmpProxyTable. Its value when read is equal to an unused 2002 value of snmpProxyIndex. When a manager wishes to create 2003 a row in the snmpProxyTable, it should first retrieve the 2004 value of this object, and then set the instance of 2005 snmpProxyRowStatus whose snmpProxyIndex value is 2006 equal to the retrieved value to either createAndWait or 2007 createAndGo." 2008 ::= { snmpProxyObjects 1 } 2009 snmpProxyTable OBJECT-TYPE 2010 SYNTAX SEQUENCE OF SnmpV3ProxyEntry 2011 MAX-ACCESS not-accessible 2012 STATUS current 2013 DESCRIPTION 2014 "" 2015 ::= { snmpProxyObjects 2 } 2017 snmpProxyEntry OBJECT-TYPE 2018 SYNTAX SnmpV3ProxyEntry 2019 MAX-ACCESS not-accessible 2020 STATUS current 2021 DESCRIPTION 2022 "" 2023 INDEX { snmpProxyIndex } 2024 ::= { snmpProxyTable 1 } 2026 SnmpV3ProxyEntry ::= SEQUENCE { 2027 snmpProxyIndex Integer32, 2028 snmpProxyType INTEGER, 2029 snmpProxyContextEngineID SnmpEngineID, 2030 snmpProxyContextName SnmpAdminString, 2031 snmpProxyTargetIn Integer32, 2032 snmpProxyTargetOut Integer32, 2033 snmpProxyStorageType StorageType, 2034 snmpProxyRowStatus RowStatus 2035 } 2037 snmpProxyIndex OBJECT-TYPE 2038 SYNTAX Integer32 (1..2147483647) 2039 MAX-ACCESS not-accessible 2040 STATUS current 2041 DESCRIPTION 2042 "The locally arbitrary, but unique identifier associated 2043 with this snmpProxyEntry." 2044 ::= { snmpProxyEntry 1 } 2046 snmpProxyType OBJECT-TYPE 2047 SYNTAX INTEGER { 2048 read(1), 2049 write(2), 2050 trap(3), 2051 inform(4) 2052 } 2053 MAX-ACCESS not-accessible 2054 STATUS current 2055 DESCRIPTION 2056 "" 2057 ::= { snmpProxyEntry 2 } 2059 snmpProxyContextEngineID OBJECT-TYPE 2060 SYNTAX SnmpEngineID 2061 MAX-ACCESS read-create 2062 STATUS current 2063 DESCRIPTION 2064 "" 2065 ::= { snmpProxyEntry 3 } 2067 snmpProxyContextName OBJECT-TYPE 2068 SYNTAX SnmpAdminString 2069 MAX-ACCESS read-create 2070 STATUS current 2071 DESCRIPTION 2072 "" 2073 ::= { snmpProxyEntry 4 } 2075 snmpProxyTargetIn OBJECT-TYPE 2076 SYNTAX Integer32 2077 MAX-ACCESS read-create 2078 STATUS current 2079 DESCRIPTION 2080 "This object selects a set of management targets defined 2081 in the snmpTargetTable (in the SNMPV3-TARGET-MIB)." 2082 ::= { snmpProxyEntry 5 } 2084 snmpProxyTargetOut OBJECT-TYPE 2085 SYNTAX Integer32 2086 MAX-ACCESS read-create 2087 STATUS current 2088 DESCRIPTION 2089 "This object selects a management target defined in the 2090 snmpTargetTable (in the SNMPV3-TARGET-MIB). Only the 2091 first transport address/domain as selected by the 2092 snmpTargetAddrName object is identified by 2093 snmpProxyTargetOut (i.e. the lexicographically smallest 2094 instance in the snmpTargetAddrTable whose 2095 snmpTargetAddrName is equal to the snmpTargetAddrName 2096 object is used for proxy forwarding)." 2097 ::= { snmpProxyEntry 6 } 2099 snmpProxyStorageType OBJECT-TYPE 2100 SYNTAX StorageType 2101 MAX-ACCESS read-create 2102 STATUS current 2103 DESCRIPTION 2104 "" 2105 ::= { snmpProxyEntry 7 } 2107 snmpProxyRowStatus OBJECT-TYPE 2108 SYNTAX RowStatus 2109 MAX-ACCESS read-create 2110 STATUS current 2111 DESCRIPTION 2112 "" 2113 ::= { snmpProxyEntry 8 } 2115 -- ------------------------------------------------------------------ 2116 -- 2117 -- Conformance information 2118 -- 2119 -- ------------------------------------------------------------------ 2121 snmpProxyCompliances OBJECT IDENTIFIER ::= 2122 { snmpProxyConformance 1 } 2123 snmpProxyGroups OBJECT IDENTIFIER ::= 2124 { snmpProxyConformance 2 } 2126 -- ------------------------------------------------------------------ 2127 -- 2128 -- Compliance statements 2129 -- 2130 -- ------------------------------------------------------------------ 2132 snmpProxyCompliance MODULE-COMPLIANCE 2133 STATUS current 2134 DESCRIPTION 2135 "The compliance statement for SNMP entities which include 2136 a proxy forwarding application." 2137 MODULE SNMPV3-TARGET-MIB 2138 MANDATORY-GROUPS { snmpTargetBasicGroup, 2139 snmpTargetResponseGroup } 2140 MODULE -- This Module 2141 MANDATORY-GROUPS { snmpProxyGroup } 2142 ::= { snmpProxyCompliances 1 } 2144 snmpProxyGroup OBJECT-GROUP 2145 OBJECTS { 2146 snmpProxyNextIndex, 2147 snmpProxyType, 2148 snmpProxyContextEngineID, 2149 snmpProxyContextName, 2150 snmpProxyTargetIn, 2151 snmpProxyTargetOut, 2152 snmpProxyStorageType, 2153 snmpProxyRowStatus 2154 } 2155 STATUS current 2156 DESCRIPTION 2157 "A collection of objects providing remote configuration of 2158 management targets, including row creation in the 2159 snmpTargetTable." 2160 ::= { snmpProxyGroups 3 } 2162 END 2163 6. Identification of Management Targets in Notification Originators 2165 This section describes the mechanisms used by a notification 2166 originator application when using the MIB described in this document 2167 to determine the set of management targets to be used when generating 2168 a notification. 2170 A notification originator uses the snmpTargetTable to find the groups 2171 of management targets to be used for generating notifications. Each 2172 active entry in this table, for which the corresponding value of 2173 snmpNotifyTargetType is trap(1) or inform(2), identifies a group of 2174 management targets to be used for notification generation. Note that 2175 if an SNMP Entity's only use of the snmpTargetTable is for generation 2176 of messages containing SNMPv2-Trap PDUs, the snmpNotifyTargetType 2177 object is not required to be implemented. In this case, the value of 2178 snmpNotifyTargetType is always assumed to be trap(1). 2180 Each such entry contains a pointer to the snmpTargetAddrTable 2181 (snmpTargetAddrName). This pointer identifies zero or more transport 2182 endpoints, defined in the snmpTargetAddrTable. If there are zero 2183 transport endpoints identified, the group of management targets is 2184 empty, and should be ignored. Otherwise, each transport endpoint, 2185 paired with the SNMP information from the snmpTargetTable, identifies 2186 a single management target within the group. 2188 The decision as to whether a notification should contain an SNMPv2- 2189 Trap or Inform PDU is determined by the value of the 2190 snmpNotifyTargetType object. If the value of this object is trap(1), 2191 the notification should contain an SNMPv2-Trap PDU. If the value of 2192 this object is inform(2), then the notification should contain an 2193 Inform PDU, and the number of retries for the Inform is the value of 2194 snmpTargetRetryCount. Note that the exception to these rules is when 2195 the snmpTargetMessageProcessingModel object indicates SNMPv1. In 2196 this case, the notification is sent as a Trap if the value of 2197 snmpNotifyTargetType is either trap(1) or inform(2). 2199 7. Notification Filtering 2201 This section describes the mechanisms used by a notification 2202 originator application when using the MIB described in this document 2203 to filter generation of notifications. 2205 A notification originator uses the snmpNotifyFilterTable to filter 2206 notifications. When generating notifications for a group of 2207 management targets, all active entries in the snmpNotifyFilterTable, 2208 for which the value of the snmpNotifyFilterProfileName index is equal 2209 to the value of the snmpNotifyFilterProfileName object of the 2210 management target group, are used for filtering the notification. If 2211 no such entries exist, no filtering is performed, and the 2212 notification may be sent to all management targets in the group. 2214 Otherwise, if matching entries do exist, the notification may be sent 2215 if the NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (this 2216 is the value of the element of the variable bindings whose name is 2217 snmpTrapOID.0, i.e. the second variable binding), and all of the 2218 object instances to be included in the variable-bindings of the 2219 notification, are not specifically excluded by the matching entries. 2221 Each set of snmpNotifyFilterTable entries is divided into two 2222 collections of filter subtrees: the included filter subtrees, and 2223 the excluded filter subtrees. The snmpNotifyFilterType object 2224 defines the collection to which each matching entry belongs. 2226 To determine whether a particular object instance is excluded by the 2227 set of matching entries, compare the object instance's OBJECT 2228 IDENTIFIER with each of the matching entries. If none match, then 2229 the object instance is considered excluded, and the notification 2230 should not be sent to this group of management targets. If one or 2231 more match, then the object instance is included or excluded, 2232 according to the value of snmpNotifyFilterType in the entry whose 2233 value of snmpNotifyFilterSubtree has the most sub-identifiers. If 2234 multiple entries match and have the same number of sub-identifiers, 2235 then the lexicographically greatest instance of snmpNotifyFilterType 2236 among those which match determines the inclusion or exclusion. 2238 An object instance's OBJECT IDENTIFIER X matches an entry in the 2239 snmpNotifyFilterTable when the number of sub-identifiers in X is at 2240 least as many as in the value of snmpNotifyFilterSubtree for the 2241 entry, and each sub-identifier in the value of 2242 snmpNotifyFilterSubtree matches its corresponding sub-identifier in 2243 X. Two sub-identifiers match either if the corresponding bit of 2244 snmpNotifyFilterMask is zero (the 'wild card' value), or if the two 2245 sub-identifiers are equal. 2247 8. Management Target Translation in Proxy Forwarder Applications 2249 This section describes the mechanisms used by a proxy forwarder 2250 application when using the MIB described in this document to 2251 translate incoming management target information into outgoing 2252 management target information for the purpose of forwarding messages. 2253 There are actually two mechanisms a proxy forwarder may use, one for 2254 forwarding request messages, and one for forwarding notification 2255 messages. 2257 8.1. Management Target Translation for Request Forwarding 2259 When forwarding request messages, the proxy forwarder will select a 2260 single entry in the snmpProxyTable. To select this entry, it will 2261 perform the following comparisons: 2263 - The snmpProxyType must be read(1) if the request is a Get, 2264 GetNext, or GetBulk request. The snmpProxyType must be 2265 write(2) if the request is a Set request. 2267 - The contextEngineId and contextName must equal the 2268 snmpProxyContextEngineID and snmpProxyContextName objects. 2270 - The snmpProxyTargetIn object identifies an entry in the 2271 snmpTargetTable. The snmp version, LoS, security model, and 2272 securityName must match the values of 2273 snmpTargetMessageProcessingModel, snmpTargetSecurityModel, 2274 snmpTargetSecurityName, and snmpTargetLoS of the identified 2275 entry in the snmpTargetTable. 2277 - The identified entry in the snmpTargetTable contains a pointer 2278 to the snmpTargetAddrTable. This pointer refers to zero or 2279 more entries in the snmpTargetAddrTable. If there are no such 2280 entries, this comparison need not succeed. If there is at 2281 least one such entry, the transport domain and address from 2282 which the request was received must match the 2283 snmpTargetAddrTDomain and snmpTargetAddrTAddress values of at 2284 least one of these entries. 2286 There may be multiple entries in the snmpProxyTable for which these 2287 comparisons succeed. The entry whose snmpProxyIndex has the smallest 2288 value and for which the comparisons succeed will be selected by the 2289 proxy forwarder. 2291 The outgoing management information is identified by the value of the 2292 snmpProxyTargetOut object of the selected entry. This object 2293 identifies an entry in the snmpTargetTable. The 2294 snmpTargetMessageProcessingModel, snmpTargetSecurityModel, 2295 snmpTargetSecurityName, and snmpTargetLoS of this entry are used as 2296 one part of the management target. The other part of the management 2297 target is a transport endpoint, which is identified by the value of 2298 the snmpTargetAddrName member of the snmpTargetTable entry. This 2299 value may identify zero or more entries in the snmpTargetAddrTable. 2300 If there are no entries identified, the selected snmpProxyTable entry 2301 is invalid, and the proxy forwarder should look for another 2302 snmpProxyTable entry to use. Otherwise, the snmpTargetAddrTable 2303 entry with the smallest value of snmpTargetAddrSubIndex is used as 2304 the transport endpoint. 2306 8.2. Management Target Translation for Notification Forwarding 2308 When forwarding notification messages, the proxy forwarder will 2309 select multiple entries in the snmpProxyTable. To select these 2310 entries, it will perform the following comparisons: 2312 - The snmpProxyType must be trap(3) if the notification is a 2313 Trap. The snmpProxyType must be inform(4) if the request is 2314 an Inform. 2316 - The contextEngineId and contextName must equal the 2317 snmpProxyContextEngineID and snmpProxyContextName objects. 2319 - The snmpProxyTargetIn object identifies an entry in the 2320 snmpTargetTable. The snmp version, LoS, security model, and 2321 securityName must match the values of 2322 snmpTargetMessageProcessingModel, snmpTargetSecurityModel, 2323 snmpTargetSecurityName, and snmpTargetLoS of the identified 2324 entry in the snmpTargetTable. 2326 - The identified entry in the snmpTargetTable contains a pointer 2327 to the snmpTargetAddrTable. This pointer refers to zero or 2328 more entries in the snmpTargetAddrTable. If there are no such 2329 entries, this comparison need not succeed. If there is at 2330 least one such entry, the transport domain and address from 2331 which the request was received must match the 2332 snmpTargetAddrTDomain and snmpTargetAddrTAddress values of at 2333 least one of these entries. 2335 All entries for which these comparisons succeed are selected. The 2336 set of outgoing management targets to be used for generating 2337 forwarded notifications is identified by the value of the 2338 snmpProxyTargetOut object of all selected entries. These values 2339 identify entries in the snmpTargetTable. All such entries are used 2340 for generating forwarded notifications. The snmpTargetNotification 2341 object is ignored when generating forwarded notifications in a proxy 2342 forwarder application. 2344 9. Security Considerations 2346 Should have some discussion about notification generation 2347 applications which provide variable bindings when generating a 2348 notification, rather than omitting them and letting the engine get 2349 them from the LPM. Applications that do this should be careful not 2350 to disclose anything that they shouldn't. 2352 10. Acknowledgments 2354 This document was produced by the IETF SNMPv3 working group. 2356 11. References 2358 [RFC1157] 2359 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2360 Management Protocol", RFC 1157, SNMP Research, Performance Systems 2361 International, Performance Systems International, MIT Laboratory 2362 for Computer Science, May 1990. 2364 [RFC1213] 2365 McCloghrie, K., and M. Rose, Editors, "Management Information Base 2366 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 2367 RFC 1213, Hughes LAN Systems, Performance Systems International, 2368 March 1991. 2370 [RFC1902] 2371 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2372 Waldbusser, "Structure of Management Information for Version 2 of 2373 the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP 2374 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2375 International Network Services, January 1996. 2377 [RFC1903] 2378 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2379 Waldbusser, "Textual Conventions for Version 2 of the Simple 2380 Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., 2381 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 2382 Network Services, January 1996. 2384 [RFC1905] 2385 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2386 Waldbusser, "Protocol Operations for Version 2 of the Simple 2387 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 2388 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 2389 Network Services, January 1996. 2391 [RFC1907] 2392 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2393 Waldbusser, "Management Information Base for Version 2 of the 2394 Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP 2395 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2396 International Network Services, January 1996. 2398 [RFC1908] 2399 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2400 Waldbusser, "Coexistence between Version 1 and Version 2 of the 2401 Internet-standard Network Management Framework", RFC1905, SNMP 2402 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2403 International Network Services, January 1996. 2405 [SNMPV3-ARCH] 2406 SNMPv3 Working Group, Harrington, D., Wijnen, B., "An Architecture 2407 for Describing Internet Management Frameworks", draft-ietf-snmpv3- 2408 next-gen-arch-02.txt, June 1997. 2410 [SNMPV3-MPC] 2411 SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., 2412 "Message Processing and Control Model for version 3 of the Simple 2413 Network Management Protocol (SNMPv3)", draft-ietf-snmpv3-next-gen- 2414 arch-02.txt, June 1997. 2416 [SNMPV3-ACM] 2417 SNMPv3 Working Group, Wijnen, B., Presuhn, R., McClogrie, K., 2418 "Access Control Model for version 3 of the Simple Network 2419 Management Protocol (SNMPv3)", draft-ietf-snmpv3-next-gen-arch- 2420 02.txt, June 1997. 2422 12. Author's Address 2424 David B. Levi 2425 SNMP Research, Inc. 2426 3001 Kimberlin Heights Road 2427 Knoxville, TN 37920-9716 2428 U.S.A. 2429 Phone: +1 423 573 1434 2430 EMail: levi@snmp.com 2432 Paul Meyer 2433 Secure Computing Corporation 2434 2675 Long Lake Road 2435 Roseville, MN 55113 2436 U.S.A. 2437 Phone: +1 612 628 1592 2438 EMail: paul_meyer@securecomputing.com 2440 Bob Stewart 2441 Cisco Systems 2442 ???? 2443 ???? 2444 U.S.A. 2445 Phone: +1 603 654 6923 2446 EMail: bstewart@cisco.com 2447 APPENDIX A - Trap Configuration Example 2449 This section describes an example configuration for a Notification 2450 Generator application which implements the 2451 snmpNotifyMinimalCompliance level. The example configuration 2452 specifies that the Notification Generator should send notifications 2453 to 3 separate managers, using authentication and no privacy for the 2454 first 2 managers, and using both authentication and privacy for the 2455 third manager. 2457 The configuration consists of three rows in the snmpTargetAddrTable, 2458 and two rows in the snmpTargetTable. 2460 * snmpTargetAddrName = "AuthNoPrivTargetAddresses" 2461 * snmpTargetAddrSubIndex = 1 2462 snmpTargetAddrTDomain = snmpUDPDomain 2463 snmpTargetAddrTAddress = 128.1.2.3:162 2464 snmpTargetAddrStorageType = readOnly(5) 2465 snmpTargetAddrRowStatus = active(1) 2467 * snmpTargetAddrName = "AuthNoPrivTargetAddresses" 2468 * snmpTargetAddrSubIndex = 2 2469 snmpTargetAddrTDomain = snmpUDPDomain 2470 snmpTargetAddrTAddress = 128.2.4.6:162 2471 snmpTargetAddrStorageType = readOnly(5) 2472 snmpTargetAddrRowStatus = active(1) 2474 * snmpTargetAddrName = "AuthPrivTargetAddresses" 2475 * snmpTargetAddrSubIndex = 1 2476 snmpTargetAddrTDomain = snmpUDPDomain 2477 snmpTargetAddrTAddress = 128.1.5.9:162 2478 snmpTargetAddrStorageType = readOnly(5) 2479 snmpTargetAddrRowStatus = active(1) 2481 * snmpTargetName = "AuthNoPrivTarget" 2482 snmpTargetAddrName = "AuthNoPrivTargetAddresses" 2483 snmpTargetMessageProcessingModel = 3 2484 snmpTargetSecurityModel = 3 (USM) 2485 snmpTargetSecurityName = "joe" 2486 snmpTargetLoS = auth(2) 2487 snmpTargetStorageType = readOnly(5) 2488 snmpTargetRowStatus = active(1) 2490 * snmpTargetName = "AuthPrivTarget" 2491 snmpTargetAddrName = "AuthPrivTargetAddresses" 2492 snmpTargetMessageProcessingModel = 3 2493 snmpTargetSecurityModel = 3 (USM) 2494 snmpTargetSecurityName = "bob" 2495 snmpTargetLoS = priv(3) 2496 snmpTargetStorageType = readOnly(5) 2497 snmpTargetRowStatus = active(1) 2499 These entries define two separate management target groups. The 2500 first group contains two management targets: 2502 first target second target 2503 ------------ ------------- 2504 snmpVersion SNMPv3 SNMPv3 2505 securityModel 3 (USM) 3 (USM) 2506 securityName "joe" "joe" 2507 LoS auth(2) auth(2) 2508 transportDomain snmpUDPDomain snmpUDPDomain 2509 transportAddress 128.1.2.3:162 128.2.4.6:162 2511 And the second group contains a single management target: 2513 snmpVersion SNMPv3 2514 LoS priv(3) 2515 securityModel 3 (USM) 2516 securityName "bob" 2517 transportDomain snmpUDPDomain 2518 transportAddress 128.1.5.9:162 2519 Table of Contents 2521 1 Abstract ..................................................... 2 2522 2 Overview ..................................................... 3 2523 2.1 Command Generators ......................................... 3 2524 2.2 Command Responders ......................................... 3 2525 2.3 Notification Originators ................................... 4 2526 2.4 Notification Receivers ..................................... 4 2527 2.5 Proxy Forwarder ............................................ 4 2528 3 Management Targets ........................................... 5 2529 4 Elements Of Procedure ........................................ 6 2530 4.1 Command Generators ......................................... 7 2531 4.2 Command Responders ......................................... 9 2532 4.3 Notification Originators ................................... 14 2533 4.4 Notification Receivers ..................................... 17 2534 4.5 Proxy Forwarders ........................................... 19 2535 4.5.1 Request Forwarding ....................................... 19 2536 4.5.1.1 Processing an Incoming Request ......................... 19 2537 4.5.1.2 Processing an Incoming Response ........................ 22 2538 4.5.2 Notification Forwarding .................................. 23 2539 5 The Structure of the MIBs .................................... 26 2540 5.1 The Management Target MIB .................................. 26 2541 5.1.1 Definitions .............................................. 26 2542 5.2 The Notification MIB ....................................... 37 2543 5.2.1 Definitions .............................................. 37 2544 5.3 The Proxy MIB .............................................. 46 2545 5.3.1 Definitions .............................................. 46 2546 6 Identification of Management Targets in Notification Origi- 2547 nators .................................................... 52 2548 7 Notification Filtering ....................................... 53 2549 8 Management Target Translation in Proxy Forwarder Applica- 2550 tions ..................................................... 54 2551 8.1 Management Target Translation for Request Forwarding ....... 54 2552 8.2 Management Target Translation for Notification Forwarding 2553 ........................................................... 55 2554 9 Security Considerations ...................................... 57 2555 10 Acknowledgments ............................................. 57 2556 11 References .................................................. 58 2557 12 Author's Address ............................................ 59 2558 Appendix A Trap Configuration Example .......................... 60