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
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
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
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
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)
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
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
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
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
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
[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
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
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
"RADIUS Accounting Server MIB for IPv6" [RFC4671] defines RADIUS
Accounting Server MIB objects that support version-neutral IP
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
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
"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
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-
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 18.104.22.168,
o User-based Security Model (USM) in Section 22.214.171.124,
o View-based Access Control Model (VACM) in Section 126.96.36.199,
o SNMP Transport Security Model in Section 188.8.131.52,
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
o Built-in and transport security for the Diameter Base Protocol in
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
o Security for Application Configuration Access Protocol (ACAP) in
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
o Security considerations for the ANCP protocol in Section 11 of
o Security considerations for the XCAP protocol in Section 14 of
Following persons made significant contributions to and reviewed this
o Ralph Droms (Cisco) - revised the section on IP Address Management
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
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.
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.