RFC 6632

An Overview of the IETF Network Management Standards

📅 published June 2012, from ietf

RFC 6632: An Overview of the IETF Network Management Standards 🎀

okay bestie, this is RFC 6632 and it's basically a big map of the IETF network management world 🗺️✨. It's Informational, so it's here to explain things and not to set any rules 🌸. The authors are M. Ersue (Ed.) from Nokia Siemens Networks and B. Claise from Cisco Systems, Inc. 💅. It came out in June 2012 and its ISSN is 2070-1721 🦋. The title block doesn't list any RFCs that it obsoletes or updates, so it's standing completely on its own 👑.

Abstract ✨

okay so this doc gives you an overview of the IETF network management standards and sums up what already exists and what's still being built for the Standards Track network management protocols and data models 🔥. It points you to other overview docs wherever they exist and sorts everything into groups so it's easier to find your way around 🧚. The whole point is to help system developers and users pick the right standard management protocols and data models for what they need 💖. It's also a guideline for other Standard Development Organizations or bodies that want to use IETF management tech and data models 🫶.

Also, this doc does not cover Operations, Administration, and Maintenance (OAM) tech on the data-path, like OAM for tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire, plus the management models that go with them 🙈. That's a whole different vibe, so it's out of scope here 💀.

Status of This Memo 📜

This doc is not an Internet Standards Track spec, it's just published for information 🌈.

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 💜. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. Not every doc the IESG approves is up for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details 🍓.

For the latest status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6632 🦋.

Copyright Notice 💅

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 📜. Please read these carefully, bestie, because they explain your rights and restrictions for this doc 🙈. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🔥.

Table of Contents 🧚

   1. Introduction ....................................................4
      1.1. Scope and Target Audience ..................................4
      1.2. Related Work ...............................................5
      1.3. Terminology ................................................6
   2. Core Network Management Protocols ...............................8
      2.1. Simple Network Management Protocol (SNMP) ..................8
           2.1.1. Architectural Principles of SNMP ....................8
           2.1.2. SNMP and Its Versions ...............................9
           2.1.3. Structure of Managed Information (SMI) .............11
           2.1.4. SNMP Security and Access Control Models ............12
                  2.1.4.1. Security Requirements on the SNMP
                           Management Framework ......................12
                  2.1.4.2. User-Based Security Model (USM) ...........12
                  2.1.4.3. View-Based Access Control Model (VACM) ....13
           2.1.5. SNMP Transport Subsystem and Transport Models ......13
                  2.1.5.1. SNMP Transport Security Model .............14
      2.2. Syslog Protocol ...........................................15
      2.3. IP Flow Information eXport (IPFIX) and Packet
           SAMPling (PSAMP) Protocols ................................16
      2.4. Network Configuration .....................................19
           2.4.1. Network Configuration Protocol (NETCONF) ...........19
           2.4.2. YANG - NETCONF Data Modeling Language ..............21
   3. Network Management Protocols and Mechanisms with
      Specific Focus .................................................23
      3.1. IP Address Management .....................................23
           3.1.1. Dynamic Host Configuration Protocol (DHCP) .........23
           3.1.2. Ad Hoc Network Autoconfiguration ...................24
      3.2. IPv6 Network Operations ...................................25
      3.3. Policy-Based Management ...................................26
           3.3.1. IETF Policy Framework ..............................26
           3.3.2. Use of Common Open Policy Service (COPS)
                  for Policy Provisioning (COPS-PR) ..................26
      3.4. IP Performance Metrics (IPPM) .............................27
      3.5. Remote Authentication Dial-In User Service (RADIUS) .......29
      3.6. Diameter Base Protocol (Diameter) .........................31
      3.7. Control and Provisioning of Wireless Access Points
           (CAPWAP) ..................................................35
      3.8. Access Node Control Protocol (ANCP) .......................36
      3.9. Application Configuration Access Protocol (ACAP) ..........36
      3.10. XML Configuration Access Protocol (XCAP) .................37
   4. Network Management Data Models .................................38
      4.1. IETF Network Management Data Models .......................39
           4.1.1. Generic Infrastructure Data Models .................39
           4.1.2. Link-Layer Data Models .............................40
           4.1.3. Network-Layer Data Models ..........................40
           4.1.4. Transport-Layer Data Models ........................40
           4.1.5. Application-Layer Data Models ......................41
           4.1.6. Network Management Infrastructure Data Models ......41
      4.2. Network Management Data Models - FCAPS View ...............41
           4.2.1. Fault Management ...................................42
           4.2.2. Configuration Management ...........................44
           4.2.3. Accounting Management ..............................45
           4.2.4. Performance Management .............................46
           4.2.5. Security Management ................................48
   5. Security Considerations ........................................49
   6. Contributors ...................................................51
   7. Acknowledgements ...............................................52
   8. Informative References .........................................52
   Appendix A. High-Level Classification of Management Protocols
               and Data Models .......................................77
     A.1. Protocols Classified by Standards Maturity in the IETF .....77
     A.2. Protocols Matched to Management Tasks ......................79
     A.3. Push versus Pull Mechanism .................................80
     A.4. Passive versus Active Monitoring ...........................80
     A.5. Supported Data Model Types and Their Extensibility  ........81
   Appendix B. New Work Related to IETF Management Standards .........83
     B.1. Energy Management (EMAN) ...................................83

1. Introduction 🦋

1.1. Scope and Target Audience 🍓

okay so this doc gives you an overview of the IETF network management standards and sums up the existing and ongoing work on Standards Track network management protocols and data models 💖. It points to other overview docs where they exist and sorts the standards into classes so you can find your way around easily ✨.

The main audience is, on one hand, IETF working groups that want to pick the right standard management protocols and data models for their network management needs 🧚. On the other hand, it's a guideline for non-IETF Standards Development Organizations (SDOs) that plan to use IETF management tech and data models to build management applications 🫶. It can also kick off a conversation between bodies so they can collect new requirements and spot possible gaps 🔥. And honestly, anyone who wants a snapshot of the current IETF network management protocols is welcome here, whether you're a network administrator or a total newcomer to the IETF 🌈.

Section 2 covers the core IETF network management standards, with a big focus on Simple Network Management Protocol (SNMP), syslog, IP Flow Information eXport / Packet SAMPling (IPFIX/PSAMP), and Network Configuration (NETCONF) 💜. Section 3 digs into IETF management protocols and mechanisms that have a specific focus, like IP address management or IP performance management 🎀. Section 4 looks at IETF data models, like MIB modules, IPFIX Information Elements, Syslog Structured Data Elements, and YANG modules, which are built to handle specific management problems 👑. It gives you two complementary views of the network management data models standardized in the IETF 🦋. Section 4.1 is the broader view, sorting models into categories like generic and infrastructure data models, plus data models matched to different layers 🧚. Section 4.2 flips it and organizes the data models by the management application view, mapping them to the network management tasks of fault, configuration, accounting, performance, and security management 💅.

Appendix A is your guide for picking management standards at a high level 🌸. It sorts the protocols by high-level criteria, like push versus pull mechanisms and passive versus active monitoring, and it also groups them by the network management task they address and how extensible their data models are 🔥. If you only care about some of the IETF network management protocols and data models in this doc, you can use Appendix A as a dispatcher that sends you to the right chapter 🙈. Appendix B gives you an overview of the new Energy Management work going on in the IETF ⭐.

This doc mainly refers to Proposed, Draft, or Internet Standard documents from the IETF (see [RFCSEARCH]) 📜. Best Current Practice (BCP) documents get referenced whenever they're useful 💖. In rare cases, if a doc gives really solid guidance on using a standard or fills an important gap, Experimental and Informational RFCs get a shout-out too, and so does ongoing work 🫶.

Info on active and concluded IETF working groups (like their charters, published or currently active docs, and mail archives) lives at [IETF-WGS]) 🧚.

Heads up, bestie: this doc does not cover OAM tech on the data-path, including MPLS forwarding plane and control plane protocols (like OAM for tunnels, MPLS-TP OAM, and pseudowire), or the management models and MIB modules that go with them 🙈. For a list of related work, check out Section 1.2 🦋.

okay that's part 1 of 19 🎀💖 next up is section 1.2 Related Work, so stay tuned, bestie 🫶✨

okay so the IETF has already written a bunch of overview docs about this stuff, and we're giving you the lay of the land 🗺️

"Internet Protocols for the Smart Grid" [RFC6272] is like the intro guide to the key protocols in the Internet Protocol Suite 🔌. In the same spirit, this document gives an overview of the IETF network management standards and how people actually use them 💅.

"Overview of the 2002 IAB Network Management Workshop" [RFC3535] wrote down the strengths and weaknesses of some IETF management protocols 📝. When you're picking existing protocols for management requirements, it is recommended that you consider those strengths and weaknesses. Some of the workshop's recommendations are outdated now, some got standardized, and some are still being worked on in the IETF, so it's not all old news 🙈.

"Guidelines for Considering Operations and Management of New Protocols and Extensions" [RFC5706] says working groups should think about operations and management needs and then pick suitable management protocols and data models 🧠. This document can help you survey the IETF Standards Track network management protocols and management data models without wanting to scream 😭.

"Multiprotocol Label Switching (MPLS) Management Overview" [RFC4221] describes the management architecture for MPLS and shows how the different MIB modules used for MPLS network management relate to each other 🦋. Then "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks" [RFC6371] covers the OAM Framework for MPLS-based Transport Networks 🎀.

"An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms" [OAM-OVERVIEW] walks through the OAM toolset for detecting and reporting connection failures or measuring connection performance parameters 🔍.

"An Overview of the OAM Tool Set for MPLS-based Transport Networks" [OAM-ANALYSIS] is the MPLS-based Transport Networks version 💜. It gives a brief summary of MPLS-TP OAM requirements and functions, plus the generic mechanisms created in the MPLS data plane so OAM packets can run in-band and share their fate with data packets 🫶. The protocol definitions for each MPLS-TP OAM tool live in separate documents, which are referenced there 📚.

"MPLS-TP MIB-based Management Overview" [MPLSTP-MIB] describes the MIB-based architecture for MPLS-TP ✨. It shows how existing MIB modules can be leveraged for MPLS-TP network management, and it points out where additional MIB modules are still required 🧚.

