4.  Network Management Data Models

   This section provides two complementary overviews for the network
   management data models standardized at IETF.  The first subsection
   focuses on a broader view of models classified into categories such
   as generic and infrastructure data models as well as data models
   matched to different layers.  The second subsection is structured
   following the management application view and focuses mainly on the
   data models for the network management tasks fault, configuration,
   accounting, performance, and security management (see [FCAPS]).

   Note that the IETF does not use the FCAPS view as an organizing
   principle for its data models.  However, the FCAPS view is used
   widely outside of the IETF for the realization of management tasks
   and applications.  Section 4.2 aims to address the FCAPS view to
   enable people outside of the IETF to understand the relevant data
   models in the IETF.

   The different data models covered in this section are MIB modules,
   IPFIX Information Elements, Syslog Structured Data Elements, and YANG
   modules.  There are many technology-specific IETF data models, such
   as transmission and protocol MIBs, which are not mentioned in this
   document and can be found at [RFCSEARCH].

   This section gives an overview of management data models that have
   reached Draft or Proposed Standard status at the IETF.  In
   exceptional cases, important Informational RFCs are referenced.  The
   advancement process for management data models beyond Proposed
   Standard status, has been defined in [BCP027] with a more pragmatic
   approach and special considerations on data model specification
   interoperability.  However, most IETF management data models never
   advanced beyond Proposed Standard.

4.1.  IETF Network Management Data Models

   The data models defined by the IETF can be broadly classified into
   the following categories depicted in Figure 1.

     +-----------+  +-------------------------------+  +-----------+
     |           |  | application-layer data models |  |  network  |
     |  generic  |  +-------------------------------+  | management|
     |  infra-   |  |  transport-layer data models  |  |  infra-   |
     | structure |  +-------------------------------+  | structure |
     |   data    |  |   network-layer data models   |  |   data    |
     |  models   |  +-------------------------------+  |  models   |
     |           |  |    link-layer data models     |  |           |
     +-----------+  +-------------------------------+  +-----------+

          Figure 1: Categories of Network Management Data Models

   Each of the categories is briefly described below.  Note that the
   classification used here is intended to provide orientation and
   reflects how most data models have been developed in the IETF by the
   various working groups.  This classification does not aim to classify
   correctly all data models that have been defined by the IETF so far.
   The network layering model in the middle of Figure 1 follows the
   four-layer model of the Internet as defined in [RFC1021].

   The network management object identifiers for use with IETF MIB
   modules defined in the IETF can be found under the IANA registry at
   [SMI-NUMBERS].

4.1.1.  Generic Infrastructure Data Models

   Generic infrastructure data models provide core abstractions that
   many other data models are built upon.  The most important example is
   the interfaces data model defined in the IF-MIB [RFC2863].  It
   provides the basic notion of network interfaces and allows expressing
   stacking/layering relationships between interfaces.  The interfaces
   data model also provides basic monitoring objects that are widely
   used for performance and fault management.

   The second important infrastructure data model is defined in the
   Entity MIB [RFC4133].  It exports the containment hierarchy of the
   physical entities (slots, modules, ports) that make up a networking
   device and, as such, it is a key data model for inventory management.
   Physical entities can have pointers to other data models that provide
   more specific information about them (e.g., physical ports usually
   point to the related network interface).  Entity MIB extensions exist
   for physical sensors such as temperature sensors embedded on line
   cards or sensors that report fan rotation speeds [RFC3433].  The

   Entity State MIB [RFC4268] models states and alarms of physical
   entities.  Some vendors have extended the basic Entity MIB with
   several proprietary data models.

4.1.2.  Link-Layer Data Models

   A number of data models exist in the form of MIB modules covering the
   link layers IP runs over, such as Asymmetric Bit-Rate DSL (ADSL)
   [RFC4706], Very high bit-rate Digital Subscriber Line (VDSL)
   [RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515] [RFC3606],
   Cable Modems [RFC4546], or Ethernet [RFC4188] [RFC4318] [RFC4363].
   These so-called transmission data models typically extend the generic
   network interfaces data model with interface type specific
   information.  Most of the link-layer data models focus on monitoring
   capabilities that can be used for performance and fault management
   functions and, to some lesser extent, for accounting and security
   management functions.  Meanwhile, the IEEE has taken over the
   responsibility to maintain and further develop data models for the
   IEEE 802 family of protocols [RFC4663].  The cable modem industry
   consortium DOCSIS is working with the IETF to publish data models for
   cable modem networks as IETF Standards Track specifications.

