idnits 2.17.1 draft-ietf-snmpv2-coex-ds-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 23 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 September 1995) is 10436 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 1303 (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Coexistence between SNMPv1 and SNMPv2 September 1995 3 Coexistence between Version 1 and Version 2 of the 4 Internet-standard Network Management Framework 6 20 September 1995 8 draft-ietf-snmpv2-coex-ds-03.txt 10 Keith McCloghrie 11 Editor + 12 Cisco Systems, Inc. 13 kzm@cisco.com 15 Status of this Memo - 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference material 25 or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 30 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 1. Introduction 34 The purpose of this document is to describe coexistence between version 35 2 of the Internet-standard Network Management Framework, termed the SNMP 36 version 2 framework (SNMPv2) [1], and the original Internet-standard 37 Network Management Framework (SNMPv1), which consists of these three 38 documents: 40 RFC 1155 [2] which defines the Structure of Management Information 41 (SMI), the mechanisms used for describing and naming objects for 42 the purpose of management. 44 RFC 1212 [3] which defines a more concise description mechanism, 45 which is wholly consistent with the SMI. 47 RFC 1157 [4] which defines the Simple Network Management Protocol 48 (SNMP), the protocol used for network access to managed objects. 50 2. Management Information 52 The SNMPv2 approach towards describing collections of managed objects is 53 nearly a proper superset of the approach defined in the Internet- 54 standard Network Management Framework. For example, both approaches use 55 ASN.1 [5] as the basis for a formal descriptive notation. Indeed, one 56 might note that the SNMPv2 approach largely codifies the existing 57 practice for defining MIB modules, based on extensive experience with 58 the current framework. 60 The SNMPv2 documents which deal with information modules are: 62 Structure of Management Information for SNMPv2 [6], which defines 63 concise notations for describing information modules, managed 64 objects and notifications; 66 Textual Conventions for SNMPv2 [7], which defines a concise 67 notation for describing textual conventions, and also defines some 68 initial conventions; and, 70 Conformance Statements for SNMPv2 [8], which defines concise 71 notation for describing compliance and capabilities statements. 73 The following sections consider the three areas: MIB modules, compliance 74 statements, and capabilities statements. 76 MIB modules defined using the current framework may continue to be used 77 with the SNMPv2 protocol. However, for the MIB modules to conform to 78 the SNMPv2 framework, the following changes are required: 80 2.1. Object Definitions 82 In general, conversion of a MIB module does not require the deprecation 83 of the objects contained therein. Only if the semantics of an object 84 truly changes should deprecation be performed. 86 (1) The IMPORTS statement must reference SNMPv2-SMI, instead of 87 RFC1155-SMI and RFC-1212. 89 (2) The MODULE-IDENTITY macro must be invoked immediately after any 90 IMPORTs statement. 92 (3) For any descriptor which contains the hyphen character, the hyphen 93 character is removed. 95 (4) For any label for a named-number enumeration which contains the 96 hyphen character, the hyphen character is removed. 98 (5) For any object with an integer-valued SYNTAX clause, in which the 99 corresponding INTEGER does not have a range restriction (i.e., the 100 INTEGER has neither a defined set of named-number enumerations nor 101 an assignment of lower- and upper-bounds on its value), the object 102 must have the value of its SYNTAX clause changed to Integer32. 104 (6) For any object with a SYNTAX clause value of an enumerated INTEGER, 105 the hyphen character is removed from any named-number labels which 106 contain the hyphen character. 108 (7) For any object with a SYNTAX clause value of Counter, the object 109 must have the value of its SYNTAX clause changed to Counter32. 111 (8) For any object with a SYNTAX clause value of Gauge, the object must 112 have the value of its SYNTAX clause changed to Gauge32. 114 (9) For all objects, the ACCESS clause must be replaced by a MAX-ACCESS 115 clause. The value of the MAX-ACCESS clause is the same as that of 116 the ACCESS clause unless some other value makes "protocol sense" as 117 the maximal level of access for the object. In particular, object 118 types for which instances can be explicitly created by a protocol 119 set operation, will have a MAX-ACCESS clause of "read-create". If 120 the value of the ACCESS clause is "write-only", then the value of 121 the MAX-ACCESS clause is "read-write", and the DESCRIPTION clause 122 notes that reading this object will result implementation-specific 123 results. 125 (10) For all objects, if the value of the STATUS clause is "mandatory", 126 the value must be replaced with "current". 128 (11) For all objects, if the value of the STATUS clause is "optional", 129 the value must be replaced with "obsolete". 131 (12) For any object not containing a DESCRIPTION clause, the object must 132 have a DESCRIPTION clause defined. 134 (13) For any object corresponding to a conceptual row which does not 135 have an INDEX clause, the object must have either an INDEX clause 136 or an AUGMENTS clause defined. 138 (14) For any object with an INDEX clause that references an object with 139 a syntax of NetworkAddress, the value of the STATUS clause of both 140 objects is changed to "obsolete". 142 (15) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER 143 value which is expressed as a collection of sub-identifiers, change 144 the value to reference a single ASN.1 identifier. 146 Other changes are desirable, but not necessary: 148 (1) Creation and deletion of conceptual rows is inconsistent using the 149 current framework. The SNMPv2 framework corrects this. As such, 150 if the MIB module undergoes review early in its lifetime, and it 151 contains conceptual tables which allow creation and deletion of 152 conceptual rows, then it may be worthwhile to deprecate the objects 153 relating to those tables and replace them with objects defined 154 using the new approach. 156 (2) For any object with a string-valued SYNTAX clause, in which the 157 corresponding OCTET STRING does not have a size restriction (i.e., 158 the OCTET STRING has no assignment of lower- and upper-bounds on 159 its length), one might consider defining the bounds for the size of 160 the object. 162 (3) For all textual conventions informally defined in the MIB module, 163 one might consider redefining those conventions using the TEXTUAL- 164 CONVENTION macro. Such a change would not necessitate deprecating 165 objects previously defined using an informal textual convention. 167 (4) For any object which represents a measurement in some kind of 168 units, one might consider adding a UNITS clause to the definition 169 of that object. 171 (5) For any conceptual row which is an extension of another conceptual 172 row, i.e., for which subordinate columnar objects both exist and 173 are identified via the same semantics as the other conceptual row, 174 one might consider using an AUGMENTS clause in place of the INDEX 175 clause for the object corresponding to the conceptual row which is 176 an extension. 178 Finally, when encountering common errors in SNMPv1 MIB modules: 180 (1) For any non-columnar object that is instanced as if it were 181 immediately subordinate to a conceptual row, the value of the 182 STATUS clause of that object is changed to "obsolete". 184 (2) For any conceptual row object that is not contained immediately 185 subordinate to a conceptual table, the value of the STATUS clause 186 of that object (and all subordinate objects) is changed to 187 "obsolete". 189 2.2. Trap Definitions 191 If a MIB module is changed to conform to the SNMPv2 framework, then each 192 occurrence of the TRAP-TYPE macro must be changed to a corresponding 193 invocation of the NOTIFICATION-TYPE macro: 195 (1) The IMPORTS statement must not reference RFC-1215. 197 (2) The ENTERPRISES clause must be removed. 199 (3) The VARIABLES clause must be renamed to the OBJECTS clause. 201 (4) The STATUS clause must be added. 203 (5) The value of an invocation of the NOTIFICATION-TYPE macro is an 204 OBJECT IDENTIFIER, not an INTEGER, and must be changed accordingly. 205 Specifically, if the value of the ENTERPRISE clause is not 'snmp' 206 then the value of the invocation is the value of the ENTERPRISE 207 clause extended with two sub-identifiers, the first of which has 208 the value 0, and the second has the value of the invocation of the 209 TRAP-TYPE. 211 2.3. Compliance Statements 213 For those information modules which are "standard", a corresponding 214 invocation of the MODULE-COMPLIANCE macro must be included within the 215 information module (or in a companion information module), and any 216 commentary text in the information module which relates to compliance 217 must be removed. Typically this editing can occur when the information 218 module undergoes review. 220 2.4. Capabilities Statements 222 In the current framework, the informational document [9] uses the 223 MODULE-CONFORMANCE macro to describe an agent's capabilities with 224 respect to one or more MIB modules. Converting such a description for 225 use with the SNMPv2 framework requires these changes: 227 (1) Use the macro name AGENT-CAPABILITIES instead of MODULE- 228 CONFORMANCE. 230 (2) The STATUS clause must be added. 232 (3) For all occurrences of the CREATION-REQUIRES clause, note the 233 slight change in semantics, and omit this clause if appropriate. 235 In order to ease the coexistence between SNMPv1 and SNMPv2, object 236 groups defined in an SNMPv1 MIB module may be referenced by the INCLUDES 237 clause of an invocation of the AGENT-CAPABILITIES macro: upon 238 encountering a reference to an OBJECT IDENTIFIER subtree defined in an 239 SNMPv1 MIB module, all leaf objects which are subordinate to the subtree 240 and have a STATUS clause value of mandatory are deemed to be INCLUDEd. 241 (Note that this method is ambiguous when different revisions of a SNMPv1 242 MIB have different sets of mandatory objects under the same subtree; in 243 such cases, the only solution is to rewrite the MIB using the SNMPv2 SMI 244 in order to define the object groups unambiguously.) 245 3. Protocol Operations 247 The SNMPv2 documents which deal with protocol operations are: 249 Protocol Operations for SNMPv2 [10], which defines the syntax and 250 semantics of the operations conveyed by the protocol; and, 252 Transport Mappings for SNMPv2 [11], which defines how the protocol 253 operations are carried over different transport services. 255 The following section considers two areas: the proxy behavior between a 256 SNMPv2 entity and a SNMPv1 agent; and, the behavior of "bi-lingual" 257 protocol entities acting in a manager role. 259 3.1. Proxy Agent Behavior 261 To achieve coexistence at the protocol-level, a proxy mechanism may be 262 used. A SNMPv2 entity acting in an agent role may be implemented and 263 configured to act in the role of a proxy agent. 265 3.1.1. SNMPv2 -> SNMPv1 267 When converting requests from a SNMPv2 entity acting in a manager role 268 into requests sent to a SNMPv1 entity acting in an agent role: 270 (1) If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU is 271 received, then it is passed unaltered by the proxy agent. 273 (2) If a GetBulkRequest-PDU is received, the proxy agent sets the non- 274 repeaters and max-repetitions fields to zero, and sets the tag of 275 the PDU to GetNextRequest-PDU. 277 3.1.2. SNMPv1 -> SNMPv2 279 When converting responses received from a SNMPv1 entity acting in an 280 agent role into responses sent to a SNMPv2 entity acting in a manager 281 role: 283 (1) If a GetResponse-PDU is received, then it is passed unaltered by 284 the proxy agent. Note that even though a SNMPv2 entity will never 285 generate a Response-PDU with a error-status field having a value of 286 `noSuchName', `badValue', or `readOnly', the proxy agent must not 287 change this field. This allows the SNMPv2 entity acting in a 288 manager role to interpret the response correctly. 290 If a GetResponse-PDU is received with an error-status field having 291 a value of `tooBig', the proxy agent will remove the contents of 292 the variable-bindings field before propagating the response. Note 293 that even though a SNMPv2 entity will never generate a `tooBig' in 294 response to a GetBulkRequest-PDU, the proxy agent must propagate 295 such a response. 297 (2) If a Trap-PDU is received, then it is mapped into a SNMPv2-Trap- 298 PDU. This is done by prepending onto the variable-bindings field 299 two new bindings: sysUpTime.0 [12], which takes its value from the 300 timestamp field of the Trap-PDU; and, snmpTrapOID.0 [12], which is 301 calculated thusly: if the value of generic-trap field is 302 `enterpriseSpecific', then the value used is the concatenation of 303 the enterprise field from the Trap-PDU with two additional sub- 304 identifiers, `0', and the value of the specific-trap field; 305 otherwise, the value of the corresponding trap defined in [12] is 306 used. (For example, if the value of the generic-trap field is 307 `coldStart', then the coldStart trap [12] is used.) Then, one new 308 binding is appended onto the variable-bindings field: 309 snmpTrapEnterprise.0 [12], which takes its value from the 310 enterprise field of the Trap-PDU. The destinations for the 311 SNMPv2-Trap-PDU are determined in an implementation-dependent 312 fashion by the proxy agent. 314 3.2. Bi-lingual Manager Behavior 316 To achieve coexistence at the protocol-level, a protocol entity acting 317 in a manager role might support both SNMPv1 and SNMPv2. When a 318 management application needs to contact a protocol entity acting in an 319 agent role, the entity acting in a manager role consults a local 320 database to select the correct management protocol to use. 322 In order to provide transparency to management applications, the entity 323 acting in a manager role must map operations as if it were acting as a 324 proxy agent. 326 4. Acknowledgements 328 This document is the result of significant work by the four major 329 contributors: 331 Jeffrey Case (SNMP Research, case@snmp.com) 332 Keith McCloghrie (Cisco Systems, kzm@cisco.com) 333 Marshall Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) 334 Steven Waldbusser (International Network Services, stevew@uni.ins.com) 336 In addition, the contributions of the SNMPv2 Working Group are 337 acknowledged. In particular, a special thanks is extended for the 338 contributions of: 340 Alexander I. Alten (Novell) 341 Dave Arneson (Cabletron) 342 Uri Blumenthal (IBM) 343 Doug Book (Chipcom) 344 Kim Curran (Bell-Northern Research) 345 Jim Galvin (Trusted Information Systems) 346 Maria Greene (Ascom Timeplex) 347 Iain Hanson (Digital) 348 Dave Harrington (Cabletron) 349 Nguyen Hien (IBM) 350 Jeff Johnson (Cisco Systems) 351 Michael Kornegay (Object Quest) 352 Deirdre Kostick (AT&T Bell Labs) 353 David Levi (SNMP Research) 354 Daniel Mahoney (Cabletron) 355 Bob Natale (ACE*COMM) 356 Brian O'Keefe (Hewlett Packard) 357 Andrew Pearson (SNMP Research) 358 Dave Perkins (Peer Networks) 359 Randy Presuhn (Peer Networks) 360 Aleksey Romanov (Quality Quorum) 361 Shawn Routhier (Epilogue) 362 Jon Saperia (BGS Systems) 363 Bob Stewart (Cisco Systems, bstewart@cisco.com), chair 364 Kaj Tesink (Bellcore) 365 Glenn Waters (Bell-Northern Research) 366 Bert Wijnen (IBM) 368 5. References 370 [1] McCloghrie, K., Editor, | 371 "Introduction to Version 2 of the Internet-standard Network 372 Management Framework", Internet Draft, Cisco Systems, September | 373 1995. | 375 [2] Rose, M., and McCloghrie, K., "Structure and Identification of 376 Management Information for TCP/IP-based internets", STD 16, RFC 377 1155, May 1990. 379 [3] Rose, M., and McCloghrie, K., "Concise MIB Definitions", STD 16, 380 RFC 1212, March 1991. 382 [4] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network 383 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 384 Systems International, MIT Laboratory for Computer Science, May 385 1990. 387 [5] Information processing systems - Open Systems Interconnection - 388 Specification of Abstract Syntax Notation One (ASN.1), 389 International Organization for Standardization. International 390 Standard 8824, (December, 1987). 392 [6] McCloghrie, K., Editor, | 393 "Structure of Management Information for Version 2 of the Simple 394 Network Management Protocol (SNMPv2)", Internet Draft, Cisco | 395 Systems, September 1995. | 397 [7] McCloghrie, K., Editor, | 398 "Textual Conventions for Version 2 of the Simple Network Management 399 Protocol (SNMPv2)", Internet Draft, Cisco Systems, September 1995. | 401 [8] McCloghrie, K., Editor, | 402 "Conformance Statements for Version 2 of the Simple Network 403 Management Protocol (SNMPv2)", Internet Draft, Cisco Systems, | 404 September 1995. | 406 [9] McCloghrie, K., and Rose, M., "A Convention for Describing SNMP- 407 based Agents", RFC 1303, Hughes LAN Systems, Dover Beach 408 Consulting, Inc., February 1992. 410 [10] McCloghrie, K., Editor, | 411 "Protocol Operations for Version 2 of the Simple Network Management 412 Protocol (SNMPv2)", Internet Draft, Cisco Systems, September 1995. | 414 [11] McCloghrie, K., Editor, | 415 "Transport Mappings for Version 2 of the Simple Network Management 416 Protocol (SNMPv2)", Internet Draft, Cisco Systems, September 1995. | 418 [12] McCloghrie, K., Editor, | 419 "Management Information Base for Version 2 of the Simple Network 420 Management Protocol (SNMPv2)", Internet Draft, Cisco Systems, | 421 September 1995. | 423 6. Security Considerations 425 Security issues are not discussed in this memo. 427 7. Editor's Address 429 Keith McCloghrie - 430 Cisco Systems, Inc. 431 170 West Tasman Drive 432 San Jose, CA 95134-1706 433 US 435 Phone: +1 408 526 5260 436 Email: kzm@cisco.com 438 Table of Contents - 440 1 Introduction .................................................... 2 441 2 Management Information .......................................... 3 442 2.1 Object Definitions ............................................ 3 443 2.2 Trap Definitions .............................................. 6 444 2.3 Compliance Statements ......................................... 6 445 2.4 Capabilities Statements ....................................... 6 446 3 Protocol Operations ............................................. 8 447 3.1 Proxy Agent Behavior .......................................... 8 448 3.1.1 SNMPv2 -> SNMPv1 ............................................ 8 449 3.1.2 SNMPv1 -> SNMPv2 ............................................ 8 450 3.2 Bi-lingual Manager Behavior ................................... 10 451 4 Acknowledgements ................................................ 11 452 5 References ...................................................... 12 453 6 Security Considerations ......................................... 14 454 7 Editor's Address ................................................ 14