Quick tea ☕: so far, the IETF has not developed specific technologies for managing sensor networks 🙃. IP-based sensors or constrained devices in that kind of environment (we're talking very limited memory and CPU resources) can use, e.g., application-layer protocols to do simple resource management and monitoring 🌸.

1.3. Terminology 🎀

okay, the bestie rule here: this document does not describe standard requirements 💅. So key words from RFC 2119 [RFC2119] are not used in the document. No vibes of obligation, just vibes 🦋.

Here are the terms you'll see floating around, bestie:

3GPP: 3rd Generation Partnership Project, a collaboration between groups of telecommunications associations to prepare the third-generation (3G) mobile phone system specification 📱.
Agent: A software module that performs the network management functions requested by network management stations. An agent may be implemented in any network element that is to be managed, such as a host, bridge, or router 🖥️. It's the 'management server' in NETCONF terminology 🧚.
BCP: An IETF Best Current Practice document 🌈.
CLI: Command Line Interface, a management interface that system administrators can use to interact with networking equipment 💻.
Data model: A mapping of the contents of an information model into a form that is specific to a particular type of datastore or repository (see [RFC3444]) 🗂️.
Event: An occurrence of something in the "real world". Events can be indicated to managers through an event message or notification 🔔.
IAB: Internet Architecture Board 🏛️.
IANA: Internet Assigned Numbers Authority, an organization that oversees global IP address allocation, autonomous system number allocation, media types, and other IP-related code point allocations 🌍.
Information model: An abstraction and representation of entities in a managed environment, their properties, attributes, operations, and the way they relate to each other, independent of any specific repository, protocol, or platform (see [RFC3444]) 🧩.
ITU-T: International Telecommunication Union - Telecommunication Standardization Sector 📡.
Managed object: A management abstraction of a resource, a piece of management information in a MIB module. In the context of SNMP, it's a structured set of data variables that represent some resource to be managed or other aspect of a managed device 🍓.
Manager: An entity that acts in a manager role, either a user or an application. It's the counterpart to an agent, and it's the 'management client' in NETCONF terminology 👑.
Management Information Base (MIB): An information repository with a collection of related objects that represent the resources to be managed 📦.
MIB module: MIB modules usually contain object definitions, may contain definitions of event notifications, and sometimes include compliance statements in terms of appropriate object and event notification groups. A MIB that is provided by a management agent is typically composed of multiple instantiated MIB modules 🧁.
Modeling language: Any artificial language that can be used to express information, knowledge, or systems in a structure defined by a consistent set of rules. Examples are Structure of Management Information Version 2 (SMIv2) [STD58], XML Schema Definition (XSD) [XSD-1], and YANG [RFC6020] 💖.
Notification: An unsolicited message sent by an agent to a management station to notify it of an unusual event 🚨.
OAM: Operations, Administration, and Maintenance 🛠️.
PDU: Protocol Data Unit, a unit of data specified in a protocol of a given layer, consisting of protocol-control information and possibly layer-specific data 📬.
Principal: An application, an individual, or a set of individuals acting in a particular role, on whose behalf access to a service or MIB is allowed 🔐.
RELAX NG: REgular LAnguage for XML Next Generation, a schema language for XML [RELAX-NG] 🧾.
SDO: Standards Development Organization 🤝.
SMI: Structure of Managed Information, the notation and grammar for the managed information definition used to define MIB modules [STD58] 🔤.
STDnn: An Internet Standard published at IETF, also referred to as Standard, e.g., [STD62] ⭐.
URI: Uniform Resource Identifier, a string of characters used to identify a name or a resource on the Internet [STD66]. It can be classified as locators (URLs), as names (URNs), or as both 🔗.
XPATH: XML Path Language, a query language for selecting nodes from an XML document [XPATH] 🧭.

2. Core Network Management Protocols 👑

2.1. Simple Network Management Protocol (SNMP) 💜

2.1.1. Architectural Principles of SNMP ✨

okay this is the foundation, so pay attention 🫶. The SNMPv3 Framework [RFC3410] builds upon both the original SNMPv1 and SNMPv2 Frameworks 🏗️. The basic structure and components did not change between versions, and the framework is made up of the following components:

managed nodes, each with an SNMP entity providing remote access to management instrumentation (the agent),
at least one SNMP entity with management applications (the manager), and
a management protocol used to convey management information between the SNMP entities and management information.

Over time the fundamental architecture of the SNMP Management Framework stayed consistent, and it's built on a modular architecture 🧩. That architecture consists of:

a generic protocol definition independent of the data it is carrying,
a protocol-independent data definition language,
an information repository containing a data set of management information definitions (the Management Information Base, or MIB), and
security and administration.

So the following standards form the basis of the current SNMP Management Framework 💖:

the SNMPv3 protocol [STD62],
the modeling language SMIv2 [STD58], and
the MIB modules for different management issues.

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

building on these three basic architectural components, in some cases incorporating them from the SNMPv2 Framework by reference, and
using the same layering principles in the definition of new capabilities in the security and administration portion of the architecture.

2.1.2. SNMP and Its Versions ✨

okay so SNMP is built on three conceptual entities: the Manager, the Agent, and the Management Information Base (MIB) 💅. In any configuration, at least one manager node runs SNMP management software. Typically, network devices like bridges, routers, and servers are equipped with an agent 🖥️. The agent is responsible for providing access to a local MIB of objects that reflects the resources and activity at its node. so it's basically the device's diary 📖

Following the manager-agent paradigm, an agent can generate notifications and send them as unsolicited messages to the management application 🔔.

SNMPv2 levels up this basic functionality with an Inform PDU, a bulk transfer capability, and other functional extensions like an administrative model for access control, security extensions, and Manager-to-Manager communication 👑. SNMPv2 entities can have a dual role as manager and agent 🪞. However, neither SNMPv1 nor SNMPv2 offers sufficient security features 💀. To address the security deficiencies of SNMPv1/v2, SNMPv3 [STD62] has been issued 🔐.

"Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework" [BCP074] gives an overview of the relevant Standard documents on the three SNMP versions 📚. The BCP document furthermore describes how to convert MIB modules from SMIv1 to SMIv2 format and how to translate notification parameters. It also describes the mapping between the message processing and security models 🧩.

SNMP utilizes the MIB, a virtual information store of modules of managed objects 🗂️. Generally, standard MIB modules support common functionality in a device. Operators often define additional MIB modules for their enterprise, or use the Command Line Interface (CLI) to configure non-standard data in managed devices and their interfaces 🛠️.

SNMPv2 Trap and Inform PDUs can alert an operator or an application when some aspects of a protocol fail or encounter an error condition, and the contents of a notification can be used to guide subsequent SNMP polling to gather additional information about an event 🚨.

SNMP is widely used for the monitoring of fault and performance data, and with its stateless nature, SNMP also works well for status polling and determining the operational state of specific functionality 📊. The widespread use of counters in standard MIB modules permits the interoperable comparison of statistics across devices from different vendors 🤝. Counters have been especially useful in monitoring bytes and packets going in and out over various protocol interfaces 📦. SNMP is often used to poll a basic parameter of a device (e.g., sysUpTime, which reports the time since the last re-initialization of the network management portion of the device) to check for operational liveliness and to detect discontinuities in counters ⏱️. Some operators also use SNMP for configuration management in their environment (e.g., for systems based on Data Over Cable Service Interface Specification (DOCSIS) such as cable modems) 📡.

SNMPv1 [RFC1157] has been declared Historic, and its use is not recommended due to its lack of security features 🪦. "Introduction to Community-based SNMPv2" [RFC1901] is an Experimental RFC, which has been declared Historic, and its use is not recommended due to its lack of security features. same energy, different name 🙃

Use of SNMPv3 [STD62] is recommended due to its security features, including support for authentication, encryption, message timeliness and integrity checking, and fine-grained data access controls 🔒. An overview of the SNMPv3 document set is in [RFC3410] 🗺️.

Standards exist to use SNMP over diverse transport and link-layer protocols, including Transmission Control Protocol (TCP) [STD07], User Datagram Protocol (UDP) [STD06], Ethernet [RFC4789], and others (see Section 2.1.5.1) 🌐.

2.1.3. Structure of Managed Information (SMI) 🧱

SNMP MIB modules are defined with the notation and grammar specified as the Structure of Managed Information (SMI) 📝. The SMI uses an adapted subset of Abstract Syntax Notation One (ASN.1) [ITU-X680] 🔤.

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

Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the semantics of an information module 🏷️.
Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax and semantics of a managed object 🎯.
Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely convey the syntax and semantics of a notification 📣.

SMIv1 is specified in "Structure and Identification of Management Information for TCP/IP-based Internets" [RFC1155] and "Concise MIB Definitions" [RFC1212], both part of [STD16]. [RFC1215] specifies conventions for defining SNMP traps. Note that SMIv1 is outdated, and its use is not recommended 🙅‍♀️.

SMIv2 is the new notation for managed information definitions, and it should be used to define MIB modules 🌟. SMIv2 is specified in the following RFCs. With the exception of BCP 74, they are all part of [STD58]:

[RFC2578] defines Version 2 of the Structure of Management Information (SMIv2),
[RFC2579] defines the textual conventions macro for defining new types, and it provides a core set of generally useful textual convention definitions,
[RFC2580] defines conformance statements and requirements for defining agent and manager capabilities, and
[BCP074] defines the mapping rules for and the conversion of MIB modules between SMIv1 and SMIv2 formats 🔁.

2.1.4. SNMP Security and Access Control Models 🛡️

2.1.4.1. Security Requirements on the SNMP Management Framework 🕵️‍♀️

Several of the classical threats to network protocols are applicable to the management problem space, and therefore they are applicable to any security model used in an SNMP Management Framework 🧐. This section lists primary and secondary threats, and threats that are of lesser importance (see [RFC3411] for the detailed description of the security threats).

The primary threats against which SNMP Security Models can provide protection are "modification of information" by an unauthorized entity, and "masquerade," i.e., the danger that management operations not authorized for some principal may be attempted by assuming the identity of another principal 🎭.

Secondary threats against which SNMP Security Models can provide protection are "message stream modification," e.g., reordering, delay, or replay of messages, and "disclosure," i.e., the danger of eavesdropping on the exchanges between SNMP engines 👂.

There are two threats against which the SNMP Security Model does not protect, since they are deemed to be of lesser importance in this context: Denial of Service and Traffic Analysis (see [RFC3411]) 🙈.

2.1.4.2. User-Based Security Model (USM) 👤

SNMPv3 [STD62] introduced the User-based Security Model (USM). USM is specified in [RFC3414] and provides authentication and privacy services for SNMP 🔑. Specifically, USM is designed to secure against the primary and secondary threats discussed in Section 2.1.4.1. USM does not secure against Denial of Service and attacks based on Traffic Analysis 🚫.

The USM supports the following security services:

Data integrity is the provision of the property that data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non-maliciously 🧷.
Data origin authentication is the provision of the property that the claimed identity of the user on whose behalf received data was originated is supported 🪪.
Data confidentiality is the provision of the property that information is not made available or disclosed to unauthorized individuals, entities, or processes 🤫.
Message timeliness and limited replay protection is the provision of the property that a message whose generation time is outside of a specified time window is not accepted ⏰.

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

2.1.4.3. View-Based Access Control Model (VACM) 👀

SNMPv3 [STD62] introduced the View-based Access Control (VACM) facility. The VACM is defined in [RFC3415] and enables the configuration of agents to provide different levels of access to the agent's MIB 🪟. An agent entity can restrict access to a certain portion of its MIB, e.g., restrict some principals to view only performance-related statistics, or disallow other principals to read those performance-related statistics. An agent entity can also restrict the access to monitoring (read-only) as opposed to monitoring and configuration (read-write) of a certain portion of its MIB, e.g., allowing only a single designated principal to update configuration parameters 🔐✨.

VACM defines five elements that make up the Access Control Model: groups, security level, contexts, MIB views, and access policy. Access to a MIB module is controlled by means of a MIB view 🧠.

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

2.1.5. SNMP Transport Subsystem and Transport Models 🚚

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

SNMP Transport Subsystem [RFC5590] extends the original SNMP architecture and Transport Model, and enables the use of transport protocols to provide message security, unifying the administrative security management for SNMP and other management interfaces 🫶.

Transport Models are tied into the SNMP Framework through the Transport Subsystem. The Transport Security Model [RFC5591] has been designed to work on top of lower-layer, secure Transport Models 🧁.

The SNMP Transport Model defines an alternative to existing standard transport mappings described in [RFC3417], e.g., for SNMP over UDP; in [RFC4789] for SNMP over IEEE 802 networks; and in the Experimental RFC [RFC3430] defining SNMP over TCP 🦋.

2.1.5.1. SNMP Transport Security Model

okay so the SNMP Transport Security Model [RFC5591] is basically an alternative to the older SNMPv1 and SNMPv2 Community-based Security Models [BCP074] and the User-based Security Model [RFC3414] (which is part of [STD62]). it's giving "new option on the menu" 🎀

this model leans on one or more lower-layer security mechanisms to provide message-oriented security services 🔐 those services include authentication of the sender, encryption, timeliness checking, and data integrity checking. the whole vibe is protecting each message as it moves 💖

a secure Transport Model sets up an authenticated and possibly encrypted session between the Transport Models of two SNMP engines 🦋 once that transport-layer session exists, SNMP messages can be sent through it from one SNMP engine to the other. the new Transport Model also supports sending multiple SNMP messages through the same session, which amortizes the costs of establishing a security association. ngl that is so efficient, it's like sharing one fancy setup for a whole group hangout instead of rebuilding it every single time ✨

the Secure Shell (SSH) Transport Model [RFC5592] and the Transport Layer Security (TLS) Transport Model [RFC6353] are the current examples of Transport Security Models 🌈

the SSH Transport Model makes use of the commonly deployed SSH security and key-management infrastructure 🔑 on top of that, [RFC5592] defines MIB objects for monitoring and managing the SSH Transport Model for SNMP. 🧚

the TLS Transport Model [RFC6353] uses either the TLS protocol [RFC5246] or the Datagram Transport Layer Security (DTLS) protocol [RFC6347] 💜 both of those give authentication and privacy services for SNMP applications. the TLS Transport Model supports sending SNMP messages over TLS and TCP, and over DTLS and UDP. [RFC6353] also defines MIB objects for managing the TLS Transport Model for SNMP 🫶

[RFC5608] describes the use of a Remote Authentication Dial-In User Service (RADIUS) service by SNMP secure Transport Models for authentication of users and authorization of services 🍓 then there's access control authorization, meaning how RADIUS attributes and messages get applied to the SNMP Access Control Models area, and VACM in particular. that part is specified in [RFC6065] 💅

2.2. Syslog Protocol

okay syslog, let's go 🌸 Syslog is a mechanism for distributing logging information, and it was first used on Unix systems (see [RFC3164] for BSD syslog) 🖥️ the IETF Syslog Protocol [RFC5424] brings in a layered architecture, so you can use any number of transport protocols for sending syslog messages, including reliable and secure transports ✨

the Syslog protocol lets a machine send system log messages across networks to event message collectors. honestly it's a super simple design, because its whole job is to transport and distribute those event messages 📬 by default, no acknowledgements of receipt are sent, unless the reliable delivery extensions in [RFC3195] are being used 🙈 the Syslog protocol and process also doesn't need strict coordination between the transport sender and receiver. like, transmission of syslog messages can start on a device with no receiver configured, or even one that isn't physically present 💀 and the flip side is that lots of devices can receive messages without any explicit configuration or definitions 🦋

BSD syslog had very little uniformity in its message format and content 😭 the body of a BSD syslog message has traditionally been unstructured text. that content is human friendly but hard for applications to parse. so with the Syslog Protocol [RFC5424], the IETF standardized a new message header format, including timestamp, hostname, application, and message ID. the goal is better filtering, interoperability, and correlation between compliant implementations 👑

the Syslog protocol [RFC5424] also introduces a mechanism for defining Structured Data Elements (SDEs) 💖 SDEs let vendors define their own structured data elements to supplement the standardized ones.

now for the SNMP and syslog crossover 🎀 [RFC5675] defines a mapping from SNMP notifications to syslog messages. [RFC5676] defines an SNMP MIB module that represents syslog messages, so they can be sent as notifications to SNMP notification receivers 🔥 [RFC5674] defines how alarms are sent in syslog. that includes mapping ITU-perceived severities onto syslog message fields, plus a number of alarm-specific definitions from ITU-T X.733 [ITU-X733] and the IETF Alarm MIB [RFC3877] 🌈

"Signed Syslog Messages" [RFC5848] defines a mechanism that adds origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to transmitted syslog messages. it's meant to be used in conjunction with the Syslog protocol 🔐 main character energy for sure ⭐

the Syslog protocol's layered architecture supports a number of transport mappings 🧚 for interoperability, and especially in managed networks where the network path has been explicitly provisioned for UDP syslog traffic, the Syslog protocol can be used over UDP [RFC5426]. however, to support congestion control and reliability, [RFC5426] strongly recommends using the TLS transport 🫶

the IETF also defined the TLS Transport Mapping for syslog in [RFC5425], which provides a secure connection for transporting syslog messages 🦋 [RFC5425] describes the security threats to syslog and how TLS can counter them. and [RFC6012] defines the Datagram Transport Layer Security (DTLS) Transport Mapping for syslog, which can be used when a connectionless transport is desired 💜

for information on MIB modules related to syslog, see Section 4.2.1 🍓

2.3. IP Flow Information eXport (IPFIX) and Packet SAMPling (PSAMP) Protocols

okay so the IPFIX Protocol spec, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information" (the IPFIX Protocol) [RFC5101], is all about a push-based export mechanism 💌. It moves IP flow information from an Exporter to a Collector in a compact binary format. ✨

Then there's "Architecture for IP Flow Information Export" (the IPFIX Architecture) [RFC5470], which lays out the cast 🎀. There's a Metering Process that generates Flow Records, an Exporting Process that sends the metered flow information using the IPFIX protocol, and a Collecting Process that receives that flow information as IPFIX Data Records. 🧩

After the IPFIX requirements were listed in [RFC3917], NetFlow Version 9 [RFC3954] was taken as the basis for the IPFIX protocol and the IPFIX architecture. NetFlow really is the blueprint here 💅.

IPFIX can run over different transport protocols 🚚. The IPFIX Protocol [RFC5101] specifies Stream Control Transmission Protocol (SCTP) [RFC4960] as the mandatory transport protocol to implement. Optional alternatives are TCP [STD07] and UDP [STD06].

SCTP is used with its Partial Reliability extension (PR-SCTP) specified in [RFC3758] 🦋. [RFC6526] specifies an extension to [RFC5101] when using PR-SCTP [RFC3758]. The extension offers several advantages over IPFIX export, e.g., the ability to calculate Data Record losses for PR-SCTP, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. Honestly, that's a glow-up 🌸.

IPFIX transmits IP flow information in Data Records containing IPFIX Information Elements (IEs) defined by the IPFIX Information Model [RFC5102] 📦. IPFIX IEs are quantities with a unit and semantics defined by the Information Model. When they go over the IPFIX protocol, only their values need to be carried in Data Records, and that compact encoding is what lets large numbers of measured flow values travel efficiently 🔥. Any leftover redundancy in Data Records can be reduced further by the methods described in [RFC5473] (for further discussion on IPFIX IEs, see Section 4).

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

The PSAMP protocol [RFC5476] extends the IPFIX protocol by transferring information on individual packets 🔍. [RFC5475] specifies a set of sampling and filtering techniques for IP packet selection, based on the PSAMP Framework [RFC5474]. The PSAMP Information Model [RFC5477] provides a set of basic IEs for reporting packet information with the IPFIX/PSAMP protocol.

The IPFIX model of an IP traffic flow is unidirectional ➡️. [RFC5103] adds ways to report bidirectional flows to IPFIX, for example, both directions of packet flows of a TCP connection.

When enterprise-specific IEs are transmitted with IPFIX, a Collector receiving Data Records may not know what type of data it got, so it can't pick the right format for storing the info 🤷‍♀️. [RFC5610] provides a way of exporting extended type information for enterprise-specific Information Elements from an Exporter to a Collector. Problem solved, bestie 🫶.

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

Now, configuration 🎛️. The Metering and Exporting Processes are configured out of band. Since the IPFIX protocol is a push mechanism only, IPFIX cannot configure the Exporter. The actual configuration of selection processes, caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant monitoring devices is done using the NETCONF protocol [RFC6241] (see Section 2.4.1). The "Configuration Data Model for IPFIX and PSAMP" (the IPFIX Configuration Data Model) [CONF-MODEL] has been specified using Unified Modeling Language (UML) class diagrams. The data model is formally defined using the YANG modeling language [RFC6020] (see Section 2.4.2).

At the time of writing, a framework for IPFIX flow mediation is in preparation 🛠️. It addresses the need for mediation of flow information in IPFIX applications in large operator networks, e.g., for aggregating huge amounts of flow data and for anonymization of flow information (see the problem statement in [RFC5982]).

The IPFIX Mediation Framework [RFC6183] defines the intermediate device between Exporters and Collectors. It provides IPFIX mediation by receiving a record stream from, e.g., a Collecting Process, hosting one or more Intermediate Processes to transform that stream, and exporting the transformed record stream into IPFIX messages via an Exporting Process. Examples of mediation functions are flow aggregation, flow selection, and anonymization of traffic information (see [RFC6235]).

Security check! 🚨 Privacy, integrity, and authentication of the Exporter and Collector are important security requirements for IPFIX [RFC3917]. Confidentiality, integrity, and authenticity of IPFIX data transferred from an Exporting Process to a Collecting Process must be ensured. The IPFIX and PSAMP protocols do not define any new security mechanisms and rely on the security mechanism of the underlying transport protocol, such as TLS [RFC5246] and DTLS [RFC6347]. Don't skip this one, it's serious 😭.

The primary goal of IPFIX is reporting flow accounting for flexible flow definitions and usage-based accounting 💰. As described in the IPFIX Applicability Statement [RFC5472], there are other applications too, like traffic profiling, traffic engineering, intrusion detection, and QoS monitoring, that need flow-based traffic measurements and can be realized using IPFIX. The IPFIX Applicability Statement also explains how IPFIX relates to other frameworks and protocols, such as PSAMP, RMON (Remote Network Monitoring MIB, Section 4.2.1), and IPPM (IP Performance Metrics, Section 3.4). Similar flow information could also be used for security monitoring. And once performance metrics are added to the IPFIX IANA registry [IANA-IPFIX], IPFIX gets to stretch into performance management 📈.

Even though IPFIX started out focused on IP flow information exchange, non-IP-related IEs are now specified in the IPFIX IANA registration (e.g., MAC (Media Access Control) address, MPLS (Multiprotocol Label Switching) labels, etc.) 🌐. At the time of writing, there are requests to widen IPFIX's focus and export non-IP-related IEs, such as SIP monitoring IEs.

The IPFIX structured data [RFC6313] is an extension to the IPFIX protocol that supports hierarchical structured data and lists (sequences) of Information Elements in Data Records 🧱. It allows complex data structures such as variable-length lists and the specification of hierarchical containment relationships between templates. It also provides the semantics to express the relationship among multiple list elements in a structured Data Record.

For info on data models related to managing the IPFIX and PSAMP protocols, see Sections 4.2.1 and 4.2.2. For info on IPFIX/PSAMP IEs, see Section 4.2.3 📚.

2.4. Network Configuration

2.4.1. Network Configuration Protocol (NETCONF)

The IAB workshop on Network Management [RFC3535] came up with advanced requirements for configuration management 📝. Here's the wishlist:

robustness: minimizing disruptions and maximizing stability,
a task-oriented view,
extensibility for new operations,
standardized error handling,
a clear distinction between configuration data and operational state,
distribution of configurations to devices under transactional constraints,
single- and multi-system transactions and scalability in the number of transactions and managed devices,
operations on selected subsets of management data,
dumping and reloading a device configuration in a textual format in a standard manner across multiple vendors and device types,
a human interface and a programmatic interface,
a data modeling language with a human-friendly syntax,
easy conflict detection and configuration validation, and
secure transport, authentication, and robust access control.

The NETCONF protocol [RFC6241] gives you mechanisms to install, manipulate, and delete the configuration of network devices, and it aims to address the configuration management requirements from the IAB workshop 🎯. It uses XML-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple and reliable Remote Procedure Call (RPC) layer. A key aspect of NETCONF is that it lets the management protocol closely mirror the device's native command-line interface, which is so iconic 💻.

The NETCONF working group developed the NETCONF Event Notifications Mechanism as an optional capability 🔔. It provides an asynchronous message notification delivery service for NETCONF [RFC5277]. The notification mechanism enables general purpose notification streams, where the originator of the notification stream can be any managed device (e.g., SNMP notifications).

The NETCONF Partial Locking specification brings fine-grained locking of the configuration datastore 🔒. It enhances NETCONF for fine-grained transactions on parts of the datastore [RFC5717].

The NETCONF working group also defined the data model needed to monitor the NETCONF protocol [RFC6022], using the modeling language YANG [RFC6020] (see Section 2.4.2) 👀. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics, which helps manage a NETCONF server.

NETCONF connections are required to provide authentication, data integrity, confidentiality, and replay protection 🛡️. NETCONF depends on the underlying transport protocol for this capability. For example, connections can be encrypted in TLS or SSH, depending on the underlying protocol.

The NETCONF working group defined the SSH transport protocol as the mandatory transport binding [RFC6242] 🔐. Other optional transport bindings are TLS [RFC5539], Blocks Extensible Exchange Protocol (BEEP) over TLS [RFC4744], and Simple Object Access Protocol (SOAP) over HTTP over TLS [RFC4743].

Last but not least, the NETCONF Access Control Model (NACM) [RFC6536] provides standard mechanisms to restrict protocol access for particular users to a pre-configured subset of operations and content 🧚.

2.4.2. YANG - NETCONF Data Modeling Language 💅

okay so following the IAB management workshop guidelines [RFC3535], the NETMOD working group built a data modeling language that defines the semantics of operational and configuration data, notifications, and operations [RFC6020] 🎀 It's called YANG, and it maps directly to XML-encoded content on the wire, so it's the normative description of NETCONF data models. literally the main character of this whole section 👑

YANG has a bunch of properties that address specific requirements a modeling language needs for configuration management, and they're so good 😭

YANG gives you the means to define hierarchical data models. It supports reusable data types and groupings, meaning a set of schema nodes you can reuse across module boundaries. copy-paste who?? 🧚
YANG supports the distinction between configuration and state data. On top of that, it handles modeling event notifications and specifying operations that extend the base NETCONF operations 🦋
YANG lets you express constraints on data models using type restrictions and XML Path Language (XPATH) 1.0 [XPATH] expressions. XPATH expressions can also make certain portions of a data model conditional. very precise, very iconic 💅
YANG supports integrating standard-defined and vendor-defined data models. Its augmentation mechanism lets you seamlessly augment standard data models with proprietary extensions. the way that's so smooth 😭✨
YANG data models can be partitioned into collections of features. That means low-end devices can implement just the core features of a data model, while high-end devices can choose to support everything 🌸 The supported features get announced to management applications through the NETCONF capability exchange.
The syntax of YANG is compact and optimized for human readers 🫶 There's also an associated XML-based syntax called the YANG Independent Notation (YIN) [RFC6020] so you can process YANG data models with XML-based tools. The mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), where RELAX NG is a major component, are defined in [RFC6110].
Devices that implement standard data models can document deviations from those models in separate YANG modules. Applications that can discover deviations can make allowances that would otherwise not be possible. bestie, that's such a clever safety net 🍓

A collection of common data types for IETF-related standards is provided in [RFC6021] ✨ This standard data type library was derived to a large extent from common SMIv2 data types, generalized so it fits the less-constrained NETCONF Framework. it's giving evolution energy 🌈

The document "An Architecture for Network Management using NETCONF and YANG" describes how NETCONF and YANG can be used to build network management applications that meet the needs of network operators [RFC6244] 📚

The Experimental RFC [RFC6095] specifies extensions for YANG, introducing language abstractions such as class inheritance and recursive data structures. ngl that's a wild plot twist 🙈

[RFC6087] gives guidelines for using YANG within the IETF and other standardization organizations 💜

Work is underway to standardize a translation of SMIv2 data models into YANG data models. The goal is to preserve investments in SNMP MIB modules, which are widely available for monitoring purposes [SMI-YANG] 🦋 no wasted effort, periodt!

Several independent and open source implementations of the YANG data modeling language and its associated tools are available 🔥

YANG is a relatively recent data modeling language, but some data models have already been produced ✨ The specification of the base NETCONF protocol operations has been revised, and it uses YANG as the normative modeling language to specify its operations [RFC6241]. The IPFIX working group also prepared the normative model for configuring and monitoring IPFIX- and PSAMP-compliant monitoring devices using YANG [CONF-MODEL] 🎀

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

For information on data models developed using the YANG modeling language, see Sections 4.2.1 and 4.2.2 💖

3. Network Management Protocols and Mechanisms with Specific Focus 🌈

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

3.1. IP Address Management 🦋

3.1.1. Dynamic Host Configuration Protocol (DHCP) 💅

Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a framework for passing configuration information to hosts on a TCP/IP network. That's what makes autoconfiguration in IP networks possible 🧚 Beyond IP address management, DHCP can also hand out other configuration information, like default routers, the IP addresses of recursive DNS servers, and the IP addresses of NTP servers. As described in [RFC6272], DHCP can be used for IPv4 and IPv6 Address Allocation and Assignment, as well as for Service Discovery 🫶

There are two versions of DHCP: one for IPv4 (DHCPv4) [RFC2131] and one for IPv6 (DHCPv6) [RFC3315]. DHCPv4 was defined as an extension to BOOTP (Bootstrap Protocol) [RFC0951]. DHCPv6 came later to accommodate new functions required by IPv6, like assigning multiple addresses to an interface, and to address limitations in DHCPv4's design that came from its BOOTP origins 🌸 Both versions bear the same name and perform the same functionality, but the details of DHCPv4 and DHCPv6 are different enough that they can be considered separate protocols. two protocols, one name, very dramatic 🙈

On top of assigning IP addresses and other configuration information, DHCP options like the Relay Agent Information option (DHCPv4) [RFC3046] and the Interface-Id Option (DHCPv6) [RFC3315] are widely used by ISPs 💜

DHCPv6 includes Prefix Delegation [RFC3633], which is used to provision a router with an IPv6 prefix for use in the subnetwork that router supports 🔥

The following are examples of DHCP options that provide configuration information or access to specific servers. A complete list of DHCP options is available at [IANA-PROT] ✨

"DNS Configuration options for Dynamic Host Configuration Protocol for IPV6 (DHCPv6)" [RFC3646] describes DHCPv6 options for passing a list of available DNS recursive name servers and a domain search list to a client.
"DHCP Options for Service Location Protocol" [RFC2610] describes DHCPv4 options and methods through which entities using the Service Location Protocol can find the address of Directory Agents, so they can transact messages. It also covers how the assignment of scope for configuring Service Location Protocol (SLP) User and Service Agents can be achieved 🦋
"Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers" [RFC3319] specifies DHCPv6 options that let SIP clients locate a local SIP server to be used for all outbound SIP requests, a so-called "outbound proxy server" 🎀
"Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers" [RFC4280] defines DHCPv6 options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network 🌈

Heads up: built directly on UDP and IP, DHCP itself has no security provisions 💀 There are two different classes of potential security issues related to DHCP: unauthorized DHCP Servers and unauthorized DHCP Clients. The recommended solutions to these risks generally involve providing security at lower layers. For example, you can carefully control physical access to the network, and security techniques implemented at Layer 2 can be used, but IPsec at Layer 3 can also be used to provide authentication 😭🔥

3.1.2. Ad Hoc Network Autoconfiguration 🌸

Ad hoc nodes need to configure their network interfaces with locally unique addresses, as well as globally routable IPv6 addresses, so they can communicate with devices on the Internet 🧚 The IETF AUTOCONF working group developed [RFC5889], which describes the addressing model for ad hoc networks and how nodes in these networks configure their addresses 💖

The ad hoc nodes under consideration are expected to support multi-hop communication by running MANET (Mobile Ad Hoc Network) routing protocols, as developed by the IETF MANET working group 🦋

From the IP layer perspective, an ad hoc network presents itself as a Layer 3 multi-hop network formed over a collection of links. The addressing model aims to avoid problems for parts of the system that are ad hoc unaware, like standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes 🫶 it's giving backwards compatibility, iconic 👑

3.2. IPv6 Network Operations 🌈

The IPv6 Operations (V6OPS) working group develops guidelines for operating a shared IPv4/IPv6 Internet. It also provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations 💅

"Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213] specifies IPv4 compatibility mechanisms for dual-stack and configured tunneling that can be implemented by IPv6 hosts and routers. "Dual stack" means providing complete implementations of both IPv4 and IPv6, and configured tunneling provides a way to carry IPv6 packets over unmodified IPv4 routing infrastructures 🎀
"Transition Scenarios for 3GPP Networks" [RFC3574] lists different scenarios in 3GPP defined packet networks that would need IPv6 and IPv4 transition. "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks" [RFC4215] does a more detailed analysis of the transition scenarios that may come up in the deployment phase of IPv6 in 3GPP packet networks 🌸
"Scenarios and Analysis for Introducing IPv6 into ISP Networks" [RFC4029] describes and analyzes different scenarios for introducing IPv6 into an ISP's existing IPv4 network. "IPv6 Deployment Scenarios in 802.16 Networks" [RFC5181] provides a detailed description of IPv6 deployment, integration methods, and scenarios in wireless broadband access networks (802.16) coexisting with deployed IPv4 services. [RFC4057] describes the scenarios for IPv6 deployment within enterprise networks 🦋
"Application Aspects of IPv6 Transition" [RFC4038] specifies scenarios and application aspects of IPv6 transition, considering how to enable IPv6 support in applications running on IPv6 hosts, and giving guidance for developing IP-version-independent applications 💜
"IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] updates RFC 5735 and requested the allocation of an IPv4/10 address block to be used as "Shared Carrier-Grade Network Address Translation (CGN) Space" by Service Providers. That block numbers the interfaces that connect CGN devices to Customer Premises Equipment (CPE) 🔥✨

3.3. Policy-Based Management 🧚

3.3.1. IETF Policy Framework ✨

okay so the IETF came up with a general policy framework [RFC2753] for managing, sharing, and reusing policies 💅 the vibe is vendor-independent, interoperable, and scalable, so nobody gets locked into one brand 🫶 [RFC3460] defines the Policy Core Information Model (PCIM), which is an object-oriented information model for representing policy info 🧚 PCIM was built together in the IETF Policy Framework (POLICY) working group and the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF), and it's been published as extensions to CIM [DMTF-CIM] 🌈

