Network Working Group D. Harrington Internet-Draft HuaweiSymantec Intended status: Informational March 2, 2009 Expires: September 3, 2009 Survey of IETF Network Management Standards draft-ietf-opsawg-survey-management-00 Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 3, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Harrington Expires September 3, 2009 [Page 1] Internet-Draft Survey of IETF Network Management March 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document provides a survey of existing IETF standards-track network management protocols and data models. The purpose of this document is to help protocol designers, implementers, and users to select appropriate standard management protocols and data models to address relevant management needs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. SYSLOG . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. IPFIX . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. PSAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6. COPS-PR . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.7. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.8. Diameter . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.9. EPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.10. VCCV . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.11. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.12. XCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Draft and Standard Level Data Models . . . . . . . . . . . . . 10 3.1. Fault Management . . . . . . . . . . . . . . . . . . . . . 11 3.2. Configuration Management . . . . . . . . . . . . . . . . . 11 3.3. Accounting Management . . . . . . . . . . . . . . . . . . 12 3.4. Performance Management . . . . . . . . . . . . . . . . . . 12 3.5. Security Management . . . . . . . . . . . . . . . . . . . 13 4. Proposed Standard Data Models . . . . . . . . . . . . . . . . 13 4.1. Fault Management . . . . . . . . . . . . . . . . . . . . . 13 4.2. Configuration Management . . . . . . . . . . . . . . . . . 14 4.3. Accounting Management . . . . . . . . . . . . . . . . . . 15 4.4. Performance Management . . . . . . . . . . . . . . . . . . 15 4.5. Security Management . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Informative References . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21 Harrington Expires September 3, 2009 [Page 2] Internet-Draft Survey of IETF Network Management March 2009 1. Introduction This document provides a survey of existing IETF standards-track network management protocols and data models. The purpose of this document is to help protocol designers, implementers, and users to select appropriate standard management protocols and data models to address relevant management needs. Guidelines for Considering Operations and Management of New Protocols and Extensions [I-D.ietf-opsawg-operations-and-management] recommends working groups consider operations and management needs, and then select appropriate management protocols and data models. This document is designed to ease this process by surveying the IETF standards-track network management protocols and management data models available at the time of this document's publication. Section 2 discusses IETF standards-track management protocols and their uses. Section 3 discusses Draft and Full Standard data models, such as MIB modules, that have been designed to address specific sets of issues.Section 4 describes Proposed Standard management data models that have been designed to address specific sets of issues. 1.1. Terminology This document deliberately does not use the (capitalized) key words described in RFC 2119 [RFC2119]. RFC 2119 states the keywords must only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions). For example, they must not be used to try to impose a particular method on implementers where the method is not required for interoperability. This document is a survey of existing IETF network management technologies. This document does not describe requirements, so the key words from RFC2119 have no place here. CLI: Command Line Interface Data model: A mapping of the contents of an information model into a form that is specific to a particular type of data store or repository. Information model: An abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, software usage, protocol, or platform. Harrington Expires September 3, 2009 [Page 3] Internet-Draft Survey of IETF Network Management March 2009 o [DISCUSS] markers indicate a lack of consensus on what should be written. o [TODO] markers indicate the editor has a reasonable understanding of what needs to be (re-)written. Contributions of text would be welcome. o Note to RFC Editor - All [DISCUSS] or [TODO] marks should be resolved before RFC publication. If any still exist, including in the Terminology section, then please return the document to the editor for resolution. 2. Protocols This Section reviews which protocols the IETF has to offer for management and discusses for which applications they were designed and/or already successfully deployed. These are protocols that have reached Proposed Standard status or higher within the IETF. [DISCUSS: Juergen: I like to perhaps see even stronger guidelines] The Overview of the 2002 IAB Network Management Workshop [RFC3535] documented strengths and weaknesses of some IETF management protocols. In choosing existing protocol solutions to meet the management requirements, it is recommended that these strengths and weaknesses be considered. Some of the recommendations from the 2002 IAB workshop have become outdated, some have been standardized, and some are being worked on in the IETF. Some Area Directors have formed directorates composed of experienced members of the IETF and the technical community. The details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s) with the review of specifications, and serve as technical advisors when needed. At the time of this writing, the OPS Area has directorates focused on Address Management, Operations, DNS, and MIB modules. Other areas have directorates that might apply as well. Protocol designers should consider asking for help from the IETF directorates knowledgeable in available existing solutions. 2.1. SNMP SNMP is widely used for monitoring fault and performance data. Some operators use SNMP for configuration in various environments/ technologies while others find SNMP an inappropriate choice for configuration in their environments. SNMPv1 [RFC1157] is a Full Standard that the IETF has declared Historic and it is NOT RECOMMENDED due to its lack of security Harrington Expires September 3, 2009 [Page 4] Internet-Draft Survey of IETF Network Management March 2009 features. SNMPv2c [RFC1901] is an Experimental specification (not a standard of any kind) that the IETF has declared Historic and it is NOT RECOMMENDED due to its lack of security features. SNMPv3 is a Full Standard that is RECOMMENDED due to its security features, including support for authentication, encryption, timeliness and integrity checking, and fine-grained data access controls. An overview of the SNMPv3 document set is in [RFC3410]. SNMP utilizes the Management Information Base, a virtual information store of modules of managed objects. MIB module support is uneven across vendors, and even within devices. The lack of standard MIB module support for all functionality in a device forces operators to use other protocols such as a command line interface (CLI) to do configuration of some aspects of their managed devices. Many operators have found it easier to use one protocol for all configuration than to split the task across multiple protocols. SNMP is good at determining the operational state of specific functionality, but not necessarily for the complete operational state of a managed device. SNMP is good for statistics gathering for specific functionality. The wide-spread use of counters in standard MIB modules permits the interoperable comparison of statistics across devices from different vendors. Counters have been especially useful in monitoring bytes and packets going in and out over various protocol interfaces. SNMP is often used to poll a device for sysUpTime, which serves to report the time since the last reinitialization of the device, to check for operational liveness, and to detect discontinuities in some counters. SNMP traps and informs can alert an operator or an application when some aspect of a protocol fails or encounters an error condition, and the contents of a notification can be used to guide subsequent SNMP polling to gather additional information about an event. Standards exist to use SNMP over multiple network protocols, including UDP, Ethernet, Appletalk, OSI, and others.. 2.2. SYSLOG The SYSLOG protocol [I-D.ietf-syslog-protocol] allows a machine to send system log messages across networks to event message collectors. The protocol is simply designed to transport these event messages. No acknowledgement of the receipt is made. One of the fundamental tenets of the SYSLOG protocol and process is its simplicity. No stringent coordination is required between the transmitters and the receivers. Indeed, the transmission of SYSLOG messages may be started on a device without a receiver being configured, or even Harrington Expires September 3, 2009 [Page 5] Internet-Draft Survey of IETF Network Management March 2009 actually physically present. Conversely, many devices will most likely be able to receive messages without explicit configuration or definitions. This simplicity has greatly aided the acceptance and deployment of SYSLOG. Since each process, application and operating system was written somewhat independently, there has been little uniformity to the message format or content of SYSLOG messages. The IETF has developed a new Proposed Standard version of the protocol that allows the use of any number of transport protocols including reliable transports and secure transports. The IETF has also standardized the application of message security for SYSLOG messages using TLS, and has defined a mechanism to digitally sign log data to ensure its integrity as log data is moved across the network and/or copied to different data stores. The IETF has standardized a new message header format, including timestamp, hostname, application, and message ID, to improve filtering, interoperability and correlation between compliant implementations. SYSLOG message content has traditionally been unstructured natural language text. This content is human-friendly, but difficult for applications to parse and correlate across vendors, or correlate with other event reporting such as SNMP traps. The IETF syslog protocol includes structured data elements to aid application-parsing. The structured data element design allows vendors to define their own structured data elements to supplement standardized elements. The IETF has standardized MIB Textual-Conventions for facility and severity labels and codes to encourage consistency between syslog and MIB representations of these event properties. IETF working groups are encouraged to standardize structured data elements, extensible human-friendly text, and consistent facility/ severity values for SYSLOG to report events specific to their protocol. 2.3. IPFIX There are several applications such as usage-based accounting, traffic profiling, traffic engineering, intrusion detection, and QoS monitoring, that require flow-based traffic measurements. IPFIX [RFC5101] is a Proposed Standard approach for transmitting IP traffic flow information over the network from an exporting process to an information collecting process. Harrington Expires September 3, 2009 [Page 6] Internet-Draft Survey of IETF Network Management March 2009 IPFIX defines a common representation of flow data and a standard means of communicating the data over a number of transport protocols. 2.4. PSAMP Several applications require sampling packets from specific data flows, or across multiple data flows, and reporting information about the packets. Measurement-based network management is a prime example. The PSAMP standard includes support for packet sampling in IPv4, IPv6, and MPLS-based networks. PSAMP standardizes sampling, selection, metering, and reporting strategies for different purposes. To simplify the solution, the IPFIX protocol is used for exporting the reports to collector applications. [TODO: this is in IESG review to become a PS. update as needed] 2.5. NETCONF The NETCONF protocol [RFC4741] is a Proposed Standard that provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. A key aspect of NETCONF is that it allows the functionality of the management protocol to closely mirror the native command line interface of the device. This reduces implementation costs and allows timely access to new features. In addition, applications can access both the syntactic and semantic content of the device's native user interface. The contents of both the request and the response can be fully described in XML DTDs or XML schemas, or both, allowing both parties to recognize the syntax constraints imposed on the exchange. As of this writing, no standard has been developed for data content specification. 2.6. COPS-PR COPS-PR and the Structure of Policy Provisioning Information (SPPI) have been approved as Proposed Standards. COPS-PR [RFC3084] uses the Common Open Policy Service (COPS) protocol for support of policy provisioning. The COPS-PR specification is independent of the type of policy being provisioned (QoS, Security, etc.) but focuses on the Harrington Expires September 3, 2009 [Page 7] Internet-Draft Survey of IETF Network Management March 2009 mechanisms and conventions used to communicate provisioned information between policy-decision-points (PDPs) and policy enforcement points (PEPs). COPS-PR does not make any assumptions about the policy data model being communicated, but describes the message formats and objects that carry the modeled policy data. Policy data is modeled using Policy Information Base modules (PIB modules). COPS-PR has not had wide deployment, and operators have stated that its use of binary encoding (BER) for management data makes it difficult to develop automated scripts for simple configuration management tasks in most text-based scripting languages. In an IAB Workshop on Network Management [RFC3535], the consensus of operators and protocol developers indicated a lack of interest in PIB modules for use with COPS-PR. As a result, the IESG has not approved any policy models (PIB modules) as an IETF standard, and the use of COPS-PR is not recommended. 2.7. RADIUS RADIUS [RFC2865], the remote Authentication Dial In User Service, is a Draft Standard that describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. This protocol is widely implemented and used. RADIUS is widely used in environments, such as enterprise networks, where a single administrative authority manages the network, and protects the privacy of user information. 2.8. Diameter DIAMETER [RFC3588] is a Proposed Standard that provides an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. DIAMETER is also intended to work in local Authentication, Authorization, Accounting situations and in roaming situations. Diameter is designed to resolve a number of known problems with RADIUS. Diameter supports server failover, transmission-level security, reliable transport over TCP, agents for proxy and redirect and relay, server-initiated messages, auditability, capability negotiation, peer discovery and configuration, and roaming support. Diameter also provides a larger attribute space than RADIUS. Harrington Expires September 3, 2009 [Page 8] Internet-Draft Survey of IETF Network Management March 2009 Diameter features make it especially appropriate for environments where the providers of services are in different administrative domains than the maintainer (protector) of confidential user information. 2.9. EPP The Extensible Provision Protocol [RFC4930] is a Draft Standard that describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. EPP permits multiple service providers to perform object provisioning operations using a shared central object repository, and addresses the requirements for a generic registry registrar protocol. 2.10. VCCV VCCV is a Proposed Standard protocol that provides a control channel associated with a Pseudowire. It is used for operations and management functions such as connectivity verification over the control channel. VCCV applies to all supported access circuit and transport types currently defined for Pseudowires. 2.11. ACAP The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted. ACAP's primary purpose is to allow users access to their configuration data from multiple network-connected computers. Users can then sit down in front of any network-connected computer, run any ACAP-enabled application and have access to their own configuration data. Because it is hoped that many applications will become ACAP- enabled, client simplicity was preferred to server or protocol simplicity whenever reasonable. 2.12. XCAP XCAP [RFC4825] is a Proposed Standard protocol that allows a client to read, write, and modify application configuration data stored in XML format on a server. Harrington Expires September 3, 2009 [Page 9] Internet-Draft Survey of IETF Network Management March 2009 XCAP is a protocol that can be used to manipulate per-user data. XCAP is a set of conventions for mapping XML documents and document components into HTTP URIs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources. Because of this structure, normal HTTP primitives can be used to manipulate the data. XCAP is meant to support the configuration needs for a multiplicity of applications, rather than just a single one. XCAP was not designed as a general purpose XML search protocol, XML database update protocol, nor a general purpose, XML-based configuration protocol for network elements. 3. Draft and Standard Level Data Models [DISCUSS: JS: The weakest part of the document is IMHO section 6. It is not clear to me what David's intention were here; sometimes he gives general advise while at other places he kind of surveys data models and such things. I am also not sure all the stuff listed there is actually useful to list; for example, has anybody ever deployed the technology which came out of the snmpconf working group? So we need to be more selective and probably also organize our pointers based on the protocol layer people are working on (transmission specific MIB modules are kind of widely used, people managing application servers usually do not use much of SNMP; the IETF application management MIBs we have produced have not gained large deployments as far as I can tell). ] [DISCUSS: David: Some MIB modules may not be deployed because few people know about them and have never tried them. Others may have been tried and been found to be inadequate. We have very little feedback concerning which ones are useful and which are widely deployed, which have been found useful by operators, and which have been found to be junk. ;-) I hesitate to make recommendations that people should avoid a MIB module unless there is real evidence that it is unsuitable for its designed task. Even then, I hesitate because maybe the MIB would be found useful in a different environment that is just emerging. Maybe the IETF needs to perform a de-crufting operation for data models, similar to that done for protocols a few years ago. But I think that would require feedback from LOTS of operators and application developers - and these tend to be scarce in the IETF. ] The purpose of this section is to inform protocol designers about solutions for which information or data models have been standardized in the IETF, so they can reuse existing solutions or apply the information model to new solutions. Harrington Expires September 3, 2009 [Page 10] Internet-Draft Survey of IETF Network Management March 2009 This section discusses management data models that have reached at least Draft Standard status in the IETF. IETF specifications must have "multiple, independent, and interoperable implementations" before they can be advanced to Draft Standard status. Management data models have a slightly different interpretation for interoperability. This is discussed in detail in BCP 27: Advancement of MIB specifications on the IETF Standards Track [RFC2438] discusses special considerations about the advancement process for management data models. Most IETF management data models never advance beyond Proposed Standard. T his section will focus on those data models that have reached at least Draft status. This is supplemented by a chapter that lists additional data models that are Proposed Standard status. [TODO] discuss specific MIB modules, SDEs, XML schemas that are designed to solve generic problems. This might cover things like Textual Conventions, RFC3415 Target tables, SYSLOG SDEs defined in -protocol-, SYSLOG -sign-, IPFIX IEs, etc. 3.1. Fault Management RFC 3418 [RFC3418], part of STD 62 SNMP, contains objects in the system group that are often polled to determine if a device is still operating, and sysUpTime can be used to detect if a system has rebooted, and counters have been reinitialized. RFC3413 [RFC3413], part of STD 62 SNMP, includes objects designed for managing notifications, including tables for addressing, retry parameters, security, lists of targets for notifications, and user customization filters. An RMON monitor [RFC2819] can be configured to recognize conditions, most notably error conditions, and continuously to check for them. When one of these conditions occurs, the event may be logged, and management stations may be notified in a number of ways. See further discussion of RMON under Performance Management. 3.2. Configuration Management It is expected that standard XML-based data models will be developed for use with NETCONF, and working groups might identify specific NETCONF data models that would be applicable to the new protocol. At the time of this writing, no such standard data models exist. For monitoring network configuration, such as physical and logical network topologies, existing MIB modules already exist that provide some of the desired capabilities. New MIB modules might be developed for the target functionality to allow operators to monitor and modify Harrington Expires September 3, 2009 [Page 11] Internet-Draft Survey of IETF Network Management March 2009 the operational parameters, such as timer granularity, event reporting thresholds, target addresses, and so on. RFC 3418 [RFC3418], part of STD 62 SNMPv3, contains objects in the system group that are often polled to determine if a device is still operating, and sysUpTime can be used to detect if a system has rebooted and caused potential discontinuity in counters. Other objects in the system MIB are useful for identifying the type of device, the location of the device, the person responsible for the device, etc. RFC3413 [RFC3413], part of STD 62 SNMPv3, includes objects designed for configuring notification destinations, and for configuring proxy- forwarding SNMP agents, which can be used to forward messages through firewalls and NAT devices. RFC2863 [RFC2863], the Interfaces MIB is used for managing Network Interfaces. This includes the 'interfaces' group of MIB-II and discusses the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. 3.3. Accounting Management TODO: RADIUS Accounting MIBs are PS; are there any DS data models for accounting? ] 3.4. Performance Management MIB modules typically contain counters to determine the frequency and rate of an occurrence. RFC2819, STD 59 RMON, defines objects for managing remote network monitoring devices. An organization may employ many remote management probes, one per network segment, to manage its internet. These devices may be used for a network management service provider to access a client network, often geographically remote. Most of the objects in the RMON MIB module are suitable for the management of any type of network, and there are some which are specific to managing Ethernet networks. RMON allows a probe to be configured to perform diagnostics and to collect statistics continuously, even when communication with the management station may not be possible or efficient. The alarm group periodically takes statistical samples from variables in the probe and compares them to previously configured thresholds. If the monitored variable crosses a threshold, an event is generated. Harrington Expires September 3, 2009 [Page 12] Internet-Draft Survey of IETF Network Management March 2009 The RMON host group discovers hosts on the network by keeping a list of source and destination MAC Addresses seen in good packets promiscuously received from the network, and contains statistics associated with each host. The hostTopN group is used to prepare reports that describe the hosts that top a list ordered by one of their statistics. The available statistics are samples of one of their base statistics over an interval specified by the management station. Thus, these statistics are rate based. The management station also selects how many such hosts are reported. The RMON matrix group stores statistics for conversations between sets of two addresses. The filter group allows packets to be matched by a filter equation. These matched packets form a data stream that may be captured or may generate events. The Packet Capture group allows packets to be captured after they flow through a channel. The event group controls the generation and notification of events from this device. The RMON-2 MIB [RFC4502] extends RMON by providing RMON analysis up to the application layer. The SMON MIB [RFC2613] extends RMON by providing RMON analysis for switched networks. 3.5. Security Management Working groups should consider existing data models that would be relevant to monitoring and managing the security of the new protocol. The IETF has no standard data models for managing security protocols such as TLS and SSH. 4. Proposed Standard Data Models 4.1. Fault Management The IETF SYSLOG protocol [I-D.ietf-syslog-protocol] is a Proposed Standard that includes a mechanism for defining structured data elements (SDEs). The SYSLOG protocol document defines an initial set of SDEs that relate to content time quality, content origin, and meta-information about the message, such as language. Proprietary SDEs can be used to supplement the IETF-defined SDEs. DISMAN-EVENT-MIB in RFC 2981 and DISMAN-EXPRESSION-MIB in RFC 2982 provide a superset of the capabilities of the RMON alarm and event groups. These modules provide mechanisms for thresholding and reporting anomalous events to management applications. The ALARM MIB in RFC 3877 and the Alarm Reporting Control MIB in RFC 3878 specify mechanisms for expressing state transition models for Harrington Expires September 3, 2009 [Page 13] Internet-Draft Survey of IETF Network Management March 2009 persistent problem states. There is also a mechanism specified to correlate a notification with subsequent state transition notifications about the same entity/object. Other MIB modules that may be applied to Fault Management include: NOTIFICATION-LOG-MIB in RFC 3014 ENTITY-STATE-MIB in RFC 4268 ENTITY-SENSOR-MIB in RFC 4268 4.2. Configuration Management The Entity MIB [RFC4133] is used for managing multiple logical and physical entities managed by a single SNMP agent. This module provides a useful mechanism for identifying the entities comprising a system. There are also event notifications defined for configuration changes that may be useful to management applications. RFC3159 [RFC3159] discusses the Structure of Policy Provisioning Information, an extension to the SMI standard for purposes of policy- based provisioning, for use with the COPS-PR protocol defined in RFC3084 [RFC3084]. RFC3317 [RFC3317] defines a DiffServ QoS PIB. At the time of this writing, there are no standards-track PIBs. During the IAB Workshop on Network Management, the workshop had rough consensus from the protocol developers that the IETF should not spend resources on SPPI PIB definitions, and the operators had rough consensus that they do not care about SPPI PIBs. The Policy Based Management MIB [RFC4011] defines objects that enable policy-based monitoring and management of SNMP infrastructures, a scripting language, and a script execution environment. RFC3165 [RFC3165] supports the use of user-written scripts to delegate management functionality. Proposed Standard RFC4011 [RFC4011] defines objects that enable policy-based monitoring using SNMP, using a scripting language, and a script execution environment. Few vendors have implemented MIB modules that support scripting. Some vendors consider running user-developed scripts within the managed device as a violation of support agreements. [TODO] Informational RFC3317 defines a DiffServ QoS PIB, and Informational RFC3571 defines policy classes for monitoring and reporting policy usage feedback, as well as policy classes for Harrington Expires September 3, 2009 [Page 14] Internet-Draft Survey of IETF Network Management March 2009 controlling reporting intervals, suspension, resumption and solicitation. At the time of this writing, there are no standards- track PIBs During the IAB Workshop on Network Management, the workshop had rough consensus from the protocol developers that the IETF should not spend resources on SPPI PIB definitions, and the operators had rough consensus that they do not care about SPPI PIBs. 4.3. Accounting Management DIAMETER [RFC3588] accounting might be collected for services, and working groups might document some of the RADIUS/DIAMETER attributes that could be used. [TODO: what data models?] RADIUS Authentication Client MIB [RFC4668] and RADIUS Authentication Server MIB [RFC4669] allow the gathering of accounting data. [TODO] The IPFIX protocol [RFC5101] can collect information related to IP flows, and existing Information Elements (IEs) may be appropriate to report flows of the new protocol. New IPFIX Information Elements might be useful for collecting flow information useful only in consideration of the new protocol. As of this writing, no IEs have reached Proposed Standard status yet, but a base set of IEs has been submitted to IESG for advancement. These include IEs for Identifying the scope of reporting, Metering and Export Process configuration, IP and Transport and Sub-IP header fields, Packet and Flow properties, timestamps, and counters. 4.4. Performance Management RAQMON [RFC4710] describes Real-Time Application Quality of Service Monitoring. The IPPM WG has defined metrics for accurately measuring and reporting the quality, performance, and reliability of Internet data delivery services. The metrics include connectivity, one-way delay and loss, round-trip delay and loss, delay variation, loss patterns, packet reordering, bulk transport capacity, and link bandwidth capacity. [TODO: detail the RFCs - 4737, 3393, 2681, 2680, 2679, 2678] SIP Package for Voice Quality Reporting [I-D.ietf-sipping-rtcp-summary] defines a SIP event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. 4.5. Security Management Harrington Expires September 3, 2009 [Page 15] Internet-Draft Survey of IETF Network Management March 2009 5. IANA Considerations This document does not introduce any new codepoints or name spaces for registration with IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations This document introduces no new security concerns. 7. Acknowledgements 8. Informative References [I-D.ietf-opsawg-operations-and-management] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols", draft-ietf- opsawg-operations-and- management-05 (work in progress), October 2008. [I-D.ietf-sipping-rtcp-summary] Clark, A., Pendleton, A., Johnston, A., and H. Sinnreich, "Session Initiation Protocol Package for Voice Quality Reporting Event", draft-ietf- sipping-rtcp-summary-05 (work in progress), October 2008. [I-D.ietf-syslog-protocol] Gerhards, R., "The syslog Protocol", draft- ietf-syslog-protocol-23 (work in progress), September 2007. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [RFC1901] Case, J., McCloghrie, Harrington Expires September 3, 2009 [Page 16] Internet-Draft Survey of IETF Network Management March 2009 K., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2438] O'Dell, M., Alvestrand, H., Wijnen, B., and S. Bradner, "Advancement of MIB specifications on the IETF Standards Track", BCP 27, RFC 2438, October 1998. [RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, June 1999. [RFC2819] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3084] Chan, K., Seligson, J., Harrington Expires September 3, 2009 [Page 17] Internet-Draft Survey of IETF Network Management March 2009 Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001. [RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", RFC 3165, August 2001. [RFC3317] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, "Differentiated Services Quality of Service Policy Information Base", RFC 3317, March 2003. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Harrington Expires September 3, 2009 [Page 18] Internet-Draft Survey of IETF Network Management March 2009 Applications", STD 62, RFC 3413, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003. [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003. [RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003. [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and W. Weiss, "Information Harrington Expires September 3, 2009 [Page 19] Internet-Draft Survey of IETF Network Management March 2009 Model for Describing Network Device QoS Datapath Mechanisms", RFC 3670, January 2004. [RFC3805] Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2", RFC 3805, June 2004. [RFC4011] Waldbusser, S., Saperia, J., and T. Hongal, "Policy Based Management MIB", RFC 4011, March 2005. [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005. [RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006. [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006. [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006. [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON) Framework", RFC 4710, October 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. Harrington Expires September 3, 2009 [Page 20] Internet-Draft Survey of IETF Network Management March 2009 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. [RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 4930, May 2007. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. Appendix A. Open Issues [TODO: need to verify all citations have references (in xref format)] Organize data models by layer? Appendix B. Change Log Changes from being part of opsawg-operations-and-management to being opsawg-survey-00 Author's Address David Harrington HuaweiSymantec 1700 Alma Dr, Suite 100 Plano, TX 75075 USA Phone: +1 603 436 8634 Fax: EMail: dharrington@huawei.com URI: Harrington Expires September 3, 2009 [Page 21]