[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                           M. Ersue
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                          October 25, 2010
Expires: April 28, 2011

 An Overview of the IETF Network Management Framework and its Standards


   This document gives an overview of the IETF standard management
   framework and summarizes existing and ongoing development of IETF
   standards-track network management protocols and data models.  The
   purpose of this document is on the one hand to help system developers
   and users to select appropriate standard management protocols and
   data models to address relevant management needs.  On the other hand
   the document can be used as an overview and guideline by other SDOs
   or bodies planning to use IETF management technologies and data

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 28, 2011.

Copyright Notice

   Copyright (c) 2010 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
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Ersue                    Expires April 28, 2011                 [Page 1]

Internet-Draft          IETF Management Framework           October 2010

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  IETF Standard Management Framework . . . . . . . . . . . . . .  6
     2.1.  Simple Network Management Protocol (SNMP) and its
           Architectural Principles . . . . . . . . . . . . . . . . .  6
     2.2.  SNMP and its Versions  . . . . . . . . . . . . . . . . . .  7
     2.3.  SNMP Security  . . . . . . . . . . . . . . . . . . . . . .  8
       2.3.1.  Security Requirements on the SNMP Management
               Framework  . . . . . . . . . . . . . . . . . . . . . .  8
       2.3.2.  User-Based Security Model (USM)  . . . . . . . . . . . 10
       2.3.3.  View-Based Access Control Model (VACM) . . . . . . . . 11
       2.3.4.  SNMP Transport Subsystem and Transport Security
               Model  . . . . . . . . . . . . . . . . . . . . . . . . 11
       2.3.5.  RADIUS Authentication and Authorization with SNMP
               Transport Models . . . . . . . . . . . . . . . . . . . 13
     2.4.  Supplementary Components of the IETF Management
           Framework  . . . . . . . . . . . . . . . . . . . . . . . . 13
       2.4.1.  NETCONF  . . . . . . . . . . . . . . . . . . . . . . . 13
       2.4.2.  SYSLOG . . . . . . . . . . . . . . . . . . . . . . . . 17
       2.4.3.  IPFIX/PSAMP  . . . . . . . . . . . . . . . . . . . . . 18
   3.  Management Protocols and Mechanisms with specific Focus  . . . 20
     3.1.  IP Address Management with DHCP  . . . . . . . . . . . . . 21
     3.2.  IPv6 Network Operations  . . . . . . . . . . . . . . . . . 22
     3.3.  SNMP Agent Extensibility (AgentX) Protocol . . . . . . . . 22
     3.4.  Radius . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     3.5.  Diameter . . . . . . . . . . . . . . . . . . . . . . . . . 24
     3.6.  CAPWAP . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     3.7.  Access Node Control Protocol . . . . . . . . . . . . . . . 26
     3.8.  Ad-Hoc Network Autoconfiguration . . . . . . . . . . . . . 26
     3.9.  Policy-based Management  . . . . . . . . . . . . . . . . . 27
       3.9.1.  IETF Policy Framework  . . . . . . . . . . . . . . . . 27
       3.9.2.  COPS-PR  . . . . . . . . . . . . . . . . . . . . . . . 27
     3.10. Network Performance Management . . . . . . . . . . . . . . 28
       3.10.1. IP Performance Metrics (IPPM)  . . . . . . . . . . . . 28
       3.10.2. Real-time Flow Measurement (RTFM)  . . . . . . . . . . 29
     3.11. Application Management Protocols . . . . . . . . . . . . . 30
       3.11.1. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . 30
       3.11.2. XCAP . . . . . . . . . . . . . . . . . . . . . . . . . 30
       3.11.3. EPP  . . . . . . . . . . . . . . . . . . . . . . . . . 31
   4.  Proposed, Draft and Standard Level Data Models . . . . . . . . 31
     4.1.  Fault Management . . . . . . . . . . . . . . . . . . . . . 31

Ersue                    Expires April 28, 2011                 [Page 2]

Internet-Draft          IETF Management Framework           October 2010

     4.2.  Configuration Management . . . . . . . . . . . . . . . . . 33
     4.3.  Accounting Management  . . . . . . . . . . . . . . . . . . 34
     4.4.  Performance Management . . . . . . . . . . . . . . . . . . 34
     4.5.  Security Management  . . . . . . . . . . . . . . . . . . . 36
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 37
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 37
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 37
   Appendix A.  New Work related to IETF Management Framework . . . . 53
     A.1.  Energy Management (eman) . . . . . . . . . . . . . . . . . 53
   Appendix B.  Open issues . . . . . . . . . . . . . . . . . . . . . 55

Ersue                    Expires April 28, 2011                 [Page 3]

Internet-Draft          IETF Management Framework           October 2010

1.  Introduction

   This document gives an overview of the IETF standard management
   framework and summarizes existing and ongoing development of IETF
   standards-track network management protocols and data models.  The
   purpose of this document is on the one hand to help system developers
   and users to select appropriate standard management protocols and
   data models to address relevant management needs.  On the other hand
   the document can be used as an overview and guideline by other SDOs
   or bodies planning to use IETF management technologies and data
   models.  The document can be also used to initiate a discussion
   between the bodies with the goal to gather new management
   requirements and to detect possible gaps.

   [I-D.baker-ietf-core] identifies the key protocols of the Internet
   Protocol Suite for use in the Smart Grid.  The target audience is
   those people seeking guidance on how to construct an appropriate
   Internet Protocol Suite profile for the Smart Grid.  In analogy to
   [I-D.baker-ietf-core] this document gives an overview on the IETF
   management framework and technologies and will show usage scenarios
   addressing the Smart Grid environment.

   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 at the IETF.

   Guidelines for Considering Operations and Management of New Protocols
   and Extensions [RFC5706] recommends working groups to consider
   operations and management needs, and then select appropriate
   management protocols and data models.  This document can be used to
   ease surveying the IETF standards-track network management protocols
   and management data models.

   Section 2 gives an overview of the IETF standard management framework
   with a special focus on Simple Network Management Protocol (SNMP) and
   supplementary components of the IETF management framework such as
   NETCONF, SYSLOG and IPFIX.  Section 3 discusses IETF management
   protocols and mechanisms with a specific focus and their use cases.
   Section 4 discusses Proposed, Draft and Standard Level data models,
   such as MIBs designed to address specific set of issues and maps them
   to different management tasks.

   IETF specifications must have "multiple, independent, and
   interoperable implementations" before they can be advanced to Draft

Ersue                    Expires April 28, 2011                 [Page 4]

Internet-Draft          IETF Management Framework           October 2010

   Standard status.  An Internet Standard, which may simply be referred
   to as a Standard, is characterized by a high degree of technical
   maturity and by a generally held belief that the specified protocol
   or service provides significant benefit to the Internet community

   This document mainly refers to Proposed, Draft or Full Standard
   documents at IETF.  As far as it is valuable standard track I-Ds just
   before publication and Best Current Practice (BCP) documents are
   referenced.  In exceptional cases and if the document provides
   substantial guideline for standard usage Informational RFCs are

   Note: This document uses the expired draft [I-D.ietf-opsawg-survey-
   management] edited by Dave Harrington as a starting point and
   enhances it with a special focus on the description of the IETF
   Standard Management Framework and SNMP security as well as aims to
   extend it with explanation of the standards, their usage scenarios
   and new development at IETF.

   Note: The document does not cover OAM technologies on the data-path,
   e.g.  OAM of tunnels, MPLS-TP OAM, Pseudowire, etc.  [I-D.ietf-
   opsawg-oam-overview] gives an overview on the OAM toolset for
   detecting and reporting connection failures or measurement of
   connection performance parameters.  [I-D.ietf-mpls-tp-oam-framework]
   describes the OAM Framework for MPLS-based Transport Networks.

1.1.  Terminology

   This document does not describe standard requirements.  Therefore key
   words from RFC2119 are not used in the document.

   o  CLI: Command Line Interface

   o  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

   o  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.

   NOTE: To be filled out!

Ersue                    Expires April 28, 2011                 [Page 5]

Internet-Draft          IETF Management Framework           October 2010

2.  IETF Standard Management Framework

2.1.  Simple Network Management Protocol (SNMP) and its Architectural

   As described in [RFC3410] the current version of the Internet
   Standard Management Framework, the SNMPv3 Framework, builds upon both
   the original SNMPv1 and SNMPv2 Management Framework.  The basic
   structure and components for the Internet Standard Management
   Framework did not change between its versions and comprises following

   o  managed nodes, each with an SNMP entity providing remote access to
      management instrumentation (the agent),

   o  at least one SNMP entity with management applications (the
      manager), and

   o  a management protocol used to convey management information
      between the SNMP entities, and management information.

   During its evolution, the fundamental architecture of the Internet
   Standard Management Framework remained consistent based on a modular
   architecture, which consists of:

   o  a generic protocol definition independent of the data it is
      carrying, and

   o  a protocol-independent data definition language,

   o  a virtual database containing data sets of management information
      definitions (the Management Information Base, or MIB), and

   o  security and administration.

   As such following standards build up the basis of the current IETF
   Standard Management Framework:

   o  SNMPv3 protocol,

   o  the modeling language SMIv2, and

   o  MIBs for different management issues.

   The SNMPv3 Framework extends the architectural principles of SNMPv1
   and SNMPv2 by:

Ersue                    Expires April 28, 2011                 [Page 6]

Internet-Draft          IETF Management Framework           October 2010

   o  building on these three basic architectural components, in some
      cases incorporating them from the SNMPv2 Framework by reference,

   o  by using the same layering principles in the definition of new
      capabilities in the security and administration portion of the

2.2.  SNMP and its Versions

   SNMP is based on three conceptual entities: Manager, Agent, and the
   Management Information Base (MIB).  In any configuration, at least
   one manager node runs SNMP management software.  Network devices such
   as bridges, routers, and servers are equipped with an agent.  The
   agent is responsible for providing access to a local MIB of objects
   that reflects the resources and activity at its node.  Following the
   manager-agent paradigm, an agent can generate notifications and send
   them as unsolicited messages to the management application.

   To enhance this basic functionality, a new version of SNMP has been
   introduced in 1993.  SNMPv2 added bulk transfer capability and other
   functional extensions like an administrative model for access
   control, security extensions, and Manager-to-Manager communication.
   SNMPv2 entities can have a dual role as manager and agent.  However,
   neither SNMPv1 nor SNMPv2 offers sufficient security features.  To
   address the security deficiencies of SNMPv1/v2, SNMPv3 was issued as
   a set of Proposed Standards in January 1998 (see [STD62]).

   The BCP document [BCP0074] "Coexistence between Version 1, Version 2,
   and Version 3 of the Internet-standard Network Management Framework"
   gives an overview of the relevant standard documents on the three
   SNMP versions.  The BCP document furthermore describes how to convert
   MIB modules from SMIv1 format to SMIv2 format and how to translate
   notification parameters as well as describes the mapping between the
   message processing and security models (see [RFC3584]).

   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
   configurations rather than to split the task across multiple

   SNMP is good at determining the operational state of specific
   functionality, but not necessarily for the complete operational state

Ersue                    Expires April 28, 2011                 [Page 7]

Internet-Draft          IETF Management Framework           October 2010

   of a managed device.  SNMP is also good for statistics gathering for
   specific functionality.  The widespread 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.

   SNMP is widely used for monitoring fault and performance data.  Some
   operators use SNMP for configuration in various environments, while
   others find SNMP an inappropriate choice for configuration in their
   environments.  During the IAB Network Management Workshop the
   attendees expected that the so-called evolutionary approaches would
   fail and more focus should be put on new approaches, such as XML-
   based configuration management.

   SNMPv1 [RFC1157] is a Full Standard that the IETF has declared
   Historic and it is not recommended due to its lack of security
   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 [STD62] 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].

   Standards exist to use SNMP over multiple network protocols,
   including TCP, UDP, Ethernet, OSI, and others.