the framework is based on policy-based admission control, and it has two main pieces: the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP) 👑 for network management, policies let an operator describe how the network should be configured and monitored using a descriptive language 💖 it also automates a bunch of management tasks, as long as they follow the requirements in the policy module 🔥

the industry is obsessed with it, ngl 😭 it's been accepted as a standard-based policy management approach, and different SDOs have adopted it, like the 3GGP charging standards 🎀

3.3.2. Use of Common Open Policy Service (COPS) for Policy Provisioning (COPS-PR) 💜

[RFC3159] defines the Structure of Policy Provisioning Information (SPPI), which is an extension to the SMIv2 modeling language used to write Policy Information Base (PIB) modules 🦋 COPS-PR [RFC3084] uses the Common Open Policy Service (COPS) protocol [RFC2748] to provision policy information 🍓 COPS gives you a simple client/server model for policy control over QoS signaling protocols 🌸 the COPS-PR spec doesn't care what kind of policy is being provisioned (QoS, security, etc.) and instead focuses on the mechanisms and conventions for moving provisioned info between policy-decision-points (PDPs) and policy enforcement points (PEPs) ✨ the policy data itself is modeled with PIB modules 🧚

but here's the tea 🫢 COPS-PR hasn't been widely deployed. Operators said its binary encoding for management data makes it really hard to write automated scripts for simple config tasks in most text-based scripting languages 💀 at the IAB Workshop on Network Management [RFC3535], operators and protocol developers agreed they weren't into PIB modules for COPS-PR either 🙈

