[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/