idnits 2.17.1 draft-ietf-snmpv3-update-proto-07.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. 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 31 instances of too long lines in the document, the longest one being 2 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 601 has weird spacing: '...ield is set...' == Line 1206 has weird spacing: '... The previo...' -- 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 (3 October 2001) is 8212 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 288, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 290, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 292, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 296, but not defined == Missing Reference: 'APPLICATION 4' is mentioned on line 298, but not defined == Missing Reference: 'APPLICATION 6' is mentioned on line 300, but not defined -- Looks like a reference, but probably isn't: '0' on line 439 -- Looks like a reference, but probably isn't: '1' on line 442 -- Looks like a reference, but probably isn't: '2' on line 445 -- Looks like a reference, but probably isn't: '3' on line 347 -- Looks like a reference, but probably isn't: '4' on line 350 -- Looks like a reference, but probably isn't: '5' on line 353 -- Looks like a reference, but probably isn't: '6' on line 357 -- Looks like a reference, but probably isn't: '7' on line 361 -- Looks like a reference, but probably isn't: '8' on line 368 == Missing Reference: 'RFC-COEX' is mentioned on line 917, but not defined == Unused Reference: 'ASN1' is defined on line 1274, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 1329, 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' ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TMM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-MIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ARC' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-MPD' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-APL' ** Obsolete normative reference: RFC 2574 (ref. 'RFC-USM') (Obsoleted by RFC 3414) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ACM' Summary: 10 errors (**), 0 flaws (~~), 14 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor of this version: 3 Request for Comments: -PRO R. Presuhn 4 STD: XXX BMC Software, Inc. 5 Obsoletes: 1905 Authors of previous version: 6 Category: Standards Track J. Case 7 SNMP Research, Inc. 8 K. McCloghrie 9 Cisco Systems, Inc. 10 M. Rose 11 Dover Beach Consulting, Inc. 12 S. Waldbusser 13 International Network Services 14 3 October 2001 16 Version 2 of the Protocol Operations for 17 the Simple Network Management Protocol 18 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright Notice 41 Copyright (C) The Internet Society (2001). All Rights Reserved. 43 Abstract 45 This document defines version 2 of the protocol operations for the 46 Simple Network Management Protocol (SNMP). This document obsoletes 47 RFC 1905. It defines the syntax and elements of procedure for 48 sending, receiving, and processing SNMP PDUs. 50 Table of Contents 52 1. Introduction ................................................ 3 53 2. Overview .................................................... 4 54 2.1. Management Information .................................... 4 55 2.2. Retransmission of Requests ................................ 4 56 2.3. Message Sizes ............................................. 4 57 2.4. Transport Mappings ........................................ 5 58 2.5. SMIv2 Data Type Mappings .................................. 5 59 3. Definitions ................................................. 6 60 4. Protocol Specification ...................................... 11 61 4.1. Common Constructs ......................................... 11 62 4.2. PDU Processing ............................................ 11 63 4.2.1. The GetRequest-PDU ...................................... 12 64 4.2.2. The GetNextRequest-PDU .................................. 13 65 4.2.2.1. Example of Table Traversal ............................ 14 66 4.2.3. The GetBulkRequest-PDU .................................. 16 67 4.2.3.1. Another Example of Table Traversal .................... 19 68 4.2.4. The Response-PDU ........................................ 20 69 4.2.5. The SetRequest-PDU ...................................... 21 70 4.2.6. The SNMPv2-Trap-PDU ..................................... 24 71 4.2.7. The InformRequest-PDU ................................... 24 72 5. Notice on Intellectual Property ............................. 25 73 6. Acknowledgments ............................................. 26 74 7. Security Considerations ..................................... 27 75 8. References .................................................. 28 76 9. Editor's Address ............................................ 30 77 10. Changes from RFC 1905 ...................................... 30 78 11. Issues ..................................................... 32 79 12. Full Copyright Statement ................................... 34 81 1. Introduction 83 The SNMP Management Framework at the time of this writing consists of 84 five major components: 86 - An overall architecture, described in RFC -ARC [RFC-ARC]. 88 - Mechanisms for describing and naming objects and events for 89 the purpose of management. The first version of this 90 Structure of Management Information (SMI) is called SMIv1 91 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 92 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, 93 called SMIv2, is described in STD 58, RFC 2578 [RFC2578], 94 STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 96 - Message protocols for transferring management information. 97 The first version of the SNMP message protocol is called 98 SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A 99 second version of the SNMP message protocol, which is not 100 an Internet standards track protocol, is called SNMPv2c and 101 described in RFC 1901 [RFC1901] and RFC -TMM [RFC-TMM]. 102 The third version of the message protocol is called SNMPv3 103 and described in RFC -TMM [RFC-TMM], RFC -MPD [RFC-MPD] and 104 RFC -USM [RFC-USM]. 106 - Protocol operations for accessing management information. 107 The first set of protocol operations and associated PDU 108 formats is described in STD 15, RFC 1157 [RFC1157]. A 109 second set of protocol operations and associated PDU 110 formats is described in this document. 112 - A set of fundamental applications described in RFC -APL 113 [RFC-APL] and the view-based access control mechanism 114 described in RFC -ACM [RFC-ACM]. 116 A more detailed introduction to the SNMP Management Framework at the 117 time of this writing can be found in RFC 2570 [RFC2570]. 119 Managed objects are accessed via a virtual information store, termed 120 the Management Information Base or MIB. Objects in the MIB are 121 defined using the mechanisms defined in the SMI. 123 This document, Version 2 of the Protocol Operations for the Simple 124 Network Management Protocol, defines the operations of the protocol 125 with respect to the sending and receiving of PDUs to be carried by 126 the message protocol. 128 2. Overview 130 SNMP entities supporting command generator or notification receiver 131 applications (traditionally called "managers") communicate with SNMP 132 entities supporting command responder or notification originator 133 applications (traditionally called "agents"). The purpose of this 134 protocol is the transport of management information and operations. 136 2.1. Management Information 138 The term "variable" refers to an instance of a non-aggregate object 139 type defined according to the conventions set forth in the SMI 140 [RFC2578] or the textual conventions based on the SMI [RFC2579]. The 141 term "variable binding" normally refers to the pairing of the name of 142 a variable and its associated value. However, if certain kinds of 143 exceptional conditions occur during processing of a retrieval 144 request, a variable binding will pair a name and an indication of 145 that exception. 147 A variable-binding list is a simple list of variable bindings. 149 The name of a variable is an OBJECT IDENTIFIER which is the 150 concatenation of the OBJECT IDENTIFIER of the corresponding 151 object-type together with an OBJECT IDENTIFIER fragment identifying 152 the instance. The OBJECT IDENTIFIER of the corresponding object-type 153 is called the OBJECT IDENTIFIER prefix of the variable. 155 2.2. Retransmission of Requests 157 For all types of request in this protocol, the receiver is required 158 under normal circumstances, to generate and transmit a response to 159 the originator of the request. Whether or not a request should be 160 retransmitted if no corresponding response is received in an 161 appropriate time interval, is at the discretion of the application 162 originating the request. This will normally depend on the urgency of 163 the request. However, such an application needs to act responsibly 164 in respect to the frequency and duration of re-transmissions. 166 2.3. Message Sizes 168 The maximum size of an SNMP message is limited to the minimum of: 170 (1) the maximum message size which the destination SNMP entity can 171 accept; and, 173 (2) the maximum message size which the source SNMP entity can 174 generate. 176 The former may be known on a per-recipient basis; and in the absence 177 of such knowledge, is indicated by transport domain used when sending 178 the message. The latter is imposed by implementation-specific local 179 constraints. 181 Each transport mapping for the SNMP indicates the minimum message 182 size which a SNMP implementation must be able to produce or consume. 183 Although implementations are encouraged to support larger values 184 whenever possible, a conformant implementation must never generate 185 messages larger than allowed by the receiving SNMP entity. 187 One of the aims of the GetBulkRequest-PDU, specified in this 188 protocol, is to minimize the number of protocol exchanges required to 189 retrieve a large amount of management information. As such, this PDU 190 type allows an SNMP entity supporting command generator applications 191 to request that the response be as large as possible given the 192 constraints on message sizes. These constraints include the limits 193 on the size of messages which the SNMP entity supporting command 194 responder applications can generate, and the SNMP entity supporting 195 command generator applications can receive. 197 However, it is possible that such maximum sized messages may be 198 larger than the Path MTU of the path across the network traversed by 199 the messages. In this situation, such messages are subject to 200 fragmentation. Fragmentation is generally considered to be harmful 201 [FRAG], since among other problems, it leads to a decrease in the 202 reliability of the transfer of the messages. Thus, an SNMP entity 203 which sends a GetBulkRequest-PDU must take care to set its parameters 204 accordingly, so as to reduce the risk of fragmentation. In 205 particular, under conditions of network stress, only small values 206 should be used for max-repetitions. 208 2.4. Transport Mappings 210 It is important to note that the exchange of SNMP messages requires 211 only an unreliable datagram service, with every message being 212 entirely and independently contained in a single transport datagram. 213 Specific transport mappings and encoding rules are specified 214 elsewhere [RFC-TMM]. However, the preferred mapping is the use of 215 the User Datagram Protocol [RFC768]. 217 2.5. SMIv2 Data Type Mappings 219 The SMIv2 [RFC2578] defines 11 base types (INTEGER, OCTET STRING, 220 OBJECT IDENTIFIER, Integer32, IpAddress, Counter32, Gauge32, 221 Unsigned32, TimeTicks, Opaque, Counter64) and the BITS construct. The 222 SMIv2 base types are mapped to the corresponding selection type in 223 the SimpleSyntax and ApplicationSyntax choices of the ASN.1 SNMP 224 protocol definition. Note that the INTEGER and Integer32 SMIv2 base 225 types are mapped to the integer-value selection type of the 226 SimpleSyntax choice. Similarly, the Gauge32 and Unsigned32 SMIv2 base 227 types are mapped to the unsigned-integer-value selection type of the 228 ApplicationSyntax choice. 230 The SMIv2 BITS construct is mapped to the string-value selection type 231 of the SimpleSyntax choice. A BITS value is encoded as an OCTET 232 STRING, in which all the named bits in (the definition of) the 233 bitstring, commencing with the first bit and proceeding to the last 234 bit, are placed in bits 8 (high order bit) to 1 (low order bit) of 235 the first octet, followed by bits 8 to 1 of each subsequent octet in 236 turn, followed by as many bits as are needed of the final subsequent 237 octet, commencing with bit 8. Remaining bits, if any, of the final 238 octet are set to zero on generation and ignored on receipt. 240 3. Definitions 242 SNMPv2-PDU DEFINITIONS ::= BEGIN 244 ObjectName ::= OBJECT IDENTIFIER ! 246 ObjectSyntax ::= ! 247 CHOICE { ! 248 simple ! 249 SimpleSyntax, ! 251 application-wide ! 252 ApplicationSyntax ! 253 } ! 255 SimpleSyntax ::= ! 256 CHOICE { ! 257 integer-value ! 258 INTEGER (-2147483648..2147483647), ! 260 string-value ! 261 OCTET STRING (SIZE (0..65535)), ! 263 objectID-value ! 264 OBJECT IDENTIFIER ! 265 } ! 267 ApplicationSyntax ::= 268 CHOICE { 269 ipAddress-value 270 IpAddress, 272 counter-value 273 Counter32, 275 timeticks-value 276 TimeTicks, 278 arbitrary-value 279 Opaque, 281 big-counter-value 282 Counter64, 284 unsigned-integer-value 285 Unsigned32 286 } 288 IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) ! 290 Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) ! 292 Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) ! 294 Gauge32 ::= Unsigned32 ! 296 TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) ! 298 Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING ! 300 Counter64 ::= [APPLICATION 6] ! 301 IMPLICIT INTEGER (0..18446744073709551615) ! 303 -- protocol data units 305 PDUs ::= 306 CHOICE { 307 get-request 308 GetRequest-PDU, 310 get-next-request 311 GetNextRequest-PDU, 313 get-bulk-request 314 GetBulkRequest-PDU, 316 response 317 Response-PDU, 319 set-request 320 SetRequest-PDU, 322 inform-request 323 InformRequest-PDU, 325 snmpV2-trap 326 SNMPv2-Trap-PDU, 328 report 329 Report-PDU ! 330 } 332 -- PDUs 334 GetRequest-PDU ::= 335 [0] 336 IMPLICIT PDU 338 GetNextRequest-PDU ::= 339 [1] 340 IMPLICIT PDU 342 Response-PDU ::= 343 [2] 344 IMPLICIT PDU 346 SetRequest-PDU ::= 347 [3] 348 IMPLICIT PDU 350 -- [4] is obsolete 352 GetBulkRequest-PDU ::= 353 [5] 354 IMPLICIT BulkPDU 356 InformRequest-PDU ::= 357 [6] 358 IMPLICIT PDU 360 SNMPv2-Trap-PDU ::= 361 [7] 362 IMPLICIT PDU 364 -- Usage and precise semantics of Report-PDU are not defined 365 -- in this document. Any SNMP administrative framework making 366 -- use of this PDU must define its usage and semantics. 367 Report-PDU ::= 368 [8] 369 IMPLICIT PDU 371 max-bindings 372 INTEGER ::= 2147483647 374 PDU ::= 375 SEQUENCE { 376 request-id 377 INTEGER (-214783648..214783647), ! 379 error-status -- sometimes ignored 380 INTEGER { 381 noError(0), 382 tooBig(1), 383 noSuchName(2), -- for proxy compatibility 384 badValue(3), -- for proxy compatibility 385 readOnly(4), -- for proxy compatibility 386 genErr(5), 387 noAccess(6), 388 wrongType(7), 389 wrongLength(8), 390 wrongEncoding(9), 391 wrongValue(10), 392 noCreation(11), 393 inconsistentValue(12), 394 resourceUnavailable(13), 395 commitFailed(14), 396 undoFailed(15), 397 authorizationError(16), 398 notWritable(17), 399 inconsistentName(18) 400 }, 402 error-index -- sometimes ignored 403 INTEGER (0..max-bindings), 405 variable-bindings -- values are sometimes ignored 406 VarBindList 407 } 409 BulkPDU ::= -- must be identical in 410 SEQUENCE { -- structure to PDU 411 request-id 412 INTEGER (-214783648..214783647), ! 414 non-repeaters 415 INTEGER (0..max-bindings), 417 max-repetitions 418 INTEGER (0..max-bindings), 420 variable-bindings -- values are ignored 421 VarBindList 422 } 424 -- variable binding 426 VarBind ::= 427 SEQUENCE { 428 name 429 ObjectName, 431 CHOICE { 432 value 433 ObjectSyntax, 435 unSpecified -- in retrieval requests 436 NULL, 438 -- exceptions in responses 439 noSuchObject[0] 440 IMPLICIT NULL, 442 noSuchInstance[1] 443 IMPLICIT NULL, 445 endOfMibView[2] 446 IMPLICIT NULL 447 } 448 } 450 -- variable-binding list 452 VarBindList ::= 453 SEQUENCE (SIZE (0..max-bindings)) OF 454 VarBind 456 END 458 4. Protocol Specification 460 4.1. Common Constructs 462 The value of the request-id field in a Response-PDU takes the value 463 of the request-id field in the request PDU to which it is a response. 464 By use of the request-id value, an application can distinguish the 465 (potentially multiple) outstanding requests, and thereby correlate 466 incoming responses with outstanding requests. In cases where an 467 unreliable datagram service is used, the request-id also provides a 468 simple means of identifying messages duplicated by the network. Use 469 of the same request-id on a retransmission of a request allows the 470 response to either the original transmission or the retransmission to 471 satisfy the request. However, in order to calculate the round trip 472 time for transmission and processing of a request-response 473 transaction, the application needs to use a different request-id 474 value on a retransmitted request. The latter strategy is recommended 475 for use in the majority of situations. 477 A non-zero value of the error-status field in a Response-PDU is used 478 to indicate that an error occurred to prevent the processing of the 479 request. In these cases, a non-zero value of the Response-PDU's 480 error-index field provides additional information by identifying 481 which variable binding in the list caused the error. A variable 482 binding is identified by its index value. The first variable binding 483 in a variable-binding list is index one, the second is index two, 484 etc. 486 SNMP limits OBJECT IDENTIFIER values to a maximum of 128 487 sub-identifiers, where each sub-identifier has a maximum value of 488 2**32-1. 490 4.2. PDU Processing 492 In the elements of procedure below, any field of a PDU which is not 493 referenced by the relevant procedure is ignored by the receiving SNMP 494 entity. However, all components of a PDU, including those whose 495 values are ignored by the receiving SNMP entity, must have valid 496 ASN.1 syntax and encoding. For example, some PDUs (e.g., the 497 GetRequest-PDU) are concerned only with the name of a variable and 498 not its value. In this case, the value portion of the variable 499 binding is ignored by the receiving SNMP entity. The unSpecified 500 value is defined for use as the value portion of such bindings. 502 On generating a management communication, the message "wrapper" to 503 encapsulate the PDU is generated according to the "Elements of 504 Procedure" of the administrative framework in use. The definition of 505 "max-bindings" imposes an upper bound on the number of variable 506 bindings. In practice, the size of a message is also limited by 507 constraints on the maximum message size. A compliant implementation 508 must support as many variable bindings in a PDU or BulkPDU as fit 509 into the overall maximum message size limit of the SNMP engine, but 510 no more than 2147483647 variable bindings. 512 On receiving a management communication, the "Elements of Procedure" 513 of the administrative framework in use is followed, and if those 514 procedures indicate that the operation contained within the message 515 is to be performed locally, then those procedures also indicate the 516 MIB view which is visible to the operation. 518 4.2.1. The GetRequest-PDU 520 A GetRequest-PDU is generated and transmitted at the request of an 521 application. 523 Upon receipt of a GetRequest-PDU, the receiving SNMP entity processes 524 each variable binding in the variable-binding list to produce a 525 Response-PDU. All fields of the Response-PDU have the same values as 526 the corresponding fields of the received request except as indicated 527 below. Each variable binding is processed as follows: 529 (1) If the variable binding's name exactly matches the name of a 530 variable accessible by this request, then the variable binding's 531 value field is set to the value of the named variable. 533 (2) Otherwise, if the variable binding's name does not have an 534 OBJECT IDENTIFIER prefix which exactly matches the OBJECT 535 IDENTIFIER prefix of any (potential) variable accessible by this 536 request, then its value field is set to "noSuchObject". 538 (3) Otherwise, the variable binding's value field is set to 539 "noSuchInstance". 541 If the processing of any variable binding fails for a reason other 542 than listed above, then the Response-PDU is re-formatted with the 543 same values in its request-id and variable-bindings fields as the 544 received GetRequest-PDU, with the value of its error-status field set 545 to "genErr", and the value of its error-index field is set to the 546 index of the failed variable binding. 548 Otherwise, the value of the Response-PDU's error-status field is set 549 to "noError", and the value of its error-index field is zero. 551 The generated Response-PDU is then encapsulated into a message. If 552 the size of the resultant message is less than or equal to both a 553 local constraint and the maximum message size of the originator, it 554 is transmitted to the originator of the GetRequest-PDU. 556 Otherwise, an alternate Response-PDU is generated. This alternate 557 Response-PDU is formatted with the same value in its request-id field 558 as the received GetRequest-PDU, with the value of its error-status 559 field set to "tooBig", the value of its error-index field set to 560 zero, and an empty variable-bindings field. This alternate 561 Response-PDU is then encapsulated into a message. If the size of the 562 resultant message is less than or equal to both a local constraint 563 and the maximum message size of the originator, it is transmitted to 564 the originator of the GetRequest-PDU. Otherwise, the snmpSilentDrops 565 [RFC-MIB] counter is incremented and the resultant message is 566 discarded. 568 4.2.2. The GetNextRequest-PDU 570 A GetNextRequest-PDU is generated and transmitted at the request of 571 an application. 573 Upon receipt of a GetNextRequest-PDU, the receiving SNMP entity 574 processes each variable binding in the variable-binding list to 575 produce a Response-PDU. All fields of the Response-PDU have the same 576 values as the corresponding fields of the received request except as 577 indicated below. Each variable binding is processed as follows: 579 (1) The variable is located which is in the lexicographically 580 ordered list of the names of all variables which are accessible 581 by this request and whose name is the first lexicographic 582 successor of the variable binding's name in the incoming 583 GetNextRequest-PDU. The corresponding variable binding's name 584 and value fields in the Response-PDU are set to the name and 585 value of the located variable. 587 (2) If the requested variable binding's name does not 588 lexicographically precede the name of any variable accessible by 589 this request, i.e., there is no lexicographic successor, then 590 the corresponding variable binding produced in the Response-PDU 591 has its value field set to "endOfMibView", and its name field 592 set to the variable binding's name in the request. 594 If the processing of any variable binding fails for a reason other 595 than listed above, then the Response-PDU is re-formatted with the 596 same values in its request-id and variable-bindings fields as the 597 received GetNextRequest-PDU, with the value of its error-status field 598 set to "genErr", and the value of its error-index field is set to the 599 index of the failed variable binding. 601 Otherwise, the value of the Response-PDU's error-status field is set 602 to "noError", and the value of its error-index field is zero. 604 The generated Response-PDU is then encapsulated into a message. If 605 the size of the resultant message is less than or equal to both a 606 local constraint and the maximum message size of the originator, it 607 is transmitted to the originator of the GetNextRequest-PDU. 609 Otherwise, an alternate Response-PDU is generated. This alternate 610 Response-PDU is formatted with the same values in its request-id 611 field as the received GetNextRequest-PDU, with the value of its 612 error-status field set to "tooBig", the value of its error-index 613 field set to zero, and an empty variable-bindings field. This 614 alternate Response-PDU is then encapsulated into a message. If the 615 size of the resultant message is less than or equal to both a local 616 constraint and the maximum message size of the originator, it is 617 transmitted to the originator of the GetNextRequest-PDU. Otherwise, 618 the snmpSilentDrops [RFC-MIB] counter is incremented and the 619 resultant message is discarded. 621 4.2.2.1. Example of Table Traversal 623 An important use of the GetNextRequest-PDU is the traversal of 624 conceptual tables of information within a MIB. The semantics of this 625 type of request, together with the method of identifying individual 626 instances of objects in the MIB, provides access to related objects 627 in the MIB as if they enjoyed a tabular organization. 629 In the protocol exchange sketched below, an application retrieves the 630 media-dependent physical address and the address-mapping type for 631 each entry in the IP net-to-media Address Translation Table [RFC1213] 632 of a particular network element. It also retrieves the value of 633 sysUpTime [RFC-MIB], at which the mappings existed. Suppose that the 634 command responder's IP net-to-media table has three entries: 635 Interface-Number Network-Address Physical-Address Type 637 1 10.0.0.51 00:00:10:01:23:45 static 638 1 9.2.3.4 00:00:10:54:32:10 dynamic 639 2 10.0.0.15 00:00:10:98:76:54 dynamic 641 The SNMP entity supporting a command generator application begins by 642 sending a GetNextRequest-PDU containing the indicated OBJECT 643 IDENTIFIER values as the requested variable names: 645 GetNextRequest ( sysUpTime, 646 ipNetToMediaPhysAddress, 647 ipNetToMediaType ) 649 The SNMP entity supporting a command responder application responds 650 with a Response-PDU: 652 Response (( sysUpTime.0 = "123456" ), 653 ( ipNetToMediaPhysAddress.1.9.2.3.4 = 654 "000010543210" ), 655 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" )) 657 The SNMP entity supporting the command generator application 658 continues with: 660 GetNextRequest ( sysUpTime, 661 ipNetToMediaPhysAddress.1.9.2.3.4, 662 ipNetToMediaType.1.9.2.3.4 ) 664 The SNMP entity supporting the command responder application responds 665 with: 667 Response (( sysUpTime.0 = "123461" ), 668 ( ipNetToMediaPhysAddress.1.10.0.0.51 = 669 "000010012345" ), 670 ( ipNetToMediaType.1.10.0.0.51 = "static" )) 672 The SNMP entity supporting the command generator application 673 continues with: 675 GetNextRequest ( sysUpTime, 676 ipNetToMediaPhysAddress.1.10.0.0.51, 677 ipNetToMediaType.1.10.0.0.51 ) 679 The SNMP entity supporting the command responder application responds 680 with: 682 Response (( sysUpTime.0 = "123466" ), 683 ( ipNetToMediaPhysAddress.2.10.0.0.15 = 684 "000010987654" ), 685 ( ipNetToMediaType.2.10.0.0.15 = "dynamic" )) 687 The SNMP entity supporting the command generator application 688 continues with: 690 GetNextRequest ( sysUpTime, 691 ipNetToMediaPhysAddress.2.10.0.0.15, 692 ipNetToMediaType.2.10.0.0.15 ) 694 As there are no further entries in the table, the SNMP entity 695 supporting the command responder application responds with the 696 variables that are next in the lexicographical ordering of the 697 accessible object names, for example: 699 Response (( sysUpTime.0 = "123471" ), 700 ( ipNetToMediaNetAddress.1.9.2.3.4 = 701 "9.2.3.4" ), 702 ( ipRoutingDiscards.0 = "2" )) 704 Note how, having reached the end of the column for 705 ipNetToMediaPhysAddress, the second variable binding from the command 706 responder application has now "wrapped" to the first row in the next 707 column. Furthermore, note how, having reached the end of the 708 ipNetToMediaTable for the third variable binding, the command 709 responder application has responded with the next available object, 710 which is outside that table. This response signals the end of the 711 table to the command generator application. 713 4.2.3. The GetBulkRequest-PDU 715 A GetBulkRequest-PDU is generated and transmitted at the request of 716 an application. The purpose of the GetBulkRequest-PDU is to request 717 the transfer of a potentially large amount of data, including, but 718 not limited to, the efficient and rapid retrieval of large tables. 720 Upon receipt of a GetBulkRequest-PDU, the receiving SNMP entity 721 processes each variable binding in the variable-binding list to 722 produce a Response-PDU with its request-id field having the same 723 value as in the request. 725 For the GetBulkRequest-PDU type, the successful processing of each 726 variable binding in the request generates zero or more variable 727 bindings in the Response-PDU. That is, the one-to-one mapping 728 between the variable bindings of the GetRequest-PDU, 729 GetNextRequest-PDU, and SetRequest-PDU types and the resultant 730 Response-PDUs does not apply for the mapping between the variable 731 bindings of a GetBulkRequest-PDU and the resultant Response-PDU. 733 The values of the non-repeaters and max-repetitions fields in the 734 request specify the processing requested. One variable binding in 735 the Response-PDU is requested for the first N variable bindings in 736 the request and M variable bindings are requested for each of the R 737 remaining variable bindings in the request. Consequently, the total 738 number of requested variable bindings communicated by the request is 739 given by N + (M * R), where N is the minimum of: a) the value of the 740 non-repeaters field in the request, and b) the number of variable 741 bindings in the request; M is the value of the max-repetitions field 742 in the request; and R is the maximum of: a) number of variable 743 bindings in the request - N, and b) zero. 745 The receiving SNMP entity produces a Response-PDU with up to the 746 total number of requested variable bindings communicated by the 747 request. The request-id shall have the same value as the received 748 GetBulkRequest-PDU. 750 If N is greater than zero, the first through the (N)-th variable 751 bindings of the Response-PDU are each produced as follows: 753 (1) The variable is located which is in the lexicographically 754 ordered list of the names of all variables which are accessible 755 by this request and whose name is the first lexicographic 756 successor of the variable binding's name in the incoming 757 GetBulkRequest-PDU. The corresponding variable binding's name 758 and value fields in the Response-PDU are set to the name and 759 value of the located variable. 761 (2) If the requested variable binding's name does not 762 lexicographically precede the name of any variable accessible by 763 this request, i.e., there is no lexicographic successor, then 764 the corresponding variable binding produced in the Response-PDU 765 has its value field set to "endOfMibView", and its name field 766 set to the variable binding's name in the request. 768 If M and R are non-zero, the (N + 1)-th and subsequent variable 769 bindings of the Response-PDU are each produced in a similar manner. 770 For each iteration i, such that i is greater than zero and less than 771 or equal to M, and for each repeated variable, r, such that r is 772 greater than zero and less than or equal to R, the (N + ( (i-1) * R ) 773 + r)-th variable binding of the Response-PDU is produced as follows: 775 (1) The variable which is in the lexicographically ordered list of 776 the names of all variables which are accessible by this request 777 and whose name is the (i)-th lexicographic successor of the (N + 778 r)-th variable binding's name in the incoming GetBulkRequest-PDU 779 is located and the variable binding's name and value fields are 780 set to the name and value of the located variable. 782 (2) If there is no (i)-th lexicographic successor, then the 783 corresponding variable binding produced in the Response-PDU has 784 its value field set to "endOfMibView", and its name field set to 785 either the last lexicographic successor, or if there are no 786 lexicographic successors, to the (N + r)-th variable binding's 787 name in the request. 789 While the maximum number of variable bindings in the Response-PDU is 790 bounded by N + (M * R), the response may be generated with a lesser 791 number of variable bindings (possibly zero) for either of three 792 reasons. 794 (1) If the size of the message encapsulating the Response-PDU 795 containing the requested number of variable bindings would be 796 greater than either a local constraint or the maximum message 797 size of the originator, then the response is generated with a 798 lesser number of variable bindings. This lesser number is the 799 ordered set of variable bindings with some of the variable 800 bindings at the end of the set removed, such that the size of 801 the message encapsulating the Response-PDU is approximately 802 equal to but no greater than either a local constraint or the 803 maximum message size of the originator. Note that the number of 804 variable bindings removed has no relationship to the values of 805 N, M, or R. 807 (2) The response may also be generated with a lesser number of 808 variable bindings if for some value of iteration i, such that i 809 is greater than zero and less than or equal to M, that all of 810 the generated variable bindings have the value field set to 811 "endOfMibView". In this case, the variable bindings may be 812 truncated after the (N + (i * R))-th variable binding. 814 (3) In the event that the processing of a request with many 815 repetitions requires a significantly greater amount of 816 processing time than a normal request, then a command responder 817 application may terminate the request with less than the full 818 number of repetitions, providing at least one repetition is 819 completed. 821 If the processing of any variable binding fails for a reason other 822 than listed above, then the Response-PDU is re-formatted with the 823 same values in its request-id and variable-bindings fields as the 824 received GetBulkRequest-PDU, with the value of its error-status field 825 set to "genErr", and the value of its error-index field is set to the 826 index of the variable binding in the original request which 827 corresponds to the failed variable binding. 829 Otherwise, the value of the Response-PDU's error-status field is set 830 to "noError", and the value of its error-index field to zero. 832 The generated Response-PDU (possibly with an empty variable-bindings 833 field) is then encapsulated into a message. If the size of the 834 resultant message is less than or equal to both a local constraint 835 and the maximum message size of the originator, it is transmitted to 836 the originator of the GetBulkRequest-PDU. Otherwise, the 837 snmpSilentDrops [RFC-MIB] counter is incremented and the resultant 838 message is discarded. 840 4.2.3.1. Another Example of Table Traversal 842 This example demonstrates how the GetBulkRequest-PDU can be used as 843 an alternative to the GetNextRequest-PDU. The same traversal of the 844 IP net-to-media table as shown in Section 4.2.2.1 is achieved with 845 fewer exchanges. 847 The SNMP entity supporting the command generator application begins 848 by sending a GetBulkRequest-PDU with the modest max-repetitions value 849 of 2, and containing the indicated OBJECT IDENTIFIER values as the 850 requested variable names: 852 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] 853 ( sysUpTime, 854 ipNetToMediaPhysAddress, 855 ipNetToMediaType ) 857 The SNMP entity supporting the command responder application responds 858 with a Response-PDU: 860 Response (( sysUpTime.0 = "123456" ), 861 ( ipNetToMediaPhysAddress.1.9.2.3.4 = 862 "000010543210" ), 863 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ), 864 ( ipNetToMediaPhysAddress.1.10.0.0.51 = 865 "000010012345" ), 866 ( ipNetToMediaType.1.10.0.0.51 = "static" )) 868 The SNMP entity supporting the command generator application 869 continues with: 871 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] 872 ( sysUpTime, 873 ipNetToMediaPhysAddress.1.10.0.0.51, 874 ipNetToMediaType.1.10.0.0.51 ) 876 The SNMP entity supporting the command responder application responds 877 with: 879 Response (( sysUpTime.0 = "123466" ), 880 ( ipNetToMediaPhysAddress.2.10.0.0.15 = 881 "000010987654" ), 882 ( ipNetToMediaType.2.10.0.0.15 = 883 "dynamic" ), 884 ( ipNetToMediaNetAddress.1.9.2.3.4 = 885 "9.2.3.4" ), 886 ( ipRoutingDiscards.0 = "2" )) 888 Note how, as in the first example, the variable bindings in the 889 response indicate that the end of the table has been reached. The 890 fourth variable binding does so by returning information from the 891 next available column; the fifth variable binding does so by 892 returning information from the first available object 893 lexicographically following the table. This response signals the end 894 of the table to the command generator application. 896 4.2.4. The Response-PDU 898 The Response-PDU is generated by an SNMP entity only upon receipt of 899 a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, 900 SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this 901 document. 903 If the error-status field of the Response-PDU is non-zero, the value 904 fields of the variable bindings in the variable binding list are 905 ignored. 907 If both the error-status field and the error-index field of the 908 Response-PDU are non-zero, then the value of the error-index field is 909 the index of the variable binding (in the variable-binding list of 910 the corresponding request) for which the request failed. The first 911 variable binding in a request's variable-binding list is index one, 912 the second is index two, etc. 914 A compliant SNMP entity supporting a command generator application 915 must be able to properly receive and handle a Response-PDU with an 916 error-status field equal to "noSuchName", "badValue", or "readOnly". 917 (See sections 1.3 and 4.3 of [RFC-COEX].) 919 Upon receipt of a Response-PDU, the receiving SNMP entity presents 920 its contents to the application which generated the request with the 921 same request-id value. For more details, see [RFC-MPD]. 923 4.2.5. The SetRequest-PDU 925 A SetRequest-PDU is generated and transmitted at the request of an 926 application. 928 Upon receipt of a SetRequest-PDU, the receiving SNMP entity 929 determines the size of a message encapsulating a Response-PDU having 930 the same values in its request-id and variable-bindings fields as the 931 received SetRequest-PDU, and the largest possible sizes of the 932 error-status and error-index fields. If the determined message size 933 is greater than either a local constraint or the maximum message size 934 of the originator, then an alternate Response-PDU is generated, 935 transmitted to the originator of the SetRequest-PDU, and processing 936 of the SetRequest-PDU terminates immediately thereafter. This 937 alternate Response-PDU is formatted with the same values in its 938 request-id field as the received SetRequest-PDU, with the value of 939 its error-status field set to "tooBig", the value of its error-index 940 field set to zero, and an empty variable-bindings field. This 941 alternate Response-PDU is then encapsulated into a message. If the 942 size of the resultant message is less than or equal to both a local 943 constraint and the maximum message size of the originator, it is 944 transmitted to the originator of the SetRequest-PDU. Otherwise, the 945 snmpSilentDrops [RFC-MIB] counter is incremented and the resultant 946 message is discarded. Regardless, processing of the SetRequest-PDU 947 terminates. 949 Otherwise, the receiving SNMP entity processes each variable binding 950 in the variable-binding list to produce a Response-PDU. All fields 951 of the Response-PDU have the same values as the corresponding fields 952 of the received request except as indicated below. 954 The variable bindings are conceptually processed as a two phase 955 operation. In the first phase, each variable binding is validated; 956 if all validations are successful, then each variable is altered in 957 the second phase. Of course, implementors are at liberty to 958 implement either the first, or second, or both, of these conceptual 959 phases as multiple implementation phases. Indeed, such multiple 960 implementation phases may be necessary in some cases to ensure 961 consistency. 963 The following validations are performed in the first phase on each 964 variable binding until they are all successful, or until one fails: 966 (1) If the variable binding's name specifies an existing or 967 non-existent variable to which this request is/would be denied 968 access because it is/would not be in the appropriate MIB view, 969 then the value of the Response-PDU's error-status field is set 970 to "noAccess", and the value of its error-index field is set to 971 the index of the failed variable binding. 973 (2) Otherwise, if there are no variables which share the same OBJECT 974 IDENTIFIER prefix as the variable binding's name, and which are 975 able to be created or modified no matter what new value is 976 specified, then the value of the Response-PDU's error-status 977 field is set to "notWritable", and the value of its error-index 978 field is set to the index of the failed variable binding. 980 (3) Otherwise, if the variable binding's value field specifies, 981 according to the ASN.1 language, a type which is inconsistent 982 with that required for all variables which share the same OBJECT 983 IDENTIFIER prefix as the variable binding's name, then the value 984 of the Response-PDU's error-status field is set to "wrongType", 985 and the value of its error-index field is set to the index of 986 the failed variable binding. 988 (4) Otherwise, if the variable binding's value field specifies, 989 according to the ASN.1 language, a length which is inconsistent 990 with that required for all variables which share the same OBJECT 991 IDENTIFIER prefix as the variable binding's name, then the value 992 of the Response-PDU's error-status field is set to 993 "wrongLength", and the value of its error-index field is set to 994 the index of the failed variable binding. 996 (5) Otherwise, if the variable binding's value field contains an 997 ASN.1 encoding which is inconsistent with that field's ASN.1 998 tag, then the value of the Response-PDU's error-status field is 999 set to "wrongEncoding", and the value of its error-index field 1000 is set to the index of the failed variable binding. (Note that 1001 not all implementation strategies will generate this error.) 1003 (6) Otherwise, if the variable binding's value field specifies a 1004 value which could under no circumstances be assigned to the 1005 variable, then the value of the Response-PDU's error-status 1006 field is set to "wrongValue", and the value of its error-index 1007 field is set to the index of the failed variable binding. 1009 (7) Otherwise, if the variable binding's name specifies a variable 1010 which does not exist and could not ever be created (even though 1011 some variables sharing the same OBJECT IDENTIFIER prefix might 1012 under some circumstances be able to be created), then the value 1013 of the Response-PDU's error-status field is set to "noCreation", 1014 and the value of its error-index field is set to the index of 1015 the failed variable binding. 1017 (8) Otherwise, if the variable binding's name specifies a variable 1018 which does not exist but can not be created under the present 1019 circumstances (even though it could be created under other 1020 circumstances), then the value of the Response-PDU's 1021 error-status field is set to "inconsistentName", and the value 1022 of its error-index field is set to the index of the failed 1023 variable binding. 1025 (9) Otherwise, if the variable binding's name specifies a variable 1026 which exists but can not be modified no matter what new value is 1027 specified, then the value of the Response-PDU's error-status 1028 field is set to "notWritable", and the value of its error-index 1029 field is set to the index of the failed variable binding. 1031 (10) Otherwise, if the variable binding's value field specifies a 1032 value that could under other circumstances be held by the 1033 variable, but is presently inconsistent or otherwise unable to 1034 be assigned to the variable, then the value of the 1035 Response-PDU's error-status field is set to "inconsistentValue", 1036 and the value of its error-index field is set to the index of 1037 the failed variable binding. 1039 (11) When, during the above steps, the assignment of the value 1040 specified by the variable binding's value field to the specified 1041 variable requires the allocation of a resource which is 1042 presently unavailable, then the value of the Response-PDU's 1043 error-status field is set to "resourceUnavailable", and the 1044 value of its error-index field is set to the index of the failed 1045 variable binding. 1047 (12) If the processing of the variable binding fails for a reason 1048 other than listed above, then the value of the Response-PDU's 1049 error-status field is set to "genErr", and the value of its 1050 error-index field is set to the index of the failed variable 1051 binding. 1053 (13) Otherwise, the validation of the variable binding succeeds. 1055 At the end of the first phase, if the validation of all variable 1056 bindings succeeded, then the value of the Response-PDU's error-status 1057 field is set to "noError" and the value of its error-index field is 1058 zero, and processing continues as follows. 1060 For each variable binding in the request, the named variable is 1061 created if necessary, and the specified value is assigned to it. 1062 Each of these variable assignments occurs as if simultaneously with 1063 respect to all other assignments specified in the same request. 1064 However, if the same variable is named more than once in a single 1065 request, with different associated values, then the actual assignment 1066 made to that variable is implementation-specific. 1068 If any of these assignments fail (even after all the previous 1069 validations), then all other assignments are undone, and the 1070 Response-PDU is modified to have the value of its error-status field 1071 set to "commitFailed", and the value of its error-index field set to 1072 the index of the failed variable binding. 1074 If and only if it is not possible to undo all the assignments, then 1075 the Response-PDU is modified to have the value of its error-status 1076 field set to "undoFailed", and the value of its error-index field is 1077 set to zero. Note that implementations are strongly encouraged to 1078 take all possible measures to avoid use of either "commitFailed" or 1079 "undoFailed" - these two error-status codes are not to be taken as 1080 license to take the easy way out in an implementation. 1082 Finally, the generated Response-PDU is encapsulated into a message, 1083 and transmitted to the originator of the SetRequest-PDU. 1085 4.2.6. The SNMPv2-Trap-PDU 1087 An SNMPv2-Trap-PDU is generated and transmitted by an SNMP entity on 1088 behalf of a notification originator application. The SNMPv2-Trap-PDU 1089 is often used to notify a notification receiver application at a 1090 logically remote SNMP entity that an event has occurred or that a 1091 condition is present. There is no confirmation associated with this 1092 notification delivery mechanism. 1094 The destination(s) to which an SNMPv2-Trap-PDU is sent is determined 1095 in an implementation-dependent fashion by the SNMP entity. The first 1096 two variable bindings in the variable binding list of an 1097 SNMPv2-Trap-PDU are sysUpTime.0 [RFC-MIB] and snmpTrapOID.0 [RFC-MIB] 1098 respectively. If the OBJECTS clause is present in the invocation of 1099 the corresponding NOTIFICATION-TYPE macro, then each corresponding 1100 variable, as instantiated by this notification, is copied, in order, 1101 to the variable-bindings field. If any additional variables are 1102 being included (at the option of the generating SNMP entity), then 1103 each is copied to the variable-bindings field. 1105 4.2.7. The InformRequest-PDU 1107 An InformRequest-PDU is generated and transmitted by an SNMP entity 1108 on behalf of a notification originator application. The 1109 InformRequest-PDU is often used to notify a notification receiver 1110 application that an event has occurred or that a condition is 1111 present. This is a confirmed notification delivery mechanism, 1112 although there is, of course, no guarantee of delivery. 1114 The destination(s) to which an InformRequest-PDU is sent is specified 1115 by the notification originator application. The first two variable 1116 bindings in the variable binding list of an InformRequest-PDU are 1117 sysUpTime.0 [RFC-MIB] and snmpTrapOID.0 [RFC-MIB] respectively. If 1118 the OBJECTS clause is present in the invocation of the corresponding 1119 NOTIFICATION-TYPE macro, then each corresponding variable, as 1120 instantiated by this notification, is copied, in order, to the 1121 variable-bindings field. If any additional variables are being 1122 included (at the option of the generating SNMP entity), then each is 1123 copied to the variable-bindings field. 1125 Upon receipt of an InformRequest-PDU, the receiving SNMP entity 1126 determines the size of a message encapsulating a Response-PDU with 1127 the same values in its request-id, error-status, error-index and 1128 variable-bindings fields as the received InformRequest-PDU. If the 1129 determined message size is greater than either a local constraint or 1130 the maximum message size of the originator, then an alternate 1131 Response-PDU is generated, transmitted to the originator of the 1132 InformRequest-PDU, and processing of the InformRequest-PDU terminates 1133 immediately thereafter. This alternate Response-PDU is formatted 1134 with the same values in its request-id field as the received 1135 InformRequest-PDU, with the value of its error-status field set to 1136 "tooBig", the value of its error-index field set to zero, and an 1137 empty variable-bindings field. This alternate Response-PDU is then 1138 encapsulated into a message. If the size of the resultant message is 1139 less than or equal to both a local constraint and the maximum message 1140 size of the originator, it is transmitted to the originator of the 1141 InformRequest-PDU. Otherwise, the snmpSilentDrops [RFC-MIB] counter 1142 is incremented and the resultant message is discarded. Regardless, 1143 processing of the InformRequest-PDU terminates. 1145 Otherwise, the receiving SNMP entity: 1147 (1) presents its contents to the appropriate application; 1149 (2) generates a Response-PDU with the same values in its request-id 1150 and variable-bindings fields as the received InformRequest-PDU, 1151 with the value of its error-status field set to "noError" and 1152 the value of its error-index field set to zero; and 1154 (3) transmits the generated Response-PDU to the originator of the 1155 InformRequest-PDU. 1157 5. Notice on Intellectual Property 1159 The IETF takes no position regarding the validity or scope of any 1160 intellectual property or other rights that might be claimed to 1161 pertain to the implementation or use of the technology described in 1162 this document or the extent to which any license under such rights 1163 might or might not be available; neither does it represent that it 1164 has made any effort to identify any such rights. Information on the 1165 IETF's procedures with respect to rights in standards-track and 1166 standards-related documentation can be found in BCP-11. Copies of 1167 claims of rights made available for publication and any assurances of 1168 licenses to be made available, or the result of an attempt made to 1169 obtain a general license or permission for the use of such 1170 proprietary rights by implementors or users of this specification can 1171 be obtained from the IETF Secretariat. 1173 The IETF invites any interested party to bring to its attention any 1174 copyrights, patents or patent applications, or other proprietary 1175 rights which may cover technology that may be required to practice 1176 this standard. Please address the information to the IETF Executive 1177 Director. 1179 6. Acknowledgments 1181 This document is the product of the SNMPv3 Working Group. Some 1182 special thanks are in order to the following Working Group members: 1184 Randy Bush 1185 Jeffrey D. Case 1186 Mike Daniele 1187 Rob Frye 1188 Lauren Heintz 1189 Keith McCloghrie 1190 Russ Mundy 1191 David T. Perkins 1192 Randy Presuhn 1193 Aleksey Romanov 1194 Juergen Schoenwaelder 1195 Bert Wijnen 1197 This version of the document, edited by Randy Presuhn, was initially 1198 based on the work of a design team whose members were: 1200 Jeffrey D. Case 1201 Keith McCloghrie 1202 David T. Perkins 1203 Randy Presuhn 1204 Juergen Schoenwaelder 1206 The previous versions of this document, edited by Keith McCloghrie, 1207 was the result of significant work by four major contributors: 1209 Jeffrey D. Case 1210 Keith McCloghrie 1211 Marshall T. Rose 1212 Steven Waldbusser 1214 Additionally, the contributions of the SNMPv2 Working Group to the 1215 previous versions are also acknowledged. In particular, a special 1216 thanks is extended for the contributions of: 1218 Alexander I. Alten 1219 Dave Arneson 1220 Uri Blumenthal 1221 Doug Book 1222 Kim Curran 1223 Jim Galvin 1224 Maria Greene 1225 Iain Hanson 1226 Dave Harrington 1227 Nguyen Hien 1228 Jeff Johnson 1229 Michael Kornegay 1230 Deirdre Kostick 1231 David Levi 1232 Daniel Mahoney 1233 Bob Natale 1234 Brian O'Keefe 1235 Andrew Pearson 1236 Dave Perkins 1237 Randy Presuhn 1238 Aleksey Romanov 1239 Shawn Routhier 1240 Jon Saperia 1241 Juergen Schoenwaelder 1242 Bob Stewart 1243 Kaj Tesink 1244 Glenn Waters 1245 Bert Wijnen 1247 7. Security Considerations 1249 The protocol defined in this document by itself does not provide a ! 1250 secure environment. Even if the network itself is secure (for ! 1251 example by using IPSec), there is no control as to who on the secure ! 1252 network is allowed access to management information. 1254 It is recommended that the implementors consider the security 1255 features as provided by the SNMPv3 framework. Specifically, the use 1256 of the User-based Security Model RFC -USM [RFC-USM] and the 1257 View-based Access Control Model RFC -ACM [RFC-ACM] is recommended. 1259 It is then a customer/user responsibility to ensure that the SNMP 1260 entity is properly configured so that: 1262 - only those principals (users) having legitimate rights can 1263 access or modify the values of any MIB objects supported by 1264 that entity; 1266 - the occurrence of particular events on the entity will be 1267 communicated appropriately; 1269 - the entity responds appropriately and with due credence to 1270 events and information that have been communicated to it. 1272 8. References 1274 [ASN1] Information processing systems - Open Systems 1275 Interconnection - Specification of Abstract Syntax Notation 1276 One (ASN.1), International Organization for 1277 Standardization. International Standard 8824, December 1278 1987. 1280 [FRAG] Kent, C., and J. Mogul, "Fragmentation Considered Harmful," 1281 Proceedings, ACM SIGCOMM '87, Stowe, VT, August 1987. 1283 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1284 USC/Information Sciences Institute, August 1980. 1286 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 1287 of Management Information for TCP/IP-based Internets", STD 1288 16, RFC 1155, May 1990. 1290 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1291 Network Management Protocol", STD 15, RFC 1157, May 1990. 1293 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 1294 16, RFC 1212, March 1991. 1296 [RFC1215] Rose, M., "A Convention for Defining Traps for use with the 1297 SNMP", RFC 1215, March 1991. 1299 [RFC1213] McCloghrie, K., and M. Rose, Editors, "Management 1300 Information Base for Network Management of TCP/IP-based 1301 internets: MIB-II", STD 17, RFC 1213, March 1991. 1303 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1304 "Introduction to Community-based SNMPv2", RFC 1901, January 1305 1996. 1307 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 1308 "Introduction to Version 3 of the Internet-standard Network 1309 Management Framework", RFC 2570, April 1999. 1311 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1312 Rose, M., and S. Waldbusser, "Structure of Management 1313 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1314 1999. 1316 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1317 Rose, M., and S. Waldbusser, "Textual Conventions for 1318 SMIv2", STD 58, RFC 2579, April 1999. 1320 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1321 Rose, M., and S. Waldbusser, "Conformance Statements for 1322 SMIv2", STD 58, RFC 2580, April 1999. 1324 [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 1325 Waldbusser, "Transport Mappings for the Simple Network 1326 Management Protocol", 1327 , October 2001. 1329 [RFC2863] McCloghrie, K., and F. Kastenholz, "The Interfaces Group 1330 MIB", RFC 2863, June 2000. 1332 [RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 1333 Waldbusser, "Management Information Base for the Simple 1334 Network Management Protocol", 1335 , October 2001. 1337 [RFC-ARC] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture 1338 for describing SNMP Management Frameworks", 1339 , October 2001. 1341 [RFC-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, 1342 "Message Processing and Dispatching for the Simple Network 1343 Management Protocol (SNMP)", 1344 , October 2001. 1346 [RFC-APL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", 1347 , October 2001. 1349 [RFC-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 1350 Model for Version 3 of the Simple Network Management 1351 Protocol (SNMPv3)", 1352 , October 2001. 1354 [RFC-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 1355 Access Control Model for the Simple Network Management 1356 Protocol (SNMP)", , 1357 October 2001. 1359 [RFC-COEX]Frye, R., Levi, D., Routhier, S., and B. Wijnen, 1360 "Coexistence between Version 1, Version 2, and Version 3 of 1361 the Internet-standard Network Management Framework", 1362 , October 2001. 1364 9. Editor's Address 1366 Randy Presuhn 1367 BMC Software, Inc. 1368 2141 North First Street 1369 San Jose, CA 95131 1370 USA 1372 Phone: +1 408 546 1006 1373 EMail: randy_presuhn@bmc.com 1375 10. Changes from RFC 1905 1377 These are the changes from RFC 1905: 1379 - Corrected spelling error in copyright statement; 1381 - Updated copyright date; 1383 - Updated with new editor's name and contact information; 1385 - Added notice on intellectual property; 1387 - Cosmetic fixes to layout and typography; 1389 - Added table of contents; 1391 - Title changed; 1393 - Updated document headers and footers; 1395 - Deleted the old clause 2.3, entitled "Access to Management 1396 Information"; 1398 - Changed the way in which request-id was defined, though 1399 with the same ultimate syntax and semantics, to avoid 1400 coupling with SMI. This does not affect the protocol in 1401 any way; 1403 - Replaced the word "exception" with the word "error" in the 1404 old clause 4.1. This does not affect the protocol in any 1405 way; 1407 - Deleted the first two paragraphs of the old clause 4.2; 1409 - Clarified the maximum number of variable bindings that an 1410 implementation must support in a PDU. This does not affect 1411 the protocol in any way; 1413 - Replaced occurrences of "SNMPv2 application" with 1414 "application"; 1416 - Deleted three sentences in old clause 4.2.3 describing the 1417 handling of an impossible situation. This does not affect 1418 the protocol in any way; 1420 - Clarified the use of the SNMPv2-Trap-Pdu in the old clause 1421 4.2.6. This does not affect the protocol in any way; 1423 - Aligned description of the use of the InformRequest-Pdu in 1424 old clause 4.2.7 with the architecture. This does not 1425 affect the protocol in any way; 1427 - Updated references; 1429 - Re-wrote introduction clause; 1431 - Replaced manager/agent/SNMPv2 entity terminology with 1432 terminology from RFC 2571. This does not affect the 1433 protocol in any way; 1435 - Eliminated IMPORTS from the SMI, replaced with equivalent 1436 in-line ASN.1. This does not affect the protocol in any 1437 way; 1439 - Added notes calling attention to two different 1440 manifestations of reaching the end of a table in the table 1441 walk examples; 1443 - Added content to security considerations clause; 1445 - Updated ASN.1 comment on use of Report-PDU. This does not 1446 affect the protocol in any way; 1448 - Updated acknowledgements section; 1450 Included information on handling of BITS; 1451 Deleted spurious comma in ASN.1 definition of PDUs; 1453 Added abstract; 1455 Made handling of additional variable bindings in informs 1456 consistent with that for traps. This was a correction of 1457 an editorial oversight, and reflects implementation 1458 practice. 1460 11. Issues 1462 This clause will be deleted when this material is published as an 1463 RFC. The issue labels are the same as those used in the on-line 1464 issues list at 1465 ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1905/index.html 1467 1905-1 Done; table of contents added. 1469 1905-2 Done; new title put in. 1471 1905-3 Done; new introduction clause put in. 1473 1905-4 Done; handled as part of 1905-3. 1475 1905-5 Done; clause deleted. 1477 1905-6 Done; clause deleted, terminology changed throughout 1478 the document. 1480 1905-7 Done; resolution was "no change". 1482 1905-8 Done; deleted the old clause 2.3. 1484 1905-9 Done; resolution was "no change". 1486 1905-10 Done; resolution was "no change". 1488 1905-11 Done; resolution was "no change". 1490 1905-12 Done; incorporated suggested text, fixed minor ASN.1 1491 problem. 1493 1905-13 Done; resolution was to change form (but not ultimate 1494 syntax or semantics) of definition of request-id 1495 element. 1497 1905-14 Done; resolution was "no change". 1499 1905-15 Done; ASN.1 comments lined up. 1501 1905-16 Done; resolution was "no change". 1503 1905-17 Done; changed "exception" to "error" in second 1504 paragraph of old clause 4.1. 1506 1905-18 Done; deleted first two paragraphs of old clause 4.2. 1508 1905-19 Done; resolution was "no change". 1510 1905-20 Done; replaced occurrences of "SNMPv2 application" 1511 with "application". 1513 1905-21 Done; though as a side-effect of issue 1905-6's 1514 resolution. 1516 1905-22 Done; clarifying notes added. 1518 1905-23 Done; deleted offending sentences. 1520 1905-24 Done; resolution was "no change". 1522 1905-25 Done; added note to example. 1524 1905-26 Done; resolution was "no change". 1526 1905-27 Done; resolution was "no change". 1528 1905-28 Done; replaced first paragraph of old clause 4.2.6. 1530 1905-29 Done; replaced first paragraph of old clause 4.2.7. 1532 1905-30 Done; added content to security considerations clause. 1534 1905-31 Done; references updated; acknowledgments updated. 1536 1905-32 Done; added clarifying text. 1538 1905-33 Done; IPR and copyright material updated. 1540 1905-34 Done; headers and footers updated appropriately. 1542 1905-35 Done; resolution was "no change". 1544 1905-36 Done; though original resolution was "no change", this 1545 was effectively superseded by the resolution to 1546 1905-12. 1548 1905-37 Done; resolution was "no change". 1550 1905-38 Done; added abstract. 1552 1905-39 Done; clarified text on maximum PDU size. 1554 1905-40 Open; should trap and inform procedures match for 1555 added varbinds? 1557 12. Full Copyright Statement 1559 Copyright (C) The Internet Society (2001). All Rights Reserved. 1561 This document and translations of it may be copied and furnished to 1562 others, and derivative works that comment on or otherwise explain it 1563 or assist in its implementation may be prepared, copied, published 1564 and distributed, in whole or in part, without restriction of any 1565 kind, provided that the above copyright notice and this paragraph are 1566 included on all such copies and derivative works. However, this 1567 document itself may not be modified in any way, such as by removing 1568 the copyright notice or references to the Internet Society or other 1569 Internet organizations, except as needed for the purpose of 1570 developing Internet standards in which case the procedures for 1571 copyrights defined in the Internet Standards process must be 1572 followed, or as required to translate it into languages other than 1573 English. 1575 The limited permissions granted above are perpetual and will not be 1576 revoked by the Internet Society or its successors or assigns. 1578 This document and the information contained herein is provided on an 1579 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1580 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1581 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1582 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1583 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.