so even though COPS-PR and SPPI were first approved as Proposed Standards, the IESG hasn't approved any PIB modules as Proposed Standard, and the use of COPS-PR is not recommended 😭🥀

3.4. IP Performance Metrics (IPPM) 🦋

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

these metrics are made for network operators and their customers, and they give unbiased quantitative measures of performance ✨ they were developed in an active measurement context, meaning the devices doing the measuring produce their own traffic 🫶 most of them can also be used in a passive context, though nobody's planning any passive measurement work right now, at least as of writing 👑

individual IPPM performance and reliability metrics need to be well defined and concrete, so they're implementable 🔥 the methodology used to implement a metric also needs to be repeatable with consistent measurements 💖

IPPMs have been adopted by different organizations, like the Metro Ethernet Forum 🎀

heads up, this document doesn't try to cover OAM technologies on the data path 🙈 so the discussion of IPPM-based active vs. passive monitoring, plus data plane measurement and diagnostics, is kinda incomplete 😅 if you want the full overview of IETF OAM standards and IPPM measurement mechanisms, check the documents listed at the end of Section 1.2 ("Related Work"), especially [OAM-OVERVIEW] 🧚

these are the essential IPPM documents:

"Framework for IP Performance Metrics" [RFC2330] defines a general framework for particular metrics developed by the IPPM working group, and it defines the fundamental concepts of 'metric' and 'measurement methodology'. It also discusses measurement uncertainties and errors, introduces empirically defined metrics, and explains how metrics can be composed. 🌸
"A One-way Delay Metric for IPPM" [RFC2679] defines a metric for the one-way delay of packets across Internet paths. It builds on notions introduced in the IPPM Framework document. 💜
"A Round-trip Delay Metric for IPPM" [RFC2681] defines a metric for the round-trip delay of packets across network paths, and it closely follows the corresponding one-way delay metric. 🍓
"IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)" [RFC3393] refers to a metric for variation in the delay of packets across network paths, based on the difference in the one-way-delay of selected packets called "IP Packet Delay Variation (ipdv)". ✨
"A One-way Packet Loss Metric for IPPM" [RFC2680] defines a metric for one-way packet loss across Internet paths. 🫶
"A One-Way Packet Duplication Metric" [RFC5560] defines a metric for the case where multiple copies of a packet are received, and it discusses ways to summarize the results of streams. 👑
"Packet Reordering Metrics" [RFC4737] defines metrics for evaluating whether a network has kept packets in order, packet by packet. It also discusses measurement issues, including the context information required for all metrics. 🔥
"IPPM Metrics for Measuring Connectivity" [RFC2678] defines a series of metrics for connectivity between a pair of Internet hosts. 🧚
"Framework for Metric Composition" [RFC5835] describes a detailed framework for composing and aggregating metrics. 🌈
"Guidelines for Considering New Performance Metric Development" [BCP170] describes the framework and process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols. 💅

to measure these metrics, two protocols and a sampling method have been standardized:

"A One-way Active Measurement Protocol (OWAMP)" [RFC4656] measures unidirectional characteristics like one-way delay and one-way loss between network devices, and it makes these measurements interoperable. OWAMP is covered in more detail in [OAM-OVERVIEW]. 🦋
"A Two-Way Active Measurement Protocol (TWAMP)" [RFC5357] adds round-trip or two-way measurement capabilities to OWAMP. TWAMP is covered in more detail in [OAM-OVERVIEW]. 🌸
"Network performance measurement with periodic streams" [RFC3432] describes a periodic sampling method and relevant metrics for assessing the performance of IP networks, as an alternative to the Poisson sampling method described in [RFC2330]. 💖

for info on MIB modules related to IP Performance Metrics, see Section 4.2.4. 🎀

3.5. Remote Authentication Dial-In User Service (RADIUS) 🎀

okay so RADIUS is literally a client/server protocol that carries authentication, authorization, and configuration info between a Network Access Server (NAS), the one that wants to authenticate its links, and a shared authentication server 💅. The main spec is "Remote Authentication Dial In User Service (RADIUS)" [RFC2865]. Its companion, "Radius Accounting" [RFC2866], handles accounting info between a NAS and a shared accounting server ✨. Then [RFC2867] adds required new RADIUS accounting attributes and new values for tunneling in dial-up networks 🦋.

RADIUS is seriously popular in places like enterprise networks, where one administrative authority runs the whole network and keeps user info private 🔒. It's also deployed in the networks of fixed broadband access providers and cellular broadband operators. It's everywhere, bestie 🌈.

RADIUS carries its details in attributes 🧚. It's extensible, but there's a known limit: a maximum of 255 attribute codes and 253 octets of attribute content length. RADIUS also has Vendor-Specific Attributes (VSAs) 💜. People use those for vendor-specific stuff (on top of the standard attributes) and also to stretch that limited attribute code space. Clever, right? 😭

RADIUS uses a shared secret plus the MD5 hash algorithm to protect passwords [RFC1321]. Based on the known threats, extra protection like IPsec tunnels [RFC4301] gets used to guard RADIUS traffic too. ngl though, building and running big IPsec-protected networks can turn into a management headache 💀, especially when that IPsec-protected RADIUS setup has to provide inter-provider connectivity. So the trend is moving toward TLS-based security [RFC5246] and setting up dynamic trust relationships between RADIUS servers 🔥. Once TCP transport for RADIUS arrived [RFC6613], TLS support for RADIUS just felt natural. There's ongoing work on "Transport Layer Security (TLS) encryption for RADIUS" [RFC6614] 🫶.

"RADIUS Attributes for Tunnel Protocol Support" [RFC2868] defines a bunch of RADIUS attributes for compulsory tunneling in dial-up network access 🚇. Compulsory tunneling is when the tunnel gets created with zero action from the user and zero choice on their part. To make that work, RADIUS needs specific attributes that carry the tunneling info from the RADIUS server to the tunnel endpoints. "Signalling Connection Control Part User Adaptation Layer (SUA)" [RFC3868] defines those necessary attributes, their values, and the required IANA registries 📋.

"RADIUS and IPv6" [RFC3162] covers how RADIUS runs over IPv6 and the attributes used to support IPv6 network access 🌸. "RADIUS Delegated-IPv6-Prefix Attribute" [RFC4818] explains how to transport delegated IPv6 prefix info over RADIUS ✨.

"RADIUS Attributes for Virtual LAN and Priority Support" [RFC4675] adds attributes for dynamic Virtual LAN assignment and prioritization, used for provisioning access to IEEE 802 local area networks with RADIUS and diameter 🌈.

"Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] calls out common RADIUS implementation problems and suggests fixes. Where it applies, it clarifies unclear statements and errors from earlier RADIUS specs 🙈. If you're designing RADIUS extensions for different deployment cases, you should get familiar with "RADIUS Design Guidelines" [RFC6158] so you can dodge things like known interoperability challenges, e.g., 😤.

"RADIUS Extension for Digest Authentication" [RFC5090] adds Digest Authentication support to RADIUS, for HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP 🧚‍♀️.

"Carrying Location Objects in RADIUS and DIAMETER" [RFC5580] describes how to convey access-network ownership and location info, based on civic and geospatial location formats, in RADIUS and diameter 📍.

"Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management" [RFC5607] specifies the required RADIUS attributes and their values for authorizing management access to a NAS 👑. Both local and remote management are supported, with access rights and management privileges. There are special provisions for remote management through Framed Management protocols like SNMP and NETCONF, plus management access over a secure transport protocol 🔐.

"RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)" [RFC3579] explains how to use RADIUS to carry an EAP [RFC3748] payload between the authenticator and the EAP server 🦋. RFC 3579 is widely implemented, for example in WLAN and 802.1 X environments 📶. "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines" [RFC3580] covers how to use RADIUS with IEEE 802.1X authenticators 💖. In the 802.1X and EAP-based authentication world, the VSAs described in [RFC2458] have been widely accepted by the industry 🙌. "RADIUS Extensions" [RFC2869] is another big RFC for EAP use. It describes additional attributes for carrying AAA info between a NAS and a shared accounting server using RADIUS, and it also defines attributes to encapsulate EAP message payloads 🎀.

There are different MIB modules defined for multiple purposes to use with RADIUS (see Sections 4.2.3 and 4.2.5) 📚✨.

3.6. Diameter Base Protocol (Diameter) 💖

Okay bestie, Diameter [RFC3588] gives you an Authentication, Authorization, and Accounting (AAA) framework for stuff like network access or IP mobility 🦋. It's also meant to work in local AAA and in roaming scenarios 🌍. Diameter provides an upgrade path for RADIUS, but it is not directly backwards compatible 💀.

Diameter was built to fix a bunch of known RADIUS problems ✨. It supports server failover, reliable transport over TCP and SCTP, well-documented functions for proxy, redirect and relay agent functions, server-initiated messages, auditability, and capability negotiation 🔥. It also has a way bigger attribute space for Attribute-Value Pairs (AVPs) and identifiers than RADIUS does 👑. These features make Diameter especially iconic for environments where the providers of services are in different administrative domains than the maintainer (protector) of confidential user information 🫶.

Other notable differences from RADIUS:

Network and Transport Layer Security (IPsec or TLS) 🔐
Stateful and stateless models 🧚
Dynamic discovery of peers (using DNS Service Record (SRV) and Naming Authority Pointer (NAPTR)) 🌸
Concept of an application that describes how a specific set of commands and Attribute-Value Pairs (AVPs) are treated by diameter nodes. Each application has an IANA-assigned unique identifier 🍓
Support of application layer acknowledgements, failover methods and state machines 💅
Basic support for user-sessions and accounting 💜
Better roaming support 🌈
Error notification, and 🚨
Easy extensibility 🎀

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

The Diameter application identifier space has been split into Standards Track and 'First Come First Served' vendor-specific applications 🦄. Here are some Diameter applications published at the IETF:

