From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3410.txt | 1515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1515 insertions(+) create mode 100644 doc/rfc/rfc3410.txt (limited to 'doc/rfc/rfc3410.txt') diff --git a/doc/rfc/rfc3410.txt b/doc/rfc/rfc3410.txt new file mode 100644 index 0000000..8a214ca --- /dev/null +++ b/doc/rfc/rfc3410.txt @@ -0,0 +1,1515 @@ + + + + + + +Network Working Group J. Case +Request for Comments: 3410 SNMP Research, Inc. +Obsoletes: 2570 R. Mundy +Category: Informational Network Associates Laboratories + D. Partain + Ericsson + B. Stewart + Retired + December 2002 + + + Introduction and Applicability Statements for + Internet Standard Management Framework + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet-standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + The purpose of this document is to provide an overview of the third + version of the Internet-Standard Management Framework, termed the + SNMP version 3 Framework (SNMPv3). This Framework is derived from + and builds upon both the original Internet-Standard Management + Framework (SNMPv1) and the second Internet-Standard Management + Framework (SNMPv2). + + The architecture is designed to be modular to allow the evolution of + the Framework over time. + + The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is + strongly recommended. The document also recommends that RFCs 1157, + 1441, 1901, 1909 and 1910 be retired by moving them to Historic + status. This document obsoletes RFC 2570. + + + + + + + + + + + +Case, et. al. Informational [Page 1] + +RFC 3410 Applicability Statements for SNMP December 2002 + + +Table of Contents + + 1 Introduction ................................................. 2 + 2 The Internet Standard Management Framework ................... 3 + 2.1 Basic Structure and Components ............................. 4 + 2.2 Architecture of the Internet Standard Management Framework . 4 + 3 The SNMPv1 Management Framework .............................. 5 + 3.1 The SNMPv1 Data Definition Language ........................ 6 + 3.2 Management Information ..................................... 6 + 3.3 Protocol Operations ........................................ 7 + 3.4 SNMPv1 Security and Administration ......................... 7 + 4 The SNMPv2 Management Framework .............................. 8 + 5 The SNMPv3 Working Group ..................................... 8 + 6 SNMPv3 Framework Module Specifications ....................... 10 + 6.1 Data Definition Language ................................... 11 + 6.2 MIB Modules ................................................ 12 + 6.3 Protocol Operations and Transport Mappings ................. 13 + 6.4 SNMPv3 Security and Administration ......................... 13 + 7 Document Summaries ........................................... 14 + 7.1 Structure of Management Information ........................ 14 + 7.1.1 Base SMI Specification ................................... 15 + 7.1.2 Textual Conventions ...................................... 15 + 7.1.3 Conformance Statements ................................... 16 + 7.2 Protocol Operations ........................................ 16 + 7.3 Transport Mappings ......................................... 16 + 7.4 Protocol Instrumentation ................................... 17 + 7.5 Architecture / Security and Administration ................. 17 + 7.6 Message Processing and Dispatch (MPD) ...................... 17 + 7.7 SNMP Applications .......................................... 18 + 7.8 User-based Security Model (USM) ............................ 18 + 7.9 View-based Access Control (VACM) ........................... 19 + 7.10 SNMPv3 Coexistence and Transition ......................... 19 + 8 Standardization Status ....................................... 20 + 8.1 SMIv1 Status ............................................... 20 + 8.2 SNMPv1 and SNMPv2 Standardization Status ................... 21 + 8.3 Working Group Recommendation ............................... 22 + 9 Security Considerations ...................................... 22 + 10 References .................................................. 22 + 11 Editor's Addresses .......................................... 26 + 12 Full Copyright Statement .................................... 27 + +1. Introduction + + This document is an introduction to the third version of the + Internet-Standard Management Framework, termed the SNMP version 3 + Management Framework (SNMPv3) and has multiple purposes. + + + + + +Case, et. al. Informational [Page 2] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + First, it describes the relationship between the SNMP version 3 + (SNMPv3) specifications and the specifications of the SNMP version 1 + (SNMPv1) Management Framework, the SNMP version 2 (SNMPv2) Management + Framework, and the Community-based Administrative Framework for + SNMPv2. + + Second, it provides a roadmap to the multiple documents which contain + the relevant specifications. + + Third, this document provides a brief easy-to-read summary of the + contents of each of the relevant specification documents. + + This document is intentionally tutorial in nature and, as such, may + occasionally be "guilty" of oversimplification. In the event of a + conflict or contradiction between this document and the more detailed + documents for which this document is a roadmap, the specifications in + the more detailed documents shall prevail. + + Further, the detailed documents attempt to maintain separation + between the various component modules in order to specify well- + defined interfaces between them. This roadmap document, however, + takes a different approach and attempts to provide an integrated view + of the various component modules in the interest of readability. + + This document is a work product of the SNMPv3 Working Group of the + Internet Engineering Task Force (IETF). + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [1]. + +2. The Internet Standard Management Framework + + The third version of the Internet Standard Management Framework (the + SNMPv3 Framework) is derived from and builds upon both the original + Internet-Standard Management Framework (SNMPv1) and the second + Internet-Standard Management Framework (SNMPv2). + + All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard + Management SNMP Framework share the same basic structure and + components. Furthermore, all versions of the specifications of the + Internet Standard Management Framework follow the same architecture. + + + + + + + + + +Case, et. al. Informational [Page 3] + +RFC 3410 Applicability Statements for SNMP December 2002 + + +2.1. Basic Structure and Components + + An enterprise deploying the Internet Standard Management Framework + contains four basic components: + + * several (typically many) managed nodes, each with an SNMP entity + which provides remote access to management instrumentation + (traditionally called an agent); + + * at least one SNMP entity with management applications (typically + called a manager), + + * a management protocol used to convey management information + between the SNMP entities, and + + * management information. + + The management protocol is used to convey management information + between SNMP entities such as managers and agents. + + This basic structure is common to all versions of the Internet + Standard Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3. + +2.2. Architecture of the Internet Standard Management Framework + + The specifications of the Internet Standard Management Framework are + based on a modular architecture. This framework is more than just a + protocol for moving data. It consists of: + + * a data definition language, + + * definitions of management information (the Management Information + Base, or MIB), + + * a protocol definition, and + + * security and administration. + + Over time, as the Framework has evolved from SNMPv1, through SNMPv2, + to SNMPv3, the definitions of each of these architectural components + have become richer and more clearly defined, but the fundamental + architecture has remained consistent. + + One prime motivator for this modularity was to enable the ongoing + evolution of the Framework, as is documented in RFC 1052 [2]. When + originally envisioned, this capability was to be used to ease the + transition from SNMP-based management of internets to management + based on OSI protocols. To this end, the framework was architected + + + +Case, et. al. Informational [Page 4] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + with a protocol-independent data definition language and Management + Information Base along with a MIB-independent protocol. This + separation was designed to allow the SNMP-based protocol to be + replaced without requiring the management information to be redefined + or reinstrumented. History has shown that the selection of this + architecture was the right decision for the wrong reason -- it turned + out that this architecture has eased the transition from SNMPv1 to + SNMPv2 and from SNMPv2 to SNMPv3 rather than easing the transition + away from management based on the Simple Network Management Protocol. + + The SNMPv3 Framework builds and extends these architectural + principles by: + + * building on these four basic architectural components, in some + cases incorporating them from the SNMPv2 Framework by reference, + and + + * by using these same layering principles in the definition of new + capabilities in the security and administration portion of the + architecture. + + Those who are familiar with the architecture of the SNMPv1 Management + Framework and the SNMPv2 Management Framework will find many familiar + concepts in the architecture of the SNMPv3 Management Framework. + However, in some cases, the terminology may be somewhat different. + +3. The SNMPv1 Management Framework + + The original Internet-Standard Network Management Framework (SNMPv1) + is defined in the following documents: + + * STD 16, RFC 1155 [3] which defines the Structure of Management + Information (SMI), the mechanisms used for describing and naming + objects for the purpose of management. + + * STD 16, RFC 1212 [4] which defines a more concise description + mechanism for describing and naming management information + objects, but which is wholly consistent with the SMI. + + * STD 15, RFC 1157 [5] which defines the Simple Network Management + Protocol (SNMP), the protocol used for network access to managed + objects and event notification. Note this document also defines + an initial set of event notifications. + + + + + + + + +Case, et. al. Informational [Page 5] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + Additionally, two documents are generally considered companions to + these three: + + * STD 17, RFC 1213 [6] which contains definitions for the base set + of management information + + * RFC 1215 [7] defines a concise description mechanism for defining + event notifications, which are called traps in the SNMPv1 + protocol. It also specifies the generic traps from RFC 1157 in + the concise notation. + + These documents describe the four parts of the first version of the + SNMP Framework. + +3.1. The SNMPv1 Data Definition Language + + The first two and the last document, i.e., RFCs 1155, 1212, and 1215, + describe the SNMPv1 data definition language and are often + collectively referred to as "SMIv1". Note that due to the initial + requirement that the SMI be protocol-independent, the first two SMI + documents do not provide a means for defining event notifications + (traps). Instead, the SNMP protocol document defines a few + standardized event notifications (generic traps) and provides a means + for additional event notifications to be defined. The last document + specifies a straight-forward approach towards defining event + notifications used with the SNMPv1 protocol. At the time that it was + written, use of traps in the Internet-Standard network management + framework was controversial. As such, RFC 1215 was put forward with + the status of "Informational", which was never updated because it was + believed that the second version of the SNMP Framework would replace + the first version. + +3.2. Management Information + + The data definition language described in the first two documents was + first used to define the now-historic MIB-I as specified in RFC 1066 + [8], and was subsequently used to define MIB-II as specified in RFC + 1213 [6]. + + Later, after the publication of MIB-II, a different approach to the + management information definition was taken from the earlier approach + of having a single committee staffed by generalists work on a single + document to define the Internet-Standard MIB. Rather, many mini-MIB + documents were produced in a parallel and distributed fashion by + groups chartered to produce a specification for a focused portion of + the Internet-Standard MIB and staffed by personnel with expertise in + those particular areas ranging from various aspects of network + management, to system management, and application management. + + + +Case, et. al. Informational [Page 6] + +RFC 3410 Applicability Statements for SNMP December 2002 + + +3.3. Protocol Operations + + The third document, STD 15 [5], describes the SNMPv1 protocol + operations performed by protocol data units (PDUs) on lists of + variable bindings and describes the format of SNMPv1 messages. The + operators defined by SNMPv1 are: get, get-next, get-response, set- + request, and trap. Typical layering of SNMP on a connectionless + transport service is also defined. + +3.4. SNMPv1 Security and Administration + + STD 15 [5] also describes an approach to security and administration. + Many of these concepts are carried forward and some, particularly + security, are extended by the SNMPv3 Framework. + + The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in + SNMP messages between SNMP entities and distinguishes between + application entities and protocol entities. In SNMPv3, these are + renamed applications and engines, respectively. + + The SNMPv1 Framework also introduces the concept of an authentication + service supporting one or more authentication schemes. In addition + to authentication, SNMPv3 defines the additional security capability + referred to as privacy. (Note: some literature from the security + community would describe SNMPv3 security capabilities as providing + data integrity, source authenticity, and confidentiality.) The + modular nature of the SNMPv3 Framework permits both changes and + additions to the security capabilities. + + Finally, the SNMPv1 Framework introduces access control based on a + concept called an SNMP MIB view. The SNMPv3 Framework specifies a + fundamentally similar concept called view-based access control. With + this capability, SNMPv3 provides the means for controlling access to + information on managed devices. + + However, while the SNMPv1 Framework anticipated the definition of + multiple authentication schemes, it did not define any such schemes + other than a trivial authentication scheme based on community + strings. This was a known fundamental weakness in the SNMPv1 + Framework but it was thought at that time that the definition of + commercial grade security might be contentious in its design and + difficult to get approved because "security" means many different + things to different people. To that end, and because some users do + not require strong authentication, the SNMPv1 architected an + authentication service as a separate block to be defined "later" and + the SNMPv3 Framework provides an architecture for use within that + block as well as a definition for its subsystems. + + + + +Case, et. al. Informational [Page 7] + +RFC 3410 Applicability Statements for SNMP December 2002 + + +4. The SNMPv2 Management Framework + + The SNMPv2 Management Framework is described in [8-13] and + coexistence and transition issues relating to SNMPv1 and SNMPv2 are + discussed in [15]. + + SNMPv2 provides several advantages over SNMPv1, including: + + * expanded data types (e.g., 64 bit counter) + + * improved efficiency and performance (get-bulk operator) + + * confirmed event notification (inform operator) + + * richer error handling (errors and exceptions) + + * improved sets, especially row creation and deletion + + * fine tuning of the data definition language + + However, the SNMPv2 Framework, as described in these documents, is + incomplete in that it does not meet the original design goals of the + SNMPv2 project. The unmet goals included provision of security and + administration delivering so-called "commercial grade" security with: + + * authentication: origin identification, message integrity, and + some aspects of replay protection; + + * privacy: confidentiality; + + * authorization and access control; and + + * suitable remote configuration and administration capabilities for + these features. + + The SNMPv3 Management Framework, as described in this document and + the companion documents, addresses these significant deficiencies. + +5. The SNMPv3 Working Group + + This document, and its companion documents, were produced by the + SNMPv3 Working Group of the Internet Engineering Task Force (IETF). + The SNMPv3 Working Group was chartered to prepare recommendations for + the next generation of SNMP. The goal of the Working Group was to + produce the necessary set of documents that provide a single standard + for the next generation of core SNMP functions. The single, most + critical need in the next generation is a definition of security and + administration that makes SNMP-based management transactions secure + + + +Case, et. al. Informational [Page 8] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + in a way which is useful for users who wish to use SNMPv3 to manage + networks, the systems that make up those networks, and the + applications which reside on those systems, including manager-to- + agent, agent-to-manager, and manager-to-manager transactions. + + In the several years prior to the chartering of the Working Group, + there were a number of activities aimed at incorporating security and + other improvements to SNMP. These efforts included: + + * "SNMP Security" circa 1991-1992 (RFC 1351 - RFC 1353), + + * "SMP" circa 1992-1993, and + + * "The Party-based SNMPv2" (sometimes called "SNMPv2p") circa + 1993-1995 (RFC 1441 - RFC 1452). + + Each of these efforts incorporated commercial grade, industrial + strength security including authentication, privacy, authorization, + view-based access control, and administration, including remote + configuration. + + These efforts fed the development of the SNMPv2 Management Framework + as described in RFCs 1902 - 1908. However, the Framework described + in those RFCs had no standards-based security and administrative + framework of its own; rather, it was associated with multiple + security and administrative frameworks, including: + + * "The Community-based SNMPv2" (SNMPv2c) as described in RFC 1901 + [16], + + * "SNMPv2u" as described in RFCs 1909 and 1910, and + + * "SNMPv2*." + + SNMPv2c had the most support within the IETF but had no security and + administration whereas both SNMPv2u and SNMPv2* had security but + lacked a consensus of support within the IETF. + + The SNMPv3 Working Group was chartered to produce a single set of + specifications for the next generation of SNMP, based upon a + convergence of the concepts and technical elements of SNMPv2u and + SNMPv2*, as was suggested by an advisory team which was formed to + provide a single recommended approach for SNMP evolution. + + + + + + + + +Case, et. al. Informational [Page 9] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + In so doing, the Working Group charter defined the following + objectives: + + * accommodate the wide range of operational environments with + differing management demands; + + * facilitate the need to transition from previous, multiple + protocols to SNMPv3; + + * facilitate the ease of setup and maintenance activities. + + In the initial work of the SNMPv3 Working Group, the group focused on + security and administration, including: + + * authentication and privacy, + + * authorization and view-based access control, and + + * standards-based remote configuration of the above. + + The SNMPv3 Working Group did not "reinvent the wheel", but reused the + SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for + those portions of the design that were outside the focused scope. + + Rather, the primary contributors to the SNMPv3 Working Group, and the + Working Group in general, devoted their considerable efforts to + addressing the missing link -- security and administration -- and in + the process made invaluable contributions to the state-of-the-art of + management. + + They produced a design based on a modular architecture with + evolutionary capabilities with emphasis on layering. As a result, + SNMPv3 can be thought of as SNMPv2 with additional security and + administration capabilities. + + In doing so, the Working Group achieved the goal of producing a + single specification which has not only the endorsement of the IETF + but also has security and administration. + +6. SNMPv3 Framework Module Specifications + + The specification of the SNMPv3 Management Framework is partitioned + in a modular fashion among several documents. It is the intention of + the SNMPv3 Working Group that, with proper care, any or all of the + individual documents can be revised, upgraded, or replaced as + requirements change, new understandings are obtained, and new + technologies become available. + + + + +Case, et. al. Informational [Page 10] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + Whenever feasible, the initial document set which defines the SNMPv3 + Management Framework leverages prior investments defining and + implementing the SNMPv2 Management Framework by incorporating by + reference each of the specifications of the SNMPv2 Management + Framework. + + The SNMPv3 Framework augments those specifications with + specifications for security and administration for SNMPv3. + + The documents which specify the SNMPv3 Management Framework follow + the same architecture as those of the prior versions and can be + organized for expository purposes into four main categories as + follows: + + * the data definition language, + + * Management Information Base (MIB) modules, + + * protocol operations, and + + * security and administration. + + The first three sets of documents are incorporated from SNMPv2. The + documents in the fourth set are new to SNMPv3, but, as described + previously, build on significant prior related works. + +6.1. Data Definition Language + + The specifications of the data definition language include STD 58, + RFC 2578, "Structure of Management Information Version 2 (SMIv2)" + [17], and related specifications. These documents are updates of + RFCs 1902 - 1904 [9-11] which have evolved independently from the + other parts of the framework and were republished with minor + editorial changes as STD 58, RFCs 2578 - 2580 [17-19] when promoted + from Draft Standard to full Standard. + + The Structure of Management Information (SMIv2) defines fundamental + data types, an object model, and the rules for writing and revising + MIB modules. Related specifications include STD 58, RFCs 2579, 2580. + + STD 58, RFC 2579, "Textual Conventions for SMIv2" [18], defines an + initial set of shorthand abbreviations which are available for use + within all MIB modules for the convenience of human readers and + writers. + + + + + + + +Case, et. al. Informational [Page 11] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + STD 58, RFC 2580, "Conformance Statements for SMIv2" [19], defines + the format for compliance statements which are used for describing + requirements for agent implementations and capability statements + which can be used to document the characteristics of particular + implementations. + + The term "SMIv2" is somewhat ambiguous because users of the term + intend it to have at least two different meanings. Sometimes the + term is used to refer the entire data definition language of STD 58, + defined collectively in RFCs 2578 - 2580 whereas at other times it is + used to refer to only the portion of the data definition language + defined in RFC 2578. This ambiguity is unfortunate but is rarely a + significant problem in practice. + +6.2. MIB Modules + + MIB modules usually contain object definitions, may contain + definitions of event notifications, and sometimes include compliance + statements specified in terms of appropriate object and event + notification groups. As such, MIB modules define the management + information maintained by the instrumentation in managed nodes, made + remotely accessible by management agents, conveyed by the management + protocol, and manipulated by management applications. + + MIB modules are defined according to the rules defined in the + documents which specify the data definition language, principally the + SMI as supplemented by the related specifications. + + There is a large and growing number of standards-track MIB modules, + as defined in the periodically updated "Internet Official Protocol + Standards" list [20]. As of this writing, there are more than 100 + standards-track MIB modules with a total number of defined objects + exceeding 10,000. In addition, there is an even larger and growing + number of enterprise-specific MIB modules defined unilaterally by + various vendors, research groups, consortia, and the like resulting + in an unknown and virtually uncountable number of defined objects. + + In general, management information defined in any MIB module, + regardless of the version of the data definition language used, can + be used with any version of the protocol. For example, MIB modules + defined in terms of the SNMPv1 SMI (SMIv1) are compatible with the + SNMPv3 Management Framework and can be conveyed by the protocols + specified therein. Furthermore, MIB modules defined in terms of the + SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and + can be conveyed by it. However, there is one noteworthy exception: + the Counter64 datatype which can be defined in a MIB module defined + + + + + +Case, et. al. Informational [Page 12] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + in SMIv2 format but which cannot be conveyed by an SNMPv1 protocol + engine. It can be conveyed by an SNMPv2 or an SNMPv3 engine, but + cannot be conveyed by an engine which exclusively supports SNMPv1. + +6.3. Protocol Operations and Transport Mappings + + The specifications for the protocol operations and transport mappings + of the SNMPv3 Framework are incorporated by reference to the two + SNMPv2 Framework documents which have subsequently been updated. + + The specification for protocol operations is found in STD 62, RFC + 3416, "Version 2 of the Protocol Operations for the Simple Network + Management Protocol (SNMP)" [21]. + + The SNMPv3 Framework is designed to allow various portions of the + architecture to evolve independently. For example, it might be + possible for a new specification of protocol operations to be defined + within the Framework to allow for additional protocol operations. + + The specification of transport mappings is found in STD 62, RFC 3417, + "Transport Mappings for the Simple Network Management Protocol + (SNMP)" [22]. + +6.4. SNMPv3 Security and Administration + + The document series pertaining to SNMPv3 Security and Administration + defined by the SNMPv3 Working Group consists of seven documents at + this time: + + RFC 3410, "Introduction and Applicability Statements for the + Internet-Standard Management Framework", which is this document. + + STD 62, RFC 3411, "An Architecture for Describing Simple Network + Management Protocol (SNMP) Management Frameworks" [23], describes + the overall architecture with special emphasis on the architecture + for security and administration. + + STD 62, RFC 3412, "Message Processing and Dispatching for the + Simple Network Management Protocol (SNMP)" [24], describes the + possibility of multiple message processing models and the + dispatcher portion that can be a part of an SNMP protocol engine. + + STD 62, RFC 3413, "Simple Network Management Protocol (SNMP) + Applications" [25], describes the five initial types of + applications that can be associated with an SNMPv3 engine and + their elements of procedure. + + + + + +Case, et. al. Informational [Page 13] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + STD 62, RFC 3414, "User-Based Security Model (USM) for Version 3 + of the Simple Network Management Protocol (SNMPv3)" [26], + describes the threats against which protection is provided, as + well as the mechanisms, protocols, and supporting data used to + provide SNMP message-level security with the user-based security + model. + + STD 62, RFC 3415, "View-based Access Control Model (VCAM) for the + Simple Network Management Protocol (SNMP)" [27], describes how + view-based access control can be applied within command responder + and notification originator applications. + + RFC 2576, "SNMPv3 Coexistence and Transition" [28], describes + coexistence between the SNMPv3 Management Framework, the SNMPv2 + Management Framework, and the original SNMPv1 Management + Framework, and is in the process of being updated by a Work in + Progress. + +7. Document Summaries + + The following sections provide brief summaries of each document with + slightly more detail than is provided in the overviews above. + +7.1. Structure of Management Information + + Management information is viewed as a collection of managed objects, + residing in a virtual information store, termed the Management + Information Base (MIB). Collections of related objects are defined + in MIB modules. These modules are written in the SNMP data + definition language, which evolved from an adapted subset of OSI's + Abstract Syntax Notation One (ASN.1) [29] language. STD 58, RFCs + 2578, 2579, 2580, collectively define the data definition language, + specify the base data types for objects, specify a core set of + short-hand specifications for data types called textual conventions, + and specify a few administrative assignments of object identifier + (OID) values. + + The SMI is divided into three parts: module definitions, object + definitions, and notification definitions. + + (1) Module definitions are used when describing information modules. + An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the + semantics of an information module. + + (2) Object definitions are used when describing managed objects. An + ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax + and semantics of a managed object. + + + + +Case, et. al. Informational [Page 14] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + (3) Notification definitions are used when describing unsolicited + transmissions of management information. An ASN.1 macro, + NOTIFICATION-TYPE, is used to convey concisely the syntax and + semantics of a notification. + + As noted earlier, the term "SMIv2" is somewhat ambiguous because + users of the term intend it to have at least two different meanings. + Sometimes the term is used to refer to the entire data definition + language of STD 58, defined collectively in RFCs 2578 - 2580 whereas + at other times it is used to refer to only the portion of the data + definition language defined in RFC 2578. This ambiguity is + unfortunate but is rarely a significant problem in practice. + +7.1.1. Base SMI Specification + + STD 58, RFC 2578 specifies the base data types for the data + definition language, which include: Integer32, enumerated integers, + Unsigned32, Gauge32, Counter32, Counter64, TimeTicks, INTEGER, OCTET + STRING, OBJECT IDENTIFIER, IpAddress, Opaque, and BITS. It also + assigns values to several object identifiers. STD 58, RFC 2578 + further defines the following constructs of the data definition + language: + + * IMPORTS to allow the specification of items that are used in a MIB + module, but defined in another MIB module. + + * MODULE-IDENTITY to specify for a MIB module a description and + administrative information such as contact and revision history. + + * OBJECT-IDENTITY and OID value assignments to specify an OID value. + + * OBJECT-TYPE to specify the data type, status, and the semantics of + managed objects. + + * SEQUENCE type assignment to list the columnar objects in a table. + + * NOTIFICATION-TYPE construct to specify an event notification. + +7.1.2. Textual Conventions + + When designing a MIB module, it is often useful to specify, in a + short-hand way, the semantics for a set of objects with similar + behavior. This is done by defining a new data type using a base data + type specified in the SMI. Each new type has a different name, and + specifies a base type with more restrictive semantics. These newly + defined types are termed textual conventions, and are used for the + convenience of humans reading a MIB module and potentially by + "intelligent" management applications. It is the purpose of STD 58, + + + +Case, et. al. Informational [Page 15] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + RFC 2579, Textual Conventions for SMIv2 [18], to define the + construct, TEXTUAL-CONVENTION, of the data definition language used + to define such new types and to specify an initial set of textual + conventions available to all MIB modules. + +7.1.3. Conformance Statements + + It may be useful to define the acceptable lower-bounds of + implementation, along with the actual level of implementation + achieved. It is the purpose of STD 58, RFC 2580, Conformance + Statements for SMIv2 [19], to define the constructs of the data + definition language used for these purposes. There are two kinds of + constructs: + + (1) Compliance statements are used when describing requirements for + agents with respect to object and event notification definitions. + The MODULE-COMPLIANCE construct is used to convey concisely such + requirements. + + (2) Capability statements are used when describing capabilities of + agents with respect to object and event notification definitions. + The AGENT-CAPABILITIES construct is used to convey concisely such + capabilities. + + Finally, collections of related objects and collections of related + event notifications are grouped together to form a unit of + conformance. The OBJECT-GROUP construct is used to convey concisely + the objects in and the semantics of an object group. The + NOTIFICATION-GROUP construct is used to convey concisely the event + notifications in and the semantics of an event notification group. + +7.2. Protocol Operations + + The management protocol provides for the exchange of messages which + convey management information between the agents and the management + stations. The form of these messages is a message "wrapper" which + encapsulates a Protocol Data Unit (PDU). + + It is the purpose of STD 62, RFC 3416, "Version 2 of the Protocol + Operations for the Simple Network Management Protocol (SNMP)" [21], + to define the operations of the protocol with respect to the sending + and receiving of the PDUs. + +7.3. Transport Mappings + + SNMP messages may be used over a variety of protocol suites. It is + the purpose of STD 62, RFC 3417, "Transport Mappings for the Simple + Network Management Protocol (SNMP)" [22], to define how SNMP messages + + + +Case, et. al. Informational [Page 16] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + map onto an initial set of transport domains. Other mappings may be + defined in the future. + + Although several mappings are defined, the mapping onto UDP is the + preferred mapping. As such, to provide for the greatest level of + interoperability, systems which choose to deploy other mappings + should also provide for proxy service to the UDP mapping. + +7.4. Protocol Instrumentation + + It is the purpose of STD 62, RFC 3418, "Management Information Base + (MIB) for the Simple Network Management Protocol (SNMP)" [30], to + define managed objects which describe the behavior of portions of an + SNMP entity. + +7.5. Architecture / Security and Administration + + It is the purpose of STD 62, RFC 3411, "An Architecture for + Describing Simple Network Management Protocol (SNMP) Management + Frameworks" [23], to define an architecture for specifying Management + Frameworks. While addressing general architectural issues, it + focuses on aspects related to security and administration. It + defines a number of terms used throughout the SNMPv3 Management + Framework and, in so doing, clarifies and extends the naming of: + + * engines and applications, + + * entities (service providers such as the engines in agents and + managers), + + * identities (service users), and + + * management information, including support for multiple logical + contexts. + + The document contains a small MIB module which is implemented by all + authoritative SNMPv3 protocol engines. + +7.6. Message Processing and Dispatch (MPD) + + STD 62, RFC 3412, "Message Processing and Dispatching for the Simple + Network Management Protocol (SNMP)" [24], describes the Message + Processing and Dispatching for SNMP messages within the SNMP + architecture. It defines the procedures for dispatching potentially + multiple versions of SNMP messages to the proper SNMP Message + Processing Models, and for dispatching PDUs to SNMP applications. + This document also describes one Message Processing Model - the + SNMPv3 Message Processing Model. + + + +Case, et. al. Informational [Page 17] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + An SNMPv3 protocol engine MUST support at least one Message + Processing Model. An SNMPv3 protocol engine MAY support more than + one, for example in a multi-lingual system which provides + simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c. For + example, such a tri-lingual system which provides simultaneous + support for SNMPv1, SNMPv2c, and SNMPv3 supports three message + processing models. + +7.7. SNMP Applications + + It is the purpose of STD 62, RFC 3413, "Simple Network Management + Protocol (SNMP) Applications" [25] to describe the five types of + applications which can be associated with an SNMP engine. They are: + Command Generators, Command Responders, Notification Originators, + Notification Receivers, and Proxy Forwarders. + + The document also defines MIB modules for specifying targets of + management operations (including notifications), for notification + filtering, and for proxy forwarding. + +7.8. User-based Security Model (USM) + + STD 62, RFC 3414, the "User-based Security Model (USM) for version 3 + of the Simple Network Management Protocol (SNMPv3)" [26] describes + the User-based Security Model for SNMPv3. It defines the Elements of + Procedure for providing SNMP message-level security. + + The document describes the two primary and two secondary threats + which are defended against by the User-based Security Model. They + are: modification of information, masquerade, message stream + modification, and disclosure. + + The USM utilizes MD5 [31] and the Secure Hash Algorithm [32] as keyed + hashing algorithms [33] for digest computation to provide data + integrity: + + * to directly protect against data modification attacks, + + * to indirectly provide data origin authentication, and + + * to defend against masquerade attacks. + + The USM uses loosely synchronized monotonically increasing time + indicators to defend against certain message stream modification + attacks. Automatic clock synchronization mechanisms based on the + protocol are specified without dependence on third-party time sources + and concomitant security considerations. + + + + +Case, et. al. Informational [Page 18] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + The USM uses the Data Encryption Standard (DES) [34] in the cipher + block chaining mode (CBC) if disclosure protection is desired. + Support for DES in the USM is optional, primarily because export and + usage restrictions in many countries make it difficult to export and + use products which include cryptographic technology. + + The document also includes a MIB suitable for remotely monitoring and + managing the configuration parameters for the USM, including key + distribution and key management. + + An entity may provide simultaneous support for multiple security + models as well as multiple authentication and privacy protocols. All + of the protocols used by the USM are based on pre-placed keys, i.e., + private key mechanisms. The SNMPv3 architecture permits the use of + symmetric and asymmetric mechanisms and protocols (asymmetric + mechanisms are commonly called public key cryptography) but, as of + this writing, there are no SNMPv3 security models on the IETF + standards track that use public key cryptography. + + Work is underway to specify how AES is to be used within the User- + based Security Model (USM). This will be a separate document. + +7.9. View-based Access Control (VACM) + + The purpose of STD 62, RFC 3415, the "View-based Access Control Model + (VACM) for the Simple Network Management Protocol (SNMP)" [27], is to + describe the View-based Access Control Model for use in the SNMP + architecture. The VACM can simultaneously be associated in a single + engine implementation with multiple Message Processing Models and + multiple Security Models. + + It is architecturally possible to have multiple, different, Access + Control Models active and present simultaneously in a single engine + implementation, but this is expected to be *_very_* rare in practice + and *_far_* less common than simultaneous support for multiple + Message Processing Models and/or multiple Security Models. + +7.10. SNMPv3 Coexistence and Transition + + The purpose of RFC 2576, "Coexistence between Version 1, Version 2, + and Version 3 of the Internet-Standard Network Management Framework" + [28], is to describe coexistence between the SNMPv3 Management + Framework, the SNMPv2 Management Framework, and the original SNMPv1 + Management Framework. In particular, this document describes four + aspects of coexistence: + + * Conversion of MIB documents from SMIv1 to SMIv2 format + + + + +Case, et. al. Informational [Page 19] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + * Mapping of notification parameters + + * Approaches to coexistence between entities which support the + various versions of SNMP in a multi-lingual network, in particular + the processing of protocol operations in multi-lingual + implementations, as well as behavior of proxy implementations + + * The SNMPv1 Message Processing Model and Community-Based Security + Model, which provides mechanisms for adapting SNMPv1 and SNMPv2c + into the View-Based Access Control Model (VACM) [27] + +8. Standardization Status + + Readers should consult the latest version of the "Internet Official + Protocol Standards" list [20] to determine the standardization status + of any document. + + However, the SNMPv3 Working Group explicitly requested that text be + included in this document to amplify on the status of SMIv1, SNMPv1, + and SNMPv2c. + +8.1. SMIv1 Status + + SMIv1, as described in STD 16, RFCs 1155 and 1212, was promoted to + full Standard status in 1990 and has remained a Standard even after + SMIv2 reached full Standard (see RFC 2026 [35] for more information + about the Internet Standards Process). In many cases, a Standard is + declared "Historic" when its replacement reaches full Standard. For + example, MIB-1 [8] was declared "Historic" when MIB-2 [6] reached + full Standard. Similarly, when SMIv2 reached full Standard, it might + have been reasonable at that time to retire SMIv1 and declare it to + be "Historic" but as the result of a conscious decision, STD 16, RFCs + 1155 and 1212 continue to have the standardization status of full + "Standard" but are not recommended. These documents were not + declared "Historic" and remain on the standards track because they + provide normative references for other documents on the standards + track and cannot be declared "Historic" without rendering the + documents which rely on them to also become "Historic". + Consequently, STD 16 retains its standardization status but is not + recommended because it has been superseded by the newer SMIv2 + specifications which are identified somewhat later in this document. + + On a pragmatic level, since about 1993 it has been wise for users of + the data definition language to use SMIv2 for all new work because + the realities of the marketplace have occasionally required the + support of data definitions in both the SMIv1 and SMIv2 formats. + While there are tools widely available at low cost or no cost to + translate SMIv2 definitions to SMIv1 definitions, it is impractical + + + +Case, et. al. Informational [Page 20] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + to build automatic tools that automatically translate SMIv1 + definitions to SMIv2 definitions. Consequently, if one works in + primarily SMIv2, the cost of providing data definitions in both SMIv1 + and SMIv2 formats is trivial. In contrast, if one works primarily in + SMIv1 format, providing data definitions in both SMIv1 and SMIv2 is + significantly more expensive. The market requirements today for + providing data definitions in SMIv1 format are greatly diminished + when compared to those of 1993, and SMIv2 continues to be the + strongly preferred format even though SMIv1 has not been declared + "Historic". Indeed, the IETF currently requires that new MIB modules + be written using SMIv2. + +8.2. SNMPv1 and SNMPv2 Standardization Status + + Protocol operations via SNMPv1 and SNMPv2c message wrappers support + only trivial authentication based on plain-text community strings + and, as a result, are fundamentally insecure. When the SNMPv3 + specifications for security and administration, which include strong + security, reached full Standard status, the full Standard SNMPv1, + formerly STD 15 [5], and the experimental SNMPv2c specifications + described in RFC 1901 [16] were declared Historic due to their + weaknesses with respect to security and to send a clear message that + the third version of the Internet Standard Management Framework is + the framework of choice. The Party-based SNMPv2 (SNMPv2p), SNMPv2u, + and SNMPv2* were either declared Historic circa 1995 or were never on + the standards track. + + On a pragmatic level, it is expected that a number of vendors will + continue to produce and users will continue to deploy and use multi- + lingual implementations that support SNMPv1 and/or SNMPv2c as well as + SNMPv3. It should be noted that the IETF standards process does not + control actions of vendors or users who may choose to promote or + deploy historic protocols, such as SNMPv1 and SNMPv2c, in spite of + known short-comings. However, it is not expected that vendors will + produce nor that users will deploy multi-lingual implementations that + support the Party-based SNMPv2p (SNMPv2p), SNMPv2u, or SNMPv2*. + + Indeed, as described above, one of the SNMPv3 specifications for + security and administration, RFC 2576, Coexistence between Version 1, + Version 2, and Version 3 of the Internet-Standard Management + Framework [28], addresses these issues. + + Of course, it is important that users deploying multi-lingual systems + with insecure protocols exercise sufficient due diligence to insure + that configurations limit access via SNMPv1 and SNMPv2c + appropriately, in keeping with the organization's security policy, + just as they should carefully limit access granted via SNMPv3 with a + security level of no authentication and no privacy which is roughly + + + +Case, et. al. Informational [Page 21] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + equivalent from a security point of view. For example, it is + probably unwise to allow SNMPv1 or SNMPv2c a greater level of access + than is provided to unauthenticated SNMPv3 users, e.g., it does not + make sense to guard the front door with armed guards, trained attack + dogs, moats and drawbridges while providing unfettered access through + an open back door. + + The SNMPv1 framework, SNMPv2 framework, and SNMPv2c had limited + capabilities for administering the SNMPv1 and SNMPv2c protocols. For + example, there are no objects defined to view and configure + communities or destinations for notifications (traps and informs). + The result has been vendor defined mechanisms for administration that + range from proprietary format configuration files that cannot be + viewed or configured via SNMP to enterprise specific object + definitions. The SNMPv3 framework provides a rich standards-based + approach to administration which, by design, can be used for the + SNMPv1 and SNMPv2c protocols. Thus, to foster interoperability of + administration of SNMPv1 and SNMPv2c protocols in multi-lingual + systems, the mechanisms and objects specified in [25], [27], and [28] + should be used to supplement or replace the equivalent proprietary + mechanisms. + +8.3. Working Group Recommendation + + Based on the explanations above, the SNMPv3 Working Group recommends + that RFCs 1157, 1441, 1901, 1909 and 1910 be reclassified as + Historical documents. + +9. Security Considerations + + As this document is primarily a roadmap document, it introduces no + new security considerations. The reader is referred to the relevant + sections of each of the referenced documents for information about + security considerations. + +10. References + +10.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March, 1997. + +10.2. Informative References + + [2] Cerf, V., "IAB Recommendations for the Development of Internet + Network Management Standards", RFC 1052, April 1988. + + + + + +Case, et. al. Informational [Page 22] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + [3] Rose, M. and K. McCloghrie, "Structure and Identification of + Management Information for TCP/IP-based internets", STD 16, RFC + 1155, May 1990. + + [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, + RFC 1212, March 1991. + + [5] Case, J., Fedor, M., Schoffstall, M. and Davin, J., "Simple + Network Management Protocol", STD 15, RFC 1157, May 1990. + + [6] McCloghrie, K. and M. Rose, "Management Information Base for + Network Management of TCP/IP-based internets: MIB-II", STD 17, + RFC 1213, March 1991. + + [7] Rose, M., "A Convention for Defining Traps for use with the + SNMP", RFC 1215, March 1991. + + [8] McCloghrie, K. and M. Rose, "Management Information Base for + Network Management of TCP/IP-based Internets", RFC 1156, March + 1990. + + [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure + of Management Information for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1902, January 1996. + + [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual + Conventions for Version 2 of the Simple Network Management + Protocol (SNMPv2)", RFC 1903, January 1996. + + [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Conformance Statements for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1904, January 1996. + + [12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol + Operations for Version 2 of the Simple Network Management + Protocol (SNMPv2)", RFC 1905, January 1996. + + [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport + Mappings for Version 2 of the Simple Network Management Protocol + (SNMPv2)", RFC 1906, January 1996. + + [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Management Information Base for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1907, January 1996. + + [15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Coexistence between Version 1 and Version 2 of the Internet- + Standard Network Management Framework", RFC 2576, January 1996. + + + +Case, et. al. Informational [Page 23] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + [16] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Introduction to Community-based SNMPv2", RFC 1901, January + 1996. + + [17] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Structure of Management Information + Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. + + [18] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, + RFC 2579, April 1999. + + [19] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, + M. and S. Waldbusser, "Conformance Statements for SMIv2", STD + 58, RFC 2580, April 1999. + + [20] "Official Internet Protocol Standards", http://www.rfc- + editor.org/rfcxx00.html also STD0001. + + [21] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. + Waldbusser, "Version 2 of the Protocol Operations for the Simple + Network Management Protocol (SNMP)", STD 62, RFC 3416, December + 2002. + + [22] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. + Waldbusser, "Transport Mappings for the Simple Network + Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. + + [23] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for + Describing Simple Network Management Protocol (SNMP) Management + Frameworks", STD 62, RFC 3411, December 2002. + + [24] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message + Processing and Dispatching for the Simple Network Management + Protocol (SNMP)", STD 62, RFC 3412, December 2002. + + [25] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management + Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. + + [26] Blumenthal, U. and B. Wijnen, "User-Based Security Model (USM) + for Version 3 of the Simple Network Management Protocol + (SNMPv3)", STD 62, RFC 3414, December 2002. + + [27] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access + Control Model (VACM) for the Simple Network Management Protocol + (SNMP)", STD 62, RFC 3415, December 2002. + + + + + +Case, et. al. Informational [Page 24] + +RFC 3410 Applicability Statements for SNMP December 2002 + + + [28] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence + between Version 1, Version 2, and Version 3 of the Internet- + Standard Network Management Framework", RFC 2576, March 2000. + + [29] Information processing systems - Open Systems Interconnection - + Specification of Abstract Syntax Notation One (ASN.1), + International Organization for Standardization. International + Standard 8824, (December, 1987). + + [30] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. + Waldbusser, "Management Information Base (MIB) for the Simple + Network Management Protocol (SNMP)", STD 62, RFC 3418, December + 2002. + + [31] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April + 1992. + + [32] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) + http://csrc.nist.gov/fips/fip180-1.txt (ASCII) + http://csrc.nist.gov/fips/fip180-1.ps (Postscript) + + [33] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing + for Message Authentication", RFC 2104, February 1997. + + [34] Data Encryption Standard, National Institute of Standards and + Technology. Federal Information Processing Standard (FIPS) + Publication 46-1. Supersedes FIPS Publication 46, (January, + 1977; reaffirmed January, 1988). + + [35] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October, 1996. + + + + + + + + + + + + + + + + + + + + +Case, et. al. Informational [Page 25] + +RFC 3410 Applicability Statements for SNMP December 2002 + + +11. Editors' Addresses + + Jeffrey Case + SNMP Research, Inc. + 3001 Kimberlin Heights Road + Knoxville, TN 37920-9716 + USA + + Phone: +1 865 573 1434 + EMail: case@snmp.com + + + Russ Mundy + Network Associates Laboratories + 15204 Omega Drive, Suite 300 + Rockville, MD 20850-4601 + USA + + Phone: +1 301 947 7107 + EMail: mundy@tislabs.com + + + David Partain + Ericsson + P.O. Box 1248 + SE-581 12 Linkoping + Sweden + + Phone: +46 13 28 41 44 + EMail: David.Partain@ericsson.com + + + Bob Stewart + Retired + + + + + + + + + + + + + + + + + +Case, et. al. Informational [Page 26] + +RFC 3410 Applicability Statements for SNMP December 2002 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Case, et. al. Informational [Page 27] + -- cgit v1.2.3