idnits 2.17.1 draft-ietf-snmpv3-update-proto-02.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. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 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 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. -- The draft header indicates that this document obsoletes RFC1905, but the abstract doesn't seem to directly say this. It does mention RFC1905 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 548 has weird spacing: '...ield is set...' == Line 1203 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 April 2000) is 8782 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 287, but not defined == Missing Reference: 'APPLICATION 1' is mentioned on line 289, but not defined == Missing Reference: 'APPLICATION 2' is mentioned on line 291, but not defined == Missing Reference: 'APPLICATION 3' is mentioned on line 295, but not defined == Missing Reference: 'APPLICATION 4' is mentioned on line 297, but not defined == Missing Reference: 'APPLICATION 6' is mentioned on line 299, but not defined -- Looks like a reference, but probably isn't: '0' on line 438 -- Looks like a reference, but probably isn't: '1' on line 441 -- Looks like a reference, but probably isn't: '2' on line 444 -- Looks like a reference, but probably isn't: '3' on line 346 -- Looks like a reference, but probably isn't: '4' on line 349 -- Looks like a reference, but probably isn't: '5' on line 352 -- Looks like a reference, but probably isn't: '6' on line 356 -- Looks like a reference, but probably isn't: '7' on line 360 -- Looks like a reference, but probably isn't: '8' on line 367 == Unused Reference: 'ASN1' is defined on line 1272, but no explicit reference was found in the text == Unused Reference: 'RFC2233' is defined on line 1306, 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 2233 (Obsoleted by RFC 2863) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2576 (Obsoleted by RFC 3584) -- 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 Request for Comments: -PROTO R. Presuhn 3 STD: XXX BMC Software, Inc. 4 Obsoletes: 1905 Authors of previous version: 5 Category: Standards Track J. Case 6 SNMP Research, Inc. 7 K. McCloghrie 8 Cisco Systems, Inc. 9 M. Rose 10 Dover Beach Consulting, Inc. 11 S. Waldbusser 12 International Network Services 13 3 April 2000 15 Version 2 of the Protocol Operations for 16 the Simple Network Management Protocol 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society (2000). All Rights Reserved. 42 Abstract 44 This document is intended to obsolete RFC 1905, Protocol Operations 45 for Version 2 of the Simple Network Management Protocol (SNMPv2). It 46 defines the syntax and elements of procedure for sending, receiving, 47 and processing SNMP PDUs. 49 Table of Contents 51 1. Introduction ................................................ 3 52 2. Overview .................................................... 4 53 2.1. Management Information .................................... 4 54 2.2. Retransmission of Requests ................................ 4 55 2.3. Message Sizes ............................................. 4 56 2.4. Transport Mappings ........................................ 5 57 2.5. SMIv2 Data Type Mappings .................................. 5 58 3. Definitions ................................................. 6 59 4. Protocol Specification ...................................... 11 60 4.1. Common Constructs ......................................... 11 61 4.2. PDU Processing ............................................ 11 62 4.2.1. The GetRequest-PDU ...................................... 12 63 4.2.2. The GetNextRequest-PDU .................................. 13 64 4.2.2.1. Example of Table Traversal ............................ 14 65 4.2.3. The GetBulkRequest-PDU .................................. 16 66 4.2.3.1. Another Example of Table Traversal .................... 19 67 4.2.4. The Response-PDU ........................................ 20 68 4.2.5. The SetRequest-PDU ...................................... 21 69 4.2.6. The SNMPv2-Trap-PDU ..................................... 24 70 4.2.7. The InformRequest-PDU ................................... 24 71 5. Notice on Intellectual Property ............................. 25 72 6. Acknowledgments ............................................. 26 73 7. Security Considerations ..................................... 27 74 8. References .................................................. 28 75 9. Editor's Address ............................................ 30 76 10. Changes from RFC 1905 ...................................... 30 77 11. Issues ..................................................... 31 78 12. Full Copyright Statement ................................... 33 80 1. Introduction 82 The SNMP Management Framework at the time of this writing consists of 83 five major components: 85 - An overall architecture, described in RFC 2571 [RFC2571]. 87 - Mechanisms for describing and naming objects and events for 88 the purpose of management. The first version of this 89 Structure of Management Information (SMI) is called SMIv1 90 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 91 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, 92 called SMIv2, is described in STD 58, RFC 2578 [RFC2578], 93 STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 95 - Message protocols for transferring management information. 96 The first version of the SNMP message protocol is called 97 SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A 98 second version of the SNMP message protocol, which is not 99 an Internet standards track protocol, is called SNMPv2c and 100 described in RFC 1901 [RFC1901] and RFC -TM [RFC-TM]. The 101 third version of the message protocol is called SNMPv3 and 102 described in RFC -TM [RFC-TM], RFC 2572 [RFC2572] and RFC 103 2574 [RFC2574]. 105 - Protocol operations for accessing management information. 106 The first set of protocol operations and associated PDU 107 formats is described in STD 15, RFC 1157 [RFC1157]. A 108 second set of protocol operations and associated PDU 109 formats is described in this document. 111 - A set of fundamental applications described in RFC 2573 112 [RFC2573] and the view-based access control mechanism 113 described in RFC 2575 [RFC2575]. 115 A more detailed introduction to the SNMP Management Framework at 116 the time of this writing can be found in RFC 2570 [RFC2570]. 118 Managed objects are accessed via a virtual information store, 119 termed the Management Information Base or MIB. Objects in the 120 MIB are defined using the mechanisms defined in the SMI. 122 This document, Version 2 of the Protocol Operations for the 123 Simple Network Management Protocol, defines the operations of 124 the protocol with respect to the sending and receiving of PDUs 125 to be carried by the message protocol. 127 2. Overview 129 SNMP entities supporting command generator or notification receiver 130 applications (traditionally called "managers") communicate with SNMP 131 entities supporting command responder or notification originator 132 applications (traditionally called "agents"). The purpose of this 133 protocol is the transport of management information and operations. 135 2.1. Management Information 137 The term "variable" refers to an instance of a non-aggregate object 138 type defined according to the conventions set forth in the SMI 139 [RFC2578] or the textual conventions based on the SMI [RFC2579]. The 140 term "variable binding" normally refers to the pairing of the name of 141 a variable and its associated value. However, if certain kinds of 142 exceptional conditions occur during processing of a retrieval 143 request, a variable binding will pair a name and an indication of 144 that exception. 146 A variable-binding list is a simple list of variable bindings. 148 The name of a variable is an OBJECT IDENTIFIER which is the 149 concatenation of the OBJECT IDENTIFIER of the corresponding 150 object-type together with an OBJECT IDENTIFIER fragment identifying 151 the instance. The OBJECT IDENTIFIER of the corresponding object-type 152 is called the OBJECT IDENTIFIER prefix of the variable. 154 2.2. Retransmission of Requests 156 For all types of request in this protocol, the receiver is required 157 under normal circumstances, to generate and transmit a response to 158 the originator of the request. Whether or not a request should be 159 retransmitted if no corresponding response is received in an 160 appropriate time interval, is at the discretion of the application 161 originating the request. This will normally depend on the urgency of 162 the request. However, such an application needs to act responsibly 163 in respect to the frequency and duration of re-transmissions. 165 2.3. Message Sizes 167 The maximum size of an SNMP message is limited to the minimum of: 169 (1) the maximum message size which the destination SNMP entity can 170 accept; and, 172 (2) the maximum message size which the source SNMP entity can 173 generate. 175 The former may be known on a per-recipient basis; and in the absence 176 of such knowledge, is indicated by transport domain used when sending 177 the message. The latter is imposed by implementation-specific local 178 constraints. 180 Each transport mapping for the SNMP indicates the minimum message 181 size which a SNMP implementation must be able to produce or consume. 182 Although implementations are encouraged to support larger values 183 whenever possible, a conformant implementation must never generate 184 messages larger than allowed by the receiving SNMP entity. 186 One of the aims of the GetBulkRequest-PDU, specified in this 187 protocol, is to minimize the number of protocol exchanges required to 188 retrieve a large amount of management information. As such, this PDU 189 type allows an SNMP entity supporting command generator applications 190 to request that the response be as large as possible given the 191 constraints on message sizes. These constraints include the limits 192 on the size of messages which the SNMP entity supporting command 193 responder applications can generate, and the SNMP entity supporting 194 command generator applications can receive. 196 However, it is possible that such maximum sized messages may be 197 larger than the Path MTU of the path across the network traversed by 198 the messages. In this situation, such messages are subject to 199 fragmentation. Fragmentation is generally considered to be harmful 200 [FRAG], since among other problems, it leads to a decrease in the 201 reliability of the transfer of the messages. Thus, an SNMP entity 202 which sends a GetBulkRequest-PDU must take care to set its parameters 203 accordingly, so as to reduce the risk of fragmentation. In 204 particular, under conditions of network stress, only small values 205 should be used for max-repetitions. 207 2.4. Transport Mappings 209 It is important to note that the exchange of SNMP messages requires 210 only an unreliable datagram service, with every message being 211 entirely and independently contained in a single transport datagram. 212 Specific transport mappings and encoding rules are specified 213 elsewhere [RFC-TM]. However, the preferred mapping is the use of the 214 User Datagram Protocol [RFC768]. 216 2.5. SMIv2 Data Type Mappings 218 The SMIv2 [RFC2578] defines 11 base types (INTEGER, OCTET STRING, 219 OBJECT IDENTIFIER, Integer32, IpAddress, Counter32, Gauge32, 220 Unsigned32, TimeTicks, Opaque, Counter64) and the BITS construct. The 221 SMIv2 base types are mapped to the corresponding selection type in 222 the SimpleSyntax and ApplicationSyntax choices of the ASN.1 SNMP 223 protocol definition. Note that the INTEGER and Integer32 SMIv2 base 224 types are mapped to the integer-value selection type of the 225 SimpleSyntax choice. Similarly, the Gauge32 and Unsigned32 SMIv2 base 226 types are mapped to the unsigned-integer-value selection type of the 227 ApplicationSyntax choice. 229 The SMIv2 BITS construct is mapped to the string-value selection type 230 of the SimpleSyntax choice. A BITS value is encoded as an OCTET 231 STRING, in which all the named bits in (the definition of) the 232 bitstring, commencing with the first bit and proceeding to the last 233 bit, are placed in bits 8 to 1 of the first octet, followed by bits 8 234 to 1 of each subsequent octet in turn, followed by as many bits as 235 are needed of the final subsequent octet, commencing with bit 8. 236 Remaining bits, if any, of the final octet are set to zero on 237 generation and ignored on receipt. 239 3. Definitions 241 SNMPv2-PDU DEFINITIONS ::= BEGIN 243 ObjectName ::= OBJECT IDENTIFIER 245 ObjectSyntax ::= 246 CHOICE { 247 simple 248 SimpleSyntax, 250 application-wide 251 ApplicationSyntax 252 } 254 SimpleSyntax ::= 255 CHOICE { 256 integer-value 257 INTEGER (-2147483648..2147483647), 259 string-value 260 OCTET STRING (SIZE (0..65535)), 262 objectID-value 263 OBJECT IDENTIFIER 264 } 266 ApplicationSyntax ::= 267 CHOICE { 268 ipAddress-value 269 IpAddress, 271 counter-value 272 Counter32, 274 timeticks-value 275 TimeTicks, 277 arbitrary-value 278 Opaque, 280 big-counter-value 281 Counter64, 283 unsigned-integer-value 284 Unsigned32 285 } 287 IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) 289 Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) 291 Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) 293 Gauge32 ::= Unsigned32 295 TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) 297 Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING 299 Counter64 ::= [APPLICATION 6] 300 IMPLICIT INTEGER (0..18446744073709551615) 302 -- protocol data units 304 PDUs ::= 305 CHOICE { 306 get-request 307 GetRequest-PDU, 309 get-next-request 310 GetNextRequest-PDU, 312 get-bulk-request 313 GetBulkRequest-PDU, 315 response 316 Response-PDU, 318 set-request 319 SetRequest-PDU, 321 inform-request 322 InformRequest-PDU, 324 snmpV2-trap 325 SNMPv2-Trap-PDU, 327 report 328 Report-PDU, 329 } 331 -- PDUs 333 GetRequest-PDU ::= 334 [0] 335 IMPLICIT PDU 337 GetNextRequest-PDU ::= 338 [1] 339 IMPLICIT PDU 341 Response-PDU ::= 342 [2] 343 IMPLICIT PDU 345 SetRequest-PDU ::= 346 [3] 347 IMPLICIT PDU 349 -- [4] is obsolete 351 GetBulkRequest-PDU ::= 352 [5] 353 IMPLICIT BulkPDU 355 InformRequest-PDU ::= 356 [6] 357 IMPLICIT PDU 359 SNMPv2-Trap-PDU ::= 360 [7] 361 IMPLICIT PDU 363 -- Usage and precise semantics of Report-PDU are not defined 364 -- in this document. Any SNMP administrative framework making 365 -- use of this PDU must define its usage and semantics. 366 Report-PDU ::= 367 [8] 368 IMPLICIT PDU 370 max-bindings 371 INTEGER ::= 2147483647 373 PDU ::= 374 SEQUENCE { 375 request-id 376 INTEGER (-214783648..214783647), 378 error-status -- sometimes ignored 379 INTEGER { 380 noError(0), 381 tooBig(1), 382 noSuchName(2), -- for proxy compatibility 383 badValue(3), -- for proxy compatibility 384 readOnly(4), -- for proxy compatibility 385 genErr(5), 386 noAccess(6), 387 wrongType(7), 388 wrongLength(8), 389 wrongEncoding(9), 390 wrongValue(10), 391 noCreation(11), 392 inconsistentValue(12), 393 resourceUnavailable(13), 394 commitFailed(14), 395 undoFailed(15), 396 authorizationError(16), 397 notWritable(17), 398 inconsistentName(18) 399 }, 401 error-index -- sometimes ignored 402 INTEGER (0..max-bindings), 404 variable-bindings -- values are sometimes ignored 405 VarBindList 406 } 408 BulkPDU ::= -- must be identical in 409 SEQUENCE { -- structure to PDU 410 request-id 411 INTEGER (-214783648..214783647), 413 non-repeaters 414 INTEGER (0..max-bindings), 416 max-repetitions 417 INTEGER (0..max-bindings), 419 variable-bindings -- values are ignored 420 VarBindList 421 } 423 -- variable binding 425 VarBind ::= 426 SEQUENCE { 427 name 428 ObjectName, 430 CHOICE { 431 value 432 ObjectSyntax, 434 unSpecified -- in retrieval requests 435 NULL, 437 -- exceptions in responses 438 noSuchObject[0] 439 IMPLICIT NULL, 441 noSuchInstance[1] 442 IMPLICIT NULL, 444 endOfMibView[2] 445 IMPLICIT NULL 446 } 447 } 449 -- variable-binding list 451 VarBindList ::= 452 SEQUENCE (SIZE (0..max-bindings)) OF 453 VarBind 455 END 457 4. Protocol Specification 459 4.1. Common Constructs 461 The value of the request-id field in a Response-PDU takes the value 462 of the request-id field in the request PDU to which it is a response. 463 By use of the request-id value, an application can distinguish the 464 (potentially multiple) outstanding requests, and thereby correlate 465 incoming responses with outstanding requests. In cases where an 466 unreliable datagram service is used, the request-id also provides a 467 simple means of identifying messages duplicated by the network. Use 468 of the same request-id on a retransmission of a request allows the 469 response to either the original transmission or the retransmission to 470 satisfy the request. However, in order to calculate the round trip 471 time for transmission and processing of a request-response 472 transaction, the application needs to use a different request-id 473 value on a retransmitted request. The latter strategy is recommended 474 for use in the majority of situations. 476 A non-zero value of the error-status field in a Response-PDU is used 477 to indicate that an error occurred to prevent the processing of the 478 request. In these cases, a non-zero value of the Response-PDU's 479 error-index field provides additional information by identifying 480 which variable binding in the list caused the error. A variable 481 binding is identified by its index value. The first variable binding 482 in a variable-binding list is index one, the second is index two, 483 etc. 485 SNMP limits OBJECT IDENTIFIER values to a maximum of 128 486 sub-identifiers, where each sub-identifier has a maximum value of 487 2**32-1. 489 4.2. PDU Processing 491 In the elements of procedure below, any field of a PDU which is not 492 referenced by the relevant procedure is ignored by the receiving SNMP 493 entity. However, all components of a PDU, including those whose 494 values are ignored by the receiving SNMP entity, must have valid 495 ASN.1 syntax and encoding. For example, some PDUs (e.g., the 496 GetRequest-PDU) are concerned only with the name of a variable and 497 not its value. In this case, the value portion of the variable 498 binding is ignored by the receiving SNMP entity. The unSpecified 499 value is defined for use as the value portion of such bindings. 501 On generating a management communication, the message "wrapper" to 502 encapsulate the PDU is generated according to the "Elements of 503 Procedure" of the administrative framework in use is followed. While 504 the definition of "max-bindings" does impose an upper-bound on the 505 number of variable bindings, in practice, the size of a message is 506 limited only by constraints on the maximum message size -- it is not 507 limited by the number of variable bindings. A compliant 508 implementation must support as many variable bindings in a PDU or 509 BulkPDU as fit into the overall maximum message size limit of the 510 SNMP engine, but no more than 2147483647. 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] message is discarded. 620 4.2.2.1. Example of Table Traversal 622 An important use of the GetNextRequest-PDU is the traversal of 623 conceptual tables of information within a MIB. The semantics of this 624 type of request, together with the method of identifying individual 625 instances of objects in the MIB, provides access to related objects 626 in the MIB as if they enjoyed a tabular organization. 628 In the protocol exchange sketched below, an application retrieves the 629 media-dependent physical address and the address-mapping type for 630 each entry in the IP net-to-media Address Translation Table [RFC1213] 631 of a particular network element. It also retrieves the value of 632 sysUpTime [RFC-MIB], at which the mappings existed. Suppose that the 633 command responder's IP net-to-media table has three entries: 634 Interface-Number Network-Address Physical-Address Type 636 1 10.0.0.51 00:00:10:01:23:45 static 637 1 9.2.3.4 00:00:10:54:32:10 dynamic 638 2 10.0.0.15 00:00:10:98:76:54 dynamic 640 The SNMP entity supporting a command generator application begins by 641 sending a GetNextRequest-PDU containing the indicated OBJECT 642 IDENTIFIER values as the requested variable names: 644 GetNextRequest ( sysUpTime, 645 ipNetToMediaPhysAddress, 646 ipNetToMediaType ) 648 The SNMP entity supporting a command responder application responds 649 with a Response-PDU: 651 Response (( sysUpTime.0 = "123456" ), 652 ( ipNetToMediaPhysAddress.1.9.2.3.4 = 653 "000010543210" ), 654 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" )) 656 The SNMP entity supporting the command generator application 657 continues with: 659 GetNextRequest ( sysUpTime, 660 ipNetToMediaPhysAddress.1.9.2.3.4, 661 ipNetToMediaType.1.9.2.3.4 ) 663 The SNMP entity supporting the command responder application responds 664 with: 666 Response (( sysUpTime.0 = "123461" ), 667 ( ipNetToMediaPhysAddress.1.10.0.0.51 = 668 "000010012345" ), 669 ( ipNetToMediaType.1.10.0.0.51 = "static" )) 671 The SNMP entity supporting the command generator application 672 continues with: 674 GetNextRequest ( sysUpTime, 675 ipNetToMediaPhysAddress.1.10.0.0.51, 676 ipNetToMediaType.1.10.0.0.51 ) 678 The SNMP entity supporting the command responder application responds 679 with: 681 Response (( sysUpTime.0 = "123466" ), 682 ( ipNetToMediaPhysAddress.2.10.0.0.15 = 683 "000010987654" ), 684 ( ipNetToMediaType.2.10.0.0.15 = "dynamic" )) 686 The SNMP entity supporting the command generator application 687 continues with: 689 GetNextRequest ( sysUpTime, 690 ipNetToMediaPhysAddress.2.10.0.0.15, 691 ipNetToMediaType.2.10.0.0.15 ) 693 As there are no further entries in the table, the SNMP entity 694 supporting the command responder application responds with the 695 variables that are next in the lexicographical ordering of the 696 accessible object names, for example: 698 Response (( sysUpTime.0 = "123471" ), 699 ( ipNetToMediaNetAddress.1.9.2.3.4 = 700 "9.2.3.4" ), 701 ( ipRoutingDiscards.0 = "2" )) 703 Note now, having reached the end of the column for 704 ipNetToMediaPhysAddress, the second variable binding in the command 705 responder application has "wrapped" to the first row in the next 706 column. Furthermore, note how, having reached the end of the 707 ipNetToMediaTable for the third variable binding, the command 708 responder application has responded with the next available object, 709 which is outside that table. This response signals the end of the 710 table to the command generator application. 712 4.2.3. The GetBulkRequest-PDU 714 A GetBulkRequest-PDU is generated and transmitted at the request of 715 an application. The purpose of the GetBulkRequest-PDU is to request 716 the transfer of a potentially large amount of data, including, but 717 not limited to, the efficient and rapid retrieval of large tables. 719 Upon receipt of a GetBulkRequest-PDU, the receiving SNMP entity 720 processes each variable binding in the variable-binding list to 721 produce a Response-PDU with its request-id field having the same 722 value as in the request. 724 For the GetBulkRequest-PDU type, the successful processing of each 725 variable binding in the request generates zero or more variable 726 bindings in the Response-PDU. That is, the one-to-one mapping 727 between the variable bindings of the GetRequest-PDU, 728 GetNextRequest-PDU, and SetRequest-PDU types and the resultant 729 Response-PDUs does not apply for the mapping between the variable 730 bindings of a GetBulkRequest-PDU and the resultant Response-PDU. 732 The values of the non-repeaters and max-repetitions fields in the 733 request specify the processing requested. One variable binding in 734 the Response-PDU is requested for the first N variable bindings in 735 the request and M variable bindings are requested for each of the R 736 remaining variable bindings in the request. Consequently, the total 737 number of requested variable bindings communicated by the request is 738 given by N + (M * R), where N is the minimum of: a) the value of the 739 non-repeaters field in the request, and b) the number of variable 740 bindings in the request; M is the value of the max-repetitions field 741 in the request; and R is the maximum of: a) number of variable 742 bindings in the request - N, and b) zero. 744 The receiving SNMP entity produces a Response-PDU with up to the 745 total number of requested variable bindings communicated by the 746 request. The request-id shall have the same value as the received 747 GetBulkRequest-PDU. 749 If N is greater than zero, the first through the (N)-th variable 750 bindings of the Response-PDU are each produced as follows: 752 (1) The variable is located which is in the lexicographically 753 ordered list of the names of all variables which are accessible 754 by this request and whose name is the first lexicographic 755 successor of the variable binding's name in the incoming 756 GetBulkRequest-PDU. The corresponding variable binding's name 757 and value fields in the Response-PDU are set to the name and 758 value of the located variable. 760 (2) If the requested variable binding's name does not 761 lexicographically precede the name of any variable accessible by 762 this request, i.e., there is no lexicographic successor, then 763 the corresponding variable binding produced in the Response-PDU 764 has its value field set to "endOfMibView", and its name field 765 set to the variable binding's name in the request. 767 If M and R are non-zero, the (N + 1)-th and subsequent variable 768 bindings of the Response-PDU are each produced in a similar manner. 769 For each iteration i, such that i is greater than zero and less than 770 or equal to M, and for each repeated variable, r, such that r is 771 greater than zero and less than or equal to R, the (N + ( (i-1) * R ) 772 + r)-th variable binding of the Response-PDU is produced as follows: 774 (1) The variable which is in the lexicographically ordered list of 775 the names of all variables which are accessible by this request 776 and whose name is the (i)-th lexicographic successor of the (N + 777 r)-th variable binding's name in the incoming GetBulkRequest-PDU 778 is located and the variable binding's name and value fields are 779 set to the name and value of the located variable. 781 (2) If there is no (i)-th lexicographic successor, then the 782 corresponding variable binding produced in the Response-PDU has 783 its value field set to "endOfMibView", and its name field set to 784 either the last lexicographic successor, or if there are no 785 lexicographic successors, to the (N + r)-th variable binding's 786 name in the request. 788 While the maximum number of variable bindings in the Response-PDU is 789 bounded by N + (M * R), the response may be generated with a lesser 790 number of variable bindings (possibly zero) for either of three 791 reasons. 793 (1) If the size of the message encapsulating the Response-PDU 794 containing the requested number of variable bindings would be 795 greater than either a local constraint or the maximum message 796 size of the originator, then the response is generated with a 797 lesser number of variable bindings. This lesser number is the 798 ordered set of variable bindings with some of the variable 799 bindings at the end of the set removed, such that the size of 800 the message encapsulating the Response-PDU is approximately 801 equal to but no greater than either a local constraint or the 802 maximum message size of the originator. Note that the number of 803 variable bindings removed has no relationship to the values of 804 N, M, or R. 806 (2) The response may also be generated with a lesser number of 807 variable bindings if for some value of iteration i, such that i 808 is greater than zero and less than or equal to M, that all of 809 the generated variable bindings have the value field set to 810 "endOfMibView". In this case, the variable bindings may be 811 truncated after the (N + (i * R))-th variable binding. 813 (3) In the event that the processing of a request with many 814 repetitions requires a significantly greater amount of 815 processing time than a normal request, then a command responder 816 application may terminate the request with less than the full 817 number of repetitions, providing at least one repetition is 818 completed. 820 If the processing of any variable binding fails for a reason other 821 than listed above, then the Response-PDU is re-formatted with the 822 same values in its request-id and variable-bindings fields as the 823 received GetBulkRequest-PDU, with the value of its error-status field 824 set to "genErr", and the value of its error-index field is set to the 825 index of the variable binding in the original request which 826 corresponds to the failed variable binding. 828 Otherwise, the value of the Response-PDU's error-status field is set 829 to "noError", and the value of its error-index field to zero. 831 The generated Response-PDU (possibly with an empty variable-bindings 832 field) is then encapsulated into a message. If the size of the 833 resultant message is less than or equal to both a local constraint 834 and the maximum message size of the originator, it is transmitted to 835 the originator of the GetBulkRequest-PDU. Otherwise, the 836 snmpSilentDrops [RFC-MIB] counter is incremented and the resultant 837 message is discarded. 839 4.2.3.1. Another Example of Table Traversal 841 This example demonstrates how the GetBulkRequest-PDU can be used as 842 an alternative to the GetNextRequest-PDU. The same traversal of the 843 IP net-to-media table as shown in Section 4.2.2.1 is achieved with 844 fewer exchanges. 846 The SNMP entity supporting the command generator application begins 847 by sending a GetBulkRequest-PDU with the modest max-repetitions value 848 of 2, and containing the indicated OBJECT IDENTIFIER values as the 849 requested variable names: 851 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] 852 ( sysUpTime, 853 ipNetToMediaPhysAddress, 854 ipNetToMediaType ) 856 The SNMP entity supporting the command responder application responds 857 with a Response-PDU: 859 Response (( sysUpTime.0 = "123456" ), 860 ( ipNetToMediaPhysAddress.1.9.2.3.4 = 861 "000010543210" ), 862 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ), 863 ( ipNetToMediaPhysAddress.1.10.0.0.51 = 864 "000010012345" ), 865 ( ipNetToMediaType.1.10.0.0.51 = "static" )) 867 The SNMP entity supporting the command generator application 868 continues with: 870 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] 871 ( sysUpTime, 872 ipNetToMediaPhysAddress.1.10.0.0.51, 873 ipNetToMediaType.1.10.0.0.51 ) 875 The SNMP entity supporting the command responder application responds 876 with: 878 Response (( sysUpTime.0 = "123466" ), 879 ( ipNetToMediaPhysAddress.2.10.0.0.15 = 880 "000010987654" ), 881 ( ipNetToMediaType.2.10.0.0.15 = 882 "dynamic" ), 883 ( ipNetToMediaNetAddress.1.9.2.3.4 = 884 "9.2.3.4" ), 885 ( ipRoutingDiscards.0 = "2" )) 887 Note how, as in the first example, the variable bindings in the 888 response indicate that the end of the table has been reached. The 889 fourth variable binding does so by returning information from the 890 next available column; the fifth variable binding does so by 891 returning information from the first available object 892 lexicographically following the table. This response signals the end 893 of the table to the command generator application. 895 4.2.4. The Response-PDU 897 The Response-PDU is generated by an SNMP entity only upon receipt of 898 a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, 899 SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this 900 document. 902 If the error-status field of the Response-PDU is non-zero, the value 903 fields of the variable bindings in the variable binding list are 904 ignored. 906 If both the error-status field and the error-index field of the 907 Response-PDU are non-zero, then the value of the error-index field is 908 the index of the variable binding (in the variable-binding list of 909 the corresponding request) for which the request failed. The first 910 variable binding in a request's variable-binding list is index one, 911 the second is index two, etc. 913 A compliant SNMP entity supporting a command generator application 914 must be able to properly receive and handle a Response-PDU with an 915 error-status field equal to "noSuchName", "badValue", or "readOnly". 916 (See Section ???3.1.2??? of [RFC2576].) 918 Upon receipt of a Response-PDU, the receiving SNMP entity presents 919 its contents to the application which generated the request with the 920 same request-id value. For more details, see [RFC2572]. 922 4.2.5. The SetRequest-PDU 924 A SetRequest-PDU is generated and transmitted at the request of an 925 application. 927 Upon receipt of a SetRequest-PDU, the receiving SNMP entity 928 determines the size of a message encapsulating a Response-PDU having 929 the same values in its request-id and variable-bindings fields as the 930 received SetRequest-PDU, and the largest possible sizes of the 931 error-status and error-index fields. If the determined message size 932 is greater than either a local constraint or the maximum message size 933 of the originator, then an alternate Response-PDU is generated, 934 transmitted to the originator of the SetRequest-PDU, and processing 935 of the SetRequest-PDU terminates immediately thereafter. This 936 alternate Response-PDU is formatted with the same values in its 937 request-id field as the received SetRequest-PDU, with the value of 938 its error-status field set to "tooBig", the value of its error-index 939 field set to zero, and an empty variable-bindings field. This 940 alternate Response-PDU is then encapsulated into a message. If the 941 size of the resultant message is less than or equal to both a local 942 constraint and the maximum message size of the originator, it is 943 transmitted to the originator of the SetRequest-PDU. Otherwise, the 944 snmpSilentDrops [RFC-MIB] counter is incremented and the resultant 945 message is discarded. Regardless, processing of the SetRequest-PDU 946 terminates. 948 Otherwise, the receiving SNMP entity processes each variable binding 949 in the variable-binding list to produce a Response-PDU. All fields 950 of the Response-PDU have the same values as the corresponding fields 951 of the received request except as indicated below. 953 The variable bindings are conceptually processed as a two phase 954 operation. In the first phase, each variable binding is validated; 955 if all validations are successful, then each variable is altered in 956 the second phase. Of course, implementors are at liberty to 957 implement either the first, or second, or both, of these conceptual 958 phases as multiple implementation phases. Indeed, such multiple 959 implementation phases may be necessary in some cases to ensure 960 consistency. 962 The following validations are performed in the first phase on each 963 variable binding until they are all successful, or until one fails: 965 (1) If the variable binding's name specifies an existing or 966 non-existent variable to which this request is/would be denied 967 access because it is/would not be in the appropriate MIB view, 968 then the value of the Response-PDU's error-status field is set 969 to "noAccess", and the value of its error-index field is set to 970 the index of the failed variable binding. 972 (2) Otherwise, if there are no variables which share the same OBJECT 973 IDENTIFIER prefix as the variable binding's name, and which are 974 able to be created or modified no matter what new value is 975 specified, then the value of the Response-PDU's error-status 976 field is set to "notWritable", and the value of its error-index 977 field is set to the index of the failed variable binding. 979 (3) Otherwise, if the variable binding's value field specifies, 980 according to the ASN.1 language, a type which is inconsistent 981 with that required for all variables which share the same OBJECT 982 IDENTIFIER prefix as the variable binding's name, then the value 983 of the Response-PDU's error-status field is set to "wrongType", 984 and the value of its error-index field is set to the index of 985 the failed variable binding. 987 (4) Otherwise, if the variable binding's value field specifies, 988 according to the ASN.1 language, a length which is inconsistent 989 with that required for all variables which share the same OBJECT 990 IDENTIFIER prefix as the variable binding's name, then the value 991 of the Response-PDU's error-status field is set to 992 "wrongLength", and the value of its error-index field is set to 993 the index of the failed variable binding. 995 (5) Otherwise, if the variable binding's value field contains an 996 ASN.1 encoding which is inconsistent with that field's ASN.1 997 tag, then the value of the Response-PDU's error-status field is 998 set to "wrongEncoding", and the value of its error-index field 999 is set to the index of the failed variable binding. (Note that 1000 not all implementation strategies will generate this error.) 1002 (6) Otherwise, if the variable binding's value field specifies a 1003 value which could under no circumstances be assigned to the 1004 variable, then the value of the Response-PDU's error-status 1005 field is set to "wrongValue", and the value of its error-index 1006 field is set to the index of the failed variable binding. 1008 (7) Otherwise, if the variable binding's name specifies a variable 1009 which does not exist and could not ever be created (even though 1010 some variables sharing the same OBJECT IDENTIFIER prefix might 1011 under some circumstances be able to be created), then the value 1012 of the Response-PDU's error-status field is set to "noCreation", 1013 and the value of its error-index field is set to the index of 1014 the failed variable binding. 1016 (8) Otherwise, if the variable binding's name specifies a variable 1017 which does not exist but can not be created under the present 1018 circumstances (even though it could be created under other 1019 circumstances), then the value of the Response-PDU's 1020 error-status field is set to "inconsistentName", and the value 1021 of its error-index field is set to the index of the failed 1022 variable binding. 1024 (9) Otherwise, if the variable binding's name specifies a variable 1025 which exists but can not be modified no matter what new value is 1026 specified, then the value of the Response-PDU's error-status 1027 field is set to "notWritable", and the value of its error-index 1028 field is set to the index of the failed variable binding. 1030 (10) Otherwise, if the variable binding's value field specifies a 1031 value that could under other circumstances be held by the 1032 variable, but is presently inconsistent or otherwise unable to 1033 be assigned to the variable, then the value of the 1034 Response-PDU's error-status field is set to "inconsistentValue", 1035 and the value of its error-index field is set to the index of 1036 the failed variable binding. 1038 (11) When, during the above steps, the assignment of the value 1039 specified by the variable binding's value field to the specified 1040 variable requires the allocation of a resource which is 1041 presently unavailable, then the value of the Response-PDU's 1042 error-status field is set to "resourceUnavailable", and the 1043 value of its error-index field is set to the index of the failed 1044 variable binding. 1046 (12) If the processing of the variable binding fails for a reason 1047 other than listed above, then the value of the Response-PDU's 1048 error-status field is set to "genErr", and the value of its 1049 error-index field is set to the index of the failed variable 1050 binding. 1052 (13) Otherwise, the validation of the variable binding succeeds. 1054 At the end of the first phase, if the validation of all variable 1055 bindings succeeded, then the value of the Response-PDU's error-status 1056 field is set to "noError" and the value of its error-index field is 1057 zero, and processing continues as follows. 1059 For each variable binding in the request, the named variable is 1060 created if necessary, and the specified value is assigned to it. 1061 Each of these variable assignments occurs as if simultaneously with 1062 respect to all other assignments specified in the same request. 1063 However, if the same variable is named more than once in a single 1064 request, with different associated values, then the actual assignment 1065 made to that variable is implementation-specific. 1067 If any of these assignments fail (even after all the previous 1068 validations), then all other assignments are undone, and the 1069 Response-PDU is modified to have the value of its error-status field 1070 set to "commitFailed", and the value of its error-index field set to 1071 the index of the failed variable binding. 1073 If and only if it is not possible to undo all the assignments, then 1074 the Response-PDU is modified to have the value of its error-status 1075 field set to "undoFailed", and the value of its error-index field is 1076 set to zero. Note that implementations are strongly encouraged to 1077 take all possible measures to avoid use of either "commitFailed" or 1078 "undoFailed" - these two error-status codes are not to be taken as 1079 license to take the easy way out in an implementation. 1081 Finally, the generated Response-PDU is encapsulated into a message, 1082 and transmitted to the originator of the SetRequest-PDU. 1084 4.2.6. The SNMPv2-Trap-PDU 1086 An SNMPv2-Trap-PDU is generated and transmitted by an SNMP entity on 1087 behalf of a notification originator application. The SNMPv2-Trap-PDU 1088 is often used to notify a notification receiver application at a 1089 logically remote SNMP entity that an event has occurred or that a 1090 condition is present. There is no confirmation associated with this 1091 notification delivery mechanism. 1093 The destination(s) to which an SNMPv2-Trap-PDU is sent is determined 1094 in an implementation-dependent fashion by the SNMP entity. The first 1095 two variable bindings in the variable binding list of an 1096 SNMPv2-Trap-PDU are sysUpTime.0 [RFC-MIB] and snmpTrapOID.0 [RFC-MIB] 1097 respectively. If the OBJECTS clause is present in the invocation of 1098 the corresponding NOTIFICATION-TYPE macro, then each corresponding 1099 variable, as instantiated by this notification, is copied, in order, 1100 to the variable-bindings field. If any additional variables are 1101 being included (at the option of the generating SNMP entity), then 1102 each is copied to the variable-bindings field. 1104 4.2.7. The InformRequest-PDU 1106 An InformRequest-PDU is generated and transmitted by an SNMP entity 1107 on behalf of a notification originator application. The 1108 InformRequest-PDU is often used to notify a notification receiver 1109 application that an event has occurred or that a condition is 1110 present. This is a confirmed notification delivery mechanism, 1111 although there is, of course, no guarantee of delivery. 1113 The destination(s) to which an InformRequest-PDU is sent is specified 1114 by the notification originator application. The first two variable 1115 bindings in the variable binding list of an InformRequest-PDU are 1116 sysUpTime.0 [RFC-MIB] and snmpTrapOID.0 [RFC-MIB] respectively. If 1117 the OBJECTS clause is present in the invocation of the corresponding 1118 NOTIFICATION-TYPE macro, then each corresponding variable, as 1119 instantiated by this notification, is copied, in order, to the 1120 variable-bindings field. 1122 Upon receipt of an InformRequest-PDU, the receiving SNMP entity 1123 determines the size of a message encapsulating a Response-PDU with 1124 the same values in its request-id, error-status, error-index and 1125 variable-bindings fields as the received InformRequest-PDU. If the 1126 determined message size is greater than either a local constraint or 1127 the maximum message size of the originator, then an alternate 1128 Response-PDU is generated, transmitted to the originator of the 1129 InformRequest-PDU, and processing of the InformRequest-PDU terminates 1130 immediately thereafter. This alternate Response-PDU is formatted 1131 with the same values in its request-id field as the received 1132 InformRequest-PDU, with the value of its error-status field set to 1133 "tooBig", the value of its error-index field set to zero, and an 1134 empty variable-bindings field. This alternate Response-PDU is then 1135 encapsulated into a message. If the size of the resultant message is 1136 less than or equal to both a local constraint and the maximum message 1137 size of the originator, it is transmitted to the originator of the 1138 InformRequest-PDU. Otherwise, the snmpSilentDrops [RFC-MIB] counter 1139 is incremented and the resultant message is discarded. Regardless, 1140 processing of the InformRequest-PDU terminates. 1142 Otherwise, the receiving SNMP entity: 1144 (1) presents its contents to the appropriate application; 1146 (2) generates a Response-PDU with the same values in its request-id 1147 and variable-bindings fields as the received InformRequest-PDU, 1148 with the value of its error-status field is set to "noError" and 1149 the value of its error-index field is zero; and 1151 (3) transmits the generated Response-PDU to the originator of the 1152 InformRequest-PDU. 1154 5. Notice on Intellectual Property 1156 The IETF takes no position regarding the validity or scope of any 1157 intellectual property or other rights that might be claimed to 1158 pertain to the implementation or use of the technology described in 1159 this document or the extent to which any license under such rights 1160 might or might not be available; neither does it represent that it 1161 has made any effort to identify any such rights. Information on the 1162 IETF's procedures with respect to rights in standards-track and 1163 standards-related documentation can be found in BCP-11. Copies of 1164 claims of rights made available for publication and any assurances of 1165 licenses to be made available, or the result of an attempt made to 1166 obtain a general license or permission for the use of such 1167 proprietary rights by implementors or users of this specification can 1168 be obtained from the IETF Secretariat. 1170 The IETF invites any interested party to bring to its attention any 1171 copyrights, patents or patent applications, or other proprietary 1172 rights which may cover technology that may be required to practice 1173 this standard. Please address the information to the IETF Executive 1174 Director. 1176 6. Acknowledgments 1178 This document is the product of the SNMPv3 Working Group. Some 1179 special thanks are in order to the following Working Group members: 1181 Randy Bush 1182 Jeffrey D. Case 1183 Mike Daniele 1184 Rob Frye 1185 Lauren Heintz 1186 Keith McCloghrie 1187 Russ Mundy 1188 David T. Perkins 1189 Randy Presuhn 1190 Aleksey Romanov 1191 Juergen Schoenwaelder 1192 Bert Wijnen 1194 This version of the document, edited by Randy Presuhn, was initially 1195 based on the work of a design team whose members were: 1197 Jeffrey D. Case 1198 Keith McCloghrie 1199 David T. Perkins 1200 Randy Presuhn 1201 Juergen Schoenwaelder 1203 The previous versions of this document, edited by Keith McCloghrie, 1204 was the result of significant work by four major contributors: 1206 Jeffrey D. Case 1207 Keith McCloghrie 1208 Marshall T. Rose 1209 Steven Waldbusser 1211 Additionally, the contributions of the SNMPv2 Working Group to the 1212 previous versions are also acknowledged. In particular, a special 1213 thanks is extended for the contributions of: 1215 Alexander I. Alten 1216 Dave Arneson 1217 Uri Blumenthal 1218 Doug Book 1219 Kim Curran 1220 Jim Galvin 1221 Maria Greene 1222 Iain Hanson 1223 Dave Harrington 1224 Nguyen Hien 1225 Jeff Johnson 1226 Michael Kornegay 1227 Deirdre Kostick 1228 David Levi 1229 Daniel Mahoney 1230 Bob Natale 1231 Brian O'Keefe 1232 Andrew Pearson 1233 Dave Perkins 1234 Randy Presuhn 1235 Aleksey Romanov 1236 Shawn Routhier 1237 Jon Saperia 1238 Juergen Schoenwaelder 1239 Bob Stewart 1240 Kaj Tesink 1241 Glenn Waters 1242 Bert Wijnen 1244 7. Security Considerations 1246 The protocol defined in this document by itself does not provide a 1247 secure environment. Even if the network itself is secure (for 1248 example by using IPSec), there is no control as to who on the secure 1249 network is allowed to access and GET/SET (read/change) MIB 1250 information. 1252 It is recommended that the implementors consider the security 1253 features as provided by the SNMPv3 framework. Specifically, the use 1254 of the User-based Security Model RFC 2574 [RFC2574] and the 1255 View-based Access Control Model RFC 2575 [RFC2575] is recommended. 1257 It is then a customer/user responsibility to ensure that the SNMP 1258 entity is properly configured so that: 1260 - only those principals (users) having legitimate rights can 1261 access or modify the values of any MIB objects supported by 1262 that entity; 1264 - the occurrence of particular events on the entity will be 1265 communicated appropriately; 1267 - the entity responds appropriately and with due credence to 1268 events and information that have been communicated to it. 1270 8. References 1272 [ASN1] Information processing systems - Open Systems 1273 Interconnection - Specification of Abstract Syntax 1274 Notation One (ASN.1), International Organization for 1275 Standardization. International Standard 8824, December 1276 1987. 1278 [FRAG] Kent, C., and J. Mogul, Fragmentation Considered Harmful, 1279 Proceedings, ACM SIGCOMM '87, Stowe, VT, August 1987. 1281 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1282 USC/Information Sciences Institute, August 1980. 1284 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 1285 "Simple Network Management Protocol", STD 15, RFC 1157, 1286 May 1990. 1288 [RFC1213] McCloghrie, K., and M. Rose, Editors, "Management 1289 Information Base for Network Management of TCP/IP-based 1290 internets: MIB-II", STD 17, RFC 1213, March 1991. 1292 [RFC1155] Rose, M., and K. McCloghrie, "Structure and 1293 Identification of Management Information for TCP/IP-based 1294 Internets", STD 16, RFC 1155, May 1990. 1296 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 1297 STD 16, RFC 1212, March 1991. 1299 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 1300 the SNMP", RFC 1215, March 1991. 1302 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1303 "Introduction to Community-based SNMPv2", RFC 1901, 1304 January 1996. 1306 [RFC2233] McCloghrie, K., and F. Kastenholz, "The Interfaces Group 1307 MIB using SMIv2", RFC 2233, November 1997. 1309 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 1310 "Introduction to Version 3 of the Internet-standard 1311 Network Management Framework", RFC 2570, April 1999. 1313 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 1314 Architecture for Describing SNMP Management Frameworks", 1315 RFC 2571, April 1999. 1317 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, 1318 "Message Processing and Dispatching for the Simple 1319 Network Management Protocol (SNMP)", RFC 2572, April 1320 1999. 1322 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 1323 Applications", RFC 2573, April 1999. 1325 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 1326 (USM) for version 3 of the Simple Network Management 1327 Protocol (SNMPv3)", RFC 2574, April 1999. 1329 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 1330 Access Control Model (VACM) for the Simple Network 1331 Management Protocol (SNMP)", RFC 2575, April 1999. 1333 [RFC2576] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 1334 "Coexistence between Version 1, Version 2, and Version 3 1335 of the Internet-standard Network Management Framework", 1336 RFC 2576, March, 2000. 1338 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1339 Rose, M., and S. Waldbusser, "Structure of Management 1340 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1341 1999. 1343 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1344 Rose, M., and S. Waldbusser, "Textual Conventions for 1345 SMIv2", STD 58, RFC 2579, April 1999. 1347 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1348 Rose, M., and S. Waldbusser, "Conformance Statements for 1349 SMIv2", STD 58, RFC 2580, April 1999. 1351 [RFC-TM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 1352 Waldbusser, "Transport Mappings for the Simple Network 1353 Management Protocol", 1354 , April 2000. 1356 [RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 1358 Waldbusser, "Management Information Base for the Simple 1359 Network Management Protocol", 1360 , April 2000. 1362 9. Editor's Address 1364 Randy Presuhn 1365 BMC Software, Inc. 1366 2141 North First Street 1367 San Jose, CA 95131 1368 USA 1370 Phone: +1 408 546 1006 1371 EMail: randy_presuhn@bmc.com 1373 10. Changes from RFC 1905 1375 These are the changes from RFC 1905: 1377 - Corrected spelling error in copyright statement; 1379 - Updated copyright date; 1381 - Updated with new editor's name and contact information; 1383 - Added notice on intellectual property; 1385 - Cosmetic fixes to layout and typography; 1387 - Added table of contents; 1389 - Title changed; 1391 - Updated document headers and footers; 1393 - Deleted the old clause 2.3, entitled "Access to Management 1394 Information". 1396 - Changed the way in which request-id was defined, though 1397 with the same ultimate syntax and semantics, to avoid 1398 coupling with SMI. This does not affect the protocol in 1399 any way. 1401 - Replaced the word "exception" with the word "error" in the 1402 old clause 4.1. This does not affect the protocol in any 1403 way. 1405 - Deleted the first two paragraphs of the old clause 4.2. 1407 - Clarified the maximum number of variable bindings that an 1408 implementation must support in a PDU. This does not affect 1409 the protocol in any way. 1411 - Replaced occurrences of "SNMPv2 application" with 1412 "application". 1414 - Deleted three sentences in old clause 4.2.3 describing the 1415 handling of an impossible situation. This does not affect 1416 the protocol in any way. 1418 - Clarified the use of the SNMPv2-Trap-Pdu in the old clause 1419 4.2.6. This does not affect the protocol in any way. 1421 - Aligned description of the use of the InformRequest-Pdu in 1422 old clause 4.2.7 with the architecture. This does not 1423 affect the protocol in any way. 1425 - Updated references. 1427 - Re-wrote introduction clause. 1429 - Replaced manager/agent/SNMPv2 entity terminology with 1430 terminology from RFC 2571. This does not affect the 1431 protocol in any way. 1433 - Eliminated IMPORTS from the SMI, replaced with equivalent 1434 in-line ASN.1. This does not affect the protocol in any 1435 way. 1437 - Added notes calling attention to two different 1438 manifestations of reaching the end of a table in the table 1439 walk examples. 1441 - Added content to security considerations clause. 1443 - Updated ASN.1 comment on use of Report-PDU. This does not 1444 affect the protocol in any way. 1446 - Updated acknowledgements section. 1448 11. Issues 1450 This clause will be deleted when this material is published as an 1451 RFC. The issue labels are the same as those used in the on-line 1452 issues list at 1453 ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1905/index.html 1454 1905-1 Done; table of contents added. 1456 1905-2 Done; new title put in. 1458 1905-3 Done; new introduction clause put in. 1460 1905-4 Done; handled as part of 1905-3. 1462 1905-5 Done; clause deleted. 1464 1905-6 Done; clause deleted, terminology changed throughout 1465 the document. 1467 1905-7 Done; resolution was "no change". 1469 1905-8 Done; deleted the old clause 2.3. 1471 1905-9 Done; resolution was "no change". 1473 1905-10 Done; resolution was "no change". 1475 1905-11 Done; resolution was "no change". 1477 1905-12 Done; incorporated suggested text, fixed minor ASN.1 1478 problem. 1480 1905-13 Done; resolution was to change form (but not ultimate 1481 syntax or semantics) of definition of request-id 1482 element. 1484 1905-14 Done; resolution was "no change". 1486 1905-15 Done; ASN.1 comments lined up. 1488 1905-16 Done; resolution was "no change". 1490 1905-17 Done; changed "exception" to "error" in second 1491 paragraph of old clause 4.1. 1493 1905-18 Done; deleted first two paragraphs of old clause 4.2. 1495 1905-19 Done; resolution was "no change". 1497 1905-20 Done; replaced occurrences of "SNMPv2 application" 1498 with "application". 1500 1905-21 Done; though as a side-effect of issue 1905-6's 1501 resolution. 1503 1905-22 Done; clarifying notes added. 1505 1905-23 Done; deleted offending sentences. 1507 1905-24 Done; resolution was "no change". 1509 1905-25 Done; added note to example. 1511 1905-26 Done; resolution was "no change". 1513 1905-27 Done; resolution was "no change". 1515 1905-28 Done; replaced first paragraph of old clause 4.2.6. 1517 1905-29 Done; replaced first paragraph of old clause 4.2.7. 1519 1905-30 Done; added content to security considerations clause. 1521 1905-31 Done; references updated; acknowledgments updated. 1523 1905-32 Done; added clarifying text. 1525 1905-33 Done; IPR and copyright material updated. 1527 1905-34 Done; headers and footers updated appropriately. 1529 1905-35 Done; resolution was "no change". 1531 1905-36 Done; though original resolution was "no change", this 1532 was effectively superseded by the resolution to 1533 1905-12. 1535 1905-37 Done; resolution was "no change". 1537 12. Full Copyright Statement 1539 Copyright (C) The Internet Society (2000). All Rights Reserved. 1541 This document and translations of it may be copied and furnished to 1542 others, and derivative works that comment on or otherwise explain it 1543 or assist in its implementation may be prepared, copied, published 1544 and distributed, in whole or in part, without restriction of any 1545 kind, provided that the above copyright notice and this paragraph are 1546 included on all such copies and derivative works. However, this 1547 document itself may not be modified in any way, such as by removing 1548 the copyright notice or references to the Internet Society or other 1549 Internet organizations, except as needed for the purpose of 1550 developing Internet standards in which case the procedures for 1551 copyrights defined in the Internet Standards process must be 1552 followed, or as required to translate it into languages other than 1553 English. 1555 The limited permissions granted above are perpetual and will not be 1556 revoked by the Internet Society or its successors or assigns. 1558 This document and the information contained herein is provided on an 1559 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1560 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1561 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1562 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1563 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.