draft-ietf-ccamp-alarm-module-05.txt   draft-ietf-ccamp-alarm-module-06.txt 
Network Working Group S. Vallin Network Working Group S. Vallin
Internet-Draft Stefan Vallin AB Internet-Draft Stefan Vallin AB
Intended status: Standards Track M. Bjorklund Intended status: Standards Track M. Bjorklund
Expires: May 10, 2019 Cisco Expires: May 26, 2019 Cisco
November 6, 2018 November 22, 2018
YANG Alarm Module YANG Alarm Module
draft-ietf-ccamp-alarm-module-05 draft-ietf-ccamp-alarm-module-06
Abstract Abstract
This document defines a YANG module for alarm management. It This document defines a YANG module for alarm management. It
includes functions for alarm list management, alarm shelving and includes functions for alarm list management, alarm shelving and
notifications to inform management systems. There are also RPCs to notifications to inform management systems. There are also
manage the operator state of an alarm and administrative alarm operations to manage the operator state of an alarm and
procedures. The module carefully maps to relevant alarm standards. administrative alarm procedures. The module carefully maps to
relevant alarm standards.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 10, 2019. This Internet-Draft will expire on May 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
3.3. Identifying the Alarming Resource . . . . . . . . . . . . 7 3.3. Identifying the Alarming Resource . . . . . . . . . . . . 7
3.4. Identifying Alarm Instances . . . . . . . . . . . . . . . 8 3.4. Identifying Alarm Instances . . . . . . . . . . . . . . . 8
3.5. Alarm Life-Cycle . . . . . . . . . . . . . . . . . . . . 8 3.5. Alarm Life-Cycle . . . . . . . . . . . . . . . . . . . . 8
3.5.1. Resource Alarm Life-Cycle . . . . . . . . . . . . . . 9 3.5.1. Resource Alarm Life-Cycle . . . . . . . . . . . . . . 9
3.5.2. Operator Alarm Life-cycle . . . . . . . . . . . . . . 10 3.5.2. Operator Alarm Life-cycle . . . . . . . . . . . . . . 10
3.5.3. Administrative Alarm Life-Cycle . . . . . . . . . . . 10 3.5.3. Administrative Alarm Life-Cycle . . . . . . . . . . . 10
3.6. Root Cause, Impacted Resources and Related Alarms . . . . 10 3.6. Root Cause, Impacted Resources and Related Alarms . . . . 10
3.7. Alarm Shelving . . . . . . . . . . . . . . . . . . . . . 11 3.7. Alarm Shelving . . . . . . . . . . . . . . . . . . . . . 11
3.8. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 12 3.8. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 12
4. Alarm Data Model . . . . . . . . . . . . . . . . . . . . . . 12 4. Alarm Data Model . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Alarm Control . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Alarm Control . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Alarm Shelving . . . . . . . . . . . . . . . . . . . 14 4.1.1. Alarm Shelving . . . . . . . . . . . . . . . . . . . 14
4.2. Alarm Inventory . . . . . . . . . . . . . . . . . . . . . 14 4.2. Alarm Inventory . . . . . . . . . . . . . . . . . . . . . 14
4.3. Alarm Summary . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Alarm Summary . . . . . . . . . . . . . . . . . . . . . . 15
4.4. The Alarm List . . . . . . . . . . . . . . . . . . . . . 15 4.4. The Alarm List . . . . . . . . . . . . . . . . . . . . . 16
4.5. The Shelved Alarms List . . . . . . . . . . . . . . . . . 17 4.5. The Shelved Alarms List . . . . . . . . . . . . . . . . . 18
4.6. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 17 4.6. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 18
4.7. RPCs and Actions . . . . . . . . . . . . . . . . . . . . 17 4.7. Operations . . . . . . . . . . . . . . . . . . . . . . . 19
4.8. Notifications . . . . . . . . . . . . . . . . . . . . . . 18 4.8. Notifications . . . . . . . . . . . . . . . . . . . . . . 19
5. Alarm YANG Module . . . . . . . . . . . . . . . . . . . . . . 18 5. Relationship to the ietf-hardware YANG module . . . . . . . . 19
6. X.733 Extensions . . . . . . . . . . . . . . . . . . . . . . 48 6. Alarm YANG Module . . . . . . . . . . . . . . . . . . . . . . 20
7. The X.733 Mapping Module . . . . . . . . . . . . . . . . . . 48 7. X.733 Extensions . . . . . . . . . . . . . . . . . . . . . . 50
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 8. The X.733 Mapping Module . . . . . . . . . . . . . . . . . . 51
9. Security Considerations . . . . . . . . . . . . . . . . . . . 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60 10. Security Considerations . . . . . . . . . . . . . . . . . . . 63
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64
11.1. Normative References . . . . . . . . . . . . . . . . . . 60 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
11.2. Informative References . . . . . . . . . . . . . . . . . 62 12.1. Normative References . . . . . . . . . . . . . . . . . . 64
Appendix A. Vendor-specific Alarm-Types Example . . . . . . . . 63 12.2. Informative References . . . . . . . . . . . . . . . . . 65
Appendix B. Alarm Inventory Example . . . . . . . . . . . . . . 64 Appendix A. Vendor-specific Alarm-Types Example . . . . . . . . 66
Appendix C. Alarm List Example . . . . . . . . . . . . . . . . . 65 Appendix B. Alarm Inventory Example . . . . . . . . . . . . . . 67
Appendix D. Alarm Shelving Example . . . . . . . . . . . . . . . 66 Appendix C. Alarm List Example . . . . . . . . . . . . . . . . . 68
Appendix E. X.733 Mapping Example . . . . . . . . . . . . . . . 67 Appendix D. Alarm Shelving Example . . . . . . . . . . . . . . . 69
Appendix F. Relationships to other standards . . . . . . . . . . 68 Appendix E. X.733 Mapping Example . . . . . . . . . . . . . . . 70
F.1. Relationship to RFC 8348 . . . . . . . . . . . . . . . . 68 Appendix F. Relationship to other alarm standards . . . . . . . 71
F.2. Relationship to other alarm standards . . . . . . . . . . 68 F.1. Alarm definition . . . . . . . . . . . . . . . . . . . . 71
F.2.1. Alarm definition . . . . . . . . . . . . . . . . . . 68 F.2. Data model . . . . . . . . . . . . . . . . . . . . . . . 73
F.2.2. Data model . . . . . . . . . . . . . . . . . . . . . 70 F.2.1. X.733 . . . . . . . . . . . . . . . . . . . . . . . . 73
Appendix G. Alarm Usability Requirements . . . . . . . . . . . . 72 F.2.2. RFC 3877, the Alarm MIB . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 F.2.3. 3GPP Alarm IRP . . . . . . . . . . . . . . . . . . . 74
F.2.4. G.7710 . . . . . . . . . . . . . . . . . . . . . . . 74
Appendix G. Alarm Usability Requirements . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
1. Introduction 1. Introduction
This document defines a YANG [RFC7950] module for alarm management. This document defines a YANG [RFC7950] module for alarm management.
The purpose is to define a standardized alarm interface for network The purpose is to define a standardized alarm interface for network
devices that can be easily integrated into management applications. devices that can be easily integrated into management applications.
The model is also applicable as a northbound alarm interface in the The model is also applicable as a northbound alarm interface in the
management applications. management applications.
Alarm monitoring is a fundamental part of monitoring the network. Alarm monitoring is a fundamental part of monitoring the network.
skipping to change at page 3, line 43 skipping to change at page 3, line 46
capitals, as shown here. capitals, as shown here.
The following terms are defined in [RFC7950]: The following terms are defined in [RFC7950]:
o action o action
o client o client
o data tree o data tree
o RPC
o server o server
The following terms are used within this document: The following terms are used within this document:
o Alarm (the general concept): An alarm signifies an undesirable o Alarm (the general concept): An alarm signifies an undesirable
state in a resource that requires corrective action. state in a resource that requires corrective action.
o Alarm Type: An alarm type identifies a possible unique alarm state o Alarm Type: An alarm type identifies a possible unique alarm state
for a resource. Alarm types are names to identify the state like for a resource. Alarm types are names to identify the state like
"link-alarm", "jitter-violation", "high-disk-utilization". "link-alarm", "jitter-violation", "high-disk-utilization".
skipping to change at page 9, line 23 skipping to change at page 9, line 23
3.5.1. Resource Alarm Life-Cycle 3.5.1. Resource Alarm Life-Cycle
From a resource perspective, an alarm can for example have the From a resource perspective, an alarm can for example have the
following life-cycle: raise, change severity, change severity, clear, following life-cycle: raise, change severity, change severity, clear,
being raised again etc. All of these status changes can have being raised again etc. All of these status changes can have
different alarm texts generated by the instrumentation. Two different alarm texts generated by the instrumentation. Two
important things to note: important things to note:
1. Alarms are not deleted when they are cleared. Deleting alarms is 1. Alarms are not deleted when they are cleared. Deleting alarms is
an administrative process. The alarm module defines an rpc an administrative process. The alarm module defines an action
"purge" that deletes alarms. "purge-alarms" that deletes alarms.
2. Alarms are not cleared by operators, only the underlying 2. Alarms are not cleared by operators, only the underlying
instrumentation can clear an alarm. Operators can close alarms. instrumentation can clear an alarm. Operators can close alarms.
The YANG tree representation below illustrates the resource oriented The YANG tree representation below illustrates the resource oriented
life-cycle: life-cycle:
+--ro alarm* [resource alarm-type-id alarm-type-qualifier] +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
... ...
+--ro is-cleared boolean +--ro is-cleared boolean
skipping to change at page 10, line 23 skipping to change at page 10, line 23
| +--ro time yang:date-and-time | +--ro time yang:date-and-time
| +--ro operator string | +--ro operator string
| +--ro state operator-state | +--ro state operator-state
| +--ro text? string | +--ro text? string
+---x set-operator-state {operator-actions}? +---x set-operator-state {operator-actions}?
+---w input +---w input
+---w state writable-operator-state +---w state writable-operator-state
+---w text? string +---w text? string
The operator state for an alarm can be: "none", "ack", "shelved", and The operator state for an alarm can be: "none", "ack", "shelved", and
"closed". Alarm deletion (using the rpc "purge-alarms"), can use "closed". Alarm deletion (using the action "purge-alarms"), can use
this state as a criteria. A closed alarm is an alarm where the this state as a criteria. A closed alarm is an alarm where the
operator has performed any required corrective actions. Closed operator has performed any required corrective actions. Closed
alarms are good candidates for being purged. alarms are good candidates for being purged.
3.5.3. Administrative Alarm Life-Cycle 3.5.3. Administrative Alarm Life-Cycle
Deleting alarms from the alarm list is considered an administrative Deleting alarms from the alarm list is considered an administrative
action. This is supported by the "purge-alarms" rpc. The "purge- action. This is supported by the "purge-alarms" action. The "purge-
alarms" rpc takes a filter as input. The filter selects alarms based alarms" action takes a filter as input. The filter selects alarms
on the operator and resource life-cycle such as "all closed cleared based on the operator and resource life-cycle such as "all closed
alarms older than a time specification". The server may also perform cleared alarms older than a time specification". The server may also
these operations based on other policies, but how that is done is out perform these operations based on other policies, but how that is
of scope for this document. done is out of scope for this document.
Purged alarms are removed from the alarm list. Note well, if the Purged alarms are removed from the alarm list. Note well, if the
alarm resource state changes after a purge, the alarm will reappear alarm resource state changes after a purge, the alarm will reappear
in the alarm list. in the alarm list.
Alarms can be compressed. Compressing an alarm deletes all entries Alarms can be compressed. Compressing an alarm deletes all entries
in the alarm's "status-change" list except for the last status in the alarm's "status-change" list except for the last status
change. A client can perform this using the "compress-alarms" rpc. change. A client can perform this using the "compress-alarms"
The server may also perform these operations based on other policies, action. The server may also perform these operations based on other
but how that is done is out of scope for this document. policies, but how that is done is out of scope for this document.
3.6. Root Cause, Impacted Resources and Related Alarms 3.6. Root Cause, Impacted Resources and Related Alarms
The general principle of this alarm module is to limit the amount of The general principle of this alarm module is to limit the amount of
alarms. In many cases several resources are affected for a given alarms. In many cases several resources are affected for a given
underlying problem. A full disk will of course impact databases and underlying problem. A full disk will of course impact databases and
applications as well. The recommendation is not have a single alarm applications as well. The recommendation is not have a single alarm
for the underlying problem an list the affected resources in the for the underlying problem an list the affected resources in the
alarm, rather than having separate alarms for each resource. alarm, rather than having separate alarms for each resource.
skipping to change at page 13, line 22 skipping to change at page 13, line 22
| +--ro alarm-type* [alarm-type-id alarm-type-qualifier] | +--ro alarm-type* [alarm-type-id alarm-type-qualifier]
| ... | ...
+--ro summary {alarm-summary}? +--ro summary {alarm-summary}?
| +--ro alarm-summary* [severity] | +--ro alarm-summary* [severity]
| | ... | | ...
| +--ro shelves-active? empty {alarm-shelving}? | +--ro shelves-active? empty {alarm-shelving}?
+--ro alarm-list +--ro alarm-list
| +--ro number-of-alarms? yang:gauge32 | +--ro number-of-alarms? yang:gauge32
| +--ro last-changed? yang:date-and-time | +--ro last-changed? yang:date-and-time
| +--ro alarm* [resource alarm-type-id alarm-type-qualifier] | +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
| | ...
| +---x purge-alarms
| | ...
| +---x compress-alarms {alarm-history}?
| ... | ...
+--ro shelved-alarms {alarm-shelving}? +--ro shelved-alarms {alarm-shelving}?
| +--ro number-of-shelved-alarms? yang:gauge32 | +--ro number-of-shelved-alarms? yang:gauge32
| +--ro shelved-alarms-last-changed? yang:date-and-time | +--ro shelved-alarms-last-changed? yang:date-and-time
| +--ro shelved-alarm* | +--ro shelved-alarm*
| [resource alarm-type-id alarm-type-qualifier] | | [resource alarm-type-id alarm-type-qualifier]
| | ...
| +---x purge-shelved-alarms
| | ...
| +---x compress-shelved-alarms {alarm-history}?
| ... | ...
+--rw alarm-profile* +--rw alarm-profile*
[alarm-type-id alarm-type-qualifier-match resource] [alarm-type-id alarm-type-qualifier-match resource]
{alarm-profile}? {alarm-profile}?
+--rw alarm-type-id al:alarm-type-id +--rw alarm-type-id alarm-type-id
+--rw alarm-type-qualifier-match string +--rw alarm-type-qualifier-match string
+--rw resource al:resource-match +--rw resource resource-match
+--rw description string +--rw description string
+--rw alarm-severity-assignment-profile +--rw alarm-severity-assignment-profile
{severity-assignment}? {severity-assignment}?
... ...
4.1. Alarm Control 4.1. Alarm Control
The "/alarms/control/notify-status-changes" choice controls if The "/alarms/control/notify-status-changes" choice controls if
notifications are sent for all state changes, only raise and clear, notifications are sent for all state changes, only raise and clear,
or only notifications more severe than a configured level. This or only notifications more severe than a configured level. This
skipping to change at page 15, line 11 skipping to change at page 15, line 21
Note that the mechanism whereby dynamic alarm types are added using Note that the mechanism whereby dynamic alarm types are added using
the alarm type qualifier MUST populate this list. the alarm type qualifier MUST populate this list.
The optional leaf-list "resource" in the alarm inventory enables the The optional leaf-list "resource" in the alarm inventory enables the
system to publish for which resources a given alarm type may appear. system to publish for which resources a given alarm type may appear.
A server MUST implement the alarm inventory in order to enable A server MUST implement the alarm inventory in order to enable
controlled alarm procedures in the client. controlled alarm procedures in the client.
A server implementer may want to document the alarm inventory for
off-line processing by clients. The file format defined in
[I-D.ietf-netmod-yang-instance-file-format] can be used for this
purpose.
The alarm inventory tree is shown below: The alarm inventory tree is shown below:
+--ro alarm-inventory +--ro alarm-inventory
+--ro alarm-type* [alarm-type-id alarm-type-qualifier] +--ro alarm-type* [alarm-type-id alarm-type-qualifier]
+--ro alarm-type-id alarm-type-id +--ro alarm-type-id alarm-type-id
+--ro alarm-type-qualifier alarm-type-qualifier +--ro alarm-type-qualifier alarm-type-qualifier
+--ro resource* resource-match +--ro resource* resource-match
+--ro has-clear boolean +--ro has-clear boolean
+--ro severity-levels* severity +--ro severity-levels* severity
+--ro description string +--ro description string
skipping to change at page 16, line 13 skipping to change at page 16, line 35
state. The composite state includes states for the resource life- state. The composite state includes states for the resource life-
cycle such as severity, clearance flag and operator states such as cycle such as severity, clearance flag and operator states such as
acknowledgment. This means that for a given resource and alarm-type acknowledgment. This means that for a given resource and alarm-type
the alarm list shows the current states of the alarm such as the alarm list shows the current states of the alarm such as
acknowledged and cleared status. acknowledged and cleared status.
+--ro alarm-list +--ro alarm-list
+--ro number-of-alarms? yang:gauge32 +--ro number-of-alarms? yang:gauge32
+--ro last-changed? yang:date-and-time +--ro last-changed? yang:date-and-time
+--ro alarm* [resource alarm-type-id alarm-type-qualifier] +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
+--ro resource resource | +--ro resource resource
+--ro alarm-type-id alarm-type-id | +--ro alarm-type-id alarm-type-id
+--ro alarm-type-qualifier alarm-type-qualifier | +--ro alarm-type-qualifier alarm-type-qualifier
+--ro alt-resource* resource | +--ro alt-resource* resource
+--ro related-alarm* | +--ro related-alarm*
| [resource alarm-type-id alarm-type-qualifier] | | [resource alarm-type-id alarm-type-qualifier]
| +--ro resource | | +--ro resource
| | -> /alarms/alarm-list/alarm/resource | | | -> /alarms/alarm-list/alarm/resource
| +--ro alarm-type-id leafref | | +--ro alarm-type-id leafref
| +--ro alarm-type-qualifier leafref | | +--ro alarm-type-qualifier leafref
+--ro impacted-resource* resource | +--ro impacted-resource* resource
+--ro root-cause-resource* resource | +--ro root-cause-resource* resource
+--ro time-created yang:date-and-time | +--ro time-created yang:date-and-time
+--ro is-cleared boolean | +--ro is-cleared boolean
+--ro last-changed yang:date-and-time | +--ro last-raised yang:date-and-time
+--ro perceived-severity severity | +--ro last-changed yang:date-and-time
+--ro alarm-text alarm-text | +--ro perceived-severity severity
+--ro status-change* [time] {alarm-history}? | +--ro alarm-text alarm-text
| +--ro time yang:date-and-time | +--ro status-change* [time] {alarm-history}?
| +--ro perceived-severity severity-with-clear | | +--ro time yang:date-and-time
| +--ro alarm-text alarm-text | | +--ro perceived-severity severity-with-clear
+--ro operator-state-change* [time] {operator-actions}? | | +--ro alarm-text alarm-text
| +--ro time yang:date-and-time | +--ro operator-state-change* [time] {operator-actions}?
| +--ro operator string | | +--ro time yang:date-and-time
| +--ro state operator-state | | +--ro operator string
| +--ro text? string | | +--ro state operator-state
+---x set-operator-state {operator-actions}? | | +--ro text? string
| +---w input | +---x set-operator-state {operator-actions}?
| +---w state writable-operator-state | | +---w input
| +---w text? string | | +---w state writable-operator-state
+---n operator-action {operator-actions}? | | +---w text? string
+-- time yang:date-and-time | +---n operator-action {operator-actions}?
+-- operator string | +-- time yang:date-and-time
+-- state operator-state | +-- operator string
+-- text? string | +-- state operator-state
| +-- text? string
+---x purge-alarms
| +---w input
| | +---w alarm-status enumeration
| | +---w older-than!
| | | +---w (age-spec)?
| | | +--:(seconds)
| | | | +---w seconds? uint16
| | | +--:(minutes)
| | | | +---w minutes? uint16
| | | +--:(hours)
| | | | +---w hours? uint16
| | | +--:(days)
| | | | +---w days? uint16
| | | +--:(weeks)
| | | +---w weeks? uint16
| | +---w severity!
| | | +---w (sev-spec)?
| | | +--:(below)
| | | | +---w below? severity
| | | +--:(is)
| | | | +---w is? severity
| | | +--:(above)
| | | +---w above? severity
| | +---w operator-state-filter! {operator-actions}?
| | +---w state? operator-state
| | +---w user? string
| +--ro output
| +--ro purged-alarms? uint32
+---x compress-alarms {alarm-history}?
+---w input
| +---w resource? resource-match
| +---w alarm-type-id?
| | -> /alarms/alarm-list/alarm/alarm-type-id
| +---w alarm-type-qualifier? leafref
+--ro output
+--ro compressed-alarms? uint32
Every alarm has three important states, the resource clearance state Every alarm has three important states, the resource clearance state
"is-cleared", the severity "perceived-severity" and the operator "is-cleared", the severity "perceived-severity" and the operator
state available in the operator state change list. state available in the operator state change list.
In order to see the alarm history the resource state changes are In order to see the alarm history the resource state changes are
available in the "status-change" list and the operator history is available in the "status-change" list and the operator history is
available in the "operator-state-change" list. available in the "operator-state-change" list.
4.5. The Shelved Alarms List 4.5. The Shelved Alarms List
skipping to change at page 17, line 31 skipping to change at page 18, line 38
Alarm profiles (/alarms/alarm-profile/) is a list of configurable Alarm profiles (/alarms/alarm-profile/) is a list of configurable
alarm types. The list supports configurable alarm severity levels in alarm types. The list supports configurable alarm severity levels in
the container "alarm-severity-assignment-profile". If an alarm the container "alarm-severity-assignment-profile". If an alarm
matches the configured alarm type it MUST use the configured severity matches the configured alarm type it MUST use the configured severity
level(s) instead of the system default. This configuration MUST also level(s) instead of the system default. This configuration MUST also
be represented in the alarm inventory. be represented in the alarm inventory.
+--rw alarm-profile* +--rw alarm-profile*
[alarm-type-id alarm-type-qualifier-match resource] [alarm-type-id alarm-type-qualifier-match resource]
{alarm-profile}? {alarm-profile}?
+--rw alarm-type-id al:alarm-type-id +--rw alarm-type-id alarm-type-id
+--rw alarm-type-qualifier-match string +--rw alarm-type-qualifier-match string
+--rw resource al:resource-match +--rw resource resource-match
+--rw description string +--rw description string
+--rw alarm-severity-assignment-profile +--rw alarm-severity-assignment-profile
{severity-assignment}? {severity-assignment}?
+--rw severity-levels* al:severity +--rw severity-levels* severity
4.7. RPCs and Actions 4.7. Operations
The alarm module supports rpcs and actions to manage the alarms: The alarm module supports the following actions to manage the alarms:
"purge-alarms" (rpc): delete alarms according to specific /alarms/alarm-list/purge-alarms: Delete alarms from the "alarm-list"
criteria, for example all cleared alarms older then a specific according to specific criteria, for example all cleared alarms
date. older than a specific date.
"compress-alarms" (rpc): compress the status-change list for the /alarms/alarm-list/compress-alarms: Compress the "status-change"
alarms. list for the alarms.
"set-operator-state" (action): change the operator state for an /alarms/alarm-list/alarm/set-operator-state: Change the operator
alarm: for example acknowledge. state for an alarm. For example, an alarn can be acknowledged by
setting the operator state to "ack".
/alarms/shelved-alarm-list/purge-shelved-alarms: Delete alarms from
the "shelved-alarm-list" according to specific criteria, for
example all alarms older than a specific date.
/alarms/shelved-alarm-list/compress-shelved-alarms: Compress the
"status-change" list for the alarms.
4.8. Notifications 4.8. Notifications
The alarm module supports a general notification to report alarm The alarm module supports a general notification to report alarm
state changes. It carries all relevant parameters for the alarm state changes. It carries all relevant parameters for the alarm
management application. management application.
There is also a notification to report that an operator changed the There is also a notification to report that an operator changed the
operator state on an alarm, like acknowledge. operator state on an alarm, like acknowledge.
If the alarm inventory is changed, for example a new card type is If the alarm inventory is changed, for example a new card type is
inserted, a notification will tell the management application that inserted, a notification will tell the management application that
new alarm types are available. new alarm types are available.
5. Alarm YANG Module 5. Relationship to the ietf-hardware YANG module
RFC 8348 [RFC8348] defines the "ietf-hardware" YANG data model for
the management of hardware. The "alarm-state" in RFC 8348 is a
summary of the alarm severity levels that may be active on the
specific hardware component. It does not say anything about how
alarms are reported, and it doesn't provide any details of the
alarms.
The mapping between the alarm YANG data model and the "alarm-state"
in RFC 8348 is as follows:
resource: Corresponds to an entry in the list "/hardware/component/"
is-cleared: No bit set in "/hardware/component/state/alarm-state"
perceived-severity: Corresponding bit set in
"/hardware/component/state/alarm-state".
operator-state-change/state: If the alarm is acknowledged by the
operator, the bit "under-repair" is in "/hardware/component/state/
alarm-state".
6. Alarm YANG Module
This YANG module references [RFC6991]. This YANG module references [RFC6991].
<CODE BEGINS> file "ietf-alarms@2018-11-06.yang" <CODE BEGINS> file "ietf-alarms@2018-11-22.yang"
module ietf-alarms { module ietf-alarms {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-alarms"; namespace "urn:ietf:params:xml:ns:yang:ietf-alarms";
prefix al; prefix al;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference "RFC 6991: Common YANG Data Types."; reference "RFC 6991: Common YANG Data Types.";
} }
skipping to change at page 18, line 44 skipping to change at page 20, line 42
"IETF CCAMP Working Group"; "IETF CCAMP Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/ccamp> "WG Web: <http://tools.ietf.org/wg/ccamp>
WG List: <mailto:ccamp@ietf.org> WG List: <mailto:ccamp@ietf.org>
Editor: Stefan Vallin Editor: Stefan Vallin
<mailto:stefan@wallan.se> <mailto:stefan@wallan.se>
Editor: Martin Bjorklund Editor: Martin Bjorklund
<mailto:mbj@tail-f.com>"; <mailto:mbj@tail-f.com>";
// RFC Ed.: replace XXXX with actual RFC number and
// remove this note.
description description
"This module defines an interface for managing alarms. Main "This module defines an interface for managing alarms. Main
inputs to the module design are the 3GPP Alarm IRP, ITU-T X.733 inputs to the module design are the 3GPP Alarm IRP, ITU-T X.733
and ANSI/ISA-18.2 alarm standards. and ANSI/ISA-18.2 alarm standards.
Main features of this module include: Main features of this module include:
* Alarm list: * Alarm list:
A list of all alarms. Cleared alarms stay in A list of all alarms. Cleared alarms stay in
the list until explicitly purged. the list until explicitly purged.
skipping to change at page 20, line 27 skipping to change at page 22, line 25
(('link-alarm', 'GigabitEthernet0/25'), (('link-alarm', 'GigabitEthernet0/25'),
warning, warning,
'interface down while interface admin state is up', 'interface down while interface admin state is up',
cleared, cleared,
closed) closed)
Administrative actions like removing closed alarms older than a Administrative actions like removing closed alarms older than a
given time is supported. given time is supported.
This alarm module does not define how the underlying This alarm module does not define how the underlying
instrumentation detects and clears the specific alarms. instrumentation detects and clears the specific alarms. That
That belongs to the SDO or enterprise that owns that belongs to the SDO or enterprise that owns that specific
specific technology. technology.
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'OPTIONAL' in the module text are to be interpreted as described 'MAY', and 'OPTIONAL' in the module text are to be interpreted
in RFC 2119 (https://tools.ietf.org/html/rfc2119). as described in BCP 14 [RFC 2119] [RFC8174] when, and only when,
they appear in all capitals, as shown here.
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
full legal notices."; full legal notices.";
revision 2018-11-06 { // RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
revision 2018-11-22 {
description description
"Initial revision."; "Initial revision.";
reference "RFC XXXX: YANG Alarm Module"; reference "RFC XXXX: YANG Alarm Module";
} }
/* /*
* Features * Features
*/ */
feature operator-actions { feature operator-actions {
description description
"This feature indicates that the system supports operator "This feature indicates that the system supports operator
skipping to change at page 23, line 7 skipping to change at page 25, line 9
If the alarming resource is modelled in YANG, this type will If the alarming resource is modelled in YANG, this type will
be an instance-identifier. be an instance-identifier.
If the resource is an SNMP object, the type will be an If the resource is an SNMP object, the type will be an
object-identifier. object-identifier.
If the resource is anything else, for example a distinguished If the resource is anything else, for example a distinguished
name or a CIM path, this type will be a string. name or a CIM path, this type will be a string.
If the alarming object is identified by a UUID use the uuid If the alarming object is identified by a UUID use the uuid
type. Be cautious when using this type, since a UUID is hard type. Be cautious when using this type, since a UUID is hard
to use for an operator. to use for an operator.
If the server supports several models, the presedence should If the server supports several models, the presedence should
be in the order as given in the union definition."; be in the order as given in the union definition.";
} }
typedef resource-match { typedef resource-match {
type union { type union {
type yang:xpath1.0; type yang:xpath1.0;
type yang:object-identifier; type yang:object-identifier;
type string; type string;
} }
description description
"This type is used to match resources of type 'resource'. "This type is used to match resources of type 'resource'.
Since the type 'resource' is a union of different types, Since the type 'resource' is a union of different types, the
the 'resource-match' type is also a union of corresponding 'resource-match' type is also a union of corresponding types.
types.
If the type is given as an XPath 1.0 expression, a resource If the type is given as an XPath 1.0 expression, a resource of
of type 'instance-identifier' matches if the instance is part type 'instance-identifier' matches if the instance is part of
of the node set that is the result of evaluating the XPath 1.0 the node set that is the result of evaluating the XPath 1.0
expression. For example, the XPath 1.0 expression: expression. For example, the XPath 1.0 expression:
/if:interfaces/if:interface[if:type='ianaift:ethernetCsmacd'] /ietf-interfaces:interfaces/ietf-interfaces:interface
[ietf-interfaces:type='ianaift:ethernetCsmacd']
would match the resource instance-identifier: would match the resource instance-identifier:
/if:interfaces/if:interface[if:name='eth1'], /if:interfaces/if:interface[if:name='eth1'],
assuming that the interface 'eth1' is of type assuming that the interface 'eth1' is of type
'ianaift:ethernetCsmacd'. 'ianaift:ethernetCsmacd'.
If the type is given as an object identifier, a resource of If the type is given as an object identifier, a resource of
type 'object-identifier' matches if the match object type 'object-identifier' matches if the match object
skipping to change at page 24, line 11 skipping to change at page 26, line 13
1.3.6.1.2.1.2.2.1.1.5 1.3.6.1.2.1.2.2.1.1.5
If the type is given as an UUID or a string, it is interpreted If the type is given as an UUID or a string, it is interpreted
as a W3C regular expression, which matches a resource of type as a W3C regular expression, which matches a resource of type
'yang:uuid' or 'string' if the given regular expression 'yang:uuid' or 'string' if the given regular expression
matches the resource string. matches the resource string.
If the type is given as an XPath expression it is evaluated If the type is given as an XPath expression it is evaluated
in the following XPath context: in the following XPath context:
o The set of namespace declarations are those in scope on o The set of namespace declarations is the set of prefix
the leaf element where this type is used. and namespace pairs for all YANG modules implemented by
the server, where the prefix is the YANG module name and
the namespace is as defined by the 'namespace' statement
in the YANG module.
If a leaf of this type is encoded in XML, all namespace
declarations in scope on the leaf element are added to
the set of namespace declarations. If a prefix found in
the XML is already present in the set of namespace
declarations, the namespace in the XML is used.
o The set of variable bindings is empty. o The set of variable bindings is empty.
o The function library is the core function library o The function library is the core function library
and the functions defined in Section 10 of RFC 7950. and the functions defined in Section 10 of RFC 7950.
o The context node is the root node in the data tree."; o The context node is the root node in the data tree.";
} }
typedef alarm-text { typedef alarm-text {
type string; type string;
description description
"The string used to inform operators about the alarm. This "The string used to inform operators about the alarm. This
MUST contain enough information for an operator to be able MUST contain enough information for an operator to be able to
to understand the problem and how to resolve it. If this understand the problem and how to resolve it. If this string
string contains structure, this format should be clearly contains structure, this format should be clearly documented
documented for programs to be able to parse that for programs to be able to parse that information.";
information.";
} }
typedef severity { typedef severity {
type enumeration { type enumeration {
enum indeterminate { enum indeterminate {
value 2; value 2;
description description
"Indicates that the severity level could not be "Indicates that the severity level could not be
determined. This level SHOULD be avoided."; determined. This level SHOULD be avoided.";
} }
skipping to change at page 25, line 43 skipping to change at page 28, line 4
} }
description description
"The severity level of the alarm. Note well that value 'clear' "The severity level of the alarm. Note well that value 'clear'
is not included. If an alarm is cleared or not is a separate is not included. If an alarm is cleared or not is a separate
boolean flag."; boolean flag.";
reference reference
"ITU Recommendation X.733: Information Technology "ITU Recommendation X.733: Information Technology
- Open Systems Interconnection - Open Systems Interconnection
- System Management: Alarm Reporting Function"; - System Management: Alarm Reporting Function";
} }
typedef severity-with-clear { typedef severity-with-clear {
type union { type union {
type enumeration { type enumeration {
enum cleared { enum cleared {
value 1; value 1;
description description
"The alarm is cleared by the instrumentation."; "The alarm is cleared by the instrumentation.";
} }
} }
type severity; type severity;
} }
description description
"The severity level of the alarm including clear. "The severity level of the alarm including clear. This is used
This is used *only* in notifications reporting state changes only in notifications reporting state changes for an alarm.";
for an alarm.";
} }
typedef writable-operator-state { typedef writable-operator-state {
type enumeration { type enumeration {
enum none { enum none {
value 1; value 1;
description description
"The alarm is not being taken care of."; "The alarm is not being taken care of.";
} }
enum ack { enum ack {
value 2; value 2;
description description
"The alarm is being taken care of. Corrective action not "The alarm is being taken care of. Corrective action not
taken yet, or failed"; taken yet, or failed";
} }
enum closed { enum closed {
value 3; value 3;
description description
"Corrective action taken successfully."; "Corrective action taken successfully.";
} }
} }
description description
"Operator states on an alarm. The 'closed' state indicates "Operator states on an alarm. The 'closed' state indicates
that an operator considers the alarm being resolved. This that an operator considers the alarm being resolved. This is
is separate from the alarm's 'is-cleared' leaf."; separate from the alarm's 'is-cleared' leaf.";
} }
typedef operator-state { typedef operator-state {
type union { type union {
type writable-operator-state; type writable-operator-state;
type enumeration { type enumeration {
enum shelved { enum shelved {
value 4; value 4;
description description
"The alarm is shelved. Alarms in /alarms/shelved-alarms/ "The alarm is shelved. Alarms in /alarms/shelved-alarms/
MUST be assigned this operator state by the server as MUST be assigned this operator state by the server as
the last entry in the operator-state-change list. The the last entry in the operator-state-change list. The
text for that entry SHOULD include the shelf name."; text for that entry SHOULD include the shelf name.";
} }
enum un-shelved { enum un-shelved {
value 5; value 5;
description description
"The alarm is moved back to 'alarm-list' from a shelf. "The alarm is moved back to 'alarm-list' from a shelf.
Alarms that are moved from /alarms/shelved-alarms/ to Alarms that are moved from /alarms/shelved-alarms/ to
/alarms/alarm-list MUST be assigned this state by the /alarms/alarm-list MUST be assigned this state by the
server as the last entry in the 'operator-state-change' server as the last entry in the 'operator-state-change'
list. The text for that entry SHOULD include the shelf list. The text for that entry SHOULD include the shelf
name."; name.";
} }
} }
} }
description description
"Operator states on an alarm. The 'closed' state indicates "Operator states on an alarm. The 'closed' state indicates
that an operator considers the alarm being resolved. This that an operator considers the alarm being resolved. This is
is separate from the alarm's 'is-cleared' leaf."; separate from the alarm's 'is-cleared' leaf.";
} }
/* Alarm type */ /* Alarm type */
typedef alarm-type-id { typedef alarm-type-id {
type identityref { type identityref {
base alarm-type-id; base alarm-type-id;
} }
description description
"Identifies an alarm type. The description of the alarm type "Identifies an alarm type. The description of the alarm type
skipping to change at page 27, line 41 skipping to change at page 29, line 48
the alarm inventory."; the alarm inventory.";
} }
typedef alarm-type-qualifier { typedef alarm-type-qualifier {
type string; type string;
description description
"If an alarm type can not be fully specified at design time by "If an alarm type can not be fully specified at design time by
alarm-type-id, this string qualifier is used in addition to alarm-type-id, this string qualifier is used in addition to
fully define a unique alarm type. fully define a unique alarm type.
The definition of alarm qualifiers is considered being part The definition of alarm qualifiers is considered being part of
of the instrumentation and out of scope for this module. the instrumentation and out of scope for this module. An
An empty string is used when this is part of a key."; empty string is used when this is part of a key.";
} }
/* /*
* Groupings * Groupings
*/ */
grouping common-alarm-parameters { grouping common-alarm-parameters {
description description
"Common parameters for an alarm. "Common parameters for an alarm.
This grouping is used both in the alarm list and in the This grouping is used both in the alarm list and in the
notification representing an alarm state change."; notification representing an alarm state change.";
skipping to change at page 28, line 12 skipping to change at page 30, line 18
grouping common-alarm-parameters { grouping common-alarm-parameters {
description description
"Common parameters for an alarm. "Common parameters for an alarm.
This grouping is used both in the alarm list and in the This grouping is used both in the alarm list and in the
notification representing an alarm state change."; notification representing an alarm state change.";
leaf resource { leaf resource {
type resource; type resource;
mandatory true; mandatory true;
description description
"The alarming resource. See also 'alt-resource'. "The alarming resource. See also 'alt-resource'. This could
This could for example be a reference to the alarming for example be a reference to the alarming interface";
interface";
} }
leaf alarm-type-id { leaf alarm-type-id {
type alarm-type-id; type alarm-type-id;
mandatory true; mandatory true;
description description
"This leaf and the leaf 'alarm-type-qualifier' together "This leaf and the leaf 'alarm-type-qualifier' together
provides a unique identification of the alarm type."; provides a unique identification of the alarm type.";
} }
leaf alarm-type-qualifier { leaf alarm-type-qualifier {
type alarm-type-qualifier; type alarm-type-qualifier;
description description
"This leaf is used when the 'alarm-type-id' leaf cannot "This leaf is used when the 'alarm-type-id' leaf cannot
uniquely identify the alarm type. Normally, this is not uniquely identify the alarm type. Normally, this is not the
the case, and this leaf is the empty string."; case, and this leaf is the empty string.";
} }
leaf-list alt-resource { leaf-list alt-resource {
type resource; type resource;
description description
"Used if the alarming resource is available over other "Used if the alarming resource is available over other
interfaces. This field can contain SNMP OID's, CIM paths or interfaces. This field can contain SNMP OID's, CIM paths or
3GPP Distinguished names for example."; 3GPP Distinguished names for example.";
} }
list related-alarm { list related-alarm {
key "resource alarm-type-id alarm-type-qualifier"; key "resource alarm-type-id alarm-type-qualifier";
skipping to change at page 29, line 45 skipping to change at page 31, line 50
leaf-list root-cause-resource { leaf-list root-cause-resource {
type resource; type resource;
description description
"Resources that are candidates for causing the alarm. If the "Resources that are candidates for causing the alarm. If the
system has a mechanism to understand the candidate root system has a mechanism to understand the candidate root
causes of an alarm, this leaf-list can be used to list the causes of an alarm, this leaf-list can be used to list the
root cause candidate resources. In this way the system can root cause candidate resources. In this way the system can
create one alarm instead of several. An example might be a create one alarm instead of several. An example might be a
logging system (alarm resource) that fails, the alarm can logging system (alarm resource) that fails, the alarm can
reference the file-system in the 'root-cause-resource' reference the file-system in the 'root-cause-resource'
leaf-list. Note that the intended use is not to also send an leaf-list. Note that the intended use is not to also send
an alarm with the root-cause-resource as alarming resource. an an alarm with the root-cause-resource as alarming
The root-cause-resource leaf list is a hint and should not resource. The root-cause-resource leaf list is a hint and
also generate an alarm for the same problem."; should not also generate an alarm for the same problem.";
} }
} }
grouping alarm-state-change-parameters { grouping alarm-state-change-parameters {
description description
"Parameters for an alarm state change. "Parameters for an alarm state change.
This grouping is used both in the alarm list's This grouping is used both in the alarm list's status-change
status-change list and in the notification representing an list and in the notification representing an alarm state
alarm state change."; change.";
leaf time { leaf time {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"The time the status of the alarm changed. The value "The time the status of the alarm changed. The value
represents the time the real alarm state change appeared represents the time the real alarm state change appeared in
in the resource and not when it was added to the the resource and not when it was added to the alarm
alarm list. The /alarm-list/alarm/last-changed MUST be list. The /alarm-list/alarm/last-changed MUST be set to the
set to the same value."; same value.";
} }
leaf perceived-severity { leaf perceived-severity {
type severity-with-clear; type severity-with-clear;
mandatory true; mandatory true;
description description
"The severity of the alarm as defined by X.733. Note "The severity of the alarm as defined by X.733. Note that
that this may not be the original severity since the alarm this may not be the original severity since the alarm may
may have changed severity."; have changed severity.";
reference reference
"ITU Recommendation X.733: Information Technology "ITU Recommendation X.733: Information Technology
- Open Systems Interconnection - Open Systems Interconnection
- System Management: Alarm Reporting Function"; - System Management: Alarm Reporting Function";
} }
leaf alarm-text { leaf alarm-text {
type alarm-text; type alarm-text;
mandatory true; mandatory true;
description description
"A user friendly text describing the alarm state change."; "A user friendly text describing the alarm state change.";
skipping to change at page 31, line 11 skipping to change at page 33, line 16
leaf time { leaf time {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"Timestamp for operator action on alarm."; "Timestamp for operator action on alarm.";
} }
leaf operator { leaf operator {
type string; type string;
mandatory true; mandatory true;
description description
"The name of the operator that has acted on this "The name of the operator that has acted on this alarm.";
alarm.";
} }
leaf state { leaf state {
type operator-state; type operator-state;
mandatory true; mandatory true;
description description
"The operator's view of the alarm state."; "The operator's view of the alarm state.";
} }
leaf text { leaf text {
type string; type string;
description description
"Additional optional textual information provided by "Additional optional textual information provided by the
the operator."; operator.";
} }
} }
grouping resource-alarm-parameters { grouping resource-alarm-parameters {
description description
"Alarm parameters that originates from the resource view."; "Alarm parameters that originates from the resource view.";
leaf is-cleared { leaf is-cleared {
type boolean; type boolean;
mandatory true; mandatory true;
description description
"Indicates the current clearance state of the alarm. An "Indicates the current clearance state of the alarm. An
alarm might toggle from active alarm to cleared alarm and alarm might toggle from active alarm to cleared alarm and
back to active again."; back to active again.";
} }
leaf last-raised {
type yang:date-and-time;
mandatory true;
description
"An alarm may change severity level and toggle between
active and cleared during its life-time. This leaf indicates
the last time it was last raised (is-cleared = false).";
}
leaf last-changed { leaf last-changed {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"A timestamp when the alarm status was last changed. Status "A timestamp when the alarm status was last changed. Status
changes are changes to 'is-cleared', 'perceived-severity', changes are changes to 'is-cleared', 'perceived-severity',
and 'alarm-text'."; and 'alarm-text'.";
} }
leaf perceived-severity { leaf perceived-severity {
type severity; type severity;
skipping to change at page 32, line 13 skipping to change at page 34, line 25
"The last severity of the alarm. "The last severity of the alarm.
If an alarm was raised with severity 'warning', but later If an alarm was raised with severity 'warning', but later
changed to 'major', this leaf will show 'major'."; changed to 'major', this leaf will show 'major'.";
} }
leaf alarm-text { leaf alarm-text {
type alarm-text; type alarm-text;
mandatory true; mandatory true;
description description
"The last reported alarm text. This text should contain "The last reported alarm text. This text should contain
information for an operator to be able to understand information for an operator to be able to understand the
the problem and how to resolve it."; problem and how to resolve it.";
} }
list status-change { list status-change {
if-feature "alarm-history"; if-feature "alarm-history";
key "time"; key "time";
min-elements 1; min-elements 1;
description description
"A list of status change events for this alarm. "A list of status change events for this alarm.
The entry with latest time-stamp in this list MUST The entry with latest time-stamp in this list MUST
correspond to the leafs 'is-cleared', 'perceived-severity' correspond to the leafs 'is-cleared', 'perceived-severity'
and 'alarm-text' for the alarm. The time-stamp for that and 'alarm-text' for the alarm. The time-stamp for that
entry MUST be equal to the 'last-changed' leaf. entry MUST be equal to the 'last-changed' leaf.
This list is ordered according to the timestamps of This list is ordered according to the timestamps of alarm
alarm state changes. The last item corresponds to the state changes. The last item corresponds to the latest
latest state change. state change.
The following state changes creates an entry in this The following state changes creates an entry in this
list: list:
- changed severity (warning, minor, major, critical) - changed severity (warning, minor, major, critical)
- clearance status, this also updates the 'is-cleared' - clearance status, this also updates the 'is-cleared'
leaf leaf
- alarm text update"; - alarm text update";
uses alarm-state-change-parameters; uses alarm-state-change-parameters;
} }
}
grouping filter-input {
description
"Grouping to specify a filter construct on alarm information.";
leaf alarm-status {
type enumeration {
enum any {
description
"Ignore alarm clearance status.";
}
enum cleared {
description
"Filter cleared alarms.";
}
enum not-cleared {
description
"Filter not cleared alarms.";
}
}
mandatory true;
description
"The clearance status of the alarm.";
}
container older-than {
presence "Age specification";
description
"Matches the 'last-status-change' leaf in the alarm.";
choice age-spec {
description
"Filter using date and time age.";
case seconds {
leaf seconds {
type uint16;
description
"Seconds part";
}
}
case minutes {
leaf minutes {
type uint16;
description
"Minute part";
}
}
case hours {
leaf hours {
type uint16;
description
"Hours part.";
}
}
case days {
leaf days {
type uint16;
description
"Day part";
}
}
case weeks {
leaf weeks {
type uint16;
description
"Week part";
}
}
}
}
container severity {
presence "Severity filter";
choice sev-spec {
description
"Filter based on severity level.";
leaf below {
type severity;
description
"Severity less than this leaf.";
}
leaf is {
type severity;
description
"Severity level equal this leaf.";
}
leaf above {
type severity;
description
"Severity level higher than this leaf.";
}
}
description
"Filter based on severity.";
}
container operator-state-filter {
if-feature "operator-actions";
presence "Operator state filter";
leaf state {
type operator-state;
description
"Filter on operator state.";
}
leaf user {
type string;
description
"Filter based on which operator.";
}
description
"Filter based on operator state.";
}
} }
/* /*
* The /alarms data tree * The /alarms data tree
*/ */
container alarms { container alarms {
description description
"The top container for this module."; "The top container for this module.";
container control { container control {
skipping to change at page 33, line 16 skipping to change at page 37, line 41
type enumeration { type enumeration {
enum infinite { enum infinite {
description description
"The status change entries are accumulated "The status change entries are accumulated
infinitely."; infinitely.";
} }
} }
} }
default "32"; default "32";
description description
"The status-change entries are kept in a circular list "The status-change entries are kept in a circular list per
per alarm. When this number is exceeded, the oldest alarm. When this number is exceeded, the oldest status
status change entry is automatically removed. If the change entry is automatically removed. If the value is
value is 'infinite', the status change entries are 'infinite', the status change entries are accumulated
accumulated infinitely."; infinitely.";
} }
choice notify-status-changes { choice notify-status-changes {
description description
"This leaf controls the notifications sent for alarm status "This leaf controls the notifications sent for alarm status
updates. There are three options: updates. There are three options:
1. notifications are sent for all updates, severity level
1. Notifications are sent for all updates, severity level
changes and alarm text changes changes and alarm text changes
2. notifications are only sent for alarm raise and clear
3. notifications are sent for status changes equal to or 2. Notifications are only sent for alarm raise and clear
above the specified severity level. Clear notifications
shall always be sent 3. Notifications are sent for status changes equal to or
Notifications shall also be sent for state changes that above the specified severity level. Clear
makes an alarm less severe than the specified level. notifications shall always be sent Notifications shall
In option 3, assuming the severity level is set to major, also be sent for state changes that makes an alarm less
and that the alarm has the following state changes severe than the specified level.
For example, in option 3, assuming the severity level is
set to major and that the alarm has the following state
changes:
[(Time, severity, clear)]: [(Time, severity, clear)]:
[(T1, major, -), (T2, minor, -), (T3, warning, -), [(T1, major, -), (T2, minor, -), (T3, warning, -),
(T4, minor, -), (T5, major, -), (T6, critical, -), (T4, minor, -), (T5, major, -), (T6, critical, -),
(T7, major. -), (T8, major, clear)] (T7, major. -), (T8, major, clear)]
In that case, notifications will be sent at
In that case, notifications will be sent at times
T1, T2, T5, T6, T7 and T8."; T1, T2, T5, T6, T7 and T8.";
leaf notify-all-state-changes { leaf notify-all-state-changes {
type empty; type empty;
description description
"Send notifications for all status changes."; "Send notifications for all status changes.";
} }
leaf notify-raise-and-clear { leaf notify-raise-and-clear {
type empty; type empty;
description description
"Send notifications only for raise, clear, and re-raise. "Send notifications only for raise, clear, and re-raise.
Notifications for severity level changes or alarm text Notifications for severity level changes or alarm text
changes are not sent."; changes are not sent.";
} }
leaf notify-severity-level { leaf notify-severity-level {
type severity; type severity;
description description
"Only send notifications for alarm state changes "Only send notifications for alarm state changes crossing
crossing the specified level. Always send clear the specified level. Always send clear notifications.";
notifications.";
} }
} }
container alarm-shelving { container alarm-shelving {
if-feature "alarm-shelving"; if-feature "alarm-shelving";
description description
"The alarm-shelving/shelf list is used to shelve "The alarm-shelving/shelf list is used to shelve
(block/filter) alarms. The server will move any alarms (block/filter) alarms. The server will move any alarms
corresponding to the shelving criteria from the corresponding to the shelving criteria from the
alarms/alarm-list/alarm list to the alarms/alarm-list/alarm list to the
alarms/shelved-alarms/shelved-alarm list. It will also alarms/shelved-alarms/shelved-alarm list. It will also
skipping to change at page 34, line 27 skipping to change at page 39, line 10
"The alarm-shelving/shelf list is used to shelve "The alarm-shelving/shelf list is used to shelve
(block/filter) alarms. The server will move any alarms (block/filter) alarms. The server will move any alarms
corresponding to the shelving criteria from the corresponding to the shelving criteria from the
alarms/alarm-list/alarm list to the alarms/alarm-list/alarm list to the
alarms/shelved-alarms/shelved-alarm list. It will also alarms/shelved-alarms/shelved-alarm list. It will also
stop sending notifications for the shelved alarms. The stop sending notifications for the shelved alarms. The
conditions in the shelf criteria are logically ANDed. conditions in the shelf criteria are logically ANDed.
When the shelving criteria is deleted or changed, the When the shelving criteria is deleted or changed, the
non-matching alarms MUST appear in the non-matching alarms MUST appear in the
alarms/alarm-list/alarm list according to the real state. alarms/alarm-list/alarm list according to the real state.
This means that the instrumentation MUST maintain states This means that the instrumentation MUST maintain states
for the shelved alarms. Alarms that match the criteria for the shelved alarms. Alarms that match the criteria
shall have an operator-state 'shelved'. When the shelf shall have an operator-state 'shelved'. When the shelf
configuration will remove an alarm from the shelf the configuration removes an alarm from the shelf the
server shall add an operator state 'unshelved'."; server shall add an operator state 'unshelved'.";
list shelf { list shelf {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for the alarm shelf."; "An arbitrary name for the alarm shelf.";
} }
description description
"Each entry defines the criteria for shelving alarms. "Each entry defines the criteria for shelving alarms.
skipping to change at page 35, line 9 skipping to change at page 39, line 41
} }
leaf alarm-type-id { leaf alarm-type-id {
type alarm-type-id; type alarm-type-id;
description description
"Shelve all alarms that have an alarm-type-id that is "Shelve all alarms that have an alarm-type-id that is
equal to or derived from the given alarm-type-id."; equal to or derived from the given alarm-type-id.";
} }
leaf alarm-type-qualifier-match { leaf alarm-type-qualifier-match {
type string; type string;
description description
"A W3C regular expression that is used to match "A W3C regular expression that is used to match an
an alarm type qualifier. Shelve all alarms that alarm type qualifier. Shelve all alarms that matches
matches this regular expression for the alarm this regular expression for the alarm type
type qualifier."; qualifier.";
} }
leaf description { leaf description {
type string; type string;
description description
"An optional textual description of the shelf. This "An optional textual description of the shelf. This
description should include the reason for shelving description should include the reason for shelving
these alarms."; these alarms.";
} }
} }
} }
} }
container alarm-inventory { container alarm-inventory {
config false; config false;
description description
"This alarm-inventory/alarm-type list contains all possible "This alarm-inventory/alarm-type list contains all possible
alarm types for the system. alarm types for the system.
If the system knows for which resources a specific alarm If the system knows for which resources a specific alarm
type can appear, this is also identified in the inventory. type can appear, this is also identified in the inventory.
The list also tells if each alarm type has a corresponding The list also tells if each alarm type has a corresponding
clear state. The inventory shall only contain concrete clear state. The inventory shall only contain concrete
alarm types. alarm types.
The alarm inventory MUST be updated by the system when new The alarm inventory MUST be updated by the system when new
alarms can appear. This can be the case when installing new alarms can appear. This can be the case when installing new
software modules or inserting new card types. A software modules or inserting new card types. A
notification 'alarm-inventory-changed' is sent when the notification 'alarm-inventory-changed' is sent when the
skipping to change at page 36, line 21 skipping to change at page 41, line 6
"Optionally, specifies for which resources the alarm type "Optionally, specifies for which resources the alarm type
is valid."; is valid.";
} }
leaf has-clear { leaf has-clear {
type boolean; type boolean;
mandatory true; mandatory true;
description description
"This leaf tells the operator if the alarm will be "This leaf tells the operator if the alarm will be
cleared when the correct corrective action has been cleared when the correct corrective action has been
taken. Implementations SHOULD strive for detecting the taken. Implementations SHOULD strive for detecting the
cleared state for all alarm types. If this leaf is cleared state for all alarm types.
true, the operator can monitor the alarm until it
becomes cleared after the corrective action has been If this leaf is 'true', the operator can monitor the
taken. If this leaf is false the operator needs to alarm until it becomes cleared after the corrective
validate that the alarm is not longer active using other action has been taken.
If this leaf is 'false', the operator needs to validate
that the alarm is not longer active using other
mechanisms. Alarms can lack a corresponding clear due mechanisms. Alarms can lack a corresponding clear due
to missing instrumentation or that there is no logical to missing instrumentation or that there is no logical
corresponding clear state."; corresponding clear state.";
} }
leaf-list severity-levels { leaf-list severity-levels {
type severity; type severity;
description description
"This leaf-list indicates the possible severity levels of "This leaf-list indicates the possible severity levels of
this alarm type. Note well that 'clear' is not part of this alarm type. Note well that 'clear' is not part of
the severity type. In general, the severity level should the severity type. In general, the severity level
be defined by the instrumentation based on dynamic state should be defined by the instrumentation based on
and not defined statically by the alarm type in order to dynamic state and not defined statically by the alarm
provide relevant severity level based on dynamic state type in order to provide relevant severity level based
and context. However most alarm types have a defined set on dynamic state and context. However most alarm types
of possible severity levels and this should be provided have a defined set of possible severity levels and this
here."; should be provided here.";
} }
leaf description { leaf description {
type string; type string;
mandatory true; mandatory true;
description description
"A description of the possible alarm. It SHOULD include "A description of the possible alarm. It SHOULD include
information on possible underlying root causes and information on possible underlying root causes and
corrective actions."; corrective actions.";
} }
} }
skipping to change at page 37, line 4 skipping to change at page 41, line 40
} }
leaf description { leaf description {
type string; type string;
mandatory true; mandatory true;
description description
"A description of the possible alarm. It SHOULD include "A description of the possible alarm. It SHOULD include
information on possible underlying root causes and information on possible underlying root causes and
corrective actions."; corrective actions.";
} }
} }
} }
container summary { container summary {
if-feature "alarm-summary"; if-feature "alarm-summary";
config false; config false;
description description
"This container gives a summary of number of alarms."; "This container gives a summary of number of alarms.";
list alarm-summary { list alarm-summary {
key "severity"; key "severity";
description description
"A global summary of all alarms in the system. The summary "A global summary of all alarms in the system. The summary
does not include shelved alarms."; does not include shelved alarms.";
leaf severity { leaf severity {
type severity; type severity;
description description
"Alarm summary for this severity level."; "Alarm summary for this severity level.";
} }
leaf total { leaf total {
type yang:gauge32; type yang:gauge32;
description description
"Total number of alarms of this severity level."; "Total number of alarms of this severity level.";
skipping to change at page 38, line 49 skipping to change at page 43, line 38
type yang:date-and-time; type yang:date-and-time;
description description
"A timestamp when the alarm list was last "A timestamp when the alarm list was last
changed. The value can be used by a manager to changed. The value can be used by a manager to
initiate an alarm resynchronization procedure."; initiate an alarm resynchronization procedure.";
} }
list alarm { list alarm {
key "resource alarm-type-id alarm-type-qualifier"; key "resource alarm-type-id alarm-type-qualifier";
description description
"The list of alarms. Each entry in the list holds one "The list of alarms. Each entry in the list holds one
alarm for a given alarm type and resource. alarm for a given alarm type and resource. An alarm can
An alarm can be updated from the underlying resource or be updated from the underlying resource or by the user.
by the user. The following leafs are maintained by the The following leafs are maintained by the resource:
resource: is-cleared, last-change, perceived-severity, is-cleared, last-change, perceived-severity, and
and alarm-text. An operator can change: operator-state alarm-text. An operator can change: operator-state and
and operator-text. operator-text.
Entries appear in the alarm list the first time an Entries appear in the alarm list the first time an alarm
alarm becomes active for a given alarm-type and resource. becomes active for a given alarm-type and resource.
Entries do not get deleted when the alarm is cleared, this Entries do not get deleted when the alarm is cleared, this
is a boolean state in the alarm. is a boolean state in the alarm.
Alarm entries are removed, purged, from the list by an Alarm entries are removed, purged, from the list by an
explicit purge action. For example, purge all alarms explicit purge action. For example, purge all alarms that
that are cleared and in closed operator-state that are are cleared and in closed operator-state that are older
older than 24 hours. Purged alarms are removed from the than 24 hours. Purged alarms are removed from the alarm
alarm list. If the alarm resource state changes list. If the alarm resource state changes after a purge,
after a purge, the alarm will reappear in the alarm list. the alarm will reappear in the alarm list.
Systems may also remove alarms based on locally configured Systems may also remove alarms based on locally configured
policies which is out of scope for this module."; policies which is out of scope for this module.";
uses common-alarm-parameters; uses common-alarm-parameters;
leaf time-created { leaf time-created {
type yang:date-and-time; type yang:date-and-time;
mandatory true; mandatory true;
description description
"The time-stamp when this alarm entry was created. This "The time-stamp when this alarm entry was created. This
represents the first time the alarm appeared, it can represents the first time the alarm appeared, it can
also represent that the alarm re-appeared after a purge. also represent that the alarm re-appeared after a purge.
Further state-changes of the same alarm does not change Further state-changes of the same alarm does not change
this leaf, these changes will update the 'last-changed' this leaf, these changes will update the 'last-changed'
leaf."; leaf.";
} }
uses resource-alarm-parameters; uses resource-alarm-parameters;
list operator-state-change { list operator-state-change {
if-feature "operator-actions"; if-feature "operator-actions";
key "time"; key "time";
description description
"This list is used by operators to indicate "This list is used by operators to indicate the state of
the state of human intervention on an alarm. human intervention on an alarm. For example, if an
For example, if an operator has seen an alarm, operator has seen an alarm, the operator can add a new
the operator can add a new item to this list indicating item to this list indicating that the alarm is
that the alarm is acknowledged."; acknowledged.";
uses operator-parameters; uses operator-parameters;
} }
action set-operator-state { action set-operator-state {
if-feature "operator-actions"; if-feature "operator-actions";
description description
"This is a means for the operator to indicate "This is a means for the operator to indicate the level
the level of human intervention on an alarm."; of human intervention on an alarm.";
input { input {
leaf state { leaf state {
type writable-operator-state; type writable-operator-state;
mandatory true; mandatory true;
description description
"Set this operator state."; "Set this operator state.";
} }
leaf text { leaf text {
type string; type string;
description description
skipping to change at page 40, line 16 skipping to change at page 45, line 4
mandatory true; mandatory true;
description description
"Set this operator state."; "Set this operator state.";
} }
leaf text { leaf text {
type string; type string;
description description
"Additional optional textual information."; "Additional optional textual information.";
} }
} }
} }
notification operator-action { notification operator-action {
if-feature "operator-actions"; if-feature "operator-actions";
description description
"This notification is used to report that an operator "This notification is used to report that an operator
acted upon an alarm."; acted upon an alarm.";
uses operator-parameters; uses operator-parameters;
} }
} }
action purge-alarms {
description
"This operation requests the server to delete entries from
the alarm list according to the supplied criteria.
Typically this operation is used to delete alarms that are
in closed operator state and older than a specified time.
The number of purged alarms is returned as an output
parameter.";
input {
uses filter-input;
}
output {
leaf purged-alarms {
type uint32;
description
"Number of purged alarms.";
}
}
}
action compress-alarms {
if-feature "alarm-history";
description
"This operation requests the server to compress entries in
the alarm list by removing all but the latest
'status-change' entry for all matching alarms. Conditions
in the input are logically ANDed. If no input condition
is given, all alarms are compressed.";
input {
leaf resource {
type resource-match;
description
"Compress the alarms matching this resource.";
}
leaf alarm-type-id {
type leafref {
path "/alarms/alarm-list/alarm/alarm-type-id";
require-instance false;
}
description
"Compress alarms with this alarm-type-id.";
}
leaf alarm-type-qualifier {
type leafref {
path "/alarms/alarm-list/alarm/alarm-type-qualifier";
require-instance false;
}
description
"Compress the alarms with this alarm-type-qualifier.";
}
}
output {
leaf compressed-alarms {
type uint32;
description
"Number of compressed alarm entries.";
}
}
}
} }
container shelved-alarms { container shelved-alarms {
if-feature "alarm-shelving"; if-feature "alarm-shelving";
config false; config false;
description description
"The shelved alarms. Alarms appear here if they match the "The shelved alarms. Alarms appear here if they match the
criteria in /alarms/control/alarm-shelving. This list does criteria in /alarms/control/alarm-shelving. This list does
not generate any notifications. The list represents alarms not generate any notifications. The list represents alarms
that are considered not relevant by the operator. Alarms in that are considered not relevant by the operator. Alarms in
this list have an operator-state of 'shelved'. This can not this list have an operator-state of 'shelved'. This can not
be changed."; be changed.";
leaf number-of-shelved-alarms { leaf number-of-shelved-alarms {
type yang:gauge32; type yang:gauge32;
description description
"This object shows the total number of currently "This object shows the total number of currently
alarms, i.e., the total number of entries alarms, i.e., the total number of entries
in the alarm list."; in the alarm list.";
} }
leaf shelved-alarms-last-changed { leaf shelved-alarms-last-changed {
type yang:date-and-time; type yang:date-and-time;
description description
"A timestamp when the shelved alarm list was last "A timestamp when the shelved alarm list was last changed.
changed. The value can be used by a manager to The value can be used by a manager to initiate an alarm
initiate an alarm resynchronization procedure."; resynchronization procedure.";
} }
list shelved-alarm { list shelved-alarm {
key "resource alarm-type-id alarm-type-qualifier"; key "resource alarm-type-id alarm-type-qualifier";
description description
"The list of shelved alarms. Shelved alarms "The list of shelved alarms. Shelved alarms can only be
can only be updated from the underlying resource, updated from the underlying resource, no operator actions
no operator actions are supported."; are supported.";
uses common-alarm-parameters; uses common-alarm-parameters;
leaf shelf-name { leaf shelf-name {
type leafref { type leafref {
path "/alarms/control/alarm-shelving/shelf/name"; path "/alarms/control/alarm-shelving/shelf/name";
require-instance false; require-instance false;
} }
description description
"The name of the shelf."; "The name of the shelf.";
} }
uses resource-alarm-parameters; uses resource-alarm-parameters;
list operator-state-change { list operator-state-change {
if-feature "operator-actions"; if-feature "operator-actions";
key "time"; key "time";
description description
"This list is used by operators to indicate "This list is used by operators to indicate the state of
the state of human intervention on an alarm. human intervention on an alarm. For shelved alarms, the
For shelved alarms, the system has set the list system has set the list item in the list to 'shelved'.";
item in the list to 'shelved'.";
uses operator-parameters; uses operator-parameters;
} }
} }
action purge-shelved-alarms {
description
"This operation requests the server to delete entries from
the shelved alarms list according to the supplied
criteria.
In the shelved alarm list it makes sense to delete alarms
that are not relevant anymore.
The number of purged alarms is returned as an output
parameter.";
input {
uses filter-input;
}
output {
leaf purged-alarms {
type uint32;
description
"Number of purged alarms.";
}
}
}
action compress-shelved-alarms {
if-feature "alarm-history";
description
"This operation requests the server to compress entries in
the shelved alarm list by removing all but the latest
'status-change' entry for all matching shelved alarms.
Conditions in the input are logically ANDed. If no input
condition is given, all alarms are compressed.";
input {
leaf resource {
type leafref {
path "/alarms/shelved-alarms/shelved-alarm/resource";
require-instance false;
}
description
"Compress the alarms with this resource.";
}
leaf alarm-type-id {
type leafref {
path "/alarms/shelved-alarms/shelved-alarm"
+ "/alarm-type-id";
require-instance false;
}
description
"Compress alarms with this alarm-type-id.";
}
leaf alarm-type-qualifier {
type leafref {
path "/alarms/shelved-alarms/shelved-alarm"
+ "/alarm-type-qualifier";
require-instance false;
}
description
"Compress the alarms with this alarm-type-qualifier.";
}
}
output {
leaf compressed-alarms {
type uint32;
description
"Number of compressed alarm entries.";
}
}
}
} }
list alarm-profile { list alarm-profile {
if-feature "alarm-profile"; if-feature "alarm-profile";
key "alarm-type-id alarm-type-qualifier-match resource"; key "alarm-type-id alarm-type-qualifier-match resource";
ordered-by user; ordered-by user;
description description
"This list is used to assign further information or "This list is used to assign further information or
configuration for each alarm type. This module supports configuration for each alarm type. This module supports a
a mechanism where the client can override the system mechanism where the client can override the system default
default alarm severity levels. The alarm-profile is alarm severity levels. The alarm-profile is also a useful
also a useful augmentation point for specific additions augmentation point for specific additions to alarm types.";
to alarm types.";
leaf alarm-type-id { leaf alarm-type-id {
type al:alarm-type-id; type alarm-type-id;
description description
"The alarm type identifier to match."; "The alarm type identifier to match.";
} }
leaf alarm-type-qualifier-match { leaf alarm-type-qualifier-match {
type string; type string;
description description
"A W3C regular expression that is used to "A W3C regular expression that is used to match the alarm
match."; type qualifier.";
} }
leaf resource { leaf resource {
type al:resource-match; type resource-match;
description description
"Specifies which resources to match."; "Specifies which resources to match.";
} }
leaf description { leaf description {
type string; type string;
mandatory true; mandatory true;
description description
"A description of the alarm profile."; "A description of the alarm profile.";
} }
container alarm-severity-assignment-profile { container alarm-severity-assignment-profile {
if-feature "severity-assignment"; if-feature "severity-assignment";
description description
"The client can override the system default "The client can override the system default severity
severity level."; level.";
reference reference
"ITU M.3100, ITU M.3160 "ITU M.3100, ITU M.3160
- Generic Network Information Model, - Generic Network Information Model, Alarm Severity
Alarm Severity Assignment Profile"; Assignment Profile";
leaf-list severity-levels { leaf-list severity-levels {
type al:severity; type severity;
ordered-by user; ordered-by user;
description description
"Specifies the configured severity level(s) for the "Specifies the configured severity level(s) for the
matching alarm. If the alarm has several severity matching alarm. If the alarm has several severity
levels the leaf-list shall be given in rising severity levels the leaf-list shall be given in rising severity
order. The original M3100/M3160 ASAP function only order. The original M3100/M3160 ASAP function only
allows for a one-to-one mapping between alarm type and allows for a one-to-one mapping between alarm type and
severity but since the IETF alarm module supports severity but since the IETF alarm module supports
stateful alarms the mapping must allow for several stateful alarms the mapping must allow for several
severity levels. severity levels.
Assume a high-utilisation alarm type with two Assume a high-utilisation alarm type with two thresholds
thresholds with the system default severity levels of with the system default severity levels of threshold1 =
threshold1 = warning and threshold2 = minor. Setting warning and threshold2 = minor. Setting this leaf-list
this leaf-list to (minor, major) will assign the to (minor, major) will assign the severity levels
severity levels threshold1 = minor and threshold1 = minor and threshold2 = major";
threshold2 = major";
}
}
}
}
/*
* Operations
*/
rpc compress-alarms {
if-feature "alarm-history";
description
"This operation requests the server to compress entries in the
alarm list by removing all but the latest state change for all
alarms. Conditions in the input are logically ANDed. If no
input condition is given, all alarms are compressed.";
input {
leaf resource {
type resource-match;
description
"Compress the alarms matching this resource.";
}
leaf alarm-type-id {
type leafref {
path "/alarms/alarm-list/alarm/alarm-type-id";
require-instance false;
}
description
"Compress alarms with this alarm-type-id.";
}
leaf alarm-type-qualifier {
type leafref {
path "/alarms/alarm-list/alarm/alarm-type-qualifier";
require-instance false;
}
description
"Compress the alarms with this alarm-type-qualifier.";
}
}
output {
leaf compressed-alarms {
type uint32;
description
"Number of compressed alarm entries.";
}
}
}
rpc compress-shelved-alarms {
if-feature "alarm-history and alarm-shelving";
description
"This operation requests the server to compress entries in the
shelved alarm list by removing all but the latest state change
for all alarms. Conditions in the input are logically ANDed.
If no input condition is given, all alarms are compressed.";
input {
leaf resource {
type leafref {
path "/alarms/shelved-alarms/shelved-alarm/resource";
require-instance false;
}
description
"Compress the alarms with this resource.";
}
leaf alarm-type-id {
type leafref {
path "/alarms/shelved-alarms/shelved-alarm/alarm-type-id";
require-instance false;
}
description
"Compress alarms with this alarm-type-id.";
}
leaf alarm-type-qualifier {
type leafref {
path "/alarms/shelved-alarms/shelved-alarm"
+ "/alarm-type-qualifier";
require-instance false;
}
description
"Compress the alarms with this alarm-type-qualifier.";
}
}
output {
leaf compressed-alarms {
type uint32;
description
"Number of compressed alarm entries.";
}
}
}
grouping filter-input {
description
"Grouping to specify a filter construct on alarm information.";
leaf alarm-status {
type enumeration {
enum any {
description
"Ignore alarm clearance status.";
}
enum cleared {
description
"Filter cleared alarms.";
}
enum not-cleared {
description
"Filter not cleared alarms.";
}
}
mandatory true;
description
"The clearance status of the alarm.";
}
container older-than {
presence "Age specification";
description
"Matches the 'last-status-change' leaf in the alarm.";
choice age-spec {
description
"Filter using date and time age.";
case seconds {
leaf seconds {
type uint16;
description
"Seconds part";
}
}
case minutes {
leaf minutes {
type uint16;
description
"Minute part";
}
}
case hours {
leaf hours {
type uint16;
description
"Hours part.";
}
}
case days {
leaf days {
type uint16;
description
"Day part";
}
}
case weeks {
leaf weeks {
type uint16;
description
"Week part";
}
}
}
}
container severity {
presence "Severity filter";
choice sev-spec {
description
"Filter based on severity level.";
leaf below {
type severity;
description
"Severity less than this leaf.";
}
leaf is {
type severity;
description
"Severity level equal this leaf.";
}
leaf above {
type severity;
description
"Severity level higher than this leaf.";
} }
} }
description
"Filter based on severity.";
}
container operator-state-filter {
if-feature "operator-actions";
presence "Operator state filter";
leaf state {
type operator-state;
description
"Filter on operator state.";
}
leaf user {
type string;
description
"Filter based on which operator.";
}
description
"Filter based on operator state.";
}
}
rpc purge-alarms {
description
"This operation requests the server to delete entries from the
alarm list or the shelved alarms list according to the
supplied criteria. To purge alarms in the shelved alarms,
set the operator-state filter input to 'shelved'.
Typically it can be used to delete alarms that are
in closed operator state and older than a specified time.
In the shelved alarm list it makes sense to delete alarms that
are not relevant anymore.
The number of purged alarms is returned as an output
parameter.";
input {
uses filter-input;
}
output {
leaf purged-alarms {
type uint32;
description
"Number of purged alarms.";
}
} }
} }
/* /*
* Notifications * Notifications
*/ */
notification alarm-notification { notification alarm-notification {
description description
"This notification is used to report a state change for an "This notification is used to report a state change for an
skipping to change at page 48, line 5 skipping to change at page 50, line 40
description description
"This notification is used to report that the list of possible "This notification is used to report that the list of possible
alarms has changed. This can happen when for example if a new alarms has changed. This can happen when for example if a new
software module is installed, or a new physical card is software module is installed, or a new physical card is
inserted."; inserted.";
} }
} }
<CODE ENDS> <CODE ENDS>
6. X.733 Extensions 7. X.733 Extensions
Many alarm systems are based on the X.733, [X.733], and X.736 [X.736] Many alarm systems are based on the X.733, [X.733], and X.736 [X.736]
alarm standards. This module augments the alarm inventory, the alarm alarm standards. This module augments the alarm inventory, the alarm
lists and the alarm notification with X.733 and X.736 parameters. lists and the alarm notification with X.733 and X.736 parameters.
The module also supports a feature whereby the alarm manager can The module also supports a feature whereby the alarm manager can
configure the mapping from alarm types to X.733 event-type and configure the mapping from alarm types to X.733 event-type and
probable-cause parameters. This might be needed when the default probable-cause parameters. This might be needed when the default
mapping provided by the system is in conflict with other management mapping provided by the system is in conflict with other management
systems or not considered correct. systems or not considered correct.
Note that the IETF Alarm Module term 'resource' is synonymous to the Note that the IETF Alarm Module term 'resource' is synonymous to the
ITU term 'managed object'. ITU term 'managed object'.
7. The X.733 Mapping Module 8. The X.733 Mapping Module
This YANG module references [X.733] and [X.736]. This YANG module references [X.721], [X.733] and [X.736].
<CODE BEGINS> file "ietf-alarms-x733@2018-11-06.yang" <CODE BEGINS> file "ietf-alarms-x733@2018-11-22.yang"
module ietf-alarms-x733 { module ietf-alarms-x733 {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-alarms-x733"; namespace "urn:ietf:params:xml:ns:yang:ietf-alarms-x733";
prefix x733; prefix x733;
import ietf-alarms { import ietf-alarms {
prefix al; prefix al;
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
skipping to change at page 49, line 26 skipping to change at page 52, line 13
to the ITU tuple (event-type, probable-cause). to the ITU tuple (event-type, probable-cause).
The mapping does not include a corresponding X.733 specific The mapping does not include a corresponding X.733 specific
problem value. The recommendation is to use the problem value. The recommendation is to use the
'alarm-type-qualifier' leaf which serves the same purpose. 'alarm-type-qualifier' leaf which serves the same purpose.
The module uses an integer and a corresponding string for The module uses an integer and a corresponding string for
probable cause instead of a globally defined enumeration, in probable cause instead of a globally defined enumeration, in
order to be able to manage conflicting enumeration definitions. order to be able to manage conflicting enumeration definitions.
A single globally defined enumeration is challenging to A single globally defined enumeration is challenging to
maintain."; maintain.
Copyright (c) 2018 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in the module text are to be interpreted
as described in BCP 14 [RFC 2119] [RFC8174] when, and only when,
they appear in all capitals, as shown here.
This version of this YANG module is part of RFC XXXX
(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
full legal notices.";
reference reference
"ITU Recommendation X.733: Information Technology "ITU Recommendation X.733: Information Technology
- Open Systems Interconnection - Open Systems Interconnection
- System Management: Alarm Reporting Function"; - System Management: Alarm Reporting Function";
revision 2018-11-06 { revision 2018-11-22 {
description description
"Initial revision."; "Initial revision.";
reference "RFC XXXX: YANG Alarm Module"; reference "RFC XXXX: YANG Alarm Module";
} }
/* /*
* Features * Features
*/ */
feature configure-x733-mapping { feature configure-x733-mapping {
skipping to change at page 52, line 14 skipping to change at page 55, line 22
enum more-severe { enum more-severe {
description description
"The Perceived severity in the current alarm is "The Perceived severity in the current alarm is
higher (more severe) than that reported in any higher (more severe) than that reported in any
of the outstanding alarms."; of the outstanding alarms.";
} }
} }
description description
"This type is used to describe the "This type is used to describe the
severity trend of the alarming resource"; severity trend of the alarming resource";
reference "Module Attribute-ASN1Module (X.721:02/1992)"; reference
"ITU Recommendation X.721: Information Technology
- Open Systems Interconnection
- Structure of management information:
Definition of management information
Module Attribute-ASN1Module";
} }
typedef value-type { typedef value-type {
type union { type union {
type int64; type int64;
type uint64; type uint64;
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
} }
} }
skipping to change at page 57, line 48 skipping to change at page 61, line 13
type al:resource; type al:resource;
description description
"The resource representing the attribute."; "The resource representing the attribute.";
} }
leaf value { leaf value {
type string; type string;
description description
"The value represented as a string since it could "The value represented as a string since it could
be of any type."; be of any type.";
} }
reference "Module Attribute-ASN1Module (X.721:02/1992)"; reference
"ITU Recommendation X.721: Information Technology
- Open Systems Interconnection
- Structure of management information:
Definition of management information
Module Attribute-ASN1Module";
} }
/* /*
* Add X.733 parameters to the alarm definitions, alarms, * Add X.733 parameters to the alarm definitions, alarms,
* and notification. * and notification.
*/ */
augment "/al:alarms/al:alarm-inventory/al:alarm-type" { augment "/al:alarms/al:alarm-inventory/al:alarm-type" {
description description
"Augment X.733 mapping information to the alarm inventory."; "Augment X.733 mapping information to the alarm inventory.";
skipping to change at page 59, line 16 skipping to change at page 62, line 34
} }
augment "/al:alarm-notification" { augment "/al:alarm-notification" {
description description
"Augment X.733 information to the alarm notification."; "Augment X.733 information to the alarm notification.";
uses x733-alarm-parameters; uses x733-alarm-parameters;
} }
} }
<CODE ENDS> <CODE ENDS>
8. IANA Considerations 9. IANA Considerations
This document registers a URI in the IETF XML registry [RFC3688]. This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in RFC 3688, the following registration is Following the format in RFC 3688, the following registrations are
requested to be made. requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-alarms URI: urn:ietf:params:xml:ns:yang:ietf-alarms
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-alarms-x733
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the YANG Module Names This document registers two YANG modules in the YANG Module Names
registry [RFC6020]. registry [RFC6020].
name: ietf-alarms name: ietf-alarms
namespace: urn:ietf:params:xml:ns:yang:ietf-alarms namespace: urn:ietf:params:xml:ns:yang:ietf-alarms
prefix: al prefix: al
reference: RFC XXXX reference: RFC XXXX
9. Security Considerations name: ietf-alarms-x7333
namespace: urn:ietf:params:xml:ns:yang:ietf-alarms-x733
prefix: x733
reference: RFC XXXX
10. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246]. [RFC5246].
The NETCONF access control model [RFC6536] provides the means to The NETCONF access control model [RFC6536] provides the means to
skipping to change at page 60, line 21 skipping to change at page 63, line 49
alarm should notify only raise and clear or all severity level alarm should notify only raise and clear or all severity level
changes. Unauthorized access to leaf could have a negative impact changes. Unauthorized access to leaf could have a negative impact
on operational procedures relying on fine-grained alarm state on operational procedures relying on fine-grained alarm state
change reporting. change reporting.
/alarms/control/alarm-shelving/shelf: This list controls the /alarms/control/alarm-shelving/shelf: This list controls the
shelving (blocking) of alarms. Unauthorized access to this list shelving (blocking) of alarms. Unauthorized access to this list
could jeopardize the alarm management procedures since these could jeopardize the alarm management procedures since these
alarms will not be notified and not be part of the alarm list. alarms will not be notified and not be part of the alarm list.
Some of the RPC operations in this YANG module may be considered Some of the operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the important to control access to these operations. These are the
operations and their sensitivity/vulnerability: operations and their sensitivity/vulnerability:
purge-alarms: This RPC deletes alarms from the alarm list. /alarms/alarm-list/purge-alarms: This action deletes alarms from the
Unauthorized use of this RPC could jeopardize the alarm management alarm list. Unauthorized use of this action could jeopardize the
procedures since the deleted alarms may be vital for the alarm alarm management procedures since the deleted alarms may be vital
management application. for the alarm management application.
10. Acknowledgements 11. Acknowledgements
The authors wish to thank Viktor Leijon and Johan Nordlander for The authors wish to thank Viktor Leijon and Johan Nordlander for
their valuable input on forming the alarm model. their valuable input on forming the alarm model.
The authors also wish to thank Nick Hancock, Joey Boyd, Tom Petch and The authors also wish to thank Nick Hancock, Joey Boyd, Tom Petch and
Balazs Lengyel for their extensive reviews and contributions to this Balazs Lengyel for their extensive reviews and contributions to this
document. document.
11. References 12. References
11.1. Normative References 12.1. Normative References
[M.3100] International Telecommunications Union, "Generic Network [M.3100] International Telecommunications Union, "Generic Network
Information Model", ITU-T Recommendation M.3100, 2005. Information Model", ITU-T Recommendation M.3100, 2005.
[M.3160] International Telecommunications Union, "Generic, [M.3160] International Telecommunications Union, "Generic,
protocol-neutral management information model", protocol-neutral management information model", ITU-T
ITU-T Recommendation M.3100, 2008. Recommendation M.3100, 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- RFC2119, March 1997,
editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004,
editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
DOI 10.17487/RFC5246, August 2008, <https://www.rfc- RFC5246, August 2008, <https://www.rfc-editor.org/info/
editor.org/info/rfc5246>. rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, <https://www.rfc- DOI 10.17487/RFC6020, October 2010,
editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, Protocol (NETCONF) Access Control Model", RFC 6536, DOI
DOI 10.17487/RFC6536, March 2012, <https://www.rfc- 10.17487/RFC6536, March 2012, <https://www.rfc-
editor.org/info/rfc6536>. editor.org/info/rfc6536>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC
RFC 6991, DOI 10.17487/RFC6991, July 2013, 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <http://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <http://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <http://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
YANG Data Model for Hardware Management", RFC 8348, DOI
10.17487/RFC8348, March 2018, <https://www.rfc-
editor.org/info/rfc8348>.
[X.721] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - Structure of
management information: Definition of management
information", ITU-T Recommendation X.721, 1992.
[X.733] International Telecommunications Union, "Information [X.733] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - Systems Technology - Open Systems Interconnection - Systems
Management: Alarm Reporting Function", Management: Alarm Reporting Function", ITU-T
ITU-T Recommendation X.733, 1992. Recommendation X.733, 1992.
11.2. Informative References 12.2. Informative References
[ALARMIRP] [ALARMIRP]
3GPP, "Telecommunication management; Fault Management; 3GPP, "Telecommunication management; Fault Management;
Part 2: Alarm Integration Reference Point (IRP): Part 2: Alarm Integration Reference Point (IRP):
Information Service (IS)", 3GPP TS 32.111-2 3.4.0, March Information Service (IS)", 3GPP TS 32.111-2 3.4.0, March
2005. 2005.
[ALARMSEM] [ALARMSEM]
Wallin, S., Leijon, V., Nordlander, J., and N. Bystedt, Wallin, S., Leijon, V., Nordlander, J., and N. Bystedt,
"The semantics of alarm definitions: enabling systematic "The semantics of alarm definitions: enabling systematic
skipping to change at page 62, line 35 skipping to change at page 66, line 22
[EEMUA] EEMUA Publication No. 191 Engineering Equipment and [EEMUA] EEMUA Publication No. 191 Engineering Equipment and
Materials Users Association, London, 2 edition., "Alarm Materials Users Association, London, 2 edition., "Alarm
Systems: A Guide to Design, Management and Procurement.", Systems: A Guide to Design, Management and Procurement.",
2007. 2007.
[G.7710] ITU-T, "SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL [G.7710] ITU-T, "SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL
SYSTEMS AND NETWORKS Data over Transport - Generic aspects SYSTEMS AND NETWORKS Data over Transport - Generic aspects
- Transport network control aspects. Common equipment - Transport network control aspects. Common equipment
management function requirements", 2012. management function requirements", 2012.
[I-D.ietf-netmod-yang-instance-file-format]
Lengyel, B. and B. Claise, "YANG Instance Data File
Format", draft-ietf-netmod-yang-instance-file-format-00
(work in progress), November 2018.
[ISA182] International Society of Automation,ISA, "ANSI/ISA- [ISA182] International Society of Automation,ISA, "ANSI/ISA-
18.2-2009 Management of Alarm Systems for the Process 18.2-2009 Management of Alarm Systems for the Process
Industries", 2009. Industries", 2009.
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management
Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877,
September 2004, <https://www.rfc-editor.org/info/rfc3877>. September 2004, <http://www.rfc-editor.org/info/rfc3877>.
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
DOI 10.17487/RFC4268, November 2005, <https://www.rfc-
editor.org/info/rfc4268>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
YANG Data Model for Hardware Management", RFC 8348,
DOI 10.17487/RFC8348, March 2018, <https://www.rfc-
editor.org/info/rfc8348>.
[X.736] International Telecommunications Union, "Information [X.736] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - Systems Technology - Open Systems Interconnection - Systems
Management: Security alarm reporting function", Management: Security alarm reporting function", ITU-T
ITU-T Recommendation X.736, 1992. Recommendation X.736, 1992.
Appendix A. Vendor-specific Alarm-Types Example Appendix A. Vendor-specific Alarm-Types Example
This example shows how to define alarm-types in a vendor-specific This example shows how to define alarm-types in a vendor-specific
module. In this case the vendor "xyz" has chosen to define top level module. In this case the vendor "xyz" has chosen to define top level
identities according to X.733 event types. identities according to X.733 event types.
module example-xyz-alarms { module example-xyz-alarms {
namespace "urn:example:xyz-alarms"; namespace "urn:example:xyz-alarms";
prefix xyz-al; prefix xyz-al;
skipping to change at page 65, line 41 skipping to change at page 68, line 41
Appendix C. Alarm List Example Appendix C. Alarm List Example
In this example we show an alarm that has toggled [major, clear, In this example we show an alarm that has toggled [major, clear,
major]. An operator has acknowledged the alarm. major]. An operator has acknowledged the alarm.
<alarms xmlns="urn:ietf:params:xml:ns:yang:ietf-alarms" <alarms xmlns="urn:ietf:params:xml:ns:yang:ietf-alarms"
xmlns:xyz-al="urn:example:xyz-alarms" xmlns:xyz-al="urn:example:xyz-alarms"
xmlns:dev="urn:example:device"> xmlns:dev="urn:example:device">
<alarm-list> <alarm-list>
<number-of-alarms>1</number-of-alarms> <number-of-alarms>1</number-of-alarms>
<last-changed>2015-04-08T08:39:50.00Z</last-changed> <last-changed>2018-04-08T08:39:50.00Z</last-changed>
<alarm> <alarm>
<resource> <resource>
/dev:interfaces/dev:interface[name='FastEthernet1/0'] /dev:interfaces/dev:interface[name='FastEthernet1/0']
</resource> </resource>
<alarm-type-id>xyz-al:link-alarm</alarm-type-id> <alarm-type-id>xyz-al:link-alarm</alarm-type-id>
<alarm-type-qualifier></alarm-type-qualifier> <alarm-type-qualifier></alarm-type-qualifier>
<time-created>2018-04-08T08:20:10.00Z</time-created>
<time-created>2015-04-08T08:39:50.00Z</time-created>
<is-cleared>false</is-cleared> <is-cleared>false</is-cleared>
<alt-resource>1.3.6.1.2.1.2.2.1.1.17</alt-resource> <alt-resource>1.3.6.1.2.1.2.2.1.1.17</alt-resource>
<last-changed>2015-04-08T08:39:40.00Z</last-changed> <last-raised>2018-04-08T08:39:40.00Z</last-raised>
<last-changed>2018-04-08T08:39:50.00Z</last-changed>
<perceived-severity>major</perceived-severity> <perceived-severity>major</perceived-severity>
<alarm-text> <alarm-text>
Link operationally down but administratively up Link operationally down but administratively up
</alarm-text> </alarm-text>
<status-change> <status-change>
<time>2015-04-08T08:39:40.00Z</time> <time>2018-04-08T08:39:40.00Z</time>
<perceived-severity>major</perceived-severity> <perceived-severity>major</perceived-severity>
<alarm-text> <alarm-text>
Link operationally down but administratively up Link operationally down but administratively up
</alarm-text> </alarm-text>
</status-change> </status-change>
<status-change> <status-change>
<time>2015-04-08T08:30:00.00+00:00</time> <time>2018-04-08T08:30:00.00Z</time>
<perceived-severity>cleared</perceived-severity> <perceived-severity>cleared</perceived-severity>
<alarm-text> <alarm-text>
Link operationally up and administratively up Link operationally up and administratively up
</alarm-text> </alarm-text>
</status-change> </status-change>
<status-change> <status-change>
<time>2015-04-08T08:20:10.00+00:00</time> <time>2018-04-08T08:20:10.00Z</time>
<perceived-severity>major</perceived-severity> <perceived-severity>major</perceived-severity>
<alarm-text> <alarm-text>
Link operationally down but administratively up Link operationally down but administratively up
</alarm-text> </alarm-text>
</status-change> </status-change>
<operator-state-change> <operator-state-change>
<time>2015-04-08T08:39:50.00Z</time> <time>2018-04-08T08:39:50.00Z</time>
<state>ack</state> <state>ack</state>
<operator>joe</operator> <operator>joe</operator>
<text>Will investigate, ticket TR764999</text> <text>Will investigate, ticket TR764999</text>
</operator-state-change> </operator-state-change>
</alarm> </alarm>
</alarm-list> </alarm-list>
</alarms> </alarms>
Appendix D. Alarm Shelving Example Appendix D. Alarm Shelving Example
skipping to change at page 68, line 5 skipping to change at page 71, line 5
<alarm-type-id>xyz-al:environmental-alarm</alarm-type-id> <alarm-type-id>xyz-al:environmental-alarm</alarm-type-id>
<alarm-type-qualifier-match> <alarm-type-qualifier-match>
smoke-alarm smoke-alarm
</alarm-type-qualifier-match> </alarm-type-qualifier-match>
<event-type>quality-of-service-alarm</event-type> <event-type>quality-of-service-alarm</event-type>
<probable-cause>777</probable-cause> <probable-cause>777</probable-cause>
</x733-mapping> </x733-mapping>
</control> </control>
</alarms> </alarms>
Appendix F. Relationships to other standards Appendix F. Relationship to other alarm standards
This section briefly describes how this alarm module relates to other This section briefly describes how this alarm module relates to other
relevant standards. relevant standards.
F.1. Relationship to RFC 8348 F.1. Alarm definition
RFC 8348 [RFC8348] defines a YANG data model for the management of
hardware. The "alarm-state" in RFC 8348 (and EntityAlarmStatus in
RFC 4268 [RFC4268]) is a summary of the alarm severity levels that
may be active on the specific hardware component. It does not say
anything about how alarms are reported, and it doesn't provide any
details of the alarms.
The mapping between the alarm YANG data-model and the alarm-state in
RFC 8348 are outlined below
resource: corresponds to /hardware/component/
is-cleared: no bit set in /hardware/component/state/alarm-state
perceived-severity: corresponding bit set in
/hardware/component/state/alarm-state
operator-state-change/state: if the alarm is acknowledged by the
operator it may correspond to under-repair
F.2. Relationship to other alarm standards
F.2.1. Alarm definition
The table below summarizes relevant definitions of the term "alarm" The table below summarizes relevant definitions of the term "alarm"
in other alarm standards. in other alarm standards.
+------------+---------------------------+--------------------------+ +------------+---------------------------+--------------------------+
| Standard | Definition | Comment | | Standard | Definition | Comment |
+------------+---------------------------+--------------------------+ +------------+---------------------------+--------------------------+
| X.733 | error: A deviation of a | The X.733 alarm | | X.733 | error: A deviation of a | The X.733 alarm |
| [X.733] | system from normal | definition is focused on | | [X.733] | system from normal | definition is focused on |
| | operation. fault: The | the notification as such | | | operation. fault: The | the notification as such |
skipping to change at page 70, line 27 skipping to change at page 73, line 5
| | loss of operational | | | | loss of operational | |
| | capabilities [...] | | | | capabilities [...] | |
+------------+---------------------------+--------------------------+ +------------+---------------------------+--------------------------+
Table 1: Definition of alarm in standards Table 1: Definition of alarm in standards
The evolution of the definition of alarm moves from focused on events The evolution of the definition of alarm moves from focused on events
reporting a deviation from normal operation towards a definition to a reporting a deviation from normal operation towards a definition to a
undesired *state* which *requires an operator action*. undesired *state* which *requires an operator action*.
F.2.2. Data model F.2. Data model
This section describes how this YANG alarm module relates to other This section describes how this YANG alarm module relates to other
standard data models. Note well that we cover other data-models for standard data models. Note well that we cover other data-models for
alarm interfaces. Not other standards such as SDO specific alarms alarm interfaces. Not other standards such as SDO specific alarms
for example. for example.
F.2.2.1. X.733 F.2.1. X.733
X.733 has acted as a base for several alarm data models over the X.733 has acted as a base for several alarm data models over the
year. The YANG alarm module differs in the following ways: year. The YANG alarm module differs in the following ways:
X.733 models the alarm list as a list of notifications. The YANG X.733 models the alarm list as a list of notifications. The YANG
alarm module defines the alarm list as the current alarm states alarm module defines the alarm list as the current alarm states
for the resources, which is generated from the state change for the resources, which is generated from the state change
reporting notifications. reporting notifications.
In X.733 an alarm can have the severity level clear. In the YANG In X.733 an alarm can have the severity level clear. In the YANG
skipping to change at page 71, line 12 skipping to change at page 73, line 38
identify alarm types. This alarm module uses a hierarchical YANG identify alarm types. This alarm module uses a hierarchical YANG
identity, alarm-type. This enables delegation of alarm types identity, alarm-type. This enables delegation of alarm types
within organizations. It also lets management reason about within organizations. It also lets management reason about
"abstract" alarm-types corresponding to base identities, see "abstract" alarm-types corresponding to base identities, see
Section 3.2. Section 3.2.
The YANG alarm module has not included the majority of the X.733 The YANG alarm module has not included the majority of the X.733
alarm attributes. Rather these are defined in an augmenting alarm attributes. Rather these are defined in an augmenting
module if "strict" X.733 compliance is needed. module if "strict" X.733 compliance is needed.
F.2.2.2. RFC 3877, the Alarm MIB F.2.2. RFC 3877, the Alarm MIB
The MIB in RFC 3877 takes a different approach, rather than defining The MIB in RFC 3877 takes a different approach, rather than defining
a concrete data model for alarms, it defines a model to map existing a concrete data model for alarms, it defines a model to map existing
SNMP managed objects and notifications into alarm states and alarm SNMP managed objects and notifications into alarm states and alarm
notifications. This was necessary since MIBs were already defined notifications. This was necessary since MIBs were already defined
with both managed objects and notifications indicating alarms, for with both managed objects and notifications indicating alarms, for
example linkUp and linkDown notifications in combination with example linkUp and linkDown notifications in combination with
ifAdminState and ifOperState. So RFC 3877 can not really be compared ifAdminState and ifOperState. So RFC 3877 can not really be compared
to the alarm YANG module in that sense. to the alarm YANG module in that sense.
The Alarm MIB maps existing MIB definitions into alarms, The Alarm MIB maps existing MIB definitions into alarms,
alarmModelTable. The upside of that is that a SNMP Manager can at alarmModelTable. The upside of that is that a SNMP Manager can at
runtime read the possible alarm types. This corresponds to the runtime read the possible alarm types. This corresponds to the
alarmInventory in the alarm YANG module. alarmInventory in the alarm YANG module.
F.2.2.3. 3GPP Alarm IRP F.2.3. 3GPP Alarm IRP
The 3GPP Alarm IRP is an evolution of X.733. Main differences The 3GPP Alarm IRP is an evolution of X.733. Main differences
between the alarm YANG module and 3GPP are: between the alarm YANG module and 3GPP are:
3GPP keeps the majority of the X.733 attributes, the alarm YANG 3GPP keeps the majority of the X.733 attributes, the alarm YANG
module does not. module does not.
3GPP introduced overlapping and possibly conflicting keys for 3GPP introduced overlapping and possibly conflicting keys for
alarms, alarmId and (managed object, event type, probable cause, alarms, alarmId and (managed object, event type, probable cause,
specific problem). (See Annex C in [X.733] Example 3). In the specific problem). (See Annex C in [X.733] Example 3). In the
YANG alarm module the key for identifying an alarm instance is YANG alarm module the key for identifying an alarm instance is
clearly defined by (resource, alarm-type, alarm-type-qualifier). clearly defined by (resource, alarm-type, alarm-type-qualifier).
See also Section 3.4 for more information. See also Section 3.4 for more information.
The alarm YANG module clearly separates the resource/ The alarm YANG module clearly separates the resource/
instrumentation life cycle from the operator life cycle. 3GPP instrumentation life cycle from the operator life cycle. 3GPP
allows operators to set the alarm severity to clear, this is not allows operators to set the alarm severity to clear, this is not
allowed by this module, rather an operator closes an alarm which allowed by this module, rather an operator closes an alarm which
does not affect the severity. does not affect the severity.
F.2.2.4. G.7710 F.2.4. G.7710
G.7710 is different than the previous referenced alarm standards. It G.7710 is different than the previous referenced alarm standards. It
does define a data-model for alarm reporting. It defines common does define a data-model for alarm reporting. It defines common
equipment management function requirements including alarm equipment management function requirements including alarm
instrumentation. The scope is transport networks. instrumentation. The scope is transport networks.
The requirements in G.7710 corresponds to features in the alarm YANG The requirements in G.7710 corresponds to features in the alarm YANG
module in the following way: module in the following way:
Alarm Severity Assignment Profile (ASAP): the alarm profile Alarm Severity Assignment Profile (ASAP): the alarm profile
 End of changes. 149 change blocks. 
576 lines changed or deleted 720 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/