2.3.  SNMP Security

2.3.1.  Security Requirements on the SNMP Management Framework

   Several of the classical threats to network protocols are applicable
   to management problem space and therefore applicable to any security
   model used in an SNMP Management Framework.  This section lists
   principal threats, secondary threats, and threats which are of lesser
   importance as defined in [RFC3411].

   The principal threats against which SNMP Security Models should

Ersue                    Expires April 28, 2011                 [Page 8]

Internet-Draft          IETF Management Framework           October 2010

   provide protection are:

   Modification of Information:
      Information might be altered by an unauthorized entity, e.g. in-
      transit SNMP messages can be generated to effect unauthorized
      management operations, including falsifying the value of an

      The masquerade threat is the danger that management operations not
      authorized for some principal may be attempted by assuming the
      identity of another principal that has the appropriate

   Secondary threats against which any Security Model used within this
   architecture should provide protection are:

   Message Stream Modification:
      The SNMP protocol is typically based upon a connectionless
      transport service which may operate over any subnetwork service.
      The re-ordering, delay or replay of messages can and does occur
      through the natural operation of many such subnetwork services.
      The message stream modification threat is the danger that messages
      may be maliciously re-ordered, delayed or replayed to an extent
      which is greater than what can occur through the natural operation
      of a subnetwork service, in order to effect unauthorized
      management operations.

      The disclosure threat is the danger of eavesdropping on the
      exchanges between SNMP engines.  Protecting against this threat
      may be required as a matter of local policy.

   There are at least two threats against which a Security Model within
   this architecture need not protect, since they are deemed to be of
   lesser importance in this context:

   Denial of Service:
      A Security Model need not attempt to address the broad range of
      attacks by which service on behalf of authorized users is denied.
      Indeed, such denial-of-service attacks are in many cases
      indistinguishable from the type of network failures with which any
      viable management protocol must cope as a matter of course.

   Traffic Analysis:
      A Security Model need not attempt to address traffic analysis
      attacks.  Many traffic patterns are predictable - entities may be
      managed on a regular basis by a relatively small number of

Ersue                    Expires April 28, 2011                 [Page 9]

Internet-Draft          IETF Management Framework           October 2010

      management stations - and therefore there is no significant
      advantage afforded by protecting against traffic analysis.

2.3.2.  User-Based Security Model (USM)

   The User Security Model (USM) provides authentication and privacy
   services for SNMP (RFC3414).  Specifically, USM is designed to secure
   against the following principal threats:

   o  Modification of Information: Alteration of an in-transit message
      generated by an authorized entity in such a way as to effect
      unauthorized management operations, including the setting of
      object values.

   o  Masquerade: Management operations that are not authorized for some
      entity may be attempted by that entity by assuming the identity of
      an authorized entity.

   o  Message Stream Modification: SNMP messages (transported over a
      connectionless protocol) could be reordered, delayed, or replayed
      (duplicated) to affect unauthorized management operations.

   o  Disclosure: An entity could observe exchanges between a manager
      and an agent and thereby learn the values of managed objects, and
      learn of notification events.

   USM does not secure against Denial of Service and attacks based on
   Traffic Analysis.

   The security services the SNMP Security Model supports are:

   o  Data Integrity is the provision of the property that data has not
      been altered or destroyed in an unauthorized manner, nor have data
      sequences been altered to an extent greater than can occur non-

   o  Data Origin Authentication is the provision of the property that
      the claimed identity of the user on whose behalf received data was
      originated is supported.

   o  Data Confidentiality is the provision of the property that
      information is not made available or disclosed to unauthorized
      individuals, entities, or processes.

   o  Message timeliness and limited replay protection is the provision
      of the property that a message whose generation time is outside of
      a specified time window is not accepted.

Ersue                    Expires April 28, 2011                [Page 10]

Internet-Draft          IETF Management Framework           October 2010

   See [RFC3414] in [STD62] for a detailed description of SNMPv3 USM.

2.3.3.  View-Based Access Control Model (VACM)

   The View-Based Access Control facility of SNMP enables the
   configuration of agents to provide different levels of access to the
   agent's MIB.  An agent entity can restrict access to its MIB for a
   particular manager entity in two ways:

   o  It can restrict access to a certain portion of its MIB, e.g., an
      agent may restrict most manager principals to viewing performance-
      related statistics and allow only a single designated manager
      principal to view and update configuration parameters.

   o  The agent can limit the operations that a principal can use on
      that portion of the MIB.  E.g., a particular manager principal
      could be limited to read-only access to a portion of an agent's

   The access control policy to be used by an agent must be pre-
   configured for each manager.  The policy is based on a table that
   details the access privileges of the various authorized managers.

   VACM defines five elements that make up the Access Control Model:
   groups, security level, contexts, MIB views, and access policy.

   See [RFC3415] in [STD62] for a detailed description of SNMPv3 VACM.

2.3.4.  SNMP Transport Subsystem and Transport Security Model

   The User-based Security Model (USM) was designed to be independent of
   other existing security infrastructures to ensure it could function
   when third-party authentication services were not available.  As a
   result, USM utilizes a separate user and key-management
   infrastructure.  Operators have reported that having to deploy
   another user and key-management infrastructure in order to use SNMPv3
   is costly and hinders the deployment of SNMPv3.

   SNMP Transport Subsystem [RFC5590] extends the existing SNMP
   framework and transport model and enables the use of transport
   protocols to provide message security unifying the administrative
   security management for SNMP, and other management interfaces.

   Transport Models are tied into the SNMP framework through the
   Transport Subsystem.  The Transport Security Model has been designed
   to work on top of lower-layer, secure Transport Models.  The
   Transport Security Model [RFC5591] and the Secure Shell Transport
   Model [RFC5592] utilize the Transport Subsystem.

Ersue                    Expires April 28, 2011                [Page 11]

Internet-Draft          IETF Management Framework           October 2010

   The Transport Security Model is an alternative to the existing SNMPv1
   Security Model [RFC3584], the SNMPv2c Security Model [RFC3584], and
   the User-based Security Model [RFC3414].  The Secure Shell Transport
   Model defines furthermore an alternative to existing standard
   transport mappings described in [RFC3417] such as SNMP over OSI, SNMP
   over IPX and SNMP over UDP.  SNMP over UDP has been so far the most
   commonly used SNMP transport binding.  The Experimental RFC [RFC3430]
   defines a transport mapping with TCP.

   The new SNMP Transport Subsystem modifies the Abstract Service
   Interfaces to pass transport-specific security parameters to other
   subsystems.  This includes transport-specific security parameters
   that are translated into the transport-independent parameters such as
   securityName and securityLevel.

   The SNMP Transport Subsystem utilizes one or more lower-layer
   security mechanisms to provide message-oriented security services.
   These include authentication of the sender, encryption, timeliness
   checking, and data integrity checking.

   A secure Transport Model establishes an authenticated and possibly
   encrypted link between the Transport Models of two SNMP engines.
   After a transport-layer tunnel is established, SNMP messages can be
   sent through this tunnel from one SNMP engine to the other.  The new
   Transport Model supports sending multiple SNMP messages through the
   same tunnel to amortize the costs of establishing a security

   The Transport Model on top of a secure transport protocol performs
   security functions within the Transport Subsystem, including the
   translation of transport-security parameters to/from Security-Model-
   independent parameters.  To accommodate this, an implementation-
   specific cache of transport-specific information is introduced and
   the data flows on this path are extended to pass Security-Model-
   independent values.  For this purpose, the Transport Subsystem
   extends SNMPv3 Abstract Service Interfaces (ASI).  New Security
   Models can be defined using the modified ASIs and the transport-
   information cache.

   [RFC5592] introduces a Transport Model (Secure Shell Transport
   Model), which makes use of the commonly deployed Secure Shell
   security infrastructure establishing a channel between itself and the
   SSH Transport Model of another SNMP engine.

   Different IETF standards use security layers at the transport or
   application layer to address security threads (e.g.  TLS [RFC5246],
   Simple Authentication and Security Layer (SASL) [RFC4422], and SSH
   [RFC4251]).  Different management interfaces, e.g.  CLI, SYSLOG

Ersue                    Expires April 28, 2011                [Page 12]

Internet-Draft          IETF Management Framework           October 2010

   [RFC5424] and NETCONF [RFC4741], use a secure transport layer to
   provide secure information and message exchange to build management

   Detailed description of the Transport Subsystem for SNMP and
   Transport Security Model for SNMP can be found in [RFC5590] and
   [RFC5591].  Secure Shell Transport Model for SNMP is specified in
   [RFC5592] and Transport Layer Security (TLS) Transport Model for SNMP
   is described in [RFC5953].