4.1.3.  Network-Layer Data Models

   There are data models in the form of MIB modules covering IP/ICMP
   [RFC4293] [RFC4292] network protocols and their extensions (e.g.,
   Mobile IP), the core protocols of the Internet.  In addition, there
   are data models covering popular unicast routing protocols (OSPF
   [RFC4750], IS-IS [RFC4444], BGP-4 [RFC4273]) and multicast routing
   protocols (PIM [RFC5060]).

   Detailed models also exist for performance measurements in the form
   of IP Performance Metrics [RFC2330] (see Section 3.4).

   The necessary data model infrastructure for configuration data models
   covering network layers are currently being defined using NETCONF
   [RFC6242] and YANG [RFC6020].

4.1.4.  Transport-Layer Data Models

   There are data models for the transport protocols TCP [RFC4022], UDP
   [RFC4113], and SCTP [RFC3873].  For TCP, a data model providing
   extended statistics is defined in [RFC4898].

4.1.5.  Application-Layer Data Models

   Some data models have been developed for specific application
   protocols (e.g., SIP [RFC4780]).  In addition, there are data models
   that provide a generic infrastructure for instrumenting applications
   in order to obtain data useful primarily for performance management
   and fault management [RFC2287] [RFC2564].  In general, however,
   generic application MIB modules have been less successful in gaining
   widespread deployment.

4.1.6.  Network Management Infrastructure Data Models

   A number of data models are concerned with the network management
   system itself.  This includes, in addition to a set of SNMP MIB
   modules for monitoring and configuring SNMP itself [RFC3410], some
   MIB modules providing generic functions such as the calculation of
   expressions over MIB objects, generic functions for thresholding and
   event generation, event notification logging functions, and data
   models to represent alarms [RFC2981] [RFC2982] [RFC3014] [RFC3877].

   In addition, there are data models that allow the execution of basic
   reachability and path discovery tests [RFC4560].  Another collection
   of MIB modules provides remote monitoring functions, ranging from the
   data link layer up to the application layer.  This is known as the
   "RMON family of MIB modules" [RFC3577].

   The IPFIX Protocol [RFC5101] (Section 2.3) is used to export
   information about network flows collected at so-called Observation
   Points (typically, a network interface).  The IEs [RFC5102] carried
   in IPFIX cover the majority of the network and transport layer header
   fields and a few link-layer-specific fields.  Work is underway to
   further extend the standardized information that can be carried in
   IPFIX.

   The Syslog Protocol document [RFC5424] (Section 2.2) 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.

4.2.  Network Management Data Models - FCAPS View

   This subsection follows the management application view and aims to
   match the data models to network management tasks for fault,
   configuration, accounting, performance, and security management
   ([FCAPS]).  As OAM is a general term that refers to a toolset, which
   can be used for fault detection, isolation, and performance
   measurement, aspects of FCAPS in the context of the data path, such

   as fault and performance management, are also discussed in "An
   Overview of Operations, Administration, and Maintenance (OAM)
   Mechanisms" [OAM-OVERVIEW].

   Some of the data models do not fit into one single FCAPS category per
   design but span multiple areas.  For example, there are many
   technology-specific IETF data models, such as transmission and
   protocol MIBs, which cover multiple FCAPS categories, and therefore
   are not mentioned in this subsection and can be found at [RFCSEARCH].