Diameter Base Protocol Application [RFC3588]: Required support from all Diameter implementations. 👑
Diameter Base Accounting Application [RFC3588]: A Diameter application using an accounting protocol based on a server-directed model with capabilities for real-time delivery of accounting information. 🧾
Diameter Mobile IPv4 Application [RFC4004]: A Diameter application that allows a Diameter server to authenticate, authorize, and collect accounting information for Mobile IPv4 services rendered to a mobile node. 📱
Diameter Network Access Server Application (NASREQ, [RFC4005]): A Diameter application used for AAA services in the NAS environment. 🛜
Diameter Extensible Authentication Protocol Application [RFC4072]: A Diameter application that carries EAP packets between a NAS and a back-end authentication server. 🔑
Diameter Credit-Control Application [RFC4006]: A Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. 💸
Diameter Session Initiation Protocol Application [RFC4740]: A Diameter application designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. 📞
Diameter Quality-of-Service Application [RFC5866]: A Diameter application allowing network elements to interact with Diameter servers when allocating QoS resources in the network. 🚀
Diameter Mobile IPv6 IKE (MIP6I) Application [RFC5778]: A Diameter application that enables the interaction between a Mobile IP home agent and a Diameter server and is used when the mobile node is authenticated and authorized using IKEv2 [RFC5996]. 🦋
Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778]: A Diameter application that enables the interaction between a Mobile IP home agent and a Diameter server and is used when the mobile node is authenticated and authorized using the Mobile IPv6 Authentication Protocol [RFC4285]. 🌷

The large majority of Diameter applications are vendor-specific and mainly used in various SDOs outside the IETF 🏢. One SDO that uses diameter extensively is 3GPP (e.g., the 3GPP 'IP Multimedia Subsystem' (IMS) uses diameter-based interfaces (e.g., Cx) [3GPPIMS]) 📡. Recently, during the standardization of the '3GPP Evolved Packet Core' [3GPPEPC], diameter was chosen as the only AAA signaling protocol 😭✨.

One part of diameter's extensibility mechanism is an easy and consistent way of creating new commands for the needs of applications 🛠️. RFC 3588 proposed defining diameter command code allocations with a new RFC. This policy decision led to undesired use and redefinition of existing command codes within SDOs 🙈. Lots of RFCs got published as simple command code allocations for other SDO purposes (see [RFC3589], [RFC5224], [RFC5431], and [RFC5516]). [RFC5719] changed the command code policy and added a range for vendor-specific command codes to be allocated on a 'First Come First Served' basis by IANA 🎉.

The implementation and deployment experience of diameter has led to the ongoing development of an update of the base protocol [DIAMETER] 🛤️. That update introduces TLS as the preferred security mechanism and deprecates the in-band security negotiation for TLS 🔒.

Some Diameter protocol enhancements and clarifications logically fit better into [DIAMETER], but they're also needed on existing deployments based on RFC 3588 🧩. So protocol extensions specifically usable in large inter-provider roaming network scenarios are made available for RFC 3588. Two existing specifications are mentioned below:

"Clarifications on the Routing of Diameter Requests Based on the Username and the Realm" [RFC5729] defines the behavior required for Diameter agents to route requests when the User-Name AVP contains a NAI formatted with multiple realms. These multi-realm Network Access Identifiers are used to force the routing of request messages through a predefined list of mediating realms 🗺️.
"Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage" [RFC6408] describes an improved DNS-based dynamic Diameter agent discovery mechanism without having to do diameter capability exchange beforehand with a number of agents 🔍.

There's been a growing number of Diameter Framework documents from the IETF that are basically just a collection of AVPs for a specific purpose or a system architecture, with semantic AVP descriptions and a logic for "imaginary" applications 🤭. From a standardization point of view, this practice lets larger system architecture documents exist without needing to reference AVPs or application logic outside the IETF 🏗️. Here are a few recent AVP and Framework documents:

"Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction" [RFC5447] describes the bootstrapping of the Mobile IPv6 framework and the support of interworking with existing AAA infrastructures by using the diameter NAS-to-home-AAA server interface 🚪.
"Traffic Classification and Quality of Service (QoS) Attributes for Diameter" [RFC5777] defines a number of Diameter AVPs for traffic classification with actions for filtering and QoS treatment 🚦.
"Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server" [RFC5779] defines AAA interactions between Proxy Mobile IPv6 (PMIPv6) entities (MAG and LMA) and a AAA server within a PMIPv6 Domain 🏠.

For information on MIB modules related to diameter, see Section 4.2.5 📚.

3.7. Control and Provisioning of Wireless Access Points (CAPWAP) 📶

Wireless LAN (WLAN) product architectures have evolved from single autonomous Access Points to systems made up of a centralized Access Controller (AC) and Wireless Termination Points (WTPs) 🌟. The big goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management, from the single access point to a centralized controller 🎯. An Access Point then pulls the information from the AC 💁‍♀️.

Based on "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)" [RFC4118], the CAPWAP working group developed the CAPWAP protocol [RFC5415] 🧠. It facilitates control, management, and provisioning of WTPs, specifying the services, functions, and resources relating to 802.11 WLAN Termination Points so that WTPs and ACs can be implemented interoperably 🤝. The protocol defines the CAPWAP control plane, including the primitives to control data access 🔐. It also specifies how configuration management of WTPs can be done, defines CAPWAP operations for debugging, gathering statistics, logging, and managing firmware, and discusses operational and transport considerations 🛠️.

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

CAPWAP Control messages, and optionally CAPWAP Data messages, are secured using DTLS [RFC6347] 🛡️. DTLS is used as a tightly integrated, secure wrapper for the CAPWAP protocol 💜.

For information on MIB modules related to CAPWAP, see Section 4.2.2 📖.

3.8. Access Node Control Protocol (ANCP) 🌐

The Access Node Control Protocol (ANCP) [RFC6320] sets up a control plane between a service-oriented Layer 3 edge device, the NAS, and a Layer 2 Access Node (AN), e.g., a Digital Subscriber Line Access Module (DSLAM) 🏢. So ANCP works in a multi-service reference architecture and passes QoS-, service-, and subscriber-related configuration and operation information between a NAS and an AN 💅.

The main goal of this protocol is to configure and manage access equipment and let them report information to the NAS, so configuration can be enabled and optimized 🎀.

The framework and requirements for an AN control mechanism, plus the use cases for ANCP, are documented in [RFC5851] 📝.

ANCP offers authentication and authorization between AN and NAS nodes, and it provides replay protection and data-origin authentication 🔏. The ANCP solution is also robust against Denial-of-Service (DoS) attacks 🛡️. Furthermore, the ANCP solution is recommended to offer confidentiality protection 🫶. Security Threats and Security Requirements for ANCP are discussed in [RFC5713] 🚨.

3.9. Application Configuration Access Protocol (ACAP) 🎀

okay bestie, ACAP [RFC2244] is giving "store all my app settings somewhere I can grab them from anywhere" 💖 It's built for remote storage and access of program option, configuration, and preference info ✨ The datastore model keeps things simple for a client to reach interesting data, lets new info get added without reconfiguring the server, and supports both standardized data and custom or proprietary data 🧚 Key features include "inheritance", which handles default values for config settings, plus access control lists so personal info can be shared while group info stays restricted 🔒

ACAP's main job is letting apps grab their config data from multiple network-connected computers 💅 So you can sit down at any networked computer, run any ACAP-enabled app, and still have your own settings 🦋 Client simplicity gets priority over server or protocol simplicity whenever it's reasonable, because wide usage is the whole vibe 🌸

The ACAP authenticate command uses Simple Authentication and Security Layer (SASL) [RFC4422] to give basic authentication, authorization, integrity, and privacy services 🔐 All ACAP implementations are required to implement CRAM-MD5 (Challenge-Response Authentication Mechanism) [RFC2195] for authentication, which can be disabled based on the site security policy 🙈

3.10. XML Configuration Access Protocol (XCAP) 💜

The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] was designed for SIP-based solutions and is commonly used with them, especially for instant messages, presence, and SIP conferences 💬 XCAP lets a client read, write, and modify application config data stored in XML format on a server, and the main functionality comes from so-called "XCAP Application Usages" 🧁

XCAP is a protocol for manipulating per-user data 👑 It's a set of conventions for mapping XML documents and document components into HTTP URIs, plus rules for how changing one resource affects another, data validation constraints, and authorization policies for accessing those resources 📜 Because of this structure, normal HTTP primitives can be used to manipulate the data 🙌 Like ACAP, XCAP handles the config needs of a whole bunch of applications at once ✨

All XCAP servers are required to implement HTTP Digest Authentication [RFC2617] 🔐 XCAP servers are also required to implement HTTP over TLS (HTTPS) [RFC2818] 🔒 It is recommended that administrators use an HTTPS URI as the XCAP root URI, so that the digest client authentication happens over TLS 🫶

Here's the rundown of the important XCAP application usages 💅

XCAP server capabilities [RFC4825] can be read by clients to figure out which extensions, application usages, or namespaces a server supports 🔍
A resource lists application is any app that needs access to a list of resources, identified by a URI, where operations like subscriptions can be applied [RFC4826] 📋
A Resource List Server (RLS) Services application is a SIP app where a server receives SIP SUBSCRIBE requests for resources and makes subscriptions towards the resource list [RFC4826] 📨
A Presence Rules application uses authorization policies (also known as authorization rules) to decide what presence info can be shown to which watchers, and when [RFC4827] 👀
A pidf-manipulation application defines how XCAP is used to change the contents of PIDF-based presence documents [RFC4827] 🦋

4. Network Management Data Models 🍓

This section gives two complementary overviews of the network management data models standardized at IETF 🗂️ The first subsection looks at a broader view, sorting models into categories like generic and infrastructure data models, plus models matched to different layers 🧠 The second subsection follows the management application view and focuses mainly on 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 🙃 The FCAPS view is still used widely outside the IETF to carry out management tasks and applications. Section 4.2 aims to address the FCAPS view so people outside the IETF can understand the relevant IETF data models 🫶

The data models covered here are MIB modules, IPFIX Information Elements, Syslog Structured Data Elements, and YANG modules 📚 There are lots of technology-specific IETF data models, such as transmission and protocol MIBs, which aren't 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 roughly sorted into the following categories, shown 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 category gets a quick description below. The classification here is meant to give orientation, and it reflects how most data models have been developed in the IETF by the various working groups 🧭 It doesn't aim to correctly classify every data model the IETF has defined 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 can be found under the IANA registry at [SMI-NUMBERS] 🔢

4.1.1. Generic Infrastructure Data Models

Generic infrastructure data models are the core abstractions that lots of other data models are built on 🏗️ The biggest example is the interfaces data model defined in the IF-MIB [RFC2863] 💖 It gives the basic notion of network interfaces and lets you express stacking/layering relationships between interfaces 🥞 It also has 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, which makes it a key data model for inventory management 🗃️ Physical entities can point to other data models that give more specific info about them (e.g., physical ports usually point to the related network interface) 👉 Entity MIB extensions exist for physical sensors, like temperature sensors 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 bunch of data models exist as MIB modules for 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 usually extend the generic network interfaces data model with interface type specific info 🧩 Most link-layer models focus on monitoring for performance and fault management and, to a lesser extent, accounting and security management 📊 Meanwhile, the IEEE has taken over responsibility for maintaining and developing 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 as MIB modules covering IP/ICMP [RFC4293] [RFC4292] network protocols and their extensions (e.g., Mobile IP), which are the core protocols of the Internet 🌐 There are also data models for 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]) 💬 There are also data models that provide a generic infrastructure for instrumenting applications, so you can get data that's mainly useful for performance management and fault management [RFC2287] [RFC2564] 🔧 In general, though, generic application MIB modules have been less successful at gaining widespread deployment 💀

4.1.6. Network Management Infrastructure Data Models ✨

okay so there's a whole group of data models that are about the network management system itself 🧠 besides the SNMP MIB modules that keep an eye on and configure SNMP [RFC3410], there are MIB modules for generic stuff like calculating expressions over MIB objects, thresholding and event generation, logging event notifications, and representing alarms [RFC2981] [RFC2982] [RFC3014] [RFC3877]. it's giving "the infrastructure behind the infrastructure" 💅

there are also data models that let you run basic reachability and path discovery tests [RFC4560] 🔍. and then there's another collection of MIB modules for remote monitoring, from the data link layer all the way up to the application layer. this is called the "RMON family of MIB modules" [RFC3577] 🦋

the IPFIX Protocol [RFC5101] (Section 2.3) is used to export information about network flows that get collected at so-called Observation Points (typically, a network interface) 🌊. the IEs [RFC5102] carried in IPFIX cover most of the network and transport layer header fields, plus a few link-layer-specific fields. work is still underway to extend the standardized information IPFIX can carry, so stay tuned 👀

the Syslog Protocol document [RFC5424] (Section 2.2) defines a first set of Structured Data Elements (SDEs) about content time quality, content origin, and meta-information about the message, like language 📝. you're allowed to use proprietary SDEs to supplement the IETF-defined ones too 🎀

4.2. Network Management Data Models - FCAPS View 🎯

this subsection takes the management application point of view and tries to match the data models to network management tasks: fault, configuration, accounting, performance, and security management ([FCAPS]) 💖. OAM is a general term for a toolset that can be used for fault detection, isolation, and performance measurement, so the FCAPS side of the data path, like fault and performance management, is also covered in "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms" [OAM-OVERVIEW] 🧚

some data models don't fit neatly into just one FCAPS category, though 🙈. for example, a lot of technology-specific IETF data models, like transmission and protocol MIBs, cover multiple FCAPS categories. so they aren't mentioned in this subsection and you can find them at [RFCSEARCH] 🔎

4.2.1. Fault Management 🚨

fault management is a whole set of functions for detecting, isolating, notifying, and correcting faults in a network, plus maintaining and examining error logs 🩹. the data models below can be used to build a fault management application ✨

[RFC3418], which is part of the SNMPv3 standard [STD62], is a MIB module with objects in the system group. people poll these a lot to figure out if a device is still operating 💜. sysUpTime can also tell you if the network management part of the system has restarted and counters have been re-initialized, which is so useful 😭

[RFC3413], also part of the SNMPv3 standard [STD62], is a MIB module with objects for managing notifications. it has tables for addressing, retry parameters, security, lists of notification targets, and user customization filters 🎀

the Interfaces Group MIB [RFC2863] builds on the old standard for MIB II [STD17] and is the primary MIB module for managing and monitoring the status of network interfaces 🔌. it defines a generic set of managed objects for network interfaces, and it also provides the infrastructure for extra managed objects that are specific to particular types of network interfaces, like Ethernet 🌸

