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