idnits 2.17.1 draft-ietf-eos-snmpxproto-mib-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 110 has weird spacing: '...cted to imple...' == Line 459 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2571' is mentioned on line 110, but not defined ** Obsolete undefined reference: RFC 2571 (Obsoleted by RFC 3411) == Missing Reference: 'RFC2262' is mentioned on line 189, but not defined ** Obsolete undefined reference: RFC 2262 (Obsoleted by RFC 2272) == Unused Reference: 'RFC2021' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC2274' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'RFC2275' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC3014' is defined on line 444, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2021 (Obsoleted by RFC 4502) ** Obsolete normative reference: RFC 2274 (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 2275 (Obsoleted by RFC 2575) Summary: 19 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EOS Working Group S. Chisholm 2 Internet Draft Nortel Networks 3 Document: draft-ietf-eos-snmpxproto-mib-01.txt 4 Category: Standards Track 5 Expiration Date: January 2002 July 16 2001 7 SNMP Extended Protocol MIB 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo defines a portion of the Management Information Base (MIB) 35 for use with network management protocols in the Internet community. 36 In particular, it describes SNMP protocol extensions supported by 37 an SNMP entity. 39 Table of Contents 41 1. The SNMP Management Framework 42 2. Introduction 43 3. Extended Protocol Management 44 3.1. SNMP Extensions 45 3.2. Interoperability 46 3.3. Relation to Agent Capabilities 47 4. MIB Overview 48 5. Definitions 49 6. IANA Considerations 50 7. Security Considerations 51 8. Author's Address 52 9. Acknowledgements 53 10. References 54 11. Full Copyright Statement 55 1. The SNMP Management Framework 57 The SNMP Management Framework presently consists of five major 58 components: 60 o An overall architecture, described in RFC 2571 [RFC2571]. 62 o Mechanisms for describing and naming objects and events for the 63 purpose of management. The first version of this Structure of 64 Management Information (SMI) is called SMIv1 and described in 65 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 66 1215 [RFC1215]. The second version, called SMIv2, is described 67 in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 68 STD 58, RFC 2580 [RFC2580]. 70 o Message protocols for transferring management information. The 71 first version of the SNMP message protocol is called SNMPv1 and 72 described in STD 15, RFC 1157 [RFC1157]. A second version of 73 the SNMP message protocol, which is not an Internet standards 74 track protocol, is called SNMPv2c and described in RFC 1901 75 [RFC1901] and RFC 1906 [RFC1906]. The third version of the 76 message protocol is called SNMPv3 and described in RFC 1906 77 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 79 o Protocol operations for accessing management information. The 80 first set of protocol operations and associated PDU formats is 81 described in STD 15, RFC 1157 [RFC1157]. A second set of 82 protocol operations and associated PDU formats is described in 83 RFC 1905 [RFC1905]. 85 o A set of fundamental applications described in RFC 2573 86 [RFC2573] and the view-based access control mechanism described 87 in RFC 2575 [RFC2575]. 89 A more detailed introduction to the current SNMP Management Framework 90 can be found in RFC 2570 [RFC2570]. 92 Managed objects are accessed via a virtual information store, termed 93 the Management Information Base or MIB. Objects in the MIB are 94 defined using the mechanisms defined in the SMI. 96 This memo specifies a MIB module that is ;'ant to the SMIv2. A 97 MIB conforming to the SMIv1 can be produced through the appropriate 98 translations. The resulting translated MIB must be semantically 99 equivalent, except where objects or events are omitted because no 100 translation is possible (use of Counter64). Some machine readable 101 information in SMIv2 will be converted into textual descriptions in 102 SMIv1 during the translation process. However, this loss of machine 103 readable information is not considered to change the semantics of the 104 MIB. 106 2. Introduction 108 Traditionally, features have been added to SNMP by developing a new 109 version of the protocol that supports these new features. Currently, 110 SNMP entities that conform to [RFC 2571] are expected to implement 111 all the protocol functionality defined by the standards. 113 The idea, moving forward, is to add features to SNMP in a more 114 modular fashion and without necessarily increasing the version 115 number. Since the protocol version number is no longer sufficient 116 information to determine which protocol features an SNMP entity 117 supports, another method is required. This memo defines a MIB to be 118 used to determine the SNMP capabilities of an SNMP entity, above and 119 beyond the base features of its protocol version. 121 Requirements of this feature are: 122 o It must be easy to determine the features that an SNMP entity 123 supports; 125 This feature is not required to: 127 o List base features of the SNMPv3 protocol. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119. 133 3. Extended Protocol Management 135 3.1 SNMP Extensions 137 SNMP extensions are those standard protocol extensions that are 138 developed within the IETF and published in standards track RFCs. 140 3.2 Interoperability 141 +------------+ 142 |Command | 143 +--------+Generator |-----------+ 144 | |Extended | | 145 | |Protocol | | 146 | +------------+ | 147 | | 148 | | 149 | +--------+------------+ 150 +------+-----+ |Command Responder | 151 |Command | | | 152 |Responder | | Extended Protocol | 153 |Protocol | +--------+------------+ 154 |Operations | | 155 |v2 | | 156 +-----+------+ | 157 | +------------+ | 158 | |Command | | 159 | |Generator +--------+ 160 +------------+Protocol | 161 |Operations | 162 |v2 | 163 +------------+ 165 An SNMP entity that supports version 2 of the protocol operations 166 [RFC1905] MUST be able to communicate with an SNMP entity supporting 167 extended protocol operations. This communication MUST be in a manner 168 consistent with communicating with an SNMP entity which supports 169 version 2 of the protocol operations. Similarly, an SNMP entity that 170 supports extended protocol operations MUST be able to communicate 171 with SNMP entities which support version 2 of the protocol 172 operations. 174 An SNMP entity that supports the extended protocol operations MUST 175 support protocol operations as defined in version 2 of the protocol 176 operations [RFC1905]. Traditional sets may be an exception to this. 177 Details to be determined. 179 A command generator SHOULD query a command responder before issuing 180 an extended protocol operation to determine if the command responder 181 supports the operation. 183 An SNMP entity MUST only issue a response using an extended protocol 184 feature if it received the request using the extended protocol 185 feature. 187 If an SNMP entity receives an extended protocol feature it does not 188 understand, it MUST follow the unknown PDU response mechanism as 189 defined in [RFC2262] section 4.2.2.1 191 3.3 Relation to Agent Capabilities 193 Agent capability statements are used when describing capabilities of 194 agents with respect to object definitions. The extended protocol 195 MIB is used when describing the capabilities of agents with respect 196 to protocol operations. 198 4. MIB Overview 200 The snmpXProtoSystem object indicates which protocol extensions are 201 supported by the entire SNMP entity. snmpXProtoSubTreeTable 202 indicates additional protocol extensions supported on particular MIB 203 sub trees. 205 5. Definitions 207 SNMP-EXTENDED-PROTOCOL-MIB DEFINITIONS ::= BEGIN 209 IMPORTS 210 MODULE-IDENTITY, OBJECT-TYPE, 211 Unsigned32, mib-2 FROM SNMPv2-SMI 212 IANASnmpExtendedProtocol FROM SNMP-X-PROTOCOL-TC 213 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 215 snmpXProtoMIB MODULE-IDENTITY 216 LAST-UPDATED "200107160000Z" 217 ORGANIZATION "IETF Evolution of SNMP Working Group" 218 CONTACT-INFO 219 " Sharon Chisholm 220 Nortel Networks 221 PO Box 3511 Station C 222 Ottawa, Ont. K1Y 4H7 223 Canada 224 schishol@nortelnetworks.com" 225 DESCRIPTION 226 "The MIB module describes the SNMP protocol 227 extensions supported by this SNMP entity." 228 REVISION "200107160000Z" 229 DESCRIPTION 230 "Initial version, published as RFC XXXX." 232 ::= { mib-2 XX } 234 snmpXProtoObjects OBJECT IDENTIFIER ::= { snmpXProtoMIB 1 } 236 snmpXProtoConformance OBJECT IDENTIFIER ::= { snmpXProtoMIB 3 } 238 snmpXProtoCompliances OBJECT IDENTIFIER 239 ::= { snmpXProtoConformance 1 } 241 snmpXProtoSystem OBJECT-TYPE 242 SYNTAX IANASnmpExtendedProtocol 243 MAX-ACCESS read-only 244 STATUS current 245 DESCRIPTION 246 "The standard SNMP protocol operations supported 247 by this system above and beyond basic protocol 248 support." 249 ::= { snmpXProtoObjects 1 } 251 -- Extra Protocol Support per SubTree 253 snmpXProtoSubTreeTable OBJECT-TYPE 254 SYNTAX SEQUENCE OF SnmpXProtoSubTreeEntry 255 MAX-ACCESS not-accessible 256 STATUS current 257 DESCRIPTION "A table of additional protocol extensions to SNMP 258 supported by specific subTrees." 259 ::= { snmpXProtoObjects 2 } 261 snmpXProtoSubTreeEntry OBJECT-TYPE 262 SYNTAX SnmpXProtoSubTreeEntry 263 MAX-ACCESS not-accessible 264 STATUS current 265 DESCRIPTION "An additional protocol extension to SNMP 266 supported by part of the MIB of this SNMP entity." 267 INDEX { snmpXProtoSubTreeIndex } 268 ::= { snmpXProtoSubTreeTable 1 } 270 SnmpXProtoSubTreeEntry ::= SEQUENCE { 271 snmpXProtoSubTreeIndex Unsigned32, 272 snmpXProtoSubTreeBranch OBJECT IDENTIFIER, 273 snmpXProtoSubTreeFeature IANASnmpExtendedProtocol 274 } 276 snmpXProtoSubTreeIndex OBJECT-TYPE 277 SYNTAX Unsigned32(1..4294967295) 278 MAX-ACCESS not-accessible 279 STATUS current 280 DESCRIPTION "An arbitrary index into this table." 281 ::= { snmpXProtoSubTreeEntry 1 } 283 snmpXProtoSubTreeBranch OBJECT-TYPE 284 SYNTAX OBJECT IDENTIFIER 285 MAX-ACCESS read-only 286 STATUS current 287 DESCRIPTION 288 "The OID which identifies this SubTree feature." 289 ::= { snmpXProtoSubTreeEntry 2 } 291 snmpXProtoSubTreeFeature OBJECT-TYPE 292 SYNTAX IANASnmpExtendedProtocol 293 MAX-ACCESS read-only 294 STATUS current 295 DESCRIPTION 296 "The standard SNMP protocol operations supported 297 by this subTree above and beyond protocol 298 support as indicated by snmpXProtoSystem." 299 ::= { snmpXProtoSubTreeEntry 3 } 301 snmpXProtoCompliance MODULE-COMPLIANCE 302 STATUS current 303 DESCRIPTION 304 "The compliance statement for systems supporting 305 the snmpXProto MIB." 306 MODULE -- this module 307 MANDATORY-GROUPS { 308 snmpXProtoGroup 309 } 310 ::= { snmpXProtoCompliances 1 } 312 snmpXProtoGroups OBJECT IDENTIFIER ::= { snmpXProtoConformance 2 } 314 snmpXProtoGroup OBJECT-GROUP 315 OBJECTS { 316 snmpXProtoSystem 317 } 318 STATUS current 319 DESCRIPTION 320 "Standard snmpXProto group." 321 ::= { snmpXProtoGroups 1} 323 snmpXProtoSubTreeGroup OBJECT-GROUP 324 OBJECTS { 325 snmpXProtoSubTreeFeature, 326 snmpXProtoSubTreeBranch 327 } 328 STATUS current 329 DESCRIPTION 330 "SubTree specific snmpXProto group." 331 ::= { snmpXProtoGroups 2} 333 END 335 6 IANA Considerations 337 IANASnmpExtendedProtocol is a bitmap which indicates which standard 338 extensions to SNMP an SNMP entity supports. It may be given out for 339 SNMP protocol extensions published as standards track RFCs. 341 7. Security Considerations 343 There are no management objects defined in this MIB that have a 344 MAX-ACCESS clause of read-write and/or read-create. So, if this MIB 345 is implemented correctly, then there is no risk that an intruder can 346 alter or create any management objects of this MIB via direct SNMP 347 SET operations. 349 8. Author's Address 351 Sharon Chisholm 352 Nortel Networks 353 PO Box 3511, Station C 354 Ottawa, Ontario, K1Y 4H7 355 Canada 356 Email: schishol@nortelnetworks.com 358 9. Acknowledgments 360 This document is a product of the Evolution of SNMP Working Group. 361 ... 363 10. References 365 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 366 Architecture for Describing SNMP Management Frameworks", 367 RFC 2571, April 41999. 369 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 370 of Management Information for TCP/IP-based Internets", STD 371 16, RFC 1155, May 1990. 373 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 374 STD 16, RFC 1212, March 1991. 376 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 377 SNMP", RFC 1215, March 1991. 379 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 380 Rose, M., and S. Waldbusser, "Structure of Management 381 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 382 1999. 384 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 385 Rose, M., and S. Waldbusser, "Textual Conventions for 386 SMIv2", STD 58, RFC 2579, April 1999. 388 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 389 Rose, M., and S. Waldbusser, "Conformance Statements for 390 SMIv2", STD 58, RFC 2580, April 1999. 392 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 393 "Simple Network Management Protocol", STD 15, RFC 1157, 394 May 1990. 396 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 397 "Introduction to Community-based SNMPv2", RFC 1901, 398 January 399 1996. 401 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 402 "Transport Mappings for Version 2 of the Simple Network 403 Management Protocol (SNMPv2)", RFC 1906, January 1996. 405 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, 406 "Message Processing and Dispatching for the Simple 407 Network Management Protocol (SNMP)", RFC 2572, April 408 1999. 410 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 411 (USM) for version 3 of the Simple Network Management 412 Protocol (SNMPv3)", RFC 2574, April 1999. 414 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 415 "Protocol Operations for Version 2 of the Simple Network 416 Management Protocol (SNMPv2)", RFC 1905, January 1996. 418 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 419 Applications", RFC 2573, April 1999. 421 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 422 Access Control Model (VACM) for the Simple Network 423 Management Protocol (SNMP)", RFC 2575, April 1999. 425 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 426 "Introduction to Version 3 of the Internet-standard 427 Network Management Framework", RFC 2570, April 1999. 429 [RFC2021] Waldbusser, S. "Remote Network Monitoring Management 430 Information Base Version 2 using SMIv2", RFC 2021, 431 January 1997 433 [RFC2274] Blumenthal, U. and B. Wijnen, "User-based Security 434 Model (USM) for version 3 of the Simple Network Management 435 Protocol (SNMPv3)", RFC 2274, January 1998. 437 [RFC2275] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 438 Access Control Model (VACM) for the Simple Network 439 Management Protocol (SNMP)", RFC 2275, January 1998. 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC3014] Stewart, B., Kavasseri, R., "Notification Log MIB, 445 RFC 3014, November 2000 447 11. Full Copyright Statement 449 Copyright (C) The Internet Society (2001). All Rights Reserved. 451 This document and translations of it may be copied and furnished to 452 others, and derivative works that comment on or otherwise explain it 453 or assist in its implementation may be prepared, copied, published 454 and distributed, in whole or in part, without restriction of any kind, 455 provided that the above copyright notice and this paragraph are 456 included on all such copies and derivative works. However, this 457 document itself may not be modified in any way, such as by removing 458 the copyright notice or references to the Internet Society or other 459 Internet organizations, except as needed for the purpose of 460 developing Internet standards in which case the procedures for 461 copyrights defined in the Internet Standards process must be followed, 462 or as required to translate it into languages other than English. 464 The limited permissions granted above are perpetual and will not be 465 revoked by the Internet Society or its successors or assigns. 467 This document and the information contained herein is provided on an 468 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 469 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 470 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 471 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 472 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.