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

Versions: 00 01 02 03

Network Working Group                                      M. Ersue, Ed.
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                          January 27, 2011
Expires: July 31, 2011


          An Overview of the IETF Network Management Standards
                  draft-ersue-opsawg-management-fw-03

Abstract

   This document gives an overview of the IETF network management
   standards 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.

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 July 31, 2011.

Copyright Notice

   Copyright (c) 2011 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 July 31, 2011                 [Page 1]


Internet-Draft          IETF Management Standards           January 2011


   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.  Scope and Target Audience  . . . . . . . . . . . . . . . .  4
     1.2.  Related Work . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Core Network Management Protocols  . . . . . . . . . . . . . .  7
     2.1.  Simple Network Management Protocol (SNMP)  . . . . . . . .  7
       2.1.1.  Architectural Principles of SNMP . . . . . . . . . . .  7
       2.1.2.  SNMP and its Versions  . . . . . . . . . . . . . . . .  8
       2.1.3.  Structure of Managed Information (SMI) . . . . . . . .  9
       2.1.4.  SNMP Security and Access Control Models  . . . . . . . 10
       2.1.5.  SNMP Transport Subsystem and Transport Models  . . . . 13
     2.2.  SYSLOG Protocol  . . . . . . . . . . . . . . . . . . . . . 15
     2.3.  IP Flow Information Export (IPFIX) and Packet Sampling
           (PSAMP) Protocols  . . . . . . . . . . . . . . . . . . . . 17
     2.4.  Network Configuration Protocol (NETCONF) . . . . . . . . . 19
       2.4.1.  YANG - NETCONF Data Modeling Language  . . . . . . . . 21
   3.  Management Protocols and Mechanisms with specific Focus  . . . 22
     3.1.  IP Address Management with Dynamic Host Configuration
           Protocol (DHCP)  . . . . . . . . . . . . . . . . . . . . . 23
     3.2.  IPv6 Network Operations  . . . . . . . . . . . . . . . . . 23
     3.3.  Policy-based Management  . . . . . . . . . . . . . . . . . 24
       3.3.1.  IETF Policy Framework  . . . . . . . . . . . . . . . . 24
       3.3.2.  Common Open Policy Service (COPS) and COPS Usage
               for Policy Provisioning (COPS-PR)  . . . . . . . . . . 25
     3.4.  IP Performance Metrics (IPPM)  . . . . . . . . . . . . . . 25
     3.5.  Remote Authentication Dial In User Service (RADIUS)  . . . 27
     3.6.  Diameter Base Protocol (DIAMETER)  . . . . . . . . . . . . 30
     3.7.  Control And Provisioning of Wireless Access Points
           (CAPWAP) . . . . . . . . . . . . . . . . . . . . . . . . . 33
     3.8.  Access Node Control Protocol (ANCP)  . . . . . . . . . . . 34
     3.9.  Ad-Hoc Network Autoconfiguration . . . . . . . . . . . . . 34
     3.10. Application Configuration Access Protocol (ACAP) . . . . . 34
     3.11. XML Configuration Access Protocol (XCAP) . . . . . . . . . 35
     3.12. Extensible Provision Protocol (EPP)  . . . . . . . . . . . 35
   4.  Proposed, Draft and Standard Level Data Models . . . . . . . . 36
     4.1.  Fault Management . . . . . . . . . . . . . . . . . . . . . 36
     4.2.  Configuration Management . . . . . . . . . . . . . . . . . 38
     4.3.  Accounting Management  . . . . . . . . . . . . . . . . . . 39
     4.4.  Performance Management . . . . . . . . . . . . . . . . . . 40
     4.5.  Security Management  . . . . . . . . . . . . . . . . . . . 42
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 43



Ersue                     Expires July 31, 2011                 [Page 2]


Internet-Draft          IETF Management Standards           January 2011


   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 43
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 44
   Appendix A.  New Work related to IETF Management Framework . . . . 59
     A.1.  Energy Management (EMAN) . . . . . . . . . . . . . . . . . 59
   Appendix B.  Open issues . . . . . . . . . . . . . . . . . . . . . 61
   Appendix C.  Change Log  . . . . . . . . . . . . . . . . . . . . . 61
     C.1.  02-03  . . . . . . . . . . . . . . . . . . . . . . . . . . 61
     C.2.  01-02  . . . . . . . . . . . . . . . . . . . . . . . . . . 61
     C.3.  00-01  . . . . . . . . . . . . . . . . . . . . . . . . . . 61








































Ersue                     Expires July 31, 2011                 [Page 3]


Internet-Draft          IETF Management Standards           January 2011


1.  Introduction

1.1.  Scope and Target Audience

   This document gives an overview of the IETF network management
   standards and summarizes existing and ongoing development of IETF
   standards-track network management protocols and data models.

   The target audience of the document are on the one hand IETF working
   groups, which aim to select appropriate standard management protocols
   and data models to address their management needs.  On the other hand
   the document can be used as an overview and guideline by non-IETF
   SDOs 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 requirements and to detect
   possible gaps.  Finally, this document is directed to all interested
   parties, which seek to get an overview of the current set of the IETF
   management protocols such as network administrators or new comers to
   IETF.

   Section 2 gives an overview of the IETF core network management
   standards with a special focus on Simple Network Management Protocol
   (SNMP), SYSLOG, IPFIX/PSAMP, and NETCONF.  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.

   This document mainly refers to Proposed, Draft or Full Standard
   documents at IETF (see [RFCSEARCH]).  As far as it is valuable Best
   Current Practice (BCP) documents are referenced.  In exceptional
   cases and if the document provides substantial guideline for standard
   usage or fills an essential gap, Experimental and Informational RFCs
   are noticed and ongoing work is mentioned.

   Note that IETF specifications must have "multiple, independent, and
   interoperable implementations" before they can be advanced to Draft
   Standard status.  An Internet or Full Standard (also referred as
   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 [RFC2026].

   Information on active and concluded IETF working groups (e.g.
   charters, documents and mail archive) can be found at [IETF-WGS].

   Note: The final document will not contain any references to Internet-
   Drafts.  Current references in the document are assumed to be
   published soon.



Ersue                     Expires July 31, 2011                 [Page 4]


Internet-Draft          IETF Management Standards           January 2011


   RFC Editor: Please delete the note above before publication.

1.2.  Related Work

   [I-D.baker-ietf-core] identifies the key protocols of the Internet
   Protocol Suite.  In analogy to [I-D.baker-ietf-core] this document
   gives an overview of the IETF network management standards and its
   usage scenarios.

   [RFC3535] "Overview of the 2002 IAB Network Management Workshop"
   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, even though 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.

   [RFC5706] "Guidelines for Considering Operations and Management of
   New Protocols and Extensions" 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.

   Note: This document uses the expired draft [I-D.ietf-opsawg-survey-
   management] as a starting point and enhances it with a special focus
   on the description of the IETF network management standards and
   management data models developed 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.3.  Terminology

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

   o  Agent: A software module that performs the network management
      functions requested by network management stations.  An agent
      module may be implemented in any network element that is to be
      managed, such as a host, bridge, or router.  The 'management
      server' in NETCONF terminology.





Ersue                     Expires July 31, 2011                 [Page 5]


Internet-Draft          IETF Management Standards           January 2011


   o  CLI: Command Line Interface.  A management interface that human
      administrators use to interact with networking equipment.

   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
      repository (see [RFC3444]).

   o  Event: An occurrence of something in the "real world".  Events can
      be indicated to managers through an event message or notification.

   o  FCAPS: Fault, Configuration, Accounting, Performance, Security.
      The five categories of management functionality defined by TMN.

   o  Information model: An abstraction and representation of entities
      in a managed environment, their properties, attributes and
      operations, and the way they relate to each other.  Independent of
      any specific repository, protocol, or platform (see [RFC3444]).

   o  Managed object: A management abstraction of a resource; a piece of
      management information in a MIB.  In the context of SNMP, a
      structured set of data variables that represent some resource to
      be managed or other aspect of a managed device.

   o  Manager: An entity that acts in a manager role, either a user or
      an application.  The counterpart to an agent.  A 'management
      client' in NETCONF terminology.

   o  Management Information Base (MIB): The definition of a related
      collection of objects that represent a collection of resources to
      be managed defined by using the modeling language SMI.

   o  MIB module: A MIB definition, typically for a particular network
      technology feature, that constitutes a subtree in an object
      identifier tree.  A MIB that is provided by a management agent is
      typically composed of multiple instantiated MIB modules.

   o  Modeling language: A modeling language is any artificial language
      that can be used to express information or knowledge or systems in
      a structure that is defined by a consistent set of rules.
      Examples are SMIv2, XSD, and YANG.

   o  Notification: An event message.

   o  Trap: An unsolicited message sent by an agent to a management
      station to notify an unusual event.






Ersue                     Expires July 31, 2011                 [Page 6]


Internet-Draft          IETF Management Standards           January 2011


2.  Core Network Management Protocols

2.1.  Simple Network Management Protocol (SNMP)

2.1.1.  Architectural Principles of SNMP

   As described in [RFC3410] the SNMPv3 Framework, builds upon both the
   original SNMPv1 and SNMPv2 framework.  The basic structure and
   components for the SNMP framework did not change between its versions
   and comprises following components:

   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 SNMP
   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 SNMP
   Management Framework:

   o  SNMPv3 protocol,

   o  the modeling language SMIv2, and

   o  MIB modules for different management issues.

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

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



Ersue                     Expires July 31, 2011                 [Page 7]


Internet-Draft          IETF Management Standards           January 2011


      and

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

2.1.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.  Typically, 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 a Trap PDU, an Inform message, a
   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]).

   [BCP74][RFC3584] "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.  Generally, standard MIB modules
   support common functionality in a device.  Based on this fact
   operators often define additional MIB modules for their enterprise or
   use other protocols such as a Command Line Interface (CLI) to
   configure non standard data in managed devices and their interfaces.

   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.




