RFC 4547
Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems
RFC 4547, Part 1 of 7 🎀
Bestie, this is RFC 4547 💖 It's a Standards Track doc from the Network Working Group, dated June 2006. Azlina Ahmad (Cisco Systems Inc.) and Greg Nakanishi (Motorola) wrote it. The full title is Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems. Its header doesn't list any RFCs it obsoletes or updates, so it isn't replacing or patching anything else ✨
Status of This Memo 🌈
Okay so this one is an Internet standards track protocol for the whole Internet community, and it's openly asking for discussion and suggestions to make it better 💬 If you want the standardization state and status, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And the best part? Distribution of this memo is unlimited 🦋
Copyright Notice 💜
Copyright (C) The Internet Society (2006). 🔒
Abstract 🌸
So this memo defines a chunk of the Management Information Base (MIB) for network management protocols used across the Internet community 🧚 Specifically, it's a basic set of managed objects for Simple Network Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification (DOCSIS) compliant Cable Modems and Cable Modem Termination Systems 📡 This MIB is an extension of the DOCSIS Cable Device MIB 💅
It's written as a MIB module that follows Structure of Management Information Version 2 (SMIv2) rules 🎀 The objects line up with the SNMP framework and existing SNMP standards, so everything is consistent 🫶
Table of Contents 📋
1. The Internet-Standard Management Framework ......................2
2. Glossary ........................................................2
2.1. BPI - Baseline Privacy Interface ...........................3
2.2. BPI - Baseline Privacy Plus Interface ......................3
2.3. CATV .......................................................3
2.4. CM - Cable Modem ...........................................3
2.5. CMTS - Cable Modem Termination System ......................3
2.6. DOCSIS .....................................................3
2.7. Downstream .................................................4
2.8. Head-end ...................................................4
2.9. MAC Packet .................................................4
2.10. RF ........................................................4
2.11. SID .......................................................4
2.12. TLV .......................................................4
2.13. Upstream ..................................................4
3. Overview ........................................................4
3.1. Structure of the MIB .......................................5
4. Definitions .....................................................5
5. Contributors ...................................................35
6. Acknowledgements ...............................................36
7. Security Considerations ........................................36
8. IANA Considerations ............................................37
9. References .....................................................37
9.1. Normative References ......................................37
9.2. Informative References ....................................381. The Internet-Standard Management Framework ✨
Want the full tea on the Internet-Standard Management Framework? Check section 7 of RFC 3410 [16] for a detailed overview of the documents that describe it 📖
Managed objects live in a virtual information store called the Management Information Base, or MIB 🗂️ You usually reach MIB objects through the Simple Network Management Protocol (SNMP) 📬 The objects are defined using the mechanisms in the Structure of Management Information (SMI) 🧩 This memo's MIB module is compliant with SMIv2, which is described in STD 58, RFC 2578 [2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 [4] 💅
2. Glossary 📚
All of these terms come from normal cable system usage or from the documents tied to the DOCSIS process 🍓
2.1. BPI - Baseline Privacy Interface 🔒
A mechanism for providing data privacy over the HFC network in DOCSIS 1.0 systems [8].
2.2. BPI - Baseline Privacy Plus Interface 🛡️
A mechanism that extends the Baseline Privacy Interface with the addition of CM authentication over the HFC network in DOCSIS 1.1/2.0 systems and beyond [9].
2.3. CATV 📺
Once upon a time it stood for "Community Antenna Television," and now it's used for any cable or hybrid fiber and cable system that delivers video signals to a community 🌈
2.4. CM - Cable Modem 🔌
A CM plays the "slave" station in a DOCSIS-compliant cable data system.
2.5. CMTS - Cable Modem Termination System 👑
A generic term covering a cable bridge or cable router in a head-end. A CMTS is the master station in a DOCSIS-compliant cable data system. It's the only station that transmits downstream, and it controls the scheduling of upstream transmissions by its associated CMs 🔥
2.6. DOCSIS 🧁
DOCSIS stands for "Data-over-Cable Service Interface Specifications." It refers to the ITU-T J.112 Annex B standard for cable modem systems [10], [13], commonly known as DOCSIS 1.0. The DOCSIS 1.1 specification extends DOCSIS 1.0 with new features for quality of service, fragmentation, and requirements for European cable plants [14] ✨
DOCSIS 2.0 [15] builds on DOCSIS 1.1 and gives you every feature and function DOCSIS 1.1 has 💖 On top of that, it brings some big upgrades to upstream capacity, like a 30.72 Mbps maximum upstream channel capacity, Synchronous-Code Division Multiple Access (CDMA) operation, better robustness to upstream noise and channel impairments, Enhanced Reed-Solomon error correction, and Trellis Coded Modulation 🚀
2.7. Downstream ⬇️
The direction from the CMTS to the CM.
2.8. Head-end 🏠
The origination point in most cable systems of the subscriber video signals. It's generally also where the CMTS equipment lives.
2.9. MAC Packet 📦
A term referring to DOCSIS Protocol Data Unit (PDU).
2.10. RF 📡
A term referring to Radio Frequency.
2.11. SID 🪪
A term referring to DOCSIS Service ID. The SID identifies a particular upstream bandwidth allocation and class-of-service management for DOCSIS, and it identifies a particular bidirectional security association for BPI 🔐
2.12. TLV 🧩
TLV stands for Type/Length/Value. It's an encoding method made of three fields. The first field says what type of element it is, the second field says how long the element is, and the third field holds the element's value 💜
2.13. Upstream ⬆️
The direction from the CM to the CMTS.
3. Overview 🌟
Offering High Speed Internet Service in the cable industry has become extremely successful 🎉 DOCSIS devices are being deployed at a rate of multiple thousands per day. Even though operators are enjoying that success, they're also facing the challenge of properly managing the devices they've deployed 😭 Operators are using Simple Network Management Protocol, a set of Management Information Base (MIB) required by DOCSIS, and SNMP Notifications to manage deployed DOCSIS devices. Using SNMP Notification for event reporting is getting more popular as an effective and efficient method for network monitoring 📈
Unfortunately, only a minimal set of SNMP Notifications is available right now 🥲 This notification MIB, together with [11] and [12], provides a minimum set of standard DOCSIS Notifications that DOCSIS devices SHOULD support, so that DOCSIS devices and networks can be managed successfully 🫶
This document defines a set of objects required for the event notification management of DOCSIS-compliant Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs). The MIB module is derived from the DOCSIS [11] and [12] 🍓
Appendix H of [11] defines all the DOCSIS 1.1 required events, and Appendix D of [12] does the same for DOCSIS 2.0. The notifications specified in this document are used to report these events via SNMP 🦋
Quick key-word heads-up 🚨 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
3.1. Structure of the MIB 🧱
This DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB was designed to extend the RFC2669 [5] notification module 🎀
Two groups of SNMP notification objects are defined in this document. One group defines notifications for cable modem events, and the other group defines notifications for cable modem termination system events 👯♀️
DOCSIS defines numerous events, and each event is assigned to a functional category. This MIB defines a notification object for each functional category. The varbinding list of each notification includes information about the event that occurred on the device 💫
4. Definitions 📜
The MIB module defined here IMPORTs from SNMPv2-SMI [2], SNMPv2-CONF [3], DOCS-CABLE-DEVICE-MIB [5], DOCS-IF-MIB [6], and IF-MIB [7] 🌸
Okay bestie, the MIB description is up first 💖 It explains that this MIB is basically an extension of the CABLE DEVICE MIB, with notification objects for both cable modems and CMTSes ✨
DESCRIPTION
"The Event Notification MIB is an extension of the
CABLE DEVICE MIB. It defines various notification
objects for both cable modem and cable modem termination
systems. Two groups of SNMP notification objects are
defined. One group is for notifying cable modem events,
and one group is for notifying cable modem termination
system events.
DOCSIS defines numerous events, and each event is
assigned to a functional category. This MIB defines
a notification object for each functional category.
The varbinding list of each notification includes
information about the event that occurred on the
device.
Copyright (C) The Internet Society (2006). This version
of this MIB module is part of RFC 4547; see the RFC
itself for full legal notices."
REVISION "200605240000Z" -- May 24, 2006
DESCRIPTION
"Initial version, published as RFC 4547."
::= { mib-2 132 }
docsDevNotifControl OBJECT IDENTIFIER ::= { docsDevNotifMIB 1}
docsDevCmNotifs OBJECT IDENTIFIER ::= { docsDevNotifMIB 2 0 }
docsDevCmtsNotifs OBJECT IDENTIFIER ::= { docsDevNotifMIB 3 0 }Next up is the control object for the CM notifications 🎀 It's a BITS object, so each bit switches one CM notification on or off 🔥
docsDevCmNotifControl OBJECT-TYPE
SYNTAX BITS {
cmInitTLVUnknownNotif( 0),
cmDynServReqFailNotif( 1),
cmDynServRspFailNotif( 2),
cmDynServAckFailNotif( 3),
cmBpiInitNotif( 4),
cmBPKMNotif( 5),
cmDynamicSANotif( 6),
cmDHCPFailNotif( 7),
cmSwUpgradeInitNotif( 8),
cmSwUpgradeFailNotif( 9),
cmSwUpgradeSuccessNotif( 10),
cmSwUpgradeCVCNotif( 11),
cmTODFailNotif( 12),
cmDCCReqFailNotif( 13),
cmDCCRspFailNotif( 14),
cmDCCAckFailNotif( 15)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The object is used to enable specific CM notifications.
For example, if the first bit is set, then
docsDevCmInitTLVUnknownNotif is enabled. If it is not set,
the notification is disabled. Note that notifications are
also under the control of the MIB modules defined in
RFC3413.
If the device is rebooted,the value of this object SHOULD
revert to the default value.
"
DEFVAL { {} }
::= { docsDevNotifControl 1 }Now the CMTS version 💅 Same idea, but for the CMTS notifications, with its own bits 🌸
docsDevCmtsNotifControl OBJECT-TYPE
SYNTAX BITS {
cmtsInitRegReqFailNotif( 0),
cmtsInitRegRspFailNotif( 1),
cmtsInitRegAckFailNotif( 2),
cmtsDynServReqFailNotif( 3),
cmtsDynServRspFailNotif( 4),
cmtsDynServAckFailNotif( 5),
cmtsBpiInitNotif( 6),
cmtsBPKMNotif( 7),
cmtsDynamicSANotif( 8),
cmtsDCCReqFailNotif( 9),
cmtsDCCRspFailNotif( 10),
cmtsDCCAckFailNotif( 11)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The object is used to enable specific CMTS notifications.
For example, if the first bit is set, then
docsDevCmtsInitRegRspFailNotif is enabled. If it is not set,
the notification is disabled. Note that notifications are
also under the control of the MIB modules defined in
RFC3413.
If the device is rebooted,the value of this object SHOULD
revert to the default value.
"
DEFVAL { {} }
::= { docsDevNotifControl 2 }Now the actual notifications, and every single one of them carries the same 8 objects in its varbinding list 🦋 The first one is the unknown TLV notification 👑
docsDevCmInitTLVUnknownNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"Notification to indicate that an unknown TLV was
encountered during the TLV parsing process.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 1 }Next is the dynamic service request failure notification 🌈
docsDevCmDynServReqFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic service
request during the dynamic services process.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected to (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 2 }Response failures get their own notification too 🍓
docsDevCmDynServRspFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
" A notification to report the failure of a dynamic service
response during the dynamic services process.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 3}Acknowledgement failures are next, and they're built the exact same way 🧚
docsDevCmDynServAckFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic service
acknowledgement during the dynamic services process.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 4}Last one for this part: the BPI initialization notification 🔐💜
docsDevCmBpiInitNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a BPI
initialization attempt during the registration process.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with theokay so we're still in the Definitions bit 💅 these are the notifications a cable modem sends when something goes sideways, and they all carry a shared bundle of objects in their varbinding list 🫶
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 5 }
docsDevCmBPKMNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a Baseline
Privacy Key Management (BPKM) operation.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 6 }
docsDevCmDynamicSANotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic security
association operation.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 7 }
docsDevCmDHCPFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsDevServerDhcp,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a DHCP operation.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsDevServerDhcp: the IP address of the DHCP server.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 8 }
docsDevCmSwUpgradeInitNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsDevSwFilename,
docsDevSwServer,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to indicate that a software upgrade
has been initiated on the device.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 9 }
docsDevCmSwUpgradeFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsDevSwFilename,
docsDevSwServer,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a software upgrade
attempt.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsDevSwFilename: the software image file name
- docsDevSwServer: the IP address of the server that
the image is retrieved from.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 10 }
docsDevCmSwUpgradeSuccessNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsDevSwFilename,
docsDevSwServer,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the software upgrade success
status.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsDevSwFilename: the software image file name
- docsDevSwServer: the IP address of the server that
the image is retrieved from.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 11 }Okay bestie, we're deep in the MIB now and it's giving notification overload 🔔💖 Each one is a little alarm the cable modem can ring when something goes sideways during a software upgrade, a time-of-day sync, or a channel change 🦋
docsDevCmSwUpgradeCVCFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report that the verification of the
code file has failed during a secure software upgrade
attempt.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 12 }The software upgrade one is the secure one 🔐 It fires when the code file fails verification during a secure software upgrade attempt. Lowkey the most dramatic one in this batch ✨
docsDevCmTODFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsDevServerTime,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a time of day
operation.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsDevServerTime: the IP address of the time server.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 13 }Time-of-day failures 🕰️ This one brings along the IP address of the time server, which is a super specific detail and I'm obsessed 🙈
docsDevCmDCCReqFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
" A notification to report the failure of a dynamic channel
change request during the dynamic channel change process
on the CM.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 14 }Dynamic channel change (DCC) is the CM switching channels on the fly 📡 These next few notifications are the DCC crew, and each one flags a different step where things can break 💅
docsDevCmDCCRspFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic channel
change response during the dynamic channel
change process on the CM.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmStatusModulationType: the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 15 } docsDevCmDCCAckFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
ifPhysAddress,
docsIfCmCmtsAddress,
docsIfDocsisBaseCapability,
docsIfCmStatusDocsisOperMode,
docsIfCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic channel
change acknowledgement during the dynamic channel
change process on the CM.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- ifPhysAddress: the MAC address of the cable
interface of this cable modem.
- docsIfCmCmtsAddress: the MAC address of the CMTS
to which the CM is connected (if there is a cable
card/interface in the CMTS, then it is actually the
MAC address of the cable interface to which it is
connected).
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmStatusDocsisOperMode: the QOS level (1.0, 1.1)
that the CM is operating in.
- docsIfCmtsCmStatusModulationType the upstream modulation
methodology used by the CM.
"
::= { docsDevCmNotifs 16}Heads up 🚨 the Ack one has a little quirk where the modulation type gets named docsIfCmtsCmStatusModulationType in its description text, which is different from the docsIfCmStatusModulationType in its OBJECTS list. I'm copying it exactly as written, because implementers are going to read every character 🤓
Now we're on the CMTS side 🏢 These notifications are reported by the CMTS instead of the modem itself 🫶
docsDevCmtsInitRegReqFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a registration
request from a CM during the CM initialization
process that was detected on the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 1 } docsDevCmtsInitRegRspFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a registration
response during the CM initialization
process that was detected by the CMTS.okay so this is where the notifications keep going 💖 these all have the same vibe: the CMTS spots something going wrong during the CM's setup and yells about it 📣
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 2 }
docsDevCmtsInitRegAckFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a registration
acknowledgement from the CM during the CM
initialization process that was detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 3 }
docsDevCmtsDynServReqFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic service
request during the dynamic services process
that was detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 4 }
docsDevCmtsDynServRspFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic service
response during the dynamic services process
that was detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 5 }
docsDevCmtsDynServAckFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic service
acknowledgement during the dynamic services
process that was detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 6 }
docsDevCmtsBpiInitNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a BPI
initialization attempt during the CM registration process
that was detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 7 }
docsDevCmtsBPKMNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a BPKM operation
that is detected by the CMTS.okay bestie, we're still deep in the CMTS notification pile 🍓 and honestly these are giving lots of repeated paragraphs, so I'm just gonna show you the exact text 💅 each notification sends the same little bundle of objects in its varbinding list, and the only thing that changes is the event it's reporting ✨
Here's the first batch, the tail of the notification description and then the dynamic security association one 🔥
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 8 }
docsDevCmtsDynamicSANotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic security
association operation that is detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 9 }Now the dynamic channel change family 🦋 There are three failure notifications here (request, response, and acknowledgement) and they all wear the exact same object list, just with a different description. Iconic consistency 👑
docsDevCmtsDCCReqFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic channel
change request during the dynamic channel
change process and is detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 10 }
docsDevCmtsDCCRspFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic channel
change response during the dynamic channel
change process and is detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 11 }
docsDevCmtsDCCAckFailNotif NOTIFICATION-TYPE
OBJECTS {
docsDevEvLevel,
docsDevEvId,
docsDevEvText,
docsIfCmtsCmStatusMacAddress,
ifPhysAddress,
docsIfCmtsCmStatusDocsisRegMode,
docsIfDocsisBaseCapability,
docsIfCmtsCmStatusModulationType
}
STATUS current
DESCRIPTION
"A notification to report the failure of a dynamic channel
change acknowledgement during the dynamic channel
change process and is detected by the CMTS.
This notification sends additional information about
the event by including the following objects in its
varbinding list.
- docsDevEvLevel: the priority level associated with the
event.
- docsDevEvId: the unique identifier of the event that
occurred.
- docsDevEvText: a textual description of the event.
- docsIfCmtsCmStatusMacAddress: the MAC address of the CM
with which this notification is associated.
- ifPhysAddress: the MAC address of the CMTS
(if there is a cable card/interface in the CMTS,
then it is actually the MAC address of the cable
interface that connected to the CM) cable interface
connected to the CM.
- docsIfCmtsCmStatusDocsisRegMode: the QOS level (1.0, 1.1)
that the reporting CM is operating in.
- docsIfDocsisBaseCapability: the highest
version of the DOCSIS specification (1.0, 1.1, 2.0)
that the device is capable of supporting.
- docsIfCmtsCmStatusModulationType: the upstream
modulation methodology used by the CM.
"
::= { docsDevCmtsNotifs 12}Next up is the conformance section 🌸 This is where the MIB gets its little ID tree for compliance statements and the groups that go with them, so the CM and CMTS notification groups get bundled up neatly 🧚
--
--Conformance definitions
--
docsDevNotifConformance OBJECT IDENTIFIER
::= { docsDevNotifMIB 4 }
docsDevNotifGroups OBJECT IDENTIFIER
::= { docsDevNotifConformance 1 }
docsDevNotifCompliances OBJECT IDENTIFIER
::= { docsDevNotifConformance 2 }
docsDevCmNotifCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for CM Notifications and Control."
MODULE --docsDevNotif
MANDATORY-GROUPS {
docsDevCmNotifControlGroup,
docsDevCmNotificationGroup
}
::= { docsDevNotifCompliances 1 }
docsDevCmNotifControlGroup OBJECT-GROUP
OBJECTS {
docsDevCmNotifControl
}
STATUS current
DESCRIPTION
"This group represents objects that allow control
over CM Notifications."
::= { docsDevNotifGroups 1 }
docsDevCmNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
docsDevCmInitTLVUnknownNotif,
docsDevCmDynServReqFailNotif,
docsDevCmDynServRspFailNotif,
docsDevCmDynServAckFailNotif,
docsDevCmBpiInitNotif,
docsDevCmBPKMNotif,
docsDevCmDynamicSANotif,
docsDevCmDHCPFailNotif,
docsDevCmSwUpgradeInitNotif,
docsDevCmSwUpgradeFailNotif,
docsDevCmSwUpgradeSuccessNotif,
docsDevCmSwUpgradeCVCFailNotif,
docsDevCmTODFailNotif,
docsDevCmDCCReqFailNotif,
docsDevCmDCCRspFailNotif,
docsDevCmDCCAckFailNotif
}
STATUS current
DESCRIPTION
"A collection of CM notifications providing device status
and control."
::= { docsDevNotifGroups 2 }
docsDevCmtsNotifCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for DOCSIS CMTS Notification
and Control."
MODULE --docsDevNotif
MANDATORY-GROUPS {
docsDevCmtsNotifControlGroup,
docsDevCmtsNotificationGroup
}
::= { docsDevNotifCompliances 2 }
docsDevCmtsNotifControlGroup OBJECT-GROUP
OBJECTS {
docsDevCmtsNotifControl
}
STATUS current
DESCRIPTION
"This group represents objects that allow control
over CMTS Notifications."
::= { docsDevNotifGroups 3 }
docsDevCmtsNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
docsDevCmtsInitRegReqFailNotif,
docsDevCmtsInitRegRspFailNotif,
docsDevCmtsInitRegAckFailNotif ,
docsDevCmtsDynServReqFailNotif,
docsDevCmtsDynServRspFailNotif,
docsDevCmtsDynServAckFailNotif,
docsDevCmtsBpiInitNotif,
docsDevCmtsBPKMNotif,
docsDevCmtsDynamicSANotif,
docsDevCmtsDCCReqFailNotif,
docsDevCmtsDCCRspFailNotif,
docsDevCmtsDCCAckFailNotif
}
STATUS current
DESCRIPTION
"A collection of CMTS notifications providing device
status and control."
::= { docsDevNotifGroups 4 }
ENDThat's the whole MIB module wrapped up, so the rest of the doc is where we get the wider context 💜 More parts are still coming, so stay tuned, bestie 🎀🦋
5. Contributors 🫶
Huge shoutout to the people who made significant contributions to this doc: Junming Gao, Jean-Francois Mule, Dave Raftus, Pak Siripunkaw, and Rich Woundy. You all are absolute legends 👑
6. Acknowledgements 🌸
This doc was produced by the IPCDN Working Group. Thank you to Harrie Hazewinkel and Bert Wijnen for their thorough review and insightful comments 💅. Special love to Rich Woundy, who came in with several valuable suggestions to improve the notifications 💖.
7. Security Considerations 🔐
Okay, this section is serious, so read it carefully bestie 😭.
There are two management objects in this MIB module with a MAX-ACCESS clause of read-write and/or read-create (docsDevCmNotifControl and docsDevCmtsNotifControl). Such objects may be considered sensitive or vulnerable in some network environments. Supporting SET operations in a non-secure environment without proper protection can have a negative effect on network operations ⚠️.
SettingdocsDevCmNotifControlordocsDevCmtsNotifControlmay cause flooding of notifications, which can disrupt network service. Besides causing "flooding", changing these objects can also mean that notifications will not be emitted when one intends that to happen 🙈
This MIB defines a number of notification objects that send detailed information about the event that caused the notification to be generated. The notification message includes:
- event priority
- the event Id
- the event message body
- the CM DOCSIS capability
- the CM DOCSIS QOS level
- the CM DOCSIS upstream modulation type
- the cable interface MAC address of the cable modem
- the cable card MAC address of the CMTS to which the modem is connected
Watching these notification messages could be used to gather information about the state of the network and devices (CM and CMTS) attached to it 👀. Honestly, that's a lot of tea ☕.
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), there is still no control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Not me being shocked 💀.
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [16], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy) 🔒.
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured, so that the objects are only accessible to those principals (users) who have legitimate rights to GET or SET (change/create/delete) them. Main character energy for the security team 🦋.
8. IANA Considerations 📝
The MIB module defined in this document uses the following IANA-assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
docsDevNotifMIB { mib-2 132 }9. References 📚
9.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [4] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [5] St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August 1999.
- [6] 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.
- [7] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
- [8] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2", 2002,
<http://www.scte.org/standards/>. - [9] CableLabs, "Baseline Privacy Plus Interface Specification SP-BPI+040407", April 2004,
<http://www.cablemodem.com/specifications/>. - [10] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Operations Support System Interface Specification Radio Frequency Interface SCTE 22-3", 2002,
<http://www.scte.org/standards/>. - [11] CableLabs, "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification CM-SP-OSSIv1.1-C01-050907", September 2005,
<http://www.cablemodem.com/specifications/>. - [12] CableLabs, "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification CM-SP-OSSIv2.0-I09-050812", August 2005,
<http://www.cablemodem.com/specifications/>. - [13] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Radio Frequency Interface Specification SCTE 22-1", 2002,
<http://www.scte.org/standards/>. - [14] CableLabs, "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification CM-SP-RFIv1.1-C01-050907", September 2005,
<http://www.cablemodem.com/specifications/>. - [15] CableLabs, "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification CM-SP-RFIv2.0-I10-051209", December 2005,
<http://www.cablemodem.com/specifications/>.
9.2. Informative References
- [16] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
Authors' Addresses 💌
Azlina Ahmad
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
US
Phone: 408 853 7927
EMail: azlina@cisco.com
Greg Nakanishi
Motorola
6450 Sequence Dr.
San Diego, CA 92126
US
Phone: 858 404-2366
EMail: gnakanishi@motorola.comFull Copyright Statement ©️
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧾
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also does not represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🙏
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
And that's the whole doc, bestie! 🌈✨ You made it through all 7 parts 💖
📦 where this page comes from
- ietf: rfc4547 2006-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms