Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6632

An Overview of the IETF Network Management Standards

Pages: 85
Part 3 of 5 – Pages 38 to 52
First   Prev   Next

Top   ToC   RFC6632 - Page 38   prevText

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.
Top   ToC   RFC6632 - Page 39

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
Top   ToC   RFC6632 - Page 40
   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].
Top   ToC   RFC6632 - Page 41

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
Top   ToC   RFC6632 - Page 42
   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).
Top   ToC   RFC6632 - Page 43
   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

   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

   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.
Top   ToC   RFC6632 - Page 44
   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

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.
Top   ToC   RFC6632 - Page 45
   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.
Top   ToC   RFC6632 - Page 46
   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.
Top   ToC   RFC6632 - Page 47
   "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.
Top   ToC   RFC6632 - Page 48
   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.
Top   ToC   RFC6632 - Page 49
   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,
Top   ToC   RFC6632 - Page 50
   o  User-based Security Model (USM) in Section,

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

   o  SNMP Transport Security Model in Section,

   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,
Top   ToC   RFC6632 - Page 51
   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

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

   o  Security considerations for the XCAP protocol in Section 14 of

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.
Top   ToC   RFC6632 - Page 52
   o  Al Morton (AT&T) - contributed to the section on IP Performance

   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.

(page 52 continued on part 4)

Next Section