diff --git a/doc/source/fault-mgmt/kubernetes/snmp-active-alarm-table.rst b/doc/source/fault-mgmt/kubernetes/snmp-active-alarm-table.rst
index e6bbb8bfb..f5053fa8f 100644
--- a/doc/source/fault-mgmt/kubernetes/snmp-active-alarm-table.rst
+++ b/doc/source/fault-mgmt/kubernetes/snmp-active-alarm-table.rst
@@ -6,36 +6,40 @@
 SNMP Active Alarms Table
 ========================
 
-|prod| supports the :abbr:`SNMP (Simple Network Management Protocol)` Active
-alarm table from the Wind River Alarm MIB via SNMP.
+|prod| supports the |SNMP| Active alarm table from the Wind River Alarm
+MIB via |SNMP|.
 
 The active alarm table contains a list of all active or set alarms in the
 system. Each entry in the table includes the following variables:
 
--   <UUID>
+- wrsAlarmActiveUuid                      
 
--   <AlarmID>
+- wrsAlarmActiveAlarmId                   
 
--   <EntityInstanceID>
+- wrsAlarmActiveEntityInstanceId          
 
--   <DateAndTime>
+- wrsAlarmActiveDateAndTime               
 
--   <AlarmSeverity>
+- wrsAlarmActiveAlarmSeverity             
 
--   <ReasonText>
+- wrsAlarmActiveReasonText                
 
--   <EventType>
+- wrsAlarmActiveEventType                 
 
--   <ProbableCause>
+- wrsAlarmActiveProbableCause             
 
--   <ProposedRepairAction>
+- wrsAlarmActiveProposedRepairAction     
 
--   <ServiceAffecting>
+- wrsAlarmActiveServiceAffecting          
 
--   <SuppressionAllowed>
+- wrsAlarmActiveSuppressionAllowed 
 
-An external SNMP Manager can examine the Active Alarm table contents by doing
-an SNMP Walk of the table.
+
+See https://opendev.org/starlingx/snmp-armada-app/src/branch/master/stx-snmp-helm/centos/docker/stx-snmp/mibs/wrsAlarmMib.mib.txt
+for alarm details.
+
+An external |SNMP| Manager can examine the Active Alarm table contents by doing
+an |SNMP| Walk of the table.
 
 For example, below is the output for a simple **snmpwalk** CLI tool showing a
 table with three rows (i.e. three active alarms).
diff --git a/doc/source/fault-mgmt/kubernetes/snmp-event-table.rst b/doc/source/fault-mgmt/kubernetes/snmp-event-table.rst
index e43f62c4f..60851efe7 100644
--- a/doc/source/fault-mgmt/kubernetes/snmp-event-table.rst
+++ b/doc/source/fault-mgmt/kubernetes/snmp-event-table.rst
@@ -6,8 +6,7 @@
 SNMP Event Table
 ================
 
-|prod| supports the Event table from the Wind River Alarm MIB via :abbr:`SNMP
-(Simple Network Management Protocol)`.
+|prod| supports the Event table from the Wind River Alarm MIB via |SNMP|.
 
 The Event table contains a historic list of all alarm events (SETs and CLEARs)
 and customer log events.
@@ -16,31 +15,34 @@ Each entry in the table includes the following variables:
 
 .. _snmp-event-table-ul-y1w-4lk-qq:
 
--   <UUID>
+-   wrsEventUuid
 
--   <EventID>
+-   wrsEventEventId
 
--   <State>
+-   wrsEventState
 
--   <EntityInstanceID>
+-   wrsEventEntityInstanceId
 
--   <DateAndTime>
+-   wrsEventDateAndTime
 
--   <EventSeverity>
+-   wrsEventSeverity
 
--   <ReasonText>
+-   wrsEventReasonText
 
--   <EventType>
+-   wrsEventEventType
 
--   <ProbableCause>
+-   wrsEventProbableCause
 
--   <ProposedRepairAction>
+-   wrsEventProposedRepairAction
 
--   <ServiceAffecting>
+-   wrsEventServiceAffecting
 
--   <SuppressionAllowed>
+-   wrsEventSuppressionAllowed
 
-An external SNMP Manager can examine the Event table contents by doing an SNMP
+See https://opendev.org/starlingx/snmp-armada-app/src/branch/master/stx-snmp-helm/centos/docker/stx-snmp/mibs/wrsAlarmMib.mib.txt
+for alarm details.
+
+An external |SNMP| manager can examine the Event table contents by doing an |SNMP|
 Walk of the table.
 
 For example, below is the output for a simple :command:`snmpwalk` CLI tool.
diff --git a/doc/source/fault-mgmt/kubernetes/traps.rst b/doc/source/fault-mgmt/kubernetes/traps.rst
index a5157e970..e6c2753f8 100644
--- a/doc/source/fault-mgmt/kubernetes/traps.rst
+++ b/doc/source/fault-mgmt/kubernetes/traps.rst
@@ -14,19 +14,19 @@ The following traps are defined.
 
 .. _traps-ul-p1j-tvn-c5:
 
--   **wrsAlarmCritical**
+-   wrsAlarmCritical
 
--   **wrsAlarmMajor**
+-   wrsAlarmMajor
 
--   **wrsAlarmMinor**
+-   wrsAlarmMinor
 
--   **wrsAlarmWarning**
+-   wrsAlarmWarning
 
--   **wrsAlarmMessage**
+-   wrsAlarmMessage
 
--   **wrsAlarmClear**
+-   wrsAlarmClear
 
--   **wrsAlarmHierarchicalClear**
+-   wrsAlarmHierarchicalClear
 
 |prod| alarms are mapped into one of the above traps based on severity, and
 customer logs are mapped into the 'Message' trap.
@@ -44,26 +44,29 @@ For the Clear trap, **varbinds** include only the following variables:
 
 .. _traps-ul-uks-byn-nkb:
 
--   <AlarmID>
+-   wrsAlarmActiveAlarmID
 
--   <EntityInstanceID>
+-   wrsAlarmActiveEntityInstanceID
 
--   <DateAndTime>
+-   wrsAlarmActiveDateAndTime
 
--   <ReasonText>
+-   wrsAlarmActiveReasonText
 
 For the HierarchicalClear trap, **varbinds** include only the following
 variables:
 
 .. _traps-ul-isn-fyn-nkb:
 
--   <EntityInstanceID>
+-   wrsAlarmActiveEntityInstanceID
 
--   <DateAndTime>
+-   wrsAlarmActiveDateAndTime
 
--   <ReasonText>
+-   wrsAlarmActiveReasonText
 
 For all alarms, the Notification Type is based on the severity of the trap or
 alarm. This is done to facilitate the interaction with most SNMP trap viewers
 which use the Notification Type to drive the coloring of traps, that is, red
 for critical, yellow for minor, and so on.
+
+See https://opendev.org/starlingx/snmp-armada-app/src/branch/master/stx-snmp-helm/centos/docker/stx-snmp/mibs/wrsAlarmMib.mib.txt
+for alarm details.