2.3.5.  RADIUS Authentication and Authorization with SNMP Transport

   [RFC5608] describes the use of a RADIUS (Remote Authentication
   Dial-In User Service) authentication and authorization service by
   SNMP secure Transport Models for authentication of users and
   authorization of secure transport session creation.

   The secure transport protocols selected for use with RADIUS and SNMP
   need to support user authentication methods that are compatible with
   those that exist in RADIUS.  Transport Models rely upon the
   underlying secure transport for user authentication services.  The
   SSH protocol provides a secure transport channel with support for
   channel authentication via local accounts and integration with
   various external authentication and authorization services such as
   RADIUS, Kerberos, etc.  SSH Server integration with RADIUS
   traditionally uses the username and password mechanism.

   Service authorization and access control authorization are the use
   cases for RADIUS support of management access via SNMP.  User
   authentication needs to be done prior to each of these use cases.
   Service authorization allows a RADIUS server to authorize an
   authenticated principal to use SNMP, optionally over a secure
   transport, typically using an SNMP Transport Model (see [RFC5608]).

   Access control authorization, i.e. how RADIUS attributes and messages
   are applied to the specific application area of SNMP Access Control
   Models, and VACM in particular is currently being specified in the
   ISMS (Integrated Security Model for SNMP) WG [I-D.ietf-isms-radius-

2.4.  Supplementary Components of the IETF Management Framework

2.4.1.  NETCONF

   SNMP works well for device monitoring and with its stateless nature
   SNMP is also useful for statistics and status polling but SNMP has
   limited configuration management support.

Ersue                    Expires April 28, 2011                [Page 13]

Internet-Draft          IETF Management Framework           October 2010

   o  There is a semantic mismatch between the task-oriented view
      preferred by operators and the data-centric view provided by SNMP,

   o  SNMP does not separate clearly between configuration data and
      operational state,

   o  Implementing SNMP transactional model and the protocol constraints
      is complex, and

   o  SNMP modeling language has limited support for structured data
      types and relationships among managed objects.

   The IAB workshop on Network Management determined advanced
   requirements for configuration management [IAB2002]:

   o  Robustness: Minimizing disruptions and maximizing stability,

   o  Support of task-oriented view,

   o  Extensible for new operations,

   o  Standardized error handling,

   o  Clear distinction between configuration data and operational

   o  Distribution of configurations to devices under transactional

   o  Single and multi-system transactions and scalability in the number
      of transactions and managed devices,

   o  Operations on selected subsets of management data,

   o  Dump and reload a device configuration in a textual format in a
      standard manner across multiple vendors and device types,

   o  Support a human interface and a programmatic interface,

   o  Data modeling language with a human friendly syntax,

   o  Easy conflict detection and configuration validation, and

   o  Secure transport, authentication, and robust access control.

   The NETCONF protocol [RFC4741] is a Proposed Standard that provides
   mechanisms to install, manipulate, and delete the configuration of
   network devices and aims to address the advanced configuration

Ersue                    Expires April 28, 2011                [Page 14]

Internet-Draft          IETF Management Framework           October 2010

   management requirements pointed in the IAB workshop.  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 and reliable
   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.

   Additionally NETCONF WG developed the NETCONF Event Notifications
   Mechanism as an optional capability, which provides an asynchronous
   message notification delivery service for NETCONF [RFC5277].  NETCONF
   notification mechanism enables using general purpose notification
   streams, which can not only transport NETCONF notifications but also
   alarms from other sources, where the originator of the NETCONF
   notification stream can be any managed device (e.g.  SNMP alarms).

   NETCONF Partial Locking introduces fine-grained locking of the
   configuration datastore to enhance NETCONF for fine-grained
   transactions on parts of the datastore [RFC5717].

   NETCONF WG also defined the necessary data model to monitor the
   NETCONF protocol by using YANG.  The monitoring data model includes
   information about NETCONF datastores, sessions, locks, and
   statistics, which facilitate the management of a NETCONF server.
   NETCONF monitoring document also defines methods for NETCONF clients
   to discover data models supported by a NETCONF server and defines a
   new operation to retrieve them [RFC6022].

   ADD: Describe how an SNMP agent and a NETCONF server may co-exist on
   the same managed device using the same datastore for the management
   data model.

   NETCONF defined SSH transport binding as the mandatory secure
   transport of its RPC messages [RFC4742].  Other optional secure
   transport bindings are available for TLS [RFC5539], BEEP (over TLS)
   [RFC4744], and SOAP (over HTTP over TLS) [RFC4743].  There is an
   implementation available using NETCONF over SOAP as a Web Service

   Currently NETCONF workgroup is focusing on bug fixing of the NETCONF
   base protocol standard [4741bis] and the SSH transport protocol
   mapping [4742bis] as well as the specification of the NETCONF Access
   Control Model (NACM).  NACM is going to provide a secure operating

Ersue                    Expires April 28, 2011                [Page 15]

Internet-Draft          IETF Management Framework           October 2010

   environment for NETCONF and proposes standard mechanisms to restrict
   protocol access to particular users with a pre-configured subset of
   operations and content.

   NETMOD WG developed YANG as the normative modeling language for the
   modeling of configuration data for usage with NETCONF.  YANG follows
   following design goals addressing specific requirements on a modeling
   language for configuration management:

   o  Allow modeling of standard and vendor defined modules for multi-
      vendor interoperability,

   o  Define semantics and data organization, i.e. models operational
      and configuration data, notifications, and operations,

   o  "human-readable", easy to use and text-based,

   o  Enable addition of new content to existing data models and can be
      extended at IETF as necessary,

   o  Map directly to XML content (on the wire), and

   o  Basic types compatible with SMIv2 and preserves therefore
      investments in SNMP MIBs.

   NETMOD WG furthermore developed Common YANG Data Types to be used
   with YANG [RFC6021] and a guidelines document for authors and
   reviewers of YANG Data Model Documents [I-D
   draft-ietf-netmod-yang-usage] as well as the mapping rules for
   translating YANG data models into Document Schema Definition
   Languages (DSDL) [I-D.ietf-netmod-dsdl-map].  The architecture
   document "An Architecture for Network Management using NETCONF and
   YANG" describes how NETCONF and YANG can help to build network
   management applications that meet the needs of network operators

   IPFIX WG prepared the normative IPFIX/PSAMP configuration model for
   configuring and monitoring IPFIX and PSAMP compliant Monitoring
   Devices with the YANG modeling language and is proposing to use
   NETCONF for the configuration of these entities [I-D.ietf-ipfix-

   At the time of this writing, the rechartering discussion of the
   NETMOD WG is ongoing.  NETMOD WG aims to focus in its second phase on
   the development of core system and core interface data models.  The
   WG will not develop models for specific topic areas or workgroups at
   IETF.  Such modeling work will be done in corresponding WGs, e.g.
   DNSOP WG will develop the DNS configuration model using YANG.

Ersue                    Expires April 28, 2011                [Page 16]

Internet-Draft          IETF Management Framework           October 2010  YANG - NETCONF Modeling Language

   Following the guideline and requests of the IAB management workshop
   the NETMOD workgroup developed a "human-friendly" modeling language
   defining the semantics of operational data, configuration data,
   notifications, and operations [RFC6020].  The new modeling language
   focuses on readability and ease of use and will serve as the
   normative description of NETCONF data models.

   ADD: Input from YANG team?

2.4.2.  SYSLOG

   The SYSLOG protocol [RFC5424] 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
   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 [RFC5424].  The
   IETF has also standardized the application of message security for
   SYSLOG messages using TLS [RFC5425], 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 [RFC5848].

   The IETF has standardized a new message header format, including
   timestamp, hostname, application, and message ID, to improve
   filtering, interoperability and correlation between compliant

   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

Ersue                    Expires April 28, 2011                [Page 17]

Internet-Draft          IETF Management Framework           October 2010

   structured data element design allows vendors to define their own
   structured data elements to supplement standardized elements.
   [RFC5675] defines a mapping from SNMP notifications to SYSLOG
   messages and [RFC5676] defines the corresponding managed objects for
   this purpose.  And [RFC5674] defines the way alarms are send in
   Syslog, which includes the mapping of ITU perceived severities onto
   syslog message fields and a number of alarm-specific definitions from
   ITU-T X.733 and the IETF Alarm MIB.

   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.  The intent is that
   these textual conventions will be imported and used in MIB modules
   that would otherwise define their own representations.  [RFC5427]

   [RFC5848] "Signed Syslog Messages" defines a mechanism to add origin
   authentication, message integrity, replay resistance, message
   sequencing, and detection of missing messages to the transmitted
   syslog messages to be used in conjunction with the Syslog protocol.

   The Syslog protocol layered architecture provides for support of any
   number of transport mappings.  However, for interoperability
   purposes, syslog protocol implementers are required to support the
   transmission of Syslog Messages over UDP as defined in [RFC5426].

   IETF furthermore defined the TLS transport mapping for Syslog in
   [RFC5425], which provides a secure connection for the transport of
   syslog messages and describes the security threats to syslog and how
   TLS can be used to counter such threats.  Datagram Transport Layer
   Security (DTLS) Transport Mapping for Syslog is defined in [RFC6012],
   which can be used in cases where a connection-less transport is

   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


   IPFIX [RFC5101] is a Proposed Standard, which defines a push-based
   data export mechanism for formatting and transferring IP flow
   information from an exporter to a collector.  PSAMP defines a
   standard set of capabilities for network elements to sample subsets
   of packets by statistical and other methods.

   The IPFIX working group has specified the Information Model (to
   describe IP flows) and the IPFIX protocol for the export of flow

Ersue                    Expires April 28, 2011                [Page 18]

Internet-Draft          IETF Management Framework           October 2010

   information from routers or measurement probes to external systems
   [RFC5101], [RFC5102].  IPFIX protocol exports flow data e.g. from
   routers and probes (IPv4, IPv6) and works on top of UDP, TCP or SCTP.
   Several applications using the IPFIX protocol are available.

   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.  IPFIX defines a common
   representation of flow data and a standard means of communicating the
   data over a number of transport protocols.

   [RFC3917] specifies the observation point, flows, exporting and the
   collecting process as well as a metering process that consists of a
   packet header capturing, time stamping, classifying, sampling, and
   maintaining flow records.

   IPFIX Information Model defines Information Elements (IEs) for
   distinguishing flows and for reporting flow characteristics
   [RFC5102].  Information Model for PSAMP extends the IPFIX information
   model by IEs for packet header and payload information [RFC5477] and
   defines packet selection methods for filtering and sampling of such
   data.  IPFIX and PSAMP packet sampling use the same packet processing
   (aka. packet mediation).  PSAMP packet information is exported with
   the IPFIX protocol based on a shared information model.

   The IPFIX WG has developed an XML-based configuration data model in
   close collaboration with the NETMOD WG and uses YANG as modeling
   language [I-D.ietf-ipfix-configuration-model].  The model specifies
   the necessary data for configuring and monitoring selection
   processes, caches, exporting processes, and collecting processes of
   IPFIX and PSAMP compliant monitoring devices.

   At the time of this writing a framework for IPFIX flow mediation is
   in preparation, which addresses the need for mediation of flow
   information in IPFIX applications in large operator networks, e.g.
   for aggregating huge amounts of flow data and for anonymization of
   flow information.  IPFIX Mediation Framework defines the intermediate
   device between Exporters and Collectors, which provides an IPFIX
   Mediation by receiving a record stream from e.g. a Collecting
   Process, hosting one or more Intermediate Processes to transform this
   stream, and exporting the transformed record stream into IPFIX
   Messages via an Exporting Process [I-D.ietf-ipfix-mediators-

   The work on IP Flow Anonymization Support describes anonymization
   techniques for IP flow data and the export of anonymized data

Ersue                    Expires April 28, 2011                [Page 19]

Internet-Draft          IETF Management Framework           October 2010

   The document 'IPFIX Export per SCTP Stream' [I-D.ietf-ipfix-export-
   per-sctp-stream] specifies a reliability extension based on a method
   for exporting a Template Record and its associated Data Sets in a
   single SCTP stream, for limiting each Template ID to a single SCTP
   stream and imposing in-order transmission.

   [I-D.ietf-ipfix-structured-data] proposes an extension to the IPFIX
   protocol to support the export of hierarchically structured data and
   lists (sequences) of Information Elements in data records.  The
   document describes how to distribute structured data with an abstract
   data type and a new Information Element, e.g. for the distribution of
   security keys or performance measures.  This application can also be
   used for the distribution of logging information if standard SYSLOG
   based logging is not available.

   There are several applications such as usage-based accounting,
   traffic profiling, traffic engineering, intrusion detection, and QoS
   monitoring, that require flow-based traffic measurements, which can
   be realized on top of IPFIX.  IPFIX can also be used e.g. for the
   monitoring of the protocols like SIP and the related media transfer,
   which is indeed based on flows on application layer.  The
   requirements to such a monitoring application are e.g. measuring
   signaling quality (e.g., session request delay, session completion
   ratio, or hops for request), media QoS (e.g., jitter, delay or bit
   rate), and user experience (e.g., Mean Opinion Score).

   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 WG developed the protocol for reporting observed
   packets by extending the IPFIX protocol.  In order to reduce the
   amount of data to be processed for selecting observed IP packets,
   packet selection methods have been defined.

   PSAMP standardizes sampling, selection, metering, and reporting
   strategies for different purposes and includes support for packet
   sampling in IPv4, IPv6, and MPLS-based networks.  To simplify the
   solution, the IPFIX protocol is used for the export of the PSAMP
   reports to collector applications.

   NOTE: Input from IPFIX WG?

3.  Management Protocols and Mechanisms with specific Focus

   This section reviews additional protocols IETF offers for management
   and discusses for which applications they were designed and/or
   already successfully deployed.  These are protocols that have mostly
   reached or short before Proposed Standard status or higher within the

Ersue                    Expires April 28, 2011                [Page 20]

Internet-Draft          IETF Management Framework           October 2010


3.1.  IP Address Management with DHCP

   BOOTP (Bootstrap Protocol), originally defined in [RFC951], has been
   used by network clients during the bootstrap process to obtain an IP
   address from a configuration server.  BOOTP requires manual
   intervention to add configuration information for each client, and
   does not provide a mechanism for reclaiming disused IP addresses.

   The Draft Standard Dynamic Host Configuration Protocol (DHCP)
   [RFC2131] was defined as an extension to BOOTP.  DHCP provides a
   framework for passing configuration information to hosts on a TCP/IP
   network and does as such enable autoconfiguration in IP networks.  In
   addition to IP address management, DHCP can also provide other
   configuration information, particularly the IP addresses of local
   caching DNS resolvers or servers providing servers.  As described in
   [I-D.baker-ietf-core] DHCP can be used for IPv4 and IPv6 Address
   Allocation and Assignment as well as Service Discovery.

   There are two versions of DHCP, one for IPv4 [RFC2131] and one for
   IPv6 [RFC3315].  While both versions bear the same name and perform
   much the same purpose, the details of the protocol for IPv4 and IPv6
   are sufficiently different that they can be considered separate

   Following are examples, where DHCP options have been used to provide
   configuration information or access to specific servers.

   o  [RFC3646] describes two DHCPv6 options for passing a list of
      available DNS recursive name servers and a domain search list to a

   o  [RFC2610] describes how entities using the Service Location
      Protocol can find out the address of Directory Agents in order to
      transact messages and how the assignment of scope for
      configuration of SLP User and Service Agents can be achieved.

   o  [RFC3319] specifies two DHCPv6 options that allow SIP clients to
      locate a local SIP server that is to be used for all outbound SIP
      requests, a so-called outbound proxy server.

   o  [RFC4280] defines new options to discover the Broadcast and
      Multicast Service (BCMCS) controller in an IP network.

Ersue                    Expires April 28, 2011                [Page 21]

Internet-Draft          IETF Management Framework           October 2010

3.2.  IPv6 Network Operations

   The IPv6 Operations Working Group (v6ops) develops guidelines for the
   operation of a shared IPv4/IPv6 Internet and provides operational
   guidance on how to deploy IPv6 into existing IPv4-only networks, as
   well as into new network installations.

   NOTE: Input planned from V6ops Workgroup.

3.3.  SNMP Agent Extensibility (AgentX) Protocol

   The Draft Standard [RFC2741] "Agent Extensibility (AgentX) Protocol"
   defines a framework for extensible SNMP agents including master
   agents and subagents, the AgentX protocol used to communicate between
   them, and how the extensible agent processes SNMP protocol messages.

   Within the SNMP framework, a managed node contains a processing
   entity called agent, which has access to management information.
   Within the AgentX framework, an agent is further defined to consist

   o  a single processing entity called the master agent, which sends
      and receives SNMP protocol messages in an agent role (as specified
      by the SNMP framework documents) but typically has little or no
      direct access to management information, and

   o  zero or more processing entities called subagents, which are
      "shielded" from the SNMP protocol messages processed by the master
      agent, but which have access to management information.

   The internal operations of AgentX are invisible to an SNMP entity
   operating in a manager role.  From a manager's point of view, an
   extensible agent behaves exactly as would a non-extensible
   (monolithic) agent that has access to the same management

   [RFC2741] specifies furthermore a TCP binding for the AgentX

   The Draft Standard [RFC2742] "Definitions of Managed Objects for
   Extensible SNMP Agents" describes objects managing SNMP agents that
   use the AgentX Protocol and specifies a MIB module, which is
   compliant to the SMIv2, and semantically identical to the peer SMIv1

Ersue                    Expires April 28, 2011                [Page 22]

Internet-Draft          IETF Management Framework           October 2010

3.4.  Radius

   Radius [RFC2865], the remote Authentication Dial In User Service, is
   a Draft Standard that describes a client/server protocol for carrying
   authentication, authorization, and configuration information between
   a Network Access Server (NAS), which desires to authenticate its
   links and a shared Authentication Server.

   This protocol is widely implemented and is used in environments like
   enterprise networks, where a single administrative authority manages
   the network, and protects the privacy of user information.

   RADIUS is extensible with Vendor-Specific Attributes (VSAs), which
   are mostly vendor-specific.

   The RADIUS protocol uses a shared secret along with the MD5 hashing
   algorithm to secure passwords.  Based on the known threads additional
   protection like IPsec tunnels are used to further protect the RADIUS

   Radius has been prepared to use over UDP port 1812 for RADIUS
   Authentication and 1813 for RADIUS Accounting assigned by IANA.

   [RFC3162] 'RADIUS and IPv6' specifies the operation of RADIUS over
   IPv6 and the RADIUS attributes used to support the IPv6 network

   [RFC4675] 'RADIUS Attributes for Virtual LAN and Priority Support'
   defines additional attributes for dynamic Virtual LAN assignment and
   prioritization, for use in provisioning of access to IEEE 802 local
   area networks usable with Radius and Diameter.

   [RFC5080] 'Common RADIUS Implementation Issues and Suggested Fixes'
   describes common issues seen in RADIUS implementations and suggests
   some fixes.  Where applicable, unclear statements and errors in
   previous RADIUS specifications are clarified.

   [RFC5090] 'RADIUS Extension for Digest Authentication' defines an
   extension to the RADIUS protocol to enable support of Digest
   Authentication, for use with HTTP-style protocols like the Session
   Initiation Protocol (SIP) and HTTP.

   [RFC5580] 'Carrying Location Objects in RADIUS and Diameter describes
   procedures for conveying access-network ownership and location
   information based on civic and geospatial location formats in RADIUS
   and Diameter.

   NOTE: Need more discussion of Radius RFCs and use cases.

Ersue                    Expires April 28, 2011                [Page 23]

Internet-Draft          IETF Management Framework           October 2010

3.5.  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 not directly
   backwards compatible, but provides an upgrade path for RADIUS.

   Diameter is designed to resolve a number of known problems with
   RADIUS.  Diameter supports server failover, reliable transport over
   TCP and SCTP, agents for proxy and redirect and relay, server-
   initiated messages, auditability, and capability negotiation.
   Diameter also provides a larger attribute space for attribute-value
   pairs (AVPs) and identifiers than Radius.  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.

   Other important differences to Radius are:
   - Use of reliable transport protocols (TCP or SCTP, not UDP),
   - Network and transport layer security (IPsec or TLS),
   - Stateful and stateless models,
   - Dynamic discovery of peers (using DNS SRV and NAPTR),
   - Supports application layer acknowledgements, defines failover
   methods and state machines [RFC3539],
   - Error notification,
   - Better roaming support,
   - Easier to extend, and
   - Basic support for user-sessions and accounting.

   The Diameter protocol has been enhanced for the use with 3GPP IP
   Multimedia Subsystem (IMS).  Different IMS interfaces (e.g.  Cx) are
   supported by Diameter applications [3GPPIMS].

   The protocol is designed to be extensible to support e.g. proxies,
   brokers, mobility and roaming, Network Access Servers (NASREQ), and
   Accounting and Resource Management.  Diameter applications extend the
   Diameter base protocol by adding new commands and/or attributes.
   Each application is defined by an application identifier and can add
   new command codes and/or new mandatory Attribute-Value Pairs (AVPs).

   Following are examples of Diameter applications:
   - Diameter Mobile IPv4 Application [RFC4004],
   - Diameter Network Access Server Application (NASREQ, [RFC4005]),
   - Diameter Extensible Authentication Protocol Application [RFC4072],
   - Diameter Credit-Control Application [RFC4006],
   - Diameter Session Initiation Protocol Application [RFC4740], and

Ersue                    Expires April 28, 2011                [Page 24]

Internet-Draft          IETF Management Framework           October 2010

   - Diameter Quality-of-Service Application [RFC5866].

   [RFC5516] 'Diameter Command Code Registration for the Third
   Generation Partnership Project (3GPP) Evolved Packet System (EPS)'
   registers a set of IANA Diameter Command Codes to use in new vendor-
   specific Diameter applications defined for the 3GPP) Evolved Packet
   System (EPS).

   [RFC5447] 'Diameter Mobile IPv6: Support for Network Access Server to
   Diameter Server Interaction' describes the bootstrapping of the
   Mobile IPv6 framework and the support of interworking with existing
   Authentication, Authorization, and Accounting (AAA) infrastructures
   by using the Diameter Network Access Server to home AAA server

   [RFC5777] 'Traffic Classification and Quality of Service (QoS)
   Attributes for Diameter' defines a number of Diameter AVPs for
   traffic classification with actions for filtering and Quality of
   Service (QoS) treatment.

   [RFC5729] 'Clarifications on the Routing of Diameter Requests Based
   on the Username and the Realm' defines the behavior required of
   Diameter agents to route requests when the User-Name AVP contains a
   Network Access Identifier formatted with multiple realms.  These
   multi-realm Network Access Identifiers are used in order to force the
   routing of request messages through a predefined list of mediating

   The IANA has assigned TCP and SCTP port number 3868 to Diameter.

   NOTE: Need more discussion of Diameter RFCs and use cases.

3.6.  CAPWAP

   Wireless LAN product architectures have evolved from single
   autonomous access points to systems consisting of a centralized
   Access Controller (AC) and Wireless Termination Points (WTPs).  The
   general goal of centralized control architectures is to move access
   control, including user authentication and authorization, mobility
   management, and radio management from the single access point to a
   centralized controller.

   Based on the CAPWAP Architecture Taxonomy work [RFC4118] CAPWAP
   workgroup developed the CAPWAP protocol to facilitate control,
   management and provisioning of WLAN Termination Points (WTPs)
   specifying the services, functions and resources relating to 802.11
   WLAN Termination Points in order to allow for interoperable
   implementations of WTPs and ACs.  The protocol defines the CAPWAP

Ersue                    Expires April 28, 2011                [Page 25]

Internet-Draft          IETF Management Framework           October 2010

   control plane including the primitives to control data access.  The
   protocol document also defines how configuration management of WTPs
   can be done and defines CAPWAP operations responsible for debugging,
   gathering statistics, logging, and firmware management as well as
   discusses operational and transport considerations.

   CAPWAP protocol is defined to be independent of Layer 2 technologies,
   and meets the objectives in "Objectives for Control and Provisioning
   of Wireless Access Points (CAPWAP)" [RFC4564].  Separate binding
   extensions enable the use with additional wireless technologies.
   [RFC5416] defines CAPWAP Protocol Binding for IEEE 802.11.

   CAPWAP Base MIB [RFC5833] describes managed objects for modeling the
   CAPWAP Protocol and provides configuration and WTP status-monitoring
   aspects of CAPWAP, where CAPWAP Binding MIB [RFC5834] describes
   managed objects for modeling of CAPWAP protocol for IEEE 802.11
   wireless binding.
   (RFC 5833 and RFC 5834 have been published as Informational RFCs to
   provide the basis for future work on a SNMP management of the CAPWAP

3.7.  Access Node Control Protocol

   The Access Node Control Protocol (ANCP) [I-D.ietf-ancp-protocol]
   realizes a control plane between a service-oriented layer 3 edge
   device (the Network Access Server, NAS) and a layer 2 Access Node
   (e.g., Digital Subscriber Line Access Module, DSLAM).  As such ANCP
   operates in a multi-service reference architecture and communicates
   QoS-, service- and subscriber-related configurations and operations
   between a NAS and an Access Node.

   The main goal of this protocol is to configure and manage access
   equipments and allow them to report information to the NAS in order
   to enable and optimize configuration.

   Framework and Requirements for an Access Node Control Mechanism and
   the use cases for ANCP are documented in [RFC5851].  Security Threats
   and Security Requirements for ANCP are discussed in [RFC5713].

3.8.  Ad-Hoc Network Autoconfiguration

   Ad-hoc nodes need to configure their network interfaces with locally
   unique addresses as well as globally routable IPv6 addresses, in
   order to communicate with devices on the Internet.  AUTOCONF WG
   developed [RFC5889], which describes the addressing model for ad-hoc
   networks and how nodes in these networks configure their addresses.

   The ad-hoc nodes under consideration are expected to be able to

Ersue                    Expires April 28, 2011                [Page 26]

Internet-Draft          IETF Management Framework           October 2010

   support multi-hop communication by running MANET routing protocols as
   developed by the IETF MANET WG.

   From the IP layer perspective, an ad hoc network presents itself as a
   layer 3 multi-hop network formed over a collection of links.  The
   addressing model aims to avoid problems for ad-hoc-unaware parts of
   the system, such as standard applications running on an ad-hoc node
   or regular Internet nodes attached to the ad-hoc nodes.

3.9.  Policy-based Management

3.9.1.  IETF Policy Framework

   IETF specified a general framework for managing, sharing, and reusing
   policies in a vendor independent, interoperable, and scalable manner
   as well as defining an extensible information model for representing
   policies.  The policy framework is based on a policy-based admission
   control specifying the two main architectural elements the Policy
   Enforcement Point (PEP) and the Policy Decision Point (PDP).

   For the purposes of network management, policies allow an operator to
   specify how the network is to be configured and monitored through a
   descriptive language.  Furthermore, it allows the automation of a
   number of management tasks, according to the requirements set out in
   the policy module.

   IETF Policy Framework [RFC2753] has been accepted by the industry as
   a standard-based policy approach and has been adopted by different
   SDOs e.g. 3GGP charging standards.

3.9.2.  COPS-PR

   [RFC3159] defines the Structure of Policy Provisioning Information
   (SPPI), an extension to the SMI modeling language used to write
   Policy Information Base (PIB) modules.  COPS-PR [RFC3084] uses the
   Common Open Policy Service (COPS) protocol for support of policy
   provisioning.  COPS-PR and the Structure of Policy Provisioning
   Information (SPPI) have been approved as Proposed Standards.

   The COPS-PR specification is independent of the type of policy being
   provisioned (QoS, Security, etc.) but focuses on the 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).

Ersue                    Expires April 28, 2011                [Page 27]

Internet-Draft          IETF Management Framework           October 2010

   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 IETF standard, and the use of COPS-PR is not recommended.

3.10.  Network Performance Management

3.10.1.  IP Performance Metrics (IPPM)

   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

   These metrics are designed for network operator use and provide
   unbiased quantitative measures of performance.

   The main properties of individual IPPM performance and reliability
   metrics are that the metrics should be well-defined and concrete thus
   implementable, and they should exhibit no bias for IP clouds
   implemented with identical technology.  In addition, the methodology
   used to implement a metric should have the property of being
   repeatable with consistent measurements.

   IETF IP Performance Metrics have been introduced widely in the
   industry and adopted by different SDOs such as ITU-T.

   Following are examples of essential IPPM documents published as
   Proposed Standard:

   o  IPPM Framework document [RFC2330] defines a general framework for
      particular metrics developed by IPPM WG and defines the
      fundamental concepts of 'metric' and 'measurement methodology' and
      discusses the issue of measurement uncertainties and errors as
      well as introduces the notion of empirically defined metrics and
      how metrics can be composed.

   o  One-way Delay Metric for IPPM [RFC2679] defines a metric for one-
      way delay of packets across Internet paths.  It builds on notions
      introduced in the IPPM Framework document.

Ersue                    Expires April 28, 2011                [Page 28]

Internet-Draft          IETF Management Framework           October 2010

   o  Round-trip Delay Metric for IPPM [RFC2681] defines a metric for
      round-trip delay of packets across network paths and follows
      closely the corresponding metric for One-way Delay.

   o  IP Packet Delay Variation Metric [RFC3393] refers to a metric for
      variation in delay of packets across network paths and is based on
      the difference in the One-Way-Delay of selected packets called "IP
      Packet Delay Variation (ipdv)".

   o  One-way Packet Loss Metric for IPPM [RFC2680] defines a metric for
      one-way packet loss across Internet paths.

   o  One-Way Packet Duplication Metric [RFC5560] defines a metric for
      the case, where multiple copies of a packet are received and
      discusses methods to summarize the results of streams.

   o  Packet Reordering Metrics [RFC4737] defines metrics to evaluate
      whether a network has maintained packet order on a packet-by-
      packet basis and discusses the measurement issues, including the
      context information required for all metrics.

   o  IPPM Metrics for Measuring Connectivity [RFC2678] defines a series
      of metrics for connectivity between a pair of Internet hosts.

   o  Framework for Metric Composition [RFC5835] describes a detailed
      framework for composing and aggregating metrics.

   o  A One-way Active Measurement Protocol (OWAMP) [RFC4656] measures
      unidirectional characteristics such as one-way delay and one-way
      loss between network devices and enables the interoperability of
      these measurements.

   o  A Two-Way Active Measurement Protocol (TWAMP) [RFC5357] adds
      round-trip or two-way measurement capabilities to OWAMP.

   For the "Information Model and XML Data Model for Traceroute
   Measurements [RFC5388] and the BCP document [BCP108] "IP Performance
   Metrics (IPPM) Metrics Registry" see section 4.4 'Performance

3.10.2.  Real-time Flow Measurement (RTFM)

   (Real-Time) Traffic Flow Measurement: Architecture [RFC2722]
   specifies the general framework for describing network traffic flows,
   an architecture for traffic flow measurement and reporting, and
   indicates how it can be used within the Internet.  As such RTFM is a
   mechanism for configuring meters and meter readers, and for
   collecting the flow data from remote meters.

Ersue                    Expires April 28, 2011                [Page 29]

Internet-Draft          IETF Management Framework           October 2010

   RTFM is e.g. used for the measurement of DNS performance.

3.11.  Application Management Protocols

3.11.1.  ACAP

   The Application Configuration Access Protocol (ACAP) [RFC2244] 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.

3.11.2.  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.

   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

   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.

Ersue                    Expires April 28, 2011                [Page 30]

Internet-Draft          IETF Management Framework           October 2010

3.11.3.  EPP

   The Extensible Provision Protocol [RFC5730] is an Internet Standard
   [STD69] 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.

   EPP is specified in XML and defines generic object management
   operations and an extensible framework that maps protocol operations
   to objects.  EPP is a stateful XML protocol that can be layered over
   multiple transport protocols.  Protected using lower-layer security
   protocols, clients exchange identification, authentication, and
   option information, and then engage in a series of client-initiated
   command-response exchanges.

   EPP has been adopted by numerous domain name registries mainly for
   the communication between domain name registries and domain name
   registrars and for allocating objects within registries over the

4.  Proposed, Draft and Standard Level Data Models

   This section lists solutions for which information or data models
   have been standardized at the IETF, so that existing solutions can be
   reused and the data models can be applied to new solutions.

   Management data models have a slightly different interpretation for
   interoperability.  This is discussed in detail in [BCP27]
   "Advancement of MIB specifications on the IETF Standards Track"
   [RFC2438] with special considerations about the advancement process
   for management data models.  However most IETF management data models
   never advance beyond Proposed Standard.

   This section discusses management data models that have reached at
   least Proposed Standard status in the IETF.

4.1.  Fault Management

   Draft Standards:

   [RFC3418], part of SNMPv3 standard [STD62], 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.

Ersue                    Expires April 28, 2011                [Page 31]

Internet-Draft          IETF Management Framework           October 2010

   [RFC3413], part of SNMPv3 standard [STD62], 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 (for further
   discussion on RMON see section 4.4 'Performance Management').

   Proposed Standards:

   The IETF SYSLOG protocol [RFC5424] 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.

   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 [RFC3877] and the Alarm Reporting Control MIB in
   [RFC3878] specify mechanisms for expressing state transition models
   for persistent problem states.

   ALARM MIB defines:
   - a mechanisms for expressing state transition models for persistent
   problem states,
   - a mechanism to correlate a notification with subsequent state
   transition notifications about the same entity/object, and
   - a generic alarm reporting mechanism (extends ITU-T work X.733 [ITU-

   [RFC3878] in particular defines objects for controlling the reporting
   of alarm conditions and extends ITU-T work M.3100 Amendment 3 [ITU-

   Other MIB modules that may be applied to Fault Management include:

   o  NOTIFICATION-LOG-MIB [RFC3014] describes managed objects used for
      logging SNMP Notifications.

   o  ENTITY-STATE-MIB [RFC4268] describes extensions to the Entity MIB
      to provide information about the state of physical entities.

Ersue                    Expires April 28, 2011                [Page 32]

Internet-Draft          IETF Management Framework           October 2010

   o  ENTITY-SENSOR-MIB [RFC3433] describes managed objects for
      extending the Entity MIB to provide generalized access to
      information related to physical sensors, which are often found in
      networking equipment (such as chassis temperature, fan RPM, power
      supply voltage).

4.2.  Configuration Management

   Draft standards:

   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, only the YANG module for the monitoring
   of the NETCONF protocol exists as proposed standard.  NETMOD WG is
   going to be rechartered to develop core system models in YANG.

   MIB modules for monitoring of network configuration (e.g. for
   physical and logical network topologies) already exist and provide
   some of the desired capabilities.  New MIB modules might be developed
   for the target functionality to allow operators to monitor and modify
   the operational parameters, such as timer granularity, event
   reporting thresholds, target addresses, and so on.

   [RFC3418], part of SNMPv3 standard [STD62], 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], 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.

   The Interfaces MIB [RFC2863] 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.

   Proposed standards:

   The Entity MIB [RFC4133] is used for managing multiple logical and
   physical entities managed by a single SNMP agent.  This module

Ersue                    Expires April 28, 2011                [Page 33]

Internet-Draft          IETF Management Framework           October 2010

   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.

   [RFC3165] supports the use of user-written scripts to delegate
   management functionality.

   Policy Based Management MIB [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.

4.3.  Accounting Management

   DIAMETER [RFC3588] and RADIUS [RFC2866] can be used to exchange
   accounting related information.

   IETF so far did only develop Informational RFCs as data model for
   accounting.  RADIUS Accounting Client MIB for IPv6 [RFC4670] and
   RADIUS Accounting Server MIB for IPv6 [RFC4671] allow the gathering
   of accounting data.

4.4.  Performance Management

   MIB modules typically contain counters to determine the frequency and
   rate of an occurrence.

   RMON [RFC2819] has the full standard status [STD59] and 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, where
   some of them are specific to management of 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.

   The RMON host group discovers hosts on the network by keeping a list
   of source and destination MAC Addresses seen in good packets

Ersue                    Expires April 28, 2011                [Page 34]

Internet-Draft          IETF Management Framework           October 2010

   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.

   Draft standards:

   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.

   Proposed standards:

   RMON MIB Extensions for High Capacity Alarms [RFC3434] describes
   managed objects for extending the alarm thresholding capabilities
   found in the RMON MIB and provides similar threshold monitoring of
   objects based on the Counter64 data type.

   RMON MIB Extensions for High Capacity Networks [RFC3273] defines
   objects for managing RMON devices for use on high-speed networks.

   RMON MIB Extensions for Interface Parameters Monitoring [RFC3144]
   describes an extension to the RMON MIB with a method of sorting the
   interfaces of a monitored device according to values of parameters
   specific to this interface.

   [RFC4710] describes Real-Time Application Quality of Service
   Monitoring.  RAQMON is part of the RMON protocol family, and supports
   end-2-end QoS monitoring for multiple concurrent applications and
   does not relate to a specific application transport.  RAQMON is
   scalable and works well with encrypted payload and signaling.  RAQMON
   uses TCP to transport RAQMON PDUs.

   [RFC4711] proposes an extension to the Remote Monitoring MIB
   [RFC2819] and describes managed objects used for real-time
   application Quality of Service (QoS) monitoring.  [RFC4712] specifies
   two transport mappings for the RAQMON information model using TCP as

Ersue                    Expires April 28, 2011                [Page 35]

Internet-Draft          IETF Management Framework           October 2010

   a native transport and SNMP to carry the RAQMON information from a
   RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC).

   Application Performance Measurement MIB [RFC3729] uses the
   architecture created in the RMON MIB and defines objects by providing
   measurement and analysis of the application performance as
   experienced by end-users.  Application performance measurement
   measures the quality of service delivered to end-users by

   Transport Performance Metrics MIB [RFC4150] describes managed objects
   used for monitoring selectable performance metrics and statistics
   derived from the monitoring of network packets and sub-application
   level transactions.  The metrics can be defined through reference to
   existing IETF, ITU, and other standards organizations' documents.

   IPPM WG defined an Information Model and XML Data Model for
   Traceroute Measurements [RFC5388], which defines a common information
   model dividing the information elements into two semantically
   separated groups (configuration elements and results elements) with
   an additional element to relate configuration elements and results
   elements by means of a common unique identifier.  Based on the
   information model, an XML data model is provided to store the results
   of traceroute measurements.

   IPPM WG has furthermore defined the BCP document [BCP108] "IP
   Performance Metrics (IPPM) Metrics Registry", which defines a
   registry for IP Performance Metrics [RFC4148].  The IANA-assigned
   registry contains an initial set of OBJECT IDENTITIES to currently
   defined metrics in the IETF as well as defines the rules for adding
   IP Performance Metrics that are defined in the future.

   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.

   Traffic Flow Measurement: Meter MIB [RFC2720] defines a MIB for use
   in controlling an RTFM Traffic Meter, in particular for specifying
   the flows to be measured and provides a mechanism for retrieving flow
   data from the meter using SNMP.

4.5.  Security Management

   Proposed standards:

   RADIUS Authentication Server MIB for IPv6 [RFC4669] defines a set of
   extensions that instrument RADIUS authentication server functions and

Ersue                    Expires April 28, 2011                [Page 36]

Internet-Draft          IETF Management Framework           October 2010

   RADIUS Authentication Client MIB for IPv6 [RFC4668] defines a set of
   extensions for RADIUS authentication client functions.  Both RFCs add
   support for version-neutral IP address formats.  Using these
   extensions, IP-based management stations can manage RADIUS
   authentication clients and servers.

   Following are Radius MIBs published as Informational RFC:

   o  RADIUS Dynamic Authorization Client MIB [RFC4672] describes the
      Dynamic Authorization Client (DAC) functions that support the
      dynamic authorization extensions defined in [RFC5176].

   o  RADIUS Dynamic Authorization Server MIB [RFC4673] describes the
      Dynamic Authorization Server (DAS) functions that support the
      dynamic authorization extensions defined in [RFC5176].

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

6.  Security Considerations

   This document introduces no new security concerns.

7.  Contributors

   This document uses the expired draft [I-D.ietf-opsawg-survey-
   management] edited by Dave Harrington as a starting point.

8.  Acknowledgements

   The authors would like to thank to ...

9.  Informative References

   [3GPPIMS]                                3GPP, "Release 10, IP
                                            Multimedia Subsystem (IMS);
                                            Stage 2", September 2010, <h

   [I-D.baker-ietf-core]                    Baker, F. and D. Meyer,
                                            "Internet Protocols for the
                                            Smart Grid",

Ersue                    Expires April 28, 2011                [Page 37]

Internet-Draft          IETF Management Framework           October 2010

                                            (work in progress),
                                            September 2010.

   [I-D.ietf-ancp-protocol]                 Wadhwa, S., Moisand, J.,
                                            Haag, T., Voigt, N., and T.
                                            Taylor, "Protocol for Access
                                            Node Control Mechanism in
                                            Broadband Networks",
                                            (work in progress),
                                            August 2010.

   [I-D.ietf-ipfix-anon]                    Boschi, E. and B. Trammell,
                                            "IP Flow Anonymisation
                                            (work in progress),
                                            October 2010.

   [I-D.ietf-ipfix-configuration-model]     Muenz, G., Claise, B., and
                                            P. Aitken, "Configuration
                                            Data Model for IPFIX and
                                            PSAMP", draft-ietf-ipfix-
                                            configuration-model-08 (work
                                            in progress), October 2010.

   [I-D.ietf-ipfix-export-per-sctp-stream]  Claise, B., Aitken, P.,
                                            Johnson, A., and G. Muenz,
                                            "IPFIX Export per SCTP
                                            Stream", draft-ietf-ipfix-
                                            (work in progress),
                                            May 2010.

   [I-D.ietf-ipfix-mediators-framework]     Kobayashi, A., Claise, B.,
                                            Muenz, G., and K. Ishibashi,
                                            "IPFIX Mediation:
                                            Framework", draft-ietf-
                                            (work in progress),
                                            October 2010.

   [I-D.ietf-ipfix-structured-data]         Yates, S., "Export of
                                            Structured Data in IPFIX", d
                                            data-03 (work in progress),
                                            October 2010.

Ersue                    Expires April 28, 2011                [Page 38]

Internet-Draft          IETF Management Framework           October 2010

   [I-D.ietf-isms-radius-vacm]              Narayan, K., Nelson, D., and
                                            R. Presuhn, "Using
                                            Authorization, and
                                            Accounting services to
                                            Dynamically Provision View-
                                            based Access Control Model
                                            User-to-Group Mappings", dra
                                            (work in progress),
                                            September 2010.

   [I-D.ietf-mpls-tp-oam-framework]         Allan, D., Busi, I., Niven-
                                            Jenkins, B., Fulignoli, A.,
                                            Hernandez-Valencia, E.,
                                            Levrau, L., Sestito, V.,
                                            Sprecher, N., Helvoort, H.,
                                            Vigoureux, M., Weingarten,
                                            Y., and R. Winter,
                                            "Operations, Administration
                                            and Maintenance Framework
                                            for MPLS- based Transport
                                            Networks", draft-ietf-mpls-
                                            tp-oam-framework-09 (work in
                                            progress), October 2010.

   [I-D.ietf-netmod-dsdl-map]               Lhotka, L., "Mapping YANG to
                                            Document Schema Definition
                                            Languages and Validating
                                            NETCONF Content", draft-
                                            (work in progress),
                                            October 2010.

   [I-D.ietf-netmod-yang-usage]             Bierman, A., "Guidelines for
                                            Authors and Reviewers of
                                            YANG Data Model Documents",
                                            usage-11 (work in progress),
                                            October 2010.

   [I-D.ietf-opsawg-oam-overview]           Mizrahi, T., Sprecher, N.,
                                            Bellagamba, E., and Y.
                                            Weingarten, "An Overview of
                                            Operations, Administration,
                                            and Maintenance (OAM)
                                            Mechanisms", draft-ietf-
                                            opsawg-oam-overview-02 (work

Ersue                    Expires April 28, 2011                [Page 39]

Internet-Draft          IETF Management Framework           October 2010

                                            in progress), October 2010.

   [I-D.ietf-opsawg-survey-management]      Harrington, D., "Survey of
                                            IETF Network Management
                                            Standards", draft-ietf-
                                            (work in progress),
                                            March 2009.

   [I-D.ietf-sipping-rtcp-summary]          Pendleton, A., Clark, A.,
                                            Johnston, A., and H.
                                            Sinnreich, "Session
                                            Initiation Protocol Event
                                            Package for Voice Quality
                                            Reporting", draft-ietf-
                                            (work in progress),
                                            August 2010.

   [RFC0951]                                Croft, B. and J. Gilmore,
                                            "Bootstrap Protocol",
                                            RFC 951, September 1985.

   [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, K.,
                                            McCloghrie, K., Rose, M.,
                                            and S. Waldbusser,
                                            "Introduction to Community-
                                            based SNMPv2", RFC 1901,
                                            January 1996.

   [RFC2026]                                Bradner, S., "The Internet
                                            Standards Process --
                                            Revision 3", BCP 9,
                                            RFC 2026, October 1996.

   [RFC2131]                                Droms, R., "Dynamic Host
                                            Configuration Protocol",
                                            RFC 2131, March 1997.

   [RFC2244]                                Newman, C. and J. Myers,
                                            "ACAP -- Application
                                            Configuration Access

Ersue                    Expires April 28, 2011                [Page 40]

Internet-Draft          IETF Management Framework           October 2010

                                            Protocol", RFC 2244,
                                            November 1997.

   [RFC2330]                                Paxson, V., Almes, G.,
                                            Mahdavi, J., and M. Mathis,
                                            "Framework for IP
                                            Performance Metrics",
                                            RFC 2330, May 1998.

   [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.

   [RFC2678]                                Mahdavi, J. and V. Paxson,
                                            "IPPM Metrics for Measuring
                                            Connectivity", RFC 2678,
                                            September 1999.

   [RFC2679]                                Almes, G., Kalidindi, S.,
                                            and M. Zekauskas, "A One-way
                                            Delay Metric for IPPM",
                                            RFC 2679, September 1999.

   [RFC2680]                                Almes, G., Kalidindi, S.,
                                            and M. Zekauskas, "A One-way
                                            Packet Loss Metric for
                                            IPPM", RFC 2680,
                                            September 1999.

   [RFC2681]                                Almes, G., Kalidindi, S.,
                                            and M. Zekauskas, "A Round-
                                            trip Delay Metric for IPPM",
                                            RFC 2681, September 1999.

   [RFC2720]                                Brownlee, N., "Traffic Flow
                                            Measurement: Meter MIB",
                                            RFC 2720, October 1999.

Ersue                    Expires April 28, 2011                [Page 41]

Internet-Draft          IETF Management Framework           October 2010

   [RFC2722]                                Brownlee, N., Mills, C., and
                                            G. Ruth, "Traffic Flow
                                            Measurement: Architecture",
                                            RFC 2722, October 1999.

   [RFC2741]                                Daniele, M., Wijnen, B.,
                                            Ellison, M., and D.
                                            Francisco, "Agent
                                            Extensibility (AgentX)
                                            Protocol Version 1",
                                            RFC 2741, January 2000.

   [RFC2753]                                Yavatkar, R., Pendarakis,
                                            D., and R. Guerin, "A
                                            Framework for Policy-based
                                            Admission Control",
                                            RFC 2753, January 2000.

   [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.

   [RFC2866]                                Rigney, C., "RADIUS
                                            Accounting", RFC 2866,
                                            June 2000.

   [RFC2981]                                Kavasseri, R., "Event MIB",
                                            RFC 2981, October 2000.

   [RFC2982]                                Kavasseri, R., "Distributed
                                            Management Expression MIB",
                                            RFC 2982, October 2000.

   [RFC3014]                                Kavasseri, R., "Notification
                                            Log MIB", RFC 3014,

Ersue                    Expires April 28, 2011                [Page 42]

Internet-Draft          IETF Management Framework           October 2010

                                            November 2000.

   [RFC3084]                                Chan, K., Seligson, J.,
                                            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.

   [RFC3144]                                Romascanu, D., "Remote
                                            Monitoring MIB Extensions
                                            for Interface Parameters
                                            Monitoring", RFC 3144,
                                            August 2001.

   [RFC3165]                                Levi, D. and J.
                                            Schoenwaelder, "Definitions
                                            of Managed Objects for the
                                            Delegation of Management
                                            Scripts", RFC 3165,
                                            August 2001.

   [RFC3273]                                Waldbusser, S., "Remote
                                            Network Monitoring
                                            Management Information Base
                                            for High Capacity Networks",
                                            RFC 3273, July 2002.

   [RFC3315]                                Droms, R., Bound, J., Volz,
                                            B., Lemon, T., Perkins, C.,
                                            and M. Carney, "Dynamic Host
                                            Configuration Protocol for
                                            IPv6 (DHCPv6)", RFC 3315,
                                            July 2003.

   [RFC3393]                                Demichelis, C. and P.
                                            Chimento, "IP Packet Delay
                                            Variation Metric for IP
                                            Performance Metrics (IPPM)",
                                            RFC 3393, November 2002.

   [RFC3410]                                Case, J., Mundy, R.,
                                            Partain, D., and B. Stewart,
                                            "Introduction and
                                            Applicability Statements for
                                            Internet-Standard Management

Ersue                    Expires April 28, 2011                [Page 43]

Internet-Draft          IETF Management Framework           October 2010

                                            Framework", RFC 3410,
                                            December 2002.

   [RFC3411]                                Harrington, D., Presuhn, R.,
                                            and B. Wijnen, "An
                                            Architecture for Describing
                                            Simple Network Management
                                            Protocol (SNMP) Management
                                            Frameworks", STD 62,
                                            RFC 3411, December 2002.

   [RFC3413]                                Levi, D., Meyer, P., and B.
                                            Stewart, "Simple Network
                                            Management Protocol (SNMP)
                                            Applications", STD 62,
                                            RFC 3413, December 2002.

   [RFC3414]                                Blumenthal, U. and B.
                                            Wijnen, "User-based Security
                                            Model (USM) for version 3 of
                                            the Simple Network
                                            Management Protocol
                                            (SNMPv3)", STD 62, RFC 3414,
                                            December 2002.

   [RFC3415]                                Wijnen, B., Presuhn, R., and
                                            K. McCloghrie, "View-based
                                            Access Control Model (VACM)
                                            for the Simple Network
                                            Management Protocol (SNMP)",
                                            STD 62, RFC 3415,
                                            December 2002.

   [RFC3417]                                Presuhn, R., "Transport
                                            Mappings for the Simple
                                            Network Management Protocol
                                            (SNMP)", STD 62, RFC 3417,
                                            December 2002.

   [RFC3418]                                Presuhn, R., "Management
                                            Information Base (MIB) for
                                            the Simple Network
                                            Management Protocol (SNMP)",
                                            STD 62, RFC 3418,
                                            December 2002.

   [RFC3433]                                Bierman, A., Romascanu, D.,
                                            and K. Norseth, "Entity

Ersue                    Expires April 28, 2011                [Page 44]

Internet-Draft          IETF Management Framework           October 2010

                                            Sensor Management
                                            Information Base", RFC 3433,
                                            December 2002.

   [RFC3434]                                Bierman, A. and K.
                                            McCloghrie, "Remote
                                            Monitoring MIB Extensions
                                            for High Capacity Alarms",
                                            RFC 3434, December 2002.

   [RFC3535]                                Schoenwaelder, J., "Overview
                                            of the 2002 IAB Network
                                            Management Workshop",
                                            RFC 3535, May 2003.

   [RFC3584]                                Frye, R., Levi, D.,
                                            Routhier, S., and B. Wijnen,
                                            "Coexistence between Version
                                            1, Version 2, and Version 3
                                            of the Internet-standard
                                            Network Management
                                            Framework", BCP 74,
                                            RFC 3584, August 2003.

   [RFC3588]                                Calhoun, P., Loughney, J.,
                                            Guttman, E., Zorn, G., and
                                            J. Arkko, "Diameter Base
                                            Protocol", RFC 3588,
                                            September 2003.

   [RFC3729]                                Waldbusser, S., "Application
                                            Performance Measurement
                                            MIB", RFC 3729, March 2004.

   [RFC3877]                                Chisholm, S. and D.
                                            Romascanu, "Alarm Management
                                            Information Base (MIB)",
                                            RFC 3877, September 2004.

   [RFC3878]                                Lam, H., Huynh, A., and D.
                                            Perkins, "Alarm Reporting
                                            Control Management
                                            Information Base (MIB)",
                                            RFC 3878, September 2004.

   [RFC3917]                                Quittek, J., Zseby, T.,
                                            Claise, B., and S. Zander,
                                            "Requirements for IP Flow

Ersue                    Expires April 28, 2011                [Page 45]

Internet-Draft          IETF Management Framework           October 2010

                                            Information Export (IPFIX)",
                                            RFC 3917, October 2004.

   [RFC4011]                                Waldbusser, S., Saperia, J.,
                                            and T. Hongal, "Policy Based
                                            Management MIB", RFC 4011,
                                            March 2005.

   [RFC4118]                                Yang, L., Zerfos, P., and E.
                                            Sadot, "Architecture
                                            Taxonomy for Control and
                                            Provisioning of Wireless
                                            Access Points (CAPWAP)",
                                            RFC 4118, June 2005.

   [RFC4133]                                Bierman, A. and K.
                                            McCloghrie, "Entity MIB
                                            (Version 3)", RFC 4133,
                                            August 2005.

   [RFC4148]                                Stephan, E., "IP Performance
                                            Metrics (IPPM) Metrics
                                            Registry", BCP 108,
                                            RFC 4148, August 2005.

   [RFC4150]                                Dietz, R. and R. Cole,
                                            "Transport Performance
                                            Metrics MIB", RFC 4150,
                                            August 2005.

   [RFC4251]                                Ylonen, T. and C. Lonvick,
                                            "The Secure Shell (SSH)
                                            Protocol Architecture",
                                            RFC 4251, January 2006.

   [RFC4268]                                Chisholm, S. and D. Perkins,
                                            "Entity State MIB",
                                            RFC 4268, November 2005.

   [RFC4422]                                Melnikov, A. and K.
                                            Zeilenga, "Simple
                                            Authentication and Security
                                            Layer (SASL)", RFC 4422,
                                            June 2006.

   [RFC4502]                                Waldbusser, S., "Remote
                                            Network Monitoring
                                            Management Information Base

Ersue                    Expires April 28, 2011                [Page 46]

Internet-Draft          IETF Management Framework           October 2010

                                            Version 2", RFC 4502,
                                            May 2006.

   [RFC4564]                                Govindan, S., Cheng, H.,
                                            Yao, ZH., Zhou, WH., and L.
                                            Yang, "Objectives for
                                            Control and Provisioning of
                                            Wireless Access Points
                                            (CAPWAP)", RFC 4564,
                                            July 2006.

   [RFC4656]                                Shalunov, S., Teitelbaum,
                                            B., Karp, A., Boote, J., and
                                            M. Zekauskas, "A One-way
                                            Active Measurement Protocol
                                            (OWAMP)", RFC 4656,
                                            September 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.

   [RFC4670]                                Nelson, D., "RADIUS
                                            Accounting Client MIB for
                                            IPv6", RFC 4670,
                                            August 2006.

   [RFC4671]                                Nelson, D., "RADIUS
                                            Accounting Server MIB for
                                            IPv6", RFC 4671,
                                            August 2006.

   [RFC4672]                                De Cnodder, S., Jonnala, N.,
                                            and M. Chiba, "RADIUS
                                            Dynamic Authorization Client
                                            MIB", RFC 4672,
                                            September 2006.

   [RFC4673]                                De Cnodder, S., Jonnala, N.,
                                            and M. Chiba, "RADIUS
                                            Dynamic Authorization Server
                                            MIB", RFC 4673,

Ersue                    Expires April 28, 2011                [Page 47]

Internet-Draft          IETF Management Framework           October 2010

                                            September 2006.

   [RFC4710]                                Siddiqui, A., Romascanu, D.,
                                            and E. Golovinsky, "Real-
                                            time Application Quality-of-
                                            Service Monitoring (RAQMON)
                                            Framework", RFC 4710,
                                            October 2006.

   [RFC4711]                                Siddiqui, A., Romascanu, D.,
                                            and E. Golovinsky, "Real-
                                            time Application Quality-of-
                                            Service Monitoring (RAQMON)
                                            MIB", RFC 4711,
                                            October 2006.

   [RFC4712]                                Siddiqui, A., Romascanu, D.,
                                            Golovinsky, E., Rahman, M.,
                                            and Y. Kim, "Transport
                                            Mappings for Real-time
                                            Application Quality-of-
                                            Service Monitoring (RAQMON)
                                            Protocol Data Unit (PDU)",
                                            RFC 4712, October 2006.

   [RFC4737]                                Morton, A., Ciavattone, L.,
                                            Ramachandran, G., Shalunov,
                                            S., and J. Perser, "Packet
                                            Reordering Metrics",
                                            RFC 4737, November 2006.

   [RFC4741]                                Enns, R., "NETCONF
                                            Configuration Protocol",
                                            RFC 4741, December 2006.

   [RFC4742]                                Wasserman, M. and T.
                                            Goddard, "Using the NETCONF
                                            Configuration Protocol over
                                            Secure SHell (SSH)",
                                            RFC 4742, December 2006.

   [RFC4743]                                Goddard, T., "Using NETCONF
                                            over the Simple Object
                                            Access Protocol (SOAP)",
                                            RFC 4743, December 2006.

   [RFC4744]                                Lear, E. and K. Crozier,
                                            "Using the NETCONF Protocol

Ersue                    Expires April 28, 2011                [Page 48]

Internet-Draft          IETF Management Framework           October 2010

                                            over the Blocks Extensible
                                            Exchange Protocol (BEEP)",
                                            RFC 4744, December 2006.

   [RFC4825]                                Rosenberg, J., "The
                                            Extensible Markup Language
                                            (XML) Configuration Access
                                            Protocol (XCAP)", RFC 4825,
                                            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.

   [RFC5102]                                Quittek, J., Bryant, S.,
                                            Claise, B., Aitken, P., and
                                            J. Meyer, "Information Model
                                            for IP Flow Information
                                            Export", RFC 5102,
                                            January 2008.

   [RFC5246]                                Dierks, T. and E. Rescorla,
                                            "The Transport Layer
                                            Security (TLS) Protocol
                                            Version 1.2", RFC 5246,
                                            August 2008.

   [RFC5277]                                Chisholm, S. and H. Trevino,
                                            "NETCONF Event
                                            Notifications", RFC 5277,
                                            July 2008.

   [RFC5357]                                Hedayat, K., Krzanowski, R.,
                                            Morton, A., Yum, K., and J.
                                            Babiarz, "A Two-Way Active
                                            Measurement Protocol
                                            (TWAMP)", RFC 5357,
                                            October 2008.

   [RFC5381]                                Iijima, T., Atarashi, Y.,
                                            Kimura, H., Kitani, M., and
                                            H. Okita, "Experience of
                                            Implementing NETCONF over
                                            SOAP", RFC 5381,
                                            October 2008.

Ersue                    Expires April 28, 2011                [Page 49]

Internet-Draft          IETF Management Framework           October 2010

   [RFC5388]                                Niccolini, S., Tartarelli,
                                            S., Quittek, J., Dietz, T.,
                                            and M. Swany, "Information
                                            Model and XML Data Model for
                                            Traceroute Measurements",
                                            RFC 5388, December 2008.

   [RFC5416]                                Calhoun, P., Montemurro, M.,
                                            and D. Stanley, "Control and
                                            Provisioning of Wireless
                                            Access Points (CAPWAP)
                                            Protocol Binding for IEEE
                                            802.11", RFC 5416,
                                            March 2009.

   [RFC5424]                                Gerhards, R., "The Syslog
                                            Protocol", RFC 5424,
                                            March 2009.

   [RFC5425]                                Miao, F., Ma, Y., and J.
                                            Salowey, "Transport Layer
                                            Security (TLS) Transport
                                            Mapping for Syslog",
                                            RFC 5425, March 2009.

   [RFC5426]                                Okmianski, A., "Transmission
                                            of Syslog Messages over
                                            UDP", RFC 5426, March 2009.

   [RFC5427]                                Keeni, G., "Textual
                                            Conventions for Syslog
                                            Management", RFC 5427,
                                            March 2009.

   [RFC5477]                                Dietz, T., Claise, B.,
                                            Aitken, P., Dressler, F.,
                                            and G. Carle, "Information
                                            Model for Packet Sampling
                                            Exports", RFC 5477,
                                            March 2009.

   [RFC5539]                                Badra, M., "NETCONF over
                                            Transport Layer Security
                                            (TLS)", RFC 5539, May 2009.

   [RFC5560]                                Uijterwaal, H., "A One-Way
                                            Packet Duplication Metric",
                                            RFC 5560, May 2009.

Ersue                    Expires April 28, 2011                [Page 50]

Internet-Draft          IETF Management Framework           October 2010

   [RFC5590]                                Harrington, D. and J.
                                            Schoenwaelder, "Transport
                                            Subsystem for the Simple
                                            Network Management Protocol
                                            (SNMP)", RFC 5590,
                                            June 2009.

   [RFC5591]                                Harrington, D. and W.
                                            Hardaker, "Transport
                                            Security Model for the
                                            Simple Network Management
                                            Protocol (SNMP)", RFC 5591,
                                            June 2009.

   [RFC5592]                                Harrington, D., Salowey, J.,
                                            and W. Hardaker, "Secure
                                            Shell Transport Model for
                                            the Simple Network
                                            Management Protocol (SNMP)",
                                            RFC 5592, June 2009.

   [RFC5608]                                Narayan, K. and D. Nelson,
                                            "Remote Authentication
                                            Dial-In User Service
                                            (RADIUS) Usage for Simple
                                            Network Management Protocol
                                            (SNMP) Transport Models",
                                            RFC 5608, August 2009.

   [RFC5674]                                Chisholm, S. and R.
                                            Gerhards, "Alarms in
                                            Syslog", RFC 5674,
                                            October 2009.

   [RFC5675]                                Marinov, V. and J.
                                            Schoenwaelder, "Mapping
                                            Simple Network Management
                                            Protocol (SNMP)
                                            Notifications to SYSLOG
                                            Messages", RFC 5675,
                                            October 2009.

   [RFC5676]                                Schoenwaelder, J., Clemm,
                                            A., and A. Karmakar,
                                            "Definitions of Managed
                                            Objects for Mapping SYSLOG
                                            Messages to Simple Network
                                            Management Protocol (SNMP)

Ersue                    Expires April 28, 2011                [Page 51]

Internet-Draft          IETF Management Framework           October 2010

                                            Notifications", RFC 5676,
                                            October 2009.

   [RFC5706]                                Harrington, D., "Guidelines
                                            for Considering Operations
                                            and Management of New
                                            Protocols and Protocol
                                            Extensions", RFC 5706,
                                            November 2009.

   [RFC5713]                                Moustafa, H., Tschofenig,
                                            H., and S. De Cnodder,
                                            "Security Threats and
                                            Security Requirements for
                                            the Access Node Control
                                            Protocol (ANCP)", RFC 5713,
                                            January 2010.

   [RFC5717]                                Lengyel, B. and M.
                                            Bjorklund, "Partial Lock
                                            Remote Procedure Call (RPC)
                                            for NETCONF", RFC 5717,
                                            December 2009.

   [RFC5833]                                Shi, Y., Perkins, D.,
                                            Elliott, C., and Y. Zhang,
                                            "Control and Provisioning of
                                            Wireless Access Points
                                            (CAPWAP) Protocol Base MIB",
                                            RFC 5833, May 2010.

   [RFC5834]                                Shi, Y., Perkins, D.,
                                            Elliott, C., and Y. Zhang,
                                            "Control and Provisioning of
                                            Wireless Access Points
                                            (CAPWAP) Protocol Binding
                                            MIB for IEEE 802.11",
                                            RFC 5834, May 2010.

   [RFC5835]                                Morton, A. and S. Van den
                                            Berghe, "Framework for
                                            Metric Composition",
                                            RFC 5835, April 2010.

   [RFC5848]                                Kelsey, J., Callas, J., and
                                            A. Clemm, "Signed Syslog
                                            Messages", RFC 5848,
                                            May 2010.

Ersue                    Expires April 28, 2011                [Page 52]

Internet-Draft          IETF Management Framework           October 2010

   [RFC5851]                                Ooghe, S., Voigt, N.,
                                            Platnic, M., Haag, T., and
                                            S. Wadhwa, "Framework and
                                            Requirements for an Access
                                            Node Control Mechanism in
                                            Broadband Multi-Service
                                            Networks", RFC 5851,
                                            May 2010.

   [RFC5889]                                Baccelli, E. and M.
                                            Townsley, "IP Addressing
                                            Model in Ad Hoc Networks",
                                            RFC 5889, September 2010.

   [RFC5953]                                Hardaker, W., "Transport
                                            Layer Security (TLS)
                                            Transport Model for the
                                            Simple Network Management
                                            Protocol (SNMP)", RFC 5953,
                                            August 2010.

   [RFC6020]                                Bjorklund, M., "YANG - A
                                            Data Modeling Language for
                                            the Network Configuration
                                            Protocol (NETCONF)",
                                            RFC 6020, October 2010.

   [RFC6021]                                Schoenwaelder, J., "Common
                                            YANG Data Types", RFC 6021,
                                            October 2010.

   [RFC6022]                                Scott, M. and M. Bjorklund,
                                            "YANG Module for NETCONF
                                            Monitoring", RFC 6022,
                                            October 2010.

Appendix A.  New Work related to IETF Management Framework

A.1.  Energy Management (eman)

   Energy management (eman) is a new workgroup at IETF and will develop
   an energy management framework and standard track MIB documents,
   which are potentially relevant for the Smart Grid environment.

   Energy management is already an additional requirement for network
   management systems due to several factors including the rising energy
   costs, the increased awareness of the ecological impact of operating
   networks and devices, and the regulation of governments.  The basic

Ersue                    Expires April 28, 2011                [Page 53]

Internet-Draft          IETF Management Framework           October 2010

   objective of energy management is operating communication networks
   and other equipments with a minimal amount of energy while still
   providing sufficient performance to meet service level objectives.

   There are very few IETF documents on energy management discussing the
   areas of power monitoring, energy monitoring, and power state
   control.  IETF started working on MIB modules for monitoring energy
   consumption and power states of energy-aware devices.  However, it
   has been found that a new framework for energy management is
   necessary to address known issues sufficiently.

   A concrete issue, which needs to be addressed, is the differentiation
   between devices reporting energy consumption and remote devices for
   which monitoring information is provided.  One usage scenario is
   power state control of remote devices, for example, at a PoE sourcing
   device that switches on and off power at its ports.  Another example
   scenario for energy management is a gateway to low resourced and
   lossy network devices in a wireless building network.

   The EMAN workgroup will work on the management of energy-aware
   devices covering following standard track WG items:

   Energy-aware Networks and Devices MIB document:
      Focus on monitoring energy-aware networks and devices addressing
      device identification, context information, and potential
      relationship between reporting devices, remote devices, and
      monitoring probes.

   Power and Energy Monitoring MIB document:
      Managed objects for monitoring of power states and energy
      consumption/production including retrieving of power states,
      properties of power states, current power state, power state
      transitions, and power state statistics.

   Battery MIB document:
      Managed objects for battery monitoring, which will provide means
      for reporting detailed properties of the actual charge, age, and
      state of a battery and of battery statistics.

   The WG will furthermore provide following RFCs as a guidance for the
   development of standard track documents:

   Requirements for energy management:
      Specification of energy management properties that will allow
      networks and devices to become energy aware.

Ersue                    Expires April 28, 2011                [Page 54]

Internet-Draft          IETF Management Framework           October 2010

   Energy management framework:
      Extensions to current management framework required for energy
      management of IP-based network equipment including power and
      energy monitoring, power states, power state control, and
      potential power state transitions.

   Applicability statement:
      Description of applications that can use the energy framework and
      associated MIB modules and the discussion of relationships of the
      framework to other frameworks like Smart Grid and existing
      standards such as those from the IEC, ANSI, DMTF, and others.

   NOTE: We need Eman use cases.

Appendix B.  Open issues

   o  Some chapters are a bit bare and need a discussion of standard
      documents in this area.

   o  Usage scenarios need to be added and discussed for different RFCs.

   o  Co-existence and inter-operation of SNMP and NETCONF e.g. for
      joint monitoring via the same manager needs to be discussed.

   o  Is Experimental RFC3179 "Script MIB Extensibility Protocol" worth
      to discuss?

   o  Relevance to Smart Grid environment needs to be discussed in an

   o  An appendix is needed to discuss management in Smart Grid
      environment with a hierarchical architecture with different proxy
      entities with possible involvement of SNMP master-agent and sub-

   o  Management of constrained devices needs a discussion.  New work is
      available e.g. for optimized SNMP in 6LowPAN environment

   o  Discuss the potential gap for an optimized NETCONF for constrained

Ersue                    Expires April 28, 2011                [Page 55]

Internet-Draft          IETF Management Framework           October 2010

Author's Address

   Mehmet Ersue
   Nokia Siemens Networks
   St.-Martin-Strasse 53
   Munich  81541

   EMail: mehmet.ersue@nsn.com

Ersue                    Expires April 28, 2011                [Page 56]

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