idnits 2.17.1 draft-ietf-snmpv3-update-proto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 33 pages 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 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 550 has weird spacing: '...ield is set...' -- 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 (9 January 2000) is 8871 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) == Missing Reference: 'APPLICATION 0' is mentioned on line 289, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 291, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 293, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 297, but not defined == Missing Reference: 'APPLICATION 4' is mentioned on line 299, but not defined == Missing Reference: 'APPLICATION 6' is mentioned on line 301, but not defined -- Looks like a reference, but probably isn't: '0' on line 440 -- Looks like a reference, but probably isn't: '1' on line 443 -- Looks like a reference, but probably isn't: '2' on line 446 -- Looks like a reference, but probably isn't: '3' on line 348 -- Looks like a reference, but probably isn't: '4' on line 351 -- Looks like a reference, but probably isn't: '5' on line 354 -- Looks like a reference, but probably isn't: '6' on line 358 -- Looks like a reference, but probably isn't: '7' on line 362 -- Looks like a reference, but probably isn't: '8' on line 369 == Unused Reference: 'ASN1' is defined on line 1250, but no explicit reference was found in the text == Unused Reference: 'RFC2233' is defined on line 1321, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAG' ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2233 (Obsoleted by RFC 2863) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-COEX' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-MIB' Summary: 15 errors (**), 0 flaws (~~), 14 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Editor of this version: 2 Will Obsolete: 1905 R. Presuhn 3 BMC Software, Inc. 4 9 January 2000 6 Authors of previous version: 7 SNMPv2 Working Group 8 J. Case 9 SNMP Research, Inc. 10 K. McCloghrie 11 Cisco Systems, Inc. 12 M. Rose 13 Dover Beach Consulting, Inc. 14 S. Waldbusser 15 International Network Services 17 Version 2 of the Protocol Operations for 18 the Simple Network Management Protocol 19 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 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 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright Notice 42 Copyright (C) The Internet Society (2000). All Rights Reserved. 44 Abstract 46 This document is intended to obsolete RFC 1905, Protocol Operations 47 for Version 2 of the Simple Network Management Protocol (SNMPv2). It 48 defines the syntax and elements of procedure for sending, receiving, 49 and processing SNMP PDUs. 51 Table of Contents 53 1. Introduction ................................................ 3 54 2. Overview .................................................... 4 55 2.1. Management Information .................................... 4 56 2.2. Retransmission of Requests ................................ 4 57 2.3. Message Sizes ............................................. 4 58 2.4. Transport Mappings ........................................ 5 59 2.5. SMIv2 Data Type Mappings .................................. 5 60 3. Definitions ................................................. 6 61 4. Protocol Specification ...................................... 11 62 4.1. Common Constructs ......................................... 11 63 4.2. PDU Processing ............................................ 11 64 4.2.1. The GetRequest-PDU ...................................... 12 65 4.2.2. The GetNextRequest-PDU .................................. 13 66 4.2.2.1. Example of Table Traversal ............................ 14 67 4.2.3. The GetBulkRequest-PDU .................................. 16 68 4.2.3.1. Another Example of Table Traversal .................... 19 69 4.2.4. The Response-PDU ........................................ 20 70 4.2.5. The SetRequest-PDU ...................................... 21 71 4.2.6. The SNMPv2-Trap-PDU ..................................... 24 72 4.2.7. The InformRequest-PDU ................................... 24 73 5. Notice on Intellectual Property ............................. 25 74 6. Acknowledgments ............................................. 26 75 7. Security Considerations ..................................... 27 76 8. References .................................................. 27 77 9. Editor's Address ............................................ 29 78 10. Changes from RFC 1905 ...................................... 29 79 11. Issues ..................................................... 31 80 12. Full Copyright Statement ................................... 33 82 1. Introduction 84 The SNMP Management Framework at the time of this writing consists of 85 five major components: 87 - An overall architecture, described in RFC 2571 [RFC2571]. 89 - Mechanisms for describing and naming objects and events for 90 the purpose of management. The first version of this 91 Structure of Management Information (SMI) is called SMIv1 92 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 93 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, 94 called SMIv2, is described in STD 58, RFC 2578 [RFC2578], 95 STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 97 - Message protocols for transferring management information. 98 The first version of the SNMP message protocol is called 99 SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A 100 second version of the SNMP message protocol, which is not 101 an Internet standards track protocol, is called SNMPv2c and 102 described in RFC 1901 [RFC1901] and RFC -TM [RFC-TM]. The 103 third version of the message protocol is called SNMPv3 and 104 described in RFC -TM [RFC-TM], RFC 2572 [RFC2572] and RFC 105 2574 [RFC2574]. 107 - Protocol operations for accessing management information. 108 The first set of protocol operations and associated PDU 109 formats is described in STD 15, RFC 1157 [RFC1157]. A 110 second set of protocol operations and associated PDU 111 formats is described in this document. 113 - A set of fundamental applications described in RFC 2573 114 [RFC2573] and the view-based access control mechanism 115 described in RFC 2575 [RFC2575]. 117 A more detailed introduction to the SNMP Management Framework at 118 the time of this writing can be found in RFC 2570 [RFC2570]. 120 Managed objects are accessed via a virtual information store, 121 termed the Management Information Base or MIB. Objects in the 122 MIB are defined using the mechanisms defined in the SMI. 124 This document, Version 2 of the Protocol Operations for the 125 Simple Network Management Protocol, defines the operations of 126 the protocol with respect to the sending and receiving of PDUs 127 to be carried by the message protocol. 129 2. Overview 131 SNMP entities supporting command generator or notification receiver 132 applications (traditionally called "managers") communicate with SNMP 133 entities supporting command responder or notification originator 134 applications (traditionally called "agents"). The purpose of this 135 protocol is the transport of management information and operations. 137 2.1. Management Information 139 The term "variable" refers to an instance of a non-aggregate object 140 type defined according to the conventions set forth in the SMI 141 [RFC2578] or the textual conventions based on the SMI [RFC2579]. The 142 term "variable binding" normally refers to the pairing of the name of 143 a variable and its associated value. However, if certain kinds of 144 exceptional conditions occur during processing of a retrieval 145 request, a variable binding will pair a name and an indication of 146 that exception. 148 A variable-binding list is a simple list of variable bindings. 150 The name of a variable is an OBJECT IDENTIFIER which is the 151 concatenation of the OBJECT IDENTIFIER of the corresponding 152 object-type together with an OBJECT IDENTIFIER fragment identifying 153 the instance. The OBJECT IDENTIFIER of the corresponding object-type 154 is called the OBJECT IDENTIFIER prefix of the variable. 156 2.2. Retransmission of Requests 158 For all types of request in this protocol, the receiver is required 159 under normal circumstances, to generate and transmit a response to 160 the originator of the request. Whether or not a request should be 161 retransmitted if no corresponding response is received in an 162 appropriate time interval, is at the discretion of the application 163 originating the request. This will normally depend on the urgency of 164 the request. However, such an application needs to act responsibly 165 in respect to the frequency and duration of re-transmissions. 167 2.3. Message Sizes 169 The maximum size of an SNMP message is limited to the minimum of: 171 (1) the maximum message size which the destination SNMP entity can 172 accept; and, 174 (2) the maximum message size which the source SNMP entity can 175 generate. 177 The former may be known on a per-recipient basis; and in the absence 178 of such knowledge, is indicated by transport domain used when sending 179 the message. The latter is imposed by implementation-specific local 180 constraints. 182 Each transport mapping for the SNMP indicates the minimum message 183 size which a SNMP implementation must be able to produce or consume. 184 Although implementations are encouraged to support larger values 185 whenever possible, a conformant implementation must never generate 186 messages larger than allowed by the receiving SNMP entity. 188 One of the aims of the GetBulkRequest-PDU, specified in this 189 protocol, is to minimize the number of protocol exchanges required to 190 retrieve a large amount of management information. As such, this PDU 191 type allows an SNMP entity supporting command generator applications 192 to request that the response be as large as possible given the 193 constraints on message sizes. These constraints include the limits 194 on the size of messages which the SNMP entity supporting command 195 responder applications can generate, and the SNMP entity supporting 196 command generator applications can receive. 198 However, it is possible that such maximum sized messages may be 199 larger than the Path MTU of the path across the network traversed by 200 the messages. In this situation, such messages are subject to 201 fragmentation. Fragmentation is generally considered to be harmful 202 [FRAG], since among other problems, it leads to a decrease in the 203 reliability of the transfer of the messages. Thus, an SNMP entity 204 which sends a GetBulkRequest-PDU must take care to set its parameters 205 accordingly, so as to reduce the risk of fragmentation. In 206 particular, under conditions of network stress, only small values 207 should be used for max-repetitions. 209 2.4. Transport Mappings 211 It is important to note that the exchange of SNMP messages requires 212 only an unreliable datagram service, with every message being 213 entirely and independently contained in a single transport datagram. 214 Specific transport mappings and encoding rules are specified 215 elsewhere [RFC-TM]. However, the preferred mapping is the use of the 216 User Datagram Protocol [RFC768]. 218 2.5. SMIv2 Data Type Mappings 220 The SMIv2 [RFC2578] defines 11 base types (INTEGER, OCTET STRING, 221 OBJECT IDENTIFIER, Integer32, IpAddress, Counter32, Gauge32, 222 Unsigned32, TimeTicks, Opaque, Counter64) and the BITS construct. The 223 SMIv2 base types are mapped to the corresponding selection type in 224 the SimpleSyntax and ApplicationSyntax choices of the ASN.1 SNMP 225 protocol definition. Note that the INTEGER and Integer32 SMIv2 base 226 types are mapped to the integer-value selection type of the 227 SimpleSyntax choice. Similarly, the Gauge32 and Unsigned32 SMIv2 base 228 types are mapped to the unsigned-integer-value selection type of the 229 ApplicationSyntax choice. 231 The SMIv2 BITS construct is mapped to the string-value selection type 232 of the SimpleSyntax choice. A BITS value is encoded as an OCTET 233 STRING, in which all the named bits in (the definition of) the 234 bitstring, commencing with the first bit and proceeding to the last 235 bit, are placed in bits 8 to 1 of the first octet, followed by bits 8 236 to 1 of each subsequent octet in turn, followed by as many bits as 237 are needed of the final subsequent octet, commencing with bit 8. 238 Remaining bits, if any, of the final octet are set to zero on 239 generation and ignored on receipt. 241 3. Definitions 243 SNMPv2-PDU DEFINITIONS ::= BEGIN 245 ObjectName ::= OBJECT IDENTIFIER 247 ObjectSyntax ::= 248 CHOICE { 249 simple 250 SimpleSyntax, 252 application-wide 253 ApplicationSyntax 254 } 256 SimpleSyntax ::= 257 CHOICE { 258 integer-value 259 INTEGER (-2147483648..2147483647), 261 string-value 262 OCTET STRING (SIZE (0..65535)), 264 objectID-value 265 OBJECT IDENTIFIER 266 } 268 ApplicationSyntax ::= 269 CHOICE { 270 ipAddress-value 271 IpAddress, 273 counter-value 274 Counter32, 276 timeticks-value 277 TimeTicks, 279 arbitrary-value 280 Opaque, 282 big-counter-value 283 Counter64, 285 unsigned-integer-value 286 Unsigned32 287 } 289 IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) 291 Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) 293 Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) 295 Gauge32 ::= Unsigned32 297 TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) 299 Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING 301 Counter64 ::= [APPLICATION 6] 302 IMPLICIT INTEGER (0..18446744073709551615) 304 -- protocol data units 306 PDUs ::= 307 CHOICE { 308 get-request 309 GetRequest-PDU, 311 get-next-request 312 GetNextRequest-PDU, 314 get-bulk-request 315 GetBulkRequest-PDU, 317 response 318 Response-PDU, 320 set-request 321 SetRequest-PDU, 323 inform-request 324 InformRequest-PDU, 326 snmpV2-trap 327 SNMPv2-Trap-PDU, 329 report 330 Report-PDU, 331 } 333 -- PDUs 335 GetRequest-PDU ::= 336 [0] 337 IMPLICIT PDU 339 GetNextRequest-PDU ::= 340 [1] 341 IMPLICIT PDU 343 Response-PDU ::= 344 [2] 345 IMPLICIT PDU 347 SetRequest-PDU ::= 348 [3] 349 IMPLICIT PDU 351 -- [4] is obsolete 353 GetBulkRequest-PDU ::= 354 [5] 355 IMPLICIT BulkPDU 357 InformRequest-PDU ::= 358 [6] 359 IMPLICIT PDU 361 SNMPv2-Trap-PDU ::= 362 [7] 363 IMPLICIT PDU 365 -- Usage and precise semantics of Report-PDU are not defined 366 -- in this document. Any SNMP administrative framework making 367 -- use of this PDU must define its usage and semantics. 368 Report-PDU ::= 369 [8] 370 IMPLICIT PDU 372 max-bindings 373 INTEGER ::= 2147483647 375 PDU ::= 376 SEQUENCE { 377 request-id 378 INTEGER (-214783648..214783647), 380 error-status -- sometimes ignored 381 INTEGER { 382 noError(0), 383 tooBig(1), 384 noSuchName(2), -- for proxy compatibility 385 badValue(3), -- for proxy compatibility 386 readOnly(4), -- for proxy compatibility 387 genErr(5), 388 noAccess(6), 389 wrongType(7), 390 wrongLength(8), 391 wrongEncoding(9), 392 wrongValue(10), 393 noCreation(11), 394 inconsistentValue(12), 395 resourceUnavailable(13), 396 commitFailed(14), 397 undoFailed(15), 398 authorizationError(16), 399 notWritable(17), 400 inconsistentName(18) 401 }, 403 error-index -- sometimes ignored 404 INTEGER (0..max-bindings), 406 variable-bindings -- values are sometimes ignored 407 VarBindList 408 } 410 BulkPDU ::= -- must be identical in 411 SEQUENCE { -- structure to PDU 412 request-id 413 INTEGER (-214783648..214783647), 415 non-repeaters 416 INTEGER (0..max-bindings), 418 max-repetitions 419 INTEGER (0..max-bindings), 421 variable-bindings -- values are ignored 422 VarBindList 423 } 425 -- variable binding 427 VarBind ::= 428 SEQUENCE { 429 name 430 ObjectName, 432 CHOICE { 433 value 434 ObjectSyntax, 436 unSpecified -- in retrieval requests 437 NULL, 439 -- exceptions in responses 440 noSuchObject[0] 441 IMPLICIT NULL, 443 noSuchInstance[1] 444 IMPLICIT NULL, 446 endOfMibView[2] 447 IMPLICIT NULL 448 } 449 } 451 -- variable-binding list 453 VarBindList ::= 454 SEQUENCE (SIZE (0..max-bindings)) OF 455 VarBind 457 END 459 4. Protocol Specification 461 4.1. Common Constructs 463 The value of the request-id field in a Response-PDU takes the value 464 of the request-id field in the request PDU to which it is a response. 465 By use of the request-id value, an application can distinguish the 466 (potentially multiple) outstanding requests, and thereby correlate 467 incoming responses with outstanding requests. In cases where an 468 unreliable datagram service is used, the request-id also provides a 469 simple means of identifying messages duplicated by the network. Use 470 of the same request-id on a retransmission of a request allows the 471 response to either the original transmission or the retransmission to 472 satisfy the request. However, in order to calculate the round trip 473 time for transmission and processing of a request-response 474 transaction, the application needs to use a different request-id 475 value on a retransmitted request. The latter strategy is recommended 476 for use in the majority of situations. 478 A non-zero value of the error-status field in a Response-PDU is used 479 to indicate that an error occurred to prevent the processing of the 480 request. In these cases, a non-zero value of the Response-PDU's 481 error-index field provides additional information by identifying 482 which variable binding in the list caused the error. A variable 483 binding is identified by its index value. The first variable binding 484 in a variable-binding list is index one, the second is index two, 485 etc. 487 SNMP limits OBJECT IDENTIFIER values to a maximum of 128 488 sub-identifiers, where each sub-identifier has a maximum value of 489 2**32-1. 491 4.2. PDU Processing 493 In the elements of procedure below, any field of a PDU which is not 494 referenced by the relevant procedure is ignored by the receiving SNMP 495 entity. However, all components of a PDU, including those whose 496 values are ignored by the receiving SNMP entity, must have valid 497 ASN.1 syntax and encoding. For example, some PDUs (e.g., the 498 GetRequest-PDU) are concerned only with the name of a variable and 499 not its value. In this case, the value portion of the variable 500 binding is ignored by the receiving SNMP entity. The unSpecified 501 value is defined for use as the value portion of such bindings. 503 On generating a management communication, the message "wrapper" to 504 encapsulate the PDU is generated according to the "Elements of 505 Procedure" of the administrative framework in use is followed. While 506 the definition of "max-bindings" does impose an upper-bound on the 507 number of variable bindings, in practice, the size of a message is 508 limited only by constraints on the maximum message size -- it is not 509 limited by the number of variable bindings. A compliant 510 implementation must support as many variable bindings in a PDU or 511 BulkPDU as fit into the overall maximum message size limit of the 512 SNMP engine, but no more than 2147483647. 514 On receiving a management communication, the "Elements of Procedure" 515 of the administrative framework in use is followed, and if those 516 procedures indicate that the operation contained within the message 517 is to be performed locally, then those procedures also indicate the 518 MIB view which is visible to the operation. 520 4.2.1. The GetRequest-PDU 522 A GetRequest-PDU is generated and transmitted at the request of an 523 application. 525 Upon receipt of a GetRequest-PDU, the receiving SNMP entity processes 526 each variable binding in the variable-binding list to produce a 527 Response-PDU. All fields of the Response-PDU have the same values as 528 the corresponding fields of the received request except as indicated 529 below. Each variable binding is processed as follows: 531 (1) If the variable binding's name exactly matches the name of a 532 variable accessible by this request, then the variable binding's 533 value field is set to the value of the named variable. 535 (2) Otherwise, if the variable binding's name does not have an 536 OBJECT IDENTIFIER prefix which exactly matches the OBJECT 537 IDENTIFIER prefix of any (potential) variable accessible by this 538 request, then its value field is set to "noSuchObject". 540 (3) Otherwise, the variable binding's value field is set to 541 "noSuchInstance". 543 If the processing of any variable binding fails for a reason other 544 than listed above, then the Response-PDU is re-formatted with the 545 same values in its request-id and variable-bindings fields as the 546 received GetRequest-PDU, with the value of its error-status field set 547 to "genErr", and the value of its error-index field is set to the 548 index of the failed variable binding. 550 Otherwise, the value of the Response-PDU's error-status field is set 551 to "noError", and the value of its error-index field is zero. 553 The generated Response-PDU is then encapsulated into a message. If 554 the size of the resultant message is less than or equal to both a 555 local constraint and the maximum message size of the originator, it 556 is transmitted to the originator of the GetRequest-PDU. 558 Otherwise, an alternate Response-PDU is generated. This alternate 559 Response-PDU is formatted with the same value in its request-id field 560 as the received GetRequest-PDU, with the value of its error-status 561 field set to "tooBig", the value of its error-index field set to 562 zero, and an empty variable-bindings field. This alternate 563 Response-PDU is then encapsulated into a message. If the size of the 564 resultant message is less than or equal to both a local constraint 565 and the maximum message size of the originator, it is transmitted to 566 the originator of the GetRequest-PDU. Otherwise, the snmpSilentDrops 567 [RFC-MIB] counter is incremented and the resultant message is 568 discarded. 570 4.2.2. The GetNextRequest-PDU 572 A GetNextRequest-PDU is generated and transmitted at the request of 573 an application. 575 Upon receipt of a GetNextRequest-PDU, the receiving SNMP entity 576 processes each variable binding in the variable-binding list to 577 produce a Response-PDU. All fields of the Response-PDU have the same 578 values as the corresponding fields of the received request except as 579 indicated below. Each variable binding is processed as follows: 581 (1) The variable is located which is in the lexicographically 582 ordered list of the names of all variables which are accessible 583 by this request and whose name is the first lexicographic 584 successor of the variable binding's name in the incoming 585 GetNextRequest-PDU. The corresponding variable binding's name 586 and value fields in the Response-PDU are set to the name and 587 value of the located variable. 589 (2) If the requested variable binding's name does not 590 lexicographically precede the name of any variable accessible by 591 this request, i.e., there is no lexicographic successor, then 592 the corresponding variable binding produced in the Response-PDU 593 has its value field set to "endOfMibView", and its name field 594 set to the variable binding's name in the request. 596 If the processing of any variable binding fails for a reason other 597 than listed above, then the Response-PDU is re-formatted with the 598 same values in its request-id and variable-bindings fields as the 599 received GetNextRequest-PDU, with the value of its error-status field 600 set to "genErr", and the value of its error-index field is set to the 601 index of the failed variable binding. 603 Otherwise, the value of the Response-PDU's error-status field is set 604 to "noError", and the value of its error-index field is zero. 606 The generated Response-PDU is then encapsulated into a message. If 607 the size of the resultant message is less than or equal to both a 608 local constraint and the maximum message size of the originator, it 609 is transmitted to the originator of the GetNextRequest-PDU. 611 Otherwise, an alternate Response-PDU is generated. This alternate 612 Response-PDU is formatted with the same values in its request-id 613 field as the received GetNextRequest-PDU, with the value of its 614 error-status field set to "tooBig", the value of its error-index 615 field set to zero, and an empty variable-bindings field. This 616 alternate Response-PDU is then encapsulated into a message. If the 617 size of the resultant message is less than or equal to both a local 618 constraint and the maximum message size of the originator, it is 619 transmitted to the originator of the GetNextRequest-PDU. Otherwise, 620 the snmpSilentDrops [RFC-MIB] message is discarded. 622 4.2.2.1. Example of Table Traversal 624 An important use of the GetNextRequest-PDU is the traversal of 625 conceptual tables of information within a MIB. The semantics of this 626 type of request, together with the method of identifying individual 627 instances of objects in the MIB, provides access to related objects 628 in the MIB as if they enjoyed a tabular organization. 630 In the protocol exchange sketched below, an application retrieves the 631 media-dependent physical address and the address-mapping type for 632 each entry in the IP net-to-media Address Translation Table [RFC1213] 633 of a particular network element. It also retrieves the value of 634 sysUpTime [RFC-MIB], at which the mappings existed. Suppose that the 635 command responder's IP net-to-media table has three entries: 636 Interface-Number Network-Address Physical-Address Type 638 1 10.0.0.51 00:00:10:01:23:45 static 639 1 9.2.3.4 00:00:10:54:32:10 dynamic 640 2 10.0.0.15 00:00:10:98:76:54 dynamic 642 The SNMP entity supporting a command generator application begins by 643 sending a GetNextRequest-PDU containing the indicated OBJECT 644 IDENTIFIER values as the requested variable names: 646 GetNextRequest ( sysUpTime, 647 ipNetToMediaPhysAddress, 648 ipNetToMediaType ) 650 The SNMP entity supporting a command responder application responds 651 with a Response-PDU: 653 Response (( sysUpTime.0 = "123456" ), 654 ( ipNetToMediaPhysAddress.1.9.2.3.4 = 655 "000010543210" ), 656 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" )) 658 The SNMP entity supporting the command generator application 659 continues with: 661 GetNextRequest ( sysUpTime, 662 ipNetToMediaPhysAddress.1.9.2.3.4, 663 ipNetToMediaType.1.9.2.3.4 ) 665 The SNMP entity supporting the command responder application responds 666 with: 668 Response (( sysUpTime.0 = "123461" ), 669 ( ipNetToMediaPhysAddress.1.10.0.0.51 = 670 "000010012345" ), 671 ( ipNetToMediaType.1.10.0.0.51 = "static" )) 673 The SNMP entity supporting the command generator application 674 continues with: 676 GetNextRequest ( sysUpTime, 677 ipNetToMediaPhysAddress.1.10.0.0.51, 678 ipNetToMediaType.1.10.0.0.51 ) 680 The SNMP entity supporting the command responder application responds 681 with: 683 Response (( sysUpTime.0 = "123466" ), 684 ( ipNetToMediaPhysAddress.2.10.0.0.15 = 685 "000010987654" ), 686 ( ipNetToMediaType.2.10.0.0.15 = "dynamic" )) 688 The SNMP entity supporting the command generator application 689 continues with: 691 GetNextRequest ( sysUpTime, 692 ipNetToMediaPhysAddress.2.10.0.0.15, 693 ipNetToMediaType.2.10.0.0.15 ) 695 As there are no further entries in the table, the SNMP entity 696 supporting the command responder application responds with the 697 variables that are next in the lexicographical ordering of the 698 accessible object names, for example: 700 Response (( sysUpTime.0 = "123471" ), 701 ( ipNetToMediaNetAddress.1.9.2.3.4 = 702 "9.2.3.4" ), 703 ( ipRoutingDiscards.0 = "2" )) 705 Note now, having reached the end of the column for 706 ipNetToMediaPhysAddress, the second variable binding in the command 707 responder application has "wrapped" to the first row in the next 708 column. Furthermore, note how, having reached the end of the 709 ipNetToMediaTable for the third variable binding, the command 710 responder application has responded with the next available object, 711 which is outside that table. This response signals the end of the 712 table to the command generator application. 714 4.2.3. The GetBulkRequest-PDU 716 A GetBulkRequest-PDU is generated and transmitted at the request of 717 an application. The purpose of the GetBulkRequest-PDU is to request 718 the transfer of a potentially large amount of data, including, but 719 not limited to, the efficient and rapid retrieval of large tables. 721 Upon receipt of a GetBulkRequest-PDU, the receiving SNMP entity 722 processes each variable binding in the variable-binding list to 723 produce a Response-PDU with its request-id field having the same 724 value as in the request. 726 For the GetBulkRequest-PDU type, the successful processing of each 727 variable binding in the request generates zero or more variable 728 bindings in the Response-PDU. That is, the one-to-one mapping 729 between the variable bindings of the GetRequest-PDU, 730 GetNextRequest-PDU, and SetRequest-PDU types and the resultant 731 Response-PDUs does not apply for the mapping between the variable 732 bindings of a GetBulkRequest-PDU and the resultant Response-PDU. 734 The values of the non-repeaters and max-repetitions fields in the 735 request specify the processing requested. One variable binding in 736 the Response-PDU is requested for the first N variable bindings in 737 the request and M variable bindings are requested for each of the R 738 remaining variable bindings in the request. Consequently, the total 739 number of requested variable bindings communicated by the request is 740 given by N + (M * R), where N is the minimum of: a) the value of the 741 non-repeaters field in the request, and b) the number of variable 742 bindings in the request; M is the value of the max-repetitions field 743 in the request; and R is the maximum of: a) number of variable 744 bindings in the request - N, and b) zero. 746 The receiving SNMP entity produces a Response-PDU with up to the 747 total number of requested variable bindings communicated by the 748 request. The request-id shall have the same value as the received 749 GetBulkRequest-PDU. 751 If N is greater than zero, the first through the (N)-th variable 752 bindings of the Response-PDU are each produced as follows: 754 (1) The variable is located which is in the lexicographically 755 ordered list of the names of all variables which are accessible 756 by this request and whose name is the first lexicographic 757 successor of the variable binding's name in the incoming 758 GetBulkRequest-PDU. The corresponding variable binding's name 759 and value fields in the Response-PDU are set to the name and 760 value of the located variable. 762 (2) If the requested variable binding's name does not 763 lexicographically precede the name of any variable accessible by 764 this request, i.e., there is no lexicographic successor, then 765 the corresponding variable binding produced in the Response-PDU 766 has its value field set to "endOfMibView", and its name field 767 set to the variable binding's name in the request. 769 If M and R are non-zero, the (N + 1)-th and subsequent variable 770 bindings of the Response-PDU are each produced in a similar manner. 771 For each iteration i, such that i is greater than zero and less than 772 or equal to M, and for each repeated variable, r, such that r is 773 greater than zero and less than or equal to R, the (N + ( (i-1) * R ) 774 + r)-th variable binding of the Response-PDU is produced as follows: 776 (1) The variable which is in the lexicographically ordered list of 777 the names of all variables which are accessible by this request 778 and whose name is the (i)-th lexicographic successor of the (N + 779 r)-th variable binding's name in the incoming GetBulkRequest-PDU 780 is located and the variable binding's name and value fields are 781 set to the name and value of the located variable. 783 (2) If there is no (i)-th lexicographic successor, then the 784 corresponding variable binding produced in the Response-PDU has 785 its value field set to "endOfMibView", and its name field set to 786 either the last lexicographic successor, or if there are no 787 lexicographic successors, to the (N + r)-th variable binding's 788 name in the request. 790 While the maximum number of variable bindings in the Response-PDU is 791 bounded by N + (M * R), the response may be generated with a lesser 792 number of variable bindings (possibly zero) for either of three 793 reasons. 795 (1) If the size of the message encapsulating the Response-PDU 796 containing the requested number of variable bindings would be 797 greater than either a local constraint or the maximum message 798 size of the originator, then the response is generated with a 799 lesser number of variable bindings. This lesser number is the 800 ordered set of variable bindings with some of the variable 801 bindings at the end of the set removed, such that the size of 802 the message encapsulating the Response-PDU is approximately 803 equal to but no greater than either a local constraint or the 804 maximum message size of the originator. Note that the number of 805 variable bindings removed has no relationship to the values of 806 N, M, or R. 808 (2) The response may also be generated with a lesser number of 809 variable bindings if for some value of iteration i, such that i 810 is greater than zero and less than or equal to M, that all of 811 the generated variable bindings have the value field set to 812 "endOfMibView". In this case, the variable bindings may be 813 truncated after the (N + (i * R))-th variable binding. 815 (3) In the event that the processing of a request with many 816 repetitions requires a significantly greater amount of 817 processing time than a normal request, then a command responder 818 application may terminate the request with less than the full 819 number of repetitions, providing at least one repetition is 820 completed. 822 If the processing of any variable binding fails for a reason other 823 than listed above, then the Response-PDU is re-formatted with the 824 same values in its request-id and variable-bindings fields as the 825 received GetBulkRequest-PDU, with the value of its error-status field 826 set to "genErr", and the value of its error-index field is set to the 827 index of the variable binding in the original request which 828 corresponds to the failed variable binding. 830 Otherwise, the value of the Response-PDU's error-status field is set 831 to "noError", and the value of its error-index field to zero. 833 The generated Response-PDU (possibly with an empty variable-bindings 834 field) is then encapsulated into a message. If the size of the 835 resultant message is less than or equal to both a local constraint 836 and the maximum message size of the originator, it is transmitted to 837 the originator of the GetBulkRequest-PDU. Otherwise, the 838 snmpSilentDrops [RFC-MIB] counter is incremented and the resultant 839 message is discarded. 841 4.2.3.1. Another Example of Table Traversal 843 This example demonstrates how the GetBulkRequest-PDU can be used as 844 an alternative to the GetNextRequest-PDU. The same traversal of the 845 IP net-to-media table as shown in Section 4.2.2.1 is achieved with 846 fewer exchanges. 848 The SNMP entity supporting the command generator application begins 849 by sending a GetBulkRequest-PDU with the modest max-repetitions value 850 of 2, and containing the indicated OBJECT IDENTIFIER values as the 851 requested variable names: 853 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] 854 ( sysUpTime, 855 ipNetToMediaPhysAddress, 856 ipNetToMediaType ) 858 The SNMP entity supporting the command responder application responds 859 with a Response-PDU: 861 Response (( sysUpTime.0 = "123456" ), 862 ( ipNetToMediaPhysAddress.1.9.2.3.4 = 863 "000010543210" ), 864 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ), 865 ( ipNetToMediaPhysAddress.1.10.0.0.51 = 866 "000010012345" ), 867 ( ipNetToMediaType.1.10.0.0.51 = "static" )) 869 The SNMP entity supporting the command generator application 870 continues with: 872 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] 873 ( sysUpTime, 874 ipNetToMediaPhysAddress.1.10.0.0.51, 875 ipNetToMediaType.1.10.0.0.51 ) 877 The SNMP entity supporting the command responder application responds 878 with: 880 Response (( sysUpTime.0 = "123466" ), 881 ( ipNetToMediaPhysAddress.2.10.0.0.15 = 882 "000010987654" ), 883 ( ipNetToMediaType.2.10.0.0.15 = 884 "dynamic" ), 885 ( ipNetToMediaNetAddress.1.9.2.3.4 = 886 "9.2.3.4" ), 887 ( ipRoutingDiscards.0 = "2" )) 889 Note how, as in the first example, the variable bindings in the 890 response indicate that the end of the table has been reached. The 891 fourth variable binding does so by returning information from the 892 next available column; the fifth variable binding does so by 893 returning information from the first available object 894 lexicographically following the table. This response signals the end 895 of the table to the command generator application. 897 4.2.4. The Response-PDU 899 The Response-PDU is generated by an SNMP entity only upon receipt of 900 a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, 901 SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this 902 document. 904 If the error-status field of the Response-PDU is non-zero, the value 905 fields of the variable bindings in the variable binding list are 906 ignored. 908 If both the error-status field and the error-index field of the 909 Response-PDU are non-zero, then the value of the error-index field is 910 the index of the variable binding (in the variable-binding list of 911 the corresponding request) for which the request failed. The first 912 variable binding in a request's variable-binding list is index one, 913 the second is index two, etc. 915 A compliant SNMP entity supporting a command generator application 916 must be able to properly receive and handle a Response-PDU with an 917 error-status field equal to "noSuchName", "badValue", or "readOnly". 918 (See Section ???3.1.2??? of [RFC-COEX].) 920 Upon receipt of a Response-PDU, the receiving SNMP entity presents 921 its contents to the application which generated the request with the 922 same request-id value. For more details, see [RFC2572]. 924 4.2.5. The SetRequest-PDU 926 A SetRequest-PDU is generated and transmitted at the request of an 927 application. 929 Upon receipt of a SetRequest-PDU, the receiving SNMP entity 930 determines the size of a message encapsulating a Response-PDU having 931 the same values in its request-id and variable-bindings fields as the 932 received SetRequest-PDU, and the largest possible sizes of the 933 error-status and error-index fields. If the determined message size 934 is greater than either a local constraint or the maximum message size 935 of the originator, then an alternate Response-PDU is generated, 936 transmitted to the originator of the SetRequest-PDU, and processing 937 of the SetRequest-PDU terminates immediately thereafter. This 938 alternate Response-PDU is formatted with the same values in its 939 request-id field as the received SetRequest-PDU, with the value of 940 its error-status field set to "tooBig", the value of its error-index 941 field set to zero, and an empty variable-bindings field. This 942 alternate Response-PDU is then encapsulated into a message. If the 943 size of the resultant message is less than or equal to both a local 944 constraint and the maximum message size of the originator, it is 945 transmitted to the originator of the SetRequest-PDU. Otherwise, the 946 snmpSilentDrops [RFC-MIB] counter is incremented and the resultant 947 message is discarded. Regardless, processing of the SetRequest-PDU 948 terminates. 950 Otherwise, the receiving SNMP entity processes each variable binding 951 in the variable-binding list to produce a Response-PDU. All fields 952 of the Response-PDU have the same values as the corresponding fields 953 of the received request except as indicated below. 955 The variable bindings are conceptually processed as a two phase 956 operation. In the first phase, each variable binding is validated; 957 if all validations are successful, then each variable is altered in 958 the second phase. Of course, implementors are at liberty to 959 implement either the first, or second, or both, of these conceptual 960 phases as multiple implementation phases. Indeed, such multiple 961 implementation phases may be necessary in some cases to ensure 962 consistency. 964 The following validations are performed in the first phase on each 965 variable binding until they are all successful, or until one fails: 967 (1) If the variable binding's name specifies an existing or 968 non-existent variable to which this request is/would be denied 969 access because it is/would not be in the appropriate MIB view, 970 then the value of the Response-PDU's error-status field is set 971 to "noAccess", and the value of its error-index field is set to 972 the index of the failed variable binding. 974 (2) Otherwise, if there are no variables which share the same OBJECT 975 IDENTIFIER prefix as the variable binding's name, and which are 976 able to be created or modified no matter what new value is 977 specified, then the value of the Response-PDU's error-status 978 field is set to "notWritable", and the value of its error-index 979 field is set to the index of the failed variable binding. 981 (3) Otherwise, if the variable binding's value field specifies, 982 according to the ASN.1 language, a type which is inconsistent 983 with that required for all variables which share the same OBJECT 984 IDENTIFIER prefix as the variable binding's name, then the value 985 of the Response-PDU's error-status field is set to "wrongType", 986 and the value of its error-index field is set to the index of 987 the failed variable binding. 989 (4) Otherwise, if the variable binding's value field specifies, 990 according to the ASN.1 language, a length which is inconsistent 991 with that required for all variables which share the same OBJECT 992 IDENTIFIER prefix as the variable binding's name, then the value 993 of the Response-PDU's error-status field is set to 994 "wrongLength", and the value of its error-index field is set to 995 the index of the failed variable binding. 997 (5) Otherwise, if the variable binding's value field contains an 998 ASN.1 encoding which is inconsistent with that field's ASN.1 999 tag, then the value of the Response-PDU's error-status field is 1000 set to "wrongEncoding", and the value of its error-index field 1001 is set to the index of the failed variable binding. (Note that 1002 not all implementation strategies will generate this error.) 1004 (6) Otherwise, if the variable binding's value field specifies a 1005 value which could under no circumstances be assigned to the 1006 variable, then the value of the Response-PDU's error-status 1007 field is set to "wrongValue", and the value of its error-index 1008 field is set to the index of the failed variable binding. 1010 (7) Otherwise, if the variable binding's name specifies a variable 1011 which does not exist and could not ever be created (even though 1012 some variables sharing the same OBJECT IDENTIFIER prefix might 1013 under some circumstances be able to be created), then the value 1014 of the Response-PDU's error-status field is set to "noCreation", 1015 and the value of its error-index field is set to the index of 1016 the failed variable binding. 1018 (8) Otherwise, if the variable binding's name specifies a variable 1019 which does not exist but can not be created under the present 1020 circumstances (even though it could be created under other 1021 circumstances), then the value of the Response-PDU's 1022 error-status field is set to "inconsistentName", and the value 1023 of its error-index field is set to the index of the failed 1024 variable binding. 1026 (9) Otherwise, if the variable binding's name specifies a variable 1027 which exists but can not be modified no matter what new value is 1028 specified, then the value of the Response-PDU's error-status 1029 field is set to "notWritable", and the value of its error-index 1030 field is set to the index of the failed variable binding. 1032 (10) Otherwise, if the variable binding's value field specifies a 1033 value that could under other circumstances be held by the 1034 variable, but is presently inconsistent or otherwise unable to 1035 be assigned to the variable, then the value of the 1036 Response-PDU's error-status field is set to "inconsistentValue", 1037 and the value of its error-index field is set to the index of 1038 the failed variable binding. 1040 (11) When, during the above steps, the assignment of the value 1041 specified by the variable binding's value field to the specified 1042 variable requires the allocation of a resource which is 1043 presently unavailable, then the value of the Response-PDU's 1044 error-status field is set to "resourceUnavailable", and the 1045 value of its error-index field is set to the index of the failed 1046 variable binding. 1048 (12) If the processing of the variable binding fails for a reason 1049 other than listed above, then the value of the Response-PDU's 1050 error-status field is set to "genErr", and the value of its 1051 error-index field is set to the index of the failed variable 1052 binding. 1054 (13) Otherwise, the validation of the variable binding succeeds. 1056 At the end of the first phase, if the validation of all variable 1057 bindings succeeded, then the value of the Response-PDU's error-status 1058 field is set to "noError" and the value of its error-index field is 1059 zero, and processing continues as follows. 1061 For each variable binding in the request, the named variable is 1062 created if necessary, and the specified value is assigned to it. 1063 Each of these variable assignments occurs as if simultaneously with 1064 respect to all other assignments specified in the same request. 1065 However, if the same variable is named more than once in a single 1066 request, with different associated values, then the actual assignment 1067 made to that variable is implementation-specific. 1069 If any of these assignments fail (even after all the previous 1070 validations), then all other assignments are undone, and the 1071 Response-PDU is modified to have the value of its error-status field 1072 set to "commitFailed", and the value of its error-index field set to 1073 the index of the failed variable binding. 1075 If and only if it is not possible to undo all the assignments, then 1076 the Response-PDU is modified to have the value of its error-status 1077 field set to "undoFailed", and the value of its error-index field is 1078 set to zero. Note that implementations are strongly encouraged to 1079 take all possible measures to avoid use of either "commitFailed" or 1080 "undoFailed" - these two error-status codes are not to be taken as 1081 license to take the easy way out in an implementation. 1083 Finally, the generated Response-PDU is encapsulated into a message, 1084 and transmitted to the originator of the SetRequest-PDU. 1086 4.2.6. The SNMPv2-Trap-PDU 1088 An SNMPv2-Trap-PDU is generated and transmitted by an SNMP entity on 1089 behalf of a notification originator application. The SNMPv2-Trap-PDU 1090 is often used to notify a notification receiver application at a 1091 logically remote SNMP entity that an event has occurred or that a 1092 condition is present. There is no confirmation associated with this 1093 notification delivery mechanism. 1095 The destination(s) to which an SNMPv2-Trap-PDU is sent is determined 1096 in an implementation-dependent fashion by the SNMP entity. The first 1097 two variable bindings in the variable binding list of an 1098 SNMPv2-Trap-PDU are sysUpTime.0 [RFC-MIB] and snmpTrapOID.0 [RFC-MIB] 1099 respectively. If the OBJECTS clause is present in the invocation of 1100 the corresponding NOTIFICATION-TYPE macro, then each corresponding 1101 variable, as instantiated by this notification, is copied, in order, 1102 to the variable-bindings field. If any additional variables are 1103 being included (at the option of the generating SNMP entity), then 1104 each is copied to the variable-bindings field. 1106 4.2.7. The InformRequest-PDU 1108 An InformRequest-PDU is generated and transmitted by an SNMP entity 1109 on behalf of a notification originator application. The 1110 InformRequest-PDU is often used to notify a notification receiver 1111 application that an event has occurred or that a condition is 1112 present. This is a confirmed notification delivery mechanism, 1113 although there is, of course, no guarantee of delivery. 1115 The destination(s) to which an InformRequest-PDU is sent is specified 1116 by the notification originator application. The first two variable 1117 bindings in the variable binding list of an InformRequest-PDU are 1118 sysUpTime.0 [RFC-MIB] and snmpTrapOID.0 [RFC-MIB] respectively. If 1119 the OBJECTS clause is present in the invocation of the corresponding 1120 NOTIFICATION-TYPE macro, then each corresponding variable, as 1121 instantiated by this notification, is copied, in order, to the 1122 variable-bindings field. 1124 Upon receipt of an InformRequest-PDU, the receiving SNMP entity 1125 determines the size of a message encapsulating a Response-PDU with 1126 the same values in its request-id, error-status, error-index and 1127 variable-bindings fields as the received InformRequest-PDU. If the 1128 determined message size is greater than either a local constraint or 1129 the maximum message size of the originator, then an alternate 1130 Response-PDU is generated, transmitted to the originator of the 1131 InformRequest-PDU, and processing of the InformRequest-PDU terminates 1132 immediately thereafter. This alternate Response-PDU is formatted 1133 with the same values in its request-id field as the received 1134 InformRequest-PDU, with the value of its error-status field set to 1135 "tooBig", the value of its error-index field set to zero, and an 1136 empty variable-bindings field. This alternate Response-PDU is then 1137 encapsulated into a message. If the size of the resultant message is 1138 less than or equal to both a local constraint and the maximum message 1139 size of the originator, it is transmitted to the originator of the 1140 InformRequest-PDU. Otherwise, the snmpSilentDrops [RFC-MIB] counter 1141 is incremented and the resultant message is discarded. Regardless, 1142 processing of the InformRequest-PDU terminates. 1144 Otherwise, the receiving SNMP entity: 1146 (1) presents its contents to the appropriate application; 1148 (2) generates a Response-PDU with the same values in its request-id 1149 and variable-bindings fields as the received InformRequest-PDU, 1150 with the value of its error-status field is set to "noError" and 1151 the value of its error-index field is zero; and 1153 (3) transmits the generated Response-PDU to the originator of the 1154 InformRequest-PDU. 1156 5. Notice on Intellectual Property 1158 The IETF takes no position regarding the validity or scope of any 1159 intellectual property or other rights that might be claimed to 1160 pertain to the implementation or use of the technology described in 1161 this document or the extent to which any license under such rights 1162 might or might not be available; neither does it represent that it 1163 has made any effort to identify any such rights. Information on the 1164 IETF's procedures with respect to rights in standards-track and 1165 standards-related documentation can be found in BCP-11. Copies of 1166 claims of rights made available for publication and any assurances of 1167 licenses to be made available, or the result of an attempt made to 1168 obtain a general license or permission for the use of such 1169 proprietary rights by implementors or users of this specification can 1170 be obtained from the IETF Secretariat. 1172 The IETF invites any interested party to bring to its attention any 1173 copyrights, patents or patent applications, or other proprietary 1174 rights which may cover technology that may be required to practice 1175 this standard. Please address the information to the IETF Executive 1176 Director. 1178 6. Acknowledgments 1180 The previous versions of this document, edited by Keith McCloghrie, 1181 was the result of significant work by four major contributors: 1183 Jeffrey D. Case (SNMP Research, case@snmp.com) 1184 Keith McCloghrie (Cisco Systems, kzm@cisco.com) 1185 Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) 1186 Steven Waldbusser (International Network Services, stevew@uni.ins.com) 1188 In addition, the contributions of the SNMPv2 Working Group are 1189 acknowledged. In particular, a special thanks is extended for the 1190 contributions of: 1192 Alexander I. Alten (Novell) 1193 Dave Arneson (Cabletron) 1194 Uri Blumenthal (IBM) 1195 Doug Book (Chipcom) 1196 Kim Curran (Bell-Northern Research) 1197 Jim Galvin (Trusted Information Systems) 1198 Maria Greene (Ascom Timeplex) 1199 Iain Hanson (Digital) 1200 Dave Harrington (Cabletron) 1201 Nguyen Hien (IBM) 1202 Jeff Johnson (Cisco Systems) 1203 Michael Kornegay (Object Quest) 1204 Deirdre Kostick (AT&T Bell Labs) 1205 David Levi (SNMP Research) 1206 Daniel Mahoney (Cabletron) 1207 Russ Mundy (TIS Labs at Network Associates, Chair) 1208 Bob Natale (ACE*COMM) 1209 Brian O'Keefe (Hewlett Packard) 1210 Andrew Pearson (SNMP Research) 1211 Dave Perkins (Peer Networks) 1212 Randy Presuhn (Peer Networks) 1213 Aleksey Romanov (Quality Quorum) 1214 Shawn Routhier (Epilogue) 1215 Jon Saperia (BGS Systems) 1216 Juergen Schoenwaelder (TU Braunschweig) 1217 Bob Stewart (Cisco Systems) 1218 Kaj Tesink (Bellcore) 1219 Glenn Waters (Bell-Northern Research) 1220 Bert Wijnen (IBM) 1222 7. Security Considerations 1224 The protocol defined in this document by itself does not provide a 1225 secure environment. Even if the network itself is secure (for 1226 example by using IPSec), there is no control as to who on the secure 1227 network is allowed to access and GET/SET (read/change) MIB 1228 information. 1230 It is recommended that the implementors consider the security 1231 features as provided by the SNMPv3 framework. Specifically, the use 1232 of the User-based Security Model RFC 2574 [RFC2574] and the 1233 View-based Access Control Model RFC 2575 [RFC2575] is recommended. 1235 It is then a customer/user responsibility to ensure that the SNMP 1236 entity is properly configured so that: 1238 - only those principals (users) having legitimate rights can 1239 access or modify the values of any MIB objects supported by 1240 that entity; 1242 - the occurrence of particular events on the entity will be 1243 communicated appropriately; 1245 - the entity responds appropriately and with due credence to 1246 events and information that have been communicated to it. 1248 8. References 1250 [ASN1] Information processing systems - Open Systems 1251 Interconnection - Specification of Abstract Syntax 1252 Notation One (ASN.1), International Organization for 1253 Standardization. International Standard 8824, December 1254 1987. 1256 [FRAG] Kent, C., and J. Mogul, Fragmentation Considered Harmful, 1257 Proceedings, ACM SIGCOMM '87, Stowe, VT, August 1987. 1259 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1260 USC/Information Sciences Institute, August 1980. 1262 [RFC1213] McCloghrie, K., and M. Rose, Editors, "Management 1263 Information Base for Network Management of TCP/IP-based 1264 internets: MIB-II", STD 17, RFC 1213, March 1991. 1266 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 1267 Architecture for Describing SNMP Management Frameworks", 1268 RFC 2571, April 1999. 1270 [RFC1155] Rose, M., and K. McCloghrie, "Structure and 1271 Identification of Management Information for TCP/IP-based 1272 Internets", STD 16, RFC 1155, May 1990. 1274 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 1275 STD 16, RFC 1212, March 1991. 1277 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 1278 the SNMP", RFC 1215, March 1991. 1280 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1281 Rose, M., and S. Waldbusser, "Structure of Management 1282 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1283 1999. 1285 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1286 Rose, M., and S. Waldbusser, "Textual Conventions for 1287 SMIv2", STD 58, RFC 2579, April 1999. 1289 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1290 Rose, M., and S. Waldbusser, "Conformance Statements for 1291 SMIv2", STD 58, RFC 2580, April 1999. 1293 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 1294 "Simple Network Management Protocol", STD 15, RFC 1157, 1295 May 1990. 1297 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1298 "Introduction to Community-based SNMPv2", RFC 1901, 1299 January 1996. 1301 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, 1302 "Message Processing and Dispatching for the Simple 1303 Network Management Protocol (SNMP)", RFC 2572, April 1304 1999. 1306 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 1307 (USM) for version 3 of the Simple Network Management 1308 Protocol (SNMPv3)", RFC 2574, April 1999. 1310 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 1311 Applications", RFC 2573, April 1999. 1313 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 1314 Access Control Model (VACM) for the Simple Network 1315 Management Protocol (SNMP)", RFC 2575, April 1999. 1317 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 1318 "Introduction to Version 3 of the Internet-standard 1319 Network Management Framework", RFC 2570, April 1999. 1321 [RFC2233] McCloghrie, K., and F. Kastenholz, "The Interfaces Group 1322 MIB using SMIv2", RFC 2233, November 1997. 1324 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 1325 "Coexistence between Version 1, Version 2, and Version 3 1326 of the Internet-standard Network Management Framework", 1327 , December 1999. 1329 [RFC-TM] Presuhn, R., SNMPv2 Working Group, Case, J., McCloghrie, 1330 K., Rose, M., and S. Waldbusser, "Transport Mappings for 1331 the Simple Network Management Protocol", 1332 , January 2000. 1334 [RFC-MIB] Presuhn, R., SNMPv2 Working Group, Case, J., McCloghrie, 1335 K., Rose, M., and S. Waldbusser, "Management Information 1336 Base for the Simple Network Management Protocol", 1337 , January 2000. 1339 9. Editor's Address 1341 Randy Presuhn 1342 BMC Software, Inc. 1343 2141 North First Street 1344 San Jose, CA 95131 1345 USA 1347 Phone: +1 408 546 1006 1348 EMail: randy_presuhn@bmc.com 1350 10. Changes from RFC 1905 1352 These are the changes from RFC 1905: 1354 - Corrected spelling error in copyright statement; 1356 - Updated copyright date; 1357 - Updated with new editor's name and contact information; 1359 - Added notice on intellectual property; 1361 - Cosmetic fixes to layout and typography; 1363 - Added table of contents; 1365 - Title changed; 1367 - Updated document headers and footers; 1369 - Deleted the old clause 2.3, entitled "Access to Management 1370 Information". 1372 - Changed the way in which request-id was defined, though 1373 with the same ultimate syntax and semantics, to avoid 1374 coupling with SMI. This does not affect the protocol in 1375 any way. 1377 - Replaced the word "exception" with the word "error" in the 1378 old clause 4.1. This does not affect the protocol in any 1379 way. 1381 - Deleted the first two paragraphs of the old clause 4.2. 1383 - Clarified the maximum number of variable bindings that an 1384 implementation must support in a PDU. This does not affect 1385 the protocol in any way. 1387 - Replaced occurrences of "SNMPv2 application" with 1388 "application". 1390 - Deleted three sentences in old clause 4.2.3 describing the 1391 handling of an impossible situation. This does not affect 1392 the protocol in any way. 1394 - Clarified the use of the SNMPv2-Trap-Pdu in the old clause 1395 4.2.6. This does not affect the protocol in any way. 1397 - Aligned description of the use of the InformRequest-Pdu in 1398 old clause 4.2.7 with the architecture. This does not 1399 affect the protocol in any way. 1401 - Updated references. 1403 - Re-wrote introduction clause. 1405 - Replaced manager/agent/SNMPv2 entity terminology with 1406 terminology from RFC 2571. This does not affect the 1407 protocol in any way. 1409 - Eliminated IMPORTS from the SMI, replaced with equivalent 1410 in-line ASN.1. This does not affect the protocol in any 1411 way. 1413 - Added notes calling attention to two different 1414 manifestations of reaching the end of a table in the table 1415 walk examples. 1417 - Added content to security considerations clause. 1419 - Updated ASN.1 comment on use of Report-PDU. This does not 1420 affect the protocol in any way. 1422 11. Issues 1424 This clause will be deleted when this material is published as an 1425 RFC. The issue labels are the same as those used in the on-line 1426 issues list at 1427 ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1905/index.html 1429 1905-1 Done; table of contents added. 1431 1905-2 Done; new title put in. 1433 1905-3 Done; new introduction clause put in. 1435 1905-4 Done; handled as part of 1905-3. 1437 1905-5 Done; clause deleted. 1439 1905-6 Done; clause deleted, terminology changed throughout 1440 the document. 1442 1905-7 Done; resolution was "no change". 1444 1905-8 Done; deleted the old clause 2.3. 1446 1905-9 Done; resolution was "no change". 1448 1905-10 Done; resolution was "no change". 1450 1905-11 Done; resolution was "no change". 1452 1905-12 Done; incorporated suggested text, fixed minor ASN.1 1453 problem. 1455 1905-13 Done; resolution was to change form (but not ultimate 1456 syntax or semantics) of definition of request-id 1457 element. 1459 1905-14 Done; resolution was "no change". 1461 1905-15 Done; ASN.1 comments lined up. 1463 1905-16 Done; resolution was "no change". 1465 1905-17 Done; changed "exception" to "error" in second 1466 paragraph of old clause 4.1. 1468 1905-18 Done; deleted first two paragraphs of old clause 4.2. 1470 1905-19 Done; resolution was "no change". 1472 1905-20 Done; replaced occurrences of "SNMPv2 application" 1473 with "application". 1475 1905-21 Done; though as a side-effect of issue 1905-6's 1476 resolution. 1478 1905-22 Done; clarifying notes added. 1480 1905-23 Done; deleted offending sentences. 1482 1905-24 Done; resolution was "no change". 1484 1905-25 Done; added note to example. 1486 1905-26 Done; resolution was "no change". 1488 1905-27 Done; resolution was "no change". 1490 1905-28 Done; replaced first paragraph of old clause 4.2.6. 1492 1905-29 Done; replaced first paragraph of old clause 4.2.7. 1494 1905-30 Done; added content to security considerations clause. 1496 1905-31 PARTIAL; references update; more work needed on 1497 acknowledgments. 1499 1905-32 Done; added clarifying text. 1501 1905-33 Done; IPR and copyright material updated. 1503 1905-34 Done; headers and footers updated appropriately. 1505 1905-35 Done; resolution was "no change". 1507 1905-36 Done; though original resolution was "no change", this 1508 was effectively superseded by the resolution to 1509 1905-12. 1511 1905-37 Done; resolution was "no change". 1513 12. Full Copyright Statement 1515 Copyright (C) The Internet Society (2000). All Rights Reserved. 1517 This document and translations of it may be copied and furnished to 1518 others, and derivative works that comment on or otherwise explain it 1519 or assist in its implementation may be prepared, copied, published 1520 and distributed, in whole or in part, without restriction of any 1521 kind, provided that the above copyright notice and this paragraph are 1522 included on all such copies and derivative works. However, this 1523 document itself may not be modified in any way, such as by removing 1524 the copyright notice or references to the Internet Society or other 1525 Internet organizations, except as needed for the purpose of 1526 developing Internet standards in which case the procedures for 1527 copyrights defined in the Internet Standards process must be 1528 followed, or as required to translate it into languages other than 1529 English. 1531 The limited permissions granted above are perpetual and will not be 1532 revoked by the Internet Society or its successors or assigns. 1534 This document and the information contained herein is provided on an 1535 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1536 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1537 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1538 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1539 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.