Ersue                     Expires July 31, 2011                 [Page 8]


Internet-Draft          IETF Management Standards           January 2011


   SNMP is widely used for monitoring fault and performance data and
   with its stateless nature SNMP also works well for status polling and
   determining the operational state of 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 liveliness, and to detect discontinuities in some
   counters.

   Some operators use SNMP for configuration in their environment (e.g.
   for DOCSIS based systems such as cable modems), while others find
   SNMP has a limited configuration management support.  Compared to
   SNMP, with its data-centric view, CLI has a task-oriented view where
   NETCONF follows the document-based view for configuration management.
   SNMP does not separate clearly between configuration data and
   operational state.  SMIv2 has limited support for structured data
   types and relationships among managed objects.

   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 only an Experimental RFC 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,
   message 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 diverse transport and link layer
   protocols, including TCP, UDP, Ethernet, OSI, and others (see
   Section 2.1.5.1).

2.1.3.  Structure of Managed Information (SMI)

   SNMP MIB modules are defined with the notation and grammar specified
   as the Structure of Managed Information (SMI), which uses an adapted
   subset of Abstract Syntax Notation One (ASN.1).

   The SMI is divided into three parts: module definitions, object
   definitions, and, notification definitions.

   o  Module definitions are used when describing information modules.
      An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the



Ersue                     Expires July 31, 2011                 [Page 9]


Internet-Draft          IETF Management Standards           January 2011


      semantics of an information module.

   o  Object definitions are used when describing managed objects.  An
      ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax
      and semantics of a managed object.

   o  Notification definitions are used when describing unsolicited
      transmissions of management information.  An ASN.1 macro,
      NOTIFICATION-TYPE, is used to concisely convey the syntax and
      semantics of a notification.

   Note that SMIv1 is outdated and shouldn't be used.

   SMIv2 is the new notation for managed information definition and
   should be used to define MIB modules.  SMIv2 is specified in
   following RFCs:

   o  [STD58][RFC2578] defines Version 2 of the Structure of Management
      Information (SMIv2),

   o  [STD58][RFC2579] defines common MIB "Textual Conventions",

   o  [STD58][RFC2580] defines Conformance Statements and requirements
      for defining agent and manager capabilities, and

   o  [RFC3584] defines the mapping rules for and the conversion of MIB
      documents between SMIv1 and SMIv2 formats.

2.1.4.  SNMP Security and Access Control Models

2.1.4.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 can 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
      object.





Ersue                     Expires July 31, 2011                [Page 10]


Internet-Draft          IETF Management Standards           January 2011


   Masquerade:
      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
      authorizations.

   Secondary threats against which any Security Model used within this
   architecture can 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.

   Disclosure:
      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
      management stations - and therefore there is no significant
      advantage afforded by protecting against traffic analysis.

2.1.4.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 principal and secondary threats discussed in



Ersue                     Expires July 31, 2011                [Page 11]


Internet-Draft          IETF Management Standards           January 2011


   Section 2.1.4.1.

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

   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.

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

2.1.4.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
      MIB.

   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:



Ersue                     Expires July 31, 2011                [Page 12]


Internet-Draft          IETF Management Standards           January 2011


   groups, security level, contexts, MIB views, and access policy.
   Access to a MIB is controlled by means of a MIB view.  The
   vacmAccessTable maps the group name, security information, the
   context, and the message type (read, write, or notification) into
   three MIB views for read, write, or notification access, which are
   used to determine whether a managed object is allowed to access.

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

2.1.5.  SNMP Transport Subsystem and Transport Models

   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.

2.1.5.1.  SNMP Transport Security Model

   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



Ersue                     Expires July 31, 2011                [Page 13]


Internet-Draft          IETF Management Standards           January 2011


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

   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
   [RFC5424] and NETCONF [RFC4741], use a secure transport layer to
   provide secure information and message exchange to build management
   applications.

   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.1.5.2.  RADIUS Authentication and Authorization with SNMP Transport
          Models

   [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



Ersue                     Expires July 31, 2011                [Page 14]


Internet-Draft          IETF Management Standards           January 2011


   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
   Integrated Security Model for SNMP (ISMS) working group.

2.2.  SYSLOG Protocol

   SYSLOG is a mechanism for distribution of logging information
   initially used on Unix systems.  IETF documented the status quo of
   the BSD SYSLOG protocol in the Informational [RFC3164].  The IETF
   SYSLOG protocol [RFC5424] obsoletes [RFC3164] and introduces a
   layered architecture allowing the use of any number of transport
   protocols, including reliable transports and secure transports, for
   transmission of SYSLOG messages.

   The content of BSD SYSLOG messages 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
   SYSLOG protocol [RFC5424] includes structured data elements to aid
   application-parsing.

   The SYSLOG protocol enables a machine to send system log messages
   across networks to event message collectors.  The protocol is simply
   designed to transport and distribute these event messages.  No
   acknowledgement of the receipt is made.  The SYSLOG protocol and
   process does not require a stringent coordination between the
   transmitters and the receivers.  Indeed, the transmission of SYSLOG
   messages may be started on a device without a receiver being



Ersue                     Expires July 31, 2011                [Page 15]


Internet-Draft          IETF Management Standards           January 2011


   configured, or even actually physically present.  Conversely, many
   devices will most likely be able to receive messages without explicit
   configuration or definitions.  This simple approach aided the
   deployment of SYSLOG.

   BSD SYSLOG had little uniformity for the message format and the
   content of SYSLOG messages.  The IETF has standardized a new message
   header format, including timestamp, hostname, application, and
   message ID, to improve filtering, interoperability and correlation
   between compliant implementations.

   The SYSLOG protocol further introduces a mechanism for defining
   Structured Data Elements (SDEs).  The SDEs allow 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.  [RFC5674] defines the way alarms are sent
   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.

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

   [RFC3195] describes mappings of the syslog protocol to TCP
   connections, useful for reliable delivery of event messages.  As such
   the specification provides robustness and security in message
   delivery with encryption and authentication over a connection-
   oriented protocol that is unavailable to the usual UDP-based syslog
   protocol.

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

   IETF working groups are encouraged to standardize structured data
   elements, extensible human-friendly text, and consistent facility/



Ersue                     Expires July 31, 2011                [Page 16]


Internet-Draft          IETF Management Standards           January 2011


   severity values for SYSLOG to report events specific to their
   protocol.

   For information on SYSLOG related MIB modules see Section 4.1.

2.3.  IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP)
      Protocols

   The IPFIX protocol [RFC5101], IP Flow Information eXport, is a
   Proposed Standard, which defines a push-based data export mechanism
   for formatting and transferring IP flow information in a compact
   binary format from an exporter to a collector.

   The IPFIX architecture [RFC5470] defines components involved in IP
   flow measurement and reporting of information on IP flows,
   particularly, a metering process generating flow records, an
   exporting process that sends metered flow information using the IPFIX
   protocol, and a colleting process that receives flow information as
   IPFIX data records.

   The IPFIX protocol and the IPFIX architecture have been specified
   following the collected requirements in [RFC3917].

   IPFIX can run over different transport protocols.  The IPFIX protocol
   [RFC5101] specifies SCTP as the mandatory transport protocol to
   implement.  SCTP is used with its Partial Reliability extension (PR-
   SCTP) specified in [RFC3758].  Optional alternatives are TCP and UDP.
   [I-D.ietf-ipfix-export-per-sctp-stream] specifies an extension for
   IPFIX over SCTP.

   IPFIX transmits IP flow information in data records containing IPFIX
   Information Elements (IEs) defined by the IPFIX information model
   [RFC5102].  IPFIX information elements are quantities with unit and
   semantics defined by the information model.  When transmitted over
   the IPFIX protocol, only their values need to be carried in data
   records.  This compact encoding allows efficient transport of large
   numbers of measured flow values.  Remaining redundancy in data
   records can be further reduced by methods described in [RFC5473] (for
   further discussion on IPFIX IEs see Section 4).

   The IPFIX information model is extensible.  New information elements
   can be registered at IANA (see 'IPFIX Information Elements' in [IANA-
   PROT]).  IPFIX also supports the use of proprietary, i.e. enterprise-
   specific information elements.

   The PSAMP protocol [RFC5476] extends the IPFIX protocol by means for
   formatting and transferring information on individual packets.
   [RFC5475] specifies a set of sampling and filtering techniques for IP



