idnits 2.17.1 draft-various-snmpv2-proto-syn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 356 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 5 instances 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 317: '... -- MUST be identical in...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 1995) is 10443 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 section? '0' on line 347 looks like a reference -- Missing reference section? '1' on line 350 looks like a reference -- Missing reference section? '2' on line 353 looks like a reference -- Missing reference section? '3' on line 258 looks like a reference -- Missing reference section? '4' on line 261 looks like a reference -- Missing reference section? '5' on line 264 looks like a reference -- Missing reference section? '6' on line 268 looks like a reference -- Missing reference section? '7' on line 272 looks like a reference -- Missing reference section? '8' on line 276 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Protocol Operations for SNMPv2 September 1995 3 Protocol Operations 4 for Version 2 of the 5 Simple Network Management Protocol (SNMPv2) 7 Fri Sep 08 1995 9 draft-various-snmpv2-proto-syn-01.txt 11 Tell U. Later 12 snmpv2@tis.com 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference material 24 or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 29 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 31 running list of open issues 32 reference list 33 reference citations 34 acknowledgements 35 authors 36 author addresses 37 spell check 39 1. Introduction 41 A management system contains: several (potentially many) manageable 42 nodes, each with a processing entity, termed an agent, which has access 43 to management instrumentation; at least one management station; and, a 44 management protocol. The management protocol is used to convey 45 management information between the agents and management stations; and, 46 for manager-to-manager communications, between management stations. 47 Operations of the protocol are carried out under an administrative 48 framework which defines authentication, authorization, access control, 49 and privacy policies. 51 Management stations execute management applications which monitor and 52 control managed elements. Managed elements are devices such as hosts, 53 routers, terminal servers, etc., which are monitored and controlled via 54 access to their management information. 56 Management information is viewed as a collection of managed objects, 57 residing in a virtual information store, termed the Management 58 Information Base (MIB). Collections of related objects are defined in 59 MIB modules. These modules are written using a subset of OSI's Abstract 60 Syntax Notation One (ASN.1) [@ref asn.1], termed the Structure of 61 Management Information (SMI) [@ref v2smi]. 63 The management protocol, version 2 of the Simple Network Management 64 Protocol, provides for the exchange of messages which convey management 65 information between the agents and the management stations. The form of 66 these messages is a message "wrapper" which encapsulates a Protocol Data 67 Unit (PDU). The form and meaning of the "wrapper" is determined by an 68 administrative framework which defines both authentication and 69 authorization policies. 71 It is the purpose of this document, Protocol Operations for SNMPv2, to 72 define the operations of the protocol with respect to the sending and 73 receiving of the PDUs. 75 1.1. A Note on Terminology 77 For the purpose of exposition, the original Internet-standard Network 78 Management Framework, as described in RFCs 1155, 1157, and 1212, is 79 termed the SNMP version 1 framework (SNMPv1). The current framework is 80 termed the SNMP version 2 framework (SNMPv2). 82 2. Overview 84 2.1. Roles of Protocol Entities 86 A SNMPv2 entity may operate in a manager role or an agent role. 88 A SNMPv2 entity acts in an agent role when it performs SNMPv2 management 89 operations in response to received SNMPv2 protocol messages (other than 90 an inform notification) or when it sends trap notifications. 92 A SNMPv2 entity acts in a manager role when it initiates SNMPv2 93 management operations by the generation of SNMPv2 protocol messages or 94 when it performs SNMPv2 management operations in response to received 95 trap or inform notifications. 97 A SNMPv2 entity may support either or both roles, as dictated by its 98 implementation and configuration. Further, a SNMPv2 entity can also act 99 in the role of a proxy agent, in which it appears to be acting in an 100 agent role, but satisfies management requests by acting in a manager 101 role with a remote entity. The use of proxy agents and the transparency 102 principle that defines their behavior is described in [@ref v2admin]. 104 2.2. Management Information 106 The term, variable, refers to an instance of a non-aggregate object type 107 defined according to the conventions set forth in the SMI [@ref v2smi] 108 or the textual conventions based on the SMI [@ref tc]. The term, 109 variable binding, normally refers to the pairing of the name of a 110 variable and its associated value. However, if certain kinds of 111 exceptional conditions occur during processing of a retrieval request, a 112 variable binding will pair a name and an indication of that exception. 114 A variable-binding list is a simple list of variable bindings. 116 The name of a variable is an OBJECT IDENTIFIER which is the 117 concatenation of the OBJECT IDENTIFIER of the corresponding object-type 118 together with an OBJECT IDENTIFIER fragment identifying the instance. 119 The OBJECT IDENTIFIER of the corresponding object-type is called the 120 OBJECT IDENTIFIER prefix of the variable. 122 2.3. Access to Management Information 124 Three types of access to management information are provided by the 125 protocol. One type is a request-response interaction, in which a SNMPv2 126 entity, acting in a manager role, sends a request to a SNMPv2 entity, 127 acting in an agent role, and the latter SNMPv2 entity then responds to 128 the request. This type is used to retrieve or modify management 129 information associated with the managed device. 131 A second type is also a request-response interaction, in which a SNMPv2 132 entity, acting in a manager role, sends a request to a SNMPv2 entity, 133 also acting in a manager role, and the latter SNMPv2 entity then 134 responds to the request. This type is used to notify a SNMPv2 entity, 135 acting in a manager role, of management information associated with 136 another SNMPv2 entity, also acting in a manager role. 138 The third type of access is an unconfirmed interaction, in which a 139 SNMPv2 entity, acting in an agent role, sends a unsolicited message, 140 termed a trap, to a SNMPv2 entity, acting in a manager role, and no 141 response is returned. This type is used to notify a SNMPv2 entity, 142 acting in a manager role, of an exceptional situation, which has 143 resulted in changes to management information associated with the 144 managed device. 146 2.4. Retransmission of Requests 148 For all types of requests in this protocol, the receiver is required 149 under normal circumstances, to generate and transmit a response to the 150 originator of the request. Whether or not a request should be 151 retransmitted if no corresponding response is received in an appropriate 152 time interval, is at the discretion of the application originating the 153 request. This will normally depend on the urgency of the request. 154 However, such an application needs to act responsibly in respect to the 155 frequency and duration of re-transmissions. 157 2.5. Message Sizes 159 The maximum size of a SNMPv2 message is limited by the minimum of: 161 (1) the maximum message size which the destination SNMPv2 entity can 162 accept; and, 164 (2) the maximum message size which the source SNMPv2 entity can 165 generate. 167 The former may be known on a per-recipient basis; and in the absence of 168 such knowledge, is indicated by transport domain used when sending the 169 message. The latter is imposed by implementation-specific local 170 constraints. 172 Each transport mapping for the SNMPv2 indicates the minimum message size 173 which a SNMPv2 implementation must be able to produce or consume. 174 Although implementations are encouraged to support larger values 175 whenever possible, a conformant implementation must never generate 176 messages larger than allowed by the receiving SNMPv2 entity. 178 One of the aims of the GetBulkRequest-PDU, specified in this protocol, 179 is to minimize the number of protocol exchanges required to retrieve a 180 large amount of management information. As such, this PDU type allows a 181 SNMPv2 entity acting in a manager role to request that the response be 182 as large as possible given the constraints on message sizes. These 183 constraints include the limits on the size of messages which the SNMPv2 184 entity acting in an agent role can generate, and the SNMPv2 entity 185 acting in a manager role can receive. 187 However, it is possible that such maximum sized messages may be larger 188 than the Path MTU of the path across the network traversed by the 189 messages. In this situation, such messages are subject to 190 fragmentation. Fragmentation is generally considered to be harmful 191 [@ref fragmentation], since among other problems, it leads to a decrease 192 in the reliability of the transfer of the messages. Thus, a SNMPv2 193 entity which sends a GetBulkRequest-PDU must take care to set its 194 parameters accordingly, so as to reduce the risk of fragmentation. In 195 particular, under conditions of network stress, only small values should 196 be used for max-repetitions. 198 2.6. Transport Mappings 200 It is important to note that the exchange of SNMPv2 messages requires 201 only an unreliable datagram service, with every message being entirely 202 and independently contained in a single transport datagram. Specific 203 transport mappings and encoding rules are specified elsewhere [@ref tm]. 204 However, the preferred mapping is the use of the User Datagram Protocol 205 [@ref udp]. 207 3. Definitions 209 SNMPv2-PDU DEFINITIONS ::= BEGIN 211 IMPORTS 212 ObjectName, ObjectSyntax, Integer32 213 FROM SNMPv2-SMI; 215 -- protocol data units 216 -- These are carried in an SnmpV2Message defined in [@ref v2admin] or 217 -- an SNMPV2CMessage defined in [@ref v2Cadmin] | 219 PDUs ::= 220 CHOICE { 221 get-request 222 GetRequest-PDU, 224 get-next-request 225 GetNextRequest-PDU, 227 get-bulk-request 228 GetBulkRequest-PDU, 230 response 231 Response-PDU, 233 set-request 234 SetRequest-PDU, 236 inform-request 237 InformRequest-PDU, 239 snmpV2-trap 240 SNMPv2-Trap-PDU 241 } 243 -- PDUs 245 GetRequest-PDU ::= 246 [0] 247 IMPLICIT PDU 249 GetNextRequest-PDU ::= 250 [1] 251 IMPLICIT PDU 253 Response-PDU ::= 254 [2] 255 IMPLICIT PDU 257 SetRequest-PDU ::= 258 [3] 259 IMPLICIT PDU 261 -- [4] is obsolete 263 GetBulkRequest-PDU ::= 264 [5] 265 IMPLICIT BulkPDU 267 InformRequest-PDU ::= 268 [6] 269 IMPLICIT PDU 271 SNMPv2-Trap-PDU ::= 272 [7] 273 IMPLICIT PDU 275 Report-PDU ::= 276 [8] 277 IMPLICIT PDU 279 max-bindings 280 INTEGER ::= 2147483647 282 PDU ::= 283 SEQUENCE { 284 request-id 285 Integer32, 287 error-status -- sometimes ignored 288 INTEGER { 289 noError(0), 290 tooBig(1), 291 noSuchName(2), -- for proxy compatibility 292 badValue(3), -- for proxy compatibility 293 readOnly(4), -- for proxy compatibility 294 genErr(5), 295 noAccess(6), 296 wrongType(7), 297 wrongLength(8), 298 wrongEncoding(9), 299 wrongValue(10), 300 noCreation(11), 301 inconsistentValue(12), 302 resourceUnavailable(13), 303 commitFailed(14), 304 undoFailed(15), 305 authorizationError(16), 306 notWritable(17), 307 inconsistentName(18) 308 }, 310 error-index -- sometimes ignored 311 INTEGER (0..max-bindings), 313 variable-bindings -- values are sometimes ignored 314 VarBindList 315 } 317 BulkPDU ::= -- MUST be identical in 318 SEQUENCE { -- structure to PDU 319 request-id 320 Integer32, 322 non-repeaters 323 INTEGER (0..max-bindings), 325 max-repetitions 326 INTEGER (0..max-bindings), 328 variable-bindings -- values are ignored 329 VarBindList 330 } 332 -- variable binding 334 VarBind ::= 335 SEQUENCE { 336 name 337 ObjectName, 339 CHOICE { 340 value 341 ObjectSyntax, 343 unSpecified -- in retrieval requests 344 NULL, 346 -- exceptions in responses 347 noSuchObject[0] 348 IMPLICIT NULL, 350 noSuchInstance[1] 351 IMPLICIT NULL, 353 endOfMibView[2] 354 IMPLICIT NULL 355 } 356 } 358 -- variable-binding list 360 VarBindList ::= 361 SEQUENCE (SIZE (0..max-bindings)) OF 362 VarBind 364 END 366 4. Protocol Specification 368 4.1. Common Constructs 370 The value of the request-id field in a Response-PDU takes the value of 371 the request-id field in the request PDU to which it is a response. By 372 use of the request-id value, a SNMPv2 application can distinguish the 373 (potentially multiple) outstanding requests, and thereby correlate 374 incoming responses with outstanding requests. In cases where an 375 unreliable datagram service is used, the request-id also provides a 376 simple means of identifying messages duplicated by the network. Use of 377 the same request-id on a retransmission of a request allows the response 378 to either the original transmission or the retransmission to satisfy the 379 request. However, in order to calculate the round trip time for 380 transmission and processing of a request-response transaction, the 381 SNMPv2 application needs to use a different request-id value on a 382 retransmitted request. The latter strategy is recommended for use in 383 the majority of situations. 385 A non-zero value of the error-status field in a Response-PDU is used to 386 indicate that an exception occurred to prevent the processing of the 387 request. In these cases, a non-zero value of the Response-PDU's error- 388 index field provides additional information by identifying which 389 variable binding in the list caused the exception. A variable binding 390 is identified by its index value. The first variable binding in a 391 variable-binding list is index one, the second is index two, etc. 393 SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128 sub- 394 identifiers, where each sub-identifier has a maximum value of 2**32-1. 396 4.2. PDU Processing 398 SNMPv2 entities acting in a manager role generate the following PDU 399 types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, 400 SetRequest-PDU, InformRequest-PDU, Response-PDU, and Report-PDU; 401 further, such implementations receive the following PDU types: 402 Response-PDU, SNMPv2-Trap-PDU, InformRequest-PDU, and Report-PDU. 404 SNMPv2 entities acting in an agent role generate the following PDU 405 types: Response-PDU, SNMPv2-Trap-PDU, and Report-PDU; further, such 406 implementations receive the following PDU types: GetRequest-PDU, 407 GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU. 409 In the elements of procedure below, any field of a PDU which is not 410 referenced by the relevant procedure is ignored by the receiving SNMPv2 411 entity. However, all components of a PDU, including those whose values 412 are ignored by the receiving SNMPv2 entity, must have valid ASN.1 syntax 413 and encoding. For example, some PDUs (e.g., the GetRequest-PDU) are 414 concerned only with the name of a variable and not its value. In this 415 case, the value portion of the variable binding is ignored by the 416 receiving SNMPv2 entity. The unSpecified value is defined for use as 417 the value portion of such bindings. 419 For all generated PDUs, the message "wrapper" to encapsulate the PDU is 420 generated according to the "Elements of Procedure" of the Administrative 421 Framework as specified in [@ref v2admin], including the invocation of 422 the specific procedures called for by the authentication and privacy 423 mechanisms, if any, in effect for the message. While the definition of 424 "max-bindings" does impose an upper-bound on the number of variable 425 bindings, in practice, the size of a message is limited only by 426 constraints on the maximum message size -- it is not limited by the 427 number of variable bindings. 429 On receiving a management communication, the message "wrapper" which 430 encapsulates the PDU is processed according to the "Elements of 431 Procedure" of the Administrative Framework as specified in [@ref 432 v2admin], including the invocation of the specific procedures called for 433 by the authentication and privacy mechanism, if any, in effect for the 434 message. If those procedures indicate that the operation contained 435 within the message is to be performed locally, then those procedures 436 also indicate the MIB view which is visible to the operation, and, if 437 applicable, the maximum message size associated with the originator of 438 the message. 440 4.2.1. The GetRequest-PDU 442 A GetRequest-PDU is generated and transmitted at the request of a SNMPv2 443 application. 445 Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity processes 446 each variable binding in the variable-binding list to produce a 447 Response-PDU. All fields of the Response-PDU have the same values as 448 the corresponding fields of the received request except as indicated 449 below. Each variable binding is processed as follows: 451 (1) If the variable binding's name exactly matches the name of a 452 variable accessible by this request, then the variable binding's 453 value field is set to the value of the named variable. 455 (2) Otherwise, if the variable binding's name does not have an OBJECT 456 IDENTIFIER prefix which exactly matches the OBJECT IDENTIFIER 457 prefix of any (potential) variable accessible by this request, then 458 its value field is set to `noSuchObject'. 460 (3) Otherwise, the variable binding's value field is set to to 461 `noSuchInstance'. 463 If the processing of any variable binding fails for a reason other than 464 listed above, then the Response-PDU is re-formatted with the same values 465 in its request-id and variable-bindings fields as the received 466 GetRequest-PDU, with the value of its error-status field set to 467 `genErr', and the value of its error-index field is set to the index of 468 the failed variable binding. 470 Otherwise, the value of the Response-PDU's error-status field is set to 471 `noError', and the value of its error-index field is zero. 473 The generated Response-PDU is then encapsulated into a message. If the 474 size of the resultant message is less than or equal to both a local 475 constraint and the maximum message size of the originator, it is 476 transmitted to the originator of the GetRequest-PDU. 478 Otherwise, an alternate Response-PDU is generated. This alternate 479 Response-PDU is formatted with the same value in its request-id field as 480 the received GetRequest-PDU, with the value of its error-status field 481 set to `tooBig', the value of its error-index field set to zero, and an 482 empty variable-bindings field. This alternate Response-PDU is then 483 encapsulated into a message. If the size of the resultant message is 484 less than or equal to both a local constraint and the maximum message 485 size of the originator, it is transmitted to the originator of the 486 GetRequest-PDU. Otherwise, the snmpSilentDrops | 487 [@ref v2mib4v2] counter is incremented and the resultant message is 488 discarded. 490 4.2.2. The GetNextRequest-PDU 492 A GetNextRequest-PDU is generated and transmitted at the request of a 493 SNMPv2 application. 495 Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2 entity 496 processes each variable binding in the variable-binding list to produce 497 a Response-PDU. All fields of the Response-PDU have the same values as 498 the corresponding fields of the received request except as indicated 499 below. Each variable binding is processed as follows: 501 (1) The variable is located which is in the lexicographically ordered 502 list of the names of all variables which are accessible by this 503 request and whose name is the first lexicographic successor of the 504 variable binding's name in the incoming GetNextRequest-PDU. The 505 corresponding variable binding's name and value fields in the 506 Response-PDU are set to the name and value of the located variable. 508 (2) If the requested variable binding's name does not lexicographically 509 precede the name of any variable accessible by this request, i.e., 510 there is no lexicographic successor, then the corresponding 511 variable binding produced in the Response-PDU has its value field 512 set to `endOfMibView', and its name field set to the variable 513 binding's name in the request. 515 If the processing of any variable binding fails for a reason other than 516 listed above, then the Response-PDU is re-formatted with the same values 517 in its request-id and variable-bindings fields as the received 518 GetNextRequest-PDU, with the value of its error-status field set to 519 `genErr', and the value of its error-index field is set to the index of 520 the failed variable binding. 522 Otherwise, the value of the Response-PDU's error-status field is set to 523 `noError', and the value of its error-index field is zero. 525 The generated Response-PDU is then encapsulated into a message. If the 526 size of the resultant message is less than or equal to both a local 527 constraint and the maximum message size of the originator, it is 528 transmitted to the originator of the GetNextRequest-PDU. 530 Otherwise, an alternate Response-PDU is generated. This alternate 531 Response-PDU is formatted with the same values in its request-id field 532 as the received GetNextRequest-PDU, with the value of its error-status 533 field set to `tooBig', the value of its error-index field set to zero, 534 and an empty variable-bindings field. This alternate Response-PDU is 535 then encapsulated into a message. If the size of the resultant message 536 is less than or equal to both a local constraint and the maximum message 537 size of the originator, it is transmitted to the originator of the 538 GetNextRequest-PDU. Otherwise, the snmpSilentDrops | 539 [@ref v2mib4v2] counter is incremented and the resultant message is 540 discarded. 542 4.2.2.1. Example of Table Traversal 544 An important use of the GetNextRequest-PDU is the traversal of 545 conceptual tables of information within a MIB. The semantics of this 546 type of request, together with the method of identifying individual 547 instances of objects in the MIB, provides access to related objects in 548 the MIB as if they enjoyed a tabular organization. 550 In the protocol exchange sketched below, a SNMPv2 application retrieves 551 the media-dependent physical address and the address-mapping type for 552 each entry in the IP net-to-media Address Translation Table [@ref 553 v2ipmib2] of a particular network element. It also retrieves the value 554 of sysUpTime [@ref v2mib4v2], at which the mappings existed. Suppose 555 that the agent's IP net-to-media table has three entries: 557 Interface-Number Network-Address Physical-Address Type 559 1 10.0.0.51 00:00:10:01:23:45 static 560 1 9.2.3.4 00:00:10:54:32:10 dynamic 561 2 10.0.0.15 00:00:10:98:76:54 dynamic 563 The SNMPv2 entity acting in a manager role begins by sending a 564 GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values as 565 the requested variable names: 567 GetNextRequest ( sysUpTime, 568 ipNetToMediaPhysAddress, 569 ipNetToMediaType ) 571 The SNMPv2 entity acting in an agent role responds with a Response-PDU: 573 Response (( sysUpTime.0 = "123456" ), 574 ( ipNetToMediaPhysAddress.1.9.2.3.4 = 575 "000010543210" ), 576 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" )) 578 The SNMPv2 entity acting in a manager role continues with: 580 GetNextRequest ( sysUpTime, 581 ipNetToMediaPhysAddress.1.9.2.3.4, 582 ipNetToMediaType.1.9.2.3.4 ) 584 The SNMPv2 entity acting in an agent role responds with: 586 Response (( sysUpTime.0 = "123461" ), 587 ( ipNetToMediaPhysAddress.1.10.0.0.51 = 588 "000010012345" ), 589 ( ipNetToMediaType.1.10.0.0.51 = "static" )) 591 The SNMPv2 entity acting in a manager role continues with: 593 GetNextRequest ( sysUpTime, 594 ipNetToMediaPhysAddress.1.10.0.0.51, 595 ipNetToMediaType.1.10.0.0.51 ) 597 The SNMPv2 entity acting in an agent role responds with: 599 Response (( sysUpTime.0 = "123466" ), 600 ( ipNetToMediaPhysAddress.2.10.0.0.15 = 601 "000010987654" ), 602 ( ipNetToMediaType.2.10.0.0.15 = "dynamic" )) 604 The SNMPv2 entity acting in a manager role continues with: 606 GetNextRequest ( sysUpTime, 607 ipNetToMediaPhysAddress.2.10.0.0.15, 608 ipNetToMediaType.2.10.0.0.15 ) 610 As there are no further entries in the table, the SNMPv2 entity acting 611 in an agent role responds with the variables that are next in the 612 lexicographical ordering of the accessible object names, for example: 614 Response (( sysUpTime.0 = "123471" ), 615 ( ipNetToMediaNetAddress.1.9.2.3.4 = 616 "9.2.3.4" ), 617 ( ipRoutingDiscards.0 = "2" )) 619 This response signals the end of the table to the SNMPv2 entity acting 620 in a manager role. 622 It is worthwhile to note that the data an agent accesses may be stored 623 internally in any arbitrary order. It is the agent's responsibility to 624 provide external access in the prescribed lexicographic order. 626 4.2.3. The GetBulkRequest-PDU 628 A GetBulkRequest-PDU is generated and transmitted at the request of a 629 SNMPv2 application. The purpose of the GetBulkRequest-PDU is to request 630 the transfer of a potentially large amount of data, including, but not 631 limited to, the efficient and rapid retrieval of large tables. 633 Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2 entity 634 processes each variable binding in the variable-binding list to produce 635 a Response-PDU with its request-id field having the same value as in the 636 request. Processing begins by examining the values in the non-repeaters 637 and max-repetitions fields. If the value in the non-repeaters field is 638 less than zero, then the value of the field is set to zero. Similarly, 639 if the value in the max-repetitions field is less than zero, then the 640 value of the field is set to zero. 642 For the GetBulkRequest-PDU type, the successful processing of each 643 variable binding in the request generates zero or more variable bindings 644 in the Response-PDU. That is, the one-to-one mapping between the 645 variable bindings of the GetRequest-PDU, GetNextRequest-PDU, and 646 SetRequest-PDU types and the resultant Response-PDUs does not apply for 647 the mapping between the variable bindings of a GetBulkRequest-PDU and 648 the resultant Response-PDU. 650 The values of the non-repeaters and max-repetitions fields in the 651 request specify the processing requested. One variable binding in the 652 Response-PDU is requested for the first N variable bindings in the 653 request and M variable bindings are requested for each of the R 654 remaining variable bindings in the request. Consequently, the total 655 number of requested variable bindings communicated by the request is 656 given by N + (M * R), where N is the minimum of: a) the value of the 657 non-repeaters field in the request, and b) the number of variable 658 bindings in the request; M is the value of the max-repetitions field in 659 the request; and R is the maximum of: a) number of variable bindings in 660 the request - N, and b) zero. 662 The receiving SNMPv2 entity produces a Response-PDU with up to the total 663 number of requested variable bindings communicated by the request. The 664 request-id shall have the same value as the received GetBulkRequest-PDU. 666 If N is greater than zero, the first through the (N)-th variable 667 bindings of the Response-PDU are each produced as follows: 669 (1) The variable is located which is in the lexicographically ordered 670 list of the names of all variables which are accessible by this 671 request and whose name is the first lexicographic successor of the 672 variable binding's name in the incoming GetBulkRequest-PDU. The 673 corresponding variable binding's name and value fields in the 674 Response-PDU are set to the name and value of the located variable. 676 (2) If the requested variable binding's name does not lexicographically 677 precede the name of any variable accessible by this request, i.e., 678 there is no lexicographic successor, then the corresponding 679 variable binding produced in the Response-PDU has its value field 680 set to `endOfMibView', and its name field set to the variable 681 binding's name in the request. 683 If M and R are non-zero, the (N + 1)-th and subsequent variable bindings 684 of the Response-PDU are each produced in a similar manner. For each 685 iteration i, such that i is greater than zero and less than or equal to 686 M, and for each repeated variable, r, such that r is greater than zero 687 and less than or equal to R, the (N + ( (i-1) * R ) + r)-th variable 688 binding of the Response-PDU is produced as follows: 690 (1) The variable which is in the lexicographically ordered list of the 691 names of all variables which are accessible by this request and 692 whose name is the (i)-th lexicographic successor of the (N + r)-th 693 variable binding's name in the incoming GetBulkRequest-PDU is 694 located and the variable binding's name and value fields are set to 695 the name and value of the located variable. 697 (2) If there is no (i)-th lexicographic successor, then the 698 corresponding variable binding produced in the Response-PDU has its 699 value field set to `endOfMibView', and its name field set to either 700 the last lexicographic successor, or if there are no lexicographic 701 successors, to the (N + r)-th variable binding's name in the 702 request. 704 While the maximum number of variable bindings in the Response-PDU is 705 bounded by N + (M * R), the response may be generated with a lesser 706 number of variable bindings (possibly zero) for either of three reasons. 708 (1) If the size of the message encapsulating the Response-PDU 709 containing the requested number of variable bindings would be 710 greater than either a local constraint or the maximum message size 711 of the originator, then the response is generated with a lesser 712 number of variable bindings. This lesser number is the ordered set 713 of variable bindings with some of the variable bindings at the end 714 of the set removed, such that the size of the message encapsulating 715 the Response-PDU is approximately equal to but no greater than 716 either a local constraint or the maximum message size of the 717 originator. Note that the number of variable bindings removed has 718 no relationship to the values of N, M, or R. 720 (2) The response may also be generated with a lesser number of variable 721 bindings if for some value of iteration i, such that i is greater 722 than zero and less than or equal to M, that all of the generated 723 variable bindings have the value field set to the `endOfMibView'. 724 In this case, the variable bindings may be truncated after the (N + 725 (i * R))-th variable binding. 727 (3) In the event that the processing of a request with many repetitions 728 requires a significantly greater amount of processing time than a 729 normal request, then an agent may terminate the request with less 730 than the full number of repetitions, providing at least one 731 repetition is completed. 733 If the processing of any variable binding fails for a reason other than 734 listed above, then the Response-PDU is re-formatted with the same values 735 in its request-id and variable-bindings fields as the received 736 GetBulkRequest-PDU, with the value of its error-status field set to 737 `genErr', and the value of its error-index field is set to the index of 738 the variable binding in the original request which corresponds to the 739 failed variable binding. 741 Otherwise, the value of the Response-PDU's error-status field is set to 742 `noError', and the value of its error-index field to zero. 744 The generated Response-PDU (possibly with an empty variable-bindings 745 field) is then encapsulated into a message. If the size of the 746 resultant message is less than or equal to both a local constraint and 747 the maximum message size of the originator, it is transmitted to the 748 originator of the GetBulkRequest-PDU. Otherwise, the snmpSilentDrops | 749 [@ref v2mib4v2] counter is incremented and the resultant message is 750 discarded. 752 4.2.3.1. Another Example of Table Traversal 754 This example demonstrates how the GetBulkRequest-PDU can be used as an 755 alternative to the GetNextRequest-PDU. The same traversal of the IP 756 net-to-media table as shown in Section 4.2.2.1 is achieved with fewer 757 exchanges. 759 The SNMPv2 entity acting in a manager role begins by sending a 760 GetBulkRequest-PDU with the modest max-repetitions value of 2, and 761 containing the indicated OBJECT IDENTIFIER values as the requested 762 variable names: 764 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] 765 ( sysUpTime, 766 ipNetToMediaPhysAddress, 767 ipNetToMediaType ) 769 The SNMPv2 entity acting in an agent role responds with a Response-PDU: 771 Response (( sysUpTime.0 = "123456" ), 772 ( ipNetToMediaPhysAddress.1.9.2.3.4 = 773 "000010543210" ), 774 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ), 775 ( ipNetToMediaPhysAddress.1.10.0.0.51 = 776 "000010012345" ), 777 ( ipNetToMediaType.1.10.0.0.51 = "static" )) 779 The SNMPv2 entity acting in a manager role continues with: 781 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] 782 ( sysUpTime, 783 ipNetToMediaPhysAddress.1.10.0.0.51, 784 ipNetToMediaType.1.10.0.0.51 ) 786 The SNMPv2 entity acting in an agent role responds with: 788 Response (( sysUpTime.0 = "123466" ), 789 ( ipNetToMediaPhysAddress.2.10.0.0.15 = 790 "000010987654" ), 791 ( ipNetToMediaType.2.10.0.0.15 = 792 "dynamic" ), 793 ( ipNetToMediaNetAddress.1.9.2.3.4 = 794 "9.2.3.4" ), 795 ( ipRoutingDiscards.0 = "2" )) 797 This response signals the end of the table to the SNMPv2 entity acting 798 in a manager role. 800 4.2.4. The Response-PDU 802 The Response-PDU is generated by a SNMPv2 entity only upon receipt of a 803 GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, 804 or InformRequest-PDU, as described elsewhere in this document. 806 If the error-status field of the Response-PDU is non-zero, the value 807 fields of the variable bindings in the variable binding list are 808 ignored. 810 If both the error-status field and the error-index field of the 811 Response-PDU are non-zero, then the value of the error-index field is 812 the index of the variable binding (in the variable-binding list of the 813 corresponding request) for which the request failed. The first variable 814 binding in a request's variable-binding list is index one, the second is 815 index two, etc. 817 A compliant SNMPv2 entity acting in a manager role must be able to 818 properly receive and handle a Response-PDU with an error-status field 819 equal to `noSuchName', `badValue', or `readOnly', in addition to the 820 error-status values generated by SNMPv2 entities. (See Section 3.1.2 of 821 [@ref coex].) 823 Upon receipt of a Response-PDU, the receiving SNMPv2 entity presents its 824 contents to the SNMPv2 application which generated the request with the 825 same request-id value. 827 4.2.5. The SetRequest-PDU 829 A SetRequest-PDU is generated and transmitted at the request of a SNMPv2 830 application. 832 Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity determines 833 the size of a message encapsulating a Response-PDU having the same 834 values in its request-id and variable-bindings fields as the received 835 SetRequest-PDU, and the largest possible sizes of the error-status and 836 error-index fields. If the determined message size is greater than 837 either a local constraint or the maximum message size of the originator, 838 then an alternate Response-PDU is generated, transmitted to the 839 originator of the SetRequest-PDU, and processing of the SetRequest-PDU 840 terminates immediately thereafter. This alternate Response-PDU is 841 formatted with the same values in its request-id field as the received 842 SetRequest-PDU, with the value of its error-status field set to 843 `tooBig', the value of its error-index field set to zero, and an empty 844 variable-bindings field. This alternate Response-PDU is then 845 encapsulated into a message. If the size of the resultant message is 846 less than or equal to both a local constraint and the maximum message 847 size of the originator, it is transmitted to the originator of the 848 SetRequest-PDU. Otherwise, the snmpSilentDrops | 849 [@ref v2mib4v2] counter is incremented and the resultant message is 850 discarded. Regardless, processing of the SetRequest-PDU terminates. 852 Otherwise, the receiving SNMPv2 entity processes each variable binding 853 in the variable-binding list to produce a Response-PDU. All fields of 854 the Response-PDU have the same values as the corresponding fields of the 855 received request except as indicated below. 857 The variable bindings are conceptually processed as a two phase 858 operation. In the first phase, each variable binding is validated; if 859 all validations are successful, then each variable is altered in the 860 second phase. Of course, implementors are at liberty to implement 861 either the first, or second, or both, of these conceptual phases as 862 multiple implementation phases. Indeed, such multiple implementation 863 phases may be necessary in some cases to ensure consistency. 865 The following validations are performed in the first phase on each 866 variable binding until they are all successful, or until one fails: 868 (1) If the variable binding's name specifies an existing or non- 869 existent variable to which this request is/would be denied access 870 because it is/would not be in the appropriate MIB view, then the 871 value of the Response-PDU's error-status field is set to 872 `noAccess', and the value of its error-index field is set to the 873 index of the failed variable binding. 875 (2) Otherwise, if there are no variables which share the same OBJECT 876 IDENTIFIER prefix as the variable binding's name, and which are 877 able to be created or modified no matter what new value is 878 specified, then the value of the Response-PDU's error-status field 879 is set to `notWritable', and the value of its error-index field is 880 set to the index of the failed variable binding. 882 (3) Otherwise, if the variable binding's value field specifies, 883 according to the ASN.1 language, a type which is inconsistent with 884 that required for all variables which share the same OBJECT 885 IDENTIFIER prefix as the variable binding's name, then the value of 886 the Response-PDU's error-status field is set to `wrongType', and 887 the value of its error-index field is set to the index of the 888 failed variable binding. 890 (4) Otherwise, if the variable binding's value field specifies, 891 according to the ASN.1 language, a length which is inconsistent 892 with that required for all variables which share the same OBJECT 893 IDENTIFIER prefix as the variable binding's name, then the value of 894 the Response-PDU's error-status field is set to `wrongLength', and 895 the value of its error-index field is set to the index of the 896 failed variable binding. 898 (5) Otherwise, if the variable binding's value field contains an ASN.1 899 encoding which is inconsistent with that field's ASN.1 tag, then 900 the value of the Response-PDU's error-status field is set to 901 `wrongEncoding', and the value of its error-index field is set to 902 the index of the failed variable binding. (Note that not all 903 implementation strategies will generate this error.) 905 (6) Otherwise, if the variable binding's value field specifies a value 906 which could under no circumstances be assigned to the variable, 907 then the value of the Response-PDU's error-status field is set to 908 `wrongValue', and the value of its error-index field is set to the 909 index of the failed variable binding. 911 (7) Otherwise, if the variable binding's name specifies a variable 912 which does not exist and could not ever be created (even though 913 some variables sharing the same OBJECT IDENTIFIER prefix might 914 under some circumstances be able to be created), then the value of 915 the Response-PDU's error-status field is set to `noCreation', and 916 the value of its error-index field is set to the index of the 917 failed variable binding. 919 (8) Otherwise, if the variable binding's name specifies a variable 920 which does not exist but can not be created under the present 921 circumstances (even though it could be created under other 922 circumstances), then the value of the Response-PDU's error-status 923 field is set to `inconsistentName', and the value of its error- 924 index field is set to the index of the failed variable binding. 926 (9) Otherwise, if the variable binding's name specifies a variable 927 which exists but can not be modified no matter what new value is 928 specified, then the value of the Response-PDU's error-status field 929 is set to `notWritable', and the value of its error-index field is 930 set to the index of the failed variable binding. 932 (10) Otherwise, if the variable binding's value field specifies a value 933 that could under other circumstances be held by the variable, but 934 is presently inconsistent or otherwise unable to be assigned to the 935 variable, then the value of the Response-PDU's error-status field 936 is set to `inconsistentValue', and the value of its error-index 937 field is set to the index of the failed variable binding. 939 (11) When, during the above steps, the assignment of the value specified 940 by the variable binding's value field to the specified variable 941 requires the allocation of a resource which is presently 942 unavailable, then the value of the Response-PDU's error-status 943 field is set to `resourceUnavailable', and the value of its error- 944 index field is set to the index of the failed variable binding. 946 (12) If the processing of the variable binding fails for a reason other 947 than listed above, then the value of the Response-PDU's error- 948 status field is set to `genErr', and the value of its error-index 949 field is set to the index of the failed variable binding. 951 (13) Otherwise, the validation of the variable binding succeeds. 953 At the end of the first phase, if the validation of all variable 954 bindings succeeded, then the value of the Response-PDU's error-status 955 field is set to `noError' and the value of its error-index field is 956 zero, and processing continues as follows. 958 For each variable binding in the request, the named variable is created 959 if necessary, and the specified value is assigned to it. Each of these 960 variable assignments occurs as if simultaneously with respect to all 961 other assignments specified in the same request. However, if the same 962 variable is named more than once in a single request, with different 963 associated values, then the actual assignment made to that variable is 964 implementation-specific. 966 If any of these assignments fail (even after all the previous 967 validations), then all other assignments are undone, and the Response- 968 PDU is modified to have the value of its error-status field set to 969 `commitFailed', and the value of its error-index field set to the index 970 of the failed variable binding. 972 If and only if it is not possible to undo all the assignments, then the 973 Response-PDU is modified to have the value of its error-status field set 974 to `undoFailed', and the value of its error-index field is set to zero. 975 Note that implementations are strongly encouraged to take all possible 976 measures to avoid use of either `commitFailed' or `undoFailed' - these 977 two error-status codes are not to be taken as license to take the easy 978 way out in an implementation. 980 Finally, the generated Response-PDU is encapsulated into a message, and 981 transmitted to the originator of the SetRequest-PDU. 983 4.2.6. The SNMPv2-Trap-PDU 985 A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity acting 986 in an agent role when an exceptional situation occurs. 988 An SNMPv2 entity wishing to send an SNMPv2-Trap, provides: 990 - A trap type (a snmpTrapOID.0 value) 992 - A context local entity value 994 - A variable binding list 996 A variable binding list is constructed with the first two variable 997 bindings in the variable binding list as sysUpTime.0 [@ref v2mib4v2] and 998 snmpTrapOID.0 [@ref v2mib4v2] respectively, followed by any additional 999 variables which the generating SNMPv2 entity provides to include within 1000 this SNMPv2-Trap-PDU. 1002 The notifyTable is scanned in conjunction with the v2ContextTable to 1003 select all notifyTable entries such that the context local entity 1004 provided by the application is equal to the context local entity 1005 associated with the context named in the notifyTable entry. 1007 For each such selected entry in which all variable bindings in the 1008 constructed variable binding list are included in the view named by that 1009 selected entry, 1011 - the values for notifySPI, notifyIdentityName, notifyContextName, 1012 and notifyTransportLabel are extracted from the selected entry; 1014 - a request id is generated, and a pdu is built with the generated 1015 value of request id, zero-valued error status and error index 1016 fields, and the constructed variable bindings list; 1018 - a ScopedPDU is constructed using the extracted value of 1019 notifyContextName, the local value of snmpID, and the just-built 1020 PDUs value; and 1022 - According to the SNMPv2 administrative model, [@ref v2admin], a 1023 requesting application must provide the required sPI, authSnmpID, 1024 identityName, ScopedPDU, and transport information in order to 1025 generate a message. Consequently, the generating entity then 1026 requests that an appropriate SnmpV2Message value be generated and 1027 sent, using 1029 - the extracted value of notifySPI as the sPI; 1031 - the local value of snmpID as the authSnmpID; 1033 - the selected entry's value of notifyIdentityName as the identityName; 1035 - the ScopedPDU value; and 1037 - the [possibly multiple] destinations named by the extracted value of 1038 notifyTransportLabel. 1040 In the interest of clarity, it is worth noting that the request-id of 1041 the generated traps is the same within a given selected notifyTable 1042 entry, but different between notifyTable entries. That is, this 1043 procedure generates potentially multiple trap messages due to 1044 potentially multiple notifyTable entries being selected and potentially 1045 multiple transportTable entries associated with one or more selections. 1046 The request-id should be the same for all traps emitted for a given 1047 event and a given notifyTable entry (where multiple messages are due to 1048 multiple transport entries), but should be different for all traps | 1049 emitted across various notifyTable entries. | 1051 4.2.7. The InformRequest-PDU 1053 An InformRequest-PDU is generated and transmitted at the request an 1054 application in a SNMPv2 entity acting in a manager role, that wishes to 1055 notify another application (in a SNMPv2 entity also acting in a manager 1056 role) of information known by the sending application. 1058 The destination(s) to which an InformRequest-PDU is sent is specified by 1059 the requesting application and/or in consultation with appropriate MIB 1060 objects such as the notificationTable [@ref adminmib]. 1062 The first two variable bindings in the variable binding list of an 1063 InformRequest-PDU are sysUpTime.0 [@ref v2mib4v2] and snmpTrapOID.0 1064 [@ref v2mib4v2] respectively. If the OBJECTS clause is present in the 1065 invocation of the corresponding NOTIFICATION-TYPE macro, then each 1066 corresponding variable, as instantiated by this notification, is copied, 1067 in order, to the variable-bindings field. The application may also 1068 choose to add additional variable bindings to the InformRequest-PDU. 1070 Upon receipt of an InformRequest-PDU, the receiving SNMPv2 entity 1071 determines the size of a message encapsulating a Response-PDU with the 1072 same values in its request-id, error-status, error-index and variable- 1073 bindings fields as the received InformRequest-PDU. If the determined 1074 message size is greater than either a local constraint or the maximum 1075 message size of the originator, then an alternate Response-PDU is 1076 generated, transmitted to the originator of the InformRequest-PDU, and 1077 processing of the InformRequest-PDU terminates immediately thereafter. 1078 This alternate Response-PDU is formatted with the same values in its 1079 request-id field as the received InformRequest-PDU, with the value of 1080 its error-status field set to `tooBig', the value of its error-index 1081 field set to zero, and an empty variable-bindings field. This alternate 1082 Response-PDU is then encapsulated into a message. If the size of the 1083 resultant message is less than or equal to both a local constraint and 1084 the maximum message size of the originator, it is transmitted to the 1085 originator of the InformRequest-PDU. Otherwise, the snmpSilentDrops | 1086 [@ref v2mib4v2] counter is incremented and the resultant message is 1087 discarded. Regardless, processing of the InformRequest-PDU terminates. 1089 Otherwise, the receiving SNMPv2 entity: 1091 (1) presents its contents to the appropriate SNMPv2 application; 1093 (2) generates a Response-PDU with the same values in its request-id and 1094 variable-bindings fields as the received InformRequest-PDU, with 1095 the value of its error-status field is set to `noError' and the 1096 value of its error-index field is zero; and 1098 (3) transmits the generated Response-PDU to the originator of the 1099 InformRequest-PDU. 1101 4.2.8. Report-PDU 1103 A Report-PDU is generated and transmitted at the request of the SNMPv2 1104 protocol entity implementing the administrative model or an 1105 authentication and privacy service within that model. In this regard, 1106 messages containing Report-PDUs are somewhat akin to IP [@ref ip] 1107 messages containing ICMP [@ref icmp] information. The sending 1108 application is the SNMPv2 protocol entity itself or the authentication 1109 and privacy service. 1111 Messages containing a Report-PDU are almost always generated in response 1112 to a problem or error condition encountered when processing a received 1113 message. While processing a received communication, an SNMPv2 protocol 1114 entity may determine that the message is unacceptable. In this case, 1115 the appropriate counter from the snmp object group [@ref v2mib4v2] or | 1116 from an | 1117 appropriate MIB which accompanies the definition of an authentication 1118 and privacy service, e.g., [@ref newusec]. If, after incrementing the 1119 appropriate counter, the procedures require the generation of a report, 1120 then the PDU is constructed as follows: 1121 the request-id field is set to the value of the request-id of the 1122 received communication which caused the error if it can be determined, 1123 and 2147483647 otherwise; 1124 the error-status and error-index fields of the report PDU are always set 1125 to zero; and 1126 the variable-bindings field. 1128 As of this writing, all uses of the the report PDU require that the 1129 variable-bindings field contain that single variable: the identity of 1130 the statistics counter which was incremented when the error condition 1131 was detected. 1133 Future uses of the Report-PDU may include additional variable-bindings. 1135 Upon receipt of a Report-PDU, the receiving SNMPv2 protocol entity 1136 invokes the proper corrective behavior, (e.g., time synchronization, 1137 proxy error propagation, etc.), if any. 1139 5. Acknowledgements 1141 To be provided here. 1143 6. References 1145 To be provided here. 1147 7. Security Considerations 1149 Security issues are not discussed in this memo. 1151 8. Authors' Addresses 1153 Tell U. Later 1154 snmpv2@tis.com 1156 Table of Contents 1158 1 Introduction .................................................... 3 1159 1.1 A Note on Terminology ......................................... 3 1160 2 Overview ........................................................ 4 1161 2.1 Roles of Protocol Entities .................................... 4 1162 2.2 Management Information ........................................ 4 1163 2.3 Access to Management Information .............................. 5 1164 2.4 Retransmission of Requests .................................... 5 1165 2.5 Message Sizes ................................................. 5 1166 2.6 Transport Mappings ............................................ 6 1167 3 Definitions ..................................................... 7 1168 4 Protocol Specification .......................................... 12 1169 4.1 Common Constructs ............................................. 12 1170 4.2 PDU Processing ................................................ 12 1171 4.2.1 The GetRequest-PDU .......................................... 13 1172 4.2.2 The GetNextRequest-PDU ...................................... 14 1173 4.2.2.1 Example of Table Traversal ................................ 16 1174 4.2.3 The GetBulkRequest-PDU ...................................... 18 1175 4.2.3.1 Another Example of Table Traversal ........................ 20 1176 4.2.4 The Response-PDU ............................................ 22 1177 4.2.5 The SetRequest-PDU .......................................... 22 1178 4.2.6 The SNMPv2-Trap-PDU ......................................... 26 1179 4.2.7 The InformRequest-PDU ....................................... 27 1180 4.2.8 Report-PDU .................................................. 28 1181 5 Acknowledgements ................................................ 30 1182 6 References ...................................................... 30 1183 7 Security Considerations ......................................... 31 1184 8 Authors' Addresses .............................................. 31