draft-ietf-ccamp-alarm-module-07.txt   draft-ietf-ccamp-alarm-module-08.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: August 1, 2019 Cisco Expires: September 27, 2019 Cisco
January 28, 2019 March 26, 2019
YANG Alarm Module YANG Alarm Module
draft-ietf-ccamp-alarm-module-07 draft-ietf-ccamp-alarm-module-08
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 notifications to inform management systems. There are also
operations to manage the operator state of an alarm and operations to manage the operator state of an alarm and
administrative alarm procedures. The module carefully maps to administrative alarm procedures. The module carefully maps to
relevant alarm standards. relevant alarm standards.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 August 1, 2019. This Internet-Draft will expire on September 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Notation . . . . . . . . . . . . . . . . 3 1.1. Terminology and Notation . . . . . . . . . . . . . . . . 3
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Alarm Module Concepts . . . . . . . . . . . . . . . . . . . . 5 3. Alarm Module Concepts . . . . . . . . . . . . . . . . . . . . 5
3.1. Alarm Definition . . . . . . . . . . . . . . . . . . . . 5 3.1. Alarm Definition . . . . . . . . . . . . . . . . . . . . 5
3.2. Alarm Type . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Alarm Type . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Identifying the Alarming Resource . . . . . . . . . . . . 8 3.3. Identifying the Alarming Resource . . . . . . . . . . . . 8
3.4. Identifying Alarm Instances . . . . . . . . . . . . . . . 8 3.4. Identifying Alarm Instances . . . . . . . . . . . . . . . 9
3.5. Alarm Life-Cycle . . . . . . . . . . . . . . . . . . . . 8 3.5. Alarm Life-Cycle . . . . . . . . . . . . . . . . . . . . 9
3.5.1. Resource Alarm Life-Cycle . . . . . . . . . . . . . . 9 3.5.1. Resource Alarm Life-Cycle . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . 11
3.6. Root Cause, Impacted Resources and Related 3.6. Root Cause, Impacted Resources and Related
Alarms . . . . . . . . . . . . . . . . . . . . . . . . . 11 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.7. Alarm Shelving . . . . . . . . . . . . . . . . . . . . . 12 3.7. Alarm Shelving . . . . . . . . . . . . . . . . . . . . . 13
3.8. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 12 3.8. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 13
4. Alarm Data Model . . . . . . . . . . . . . . . . . . . . . . 12 4. Alarm Data Model . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Alarm Control . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Alarm Control . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Alarm Shelving . . . . . . . . . . . . . . . . . . . 14 4.1.1. Alarm Shelving . . . . . . . . . . . . . . . . . . . 15
4.2. Alarm Inventory . . . . . . . . . . . . . . . . . . . . . 15 4.2. Alarm Inventory . . . . . . . . . . . . . . . . . . . . . 16
4.3. Alarm Summary . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Alarm Summary . . . . . . . . . . . . . . . . . . . . . . 16
4.4. The Alarm List . . . . . . . . . . . . . . . . . . . . . 16 4.4. The Alarm List . . . . . . . . . . . . . . . . . . . . . 17
4.5. The Shelved Alarms List . . . . . . . . . . . . . . . . . 18 4.5. The Shelved Alarms List . . . . . . . . . . . . . . . . . 19
4.6. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 18 4.6. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 19
4.7. Operations . . . . . . . . . . . . . . . . . . . . . . . 19 4.7. Operations . . . . . . . . . . . . . . . . . . . . . . . 20
4.8. Notifications . . . . . . . . . . . . . . . . . . . . . . 19 4.8. Notifications . . . . . . . . . . . . . . . . . . . . . . 20
5. Relationship to the ietf-hardware YANG module . . . . . . . . 19 5. Relationship to the ietf-hardware YANG module . . . . . . . . 20
6. Alarm YANG Module . . . . . . . . . . . . . . . . . . . . . . 20 6. Alarm YANG Module . . . . . . . . . . . . . . . . . . . . . . 21
7. X.733 Extensions . . . . . . . . . . . . . . . . . . . . . . 51 7. X.733 Extensions . . . . . . . . . . . . . . . . . . . . . . 53
8. The X.733 Mapping Module . . . . . . . . . . . . . . . . . . 51 8. The X.733 Mapping Module . . . . . . . . . . . . . . . . . . 53
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
10. Security Considerations . . . . . . . . . . . . . . . . . . . 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 65
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
12.1. Normative References . . . . . . . . . . . . . . . . . . 65 12.1. Normative References . . . . . . . . . . . . . . . . . . 66
12.2. Informative References . . . . . . . . . . . . . . . . . 66 12.2. Informative References . . . . . . . . . . . . . . . . . 68
Appendix A. Vendor-specific Alarm-Types Example . . . . . . . . 67 Appendix A. Vendor-specific Alarm-Types Example . . . . . . . . 69
Appendix B. Alarm Inventory Example . . . . . . . . . . . . . . 68 Appendix B. Alarm Inventory Example . . . . . . . . . . . . . . 70
Appendix C. Alarm List Example . . . . . . . . . . . . . . . . . 69 Appendix C. Alarm List Example . . . . . . . . . . . . . . . . . 71
Appendix D. Alarm Shelving Example . . . . . . . . . . . . . . . 70 Appendix D. Alarm Shelving Example . . . . . . . . . . . . . . . 72
Appendix E. X.733 Mapping Example . . . . . . . . . . . . . . . 71 Appendix E. X.733 Mapping Example . . . . . . . . . . . . . . . 73
Appendix F. Relationship to other alarm standards . . . . . . . 72 Appendix F. Relationship to other alarm standards . . . . . . . 74
F.1. Alarm definition . . . . . . . . . . . . . . . . . . . . 72 F.1. Alarm definition . . . . . . . . . . . . . . . . . . . . 74
F.2. Data model . . . . . . . . . . . . . . . . . . . . . . . 74 F.2. Data model . . . . . . . . . . . . . . . . . . . . . . . 76
F.2.1. X.733 . . . . . . . . . . . . . . . . . . . . . . . . 74 F.2.1. X.733 . . . . . . . . . . . . . . . . . . . . . . . . 76
F.2.2. RFC 3877, the Alarm MIB . . . . . . . . . . . . . . . 74 F.2.2. RFC 3877, the Alarm MIB . . . . . . . . . . . . . . . 76
F.2.3. 3GPP Alarm IRP . . . . . . . . . . . . . . . . . . . 75 F.2.3. 3GPP Alarm IRP . . . . . . . . . . . . . . . . . . . 77
F.2.4. G.7710 . . . . . . . . . . . . . . . . . . . . . . . 75 F.2.4. G.7710 . . . . . . . . . . . . . . . . . . . . . . . 77
Appendix G. Alarm Usability Requirements . . . . . . . . . . . . 75 Appendix G. Alarm Usability Requirements . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
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 north-bound 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.
Raw alarms from devices do not always tell the status of the network Raw alarms from devices do not always tell the status of the network
services or necessarily point to the root cause. However, being able services or necessarily point to the root cause. However, being able
to feed alarms to the alarm management application in a standardized to feed alarms to the alarm management application in a standardized
format is a starting point for performing higher level network format is a starting point for performing higher level network
assurance tasks. assurance tasks.
The design of the module is based on experience from using and The design of the module is based on experience from using and
skipping to change at page 4, line 8 skipping to change at page 4, line 8
o data tree o data tree
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 Fault: A fault is the underlying cause of an undesired behaviour.
There is no trivial one-to-one mapping between faults and alarms.
One fault may result in several alarms in case the system lacks
root-cause and correlation capabilities. An alarm might not have
an underlying fault as a cause, imagine a bad MOS score alarm from
a VOIP probe and the cause being non-optimal QoS configuration.
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".
o Resource: A fine-grained identification of the alarming resource, o Resource: A fine-grained identification of the alarming resource,
for example: an interface, a process. for example: an interface, a process.
o Alarm Instance: The alarm state for a specific resource and alarm o Alarm Instance: The alarm state for a specific resource and alarm
type. For example (GigabitEthernet0/15, link-alarm). An entry in type. For example (GigabitEthernet0/15, link-alarm). An entry in
the alarm list. the alarm list.
o Cleared alarm: A cleared alarm is an alarm where the system/server
considers the undesired state to be cleared. Operators can not
clear alarms, clearance is managed by the system. A linkUp
notification can be considered a clear condition for a linkDown
state.
o Closed alarm: Operators can close alarms irrespective of the alarm
being cleared or not. A closed alarm indicates that the alarm
does not need attention, either since the corrective action has
been taken or that it can be ignored for other reasons.
o Alarm Inventory: A list of all possible alarm types on a system. o Alarm Inventory: A list of all possible alarm types on a system.
o Alarm Shelving: Blocking alarms according to specific criteria. o Alarm Shelving: Blocking alarms according to specific criteria.
o Corrective Action: An action taken by an operator or automation o Corrective Action: An action taken by an operator or automation
routine in order to minimize the impact of the alarm or resolving routine in order to minimize the impact of the alarm or resolving
the root cause. the root cause.
o Management System: The alarm management application that consumes o Management System: The alarm management application that consumes
the alarms, i.e., acts as a client. the alarms, i.e., acts as a client.
skipping to change at page 5, line 14 skipping to change at page 5, line 31
o Clear and precise identification of alarm types and alarm o Clear and precise identification of alarm types and alarm
instances. instances.
o A management system should be able to pull all available alarm o A management system should be able to pull all available alarm
types from a system, i.e., read the alarm inventory from a system. types from a system, i.e., read the alarm inventory from a system.
This makes it possible to prepare alarm operators with This makes it possible to prepare alarm operators with
corresponding alarm instructions. corresponding alarm instructions.
o Address alarm usability requirements, see Appendix G. While IETF o Address alarm usability requirements, see Appendix G. While IETF
has not really addressed alarm management, telecom standards has and telecom standards have addressed alarms mostly from a protocol
addressed it purely from a protocol perspective. The process perspective, the process industry has published several relevant
industry has published several relevant standards addressing standards addressing requirements for a useful alarm interface;
requirements for a useful alarm interface; [EEMUA], [ISA182]. [EEMUA], [ISA182]. This alarm module defines usability
This alarm module defines usability requirements as well as a YANG requirements as well as a YANG data model.
data model.
o Mapping to X.733, which is a requirement for some alarm systems. o Mapping to X.733, which is a requirement for some alarm systems.
Still, keep some of the X.733 concepts out of the core model in Still, keep some of the X.733 concepts out of the core model in
order to make the model small and easy to understand. order to make the model small and easy to understand.
3. Alarm Module Concepts 3. Alarm Module Concepts
This section defines the fundamental concepts behind the data model. This section defines the fundamental concepts behind the data model.
This section is rooted in the works of Vallin et. al [ALARMSEM]. This section is rooted in the works of Vallin et. al [ALARMSEM].
skipping to change at page 5, line 41 skipping to change at page 6, line 9
An alarm signifies an undesirable state in a resource that requires An alarm signifies an undesirable state in a resource that requires
corrective action. corrective action.
There are two main things to remember from this definition: There are two main things to remember from this definition:
1. the definition focuses on leaving out events and logging 1. the definition focuses on leaving out events and logging
information in general. Alarms should only be used for undesired information in general. Alarms should only be used for undesired
states that require action. states that require action.
2. the definition also focus on alarms as a state on a resource, not 2. the definition also focuses on alarms as a state on a resource,
the notifications that report the state changes. not the notifications that report the state changes.
See Appendix F for information how this definition relates to other See Appendix F for information how this definition relates to other
alarm standards. alarm standards.
3.2. Alarm Type 3.2. Alarm Type
This document defines an alarm type with an alarm type id and an This document defines an alarm type with an alarm type id and an
alarm type qualifier. alarm type qualifier.
The alarm type id is modeled as a YANG identity. With YANG The alarm type id is modeled as a YANG identity. With YANG
identities, new alarm types can be defined in a distributed fashion. identities, new alarm types can be defined in a distributed fashion.
YANG identities are hierarchical, which means that an hierarchy of YANG identities are hierarchical, which means that a hierarchy of
alarm types can be defined. alarm types can be defined.
Standards and vendors should define their own alarm type identities Standards and vendors should define their own alarm type identities
based on this definition. based on this definition.
The use of YANG identities means that all possible alarms are The use of YANG identities means that all possible alarms are
identified at design time. This explicit declaration of alarm types identified at design time. This explicit declaration of alarm types
makes it easier to allow for alarm qualification reviews and makes it easier to allow for alarm qualification reviews and
preparation of alarm actions and documentation. preparation of alarm actions and documentation.
skipping to change at page 9, line 24 skipping to change at page 10, line 9
server may also perform these operations based on other policies, server may also perform these operations based on other policies,
but how that is done is out of scope for this document. but how that is done is out of scope for this document.
A server SHOULD describe how long it retains cleared/closed alarms: A server SHOULD describe how long it retains cleared/closed alarms:
until manually purged or if it has an automatic removal policy. until manually purged or if it has an automatic removal policy.
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 action an administrative process. The alarm module defines an action
"purge-alarms" 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.
skipping to change at page 9, line 50 skipping to change at page 10, line 35
+--ro is-cleared boolean +--ro is-cleared boolean
+--ro last-changed yang:date-and-time +--ro last-changed yang:date-and-time
+--ro perceived-severity severity +--ro perceived-severity severity
+--ro alarm-text alarm-text +--ro alarm-text alarm-text
+--ro status-change* [time] {alarm-history}? +--ro status-change* [time] {alarm-history}?
+--ro time yang:date-and-time +--ro time yang:date-and-time
+--ro perceived-severity severity-with-clear +--ro perceived-severity severity-with-clear
+--ro alarm-text alarm-text +--ro alarm-text alarm-text
For every status change from the resource perspective a row is added For every status change from the resource perspective a row is added
to the "status-change" list. The last status values are also to the "status-change" list, if the server implements the feature
represented as leafs for the alarm. Note well that the alarm "alarm-history". The feature "alarm-history" is optional to
severity does not include "cleared", alarm clearance is a boolean implement, since keeping the alarm history may have an impact on the
flag. server's memory resources.
The last status values are also represented as leafs for the alarm.
Note well that the alarm severity does not include "cleared", alarm
clearance is a boolean flag.
An alarm can therefore look like this: ((GigabitEthernet0/25, link- An alarm can therefore look like this: ((GigabitEthernet0/25, link-
alarm,""), false, T, major, "Interface GigabitEthernet0/25 down") alarm,""), false, 2018-04-08T08:20:10.00Z, major, "Interface
GigabitEthernet0/25 down")
3.5.2. Operator Alarm Life-cycle 3.5.2. Operator Alarm Life-cycle
Operators can also act upon alarms using the set-operator-state Operators can also act upon alarms using the set-operator-state
action: action:
+--ro alarm* [resource alarm-type-id alarm-type-qualifier] +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
... ...
+--ro operator-state-change* [time] {operator-actions}? +--ro operator-state-change* [time] {operator-actions}?
| +--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 action "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 criterion. 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" action. The "purge- action. This is supported by the "purge-alarms" action. The "purge-
alarms" action takes a filter as input. The filter selects alarms alarms" action takes a filter as input. The filter selects alarms
based on the operator and resource life-cycle such as "all closed based on the operator and resource life-cycle such as "all closed
cleared alarms older than a time specification". The server may also cleared alarms older than a time specification". The server may also
skipping to change at page 11, line 40 skipping to change at page 12, line 31
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 to have a single alarm applications as well. The recommendation is to have a single alarm
for the underlying problem and list the affected resources in the for the underlying problem and list the affected resources in the
alarm, rather than having separate alarms for each resource. alarm, rather than having separate alarms for each resource.
The alarm has one leaf-list to identify possible "impacted-resources" The alarm has one leaf-list to identify possible "impacted-resources"
and a leaf-list to identify possible "root-cause-resources". These and a leaf-list to identify possible "root-cause-resources". These
serves as hints only. It is up to the client application to use this serves as hints only. It is up to the client application to use this
information to present the overall status. Using the the disk full information to present the overall status. Using the disk full
example, a "good" alarm would be to use the hard disk partition as example, a "good" alarm would be to use the hard disk partition as
the alarming resource and add the database and applications into the the alarming resource and add the database and applications into the
impacted-resources leaf-list. impacted-resources leaf-list.
A system should always strive to identify the resource that can be A system should always strive to identify the resource that can be
acted upon as the "resource" leaf. The "impacted-resource" leaf-list acted upon as the "resource" leaf. The "impacted-resource" leaf-list
shall be used to identify any side-effects of the alarm. The shall be used to identify any side-effects of the alarm. The
impacted resources can not be acted upon to fix the problem. The impacted resources can not be acted upon to fix the problem. The
disk full example above illustrates the principle; you can not fix disk full example above illustrates the principle; you can not fix
the underlying issue by database operations. However, you need to the underlying issue by database operations. However, you need to
skipping to change at page 12, line 30 skipping to change at page 13, line 21
Note well that this module does not prescribe any dependencies or Note well that this module does not prescribe any dependencies or
preference between the above alarm correlation mechanisms. Different preference between the above alarm correlation mechanisms. Different
systems have different capabilities and the above described systems have different capabilities and the above described
mechanisms are available to support the instrumentation features. mechanisms are available to support the instrumentation features.
3.7. Alarm Shelving 3.7. Alarm Shelving
Alarm shelving is an important function in order for alarm management Alarm shelving is an important function in order for alarm management
applications and operators to stop superfluous alarms. A shelved applications and operators to stop superfluous alarms. A shelved
alarm implies that any alarms fulfilling this criteria are ignored alarm implies that any alarms fulfilling these criteria are ignored
(blocked/filtered). Shelved alarms appear in a dedicated shelved (blocked/filtered). Shelved alarms appear in a dedicated shelved
alarm list in order not to disturb the relevant alarms. Shelved alarm list in order not to disturb the relevant alarms. Shelved
alarms do not generate notifications but the shelved alarm list is alarms do not generate notifications but the shelved alarm list is
updated with any alarm state changes. updated with any alarm state changes.
Alarm shelving is optional to implement, since matching alarms
against shelf criteria may have an impact on the server's processing
resources.
3.8. Alarm Profiles 3.8. Alarm Profiles
Alarm profiles are used to configure further information to an alarm Alarm profiles are used to configure further information to an alarm
type. This module supports configuring severity levels overriding type. This module supports configuring severity levels overriding
the system default levels. This corresponds to the Alarm Assignment the system default levels. This corresponds to the Alarm Assignment
Profile, ASAP, functionality in M.3100 [M.3100] and M.3160 [M.3160]. Profile, ASAP, functionality in M.3100 [M.3100] and M.3160 [M.3160].
Other standard or enterprise modules can augment this list with Other standard or enterprise modules can augment this list with
further alarm type information. further alarm type information.
4. Alarm Data Model 4. Alarm Data Model
skipping to change at page 13, line 8 skipping to change at page 14, line 6
The fundamental parts of the data model are the "alarm-list" with The fundamental parts of the data model are the "alarm-list" with
associated notifications and the "alarm-inventory" list of all associated notifications and the "alarm-inventory" list of all
possible alarm types. These MUST be implemented by a system. The possible alarm types. These MUST be implemented by a system. The
rest of the data model are made conditional with YANG the features rest of the data model are made conditional with YANG the features
"operator-actions", "alarm-shelving", "alarm-history", "alarm- "operator-actions", "alarm-shelving", "alarm-history", "alarm-
summary", "alarm-profile", and "severity-assignment". summary", "alarm-profile", and "severity-assignment".
The data model has the following overall structure: The data model has the following overall structure:
+--rw control +--rw control
| +--rw max-alarm-status-changes? union | +--rw max-alarm-status-changes? union
| +--rw (notify-status-changes)? | +--rw notify-status-changes? enumeration
| | ... | +--rw notify-severity-level? severity
| +--rw alarm-shelving {alarm-shelving}? | +--rw alarm-shelving {alarm-shelving}?
| ... | ...
+--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 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
skipping to change at page 14, line 7 skipping to change at page 15, line 7
+--rw alarm-type-id alarm-type-id +--rw alarm-type-id alarm-type-id
+--rw alarm-type-qualifier-match string +--rw alarm-type-qualifier-match string
+--rw resource 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" leaf 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
feature in combination with alarm shelving corresponds to the ITU feature in combination with alarm shelving corresponds to the ITU
Alarm Report Control functionality. Alarm Report Control functionality.
Every alarm has a list of status changes, this is a circular list. Every alarm has a list of status changes. The length of this list is
The length of this list is controlled by "/alarms/control/max-alarm- controlled by "/alarms/control/max-alarm-status-changes". When the
status-changes". list is full and a new entry created, the oldest entry is removed.
4.1.1. Alarm Shelving 4.1.1. Alarm Shelving
The shelving control tree is shown below: The shelving control tree is shown below:
+--rw control +--rw control
+--rw alarm-shelving {alarm-shelving}? +--rw alarm-shelving {alarm-shelving}?
+--rw shelf* [name] +--rw shelf* [name]
+--rw name string +--rw name string
+--rw resource* resource-match +--rw resource* resource-match
skipping to change at page 15, line 39 skipping to change at page 16, line 39
[I-D.ietf-netmod-yang-instance-file-format] can be used for this [I-D.ietf-netmod-yang-instance-file-format] can be used for this
purpose. 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 will-clear boolean
+--ro severity-levels* severity +--ro severity-levels* severity
+--ro description string +--ro description string
4.3. Alarm Summary 4.3. Alarm Summary
The alarm summary list summarizes alarms per severity; how many The alarm summary list summarizes alarms per severity; how many
cleared, cleared and closed, and closed. It also gives an indication cleared, cleared and closed, and closed. It also gives an indication
if there are shelved alarms. if there are shelved alarms.
The alarm summary tree is shown below: The alarm summary tree is shown below:
skipping to change at page 19, line 17 skipping to change at page 20, line 17
The alarm module supports the following actions to manage the alarms: The alarm module supports the following actions to manage the alarms:
/alarms/alarm-list/purge-alarms: Delete alarms from the "alarm-list" /alarms/alarm-list/purge-alarms: Delete alarms from the "alarm-list"
according to specific criteria, for example all cleared alarms according to specific criteria, for example all cleared alarms
older than a specific date. older than a specific date.
/alarms/alarm-list/compress-alarms: Compress the "status-change" /alarms/alarm-list/compress-alarms: Compress the "status-change"
list for the alarms. list for the alarms.
/alarms/alarm-list/alarm/set-operator-state: Change the operator /alarms/alarm-list/alarm/set-operator-state: Change the operator
state for an alarm. For example, an alarn can be acknowledged by state for an alarm. For example, an alarm can be acknowledged by
setting the operator state to "ack". setting the operator state to "ack".
/alarms/shelved-alarm-list/purge-shelved-alarms: Delete alarms from /alarms/shelved-alarm-list/purge-shelved-alarms: Delete alarms from
the "shelved-alarm-list" according to specific criteria, for the "shelved-alarm-list" according to specific criteria, for
example all alarms older than a specific date. example all alarms older than a specific date.
/alarms/shelved-alarm-list/compress-shelved-alarms: Compress the /alarms/shelved-alarm-list/compress-shelved-alarms: Compress the
"status-change" list for the alarms. "status-change" list for the alarms.
4.8. Notifications 4.8. Notifications
skipping to change at page 20, line 20 skipping to change at page 21, line 20
"/hardware/component/state/alarm-state". "/hardware/component/state/alarm-state".
operator-state-change/state: If the alarm is acknowledged by the operator-state-change/state: If the alarm is acknowledged by the
operator, the bit "under-repair" is in "/hardware/component/state/ operator, the bit "under-repair" is in "/hardware/component/state/
alarm-state". alarm-state".
6. Alarm YANG Module 6. Alarm YANG Module
This YANG module references [RFC6991]. This YANG module references [RFC6991].
<CODE BEGINS> file "ietf-alarms@2019-01-27.yang" <CODE BEGINS> file "ietf-alarms@2019-03-21.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 reference
"RFC 6991: Common YANG Data Types."; "RFC 6991: Common YANG Data Types.";
} }
skipping to change at page 23, line 5 skipping to change at page 24, line 5
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
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.";
// RFC Ed.: update the date below with the date of RFC publication // RFC Ed.: update the date below with the date of RFC publication
// and remove this note. // and remove this note.
revision 2010-01-27 { revision 2019-03-21 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Alarm Module"; "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
states on alarms."; states on alarms.";
} }
feature alarm-shelving { feature alarm-shelving {
description description
"This feature indicates that the system supports shelving "This feature indicates that the system supports shelving
(blocking) alarms."; (blocking) alarms.
Alarm shelving may have an impact on server processing
resources in order to match alarms against shelf
criteria.";
} }
feature alarm-history { feature alarm-history {
description description
"This feature indicates that server maintains a history of "This feature indicates that server maintains a history of
state changes for each alarm. For example, if an alarm state changes for each alarm. For example, if an alarm
toggles between cleared and active 10 times, these state toggles between cleared and active 10 times, these state
changes are present in a separate list in the alarm."; changes are present in a separate list in the alarm.
Keeping the alarm history may have an impact on server memory
resources.";
} }
feature alarm-summary { feature alarm-summary {
description description
"This feature indicates that the server summarizes the number "This feature indicates that the server summarizes the number
of alarms per severity and operator state."; of alarms per severity and operator state.";
} }
feature alarm-profile { feature alarm-profile {
description description
skipping to change at page 24, line 16 skipping to change at page 25, line 23
feature root-cause-analysis { feature root-cause-analysis {
description description
"The system supports identifying candidate root-cause "The system supports identifying candidate root-cause
resources for an alarm, for example a disc partition resources for an alarm, for example a disc partition
root cause for a logger failure alarm."; root cause for a logger failure alarm.";
} }
feature service-impact-analysis { feature service-impact-analysis {
description description
"The system supports identifiying candidate impacted "The system supports identifying candidate impacted
resources for an alarm, for exampla a link being impacted resources for an alarm, for example a link being impacted
by an interface alarm."; by an interface alarm.";
} }
feature alarm-correlation { feature alarm-correlation {
description description
"The system supports correlating/grouping alarms "The system supports correlating/grouping alarms
that belong together."; that belong together.";
} }
/* /*
skipping to change at page 38, line 27 skipping to change at page 39, line 33
} }
} }
default "32"; default "32";
description description
"The status-change entries are kept in a circular list per "The status-change entries are kept in a circular list per
alarm. When this number is exceeded, the oldest status alarm. When this number is exceeded, the oldest status
change entry is automatically removed. If the value is change entry is automatically removed. If the value is
'infinite', the status change entries are accumulated 'infinite', the status change entries are accumulated
infinitely."; infinitely.";
} }
choice notify-status-changes { leaf notify-status-changes {
type enumeration {
enum all-state-changes {
description
"Send notifications for all status changes.";
}
enum raise-and-clear {
description
"Send notifications only for raise, clear, and
re-raise. Notifications for severity level changes or
alarm text changes are not sent.";
}
enum severity-level {
description
"Only send notifications for alarm state changes
crossing the level specified in
'notify-severity-level'. Always send clear
notifications.";
}
}
must '. != "severity-level" or ../notify-severity-level' {
description
"When notify-status-changes is 'severity-level', a value
must be given for notify-severity-level.";
}
default "all-state-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 2. Notifications are only sent for alarm raise and clear
3. Notifications are sent for status changes equal to or 3. Notifications are sent for status changes equal to or
above the specified severity level. Clear above the specified severity level. Clear
notifications shall always be sent Notifications shall notifications shall always be sent. Notifications shall
also be sent for state changes that makes an alarm less also be sent for state changes that makes an alarm less
severe than the specified level. severe than the specified level.
For example, in option 3, assuming the severity level is For example, in option 3, assuming the severity level is
set to major and that the alarm has the following state set to major and that the alarm has the following state
changes: 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 times 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 { }
type empty; leaf notify-severity-level {
description when '../notify-status-changes = "severity-level"';
"Send notifications for all status changes."; type severity;
} description
leaf notify-raise-and-clear { "Only send notifications for alarm state changes crossing
type empty; the specified level. Always send clear notifications.";
description
"Send notifications only for raise, clear, and re-raise.
Notifications for severity level changes or alarm text
changes are not sent.";
}
leaf notify-severity-level {
type severity;
description
"Only send notifications for alarm state changes crossing
the specified level. Always send clear 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 first matching shelf is used, (block/filter) alarms. The first matching shelf is used,
and an alarm is shelved only for this first match. and an alarm is shelved only for this first match.
The server will move any alarms corresponding to the The server will move any alarms corresponding to the
shelving criteria from the shelving criteria from the
alarms/alarm-list/alarm list to the alarms/alarm-list/alarm list to the
skipping to change at page 41, line 36 skipping to change at page 43, line 9
description description
"The optionally dynamically defined alarm type identifier "The optionally dynamically defined alarm type identifier
for this possible alarm."; for this possible alarm.";
} }
leaf-list resource { leaf-list resource {
type resource-match; type resource-match;
description description
"Optionally, specifies for which resources the alarm type "Optionally, specifies for which resources the alarm type
is valid."; is valid.";
} }
leaf has-clear { leaf will-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. cleared state for all alarm types.
If this leaf is 'true', the operator can monitor the If this leaf is 'true', the operator can monitor the
alarm until it becomes cleared after the corrective alarm until it becomes cleared after the corrective
action has been taken. action has been taken.
If this leaf is 'false', the operator needs to validate If this leaf is 'false', the operator needs to validate
that the alarm is not longer active using other that the alarm is no 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 the severity type. In general, the severity level
skipping to change at page 51, line 48 skipping to change at page 53, line 24
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'.
8. The X.733 Mapping Module 8. The X.733 Mapping Module
This YANG module references [X.721], [X.733] and [X.736]. This YANG module references [X.721], [X.733] and [X.736].
<CODE BEGINS> file "ietf-alarms-x733@2019-01-27.yang" <CODE BEGINS> file "ietf-alarms-x733@2019-03-21.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 53, line 29 skipping to change at page 54, line 52
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
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.";
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 2019-01-27 { revision 2019-03-21 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: YANG Alarm Module"; "RFC XXXX: YANG Alarm Module";
} }
/* /*
* Features * Features
*/ */
skipping to change at page 63, line 47 skipping to change at page 65, line 27
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers two YANG modules 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
name: ietf-alarms-x7333 name: ietf-alarms-x733
namespace: urn:ietf:params:xml:ns:yang:ietf-alarms-x733 namespace: urn:ietf:params:xml:ns:yang:ietf-alarms-x733
prefix: x733 prefix: x733
reference: RFC XXXX reference: RFC XXXX
10. Security Considerations 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
[RFC8446]. [RFC8446].
The NETCONF access control model [RFC8341] provides the means to The Network Configuration Access Control model (NACM) [RFC8341]
restrict access for particular NETCONF or RESTCONF users to a provides the means to restrict access for particular NETCONF or
preconfigured subset of all available NETCONF or RESTCONF protocol RESTCONF users to a preconfigured subset of all available NETCONF or
operations and content. RESTCONF protocol operations and content.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
/alarms/control/notify-status-change: This leaf controls whether an /alarms/control/notify-status-changes: This leaf controls whether an
alarm should notify only raise and clear or all severity level alarm should notify based on various state changes. Unauthorized
changes. Unauthorized access to leaf could have a negative impact access to this leaf could have a negative impact on operational
on operational procedures relying on fine-grained alarm state 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.
/alarms/control/alarm-profile/alarm-severity-assignment-profile:
This list controls the severity levels of an alarm. Unauthorized
access to this could for example downgrade the severity of an
alarm and thereby have a negative impact on the alarm monitoring
process.
Some of the 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:
/alarms/alarm-list/purge-alarms: This action deletes alarms from the /alarms/alarm-list/purge-alarms: This action deletes alarms from the
alarm list. Unauthorized use of this action could jeopardize the alarm list. Unauthorized use of this action could jeopardize the
alarm management procedures since the deleted alarms may be vital alarm management procedures since the deleted alarms may be vital
for the alarm management application. for the alarm management application.
skipping to change at page 69, line 15 skipping to change at page 71, line 15
<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-inventory> <alarm-inventory>
<alarm-type> <alarm-type>
<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/>
<resource> <resource>
/dev:interfaces/dev:interface /dev:interfaces/dev:interface
</resource> </resource>
<has-clear>true</has-clear> <will-clear>true</will-clear>
<description> <description>
Link failure, operational state down but admin state up Link failure, operational state down but admin state up
</description> </description>
</alarm-type> </alarm-type>
<alarm-type> <alarm-type>
<alarm-type-id>xyz-al:environmental-alarm</alarm-type-id> <alarm-type-id>xyz-al:environmental-alarm</alarm-type-id>
<alarm-type-qualifier>smoke-alarm</alarm-type-qualifier> <alarm-type-qualifier>smoke-alarm</alarm-type-qualifier>
<has-clear>true</has-clear> <will-clear>true</will-clear>
<description> <description>
Connected smoke detector to digital input Connected smoke detector to digital input
</description> </description>
</alarm-type> </alarm-type>
</alarm-inventory> </alarm-inventory>
</alarms> </alarms>
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,
skipping to change at page 72, line 38 skipping to change at page 74, line 38
| | event. An alarm may or | | | | event. An alarm may or | |
| | may not represent an | | | | may not represent an | |
| | error. | | | | error. | |
| | | | | | | |
| G.7710 | Alarms are indications | The G.7710 definition is | | G.7710 | Alarms are indications | The G.7710 definition is |
| [G.7710] | that are automatically | close to the original | | [G.7710] | that are automatically | close to the original |
| | generated by an NE as a | X.733 definition. | | | generated by an NE as a | X.733 definition. |
| | result of the declaration | | | | result of the declaration | |
| | of a failure. | | | | of a failure. | |
| | | | | | | |
| Alarm MIB | Alarm: Persistent | RFC 3877 defines alarm | | Alarm MIB | Alarm: Persistent | RFC 3877 defines the |
| [RFC3877] | indication of a fault. | referring back to "a | | [RFC3877] | indication of a fault. | term alarm referring |
| | Fault: Lasting error or | deviation from normal | | | Fault: Lasting error or | back to "a deviation |
| | warning condition. | operation". This is | | | warning condition. | from normal operation". |
| | Error: A deviation of a | problematic, since this | | | Error: A deviation of a | The Alarm YANG model |
| | system from normal | might not require an | | | system from normal | adds the requirement |
| | operation. | operator action. The | | | operation. | that it should require a |
| | | alarm MIB is state | | | | corrective action and |
| | | oriented rather than | | | | should be undesired, not |
| | | notification oriented, | | | | only a deviation from |
| | | an alarm is a "lasting | | | | normal. The alarm MIB |
| | | condition", not a | | | | is state oriented in the |
| | | discrete notification | | | | same way as the Alarm |
| | | reporting about a | | | | YANG, it focuses on the |
| | | condition state change. | | | | "lasting condition", |
| | | not the individual |
| | | notifications. |
| | | | | | | |
| ISA | Alarm: An audible and/or | The ISA standard adds an | | ISA | Alarm: An audible and/or | The ISA standard adds an |
| [ISA182] | visible means of | important requirement to | | [ISA182] | visible means of | important requirement to |
| | indicating to the | the "deviation from | | | indicating to the | the "deviation from |
| | operator an equipment | normal condition state"; | | | operator an equipment | normal condition state"; |
| | malfunction, process | requiring a response. | | | malfunction, process | requiring a response. |
| | deviation or abnormal | | | | deviation or abnormal | |
| | condition requiring a | | | | condition requiring a | |
| | response. | | | | response. | |
| | | | | | | |
 End of changes. 45 change blocks. 
131 lines changed or deleted 186 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/