Ersue                     Expires July 31, 2011                [Page 17]


Internet-Draft          IETF Management Standards           January 2011


   packet selection and the PSAMP information model [RFC5477] provides a
   set of basic information elements for reporting packet information
   with the IPFIX/PSAMP protocol.

   The IPFIX model of an IP traffic flow is uni-directional.  [RFC5103]
   adds means to IPFIX for reporting bi-directional flows, for example
   both directions of packet flows of a TCP connection.

   When enterprise-specific information elements are transmitted with
   IPFIX, a collector receiving data records may not know the type of
   received data and cannot choose the right format for storing the
   contained information.  [RFC5610] provides means for providing type
   information of enterprise-specific information Elements from an
   exporter to a collector.

   Collectors may store received flow information in files.  The IPFIX
   file format [RFC5655] can be used for storing IP flow information in
   a way that facilitates exchange of traffic flow information between
   different systems and applications.

   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 (see the problem statement in [RFC5982]).

   The 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-framework].

   Examples for mediation functions are flow aggregation, flow selection
   [I-D.ietf-ipfix-flow-selection-tech], and anonymization of traffic
   information [I-D.ietf-ipfix-anon].

   Privacy, integrity, and authentication of exporter and collector are
   important security requirements for IPFIX [RFC3917].  The IPFIX and
   PSAMP protocol do not define any new security mechanisms, but rely on
   security mechanisms of the underlying protocols, such as, for
   example, TLS [RFC5246] and DTLS [RFC4347] [I-D.ietf-tsvwg-dtls-for-
   sctp].

   Several applications such as usage-based accounting, traffic
   profiling, traffic engineering, intrusion detection, and QoS
   monitoring, that require flow-based traffic measurements can be
   realized using IPFIX.



Ersue                     Expires July 31, 2011                [Page 18]


Internet-Draft          IETF Management Standards           January 2011


   With further information elements, IPFIX can also be applied to
   monitoring application-level protocols, for example, SIP [RFC3261]
   and related media transfer protocols.  Requirements to such a
   monitoring on the application level include 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).

   Note that even if the initial IPFIX focus has been around IP flow
   information exchange, non IP-related information elements are now
   specified in IPFIX IANA registration (e.g.  MAC address, MPLS labels,
   etc.).  At the time of this writing, there are requests to widen the
   focus of IPFIX and to export also non-IP related information elements
   (such as SIP monitoring IEs).

   For information on IPFIX/PSAMP related data models see Section 4.1
   and Section 4.2.

2.4.  Network Configuration Protocol (NETCONF)

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

   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
      state,

   o  Distribution of configurations to devices under transactional
      constraints,

   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,





Ersue                     Expires July 31, 2011                [Page 19]


Internet-Draft          IETF Management Standards           January 2011


   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
   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.  In addition, applications can access both
   the syntactic and semantic content of the device's native user
   interface.

   NETCONF working group 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 also transport alarms from other sources, where
   the originator of the 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 working group also defined the necessary data model to
   monitor the NETCONF protocol by using YANG [RFC6022] (see
   Section 4.1).

   NETCONF working group 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
   [RFC5381].

   Currently NETCONF working group is focusing on bug fixing of the
   NETCONF base protocol standard [I-D.draft-ietf-netconf-4741bis] and
   the SSH transport protocol mapping [I-D.draft-ietf-netconf-4742bis]
   as well as the specification of the NETCONF Access Control Model



Ersue                     Expires July 31, 2011                [Page 20]


Internet-Draft          IETF Management Standards           January 2011


   (NACM).  NACM is going to provide a secure operating environment for
   NETCONF and proposes standard mechanisms to restrict protocol access
   to particular users with a pre-configured subset of operations and
   content.

2.4.1.  YANG - NETCONF Data Modeling Language

   Following the guideline and requests of the IAB management workshop
   [RFC3535], the NETMOD working group developed a data modeling
   language defining the semantics of operational and configuration
   data, notifications, and operations [RFC6020].  The new data modeling
   language maps directly to XML encoded content (on the wire) and will
   serve as the normative description of NETCONF data models.

   YANG has following properties addressing specific requirements on a
   modeling language for configuration management:

   o  YANG provides the means to define hierarchical data models.  It
      supports reusable data types and groupings, i.e., a set of schema
      nodes that can be reused across module boundaries.

   o  YANG supports the distinction between configuration and state
      data.  In addition, it provides support for modeling event
      notifications and the specification of operations that extend the
      base NETCONF operations.

   o  YANG allows to express constraints on data models by means of type
      restrictions and XPATH 1.0 [XPATH] expressions.  XPATH expressions
      can also be used to make certain portions of a data model
      conditional.

   o  YANG supports the integration of standard and vendor defined data
      models.  YANG's augmentation mechanism allows to seamlessly
      augment standard data models with proprietary extensions.

   o  YANG data models can be partitioned into collections of features,
      allowing low-end devices to only implement the core features of a
      data model while high-end devices may choose to support all
      features.  The supported features are announced via the NETCONF
      capability exchange to management applications.

   o  The syntax of the YANG language is compact and optimized for human
      readers.  An associated XML-based syntax called the YANG
      Independent Notation (YIN) [RFC6020] is available to allow the
      processing of YANG data models with XML-based tools.  The mapping
      rules for the translation of YANG data models into Document Schema
      Definition Languages (DSDL), of which Relax NG is a major
      component, are defined in [I-D.draft-ietf-netmod-dsdl-map].



Ersue                     Expires July 31, 2011                [Page 21]


Internet-Draft          IETF Management Standards           January 2011


   o  Devices implementing standard data models can document deviations
      from the data model in separate YANG modules.  Applications
      capable of discovering deviations can make allowances that would
      otherwise not be possible.

   A collection of common data types for IETF-related standards is
   provided in [RFC6021].  This standard data type library has been
   derived to a large extend from common SMIv2 data types, generalizing
   them to a less constrained NETCONF framework where necessary.

   The document "An Architecture for Network Management using NETCONF
   and YANG" describes how NETCONF and YANG can be used to build network
   management applications that meet the needs of network operators
   [I-D.draft-ietf-netmod-arch].

   The Experimental RFC [I-D.draft-linowski-netmod-yang-abstract]
   specifies extensions for YANG introducing language abstractions such
   as class inheritance and recursive data structures.

   Work is underway to standardize a translation of SMIv2 data models
   into YANG data models, which preserves investments into SNMP MIB
   modules, which are widely available for monitoring purposes.

   Several independent and open source implementations of the YANG data
   modeling language and associated tools are available.  The IETF has
   also developed guidelines [I-D.draft-ietf-netmod-yang-usage] for the
   use of YANG within standardization organizations such as the IETF.

   While YANG is a relatively recent language, some data models have
   already been produced.  IPFIX working group prepared the normative
   model for configuring and monitoring IPFIX and PSAMP compliant
   monitoring devices using the YANG modeling language
   [I-D.draft-ietf-ipfix-configuration-model].  The specification of the
   base NETCONF protocol operations has been revised and uses YANG as
   the normative modeling language to specify its operations
   [I-D.draft-ietf-netconf-4741bis].

   At the time of this writing NETMOD working group is developing core
   system and interface data models.  Following the example of IPFIX
   configuration model, working groups at IETF will prepare models for
   their specific needs.

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 Proposed Standard status or higher within the IETF.



Ersue                     Expires July 31, 2011                [Page 22]


Internet-Draft          IETF Management Standards           January 2011


3.1.  IP Address Management with Dynamic Host Configuration Protocol
      (DHCP)

   The Draft Standard Dynamic Host Configuration Protocol (DHCP)
   [RFC2131] was defined as an extension to BOOTP (Bootstrap Protocol)
   [RFC0951].  DHCP provides a framework for passing configuration
   information to hosts on a TCP/IP network and enables as such auto-
   configuration 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
   protocols.

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

   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.

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.

   o  The Proposed Standard [RFC4213] specifies IPv4 compatibility
      mechanisms for dual stack and configured tunneling that can be



