idnits 2.17.1 draft-ietf-snmpv2-intro-ds-06.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-24) 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 8 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 (October 1995) is 10419 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. '3') -- Possible downref: Non-RFC (?) normative reference: 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' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Introduction to SNMPv2 October 1995 3 Introduction to Version 2 of the 4 Internet-standard Network Management Framework 6 18 October 1995 | 8 draft-ietf-snmpv2-intro-ds-06.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 provide an overview of version 2 of 35 the Internet-standard Network Management Framework, termed the SNMP 36 version 2 framework (SNMPv2). The SNMPv2 framework is fully described 37 in [6,7,8,9,10,11]. This framework is derived from the original 38 Internet-standard Network Management Framework (SNMPv1), which consists 39 of these three documents: 41 RFC 1155 [1] which defines the Structure of Management Information 42 (SMI), the mechanisms used for describing and naming objects for 43 the purpose of management. 45 RFC 1212 [2] which defines a more concise description mechanism, 46 which is wholly consistent with the SMI. 48 RFC 1157 [3] which defines the Simple Network Management Protocol 49 (SNMP), the protocol used for network access to managed objects. 51 For information on coexistence between SNMPv1 and SNMPv2, consult [4]. 53 2. Components of the SNMPv2 Framework 55 A management system contains: several (potentially many) nodes, each 56 with a processing entity, termed an agent, which has access to 57 management instrumentation; at least one management station; and, a 58 management protocol, used to convey management information between the 59 agents and management stations. Operations of the protocol are carried 60 out under an administrative framework which defines authentication, 61 authorization, access control, and privacy policies. 63 Management stations execute management applications which monitor and 64 control managed elements. Managed elements are devices such as hosts, 65 routers, terminal servers, etc., which are monitored and controlled via 66 access to their management information. 68 2.1. Structure of Management Information 70 Management information is viewed as a collection of managed objects, 71 residing in a virtual information store, termed the Management 72 Information Base (MIB). Collections of related objects are defined in 73 MIB modules. These modules are written using a subset of OSI's Abstract 74 Syntax Notation One (ASN.1) [5]. It is the purpose of the Structure of 75 Management Information for SNMPv2 document [6] to define that subset. 77 The SMI is divided into three parts: module definitions, object 78 definitions, and, trap definitions. 80 (1) Module definitions are used when describing information modules. 81 An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the 82 semantics of an information module. 84 (2) Object definitions are used when describing managed objects. An 85 ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax 86 and semantics of a managed object. 88 (3) Notification definitions are used when describing unsolicited 89 transmissions of management information. An ASN.1 macro, 90 NOTIFICATION-TYPE, is used to concisely convey the syntax and 91 semantics of a notification. 93 2.2. Textual Conventions 95 When designing a MIB module, it is often useful to define new types 96 similar to those defined in the SMI. In comparison to a type defined in 97 the SMI, each of these new types has a different name, a similar syntax, 98 but a more precise semantics. These newly defined types are termed 99 textual conventions, and are used for the convenience of humans reading 100 the MIB module. It is the purpose of the Textual Conventions for SNMPv2 101 document [7] to define the initial set of textual conventions available 102 to all MIB modules. 104 Objects defined using a textual convention are always encoded by means 105 of the rules that define their primitive type. However, textual 106 conventions often have special semantics associated with them. As such, 107 an ASN.1 macro, TEXTUAL-CONVENTION, is used to concisely convey the 108 syntax and semantics of a textual convention. 110 2.3. Protocol Operations 112 The management protocol provides for the exchange of messages which 113 convey management information between the agents and the management 114 stations. The form of these messages is a message "wrapper" which 115 encapsulates a Protocol Data Unit (PDU). 117 It is the purpose of the Protocol Operations for SNMPv2 document [8] to 118 define the operations of the protocol with respect to the sending and 119 receiving of the PDUs. 121 2.4. Transport Mappings 123 The management protocol, version 2 of the Simple Network Management 124 Protocol, may be used over a variety of protocol suites. It is the 125 purpose of the Transport Mappings for SNMPv2 document [9] to define how 126 the SNMPv2 maps onto an initial set of transport domains. Other 127 mappings may be defined in the future. 129 Although several mappings are defined, the mapping onto UDP is the 130 preferred mapping. As such, to provide for the greatest level of 131 interoperability, systems which choose to deploy other mappings should 132 also provide for proxy service to the UDP mapping. 134 2.5. Protocol Instrumentation 136 It is the purpose of the Management Information Base for SNMPv2 document 137 [10] to define managed objects which describe the behavior of a SNMPv2 138 entity. 140 2.6. Conformance Statements 142 It may be useful to define the acceptable lower-bounds of 143 implementation, along with the actual level of implementation achieved. 144 It is the purpose of the Conformance Statements for SNMPv2 document [11] 145 to define the notation used for these purposes. There are two kinds of 146 notations: 148 (1) Compliance statements are used when describing requirements for 149 agents with respect to object definitions. An ASN.1 macro, 150 MODULE-COMPLIANCE, is used to concisely convey such requirements. 152 (2) Capability statements are used when describing capabilities of 153 agents with respect to object definitions. An ASN.1 macro, AGENT- 154 CAPABILITIES, is used to concisely convey such capabilities. 156 Finally, collections of related objects are grouped together to form a 157 unit of conformance. An ASN.1 macro, OBJECT-GROUP, is used to concisely 158 convey the syntax and semantics of a group. 160 2.7. Administrative Framework 162 It is the purpose of an administrative framework to define an 163 infrastructure through which effective management can be realized in a 164 variety of configurations and environments. Specified as a part of, or 165 as extensions of, an administrative framework are security mechanisms 166 used to achieve an administratively-defined level of security for 167 protocol interactions. 169 The administrative framework for SNMPv2 identified in this document is | 170 the same framework as was defined for SNMPv1 [3]. | 171 This administrative framework associates each message with a "community" | 172 as defined in [3]. Use of this administrative framework with SNMP | 173 Version 2 is commonly known as "Community-based SNMPv2 (SNMPv2C)." | 175 Specifically, Section 3.2.5 of [3] defines the concept of a community, 176 and Section 4.1 of [3] defines the Elements of Procedure for generating 177 and receiving messages. The following updates apply: 179 (1) The types of access defined in Section 3.2.5 of [3] are updated by 180 [6]. 182 (2) The Elements of Procedure defined in Section 4.1 of [3] are updated 183 with the additional requirement of incrementing the relevant 184 statistics counter as defined in [10]. 186 (3) The requirement in the Elements of Procedure in Section 4.1 of [3] 187 that the "the source transport address that a response message is 188 sent from shall be identical to the destination transport address 189 that the original request message was sent to" is deleted, i.e., 190 the source transport address of a response message can be any 191 transport address belonging to the agent. 193 The form of a message is also taken from [3], with the exception that a 194 new version number is used in the message "wrapper". Use of a new 195 version number is necessary because of SNMPv2's new PDU types [8], error 196 codes [8], etc. With this one change, the wrapper becomes: 198 COMMUNITY-BASED-SNMPv2 DEFINITIONS ::= BEGIN 200 -- top-level message 202 Message ::= 203 SEQUENCE { 204 version 205 INTEGER { 206 version(1) -- modified from RFC 1157 207 }, 209 community -- community name 210 OCTET STRING, 212 data -- PDUs as defined in [8] 213 ANY 214 } 215 } 217 END 219 Note that with this administrative framework, the 220 'authorizationError(16)' value defined for the error-status component of 221 an SNMPv2 PDU [8] is unused. It may, however, be used with future 222 administrative frameworks. 224 3. Acknowledgements 226 This document is the result of significant work by the four major 227 contributors: 229 Jeffrey Case (SNMP Research, case@snmp.com) 230 Keith McCloghrie (Cisco Systems, kzm@cisco.com) 231 Marshall Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) 232 Steven Waldbusser (International Network Services, stevew@uni.ins.com) 234 In addition, the contributions of the SNMPv2 Working Group are 235 acknowledged. In particular, a special thanks is extended for the 236 contributions of: 238 Alexander I. Alten (Novell) 239 Dave Arneson (Cabletron) 240 Uri Blumenthal (IBM) 241 Doug Book (Chipcom) 242 Kim Curran (Bell-Northern Research) 243 Jim Galvin (Trusted Information Systems) 244 Maria Greene (Ascom Timeplex) 245 Iain Hanson (Digital) 246 Dave Harrington (Cabletron) 247 Nguyen Hien (IBM) 248 Jeff Johnson (Cisco Systems) 249 Michael Kornegay (Object Quest) 250 Deirdre Kostick (AT&T Bell Labs) 251 David Levi (SNMP Research) 252 Daniel Mahoney (Cabletron) 253 Bob Natale (ACE*COMM) 254 Brian O'Keefe (Hewlett Packard) 255 Andrew Pearson (SNMP Research) 256 Dave Perkins (Peer Networks) 257 Randy Presuhn (Peer Networks) 258 Aleksey Romanov (Quality Quorum) 259 Shawn Routhier (Epilogue) 260 Jon Saperia (BGS Systems) 261 Bob Stewart (Cisco Systems, bstewart@cisco.com), chair 262 Kaj Tesink (Bellcore) 263 Glenn Waters (Bell-Northern Research) 264 Bert Wijnen (IBM) 266 4. References 268 [1] Rose, M., and McCloghrie, K., "Structure and Identification of 269 Management Information for TCP/IP-based internets", STD 16, RFC 270 1155, May 1990. 272 [2] Rose, M., and McCloghrie, K., "Concise MIB Definitions", STD 16, 273 RFC 1212, March 1991. 275 [3] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network 276 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 277 Systems International, MIT Laboratory for Computer Science, May 278 1990. 280 [4] McCloghrie, K., Editor, "Coexistence between Version 1 and Version 281 2 of the Internet-standard Network Management Framework", Internet 282 Draft, Cisco Systems, September 1995. 284 [5] Information processing systems - Open Systems Interconnection - 285 Specification of Abstract Syntax Notation One (ASN.1), 286 International Organization for Standardization. International 287 Standard 8824, (December, 1987). 289 [6] McCloghrie, K., Editor, "Structure of Management Information for 290 Version 2 of the Simple Network Management Protocol (SNMPv2)", 291 Internet Draft, Cisco Systems, September 1995. 293 [7] McCloghrie, K., Editor, "Textual Conventions for Version 2 of the 294 Simple Network Management Protocol (SNMPv2)", Internet Draft, Cisco 295 Systems, September 1995. 297 [8] McCloghrie, K., Editor, "Protocol Operations for Version 2 of the 298 Simple Network Management Protocol (SNMPv2)", Internet Draft, Cisco 299 Systems, September 1995. 301 [9] McCloghrie, K., Editor, "Transport Mappings for Version 2 of the 302 Simple Network Management Protocol (SNMPv2)", Internet Draft, Cisco 303 Systems, September 1995. 305 [10] McCloghrie, K., Editor, "Management Information Base for Version 2 306 of the Simple Network Management Protocol (SNMPv2)", Internet 307 Draft, Cisco Systems, September 1995. 309 [11] McCloghrie, K., Editor, "Conformance Statements for Version 2 of 310 the Simple Network Management Protocol (SNMPv2)", Internet Draft, 311 Cisco Systems, September 1995. 313 5. Security Considerations 315 Security issues are not discussed in this memo. 317 6. Editor's Address 319 Keith McCloghrie 320 Cisco Systems, Inc. 321 170 West Tasman Drive 322 San Jose, CA 95134-1706 323 US 325 Phone: +1 408 526 5260 326 Email: kzm@cisco.com 328 Table of Contents 330 1 Introduction .................................................... 2 331 2 Components of the SNMPv2 Framework .............................. 3 332 2.1 Structure of Management Information ........................... 3 333 2.2 Textual Conventions ........................................... 4 334 2.3 Protocol Operations ........................................... 4 335 2.4 Transport Mappings ............................................ 4 336 2.5 Protocol Instrumentation ...................................... 5 337 2.6 Conformance Statements ........................................ 5 338 2.7 Administrative Framework ...................................... 5 339 3 Acknowledgements ................................................ 7 340 4 References ...................................................... 8 341 5 Security Considerations ......................................... 10 342 6 Editor's Address ................................................ 10