[RFC4560] defines a MIB module for doing ping, traceroute, and lookup operations at a host 🏓. for troubleshooting, it's really handy to be able to start ping or traceroute operations and get the results back when they're run from a remote host 🫶

the RMON (Remote Network Monitoring) MIB [STD59] can be configured to recognize conditions on existing MIB variables (especially error conditions) and keep checking for them, nonstop 👀. when one of these conditions happens, the event may get logged, and management stations may be notified in a bunch of different ways (for more on RMON, see Section 4.2.4) 🍓

DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982] give you a superset of what the RMON alarm and event groups can do 🔥. these modules provide ways to set thresholds and report anomalous events to management applications 💅

the Alarm MIB in [RFC3877] and the Alarm Reporting Control MIB in [RFC3878] specify ways to express state transition models for persistent problem states 🌈. the Alarm MIB defines the following:

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

in particular, [RFC3878] defines objects for controlling how alarm conditions get reported, and it extends ITU-T work on M.3100 Amendment 3 [ITU-M3100] 💖

other MIB modules that can be used for fault management with SNMP include:

NOTIFICATION-LOG-MIB [RFC3014] describes managed objects used for logging SNMP Notifications. 📒
ENTITY-STATE-MIB [RFC4268] describes extensions to the Entity MIB that give information about the state of physical entities. 🧚
ENTITY-SENSOR-MIB [RFC3433] describes managed objects that extend the Entity MIB to give generalized access to information about physical sensors, which are often found in networking equipment (things like chassis temperature, fan RPM, and power supply voltage) 🌡️

the Syslog protocol document [RFC5424] defines an initial set of SDEs about content time quality, content origin, and meta-information about the message, like language 📝. proprietary SDEs can be used to supplement the IETF-defined SDEs too 🎀

the IETF has standardized MIB Textual-Conventions for facility and severity labels and codes, so syslog and MIB representations of these event properties stay consistent [RFC5427] 🫶. the idea is that these textual conventions get 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 with managed objects for monitoring PSAMP implementations [PSAMP-MIB] 🔮

the NETCONF working group defined the data model needed to monitor the NETCONF protocol [RFC6022], written in the YANG modeling language 🎀. the monitoring data model includes info about NETCONF datastores, sessions, locks, and statistics, which makes managing a NETCONF server way easier 🙌. the NETCONF monitoring document also defines methods that let NETCONF clients discover the data models a NETCONF server supports, and it defines the operation <get-schema> to retrieve them 🧠

4.2.2. Configuration Management ⚙️

configuration management is all about establishing and maintaining consistency of a system. it defines the functionality for configuring a system's functional and physical attributes, plus its operational info, throughout its whole life 💅. it includes configuration of network devices, inventory management, and software management 📦. the data models below can be used to do configuration management ✨

MIB modules for monitoring network configuration (for example, physical and logical network topologies) already exist and cover some of what we want 🗺️. new MIB modules might be developed for the target functionality, so operators can monitor and modify operational parameters like timer granularity, event reporting thresholds, target addresses, and so on 🫶

[RFC3418], which is part of [STD62], has objects in the system group that are useful for identifying the type of device, its location, and the person responsible for it 📍. the SNMPv3 standard [STD62] also includes objects for configuring principals, access control rules, and notification destinations, plus configuring proxy-forwarding SNMP agents, which can forward messages through firewalls and NAT devices 🔥

the Entity MIB [RFC4133] mainly supports inventory management and is used to manage multiple logical and physical entities matched to a single SNMP agent 🗂️. this module gives you a handy mechanism for identifying the entities that make up a system, and it defines event notifications for configuration changes that management applications may find useful 🎀

[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], written in YANG and built in close collaboration with the NETMOD working group (see Section 2.4.2) 💻. the model specifies the data needed to configure and monitor Selection Processes, caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant monitoring devices 🌈

at the time of 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], and the TLVs for IEEE 802.11 are specified in [RFC5416] 📡. the CAPWAP Base MIB [RFC5833] specifies managed objects for modeling the CAPWAP protocol, and it covers configuration and WTP status-monitoring aspects of CAPWAP 🛜. the CAPWAP Binding MIB [RFC5834] defines managed objects for modeling the CAPWAP protocol for the 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 SNMP management of the CAPWAP protocol. 🙈

4.2.3. Accounting Management ✨

Okay so accounting management is all about collecting usage info on network resources 📊. Quick reminder that the IETF does not define any mechanisms related to billing and charging 💅. Lots of technology-specific MIBs (link layer, network layer, transport layer, or application layer) have counters in them, but they aren't mainly made for accounting, so they're not 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 too 🦋.

IPFIX/PSAMP Information Elements:

As mentioned in Section 2.3, the IPFIX Architecture [RFC5470] defines the components involved in IP flow measurement and reporting of information on IP flows 🌊. So IPFIX records give you super fine-grained measurement data for flexible, detailed usage reporting, and they enable usage-based accounting 💜.

The IPFIX Information Elements (IEs) were first defined in the IPFIX Information Model [RFC5102] and registered with IANA [IANA-IPFIX] ✨. There are two types of IEs:

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
IEs related to counters 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]. There's also an extra set of PSAMP Information Elements for reporting packet information with the IPFIX/PSAMP protocol, like Sampling-related IEs, and those are specified in the PSAMP Information Model [RFC5477]. These IEs cover the requirements on reporting of different sampling and filtering techniques specified in [RFC5475] 💖.

4.2.4. Performance Management 🚀

Performance management is a whole set of functions that evaluate and report on the performance of network elements and the network, with the goal of keeping overall network performance at a defined level 📈. It includes monitoring and measuring network performance parameters, gathering statistical info, and maintaining and examining activity logs 🗂️. The data models below can be used for performance management tasks, so bookmark this part bestie 🔖.

The RMON (Remote Network Monitoring) MIB [STD59] defines objects for collecting data about network performance and traffic from remote monitoring devices 🛰️. An organization might use lots of remote monitoring probes, one per network segment, to keep an eye on its network. A network service provider might use these devices to access a (distant) client network 🌐. Most of the objects in the RMON MIB module work for monitoring any type of network, while some are specific to monitoring Ethernet networks 🔌.

RMON lets a probe be configured to run diagnostics and collect network statistics continuously, even when talking to the management station might 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 a monitored variable crosses a threshold, an event gets 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 it 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 each 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 it doesn't relate to a specific application transport 🙌. It's scalable, works well with encrypted payload and signaling, and 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. One uses TCP as a native transport, and the other uses 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 for measuring and analyzing application performance as experienced by end-users 👀. It enables measurement of the quality of service that applications deliver to end-users 🌟.

"Transport Performance Metrics MIB" [RFC4150] describes managed objects used for monitoring selectable Performance Metrics and statistics derived from monitoring 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 the "IP Performance Metrics (IPPM) Metrics Registry" [RFC4148] 🏷️. Heads up though: with the publication of [RFC6248], [RFC4148] and the corresponding IANA registry for IPPM metrics have been declared Obsolete, so they shouldn't be used 🚫.

The IPPM working group also defined the "Information Model and XML Data Model for Traceroute Measurements" [RFC5388] 🗺️. It defines a common information model that splits the IEs into two semantically separated groups (configuration elements and results elements), plus an additional element that relates configuration elements and results elements through a common unique identifier 🔗. Based on that information model, an XML data model is provided for storing the results of traceroute measurements 📦.

"Session Initiation Protocol Event Package for Voice Quality Reporting" [RFC6035] defines a SIP event package that enables collecting and reporting metrics that measure the quality of Voice over Internet Protocol (VoIP) sessions 📞💜.

4.2.5. Security Management 🔐

Security management is the set of functions that protect the network and system from unauthorized access 🛡️. It includes functions like creating, deleting, and controlling security services and mechanisms, key management, reporting security-relevant events, and authorizing user access and privileges 🔑. RADIUS and diameter are seen as security management protocols, based on their support for authentication and authorization 👑. The data models below can be used to make use of security management 💅.

[RFC3414], part of [STD62], specifies the procedures for providing SNMPv3 message-level security. It 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. It includes a MIB module that defines managed objects to access portions of an SNMP engine's Local Configuration Datastore (LCD). This means the 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] 🧿. So 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 🌈:

"RADIUS Authentication Client MIB for IPv6" [RFC4668] defines RADIUS Authentication Client MIB objects that support version-neutral IP addressing formats, and it defines a set of extensions for RADIUS authentication client functions 💖.
"RADIUS Authentication Server MIB for IPv6" [RFC4669] defines RADIUS Authentication Server MIB objects that support version-neutral IP addressing formats, and it defines a set of extensions for RADIUS authentication server functions 💜.
"RADIUS Dynamic Authorization Client MIB" [RFC4672] defines the MIB module for entities implementing the client side of the Dynamic Authorization Extensions to RADIUS [RFC5176] ✨.
"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 they do not support RADIUS over TCP. There's 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 a lack on the management side of diameter nodes 🥺.

5. Security Considerations 🔒

Okay bestie, this doc is basically a tour of IETF network management standards and what's cooking in them right now, and it's giving summary more than spec. So it doesn't have any security implications in or of itself 💅. The real security tea lives in the chapters for each tech.

Each technology gets a quick summary of its security usage in its own chapter, and for a few (SNMP especially) there's a full breakdown of the security mechanisms. 🦋

Here are the sections you really need to read carefully 👀:

SNMP Security and Access Control Models in Section 2.1.4.1,
User-based Security Model (USM) in Section 2.1.4.2,
View-based Access Control Model (VACM) in Section 2.1.4.3,
SNMP Transport Security Model in Section 2.1.5.1,
Secure syslog message delivery in Section 2.2,
Use of secure NETCONF message transport and the NETCONF Access Control Model (NACM) in Section 2.4.1,
Message authentication for Dynamic Host Configuration Protocol (DHCP) in Section 3.1.1,
Security for Remote Authentication Dial-In User Service (RADIUS) in conjunction with EAP and IEEE 802.1X authenticators in Section 3.5,
Built-in and transport security for the Diameter Base Protocol in Section 3.6,
Transport security for Control And Provisioning of Wireless Access Points (CAPWAP) in Section 3.7,
Built-in security for Access Node Control Protocol (ANCP) in Section 3.8,
Security for Application Configuration Access Protocol (ACAP) in Section 3.9,
Security for XML Configuration Access Protocol (XCAP) in Section 3.10, and
Data models for Security Management in Section 4.2.5.

The authors also point you to the detailed security consideration sections of the individual management standards in this doc. These go deep into the security implications of each protocol and mechanism, so please read them before you implement anything 🚨. The ones to look at are:

For SNMP security in general, the subsequent security consideration sections in [STD62], which includes RFCs 3411-3418,
The security considerations section in Section 8 of [BCP074] for coexistence of SNMP versions 1, 2, and 3,
Security considerations for the SNMP Transport Security Model in Section 8 of [RFC5591],
Security considerations for the Secure Shell Transport Model for SNMP in Section 9 of [RFC5592],
Security considerations for the TLS Transport Model for SNMP in Section 9 of [RFC6353],
Security considerations for the TLS Transport Mapping for syslog in Section 6 of [RFC5425],
Security considerations for the IPFIX Protocol Specification in Section 11 of [RFC5101],
Security considerations for the NETCONF protocol in Section 9 of [RFC6241] and the SSH transport in Section 6 of [RFC6242],
Security considerations for the NETCONF Access Control Model (NACM) in Section 3.7 of [RFC6536],
Security considerations for DHCPv4 and DHCPv6 in Section 7 of [RFC2131] and Section 23. of [RFC3315],
Security considerations for RADIUS in Section 8 of [RFC2865],
Security considerations for diameter in Section 13 of [RFC3588],
Security considerations for the CAPWAP protocol in Section 12 of [RFC5415],
Security considerations for the ANCP protocol in Section 11 of [RFC6320], and
Security considerations for the XCAP protocol in Section 14 of [RFC4825].

6. Contributors 🫶

These amazing people made significant contributions to and reviewed this document 🌸:

Ralph Droms (Cisco) - revised the section on IP Address Management and DHCP.
Jouni Korhonen (Nokia Siemens Networks) - contributed the sections on RADIUS and diameter.
Al Morton (AT&T) - contributed to the section on IP Performance Metrics.
Juergen Quittek (NEC) - contributed the section on IPFIX/PSAMP.
Juergen Schoenwaelder (Jacobs University Bremen) - contributed the sections on IETF Network Management Data Models and YANG.

7. Acknowledgements 💜

The editor says a huge thank you to 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 especially thanks Dave Harrington, who created the document "Survey of IETF Network Management Standards" a few years ago. It was the starting point, and it got enhanced with a special focus on the IETF network management standards and management data models 👑.

8. Informative References 📚

[3GPPEPC] 3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks", December 2010, <http://www.3gpp.org/ftp/Specs/html-info/24302.htm>.
[3GPPIMS] 3GPP, "Release 10, IP Multimedia Subsystem (IMS); Stage 2", September 2010, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
[BCP027] O'Dell, M., Alvestrand, H., Wijnen, B., and S. Bradner, "Advancement of MIB specifications on the IETF Standards Track", BCP 27, RFC 2438, October 1998.
[BCP074] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[BCP170] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[CONF-MODEL] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for IPFIX and PSAMP", Work in Progress, July 2011.
[DIAMETER] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", Work in Progress, April 2012.
[DMTF-CIM] DMTF, "Common Information Model Schema, Version 2.27.0", November 2010, <http://www.dmtf.org/standards/cim>.
[EMAN-WG] IETF, "EMAN Working Group", <http://datatracker.ietf.org/wg/eman>.
[FCAPS] International Telecommunication Union, "X.700: Management Framework For Open Systems Interconnection (OSI) For CCITT Applications", September 1992, <http://www.itu.int/rec/T-REC-X.700-199209-I/en>.
[IANA-AAA] Internet Assigned Numbers Authority, "Authentication, Authorization, and Accounting (AAA) Parameters", February 2012, <http://www.iana.org/assignments/aaa-parameters>.
[IANA-IPFIX] Internet Assigned Numbers Authority, "IP Flow Information Export (IPFIX) Entities", May 2012, <http://www.iana.org/assignments/ipfix>.
[IANA-PROT] Internet Assigned Numbers Authority, "Protocol Registries", <http://www.iana.org/protocols/>.
[IANA-PSAMP] Internet Assigned Numbers Authority, "Packet Sampling (PSAMP) Parameters", April 2009, <http://www.iana.org/assignments/psamp-parameters>.
[IETF-WGS] IETF, "IETF Working Groups", <http://datatracker.ietf.org/wg/>.
[ITU-M3100] International Telecommunication Union, "M.3100: Generic network information model", January 2006, <http://www.itu.int/rec/T-REC-M.3100-200504-I>.
[ITU-X680] International Telecommunication Union, "X.680: Abstract Syntax Notation One (ASN.1): Specification of basic notation", July 2002, <http://www.itu.int/ ITU-T/studygroups/com17/languages/X.680-0207.pdf>.
[ITU-X733] International Telecommunication Union, "X.733: Systems Management: Alarm Reporting Function", October 1992, <http://www.itu.int/rec/T-REC-X.733-199202-I/en>.
[MPLSTP-MIB] King, D. and V. Mahalingam, "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview", Work in Progress, April 2012.
[OAM-ANALYSIS] Sprecher, N. and L. Fang, "An Overview of the OAM Tool Set for MPLS based Transport Networks", Work in Progress, April 2012.
[OAM-OVERVIEW] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", Work in Progress, March 2012.
[PSAMP-MIB] Dietz, T., Claise, B., and J. Quittek, "Definitions of Managed Objects for Packet Sampling", Work in Progress, October 2011.
[RELAX-NG] OASIS, "RELAX NG Specification, Committee Specification 3 December 2001", December 2001, <http: //www.oasis-open.org/committees/relax-ng/ spec-20011203.html>.
[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC1021] Partridge, C. and G. Trewitt, "High-level Entity Management System (HEMS)", RFC 1021, October 1987.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/ IP-based internets", STD 16, RFC 1155, May 1990.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB definitions", STD 16, RFC 1212, March 1991.
[RFC1215] Rose, M., "Convention for defining traps for use with the SNMP", RFC 1215, March 1991.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1470] Enger, R. and J. Reynolds, "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", RFC 1470, June 1993.
[RFC1901] Case, J., McCloghrie, K., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2127] Roeck, G., "ISDN Management Information Base using SMIv2", RFC 2127, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.

Okay bestie, the reading list keeps going 📚🎀 These are all the informative refs, so no cap, you can skim them and pick what you need 🫶