Ersue                     Expires July 31, 2011                [Page 23]


Internet-Draft          IETF Management Standards           January 2011


      implemented by IPv6 hosts and routers.  Dual stack implies
      providing complete implementations of both IPv4 and IPv6, and
      configured tunneling provides a means to carry IPv6 packets over
      unmodified IPv4 routing infrastructures.

   o  [RFC3574] lists different scenarios in 3GPP defined packet network
      that would need IPv6 and IPv4 transition, where [RFC4215] does a
      more detailed analysis of the transition scenarios that may come
      up in the deployment phase of IPv6 in 3GPP packet networks.

   o  [RFC4029] describes and analyzes different scenarios for the
      introduction of IPv6 into an ISP's existing IPv4 network.
      [RFC5181] provides a detailed description of IPv6 deployment,
      integration methods and scenarios in wireless broadband access
      networks (802.16) in coexistence with deployed IPv4 services.
      [RFC4057] describes the scenarios for IPv6 deployment within
      enterprise networks.

   o  [RFC4038] specifies scenarios and application aspects of IPv6
      transition considering how to enable IPv6 support in applications
      running on IPv6 hosts, and giving guidance for the development of
      IP version-independent applications.

   NOTE: Additional input needed.

3.3.  Policy-based Management

3.3.1.  IETF Policy Framework

   IETF specified a general policy framework [RFC2753] for managing,
   sharing, and reusing policies in a vendor independent, interoperable,
   and scalable manner.  [RFC3460] specifies the Policy Core Information
   Model (PCIM), an object-oriented information model for representing
   policy information developed jointly in the IETF Policy Framework
   working group and as extensions to the Common Information Model (CIM)
   activity in the Distributed Management Task Force (DMTF) [DMTF-CIM].

   The policy framework is based on a policy-based admission control
   specifying two main architectural elements, the Policy Enforcement
   Point (PEP) and the Policy Decision Point (PDP).  For the purpose of
   network management, policies allow an operator to specify how the
   network is to be configured and monitored by using 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 has been accepted by the industry as a
   standard-based policy approach and has been adopted by different SDOs



Ersue                     Expires July 31, 2011                [Page 24]


Internet-Draft          IETF Management Standards           January 2011


   e.g. for 3GGP charging standards.

3.3.2.  Common Open Policy Service (COPS) and COPS Usage for Policy
        Provisioning (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 [RFC2748] for provisioning
   of policy information.  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).  Policy data is modeled using
   Policy Information Base modules (PIB modules).

   COPS-PR has not been widely deployed, 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 the 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, even if COPS-PR and the Structure of Policy Provisioning
   Information (SPPI) were initially approved as Proposed Standards, the
   IESG has not approved any policy models (PIB modules) as IETF
   standard, and the use of COPS-PR is not recommended.

3.4.  IP Performance Metrics (IPPM)

   The IPPM working group has defined metrics for accurately measuring
   and reporting the quality, performance, and reliability of Internet
   data delivery.  The metrics include connectivity, one-way delay and
   loss, round-trip delay and loss, delay variation, loss patterns,
   packet reordering, bulk transport capacity, and link bandwidth
   capacity.

   These metrics are designed for use by network operators and their
   customers, and provide unbiased quantitative measures of performance.
   The IPPM metrics have been developed inside an active measurement
   context, that is, the devices used to measure the metrics produce
   their own traffic.  However, most of the metrics can be used inside a
   passive context as well.  At the time of this writing there is no
   work planned in the area of passive measurement.

   The main properties of individual IPPM performance and reliability
   metrics are that the metrics should be well-defined and concrete thus



Ersue                     Expires July 31, 2011                [Page 25]


Internet-Draft          IETF Management Standards           January 2011


   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 the Metro Ethernet
   Forum.

   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 working group 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.

   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.





Ersue                     Expires July 31, 2011                [Page 26]


Internet-Draft          IETF Management Standards           January 2011


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

   Next to the metrics, two protocols to measure these metrics have been
   standardized:

   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.

   o  [RFC3432] 'Network performance measurement with Periodic Streams'
      describes a periodic sampling method and relevant metrics for
      assessing the performance of IP networks, as an alternative to the
      Poisson sampling method described in [RFC2330].

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

3.5.  Remote Authentication Dial In User Service (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.  The companion document
   [RFC2866] 'Radius Accounting' describes a protocol for carrying
   accounting information between a network access server and a shared
   accounting server.  [RFC2867] adds required new RADIUS accounting
   attributes and new values designed to support the provision of
   tunneling in dial-up networks.

   RADIUS 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 also has a strong position in fixed broadband access provider
   networks and well as in certain cellular broadband operators'
   networks.

   RADIUS is extensible with a known limitation of maximum 255 attribute
   codes and 253 octets as attribute content length.  RADIUS has Vendor-
   Specific Attributes (VSA), which have been used both for vendor-
   specific purposes as an addition to standardized attributes as well
   as to extend the limited attribute code space.  IETF has been working



Ersue                     Expires July 31, 2011                [Page 27]


Internet-Draft          IETF Management Standards           January 2011


   on for a solution to extend the attribute space beyond 255 and
   allowing attributes longer than 253 octets.  A recent proposal
   [I-D.dekok-radext-radius-extensions] would extend the 'conventional'
   attribute space up to ~1000 attributes and add another ~500 'long'
   attributes with a length bound by the RADIUS packet size.  As side
   product, the attribute extension also introduces a new RADIUS
   attribute type Type-Length-Value (TLV) in a similar fashion as
   Diameter AVPs (see [RFC3588]).  TLVs allow grouping and nesting of
   attributes in a similar way as Diameter Grouped AVPs.

   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
   traffic.  However, building and administering large IPsec protected
   networks may become a management burden, especially when IPsec
   protected RADIUS infrastructure should provide inter-provider
   connectivity.  A trend has been moving towards TLS-based security
   solutions and establishing dynamic trust relationships between RADIUS
   servers.  Once TCP transport was introduced to RADIUS, it became
   natural to have a TLS support for RADIUS [I-D.ietf-radext-radsec].
   In addition to TLS-based security for TCP transport, the UDP
   transport also has Datagram TLS (DTLS) based security solution
   [I-D.ietf-radext-dtls].

   Once the 'flavors' of different RADIUS servers/proxies increase, a
   mechanism to discover RADIUS servers/proxies dynamically in a desired
   realm based on their transport and security properties becomes
   topical.  A DNS based dynamic discovery, equivalent to DIAMETER
   [RFC3588], is under development [I-D.ietf-radext-dynamic-discovery].
   Naturally, piggy-packing RADIUS realm information in DNS
   infrastructure would add a new area for general management and
   administration.  This is specifically something new as, for example,
   previously RADIUS realm and realm-based routing information has been
   completely separate from DNS namespace.

   [RFC2868] 'RADIUS Attributes for Tunnel Protocol Support' defines a
   number of RADIUS attributes designed to support the provision
   compulsory of tunneling in dial-up network access.  Some applications
   involve compulsory tunneling i.e. the tunnel is created without any
   action from the user and without allowing the user any choice in the
   matter.  In order to provide this functionality, specific RADIUS
   attributes are needed to carry the tunneling information from the
   RADIUS server to the tunnel end points.  RFC 3868 defines those
   attributes, attribute values and the required IANA registries.

   [RFC3162] 'RADIUS and IPv6' specifies the operation of RADIUS over
   IPv6 and the RADIUS attributes used to support the IPv6 network
   access.  [RFC4818] describes how to transport delegated IPv6 prefix



Ersue                     Expires July 31, 2011                [Page 28]


Internet-Draft          IETF Management Standards           January 2011


   information over RADIUS

   [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.  People designing
   extensions to RADIUS protocol for various deployment cases should get
   familiar with RADIUS Design Guidelines [I-D.ietf-radext-design] in
   order to avoid e.g. known interoperability challenges.

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

   [RFC5607] specifies required RADIUS attributes and their values for
   authorizing a management access to a NAS.  Both local and remote
   management are supported, with access rights and management
   privileges.  Specific provisions are made for remote management via
   Framed Management protocols, such as SNMP and NETCONF, and for
   management access over a secure transport protocols.

   [RFC3579] describes how to use RADIUS to convey EAP payload between
   the authenticator and the EAP server using RADIUS.  RFC3579 is widely
   implemented, for example, in WLAN and 802.1X environment.  [RFC3580]
   describes how to use RADIUS with IEEE 802.1X authenticators.  In the
   context of 802.1X and EAP-based authentication, the Vendor Specific
   Attributes described in [RFC2458] have been widely accepted by the
   industry.  [RFC2869] 'RADIUS extensions' is another important RFC
   related to EAP use.  RFC2869 describes additional attributes for
   carrying AAA information between a NAS and a shared Accounting Server
   using RADIUS.  It also defines attributes to encapsulate EAP message
   payload.

   There are an extensive number of MIB modules defined for multiple
   purposes to use with RADIUS (see Section 4.3 and Section 4.5 ).

   RADIUS is catching up DIAMETER (see [RFC3588]) functionality wise.



Ersue                     Expires July 31, 2011                [Page 29]


Internet-Draft          IETF Management Standards           January 2011


   However, it should be noted that newly introduced features such as
   TCP-based transport, extended attributes or new security features are
   not yet widely implemented, and are unlikely to be upgraded to the
   deployed legacy in a near future.

3.6.  Diameter Base Protocol (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, well documented functions for proxy, redirect and relay
   agent functions, 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 (as defined in [RFC2865]) are:

   o  Use of reliable transport protocols (TCP or SCTP, not UDP),

   o  Network and transport layer security (IPsec or TLS),

   o  Stateful and stateless models,

   o  Dynamic discovery of peers (using DNS SRV and NAPTR),

   o  Concept of an application that describes how a specific set of
      commands and Attribute-Value Pairs (AVPs) are treated by DIAMETER
      nodes.  Each application has an IANA assigned unique identifier,

   o  Supports application layer acknowledgements, defines failover
      methods and state machines [RFC3539] ??? ,

   o  Error notification,

   o  Better roaming support,

   o  Easier to extend, and




Ersue                     Expires July 31, 2011                [Page 30]


Internet-Draft          IETF Management Standards           January 2011


   o  Basic support for user-sessions and accounting.

   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 unique IANA assigned application
   identifier and can add new command codes and/or new mandatory AVPs.

   The DIAMETER application identifier space has been divided into
   Standards Track and First Come First Served vendor-specific
   applications.  Following are the current Standards Track, IETF
   defined, DIAMETER applications:

   o  Diameter Base Protocol Application [RFC3588],

   o  Diameter Base Accounting Application [RFC3588],

   o  Diameter Mobile IPv4 Application [RFC4004],

   o  Diameter Network Access Server Application (NASREQ, [RFC4005]),

   o  Diameter Extensible Authentication Protocol Application [RFC4072],

   o  Diameter Credit-Control Application [RFC4006],

   o  Diameter Session Initiation Protocol Application [RFC4740], and

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

   o  Diameter Mobile IPv6 IKE (MIP6I) Application [RFC5778].

   o  Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778].

   o  Diameter Relay Agent Application [RFC3588].

   The large majority of DIAMETER applications are vendor-specific and
   mainly used in various Standards Development Organizations (SDO)
   outside IETF.  One example of an important SDO extensively using
   DIAMETER is 3GPP.  For example the whole 3GPP IP Multimedia Subsystem
   (IMS) uses DIAMETER based interfaces (e.g.  Cx) [3GPPIMS].  Recently,
   during the standardization of the 3GPP Evolved Packet Core, DIAMETER
   was chosen as the only AAA signaling protocol.

   One part of the DIAMETER extensibility mechanism is an easy and
   consistent way of creating new commands for applications need.
   RFC3588 proposes 'IETF Consensus' as the IANA policy for the DIAMETER
   command code allocations, which requires an RFC to pass through the



Ersue                     Expires July 31, 2011                [Page 31]


Internet-Draft          IETF Management Standards           January 2011


   IETF publication process.  This policy decision caused undesired use
   and redefinition of existing Commands Codes within SDOs.  Secondly,
   diverse RFCs have been published as simple command code allocations
   for other SDO purposes (see [RFC3589], [RFC5224], [RFC5431] and
   [RFC5516]).  Later, the Command Code IANA policy has been changed in
   [RFC5719], which added a range for vendor-specific Command Codes with
   a First Come First Served policy.

   The implementation and deployment experience of DIAMETER has led to
   the development of an update of the Base protocol (RFC3588bis)
   [I-D.ietf-dime-rfc3588bis].  One of the major changes is making
   transport layer security (TLS) as the preferred security mechanism
   and deprecating the in-band security negotiation for TLS.

   Some DIAMETER extensions and clarifications that logically would fit
   better into RFC3588bis are also needed on the existing RFC3588 based
   deployments.  Therefore, some extensions specifically usable in large
   inter-provider roaming network settlements are made available for
   both RFC3588 (updates) and RFC3588bis (part of the document set):

   o  'Clarifications on the Routing of Diameter Requests Based on the
      Username and the Realm' [RFC5729] defines the behavior required
      for 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 realms.

   o  'Diameter Extended NAPTR' [I-D.ietf-dime-extended-naptr] describes
      an improved DNS-based dynamic DIAMETER Agent discovery mechanism.
      Using an extended format for the Straightforward-NAPTR (S-NAPTR)
      Application Service Tag allows a DNS-based discovery of DIAMETER
      agents of the supported applications without doing DIAMETER
      capability exchange beforehand with a number of agents.

   Experience has shown, that it is hard for IETF to develop DIAMETER
   applications that actually get adopted and deployed by other SDOs.
   As a result, there has been a growing number of IETF defined DIAMETER
   framework documents that basically are just a collection of AVPs for
   a specific purpose or system architecture with semantical AVP
   descriptions and logic for "imaginary" applications.  It is not
   entirely clear whether such practice is worthwhile in the long run.
   From IETF point of view, this practice allows the development of
   larger 'system architecture' documents that do not need to reference
   AVPs or application logic outside IETF.  Below are examples of few
   recent AVP and framework documents:





Ersue                     Expires July 31, 2011                [Page 32]


Internet-Draft          IETF Management Standards           January 2011


   o  'Diameter Mobile IPv6: Support for Network Access Server to
      Diameter Server Interaction' [RFC5447] 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 interface.

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

   o  'Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local
      Mobility Anchor Interaction with Diameter Server' [RFC5779]
      defines AAA interactions between Proxy Mobile IPv6 (PMIPv6)
      entities (both Mobile Access Gateway and Local Mobility Anchor)
      and a AAA server within a PMIPv6 Domain.  These AAA interactions
      are primarily used to download and update mobile node specific
      policy profile information between PMIPv6 entities and a remote
      policy store.

   For information on DIAMETER related MIB modules see Section 4.5.

3.7.  Control And Provisioning of Wireless Access Points (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
   working group 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
   control plane including the primitives to control data access.  The
   protocol document also specifies 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 prepared to be independent of Layer 2
   technologies, and meets the objectives in "Objectives for Control and
   Provisioning of Wireless Access Points (CAPWAP)" [RFC4564].  Separate



Ersue                     Expires July 31, 2011                [Page 33]


Internet-Draft          IETF Management Standards           January 2011


   binding extensions enable the use with additional wireless
   technologies.  [RFC5416] defines CAPWAP Protocol Binding for IEEE
   802.11.

   For information on CAPWAP related MIB modules see Section 4.2.

3.8.  Access Node Control Protocol (ANCP)

   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.9.  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 working
   group 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
   support multi-hop communication by running MANET routing protocols as
   developed by the IETF MANET working group.

   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.10.  Application Configuration Access Protocol (ACAP)

   The Application Configuration Access Protocol (ACAP) [RFC2244] is a
   Proposed Standard protocol designed to support remote storage and
   access of program option, configuration and preference information.



Ersue                     Expires July 31, 2011                [Page 34]


Internet-Draft          IETF Management Standards           January 2011


   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 use any network-connected computer, run any ACAP-enabled
   application and have access to their own configuration data.  To
   enable wide usage client simplicity has been preferred to server or
   protocol simplicity whenever reasonable.

3.11.  XML Configuration Access Protocol (XCAP)

   The Extensible Markup Language (XML) Configuration Access Protocol
   (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
   one.

3.12.  Extensible Provision Protocol (EPP)

   The Extensible Provision Protocol [RFC5730] is a Full 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



Ersue                     Expires July 31, 2011                [Page 35]


Internet-Draft          IETF Management Standards           January 2011


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

4.  Proposed, Draft and Standard Level Data Models

   This section lists management data models standardized at IETF, which
   can be reused and applied to different solutions.  The different data
   models covered in this section are MIB modules, IPFIX Information
   Elements, Syslog Structured Data Elements, and YANG modules.

   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
   Proposed Standard status at the IETF.  In exceptional cases important
   Informational RFCs are referred.

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.

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

   Proposed Standards:




Ersue                     Expires July 31, 2011                [Page 36]


Internet-Draft          IETF Management Standards           January 2011


   DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982]
   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 mechanism 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-
   X733).

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

   Other MIB modules that may be applied to fault management with SNMP
   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.

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

   The SYSLOG protocol document defines an initial set of Structured
   Data Elements (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.

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

   An IPFIX MIB module [RFC5815] has been defined for monitoring IPFIX



Ersue                     Expires July 31, 2011                [Page 37]


Internet-Draft          IETF Management Standards           January 2011


   meters, exporters and collectors (see Section 2.3).  The PSAMP MIB
   module (work ongoing) extends the IPFIX MIB modules by managed
   objects for monitoring PSAMP implementations.

   NETCONF working group defined the necessary data model to monitor the
   NETCONF protocol with the modeling language YANG [RFC6022].  The
   monitoring data model includes information about NETCONF datastores,
   sessions, locks, and statistics, which facilitate the management of a
   NETCONF server.  NETCONF monitoring RFC also defines methods for
   NETCONF clients to discover the data models supported by a NETCONF
   server and defines the operation <get-schema> to retrieve them.

4.2.  Configuration Management

   It is expected that standard XML-based data models will be developed
   for use with NETCONF, and working groups might identify specific
   NETCONF data models that would be applicable to the new protocol.

   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.

   Draft standards:

   [RFC3418] contains objects in the system group useful e.g. for
   identifying the type of device, the location of the device, the
   person responsible for the device.  [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
   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.




Ersue                     Expires July 31, 2011                [Page 38]


Internet-Draft          IETF Management Standards           January 2011


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

   At the time of this writing, only the YANG module for the monitoring
   of the NETCONF protocol exists as proposed standard [RFC6022].

   For configuring IPFIX and PSMAP devices, the IPFIX working group has
   developed an XML-based configuration data model [I-D.ietf-ipfix-
   configuration-model], in close collaboration with the NETMOD working
   group.  IPFIX configuration data model uses YANG as modeling language
   (see Section 2.4.1).  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.

   Non-standard data models:

   CAPWAP Base MIB [RFC5833] specifies managed objects for modeling the
   CAPWAP Protocol and provides configuration and WTP status-monitoring
   aspects of CAPWAP, where CAPWAP Binding MIB [RFC5834] defines managed
   objects for modeling of CAPWAP protocol for IEEE 802.11 wireless
   binding.
   Note: 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 protocol.

   At the time of this writing NETMOD working group is developing core
   system and interface models in YANG.

4.3.  Accounting Management

   Non-standard data models:

   [RFC4670] 'RADIUS Accounting Client MIB for IPv6' defines RADIUS
   Accounting Client MIB objects that support version-neutral IP
   addressing formats.

   [RFC4671] 'RADIUS Accounting Server MIB for IPv6' defines RADIUS
   Accounting Server MIB objects that support version-neutral IP
   addressing formats.



Ersue                     Expires July 31, 2011                [Page 39]


Internet-Draft          IETF Management Standards           January 2011


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



Ersue                     Expires July 31, 2011                [Page 40]


Internet-Draft          IETF Management Standards           January 2011


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

   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 working group 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.




Ersue                     Expires July 31, 2011                [Page 41]


Internet-Draft          IETF Management Standards           January 2011


   IPPM working group has defined [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.  However, the current registry structure has
   been found to be insufficiently detailed to uniquely identify IPPM
   metrics.  Due to the ambiguities between the current metrics
   registrations and the metrics used, and the apparent non-adoption of
   the registry in practice, it has been proposed to reclassify
   [RFC4148] as Obsolete and to withdraw the current IPPM Metrics
   Registry from use.

   Note: In case [RFC4148] is declared as Obsolete, IANA will prevent
   registering new metrics and actual users can continue to use the
   current registry and its contents.

   SIP Package for Voice Quality Reporting [RFC6035] 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:

   There are an extensive number of MIB modules defined for multiple
   purposes to use with RADIUS:

   o  [RFC4668] 'RADIUS Authentication Client MIB for IPv6' defines
      RADIUS Authentication Client MIB objects that support version-
      neutral IP addressing formats and defines a set of extensions for
      RADIUS authentication client functions.

   o  [RFC4669] 'RADIUS Authentication Server MIB for IPv6' defines
      RADIUS Authentication Server MIB objects that support version-
      neutral IP addressing formats and defines a set of extensions for
      RADIUS authentication server functions.

   o  [RFC4670] 'RADIUS Accounting Client MIB for IPv6' defines RADIUS
      Accounting Client MIB that objects that support version-neutral IP
      addressing formats.





Ersue                     Expires July 31, 2011                [Page 42]


Internet-Draft          IETF Management Standards           January 2011


   o  [RFC4671] 'RADIUS Accounting Server MIB for IPv6' defines RADIUS
      Accounting Server MIB that objects that support version-neutral IP
      addressing formats.

   o  [RFC4672] 'RADIUS Dynamic Authorization Client MIB' defines the
      MIB module for entities implementing the client side of the
      Dynamic Authorization Extensions to RADIUS [RFC5176].

   o  [RFC4673] 'RADIUS Dynamic Authorization Server MIB' defines the
      MIB module for entities implementing the server side of the
      Dynamic Authorization Extensions to RADIUS [RFC5176].

   The MIB Module definitions in [RFC4668], [RFC4669], [RFC4670],
   [RFC4671], [RFC4672], [RFC4673] are intended to be used only for
   RADIUS over UDP and therefore do not support RADIUS/TCP.  There is
   also a recommendation that RADIUS clients and servers implementing
   RADIUS/TCP should not re-use earlier listed MIB modules to perform
   statistics counting for RADIUS/TCP connections.

   Currently there are no standardized MIB modules for DIAMETER
   applications, which can be considered as a weakness on the management
   side of DIAMETER nodes.  There is an ongoing effort to produce a
   standard MIB for the [RFC3588] defined 'Diameter Base Protocol'
   [I-D.ietf-dime-diameter-base-protocol-mib] and the [RFC4006] defined
   'Diameter Credit-Control Application' [I-D.ietf-dime-diameter-cc-
   appl-mib].

5.  IANA Considerations

   This document does not introduce any new codepoints or name spaces
   for registration with IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

6.  Security Considerations

   This document introduces no new security concerns.

7.  Contributors

   Following persons made significant contributions to this document:

   o  Benoit Claise - Cisco - edited parts of the section on IPFIX/PSAMP
      and contributed the section on Energy Management.

   o  Dave Harrington - Huawei - edited the expired document
      'draft-ietf-opsawg-survey-management-00.txt', which has been used



Ersue                     Expires July 31, 2011                [Page 43]


Internet-Draft          IETF Management Standards           January 2011


      as a starting point for this document.

   o  Jouni Korhonen - Nokia Siemens Networks - contributed the sections
      on RADIUS and DIAMETER.

   o  Al Morton - AT&T - contributed to the section on IP Performance
      Metrics.

   o  Juergen Quittek - NEC - contributed the section on IPFIX/PSAMP.

   o  Juergen Schoenwaelder - Jacobs University Bremen - contributed the
      section on YANG.

8.  Acknowledgements

   The editor would like to thank to Tom Petch, Dan Romascanu and Henk
   Uijterwaal for their valuable suggestions and comments in the OPSAWG
   session and on its maillist.

9.  Informative References

   [3GPPIMS]    3GPP, "Release 10, IP Multimedia Subsystem (IMS); Stage
                2", September 2010,
                <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.

   [BCP108]     Emile, S., "IP Performance Metrics (IPPM) Metrics
                Registry", August 2005.

   [BCP27]      D. O'Dell, M., "Advancement of MIB specifications on the
                IETF Standards Track", October 1998.

   [BCP74]      Frye, R., "Coexistence between Version 1, Version 2, and
                Version 3 of the Internet-standard Network Management
                Framework", August 2003.

   [DMTF-CIM]   DMTF, "Common Information Model Schema, Version 2.27.0",
                November 2010, <http://www.dmtf.org/standards/cim>.

   [IANA-PROT]  Internet Assigned Numbers Authority, "IANA Protocol
                Registries", October 2010,
                <http://www.iana.org/protocols/>.

   [IETF-WGS]   IETF, "IETF Working Groups",
                <http://datatracker.ietf.org/wg/>.

   [ITU-M3100]  International Telecommunication Union, "M.3100: Generic
                network information model",  January 2006,
                <http://www.itu.int/rec/T-REC-M.3100-200504-I>.



Ersue                     Expires July 31, 2011                [Page 44]


Internet-Draft          IETF Management Standards           January 2011


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

   [RFC2458]    Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S.,
                Burg, F., DeSimone, A., Tewani, K., Davidson, P.,
                Schulzrinne, H., and K. Vishwanathan, "Toward the PSTN/
                Internet Inter-Networking --Pre-PINT Implementations",
                RFC 2458, November 1998.

   [RFC2578]    McCloghrie, K., Ed., Perkins, D., Ed., and J.
                Schoenwaelder, Ed., "Structure of Management Information
                Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2579]    McCloghrie, K., Ed., Perkins, D., Ed., and J.
                Schoenwaelder, Ed., "Textual Conventions for SMIv2",
                STD 58, RFC 2579, April 1999.

   [RFC2580]    McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                "Conformance Statements for SMIv2", STD 58, RFC 2580,
                April 1999.

   [RFC2610]    Perkins, C. and E. Guttman, "DHCP Options for Service
                Location Protocol", RFC 2610, June 1999.



Ersue                     Expires July 31, 2011                [Page 45]


Internet-Draft          IETF Management Standards           January 2011


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

   [RFC2748]    Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.,
                and A. Sastry, "The COPS (Common Open Policy Service)
                Protocol", RFC 2748, 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.

   [RFC2867]    Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
                Modifications for Tunnel Protocol Support", RFC 2867,
                June 2000.

   [RFC2868]    Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
                M., and I. Goyret, "RADIUS Attributes for Tunnel
                Protocol Support", RFC 2868, June 2000.

   [RFC2869]    Rigney, C., Willats, W., and P. Calhoun, "RADIUS



Ersue                     Expires July 31, 2011                [Page 46]


Internet-Draft          IETF Management Standards           January 2011


                Extensions", RFC 2869, 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,
                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.

   [RFC3159]    McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn,
                S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure
                of Policy Provisioning Information (SPPI)", RFC 3159,
                August 2001.

   [RFC3162]    Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
                RFC 3162, August 2001.

   [RFC3164]    Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
                August 2001.

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

   [RFC3195]    New, D. and M. Rose, "Reliable Delivery for syslog",
                RFC 3195, November 2001.

   [RFC3261]    Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
                A., Peterson, J., Sparks, R., Handley, M., and E.
                Schooler, "SIP: Session Initiation Protocol", RFC 3261,
                June 2002.

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



Ersue                     Expires July 31, 2011                [Page 47]


Internet-Draft          IETF Management Standards           January 2011


   [RFC3319]    Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
                Protocol (DHCPv6) Options for Session Initiation
                Protocol (SIP) Servers", RFC 3319, 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 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.

   [RFC3430]    Schoenwaelder, J., "Simple Network Management Protocol
                Over Transmission Control Protocol Transport Mapping",
                RFC 3430, December 2002.

   [RFC3432]    Raisanen, V., Grotefeld, G., and A. Morton, "Network
                performance measurement with periodic streams",
                RFC 3432, November 2002.

   [RFC3433]    Bierman, A., Romascanu, D., and K. Norseth, "Entity
                Sensor Management Information Base", RFC 3433,



Ersue                     Expires July 31, 2011                [Page 48]


Internet-Draft          IETF Management Standards           January 2011


                December 2002.

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

   [RFC3444]    Pras, A. and J. Schoenwaelder, "On the Difference
                between Information Models and Data Models", RFC 3444,
                January 2003.

   [RFC3460]    Moore, B., "Policy Core Information Model (PCIM)
                Extensions", RFC 3460, January 2003.

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

   [RFC3539]    Aboba, B. and J. Wood, "Authentication, Authorization
                and Accounting (AAA) Transport Profile", RFC 3539,
                June 2003.

   [RFC3574]    Soininen, J., "Transition Scenarios for 3GPP Networks",
                RFC 3574, August 2003.

   [RFC3579]    Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
                Dial In User Service) Support For Extensible
                Authentication Protocol (EAP)", RFC 3579,
                September 2003.

   [RFC3580]    Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
                Roese, "IEEE 802.1X Remote Authentication Dial In User
                Service (RADIUS) Usage Guidelines", RFC 3580,
                September 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.

   [RFC3589]    Loughney, J., "Diameter Command Codes for Third
                Generation Partnership Project (3GPP) Release 5",
                RFC 3589, September 2003.

   [RFC3646]    Droms, R., "DNS Configuration options for Dynamic Host
                Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,



Ersue                     Expires July 31, 2011                [Page 49]


Internet-Draft          IETF Management Standards           January 2011


                December 2003.

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

   [RFC3758]    Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
                Conrad, "Stream Control Transmission Protocol (SCTP)
                Partial Reliability Extension", RFC 3758, May 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 Information Export (IPFIX)",
                RFC 3917, October 2004.

   [RFC4004]    Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
                P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
                August 2005.

   [RFC4005]    Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
                "Diameter Network Access Server Application", RFC 4005,
                August 2005.

   [RFC4006]    Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and
                J. Loughney, "Diameter Credit-Control Application",
                RFC 4006, August 2005.

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

   [RFC4029]    Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
                Savola, "Scenarios and Analysis for Introducing IPv6
                into ISP Networks", RFC 4029, March 2005.

   [RFC4038]    Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
                Castro, "Application Aspects of IPv6 Transition",
                RFC 4038, March 2005.

   [RFC4057]    Bound, J., "IPv6 Enterprise Network Scenarios",
                RFC 4057, June 2005.

   [RFC4072]    Eronen, P., Hiller, T., and G. Zorn, "Diameter
                Extensible Authentication Protocol (EAP) Application",



Ersue                     Expires July 31, 2011                [Page 50]


Internet-Draft          IETF Management Standards           January 2011


                RFC 4072, August 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.

   [RFC4213]    Nordmark, E. and R. Gilligan, "Basic Transition
                Mechanisms for IPv6 Hosts and Routers", RFC 4213,
                October 2005.

   [RFC4215]    Wiljakka, J., "Analysis on IPv6 Transition in Third
                Generation Partnership Project (3GPP) Networks",
                RFC 4215, October 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.

   [RFC4280]    Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host
                Configuration Protocol (DHCP) Options for Broadcast and
                Multicast Control Servers", RFC 4280, November 2005.

   [RFC4347]    Rescorla, E. and N. Modadugu, "Datagram Transport Layer
                Security", RFC 4347, April 2006.

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



Ersue                     Expires July 31, 2011                [Page 51]


Internet-Draft          IETF Management Standards           January 2011


                (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,
                September 2006.

   [RFC4675]    Congdon, P., Sanchez, M., and B. Aboba, "RADIUS
                Attributes for Virtual LAN and Priority Support",
                RFC 4675, 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.

   [RFC4740]    Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M.,
                Canales-Valenzuela, C., and K. Tammi, "Diameter Session
                Initiation Protocol (SIP) Application", RFC 4740,
                November 2006.




Ersue                     Expires July 31, 2011                [Page 52]


Internet-Draft          IETF Management Standards           January 2011


   [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
                over the Blocks Extensible Exchange Protocol (BEEP)",
                RFC 4744, December 2006.

   [RFC4818]    Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
                Attribute", RFC 4818, April 2007.

   [RFC4825]    Rosenberg, J., "The Extensible Markup Language (XML)
                Configuration Access Protocol (XCAP)", RFC 4825,
                May 2007.

   [RFC5080]    Nelson, D. and A. DeKok, "Common Remote Authentication
                Dial In User Service (RADIUS) Implementation Issues and
                Suggested Fixes", RFC 5080, December 2007.

   [RFC5090]    Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D.,
                and W. Beck, "RADIUS Extension for Digest
                Authentication", RFC 5090, February 2008.

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

   [RFC5103]    Trammell, B. and E. Boschi, "Bidirectional Flow Export
                Using IP Flow Information Export (IPFIX)", RFC 5103,
                January 2008.

   [RFC5176]    Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
                Aboba, "Dynamic Authorization Extensions to Remote
                Authentication Dial In User Service (RADIUS)", RFC 5176,
                January 2008.

   [RFC5181]    Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6
                Deployment Scenarios in 802.16 Networks", RFC 5181,



Ersue                     Expires July 31, 2011                [Page 53]


Internet-Draft          IETF Management Standards           January 2011


                May 2008.

   [RFC5224]    Brenner, M., "Diameter Policy Processing Application",
                RFC 5224, March 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.

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

   [RFC5431]    Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface
                Application", RFC 5431, March 2009.

   [RFC5447]    Korhonen, J., Bournelle, J., Tschofenig, H., Perkins,
                C., and K. Chowdhury, "Diameter Mobile IPv6: Support for
                Network Access Server to Diameter Server Interaction",
                RFC 5447, February 2009.



Ersue                     Expires July 31, 2011                [Page 54]


Internet-Draft          IETF Management Standards           January 2011


   [RFC5470]    Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
                "Architecture for IP Flow Information Export", RFC 5470,
                March 2009.

   [RFC5473]    Boschi, E., Mark, L., and B. Claise, "Reducing
                Redundancy in IP Flow Information Export (IPFIX) and
                Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.

   [RFC5475]    Zseby, T., Molina, M., Duffield, N., Niccolini, S., and
                F. Raspall, "Sampling and Filtering Techniques for IP
                Packet Selection", RFC 5475, March 2009.

   [RFC5476]    Claise, B., Johnson, A., and J. Quittek, "Packet
                Sampling (PSAMP) Protocol Specifications", RFC 5476,
                March 2009.

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

   [RFC5516]    Jones, M. and L. Morand, "Diameter Command Code
                Registration for the Third Generation Partnership
                Project (3GPP) Evolved Packet System (EPS)", RFC 5516,
                April 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.

   [RFC5580]    Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.
                Aboba, "Carrying Location Objects in RADIUS and
                Diameter", RFC 5580, August 2009.

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

   [RFC5607]    Nelson, D. and G. Weber, "Remote Authentication Dial-In



Ersue                     Expires July 31, 2011                [Page 55]


Internet-Draft          IETF Management Standards           January 2011


                User Service (RADIUS) Authorization for Network Access
                Server (NAS) Management", RFC 5607, July 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.

   [RFC5610]    Boschi, E., Trammell, B., Mark, L., and T. Zseby,
                "Exporting Type Information for IP Flow Information
                Export (IPFIX) Information Elements", RFC 5610,
                July 2009.

   [RFC5655]    Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
                Wagner, "Specification of the IP Flow Information Export
                (IPFIX) File Format", RFC 5655, October 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)
                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.

   [RFC5719]    Romascanu, D. and H. Tschofenig, "Updated IANA
                Considerations for Diameter Command Code Allocations",
                RFC 5719, January 2010.

   [RFC5729]    Korhonen, J., Jones, M., Morand, L., and T. Tsou,
                "Clarifications on the Routing of Diameter Requests



Ersue                     Expires July 31, 2011                [Page 56]


Internet-Draft          IETF Management Standards           January 2011


                Based on the Username and the Realm", RFC 5729,
                December 2009.

   [RFC5730]    Hollenbeck, S., "Extensible Provisioning Protocol
                (EPP)", STD 69, RFC 5730, August 2009.

   [RFC5777]    Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones,
                M., and A. Lior, "Traffic Classification and Quality of
                Service (QoS) Attributes for Diameter", RFC 5777,
                February 2010.

   [RFC5778]    Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta,
                G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for
                Home Agent to Diameter Server Interaction", RFC 5778,
                February 2010.

   [RFC5779]    Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
                and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
                Gateway and Local Mobility Anchor Interaction with
                Diameter Server", RFC 5779, February 2010.

   [RFC5815]    Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
                "Definitions of Managed Objects for IP Flow Information
                Export", RFC 5815, April 2010.

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

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

   [RFC5866]    Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria,
                A., and G. Zorn, "Diameter Quality-of-Service
                Application", RFC 5866, May 2010.



Ersue                     Expires July 31, 2011                [Page 57]


Internet-Draft          IETF Management Standards           January 2011


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

   [RFC5982]    Kobayashi, A. and B. Claise, "IP Flow Information Export
                (IPFIX) Mediation: Problem Statement", RFC 5982,
                August 2010.

   [RFC6012]    Salowey, J., Petch, T., Gerhards, R., and H. Feng,
                "Datagram Transport Layer Security (DTLS) Transport
                Mapping for Syslog", RFC 6012, October 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.

   [RFC6035]    Pendleton, A., Clark, A., Johnston, A., and H.
                Sinnreich, "Session Initiation Protocol Event Package
                for Voice Quality Reporting", RFC 6035, November 2010.

   [RFCSEARCH]  IETF, "RFC Index Search Engine", January 2006,
                <http://www.rfc-editor.org/rfcsearch.html>.

   [STD58]      McCloghrie, K., David, D., and J. Juergen, "Structure of
                Management Information Version 2 (SMIv2)", April 1999.

   [STD59]      Waldbusser, S., "Remote Network Monitoring Management
                Information Base", May 2000.

   [STD62]      Harrington, D., "An Architecture for Describing Simple
                Network Management Protocol (SNMP) Management
                Frameworks", December 2002.

   [STD69]      Hollenbeck, S., "Extensible Provisioning Protocol
                (EPP)", August 2009.

   [XPATH]      World Wide Web Consortium, "XML Path Language (XPath)
                Version 1.0", November 1999,
                <http://www.w3.org/TR/1999/REC-xpath-19991116>.



Ersue                     Expires July 31, 2011                [Page 58]


Internet-Draft          IETF Management Standards           January 2011


Appendix A.  New Work related to IETF Management Framework

A.1.  Energy Management (EMAN)

   Energy management is becoming an additional requirement for network
   management systems due to several factors including the rising and
   fluctuating energy costs, the increased awareness of the ecological
   impact of operating networks and devices, and the regulation of
   governments on energy consumption and production.

   The basic 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.  Today, most networking and network-attached devices
   neither monitor nor allow control energy usage as they are mainly
   instrumented for functions such as fault, configuration, accounting,
   performance, and security management.  These devices are not
   instrumented to be aware of energy consumption.  There are very few
   means specified in IETF documents for energy management, which
   includes the areas of power monitoring, energy monitoring, and power
   state control.

   A particular difference between energy management and other
   management tasks is that in some cases energy consumption of a device
   is not measured at the device itself but reported by a different
   place.  For example, at a Power over Ethernet (PoE) sourcing device
   or at a smart power strip, in which cases one device is effectively
   metering another remote device.  This requires a clear definition of
   the relationship between the reporting devices and identification of
   remote devices for which monitoring information is provided.  Similar
   considerations will apply to 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 wireless a
   building network.  Here the energy management system talks directly
   to the gateway but not necessarily to other devices in the building
   network.

   At the time of this writing the EMAN working group works on the
   management of energy-aware devices, covered by the following items:

   o  Requirements for energy management, specifying energy management
      properties that will allow networks and devices to become energy
      aware.  In addition to energy awareness requirements, the need for
      control functions will be discussed.  Specifically the need to
      monitor and control properties of devices that are remote to the
      reporting device should be discussed.




Ersue                     Expires July 31, 2011                [Page 59]


Internet-Draft          IETF Management Standards           January 2011


   o  Energy management framework, which will describe extensions to
      current management framework, required for energy management.
      This includes: power and energy monitoring, power states, power
      state control, and potential power state transitions.  The
      framework will focus on energy management for IP-based network
      equipment (routers, switches, PCs, IP cameras, phones and the
      like).  Particularly, the relationships between reporting devices,
      remote devices, and monitoring probes (such as might be used in
      low-power and lossy networks) need to be elaborated.  For the case
      of a device reporting on behalf of other devices and controlling
      those devices, the framework will address the issues of discovery
      and identification of remote devices.

   o  Energy-aware Networks and Devices MIB document, for monitoring
      energy-aware networks and devices, will address devices
      identification, context information, and potential relationship
      between reporting devices, remote devices, and monitoring probes.

   o  Power and Energy Monitoring MIB document will document defining
      managed objects for monitoring of power states and energy
      consumption/production.  The monitoring of power states includes:
      retrieving power states, properties of power states, current power
      state, power state transitions, and power state statistics.  The
      managed objects will provide means for reporting detailed
      properties of the actual energy rate (power) and of accumulated
      energy.  Further, it will provide information on electrical power
      quality.

   o  Battery MIB document will define 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.

   o  Applicability statement will describe the variety of applications
      that can use the energy framework and associated MIB modules.
      Potential examples are building networks, home energy gateway,
      etc.  Finally, the document will also discuss relationships of the
      framework to other architectures and frameworks (such as Smart
      Grid).  The applicability statement will explain the relationship
      between the work in this WG and the other existing standards such
      as those from the IEC, ANSI, DMTF, and others.  Note that the EMAN
      WG will be looking into existing standards such as those from the
      IEC, ANSI, DMTF and others, and reuse existing work as much as
      possible.







Ersue                     Expires July 31, 2011                [Page 60]


Internet-Draft          IETF Management Standards           January 2011


Appendix B.  Open issues

   Need additional discussion on usage scenarios for different RFCs.

Appendix C.  Change Log

C.1.  02-03

   o  Rearranged the document structure using a flat structure putting
      all protocols onto the same level.

   o  Incorporated contributions for RADIUS/DIAMETER, IPFIX/PSAMP, YANG,
      and EMAN.

   o  Added diverse references.

   o  Added Contributors and Acknowledgements sections.

   o  Bug fixing and issue solving.

C.2.  01-02

   o  Added terminology section.

   o  Changed the language for neutral standard description addressing
      diverse SDOs.

   o  Extended NETCONF and NETMOD related text.

   o  Extended section for 'IPv6 Network Operations'.

   o  Bug fixing.

C.3.  00-01

   o  Extended text for SNMP

   o  Extended RADIUS and DIAMETER sections.

   o  Added references.

   o  Bug fixing.









Ersue                     Expires July 31, 2011                [Page 61]


Internet-Draft          IETF Management Standards           January 2011


Author's Address

   Mehmet Ersue (editor)
   Nokia Siemens Networks
   St.-Martin-Strasse 53
   Munich  81541
   Germany

   EMail: mehmet.ersue@nsn.com










































Ersue                     Expires July 31, 2011                [Page 62]


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