4.2.1.  Fault Management

   Fault management encloses a set of functions to detect, isolate,
   notify, and correct faults encountered in a network as well as to
   maintain and examine error logs.  The data models below can be
   utilized to realize a fault management application.

   [RFC3418], part of SNMPv3 standard [STD62], is a MIB module
   containing 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 the network management portion of the system has
   restarted and counters have been re-initialized.

   [RFC3413], part of SNMPv3 standard [STD62], is a MIB module including
   objects designed for managing notifications, including tables for
   addressing, retry parameters, security, lists of targets for
   notifications, and user customization filters.

   The Interfaces Group MIB [RFC2863] builds on the old standard for MIB
   II [STD17] and is used as a primary MIB module for managing and
   monitoring the status of network interfaces.  The Interfaces Group
   MIB defines a generic set of managed objects for network interfaces,
   and it provides the infrastructure for additional managed objects
   specific to particular types of network interfaces, such as Ethernet.

   [RFC4560] defines a MIB module for performing ping, traceroute, and
   lookup operations at a host.  For troubleshooting purposes, it is
   useful to be able to initiate and retrieve the results of ping or
   traceroute operations when they are performed at a remote host.

   The RMON (Remote Network Monitoring) MIB [STD59] can be configured to
   recognize conditions on existing MIB variables (most notably error
   conditions) and continuously 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.2.4).

   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 the following:

   o  a mechanism for expressing state transition models for persistent
      problem states,

   o  a mechanism to correlate a notification with subsequent state
      transition notifications about the same entity/object, and

   o  a generic alarm reporting mechanism (extends ITU-T work on X.733
      [ITU-X733]).

   In particular, [RFC3878] defines objects for controlling the
   reporting of alarm conditions and extends ITU-T work on 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 [RFC5424] defines an initial set of SDEs
   that relate to content time quality, content origin, and meta-
   information about the message, such as language.  Proprietary SDEs
   can be used to supplement the IETF-defined SDEs.

   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
   Meters, Exporters, and Collectors (see Section 2.3).  The ongoing
   work on the PSAMP MIB module extends the IPFIX MIB modules by managed
   objects for monitoring PSAMP implementations [PSAMP-MIB].

   The NETCONF working group defined the data model necessary to monitor
   the NETCONF protocol [RFC6022] with the modeling language YANG.  The
   monitoring data model includes information about NETCONF datastores,
   sessions, locks, and statistics, which facilitate the management of a
   NETCONF server.  The NETCONF monitoring document 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.2.  Configuration Management

   Configuration management focuses on establishing and maintaining
   consistency of a system and defines the functionality to configure
   its functional and physical attributes as well as operational
   information throughout its life.  Configuration management includes
   configuration of network devices, inventory management, and software
   management.  The data models below can be used to utilize
   configuration management.

   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, etc.

   [RFC3418], part of [STD62], contains objects in the system group
   useful, e.g., for identifying the type of device and the location of
   the device, the person responsible for the device.  The SNMPv3
   standard [STD62] furthermore includes objects designed for
   configuring principals, access control rules, notification
   destinations, and for configuring proxy-forwarding SNMP agents, which
   can be used to forward messages through firewalls and NAT devices.

   The Entity MIB [RFC4133] supports mainly inventory management and is
   used for managing multiple logical and physical entities matched to a
   single SNMP agent.  This module provides a useful mechanism for
   identifying the entities comprising a system and defines event
   notifications for configuration changes that may be useful to
   management applications.

   [RFC3165] defines a set of managed objects that enable the delegation
   of management scripts to distributed managers.

   For configuring IPFIX and PSAMP devices, the IPFIX working group
   developed the IPFIX Configuration Data Model [CONF-MODEL], by using
   the YANG modeling language and in close collaboration with the NETMOD
   working group (see Section 2.4.2).  The model specifies the necessary
   data for configuring and monitoring Selection Processes, caches,
   Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-
   compliant monitoring devices.

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

   The CAPWAP protocol exchanges message elements using the Type-Length-
   Value (TLV) format.  The base TLVs are specified in [RFC5415], while
   the TLVs for IEEE 802.11 are specified in [RFC5416].  The CAPWAP Base
   MIB [RFC5833] specifies managed objects for the modeling the CAPWAP
   protocol and provides configuration and WTP status-monitoring aspects
   of CAPWAP, where the CAPWAP Binding MIB [RFC5834] defines managed
   objects for the modeling of the 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.

4.2.3.  Accounting Management

   Accounting management collects usage information of network
   resources.  Note that the IETF does not define any mechanisms related
   to billing and charging.  Many technology-specific MIBs (link layer,
   network layer, transport layer, or application layer) contain
   counters but are not primarily targeted for accounting and,
   therefore, are not included in this section.

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

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

   IPFIX/PSAMP Information Elements:

   As expressed in Section 2.3, the IPFIX Architecture [RFC5470] defines
   components involved in IP flow measurement and reporting of
   information on IP flows.  As such, IPFIX records provide fine-grained
   measurement data for flexible and detailed usage reporting and enable
   usage-based accounting.

   The IPFIX Information Elements (IEs) have been initially defined in
   the IPFIX Information Model [RFC5102] and registered with IANA
   [IANA-IPFIX].  The IPFIX IEs are composed of two types:

   o  IEs related to identification of IP flows such as header
      information, derived packet properties, IGP and BGP next-hop IP
      address, BGP AS, etc., and

   o  IEs related to counter and timestamps, such as per-flow counters
      (e.g., octet count, packet count), flow start times, flow end
      times, and flow duration, etc.

   The Information Elements specified in the IPFIX Information Model
   [RFC5102] are used by the PSAMP protocol where applicable.  PSAMP
   Parameters defined in the PSAMP protocol specification are registered
   at [IANA-PSAMP].  An additional set of PSAMP Information Elements for
   reporting packet information with the IPFIX/PSAMP protocol such as
   Sampling-related IEs are specified in the PSAMP Information Model
   [RFC5477].  These IEs fulfill the requirements on reporting of
   different sampling and filtering techniques specified in [RFC5475].

4.2.4.  Performance Management

   Performance management covers a set of functions that evaluate and
   report the performance of network elements and the network, with the
   goal to maintain the overall network performance at a defined level.
   Performance management functionality includes monitoring and
   measurement of network performance parameters, gathering statistical
   information, maintaining and examining activity logs.  The data
   models below can be used for performance management tasks.

   The RMON (Remote Network Monitoring) MIB [STD59] defines objects for
   collecting data related to network performance and traffic from
   remote monitoring devices.  An organization may employ many remote
   monitoring probes, one per network segment, to monitor its network.
   These devices may be used by a network service provider to access a
   (distant) client network.  Most of the objects in the RMON MIB module
   are suitable for the monitoring of any type of network, while some of
   them are specific to the monitoring of Ethernet networks.

   RMON allows a probe to be configured to perform diagnostics and to
   collect network 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.

   "Introduction to the Remote Monitoring (RMON) Family of MIB Modules"
   [RFC3577] describes the documents associated with the RMON Framework
   and how they relate to each other.

   The RMON-2 MIB [RFC4502] extends RMON by providing RMON analysis up
   to the application layer and defines performance data to monitor.
   The SMON MIB [RFC2613] extends RMON by providing RMON analysis for
   switched networks.

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

   "Remote Network Monitoring Management Information Base for High
   Capacity Networks" [RFC3273] defines objects for managing RMON
   devices for use on high-speed networks.

   "Remote Monitoring 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), which is part of the RMON protocol family.
   RAQMON supports end-to-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 [STD59]
   and describes managed objects used for RAQMON.  [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.  [RFC3729] enables the measurement of 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 SDOs' documents.

   The IPPM working group has defined "IP Performance Metrics (IPPM)
   Metrics Registry" [RFC4148].  Note that with the publication of
   [RFC6248], [RFC4148] and the corresponding IANA registry for IPPM
   metrics have been declared Obsolete and shouldn't be used.

   The IPPM working group defined the "Information Model and XML Data
   Model for Traceroute Measurements" [RFC5388], which defines a common
   information model dividing the IEs 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.

   "Session Initiation Protocol Event 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.

4.2.5.  Security Management

   Security management provides the set of functions to protect the
   network and system from unauthorized access and includes functions
   such as creating, deleting, and controlling security services and
   mechanisms, key management, reporting security-relevant events, and
   authorizing user access and privileges.  Based on their support for
   authentication and authorization, RADIUS and diameter are seen as
   security management protocols.  The data models below can be used to
   utilize security management.

   [RFC3414], part of [STD62], specifies the procedures for providing
   SNMPv3 message-level security and includes a MIB module for remotely
   monitoring and managing the configuration parameters for the USM.

   [RFC3415], part of [STD62], describes the procedures for controlling
   access to management information in the SNMPv3 architecture and
   includes a MIB module, which defines managed objects to access
   portions of an SNMP engine's Local Configuration Datastore (LCD).  As
   such, this MIB module enables remote management of the configuration
   parameters of the VACM.

   The NETCONF Access Control Model (NACM) [RFC6536] addresses the need
   for access control mechanisms for the operation and content layers of
   NETCONF, as defined in [RFC6241].  As such, the NACM proposes
   standard mechanisms to restrict NETCONF protocol access for
   particular users to a pre-configured subset of all available NETCONF
   protocol operations and content within a particular server.

   There are numerous MIB modules defined for multiple purposes to use
   with RADIUS:

   o  "RADIUS Authentication Client MIB for IPv6" [RFC4668] 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  "RADIUS Authentication Server MIB for IPv6" [RFC4669] 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  "RADIUS Dynamic Authorization Client MIB" [RFC4672] defines the
      MIB module for entities implementing the client side of the
      Dynamic Authorization Extensions to RADIUS [RFC5176].

   o  "RADIUS Dynamic Authorization Server MIB" [RFC4673] 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], [RFC4672],
   [RFC4673] are intended to be used only for RADIUS over UDP and do not
   support RADIUS over TCP.  There is also a recommendation that RADIUS
   clients and servers implementing RADIUS over TCP should not reuse
   earlier listed MIB modules to perform statistics counting for RADIUS-
   over-TCP connections.

   Currently, there are no standardized MIB modules for diameter
   applications, which can be considered as a lack on the management
   side of diameter nodes.