[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. 💖
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. 🧚
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. ✨
[RFC2458] Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S., Burg, F., DeSimone, A., Tewani, K., Davidson, P., Schulzrinne, H., and K. Vishwanathan, "Toward the PSTN/Internet Inter-Networking --Pre-PINT Implementations", RFC 2458, November 1998. 🌈
[RFC2515] Tesink, K., "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999. 🦋
[RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. Saperia, "Application Management MIB", RFC 2564, May 1999. 🍓
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 👑
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. 💅
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. 🫶
[RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999. 🌸
[RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, June 1999. 🔥
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. 🙈
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. 💜
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. ⭐
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. 🎀
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. 🦋
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. 🌈
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. 🍓
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 🔥
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. 🧚
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 💖
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. ✨
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. 🌸
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. 👑
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. 💅
[RFC2981] Kavasseri, R., "Event MIB", RFC 2981, October 2000. 🫶
[RFC2982] Kavasseri, R., "Distributed Management Expression MIB", RFC 2982, October 2000. 🌈
[RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 2000. 🦋
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. 🍓
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. 🔥
[RFC3144] Romascanu, D., "Remote Monitoring MIB Extensions for Interface Parameters Monitoring", RFC 3144, August 2001. 🙈
[RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001. 💜
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. ⭐
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. 🎀
[RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", RFC 3165, August 2001. 🧚
[RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001. 🌸
[RFC3273] Waldbusser, S., "Remote Network Monitoring Management Information Base for High Capacity Networks", RFC 3273, July 2002. 🦋
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 🍓
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003. 🔥
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 🙈
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 💜
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. ⭐
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. 🎀
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 🦋
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. 🧚
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 🌈
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. 💖
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping", RFC 3430, December 2002. ✨
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. 🌸
[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002. 👑
[RFC3434] Bierman, A. and K. McCloghrie, "Remote Monitoring MIB Extensions for High Capacity Alarms", RFC 3434, December 2002. 💅
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003. 🫶
[RFC3460] Moore, B., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003. 🔥
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003. 🙈
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003. 💜
[RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, August 2003. ⭐
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. 🎀
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. 🦋
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 🧚
[RFC3589] Loughney, J., "Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5", RFC 3589, September 2003. 🌈
[RFC3606] Ly, F., Noto, M., Smith, A., Spiegel, E., and K. Tesink, "Definitions of Supplemental Managed Objects for ATM Interface", RFC 3606, November 2003. 💖
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. ✨
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. 🌸
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004. 👑
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 💅
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. 🫶
[RFC3868] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., Keller, J., and B. Bidulock, "Signalling Connection Control Part User Adaptation Layer (SUA)", RFC 3868, October 2004. 🔥
[RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)", RFC 3873, September 2004.
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[RFC3878] Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting Control Management Information Base (MIB)", RFC 3878, September 2004.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005.
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4113] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", RFC 4113, June 2005.
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005.
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005.
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005.
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005.
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, November 2005.
[RFC4273] Haas, J. and S. Hares, "Definitions of Managed Objects for BGP-4", RFC 4273, January 2006.
[RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers", RFC 4280, November 2005.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006.
[RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4318] Levi, D. and D. Harrington, "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol", RFC 4318, December 2005.
[RFC4363] Levi, D. and D. Harrington, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions", RFC 4363, January 2006.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4444] Parker, J., "Management Information Base for Intermediate System to Intermediate System (IS-IS)", RFC 4444, April 2006.
[RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006.
[RFC4546] Raftus, D. and E. Cardona, "Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces", RFC 4546, June 2006.
[RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 4560, June 2006.
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG", RFC 4663, September 2006.
[RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006.
[RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006.
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, August 2006.
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006.
[RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Client MIB", RFC 4672, September 2006.
[RFC4673] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Server MIB", RFC 4673, September 2006.
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4706] Morgenstern, M., Dodge, M., Baillie, S., and U. Bonollo, "Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)", RFC 4706, November 2006.
[RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON) Framework", RFC 4710, October 2006.
[RFC4711] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON) MIB", RFC 4711, October 2006.
[RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., and Y. Kim, "Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)", RFC 4712, October 2006.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006.
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006.
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006.
[RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006.
[RFC4780] Lingle, K., Mule, J-F., Maeng, J., and D. Walker, "Management Information Base for the Session Initiation Protocol (SIP)", RFC 4780, April 2007.
[RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network Management Protocol (SNMP) over IEEE 802 Networks", RFC 4789, November 2006.
[RFC4803] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, February 2007.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4827] Isomaki, M. and E. Leppanen, "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents", RFC 4827, May 2007.
[RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP Extended Statistics MIB", RFC 4898, May 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. Kessler, "Protocol Independent Multicast MIB", RFC 5060, January 2008.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, February 2008.

Okay bestie, these are the receipts for the whole doc 🧾✨ Every one of these is a real reference we're leaning on, so I've kept each entry word for word. Let's go 💅

[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008.
[RFC5224] Brenner, M., "Diameter Policy Processing Application", RFC 5224, March 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.
[RFC5388] Niccolini, S., Tartarelli, S., Quittek, J., Dietz, T., and M. Swany, "Information Model and XML Data Model for Traceroute Measurements", RFC 5388, December 2008.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009.
[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009.
[RFC5427] Keeni, G., "Textual Conventions for Syslog Management", RFC 5427, March 2009.
[RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface Application", RFC 5431, March 2009.
[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
[RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5516] Jones, M. and L. Morand, "Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 5516, April 2009.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009.
[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009.
[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009.
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
[RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", RFC 5607, July 2009.
[RFC5608] Narayan, K. and D. Nelson, "Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models", RFC 5608, August 2009.
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009.
[RFC5650] Morgenstern, M., Baillie, S., and U. Bonollo, "Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)", RFC 5650, September 2009.
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009.
[RFC5674] Chisholm, S. and R. Gerhards, "Alarms in Syslog", RFC 5674, October 2009.
[RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", RFC 5675, October 2009.
[RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", RFC 5676, October 2009.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote Procedure Call (RPC) for NETCONF", RFC 5717, December 2009.
[RFC5719] Romascanu, D. and H. Tschofenig, "Updated IANA Considerations for Diameter Command Code Allocations", RFC 5719, January 2010.
[RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009.
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010.
[RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", RFC 5778, February 2010.
[RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010.
[RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 5815, April 2010.
[RFC5833] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB", RFC 5833, May 2010.
[RFC5834] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11", RFC 5834, May 2010.
[RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric Composition", RFC 5835, April 2010.
[RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog Messages", RFC 5848, May 2010.
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", RFC 5851, May 2010.
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad Hoc Networks", RFC 5889, September 2010.
[RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export (IPFIX) Mediation: Problem Statement", RFC 5982, August 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, "Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog", RFC 6012, October 2010.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010.

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

[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, "Session Initiation Protocol Event Package for Voice Quality Reporting", RFC 6035, November 2010. 📞
[RFC6065] Narayan, K., Nelson, D., and R. Presuhn, "Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings", RFC 6065, December 2010. 🔐
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", RFC 6087, January 2011. 📝
[RFC6095] Linowski, B., Ersue, M., and S. Kuryla, "Extending YANG with Language Abstractions", RFC 6095, March 2011. 🧩
[RFC6110] Lhotka, L., "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content", RFC 6110, February 2011. 🗺️
[RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011. 🎀
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011. 🌊
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, May 2011. 🫥
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. ⚙️
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011. 🐚
[RFC6244] Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, June 2011. 🏛️
[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 2011. 📉
[RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, June 2011. ⚡
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011. 📦
[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. Taylor, "Protocol for Access Node Control Mechanism in Broadband Networks", RFC 6320, October 2011. 📡
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 🔒
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011. 🛡️
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. 🛠️
[RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage", RFC 6408, November 2011. 🧭
[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011. 🪜
[RFC6526] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream", RFC 6526, March 2012. 🌀
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012. 🚪
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012. 🏠
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 🧵
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012. 🔏
[RFCSEARCH] RFC Editor, "RFC Index Search Engine", http://www.rfc-editor.org/rfcsearch.html. 🔍
[SMI-NUMBERS] IANA, "Network Management Parameters - SMI OID List", May 2012, http://www.iana.org/assignments/smi-numbers. 🔢
[SMI-YANG] Schoenwaelder, J., "Translation of SMIv2 MIB Modules to YANG Modules", Work in Progress, April 2012. 🚧
[STD06] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. 📮
[STD07] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. 🤝
[STD16] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. 🪪
- Rose, M. and K. McCloghrie, "Concise MIB definitions", STD 16, RFC 1212, March 1991. ✂️
[STD17] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. 📚
[STD58] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 🧱
- McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. 🔤
- McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. ✅
[STD59] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. 👀
[STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. 🏗️
- Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. 📬
- Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. 🧰
- Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 👤
- Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. 👓
- Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. 🛎️
- Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 🚚
- Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. 🗃️
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. 🌐
[XPATH] World Wide Web Consortium, "XML Path Language (XPath) Version 1.0", November 1999, http://www.w3.org/TR/1999/REC-xpath-19991116. 🛤️
[XSD-1] Beech, D., Thompson, H., Maloney, M., Mendelsohn, N., and World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, "XML Schema Part 1: Structures Second Edition", October 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028. 🧾

Appendix A. High-Level Classification of Management Protocols and Data Models ✨

The following subsections are your fast-track dispatcher 🚀 Pick the management standard you're after, then forward to the right chapter. They sort the protocols by high-level stuff like push versus pull, and passive versus active monitoring. They also group them by the network management task they handle or how extensible their data model is. Once you know what you need, you can shortlist a smaller set of standard protocols and data models to read. 💅

Say you're someone outside the IETF 🙋‍♀️ You'd probably go looking for the TWAMP protocol in the Operations and Management Area working groups, because it handles performance management. Plot twist: TWAMP was actually developed by the IPPM working group in the Transport Area. 😭

Heads up, not every protocol shows up in every classification section. Some of them, especially the protocols with a specific focus in Section 3, can't be clearly classified. 🧩 Also, COPS and COPS-PR aren't in the tables at all, because COPS-PR is not recommended to use (see Section 3.3). 🙈

A.1. Protocols Classified by Standards Maturity in the IETF ✨

okay so this section sorts the management protocols by how mature they are in the IETF 💅 The IETF maturity levels are Proposed, Draft, or Internet Standard, and they're defined in [RFC2026] (as amended by [RFC6410]). An Internet Standard is the top tier: it has a high degree of technical maturity and a generally held belief that the protocol or service gives the Internet community significant benefit 👑

the table below covers the standard maturity of the main protocols in this document. only the main protocols are listed, not their extensions 🦋 if you want the current document status, there's an RFC search tool at [RFCSEARCH] 🔍

   +---------------------------------------------+---------------------+
   | Protocol                                    | Maturity Level      |
   +---------------------------------------------+---------------------+
   | SNMP [STD62][RFC3411] (Section 2.1)         | Internet Standard   |
   |                                             |                     |
   | Syslog [RFC5424] (Section 2.2)              | Proposed Standard   |
   |                                             |                     |
   | IPFIX [RFC5101] (Section 2.3)               | Proposed Standard   |
   |                                             |                     |
   | PSAMP [RFC5476] (Section 2.3)               | Proposed Standard   |
   |                                             |                     |
   | NETCONF [RFC6241] (Section 2.4.1)           | Proposed Standard   |
   |                                             |                     |
   | DHCP for IPv4 [RFC2131] (Section 3.1.1)     | Draft Standard      |
   |                                             |                     |
   | DHCP for IPv6 [RFC3315] (Section 3.1.1)     | Proposed Standard   |
   |                                             |                     |
   | OWAMP [RFC4656] (Section 3.4)               | Proposed Standard   |
   |                                             |                     |
   | TWAMP [RFC5357] (Section 3.4)               | Proposed Standard   |
   |                                             |                     |
   | RADIUS [RFC2865] (Section 3.5)              | Draft Standard      |
   |                                             |                     |
   | Diameter [RFC3588] (Section 3.6)            | Proposed Standard   |
   |                                             |                     |
   | CAPWAP [RFC5416] (Section 3.7)              | Proposed Standard   |
   |                                             |                     |
   | ANCP [RFC6320] (Section 3.8)                | Proposed Standard   |
   |                                             |                     |
   | Ad hoc network configuration [RFC5889]      | Informational       |
   | (Section 3.1.2)                             |                     |
   |                                             |                     |
   | ACAP [RFC2244] (Section 3.9)                | Proposed Standard   |
   |                                             |                     |
   | XCAP [RFC4825] (Section 3.10)               | Proposed Standard   |
   +---------------------------------------------+---------------------+

      Table 1: Protocols Classified by Standard Maturity in the IETF

A.2. Protocols Matched to Management Tasks 🎀

this subsection matches the management protocols to the tasks for fault, configuration, accounting, performance, and security management. it's basically a little matchmaking table, bestie 💘

   +------------+------------+-------------+--------------+------------+
   | Fault Mgmt | Config.    | Accounting  | Performance  | Security   |
   |            | Mgmt       | Mgmt        | Mgmt         | Mgmt       |
   +------------+------------+-------------+--------------+------------+
   | SNMP       | SNMP       | SNMP        | SNMP         |            |
   | notif.     | config.    | monitoring  | monitoring   |            |
   | with trap  | with set   | with get    | with get     |            |
   | operation  | operation  | operation   | operation    |            |
   | (S. 2.1.1) | (S. 2.1.1) | (S. 2.1.1)  | (S. 2.1.1)   |            |
   |            |            |             |              |            |
   | IPFIX      | CAPWAP     | IPFIX       | IPFIX        |            |
   | (S. 2.3)   | (S. 3.7)   | (S. 2.3)    | (S. 2.3)     |            |
   |            |            |             |              |            |
   | PSAMP      | NETCONF    | PSAMP       | PSAMP        |            |
   | (S. 2.3)   | (S. 2.4.1) | (S. 2.3)    | (S. 2.3)     |            |
   |            |            |             |              |            |
   | Syslog     | ANCP       | RADIUS      |              | RADIUS     |
   | (S. 2.2)   | (S. 3.8)   | Accounting  |              | Authent.&  |
   |            |            | (S. 3.5)    |              | Authoriz.  |
   |            |            |             |              | (S. 3.5)   |
   |            |            |             |              |            |
   |            | AUTOCONF   | Diameter    |              | Diameter   |
   |            | (S. 3.1.2) | Accounting  |              | Authent.&  |
   |            |            | (S. 3.6)    |              | Authoriz.  |
   |            |            |             |              | (S. 3.6)   |
   |            |            |             |              |            |
   |            | ACAP       |             |              |            |
   |            | (S. 3.9)   |             |              |            |
   |            |            |             |              |            |
   |            | XCAP       |             |              |            |
   |            | (S. 3.10)  |             |              |            |
   |            |            |             |              |            |
   |            | DHCP       |             |              |            |
   |            | (S. 3.1.1) |             |              |            |
   +------------+------------+-------------+--------------+------------+

              Table 2: Protocols Matched to Management Tasks

Note: Corresponding section numbers are given in parentheses. 📝

A.3. Push versus Pull Mechanism 🚀

so here's the vibe check: a pull mechanism is when the Network Management System (NMS) goes and grabs the management information out of network elements, when it needs it 🫶 a push mechanism is when the network elements send the management information to the NMS, either as soon as it's available or on a regular basis 📤

Client/Server protocols, such as DHCP, ANCP, ACAP, and XCAP are not listed in Table 3. they're just a different category, so they're left out of this one 🙈

   +---------------------------------+---------------------------------+
   | Protocols supporting the Pull   | Protocols supporting the Push   |
   | mechanism                       | mechanism                       |
   +---------------------------------+---------------------------------+
   | SNMP (except notifications)     | SNMP notifications              |
   | (Section 2.1)                   | (Section 2.1)                   |
   | NETCONF (except notifications)  | NETCONF notifications           |
   | (Section 2.4.1)                 | (Section 2.4.1)                 |
   | CAPWAP (Section 3.7)            | Syslog (Section 2.2)            |
   |                                 | IPFIX (Section 2.3)             |
   |                                 | PSAMP (Section 2.3)             |
   |                                 | RADIUS accounting               |
   |                                 | (Section 3.5)                   |
   |                                 | Diameter accounting             |
   |                                 | (Section 3.6)                   |
   +---------------------------------+---------------------------------+

      Table 3: Protocol Classification by Push versus Pull Mechanism

A.4. Passive versus Active Monitoring 👀

monitoring splits into two categories: passive and active 🌈 passive monitoring can cover network traffic monitoring, monitoring of a device, or accounting of network resource consumption by users 🧚 active monitoring, as used in this document, focuses mainly on active network monitoring. it relies on injecting specific traffic (also called "synthetic traffic"), which then gets monitored 💜 the monitoring focus is shown in the table below as "network", "device", or "accounting" ✨

this classification leaves out non-monitoring protocols, like configuration protocols: Ad hoc network autoconfiguration, ANCP, and XCAP 🙅‍♀️ some active monitoring protocols work in the context of the data path, like ICMP Ping and Traceroute [RFC1470], Bidirectional Forwarding Detection (BFD) [RFC5880], and PWE3 Virtual Circuit Connectivity Verification (VCCV) [RFC5085]. those are covered in [OAM-OVERVIEW] 🔥

   +---------------------------------+---------------------------------+
   | Protocols supporting passive    | Protocols supporting active     |
   | monitoring                      | monitoring                      |
   +---------------------------------+---------------------------------+
   | IPFIX (network) (Section 2.3)   | OWAMP (network) (Section 3.4)   |
   | PSAMP (network) (Section 2.3)   | TWAMP (network) (Section 3.4)   |
   | SNMP (network and device)       |                                 |
   | (Section 2.1)                   |                                 |
   | NETCONF (device)                |                                 |
   | (Section 2.4.1)                 |                                 |
   | RADIUS (accounting)             |                                 |
   | (Section 3.5)                   |                                 |
   | Diameter (accounting)           |                                 |
   | (Section 3.6)                   |                                 |
   | CAPWAP (device) (Section 3.7)   |                                 |
   +---------------------------------+---------------------------------+

      Table 4: Protocols for Passive and Active Monitoring and Their
                             Monitoring Focus

The application of SNMP to passive traffic monitoring (e.g., with RMON-MIB) or active monitoring (with IPPM MIB) depends on the MIB modules used. however, the SNMP protocol itself does not have operations which support active monitoring 🙃 NETCONF can be used for passive monitoring, e.g., with the NETCONF Monitoring YANG module [RFC6022] for monitoring the NETCONF protocol. CAPWAP monitors the status of a Wireless Termination Point 📡

RADIUS and Diameter are considered passive monitoring protocols, since they perform accounting, i.e., counting the number of packets/bytes for a specific user 💖

A.5. Supported Data Model Types and Their Extensibility ✨

Okay bestie, this table is where it all comes together 💅 It matches each protocol to its data model type, shows how that model can be extended with what's available today, and tells you whether the protocol has a built-in way to add proprietary extensions 🎀

+-------------+---------------+------------------+------------------+
| Protocol    | Data Modeling | Data Model       | Proprietary Data |
|             |               | Extensions       | Modeling         |
|             |               |                  | Extensions       |
+-------------+---------------+------------------+------------------+
| SNMP        | MIB modules   | New MIB modules  | Enterprise-      |
| (S. 2.1)    | defined with  | specified in new | specific MIB     |
|             | SMI           | RFCs             | modules          |
|             | (S. 2.1.3)    |                  |                  |
|             |               |                  |                  |
| Syslog      | Structured    | With the         | Enterprise-      |
| (S. 2.2)    | Data Elements | procedure to add | specific SDEs    |
|             | (SDEs)        | Structured Data  |                  |
|             | (S. 4.2.1)    | ID in [RFC5424]  |                  |
|             |               |                  |                  |
| IPFIX       | IPFIX         | With the         | Enterprise-      |
| (S. 2.3)    | Information   | procedure to add | specific         |
|             | Elements,     | Information      | Information      |
|             | IPFIX IANA    | Elements         | Elements         |
|             | registry at   | specified in     | [RFC5101]        |
|             | [IANA-IPFIX]  | [RFC5102]        |                  |
|             | (S. 2.3)      |                  |                  |
|             |               |                  |                  |
| PSAMP       | PSAMP         | With the         | Enterprise-      |
| (S. 2.3)    | Information   | procedure to add | specific         |
|             | Elements, as  | Information      | Information      |
|             | an extension  | Elements         | Elements         |
|             | to IPFIX      | specified in     | [RFC5101]        |
|             | [IANA-IPFIX], | [RFC5102]        |                  |
|             | and PSAMP     |                  |                  |
|             | IANA registry |                  |                  |
|             | at            |                  |                  |
|             | [IANA-PSAMP]  |                  |                  |
|             | (S. 2.3)      |                  |                  |
|             |               |                  |                  |
| NETCONF     | YANG modules  | New YANG modules | Enterprise-      |
| (S. 2.4.1)  | (S. 2.4.2)    | specified in new | specific YANG    |
|             |               | RFCs following   | modules          |
|             |               | the guideline in |                  |
|             |               | [RFC6087]        |                  |
|             |               |                  |                  |
| IPPM OWAMP/ | IPPM metrics  | New IPPM metrics | Not applicable   |
| TWAMP       | (*) (S. 3.4)  | (S. 3.4)         |                  |
| (S. 3.4)    |               |                  |                  |
|             |               |                  |                  |
| RADIUS      | TLVs          | RADIUS-related   | Vendor-Specific  |
| (S. 3.5)    |               | registries at    | Attributes       |
|             |               | [IANA-AAA] and   | [RFC2865]        |
|             |               | [IANA-PROT]      |                  |
|             |               |                  |                  |
| Diameter    | AVPs          | Diameter-related | Vendor-Specific  |
| (S. 3.6)    |               | registry at      | Attributes       |
|             |               | [IANA-AAA]       | [RFC2865]        |
|             |               |                  |                  |
| CAPWAP      | TLVs          | New bindings     | Vendor-specific  |
| (S. 3.7)    |               | specified in new | TLVs             |
|             |               | RFCs             |                  |
+-------------+---------------+------------------+------------------+

               Table 5: Data Models and Their Extensibility

   (*): With the publication of [RFC6248], the latest IANA registry for
        IPFIX metrics has been declared Obsolete.

B.1. Energy Management (EMAN) ⚡

Energy management is becoming a must-have requirement for network management systems 💚 Why? Energy costs keep rising and fluctuating, people are way more aware of the ecological impact of running networks and devices, and governments are regulating how much energy gets consumed and produced 🌍

The big goal of energy management is running communication networks and other equipment on as little energy as possible while still delivering enough performance to hit service-level objectives ✨ Right now, though, most networking gear and network-attached devices neither monitor nor allow controlled energy usage 🥺 They're mostly built for fault, configuration, accounting, performance, and security management, so they aren't instrumented to know how much energy they're using. IETF documents only specify a handful of means for energy management, covering power monitoring, energy monitoring, and power state control.

Here's what makes energy management different from the other management tasks 👀 Sometimes a device's energy consumption isn't measured at the device itself. It gets reported by a different place instead. Think of a Power over Ethernet (PoE) sourcing device or a smart power strip, where one device is basically metering another remote device. That means you need a clear definition of how the reporting devices relate to each other, and a way to identify the remote devices that monitoring information is provided for. Power state control of remote devices has similar considerations, like a PoE sourcing device that switches power on and off at its ports 🔌 Another example is a gateway to low-resourced and lossy network devices in a wireless building network. In that case, the energy management system talks directly to the gateway, but not necessarily to the other devices in the building network 🏢

At the time of writing, the EMAN working group is working on the management of energy-aware devices 🧚 It's covered by the following items:

The requirements for energy management, specifying energy management properties that will allow networks and devices to become energy aware. On top of energy awareness requirements, the need for control functions will be discussed. Specifically, the need to monitor and control properties of devices that are remote to the reporting device should be discussed.
The energy management framework, which will describe extensions to the current management framework, required for energy management. This includes power and energy monitoring, power states, power state control, and potential power state transitions. The framework will focus on energy management for IP-based network equipment (routers, switches, PCs, IP cameras, phones and the like). In particular, the relationships between reporting devices, remote devices, and monitoring probes (such as might be used in low-power and lossy networks) need to be elaborated. For the case of a device reporting on behalf of other devices and controlling those devices, the framework will address the issues of discovery and identification of remote devices.
The Energy-aware Networks and Devices MIB document, for monitoring energy-aware networks and devices, will address device identification, context information, and the potential relationship between reporting devices, remote devices, and monitoring probes.
The Power and Energy Monitoring MIB document will define managed objects for the monitoring of power states and energy consumption/production. Monitoring of power states includes retrieving power states, properties of power states, current power state, power state transitions, and power state statistics. The managed objects will provide means of reporting detailed properties of the actual energy rate (power) and of accumulated energy. Further, they will provide information on electrical power quality.
The Battery MIB document will define managed objects for battery monitoring, providing means of reporting detailed properties of the actual charge, age, and state of a battery, plus battery statistics 🔋
The applicability statement will describe the variety of applications that can use the energy framework and associated MIB modules. Potential examples are building networks, home energy gateways, and so on. Finally, the document will also discuss how the framework relates to other architectures and frameworks (such as Smart Grid). The applicability statement will explain the relationship between this WG's work and other existing standards, e.g., from the IEC, ANSI, DMTF, etc. Note that the EMAN WG will be looking into existing standards such as those from the IEC, ANSI, DMTF and others, and reuse existing work as much as possible 🫶

The documents of the EMAN working group can be found at [EMAN-WG] 📚

Authors' Addresses 💌

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

EMail: mehmet.ersue@nsn.com


Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem  1831
Belgium

EMail: bclaise@cisco.com

📦 where this page comes from

ietf: rfc6632 2012-06
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms