idnits 2.17.1 draft-ietf-snmpv3-coex-03.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: ---------------------------------------------------------------------------- ** 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. == 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 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 14 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([13], [14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document obsoletes RFC1908, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 505 has weird spacing: '...rameter snmp...' == Line 997 has weird spacing: '...ailable gen...' == Line 1802 has weird spacing: '...for the purpo...' -- 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 (10 Feb 1999) is 9207 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) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1303 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '6') ** Obsolete normative reference: RFC 1902 (ref. '7') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '8') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '9') (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (ref. '10') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (ref. '12') (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (ref. '13') (Obsoleted by RFC 2576) ** Obsolete normative reference: RFC 2089 (ref. '14') (Obsoleted by RFC 2576) Summary: 19 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Rob Frye 2 MCI Communications Corp. 3 David B. Levi 4 SNMP Research, Inc. 5 Shawn A. Routhier 6 Integrated Systems Inc. 7 Bert Wijnen 8 IBM T.J. Watson Research 9 10 Feb 1999 11 Coexistence between Version 1, Version 2, and Version 3 12 of the Internet-standard Network Management Framework 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (1999). All Rights Reserved. 38 Abstract 40 The purpose of this document is to describe coexistence between 41 version 3 of the Internet-standard Network Management Framework, 42 (SNMPv3), version 2 of the Internet-standard Network Management 43 Framework (SNMPv2), and the original Internet-standard Network 44 Management Framework (SNMPv1). This document obsoletes RFC 1908 [13] 45 and RFC2089 [14]. 47 Table Of Contents 49 1 Overview ..................................................... 4 50 1.1 SNMPv1 ..................................................... 4 51 1.2 SNMPv2 ..................................................... 5 52 1.3 SNMPv3 ..................................................... 6 53 1.4 SNMPv1 and SNMPv2 MIB Instrumentation ...................... 6 54 2 SMI and Management Information Mappings ...................... 8 55 2.1 Object Definitions ......................................... 8 56 2.2 Trap and Notification Definitions .......................... 10 57 2.3 Compliance Statements ...................................... 11 58 2.4 Capabilities Statements .................................... 11 59 3 Translating Notifications Parameters ......................... 13 60 3.1 Translating SNMPv1 Notification Parameters to SNMPv2 No- 61 tification Parameters ..................................... 14 62 3.2 Translating SNMPv2 Notification Parameters to SNMPv1 No- 63 tification Parameters ..................................... 15 64 4 Approaches to Coexistence in a Multi-lingual Network ......... 18 65 4.1 Multi-lingual implementations .............................. 18 66 4.1.1 Command Generator ........................................ 18 67 4.1.2 Command Responder ........................................ 18 68 4.1.2.1 Handling Counter64 ..................................... 19 69 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20 70 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 20 71 4.1.2.2.2 Mapping endOfMibView ................................. 21 72 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21 73 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22 74 4.1.3 Notification Originator .................................. 23 75 4.1.4 Notification Receiver .................................... 24 76 4.2 Proxy Implementations ...................................... 24 77 4.3 Error Status Mappings ...................................... 26 78 5 Message Processing Models and Security Models ................ 27 79 5.1 Mappings ................................................... 27 80 5.2 The SNMPv1 Message Processing Model ........................ 27 81 5.2.1 Processing An Incoming Request ........................... 28 82 5.2.2 Generating An Outgoing Response .......................... 30 83 5.2.3 Generating An Outgoing Notification ...................... 30 84 5.3 The SNMP Community MIB Module .............................. 31 85 6 Intellectual Property ........................................ 41 86 7 Acknowledgments .............................................. 42 87 8 Security Considerations ...................................... 43 88 9 References ................................................... 44 89 10 Editor's Address ............................................ 46 90 A. Full Copyright Statement .................................... 47 92 1. Overview 94 The purpose of this document is to describe coexistence between 95 version 3 of the Internet-standard Network Management Framework, 96 termed the SNMP version 3 framework (SNMPv3), version 2 of the 97 Internet-standard Network Management Framework, termed the SNMP 98 version 2 framework (SNMPv2), and the original Internet-standard 99 Network Management Framework (SNMPv1). 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC2119 [15]. 105 There are four general aspects of coexistence described in this 106 document. Each of these is described in a separate section: 108 - Conversion of MIB documents between SMIv1 and SMIv2 formats is 109 documented in section 2. 111 - Mapping of notification parameters is documented in section 3. 113 - Approaches to coexistence between entities which support the 114 various versions of SNMP in a multi-lingual network is 115 documented in section 4. This section addresses the 116 processing of protocol operations in multi-lingual 117 implementations, as well as behaviour of proxy 118 implementations. 120 - The SNMPv1 Message Processing Model and Community-Based 121 Security Model, which provides mechanisms for adapting SNMPv1 122 into the View-Based Access Control Model (VACM) [20], is 123 documented in section 5 (this section also addresses the 124 SNMPv2c Message Processing Model and Community-Based Security 125 Model). 127 1.1. SNMPv1 129 SNMPv1 is defined by these documents: 131 - STD 16, RFC 1155 [1] which defines the Structure of Management 132 Information (SMIv1), the mechanisms used for describing and 133 naming objects for the purpose of management. 135 - STD 16, RFC 1212 [3] which defines a more concise description 136 mechanism, which is wholly consistent with the SMIv1. 138 - STD 15, RFC 1157 [2] which defines the Simple Network 139 Management Protocol (SNMPv1), the protocol used for network 140 access to managed objects. 142 - RFC 1215 [4] which defines a convention for defining Traps for 143 use with the SMIv1. 145 Note that throughout this document, the term 'SMIv1' is used. This 146 term generally refers to the information presented in RFC 1155, RFC 147 1212, and RFC 1215. 149 1.2. SNMPv2 151 SNMPv2 is defined by these documents: 153 - RFC 1902 which defines Version 2 of the Structure of 154 Management Information (SMIv2) [7]. 156 - RFC 1903 which defines common MIB "Textual Conventions" [8]. 158 - RFC 1904 which defines Conformance Statements and requirements 159 for defining agent and manager capabilities [9]. 161 - RFC 1905 which defines the Protocol Operations used in 162 processing [10]. 164 - RFC 1906 which defines the Transport Mappings used "on the 165 wire" [11]. 167 - RFC 1907 which defines the basic Management Information Base 168 upon which other MIBs can be built [12]. 170 Note that SMIv2 as used throughout this document refers to the first 171 three documents listed above (RFCs 1902, 1903, and 1904). 173 The following document augments the definition of SNMPv2: 175 - RFC 1901 [6] is an Experimental definition for using SNMPv2 176 PDUs within a community-based message wrapper. This is 177 referred to throughout this document as SNMPv2c. 179 1.3. SNMPv3 181 SNMPv3 is defined by these documents: 183 - RFC 2271 which defines an Architecture for Describing SNMP 184 Management Frameworks [16]. 186 - RFC 2272 which defines Message Processing and Dispatching 187 [17]. 189 - RFC 2273 which defines various SNMP Applications [18]. 191 - RFC 2274 which defines the User-based Security Model (USM), 192 providing for both Authenticated and Private (encrypted) SNMP 193 messages [19]. 195 - RFC 2275 which defines the View-based Access Control Model 196 (VACM), providing the ability to limit access to different MIB 197 objects on a per-user basis [20]. 199 SNMPv3 also uses the SNMPv2 definitions of RFCs 1902 through 1907 200 described above. 202 1.4. SNMPv1 and SNMPv2 MIB Instrumentation 204 In several places, this document refers to 'SNMPv1 MIB 205 Instrumentation' and 'SNMPv2 MIB Instrumentation'. These terms refer 206 to the part of an SNMP agent which actually implements MIB objects, 207 and which actually initiates generation of notifications. 208 Differences between the two types of MIB instrumentation are: 210 - Error-status values generated. 212 - Generation of exception codes. 214 - Use of the Counter64 data type. 216 - The format of parameters provided when a notification is 217 generated. 219 SNMPv1 MIB instrumentation will generate SNMPv1 error-status values, 220 will never generate exception codes nor use the Counter64 data type, 221 and will provide SNMPv1 format parameters for generating 222 notifications. Note also that SNMPv1 MIB instrumentation will 223 actually never generate a readOnly error (a noSuchName error would 224 always occur in the situation where one would expect a readOnly 225 error). 227 SNMPv2 MIB instrumentation will generate SNMPv2 error-status values, 228 will generate exception codes, will use the Counter64 data type, and 229 will provide SNMPv2 format parameters for generating notifications. 230 Note that SNMPv2 MIB instrumentation will never generate readOnly, 231 noSuchName, or badValue errors. 233 Note that a particular multi-lingual implementation may choose to 234 implement all MIB instrumentation as SNMPv2 MIB instrumentation. 236 2. SMI and Management Information Mappings 238 The SMIv2 approach towards describing collections of managed objects 239 is nearly a proper superset of the approach defined in the SMIv1. 240 For example, both approaches use an adapted subset of ASN.1 (1988) 241 [11] as the basis for a formal descriptive notation. Indeed, one 242 might note that the SMIv2 approach largely codifies the existing 243 practice for defining MIB modules, based on extensive experience with 244 the SMIv1. 246 The following sections consider the three areas: MIB modules, 247 compliance statements, and capabilities statements. 249 MIB modules defined using the SMIv1 may continue to be used with 250 protocol versions which use SNMPv2 PDUs. However, for the MIB 251 modules to conform to the SMIv2, the following changes SHALL be made: 253 2.1. Object Definitions 255 In general, conversion of a MIB module does not require the 256 deprecation of the objects contained therein. If the semantics of an 257 object truly changes, the object SHALL be deprecated, otherwise 258 deprecation is not required. 260 (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of 261 RFC1155-SMI and RFC-1212. 263 (2) The MODULE-IDENTITY macro MUST be invoked immediately after any 264 IMPORTs statement. 266 (3) For any object with an integer-valued SYNTAX clause, in which the 267 corresponding INTEGER does not have a range restriction (i.e., the 268 INTEGER has neither a defined set of named-number enumerations nor 269 an assignment of lower- and upper-bounds on its value), the object 270 MUST have the value of its SYNTAX clause changed to Integer32. 272 (4) For any object with a SYNTAX clause value of Counter, the object 273 MUST have the value of its SYNTAX clause changed to Counter32. 275 (5) For any object with a SYNTAX clause value of Gauge, the object MUST 276 have the value of its SYNTAX clause changed to Gauge32. 278 (6) For all objects, the ACCESS clause MUST be replaced by a MAX-ACCESS 279 clause. The value of the MAX-ACCESS clause SHALL be the same as 280 that of the ACCESS clause unless some other value makes "protocol 281 sense" as the maximal level of access for the object. In 282 particular, object types for which instances can be explicitly 283 created by a protocol set operation, SHALL have a MAX-ACCESS clause 284 of "read-create". If the value of the ACCESS clause is "write- 285 only", then the value of the MAX-ACCESS clause MUST be "read- 286 write", and the DESCRIPTION clause SHALL note that reading this 287 object will result in implementation-specific results. 289 (7) For all objects, if the value of the STATUS clause is "mandatory", 290 the value MUST be replaced with "current". 292 (8) For all objects, if the value of the STATUS clause is "optional", 293 the value MUST be replaced with "obsolete". 295 (9) For any object not containing a DESCRIPTION clause, the object MUST 296 have a DESCRIPTION clause defined. 298 (10) For any object corresponding to a conceptual row which does not 299 have an INDEX clause, the object MUST have either an INDEX clause 300 or an AUGMENTS clause defined. 302 (11) For any object with an INDEX clause that references an object with 303 a syntax of NetworkAddress, the value of the STATUS clause of both 304 objects MUST be changed to "obsolete". 306 (12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER 307 value which is expressed as a collection of sub-identifiers, the 308 value MUST be changed to reference a single ASN.1 identifier. This 309 may require defining a series of new objects in order to define the 310 single ASN.1 identifier. 312 Other changes are desirable, but not necessary: 314 (1) Creation and deletion of conceptual rows is inconsistent using the 315 SMIv1. The SMIv2 corrects this. As such, if the MIB module 316 undergoes review early in its lifetime, and it contains conceptual 317 tables which allow creation and deletion of conceptual rows, then 318 the objects relating to those tables MAY be deprecated and replaced 319 with objects defined using the new approach. The new approach can 320 be found in section 7 of RFC1902 [7], and the RowStatus and 321 StorageType TEXTUAL-CONVENTIONs are described in section 2 of 322 RFC1903 [8]. 324 (2) For any object with a string-valued SYNTAX clause, in which the 325 corresponding OCTET STRING does not have a size restriction (i.e., 326 the OCTET STRING has no assignment of lower- and upper-bounds on 327 its length), the bounds for the size of the object SHOULD be 328 defined. 330 (3) All textual conventions informally defined in the MIB module SHOULD 331 be redefined using the TEXTUAL-CONVENTION macro. Such a change 332 would not necessitate deprecating objects previously defined using 333 an informal textual convention. 335 (4) For any object which represents a measurement in some kind of 336 units, a UNITS clause SHOULD be added to the definition of that 337 object. 339 (5) For any conceptual row which is an extension of another conceptual 340 row, i.e., for which subordinate columnar objects both exist and 341 are identified via the same semantics as the other conceptual row, 342 an AUGMENTS clause SHOULD be used in place of the INDEX clause for 343 the object corresponding to the conceptual row which is an 344 extension. 346 Finally, to avoid common errors in SMIv1 MIB modules: 348 (1) For any non-columnar object that is instanced as if it were 349 immediately subordinate to a conceptual row, the value of the 350 STATUS clause of that object MUST be changed to "obsolete". 352 (2) For any conceptual row object that is not contained immediately 353 subordinate to a conceptual table, the value of the STATUS clause 354 of that object (and all subordinate objects) MUST be changed to 355 "obsolete". 357 2.2. Trap and Notification Definitions 359 If a MIB module is changed to conform to the SMIv2, then each 360 occurrence of the TRAP-TYPE macro MUST be changed to a corresponding 361 invocation of the NOTIFICATION-TYPE macro: 363 (1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST 364 reference SNMPv2-SMI instead. 366 (2) The ENTERPRISE clause MUST be removed. 368 (3) The VARIABLES clause MUST be renamed to the OBJECTS clause. 370 (4) The STATUS clause MUST be added, with a value of 'current'. 372 (5) The value of an invocation of the NOTIFICATION-TYPE macro is an 373 OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. 374 Specifically, if the value of the ENTERPRISE clause is not 'snmp' 375 then the value of the invocation SHALL be the value of the 376 ENTERPRISE clause extended with two sub-identifiers, the first of 377 which has the value 0, and the second has the value of the 378 invocation of the TRAP-TYPE. 380 (6) The DESCRIPTION clause MUST be added, if not already present. 382 (7) One or more NOTIFICATION-GROUPs SHOULD be defined, and related 383 notifications SHOULD be collected into those groups. 385 2.3. Compliance Statements 387 For those information modules which are "standard", a corresponding 388 invocation of the MODULE-COMPLIANCE macro and related OBJECT-GROUP 389 macros MUST be included within the information module (or in a 390 companion information module), and any commentary text in the 391 information module which relates to compliance SHOULD be removed. 392 Typically this editing can occur when the information module 393 undergoes review. 395 2.4. Capabilities Statements 397 In the SMIv1, RFC1303 [5] uses the MODULE-CONFORMANCE macro to 398 describe an agent's capabilities with respect to one or more MIB 399 modules. Converting such a description for use with the SMIv2 400 requires these changes: 402 (1) The macro name AGENT-CAPABILITIES SHOULD be used instead of MODULE- 403 CONFORMANCE. 405 (2) The STATUS clause SHOULD be added, with a value of 'current'. 407 (3) All occurrences of the CREATION-REQUIRES clause SHOULD either be 408 omitted if appropriate, or be changed such that the semantics are 409 consistent with RFC1904 [9]. 411 In order to ease coexistence, object groups defined in an SMIv1 412 compliant MIB module may be referenced by the INCLUDES clause of an 413 invocation of the AGENT-CAPABILITIES macro: upon encountering a 414 reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB 415 module, all leaf objects which are subordinate to the subtree and 416 have a STATUS clause value of mandatory are deemed to be INCLUDEd. 417 (Note that this method is ambiguous when different revisions of an 418 SMIv1 MIB have different sets of mandatory objects under the same 419 subtree; in such cases, the only solution is to rewrite the MIB using 420 the SMIv2 in order to define the object groups unambiguously.) 422 3. Translating Notifications Parameters 424 This section describes how parameters used for generating 425 notifications are translated between the format used for SNMPv1 426 notification protocol operations and the format used for SNMPv2 427 notification protocol operations. The parameters used to generate a 428 notification are called 'notification parameters'. The format of 429 parameters used for SNMPv1 notification protocol operations is 430 refered to in this document as 'SNMPv1 notification parameters.' The 431 format of parameters used for SNMPv2 notification protocol operations 432 is refered to in this document as 'SNMPv2 notification parameters.' 434 The SMI version used to define a notification will usually determine 435 which type of notification parameters are provided by MIB 436 instrumentation when a notification is generated. 438 The situations where notification parameters MUST be translated are: 440 - When MIB instrumentation in an entity generates a set of 441 notification parameters in a particular format, and the 442 configuration of the entity indicates that the notification 443 must be sent using an SNMP message version that requires the 444 other format for notification parameters. 446 - When a proxy receives a notification that was sent using an 447 SNMP message version that requires one format of notification 448 parameters, and must forward the notification using an SNMP 449 message version that requires the other format of notification 450 parameters. 452 In addition, it MAY be desirable to translate notification parameters 453 in a notification receiver application in order to present 454 notifications to the end user in a consistent format. 456 Note that for the purposes of this section, the set of notification 457 parameters is independent of whether the notification is to be sent 458 as a trap or an inform. 460 SNMPv1 notification parameters consist of: 462 - An enterprise parameter (OBJECT IDENTIFIER). 464 - An agent-addr parameter (NetworkAddress). 466 - A generic-trap parameter (INTEGER). 468 - A specific-trap parameter (INTEGER). 470 - A time-stamp parameter (TimeTicks). 472 - A list of variable-bindings (VarBindList). 474 SNMPv2 notification parameters consist of: 476 - A sysUpTime parameter (TimeTicks). This appears in the first 477 variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU. 479 - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in 480 the second variable-binding in an SNMPv2-Trap-PDU or 481 InformRequest-PDU. 483 - A list of variable-bindings (VarBindList). This refers to all 484 but the first two variable-bindings in an SNMPv2-Trap-PDU or 485 InformRequest-PDU. 487 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification 488 Parameters 490 The following procedure describes how to translate SNMPv1 491 notification parameters into SNMPv2 notification parameters: 493 (1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the 494 SNMPv1 time-stamp parameter. 496 (2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', 497 the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of the 498 SNMPv1 enterprise parameter and two additional sub-identifiers, 499 '0', and the SNMPv1 specific-trap parameter. 501 (3) If the SNMPv1 generic-trap parameter is not 502 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be 503 the corresponding trap as defined in section 2 of RFC1907 [12]: 505 generic-trap parameter snmpTrapOID.0 506 ====================== ============= 507 0 1.3.6.1.6.3.1.1.5.1 (coldStart) 508 1 1.3.6.1.6.3.1.1.5.2 (warmStart) 509 2 1.3.6.1.6.3.1.1.5.3 (linkDown) 510 3 1.3.6.1.6.3.1.1.5.4 (linkUp) 511 4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 512 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 514 (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings. 515 In addition, if the translation is being performed by a proxy in 516 order to forward a received trap, three additional variable- 517 bindings will be appended, if these three additional variable- 518 bindings do not already exist in the SNMPv1 variable-bindings. The 519 name portion of the first variable binding SHALL contain 520 snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent- 521 addr parameter. The name portion of the second variable binding 522 SHALL contain snmpTrapCommunity.0, and the value SHALL contain the 523 value of the community-string field from the received SNMPv1 524 message which contained the SNMPv1 Trap-PDU. The name portion of 525 the third variable binding SHALL contain snmpTrapEnterprise.0 [12], 526 and the value SHALL be the SNMPv1 enterprise parameter. 528 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification 529 Parameters 531 The following procedure describes how to translate SNMPv2 532 notification parameters into SNMPv1 notification parameters: 534 (1) The SNMPv1 enterprise parameter SHALL be determined as follows: 536 - If the SNMPv2 snmpTrapOID parameter is one of the standard 537 traps as defined in RFC1907 [12], then the SNMPv1 enterprise 538 parameter SHALL be set to the value of the variable-binding in 539 the SNMPv2 variable-bindings whose name is 540 snmpTrapEnterprise.0 if that variable-binding exists. If it 541 does not exist, the SNMPv1 enterprise parameter SHALL be set 542 to the value 'snmpTraps' as defined in RFC1907 [12]. 544 - If the SNMPv2 snmpTrapOID parameter is not one of the standard 545 traps as defined in RFC1907 [12], then the SNMPv1 enterprise 546 parameter SHALL be set to the SNMPv2 snmpTrapOID parameter as 547 follows: 549 - If the next-to-last sub-identifier of the snmpTrapOID is 550 zero, then the SMIv1 enterprise SHALL be the SMIv2 551 snmpTrapOID with the last 2 sub-identifiers removed, 552 otherwise 554 - If the next-to-last sub-identifier of the snmpTrapOID is 555 non-zero, then the SMIv1 enterprise SHALL be the SMIv2 556 snmpTrapOID with the last sub-identifier removed. 558 (2) The SNMPv1 agent-addr parameter SHALL be determined based on the 559 situation in which the translation occurs. 561 - If the translation occurs within a notification originator 562 application, and the notification is to be sent over IP, the 563 SNMPv1 agent-addr parameter SHALL be set to the IP address of 564 the SNMP entity in which the notification originator resides. 565 If the notification is to be sent over some other transport, 566 the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. 568 - If the translation occurs within a proxy application, the 569 proxy must attempt to determine the original source of the 570 notification. If the SNMPv2 variable-bindings contains a 571 variable binding whose name is snmpTrapAddress.0, the agent- 572 addr parameter SHALL be set to the value of that variable 573 binding. Otherwise, Otherwise, the SNMPv1 agent-addr 574 parameter SHALL be set to 0.0.0.0. 576 (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as 577 defined in RFC1907 [12], the SNMPv1 generic-trap parameter SHALL be 578 set as follows: 580 snmpTrapOID.0 parameter generic-trap 581 =============================== ============ 582 1.3.6.1.6.3.1.1.5.1 (coldStart) 0 583 1.3.6.1.6.3.1.1.5.2 (warmStart) 1 584 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 585 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 586 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4 587 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 589 Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6. 591 (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as 592 defined in RFC1907 [12], the SNMPv1 specific-trap parameter SHALL 593 be set to zero. Otherwise, the SNMPv1 specific-trap parameter 594 SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID 595 parameter. 597 (5) The SNMPv1 time-stamp parameter SHALL be taken directly from the 598 SNMPv2 sysUpTime parameter. 600 (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings 601 with the following exceptions: 603 - Any variable-binding whose type is Counter64 which exists in 604 the SNMPv2 variable-bindings SHALL be removed. 606 4. Approaches to Coexistence in a Multi-lingual Network 608 There are two basic approaches to coexistence in a multi-lingual 609 network, multi-lingual implementations and proxy implementations. 610 Multi-lingual implementations allow elements in a network to 611 communicate with each other using an SNMP version which both elements 612 support. This allows a multi-lingual implementation to communicate 613 with any mono-lingual implementation, regardless of the SNMP version 614 supported by the mono-lingual implementation. 616 Proxy implementations provide a mechanism for translating between 617 SNMP versions using a third party network element. This allows 618 network elements which support only a single, but different, SNMP 619 version to communicate with each other. Proxy implementations are 620 also useful for securing communications over an insecure link between 621 two locally secure networks. 623 4.1. Multi-lingual implementations 625 This approach requires an entity to support multiple SNMP message 626 versions. Typically this means supporting SNMPv1, SNMPv2c, and 627 SNMPv3 message versions. The behaviour of various types of SNMP 628 applications which support multiple message versions is described in 629 the following sections. This approach allows entities which support 630 multiple SNMP message versions to coexist with and communicate with 631 entities which support only a single SNMP message version. 633 4.1.1. Command Generator 635 A command generator must select an appropriate message version when 636 sending requests to another entity. One way to achieve this is to 637 consult a local database to select the appropriate message version. 639 In addition, a command generator should 'downgrade' GetBulk requests 640 to GetNext requests when selecting SNMPv1 as the message version for 641 an outgoing request. 643 4.1.2. Command Responder 645 A command responder must be able to deal with MIB instrumentation 646 that is written using both the SNMPv1 and SNMPv2. There are three 647 aspects to dealing with this. A command responder must: 649 - Deal correctly with SNMPv2 MIB instrumentation that returns a 650 Counter64 value while processing an SNMPv1 message, 652 - Deal correctly with SNMPv2 MIB instrumentation that returns 653 one of the three exception values while processing an SNMPv1 654 message, and 656 - Map SNMPv2 error codes returned from SNMPv2 MIB 657 instrumentation into SNMPv1 error code when processing an 658 SNMPv1 message. 660 Note that SNMPv1 error codes can be used without any change when 661 processing SNMPv2c or SNMPv3 messages. 663 The following sections describe the behaviour of a command responder 664 application which supports multiple SNMP message versions, and which 665 has access to some combination of SNMPv1 and SNMPv2 MIB 666 instrumentation. 668 4.1.2.1. Handling Counter64 670 The SMIv2 [7] defines one new syntax that is incompatible with SMIv1. 671 This syntax is Counter64. All other syntaxes defined by SMIv2 are 672 compatible with SMIv1. 674 The impact on multi-lingual command responders is that they MUST NOT 675 ever return a variable binding containing a Counter64 value in a 676 response to a request that was received using the SNMPv1 message 677 version. 679 Multi-lingual command responders SHALL take the approach that object 680 instances whose type is Counter64 are implicitly excluded from view 681 when processing an SNMPv1 message. So: 683 - On an SNMPv1 GET request, an error-status of noSuchName SHALL 684 be returned, and the error-index SHALL be set to the variable 685 binding that caused this error. 687 - On an SNMPv1 GetNext request, any object instance which 688 contains a syntax of Counter64 shall be skipped, and the next 689 object instance that follows the one with a syntax of 690 Counter64 SHALL be fetched. This step may need to be repeated 691 several times in order to find an object whose syntax is not 692 Counter64. 694 - Any SET request that has a variable binding with a Counter64 695 value must have come from a SNMPv2 manager, and so it should 696 not cause a problem. However, if an object with SYNTAX of 697 Counter64 is received in an SNMPv1 SET packet, it SHALL result 698 in an ASN.1 parse error since Counter64 is not valid in the 699 SNMPv1 protocol. When an ASN.1 parse error occurs, the counter 700 snmpInASNParseErrs SHALL be incremented and no response is 701 returned. 703 4.1.2.2. Mapping SNMPv2 Exceptions 705 SNMPv2 provides a feature called exceptions, which allow an SNMPv2 706 Response PDU to return as much management information as possible, 707 even when an error occurs. However, SNMPv1 does not support 708 exceptions, and so an SNMPv1 Response PDU cannot return any 709 management information, and can only return an error-status and 710 error-index value. 712 When an SNMPv1 request is received, a command responder MUST check 713 any variable bindings returned from SNMPv2 MIB instrumentation for 714 exception values, and convert these exception values into SNMPv1 715 error codes. 717 The type of exception that can be returned from MIB instrumentation 718 and the action taken depends on the type of SNMP request. 720 - For a GetRequest, a noSuchObject or noSuchInstance exception 721 may be returned. 723 - For a GetNextRequest, an endOfMibView exception may be 724 returned. 726 - No exceptions will be returned for a SetRequest, and a 727 GetBulkRequest should only be received in an SNMPv2c or SNMPv3 728 message, so these request types may be ignored when mapping 729 exceptions. 731 4.1.2.2.1. Mapping noSuchObject and noSuchInstance 733 A noSuchObject or noSuchInstance exception generated by SNMPv2 MIB 734 instrumentation indicates that the requested object instance can not 735 be returned. The SNMPv1 error code for this condition is noSuchName, 736 and so the error-status field of the response PDU SHALL be set to 737 noSuchName. Also, the error-index field SHALL be set to the index of 738 the variable binding for which an exception occurred, and the 739 variable binding list from the original request SHALL be returned 740 with the response PDU. 742 Note that when a response contains multiple exceptions, it is an 743 implementation choice as to which variable binding the error-index 744 should reference. 746 4.1.2.2.2. Mapping endOfMibView 748 When SNMPv2 MIB instrumentation returns a variable binding containing 749 an endOfMibView exception, it indicates that there are no object 750 instances available which lexicographically follow the object in the 751 request. In an SNMPv1 agent, this condition normally results in a 752 noSuchName error, and so the error-status field of the response PDU 753 SHALL be set to noSuchName. Also, the error-index field SHALL be set 754 to the index of the variable binding for which an exception occurred, 755 and the variable binding list from the original request SHALL be 756 returned with the response PDU. 758 Note that when a response contains multiple exceptions, it is an 759 implementation choice as to which variable binding the error-index 760 should reference. 762 4.1.2.3. Processing An SNMPv1 GetRequest 764 When processing an SNMPv1 GetRequest, the following procedures MUST 765 be followed when calling SNMPv2 MIB instrumentation. 767 When such MIB instrumentation returns response data using SNMPv2 768 syntax and error-status values, then: 770 (1) If the error-status is anything other than noError, 772 - The error status SHALL be translated to an SNMPv1 error-status 773 using the table in section 4.3, "Error Status Mappings". 775 - The error-index SHALL be set to the position (in the original 776 request) of the variable binding that caused the error-status. 778 - The variable binding list of the response PDU SHALL be made 779 exactly the same as the variable binding list that was 780 received in the original request. 782 (2) If the error-status is noError, the variable bindings SHALL be 783 checked for any SNMPv2 exception (noSuchObject or noSuchInstance) 784 or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If 785 there are any such variable bindings, one of those variable 786 bindings SHALL be selected (it is an implementation choice as to 787 which is selected), and: 789 - The error-status SHALL be set to noSuchName, 791 - The error-index SHALL be set to the position (in the variable 792 binding list of the original request) of the selected variable 793 binding, and 795 - The variable binding list of the response PDU SHALL be exactly 796 the same as the variable binding list that was received in the 797 original request. 799 (3) If there are no such variable bindings, then: 801 - The error-status SHALL be set to noError, 803 - The error-index SHALL be set to zero, and 805 - The variable binding list of the response SHALL be composed 806 from the data as it is returned by the MIB instrumentation. 808 4.1.2.4. Processing An SNMPv1 GetNextRequest 810 When processing an SNMPv1 GetNextRequest, the following procedures 811 MUST be followed when SNMPv2 MIB instrumentation is called as part of 812 processing the request. There may be repetitive calls to (possibly 813 different pieces of) MIB instrumentation to try to find the first 814 object which lexicographically follows each of the objects in the 815 request. This is implementation specific. These procedures are 816 followed only for data returned from SNMPv2 MIB instrumentation. 817 Data returned from SNMPv1 MIB instrumentation may be treated in the 818 normal manner for an SNMPv1 request. 820 First, if the MIB instrumentation returns an error-status of anything 821 other than noError: 823 (1) The error status SHALL be translated to an SNMPv1 error-status 824 using the table in section 4.3, "Error Status Mappings". 826 (2) The error-index SHALL be set to the position (in the original 827 request) of the variable binding that caused the error-status. 829 (3) The variable binding list of the response PDU SHALL be exactly the 830 same as the variable binding list that was received in the original 831 request. 833 Otherwise, if the MIB instrumentation returns an error-status of 834 noError: 836 (1) Any variable bindings containing an SNMPv2 syntax of Counter64 837 SHALL be considered to be not in view, and the MIB instrumentation 838 SHALL be called as often as is required until either a value other 839 than Counter64 is returned, or an error occurs. 841 (2) If there is any variable binding that contains an SNMPv2 exception 842 endOfMibView (there may be more than one, it is an implementation 843 decision as to which is chosen): 845 - The error-status SHALL be set to noSuchName, 847 - The error-index SHALL be set to the position (in the variable 848 binding list of the original request) of the variable binding 849 that returned such an SNMPv2 exception, and 851 - The variable binding list of the response PDU SHALL be exactly 852 the same as the variable binding list that was received in the 853 original request. 855 (3) If there are no such variable bindings, then: 857 - The error-status SHALL be set to noError, 859 - The error-index SHALL be set to zero, and 861 - The variable binding list of the response SHALL be composed 862 from the data as it is returned by the MIB instrumentation. 864 4.1.3. Notification Originator 866 A notification originator must be able to translate between SNMPv1 867 notifications parameters and SNMPv2 notification parameters in order 868 to send a notification using a particular SNMP message version. If 869 MIB instrumentation presents a notification using SNMPv1 notification 870 parameters, and configuration information specifies that 871 notifications be sent using SNMPv2c or SNMPv3, the notification 872 parameters must be translated to SNMPv2 notification parameters. 873 Likewise, if MIB instrumentation presents a notification using SNMPv2 874 notification parameters, and configuration information specifies that 875 notifications be sent using SNMPv1, the notification parameters must 876 be translated to SNMPv1 notification parameters. 878 When a notification originator generates a notification, using 879 parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION- 880 MIB, if the SNMP version used to generate the notification is SNMPv1, 881 the PDU type used will always be a TrapPDU, regardless of whether the 882 value of snmpNotifyType is trap(1) or inform(2). 884 Note also that access control and notification filtering are 885 performed in the usual manner for notifications, regardless of the 886 SNMP message version to be used when sending a notification. The 887 parameters for performing access control are found in the usual 888 manner (i.e. from inspecting the SNMP-TARGET-MIB and SNMP- 889 NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in 890 order to perform the access check specified in [18], section 3.3, 891 bullet (3), the notification originator may need to generate a value 892 for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of 893 this document. If the SNMPv1 notification parameters being used were 894 previously translated from a set of SNMPv2 notification parameters, 895 this value may already be known, in which case it need not be 896 generated. 898 4.1.4. Notification Receiver 900 There are no special requirements of a notification receiver. 901 However, an implementation may find it useful to allow a higher level 902 application to request whether notifications should be delivered to a 903 higher level application using SNMPv1 notification parameter or 904 SNMPv2 notification parameters. The notification receiver would then 905 translate notification parameters when required in order to present a 906 notification using the desired set of parameters. 908 4.2. Proxy Implementations 910 A proxy implementation may be used to enable communication between 911 entities which support different SNMP message versions. This is 912 accomplished in a proxy forwarder application by performing 913 translations on a PDU in the following situations: 915 - If a GetBulkRequest-PDU is received and must be forwarded 916 using the SNMPv1 message version, the proxy forwarder SHALL 917 set the non-repeaters and max-repetitions fields to 0, and 918 SHALL set the tag of the PDU to GetNextRequest-PDU. 920 - If a GetResponse-PDU is received whose error-status field has 921 a value of 'tooBig', and the message will be forwarded using 922 the SNMPv2c or SNMPv3 message version, the proxy forwarder 923 SHALL remove the contents of the variable-bindings field 924 before forwarding the response. 926 - If a GetResponse-PDU is received which contains variable- 927 bindings of type Counter64 or which contain an SNMPv2 928 exception code, and the message would be forwarded using the 929 SNMPv1 message version, the proxy MUST generate an alternate 930 response PDU consisting of the request-id and variable 931 bindings from the original SNMPv1 request, containing a 932 noSuchName error-status value, and containing an error-index 933 value indicating the position of the variable-binding 934 containing the Counter64 type or exception code. 936 - If a GetResponse-PDU is received which contains an SNMPv2 937 error-status value of wrongValue, wrongEncoding, wrongType, 938 wrongLength, inconsistentValue, noAccess, notWritable, 939 noCreation, inconsistentName, resourceUnavailable, 940 commitFailed, undoFailed, or authorizationError, the error- 941 status value is modified using the mappings in section 4.3. 943 - If a Trap-PDU is received, and will be forwarded using the 944 SNMPv2c or SNMPv3 message version, the proxy SHALL apply the 945 translation rules described in section 3, and SHALL forward 946 the notification as an SNMPv2-Trap-PDU. 948 - If an SNMPv2-Trap-PDU is received, and will be forwarded using 949 the SNMPv1 message version, the proxy SHALL apply the 950 translation rules described in section 3, and SHALL forward 951 the notification as a Trap-PDU. 953 - If an InformRequest-PDU is received, any configuration 954 information indicating that it would be forwarded using the 955 SNMPv1 message version SHALL be ignored. An InformRequest-PDU 956 can only be forwarded using the SNMPv2c or SNMPv3 message 957 version. 959 - In all other cases, the proxy SHALL forward a received PDU 960 without change. 962 Note that when an SNMPv1 agent generates a message containing a 963 Trap-PDU which is subsequently forwarded by one or more proxy 964 forwarders using SNMP versions other than SNMPv1, the community 965 string and agent-addr fields from the original message generated by 966 the SNMPv1 agent will be preserved through the use of the 967 snmpTrapAddress and snmpTrapCommunity objects. 969 4.3. Error Status Mappings 971 The following tables shows the mappings of SNMPv1 error-status values 972 into SNMPv2 error-status values, and the mappings of SNMPv2 error- 973 status values into SNMPv1 error-status values. 975 SNMPv1 error-status SNMPv2 error-status 976 =================== =================== 977 noError noError 978 tooBig tooBig 979 noSuchName noSuchName 980 badValue badValue 981 genErr genErr 983 SNMPv2 error-status SNMPv1 error-status 984 =================== =================== 985 noError noError 986 tooBig tooBig 987 genErr genErr 988 wrongValue badValue 989 wrongEncoding badValue 990 wrongType badValue 991 wrongLength badValue 992 inconsistentValue badValue 993 noAccess noSuchName 994 notWritable noSuchName 995 noCreation noSuchName 996 inconsistentName noSuchName 997 resourceUnavailable genErr 998 commitFailed genErr 999 undoFailed genErr 1000 authorizationError noSuchName 1002 5. Message Processing Models and Security Models 1004 In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, 1005 the following models are defined in this document: 1007 - The SNMPv1 Message Processing Model 1009 - The SNMPv1 Community-Based Security Model 1011 The following models are also described in this document: 1013 - The SNMPv2c Message Processing Model 1015 - The SNMPv2c Community-Based Security Model 1017 In most respects, the SNMPv1 Message Processing Model and the 1018 SNMPv2c Message Processing Model are identical, and so these 1019 are not discussed independently in this document. Differences 1020 between the two models are described as required. 1022 Similarly, the SNMPv1 Community-Based Security Model and the 1023 SNMPv2c Community-Based Security Model are nearly identical, 1024 and so are not discussed independently. Differences between 1025 these two models are also described as required. 1027 5.1. Mappings 1029 The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model 1030 require mappings between parameters used in SNMPv1 (and SNMPv2c) 1031 messages, and the version independent parameters used in the SNMP 1032 architecture [16]. The parameters which MUST be mapped consist of the 1033 SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and 1034 contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB) 1035 is provided in this document in order to perform these mappings. This 1036 MIB provides mappings in both directions, that is, a community name may 1037 be mapped to a securityName, contextEngineID, and contextName, or the 1038 combination of securityName, contextEngineID, and contextName may be 1039 mapped to a community name. 1041 5.2. The SNMPv1 Message Processing Model 1043 The SNMPv1 Message Processing Model handles processing of SNMPv1 1044 messages. The processing of messages is handled generally in the 1045 same manner as described in RFC1157 [2], with differences and 1046 clarifications as described in the following sections. The 1047 SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for 1048 SNMPv2c is 1). 1050 5.2.1. Processing An Incoming Request 1052 In RFC1157 [2], section 4.1, item (3) for an entity which receives a 1053 message, states that various parameters are passed to the 'desired 1054 authentication scheme.' The desired authentication scheme in this 1055 case is the SNMPv1 Community-Based Security Model, which will be 1056 called using the processIncomingMsg ASI. The parameters passed to 1057 this ASI are: 1059 - The messageProcessingModel, which will be 0 (or 1 for 1060 SNMPv2c). 1062 - The maxMessageSize, which should be the maximum size of a 1063 message that the receiving entity can generate (since there is 1064 no such value in the received message). 1066 - The securityParameters, which consist of the community string 1067 and the message's source and destination transport addresses. 1069 - The securityModel, which will be 1 (or 2 for SNMPv2c). 1071 - The securityLevel, which will be noAuthNoPriv. 1073 - The wholeMsg and wholeMsgLength. 1075 The Community-Based Security Model will attempt to select a row in 1076 the snmpCommunityTable. This is done by performing a search through 1077 the snmpCommunityTable in lexicographic order. The first entry for 1078 which the following matching criteria are satisfied will be selected: 1080 - The community string is equal to the snmpCommunityName value. 1082 - If the snmpCommunityTransportTag is not an empty string, the 1083 transportDomain and transportAddress from which the message 1084 was received must match one of the entries in the 1085 snmpTargetAddrTable selected by the snmpCommunityTransportTag 1086 value. If the snmpCommunityTransportTag is an empty string, 1087 it is ignored for the purpose of matching. 1089 If no such entry can be found, an authentication failure occurs as 1090 described in RFC1157 [2]. 1092 The parameters returned from the Community-Based Security Model are: 1094 - The securityEngineID, which will always be the local value of 1095 snmpEngineID.0. 1097 - The securityName. 1099 - The scopedPDU. Note that this parameter will actually consist 1100 of three values, the contextSnmpEngineID, the contextName, and 1101 the PDU. These must be separate values, since the first two 1102 do not actually appear in the message. 1104 - The maxSizeResponseScopedPDU. 1106 - The securityStateReference. 1108 The appropriate SNMP application will then be called (depending on 1109 the value of the contextEngineID and the request type in the PDU) 1110 using the processPdu ASI. The parameters passed to this ASI are: 1112 - The messageProcessingModel, which will be 0 (or 1 for 1113 SNMPv2c). 1115 - The securityModel, which will be 1 (or 2 for SNMPv2c). 1117 - The securityName, which was returned from the call to 1118 processIncomingMsg. 1120 - The securityLevel, which is noAuthNoPriv. 1122 - The contextEngineID, which was returned as part of the 1123 ScopedPDU from the call to processIncomingMsg. 1125 - The contextName, which was returned as part of the ScopedPDU 1126 from the call to processIncomingMsg. 1128 - The pduVersion, which should indicate an SNMPv1 version PDU 1129 (if the message version was SNMPv2c, this would be an SNMPv2 1130 version PDU). 1132 - The PDU, which was returned as part of the ScopedPDU from the 1133 call to processIncomingMsg. 1135 - The maxSizeResponseScopedPDU which was returned from the call 1136 to processIncomingMsg. 1138 - The stateReference which was returned from the call to 1139 processIncomingMsg. 1141 The SNMP application should process the request as described 1142 previously in this document. Note that access control is applied by 1143 an SNMPv3 command responder application as usual. The parameters as 1144 passed to the processPdu ASI will be used in calls to the 1145 isAccessAllowed ASI. 1147 5.2.2. Generating An Outgoing Response 1149 There is no special processing required for generating an outgoing 1150 response. However, the community string used in an outgoing response 1151 must be the same as the community string from the original request. 1152 The original community string MUST be present in the stateReference 1153 information of the original request. 1155 5.2.3. Generating An Outgoing Notification 1157 In a multi-lingual SNMP entity, the parameters used for generating 1158 notifications will be obtained by examining the SNMP-TARGET-MIB and 1159 SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 1160 Message Processing Model using the sendPdu ASI. The SNMPv1 Message 1161 Processing Model will attempt to locate an appropriate community 1162 string in the snmpCommunityTable based on the parameters passed to 1163 the sendPdu ASI. This is done by performing a search through the 1164 snmpCommunityTable in lexicographic order. The first entry for which 1165 the following matching criteria are satisfied will be selected: 1167 - The securityName must be equal to the 1168 snmpCommunitySecurityName value. 1170 - The contextEngineID must be equal to the 1171 snmpCommunityContextEngineID value. 1173 - The contextName must be equal to the snmpCommunityContextName 1174 value. 1176 - If the snmpCommunityTransportTag is not an empty string, the 1177 transportDomain and transportAddress must match one of the 1178 entries in the snmpTargetAddrTable selected by the 1179 snmpCommunityTransportTag value. If the 1180 snmpCommunityTransportTag is an empty string, it is ignored 1181 for the purpose of matching. 1183 If no such entry can be found, the notification is not sent. 1184 Otherwise, the community string used in the outgoing notification 1185 will be the value of the snmpCommunityName column of the selected 1186 row. 1188 5.3. The SNMP Community MIB Module 1190 The SNMP-COMMUNITY-MIB contains objects for mapping between community 1191 strings and version-independent SNMP message parameters. In 1192 addition, this MIB provides a mechanism for performing source address 1193 validation on incoming requests, and for selecting community strings 1194 based on target addresses for outgoing notifications. These two 1195 features are accomplished by providing a tag in the 1196 snmpCommunityTable which selects sets of entries in the 1197 snmpTargetAddrTable [18]. In addition, the SNMP-COMMUNITY-MIB 1198 augments the snmpTargetAddrTable with a transport address mask value 1199 and a maximum message size value. These values are used only where 1200 explicitly stated. In cases where the snmpTargetAddrTable is used 1201 without mention of these augmenting values, the augmenting values 1202 should be ignored. 1204 The mask value, snmpTargetAddrTMask, allows selected entries in the 1205 snmpTargetAddrTable to specify multiple addresses (rather than just a 1206 single address per entry). This would typically be used to specify a 1207 subnet in an snmpTargetAddrTable rather than just a single address. 1208 The mask value is used to select which bits of a transport address 1209 must match bits of the corresponding instance of 1210 snmpTargetAddrTAddress, in order for the transport address to match a 1211 particular entry in the snmpTargetAddrTable. The value of an 1212 instance of snmpTargetAddrTMask must always be an OCTET STRING whose 1213 length is either zero or the same as that of the corresponding 1214 instance of snmpTargetAddrTAddress. 1216 When checking whether a transport address matches an entry in the 1217 snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero- 1218 length OCTET STRING, the mask value is ignored, and the value of 1219 snmpTargetAddrTAddress must exactly match a transport address. 1220 Otherwise, each bit of each octet in the snmpTargetAddrTMask value 1221 corresponds to the same bit of the same octet in the 1222 snmpTargetAddrTAddress value. For bits that are set in the 1223 snmpTargetAddrTMask value (i.e. bits equal to 1), the corresponding 1224 bits in the snmpTargetAddrTAddress value must match the bits in a 1225 transport address. If all such bits match, the transport address is 1226 matched by that snmpTargetAddrTable entry. Otherwise, the transport 1227 address is not matched. 1229 The maximum message size value, snmpTargetAddrMMS, is used to 1230 determine the maximum message size acceptable to another SNMP entity 1231 when the value cannot be determined from the protocol. 1233 SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN 1235 IMPORTS 1236 IpAddress 1237 FROM RFC1155-SMI 1238 MODULE-IDENTITY, 1239 OBJECT-TYPE, 1240 Integer32, 1241 FROM SNMPv2-SMI 1242 RowStatus, 1243 TestAndIncr, 1244 StorageType 1245 FROM SNMPv2-TC 1246 SnmpAdminString 1247 FROM SNMP-FRAMEWORK-MIB 1248 SnmpTagValue 1249 FROM SNMP-TARGET-MIB 1250 MODULE-COMPLIANCE, 1251 OBJECT-GROUP 1252 FROM SNMPv2-CONF; 1254 snmpCommunityMIB MODULE-IDENTITY 1255 LAST-UPDATED "9805110000Z" -- 11 May 1998, midnight 1256 ORGANIZATION "SNMPv3 Working Group" 1257 CONTACT-INFO "WG-email: snmpv3@tis.com 1258 Subscribe: majordomo@tis.com 1259 In msg body: subscribe snmpv3 1261 Chair: Russ Mundy 1262 Trusted Information Systems 1263 postal: 3060 Washington Rd 1264 Glenwood MD 21738 1265 USA 1266 email: mundy@tis.com 1267 phone: +1-301-854-6889 1269 Co-editor: Rob Frye 1270 MCI Communications Corp. 1271 Postal: 2100 Reston Parkway, Suite 600 1272 Reston, VA 20191 1273 USA 1274 E-mail: Rob.Frye@mci.com 1275 Phone: +1 703 715 7225 1277 Co-editor: David B. Levi 1278 SNMP Research, Inc. 1279 Postal: 3001 Kimberlin Heights Road 1280 Knoxville, TN 37920-9716 1281 E-mail: levi@snmp.com 1282 Phone: +1 423 573 1434 1284 Co-editor: Shawn A. Routhier 1285 Integrated Systems Inc. 1286 Postal: 333 North Ave 4th Floor 1287 Wakefield, MA 01880 1288 E-mail: sar@epilogue.com 1289 Phone: +1 781 245 0804 1291 Co-editor: Bert Wijnen 1292 IBM T. J. Watson Research 1293 postal: Schagen 33 1294 3461 GL Linschoten 1295 Netherlands 1296 email: wijnen@vnet.ibm.com 1297 phone: +31-348-432-794 1298 " 1300 DESCRIPTION 1301 "This MIB module defines objects to help support coexistence 1302 between SNMPv1, SNMPv2, and SNMPv3." 1303 ::= { snmpModules 18 } 1305 -- Administrative assignments **************************************** 1307 snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 } 1308 snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 } 1310 -- 1311 -- The snmpCommunityTable contains a database of community strings. 1312 -- This table provides mappings between community strings, and the 1313 -- parameters required for View-based Access Control. 1314 -- 1316 snmpCommunityTable OBJECT-TYPE 1317 SYNTAX SEQUENCE OF SnmpCommunityEntry 1318 MAX-ACCESS not-accessible 1319 STATUS current 1320 DESCRIPTION 1321 "The table of community strings configured in the SNMP 1322 engine's Local Configuration Datastore (LCD)." 1323 ::= { snmpCommunityMIBObjects 1 } 1325 snmpCommunityEntry OBJECT-TYPE 1326 SYNTAX SnmpCommunityEntry 1327 MAX-ACCESS not-accessible 1328 STATUS current 1329 DESCRIPTION 1330 "Information about a particular community string." 1331 INDEX { IMPLIED snmpCommunityIndex } 1332 ::= { snmpCommunityTable 1 } 1334 SnmpCommunityEntry ::= SEQUENCE { 1335 snmpCommunityIndex SnmpAdminString, 1336 snmpCommunityName OCTET STRING, 1337 snmpCommunitySecurityName SnmpAdminString, 1338 snmpCommunityContextEngineID SnmpEngineID, 1339 snmpCommunityContextName SnmpAdminString, 1340 snmpCommunityTransportTag SnmpTagValue, 1341 snmpCommunityStorageType StorageType, 1342 snmpCommunityStatus RowStatus 1343 } 1345 snmpCommunityIndex OBJECT-TYPE 1346 SYNTAX SnmpAdminString (SIZE(1..32)) 1347 MAX-ACCESS not-accessible 1348 STATUS current 1349 DESCRIPTION 1350 "The unique index value of a row in this table." 1351 ::= { snmpCommunityEntry 1 } 1353 snmpCommunityName OBJECT-TYPE 1354 SYNTAX OCTET STRING (SIZE(1..64)) 1355 MAX-ACCESS read-create 1356 STATUS current 1357 DESCRIPTION 1358 "The community string for which a row in this table 1359 represents a configuration." 1360 ::= { snmpCommunityEntry 2 } 1362 snmpCommunitySecurityName OBJECT-TYPE 1363 SYNTAX SnmpAdminString 1364 MAX-ACCESS read-create 1365 STATUS current 1366 DESCRIPTION 1367 "A human readable string representing the corresponding 1368 value of snmpCommunityName in a Security Model 1369 independent format." 1370 ::= { snmpCommunityEntry 3 } 1372 snmpCommunityContextEngineID OBJECT-TYPE 1373 SYNTAX SnmpEngineID 1374 MAX-ACCESS read-create 1375 STATUS current 1376 DESCRIPTION 1377 "The contextEngineID indicating the location of the 1378 context in which management information is accessed 1379 when using the community string specified by the 1380 corresponding instance of snmpCommunityName. 1382 The default value is the snmpEngineID of the entity in 1383 which this object is instantiated." 1384 ::= { snmpCommunityEntry 4 } 1386 snmpCommunityContextName OBJECT-TYPE 1387 SYNTAX SnmpAdminString 1388 MAX-ACCESS read-create 1389 STATUS current 1390 DESCRIPTION 1391 "The context in which management information is accessed 1392 when using the community string specified by the corresponding 1393 instance of snmpCommunityName." 1394 DEFVAL { ''H } -- the empty string 1395 ::= { snmpCommunityEntry 5 } 1397 snmpCommunityTransportTag OBJECT-TYPE 1398 SYNTAX SnmpTagValue 1399 MAX-ACCESS read-create 1400 STATUS current 1401 DESCRIPTION 1402 "This object specifies a set of transport endpoints 1403 from which an agent will accept management requests. 1404 If a management request containing this community 1405 is received on a transport endpoint other than the 1406 transport endpoints identified by this object, the 1407 request is deemed unauthentic. 1409 The transports identified by this object are specified 1410 in the snmpTargetAddrTable. Entries in that table 1411 whose snmpTargetAddrTagList contains this tag value 1412 are identified. 1414 If the value of this object has zero-length, transport 1415 endpoints are not checked when authenticating messages 1416 containing this community string." 1417 DEFVAL { ''H } -- the empty string 1418 ::= { snmpCommunityEntry 6 } 1420 snmpCommunityStorageType OBJECT-TYPE 1421 SYNTAX StorageType 1422 MAX-ACCESS read-create 1423 STATUS current 1424 DESCRIPTION 1425 "The storage type for this conceptual row in the 1426 snmpCommunityTable. Conceptual rows having the value 1427 'permanent' need not allow write-access to any 1428 columnar object in the row." 1429 ::= { snmpCommunityEntry 7 } 1431 snmpCommunityStatus OBJECT-TYPE 1432 SYNTAX RowStatus 1433 MAX-ACCESS read-create 1434 STATUS current 1435 DESCRIPTION 1436 "The status of this conceptual row in the snmpCommunityTable. 1438 An entry in this table is not qualified for activation 1439 until instances of all corresponding columns have been 1440 initialized, either through default values, or through 1441 Set operations. The snmpCommunityName and 1442 snmpCommunitySecurityName objects must be explicitly set." 1443 ::= { snmpCommunityEntry 8 } 1445 -- 1446 -- The snmpTargetAddrExtTable augments the snmpTargetAddrTable with 1447 -- a transport address mask value and a maximum message size value. 1448 -- The transport address mask allows entries in the 1449 -- snmpTargetAddrTable to define a set of addresses instead of just 1450 -- a single address. The maximum message size value allows the 1451 -- maximum message size of another SNMP entity to be configured 1452 -- for use in SNMPv1 (and SNMPv2c) transactions, where the message 1453 -- format does not specify a maximum message size. 1454 -- 1456 snmpTargetAddrExtTable OBJECT-TYPE 1457 SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry 1458 MAX-ACCESS not-accessible 1459 STATUS current 1460 DESCRIPTION 1461 "The table of mask and mms values associated with the 1462 snmpTargetAddrTable." 1463 ::= { snmpCommunityMIBObjects 2 } 1465 snmpTargetAddrExtEntry OBJECT-TYPE 1466 SYNTAX SnmpTargetAddrExtEntry 1467 MAX-ACCESS not-accessible 1468 STATUS current 1469 DESCRIPTION 1470 "Information about a particular mask and mms value." 1471 AUGMENTS { snmpTargetAddrEntry } 1472 ::= { snmpTargetAddrExtTable 1 } 1474 SnmpTargetAddrExtEntry ::= SEQUENCE { 1475 snmpTargetAddrTMask OCTET STRING, 1476 snmpTargetAddrMMS Integer32 1477 } 1479 snmpTargetAddrTMask OBJECT-TYPE 1480 SYNTAX OCTET STRING (SIZE (0..255)) 1481 MAX-ACCESS read-create 1482 STATUS current 1483 DESCRIPTION 1484 "The mask value associated with an entry in the 1485 snmpTargetAddrTable. The value of this object must 1486 have the same length as the corresponding instance of 1487 snmpTargetAddrTAddress, or must have length 0." 1488 DEFVAL { ''H } 1489 ::= { snmpTargetAddrExtEntry 1 } 1491 snmpTargetAddrMMS OBJECT-TYPE 1492 SYNTAX Integer32 (484..65535) 1493 MAX-ACCESS read-create 1494 STATUS current 1495 DESCRIPTION 1496 "The maximum message size value associated with an entry 1497 in the snmpTargetAddrTable." 1498 DEFVAL { 2048 } 1499 ::= { snmpTargetAddrExtEntry 2 } 1501 -- 1502 -- The snmpTrapAddress and snmpTrapCommunity objects are included 1503 -- in notifications that are forwarded by a proxy, which were 1504 -- originally received as SNMPv1 Trap messages. 1505 -- 1507 snmpTrapAddress OBJECT-TYPE 1508 SYNTAX IpAddress 1509 MAX-ACCESS accessible-for-notify 1510 STATUS current 1511 DESCRIPTION 1512 "The value of the agent-addr field of a Trap PDU which 1513 is forwarded by a proxy forwarder application using 1514 an SNMP version other than SNMPv1. The value of this 1515 object SHOULD contain the value of the agent-addr field 1516 from the original Trap PDU as generated by an SNMPv1 1517 agent." 1518 ::= { snmpCommunityMIBObjects 3 } 1520 snmpTrapCommunity OBJECT-TYPE 1521 SYNTAX OCTET STRING 1522 MAX-ACCESS accessible-for-notify 1523 STATUS current 1524 DESCRIPTION 1525 "The value of the community string field of an SNMPv1 1526 message containing a Trap PDU which is forwarded by a 1527 a proxy forwarder application using an SNMP version 1528 other than SNMPv1. The value of this object SHOULD 1529 contain the value of the community string field from 1530 the original SNMPv1 message containing a Trap PDU as 1531 generated by an SNMPv1 agent." 1532 ::= { snmpCommunityMIBObjects 4 } 1534 -- Conformance Information ******************************************* 1536 snmpCommunityMIBCompliances OBJECT IDENTIFIER 1537 ::= { snmpCommunityMIBConformance 1 } 1538 snmpCommunityMIBGroups OBJECT IDENTIFIER 1539 ::= { snmpCommunityMIBConformance 2 } 1541 -- Compliance statements 1543 snmpCommunityMIBCompliance MODULE-COMPLIANCE 1544 STATUS current 1545 DESCRIPTION 1546 "The compliance statement for SNMP engines which 1547 implement the SNMP-COMMUNITY-MIB." 1549 MODULE -- this module 1550 MANDATORY-GROUPS { snmpCommunityGroup } 1552 OBJECT snmpCommunityName 1553 MIN-ACCESS read-only 1554 DESCRIPTION "Write access is not required." 1555 OBJECT snmpCommunitySecurityName 1556 MIN-ACCESS read-only 1557 DESCRIPTION "Write access is not required." 1559 OBJECT snmpCommunitySecurityLevel 1560 MIN-ACCESS read-only 1561 DESCRIPTION "Write access is not required." 1563 OBJECT snmpCommunityContextEngineID 1564 MIN-ACCESS read-only 1565 DESCRIPTION "Write access is not required." 1567 OBJECT snmpCommunityContextName 1568 MIN-ACCESS read-only 1569 DESCRIPTION "Write access is not required." 1571 OBJECT snmpCommunityTransportTag 1572 MIN-ACCESS read-only 1573 DESCRIPTION "Write access is not required." 1575 OBJECT snmpCommunityStorageType 1576 MIN-ACCESS read-only 1577 DESCRIPTION "Write access is not required." 1579 OBJECT snmpCommunityStatus 1580 MIN-ACCESS read-only 1581 DESCRIPTION "Write access is not required." 1583 ::= { snmpCommunityMIBCompliances 1 } 1585 snmpCommunityGroup OBJECT-GROUP 1586 OBJECTS { 1587 snmpCommunityIndex, 1588 snmpCommunityName, 1589 snmpCommunitySecurityName, 1590 snmpCommunityContextEngineID, 1591 snmpCommunityContextName, 1592 snmpCommunityTransportTag, 1593 snmpCommunityStorageType, 1594 snmpCommunityStatus, 1595 snmpTargetAddrTMask, 1596 snmpTargetAddrMMS 1597 } 1598 STATUS current 1599 DESCRIPTION 1600 "A collection of objects providing for configuration 1601 of community strings for SNMPv1 (and SNMPv2c) usage." 1603 ::= { snmpCommunityMIBGroups 1 } 1605 END 1607 6. Intellectual Property 1609 The IETF takes no position regarding the validity or scope of any 1610 intellectual property or other rights that might be claimed to 1611 pertain to the implementation or use of the technology described in 1612 this document or the extent to which any license under such rights 1613 might or might not be available; neither does it represent that it 1614 has made any effort to identify any such rights. Information on the 1615 IETF's procedures with respect to rights in standards-track and 1616 standards-related documentation can be found in BCP-11. Copies of 1617 claims of rights made available for publication and any assurances of 1618 licenses to be made available, or the result of an attempt made to 1619 obtain a general license or permission for the use of such 1620 proprietary rights by implementors or users of this specification can 1621 be obtained from the IETF Secretariat. 1623 The IETF invites any interested party to bring to its attention any 1624 copyrights, patents or patent applications, or other proprietary 1625 rights which may cover technology that may be required to practice 1626 this standard. Please address the information to the IETF Executive 1627 Director. 1629 7. Acknowledgments 1631 This document is the result of the efforts of the SNMPv3 Working 1632 Group. The design of the SNMP-COMMUNITY-MIB incorporates work done 1633 by the authors of SNMPv2*: 1635 Jeff Case (SNMP Research, Inc.) 1636 David Harrington (Cabletron Systems Inc.) 1637 David Levi (SNMP Research, Inc.) 1638 Brian O'Keefe (Hewlett Packard) 1639 Jon Saperia (BGS Systems Inc.) 1640 Steve Waldbusser (International Network Services) 1642 8. Security Considerations 1644 Although SNMPv1 and SNMPv2 do not provide any security, allowing 1645 community names to be mapped into securityName/contextName provides 1646 the ability to use view-based access control to limit the access of 1647 unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for 1648 network administrators to make use of this capability in order to 1649 avoid unauthorized access to MIB data that would otherwise be secure. 1651 Further, the SNMP-COMMUNITY-MIB has the potential to expose community 1652 strings which provide access to more information than that which is 1653 available using the usual 'public' community string. For this 1654 reason, a security administrator may wish to limit accessibility to 1655 the SNMP-COMMUNITY-MIB, and in particular, to make it inaccessible 1656 when using the 'public' community string. 1658 When a proxy implementation translates messages between SNMPv1 (or 1659 SNMPv2c) and SNMPv3, there may be a loss of security. For example, 1660 an SNMPv3 message received using authentication and privacy which is 1661 subsequently forwarded using SNMPv1 will lose the security benefits 1662 of using authentication and privacy. Careful configuration of 1663 proxies is required to address such situations. One approach to deal 1664 with such situations might be to use an encrypted tunnel. 1666 9. References 1668 [1] Rose, M. and K. McCloghrie, "Structure and Identification of 1669 Management Information for TCP/IP-based internets"", STD16, RFC 1670 1155, May 1990. 1672 [2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1673 Management Protocol", STD15, RFC 1157, SNMP Research, Performance 1674 Systems International, Performance Systems International, MIT 1675 Laboratory for Computer Science, May 1990. 1677 [3] McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions", 1678 STD 16, RFC 1212, Hughes LAN Systems, Performance Systems 1679 International, March 1991. 1681 [4] Rose, M. T., "A Convention for Defining Traps for use with the 1682 SNMP", RFC 1215, March 1991. 1684 [5] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP- 1685 based Agents", RFC 1303, Hughes LAN Systems, Dover Beach 1686 Consulting, Inc., February 1992. 1688 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1689 Waldbusser, "Introduction to Community-based SNMPv2", RFC1901, SNMP 1690 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1691 International Network Services, January 1996. 1693 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1694 Waldbusser, "Structure of Management Information for Version 2 of 1695 the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP 1696 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1697 International Network Services, January 1996. 1699 [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1700 Waldbusser, "Textual Conventions for Version 2 of the Simple 1701 Network Management Protocol (SNMPv2)", RFC1903, SNMP Research,Inc., 1702 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1703 Network Services, January 1996. 1705 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1706 Waldbusser, "Conformance Statements for Version 2 of the Simple 1707 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 1709 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1710 Waldbusser, "Protocol Operations for Version 2 of the Simple 1711 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 1712 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1713 Network Services, January 1996. 1715 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport 1716 Mappings for Version 2 of the Simple Network Management Protocol 1717 (SNMPv2)", RFC 1906, January 1996. 1719 [12] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1720 Waldbusser, "Management Information Base for Version 2 of the 1721 Simple Network Management Protocol (SNMPv2)", RFC1907, SNMP 1722 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1723 International Network Services, January 1996. 1725 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1726 Waldbusser, "Coexistence between Version 1 and Version 2 of the 1727 Internet-standard Network Management Framework", RFC1908, SNMP 1728 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1729 International Network Services, January 1996. 1731 [14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi- 1732 lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January 1733 1997. 1735 [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1736 Levels", BCP 14, RFC 2119, March 1997. 1738 [16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An 1739 Architecture for Describing SNMP Management Frameworks", draft- 1740 ietf-snmpv3-arch-05.txt, February 1999. 1742 [17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., 1743 "Message Processing and Dispatching for the Simple Network 1744 Management Protocol (SNMP)", draft-ietf-snmpv3-mpc-05.txt, February 1745 1999. 1747 [18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP 1748 Applications", draft-ietf-snmpv3-appl-v2-03.txt, February 1999. 1750 [19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User- 1751 Based Security Model for Version 3 of the Simple Network Management 1752 Protocol (SNMP)", draft-ietf-snmpv3-usm-v2-05.txt, February 1999. 1754 [20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., 1755 "View-based Access Control Model for the Simple Network Management 1756 Protocol (SNMP)", draft-ietf-snmpv3-vacm-04.txt, February 1999. 1758 10. Editor's Address 1760 Rob Frye 1761 MCI Communications Corp. 1762 2100 Reston Parkway, Suite 600 1763 Reston, VA 20191 1764 U.S.A. 1765 Phone: +1 703 715 7225 1766 EMail: Rob.Frye@mci.com 1768 David B. Levi 1769 SNMP Research, Inc. 1770 3001 Kimberlin Heights Road 1771 Knoxville, TN 37920-9716 1772 U.S.A. 1773 Phone: +1 423 573 1434 1774 EMail: levi@snmp.com 1776 Shawn A. Routhier 1777 Integrated Systems Inc. 1778 333 North Ave 4th Floor 1779 Wakefield MA 01880 1780 U.S.A. 1781 Phone: + 1 781 245 0804 1782 EMail: sar@epilogue.com 1784 Bert Wijnen 1785 IBM T. J. Watson Research 1786 Schagen 33 1787 3461 GL Linschoten 1788 Netherlands 1789 Phone: +31 348 432 794 1790 EMail: wijnen@vnet.ibm.com 1792 A. Full Copyright Statement 1794 This document and translations of it may be copied and furnished to 1795 others, and derivative works that comment on or otherwise explain it 1796 or assist in its implementation may be prepared, copied, published 1797 and distributed, in whole or in part, without restriction of any 1798 kind, provided that the above copyright notice and this paragraph are 1799 included on all such copies and derivative works. However, this 1800 document itself may not be modified in any way, such as by removing 1801 the copyright notice or references to the Internet Society or other 1802 Internet organizations, except as needed for the purpose of 1803 developing Internet standards in which case the procedures for 1804 copyrights defined in the Internet Standards process must be 1805 followed, or as required to translate it into languages other than 1806 English. 1808 The limited permissions granted above are perpetual and will not be 1809 revoked by the Internet Society or its successors or assigns. 1811 This document and the information contained herein is provided on an 1812 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1813 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1814 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1815 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1816 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.