5.  Security Considerations

   This document gives an overview of IETF network management standards
   and summarizes existing and ongoing development of IETF Standards
   Track network management protocols and data models.  As such, it does
   not have any security implications in or of itself.

   For each specific technology discussed in the document a summary of
   its security usage has been given in corresponding chapters.  In a
   few cases, e.g., for SNMP, a detailed description of developed
   security mechanisms has been provided.

   The attention of the reader is particularly drawn to the security
   discussion in following document sections:

   o  SNMP Security and Access Control Models in Section 2.1.4.1,

   o  User-based Security Model (USM) in Section 2.1.4.2,

   o  View-based Access Control Model (VACM) in Section 2.1.4.3,

   o  SNMP Transport Security Model in Section 2.1.5.1,

   o  Secure syslog message delivery in Section 2.2,

   o  Use of secure NETCONF message transport and the NETCONF Access
      Control Model (NACM) in Section 2.4.1,

   o  Message authentication for Dynamic Host Configuration Protocol
      (DHCP) in Section 3.1.1,

   o  Security for Remote Authentication Dial-In User Service (RADIUS)
      in conjunction with EAP and IEEE 802.1X authenticators in
      Section 3.5,

   o  Built-in and transport security for the Diameter Base Protocol in
      Section 3.6,

   o  Transport security for Control And Provisioning of Wireless Access
      Points (CAPWAP) in Section 3.7,

   o  Built-in security for Access Node Control Protocol (ANCP) in
      Section 3.8,

   o  Security for Application Configuration Access Protocol (ACAP) in
      Section 3.9,

   o  Security for XML Configuration Access Protocol (XCAP) in
      Section 3.10, and

   o  Data models for Security Management in Section 4.2.5.

   The authors would also like to refer to detailed security
   consideration sections for specific management standards described in
   this document, which contain comprehensive discussion of security
   implications of the particular management protocols and mechanisms.
   Among others, security consideration sections of following documents
   should be carefully read before implementing the technology.

   o  For SNMP security in general, subsequent security consideration
      sections in [STD62], which includes RFCs 3411-3418,

   o  Security considerations section in Section 8 of [BCP074] for the
      coexistence of SNMP versions 1, 2, and 3,

   o  Security considerations for the SNMP Transport Security Model in
      Section 8 of [RFC5591],

   o  Security considerations for the Secure Shell Transport Model for
      SNMP in Section 9 of [RFC5592],

   o  Security considerations for the TLS Transport Model for SNMP in
      Section 9 of [RFC6353],

   o  Security considerations for the TLS Transport Mapping for syslog
      in Section 6 of [RFC5425],

   o  Security considerations for the IPFIX Protocol Specification in
      Section 11 of [RFC5101],

   o  Security considerations for the NETCONF protocol in Section 9 of
      [RFC6241] and the SSH transport in Section 6 of [RFC6242],

   o  Security considerations for the NETCONF Access Control Model
      (NACM) in Section 3.7 of [RFC6536],

   o  Security considerations for DHCPv4 and DHCPv6 in Section 7 of
      [RFC2131] and Section 23. of [RFC3315],

   o  Security considerations for RADIUS in Section 8 of [RFC2865],

   o  Security considerations for diameter in Section 13 of [RFC3588],

   o  Security considerations for the CAPWAP protocol in Section 12 of
      [RFC5415],

   o  Security considerations for the ANCP protocol in Section 11 of
      [RFC6320], and

   o  Security considerations for the XCAP protocol in Section 14 of
      [RFC4825].

6.  Contributors

   Following persons made significant contributions to and reviewed this
   document:

   o  Ralph Droms (Cisco) - revised the section on IP Address Management
      and DHCP.

   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
      sections on IETF Network Management Data Models and YANG.

7.  Acknowledgements

   The editor would like to thank Fred Baker, Alex Clemm, Miguel A.
   Garcia, Simon Leinen, Christopher Liljenstolpe, Tom Petch, Randy
   Presuhn, Dan Romascanu, Juergen Schoenwaelder, Tina Tsou, and Henk
   Uijterwaal for their valuable suggestions and comments in the OPSAWG
   sessions and on the mailing list.

   The editor would like to especially thank Dave Harrington, who
   created the document "Survey of IETF Network Management Standards" a
   few years ago, which has been used as a starting point and enhanced
   with a special focus on the description of the IETF network
   management standards and management data models.