draft-ietf-ccamp-alarm-module-04.txt   draft-ietf-ccamp-alarm-module-05.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: April 12, 2019 Cisco Expires: May 10, 2019 Cisco
October 9, 2018 November 6, 2018
YANG Alarm Module YANG Alarm Module
draft-ietf-ccamp-alarm-module-04 draft-ietf-ccamp-alarm-module-05
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 RPCs to
manage the operator state of an alarm and administrative alarm manage the operator state of an alarm and administrative alarm
procedures. The module carefully maps to relevant alarm standards. procedures. The module carefully maps to relevant alarm standards.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 April 12, 2019. This Internet-Draft will expire on May 10, 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 23 skipping to change at page 2, line 23
3.1. Alarm Definition . . . . . . . . . . . . . . . . . . . . 5 3.1. Alarm Definition . . . . . . . . . . . . . . . . . . . . 5
3.2. Alarm Type . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Alarm Type . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . 11 3.8. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 12
4. Alarm Data Model . . . . . . . . . . . . . . . . . . . . . . 12 4. Alarm Data Model . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Alarm Control . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Alarm Control . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Alarm Shelving . . . . . . . . . . . . . . . . . . . 13 4.1.1. Alarm Shelving . . . . . . . . . . . . . . . . . . . 14
4.2. Alarm Inventory . . . . . . . . . . . . . . . . . . . . . 13 4.2. Alarm Inventory . . . . . . . . . . . . . . . . . . . . . 14
4.3. Alarm Summary . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Alarm Summary . . . . . . . . . . . . . . . . . . . . . . 15
4.4. The Alarm List . . . . . . . . . . . . . . . . . . . . . 15 4.4. The Alarm List . . . . . . . . . . . . . . . . . . . . . 15
4.5. The Shelved Alarms List . . . . . . . . . . . . . . . . . 17 4.5. The Shelved Alarms List . . . . . . . . . . . . . . . . . 17
4.6. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 17 4.6. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 17
4.7. RPCs and Actions . . . . . . . . . . . . . . . . . . . . 17 4.7. RPCs and Actions . . . . . . . . . . . . . . . . . . . . 17
4.8. Notifications . . . . . . . . . . . . . . . . . . . . . . 17 4.8. Notifications . . . . . . . . . . . . . . . . . . . . . . 18
5. Alarm YANG Module . . . . . . . . . . . . . . . . . . . . . . 18 5. Alarm YANG Module . . . . . . . . . . . . . . . . . . . . . . 18
6. X.733 Extensions . . . . . . . . . . . . . . . . . . . . . . 47 6. X.733 Extensions . . . . . . . . . . . . . . . . . . . . . . 48
7. The X.733 Mapping Module . . . . . . . . . . . . . . . . . . 48 7. The X.733 Mapping Module . . . . . . . . . . . . . . . . . . 48
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
9. Security Considerations . . . . . . . . . . . . . . . . . . . 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 59
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
11.1. Normative References . . . . . . . . . . . . . . . . . . 60 11.1. Normative References . . . . . . . . . . . . . . . . . . 60
11.2. Informative References . . . . . . . . . . . . . . . . . 61 11.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Vendor-specific Alarm-Types Example . . . . . . . . 62 Appendix A. Vendor-specific Alarm-Types Example . . . . . . . . 63
Appendix B. Alarm Inventory Example . . . . . . . . . . . . . . 63 Appendix B. Alarm Inventory Example . . . . . . . . . . . . . . 64
Appendix C. Alarm List Example . . . . . . . . . . . . . . . . . 64 Appendix C. Alarm List Example . . . . . . . . . . . . . . . . . 65
Appendix D. Alarm Shelving Example . . . . . . . . . . . . . . . 65 Appendix D. Alarm Shelving Example . . . . . . . . . . . . . . . 66
Appendix E. X.733 Mapping Example . . . . . . . . . . . . . . . 66 Appendix E. X.733 Mapping Example . . . . . . . . . . . . . . . 67
Appendix F. Relationships to other standards . . . . . . . . . . 67 Appendix F. Relationships to other standards . . . . . . . . . . 68
F.1. Relationship to RFC 8348 . . . . . . . . . . . . . . . . 67 F.1. Relationship to RFC 8348 . . . . . . . . . . . . . . . . 68
F.2. Relationship to other alarm standards . . . . . . . . . . 67 F.2. Relationship to other alarm standards . . . . . . . . . . 68
F.2.1. Alarm definition . . . . . . . . . . . . . . . . . . 67 F.2.1. Alarm definition . . . . . . . . . . . . . . . . . . 68
F.2.2. Data model . . . . . . . . . . . . . . . . . . . . . 69 F.2.2. Data model . . . . . . . . . . . . . . . . . . . . . 70
Appendix G. Alarm Usability Requirements . . . . . . . . . . . . 71 Appendix G. Alarm Usability Requirements . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75
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 9, line 38 skipping to change at page 9, line 38
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
+--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] +--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. The last status values are also
represented as leafs for the alarm. Note well that the alarm represented as leafs for the alarm. Note well that the alarm
severity does not include "cleared", alarm clearance is a boolean severity does not include "cleared", alarm clearance is a boolean
flag. flag.
skipping to change at page 10, line 38 skipping to change at page 10, line 38
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" rpc. The "purge-
alarms" rpc takes a filter as input. The filter selects alarms based alarms" rpc takes a filter as input. The filter selects alarms based
on the operator and resource life-cycle such as "all closed cleared on the operator and resource life-cycle such as "all closed cleared
alarms older than a time specification". The server may also perform alarms older than a time specification". The server may also perform
these operations based on other policies, but how that is done is out these operations based on other policies, but how that is done is out
of scope for this document. of scope for this document.
Purged alarms are removed from the alarm list. Note well, if the
alarm resource state changes after a purge, the alarm will reappear
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" rpc.
The server may also perform these operations based on other policies, The 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.
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. The alarm has two leaf-lists to identify possible impacted alarms. In many cases several resources are affected for a given
resources and possible root-cause resources. The system should not underlying problem. A full disk will of course impact databases and
represent individual alarms for the possible root-cause resources and applications as well. The recommendation is not have a single alarm
impacted resources. These serves as hints only. It is up to the for the underlying problem an list the affected resources in the
client application to use this information to present the overall alarm, rather than having separate alarms for each resource.
status.
The alarm has one leaf-list to identify possible "impacted-resources"
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
information to present the overall status. Using the the disk full
example, a "good" alarm would be to use the hard disk partition as
the alarming resource and add the database and applications into the
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. An impacted resources can not be acted upon to fix the problem. The
example of this kind of alarm might be a disc full problem which disk full example above illustrates the principle; you can not fix
impacts a number of databases. the underlying issue by database operations. However, you need to
pay attention to the database to perform any operations that limits
the impact of problem.
In some occasions the system might not be capable of detecting the In some occasions the system might not be capable of detecting the
root cause, the resource that can be acted upon. The instrumentation root cause, the resource that can be acted upon. The instrumentation
in this case only monitors the side-effect and needs to represent an in this case only monitors the side-effect and needs to represent an
alarm that indicates a situation that needs acting upon. The alarm that indicates a situation that needs acting upon. The
instrumentation still might identify possible candidates for the instrumentation still might identify possible candidates for the
root-cause resource. In this case the "root-cause-resource" leaf- root-cause resource. In this case the "root-cause-resource" leaf-
list can be used to indicate the candidate root-cause resources. An list can be used to indicate the candidate root-cause resources. An
example of this kind of alarm might be an active test tool that example of this kind of alarm might be an active test tool that
detects an SLA violation on a VPN connection and identifies the detects an SLA violation on a VPN connection and identifies the
skipping to change at page 12, line 35 skipping to change at page 13, line 24
+--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]
| ... | ...
+--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 alarm-shelf-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]
| ... | ...
+--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 al:alarm-type-id
+--rw alarm-type-qualifier-match string +--rw alarm-type-qualifier-match string
+--rw resource al:resource-match +--rw resource al:resource-match
+--rw description string +--rw description string
skipping to change at page 15, line 9 skipping to change at page 15, line 34
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:
+--ro summary {alarm-summary}? +--ro summary {alarm-summary}?
+--ro alarm-summary* [severity] +--ro alarm-summary* [severity]
| +--ro severity severity | +--ro severity severity
| +--ro total? yang:gauge32 | +--ro total? yang:gauge32
| +--ro not-cleared? yang:gauge32
| +--ro cleared? yang:gauge32 | +--ro cleared? yang:gauge32
| +--ro cleared-not-closed? yang:gauge32 | +--ro cleared-not-closed? yang:gauge32
| | {operator-actions}? | | {operator-actions}?
| +--ro cleared-closed? yang:gauge32 | +--ro cleared-closed? yang:gauge32
| | {operator-actions}? | | {operator-actions}?
| +--ro not-cleared-closed? yang:gauge32 | +--ro not-cleared-closed? yang:gauge32
| | {operator-actions}? | | {operator-actions}?
| +--ro not-cleared-not-closed? yang:gauge32 | +--ro not-cleared-not-closed? yang:gauge32
| {operator-actions}? | {operator-actions}?
+--ro shelves-active? empty {alarm-shelving}? +--ro shelves-active? empty {alarm-shelving}?
4.4. The Alarm List 4.4. The Alarm List
The alarm list (/alarms/alarm-list) is a function from (resource, The alarm list (/alarms/alarm-list) is a function from (resource,
alarm type, alarm type qualifier) to the current composite alarm alarm type, alarm type qualifier) to the current composite alarm
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. acknowledgment. This means that for a given resource and alarm-type
the alarm list shows the current states of the alarm such as
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*
skipping to change at page 18, line 16 skipping to change at page 18, line 22
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. Alarm YANG Module
This YANG module references [RFC6991]. This YANG module references [RFC6991].
<CODE BEGINS> file "ietf-alarms@2018-10-09.yang" <CODE BEGINS> file "ietf-alarms@2018-11-06.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 20, line 43 skipping to change at page 20, line 50
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', 'MAY', and
'OPTIONAL' in the module text are to be interpreted as described 'OPTIONAL' in the module text are to be interpreted as described
in RFC 2119 (https://tools.ietf.org/html/rfc2119). in RFC 2119 (https://tools.ietf.org/html/rfc2119).
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-10-09 { revision 2018-11-06 {
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 22, line 30 skipping to change at page 22, line 37
/* /*
* Common types * Common types
*/ */
typedef resource { typedef resource {
type union { type union {
type instance-identifier { type instance-identifier {
require-instance false; require-instance false;
} }
type yang:object-identifier; type yang:object-identifier;
type yang:uuid;
type string; type string;
type yang:uuid;
} }
description description
"This is an identification of the alarming resource, such as an "This is an identification of the alarming resource, such as an
interface. It should be as fine-grained as possible both to interface. It should be as fine-grained as possible both to
guide the operator and to guarantee uniqueness of the alarms. guide the operator and to guarantee uniqueness of the alarms.
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
skipping to change at page 24, line 13 skipping to change at page 24, line 19
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 are those in scope on
the leaf element where this type is used. the leaf element where this type 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 function library is the core function library
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 understand the problem and how to resolve it. If this to understand the problem and how to resolve it. If this
string contains structure, this format should be clearly string contains structure, this format should be clearly
skipping to change at page 37, line 21 skipping to change at page 37, line 26
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.";
} }
leaf not-cleared {
type yang:gauge32;
description
"Total number of alarms of this severity level
that are not cleared.";
}
leaf cleared { leaf cleared {
type yang:gauge32; type yang:gauge32;
description description
"For this severity level, the number of alarms that are "For this severity level, the number of alarms that are
cleared."; cleared.";
} }
leaf cleared-not-closed { leaf cleared-not-closed {
if-feature "operator-actions"; if-feature "operator-actions";
type yang:gauge32; type yang:gauge32;
description description
skipping to change at page 39, line 6 skipping to change at page 39, line 16
and operator-text. and operator-text.
Entries appear in the alarm list the first time an Entries appear in the alarm list the first time an
alarm becomes active for a given alarm-type and resource. alarm 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 are cleared and in closed operator-state that are that are cleared and in closed operator-state that are
older than 24 hours. Systems may also remove alarms based older than 24 hours. Purged alarms are removed from the
on locally configured policies which is out of scope for alarm list. If the alarm resource state changes
this module."; after a purge, the alarm will reappear in the alarm list.
Systems may also remove alarms based on locally configured
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'
skipping to change at page 40, line 30 skipping to change at page 40, line 43
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 alarm-shelf-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. 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 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
skipping to change at page 42, line 48 skipping to change at page 43, line 14
rpc compress-alarms { rpc compress-alarms {
if-feature "alarm-history"; if-feature "alarm-history";
description description
"This operation requests the server to compress entries in the "This operation requests the server to compress entries in the
alarm list by removing all but the latest state change for all alarm list by removing all but the latest state change for all
alarms. Conditions in the input are logically ANDed. If no alarms. Conditions in the input are logically ANDed. If no
input condition is given, all alarms are compressed."; input condition is given, all alarms are compressed.";
input { input {
leaf resource { leaf resource {
type leafref { type resource-match;
path "/alarms/alarm-list/alarm/resource";
require-instance false;
}
description description
"Compress the alarms with this resource."; "Compress the alarms matching this resource.";
} }
leaf alarm-type-id { leaf alarm-type-id {
type leafref { type leafref {
path "/alarms/alarm-list/alarm/alarm-type-id"; path "/alarms/alarm-list/alarm/alarm-type-id";
require-instance false; require-instance false;
} }
description description
"Compress alarms with this alarm-type-id."; "Compress alarms with this alarm-type-id.";
} }
leaf alarm-type-qualifier { leaf alarm-type-qualifier {
skipping to change at page 48, line 12 skipping to change at page 48, 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'.
7. The X.733 Mapping Module 7. The X.733 Mapping Module
This YANG module references [X.733] and [X.736]. This YANG module references [X.733] and [X.736].
<CODE BEGINS> file "ietf-alarms-x733@2018-10-09.yang" <CODE BEGINS> file "ietf-alarms-x733@2018-11-06.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 48, line 48 skipping to change at page 49, line 12
"This module augments the ietf-alarms module with X.733 alarm "This module augments the ietf-alarms module with X.733 alarm
parameters. parameters.
The following structures are augmented with X.733 event type The following structures are augmented with X.733 event type
and probable cause: and probable cause:
1) alarms/alarm-inventory: all possible alarm types 1) alarms/alarm-inventory: all possible alarm types
2) alarms/alarm-list: every alarm in the system 2) alarms/alarm-list: every alarm in the system
3) alarm-notification: notifications indicating alarm state 3) alarm-notification: notifications indicating alarm state
changes changes
4) alarms/shelved-alarms
The module also optionally allows the alarm management system The module also optionally allows the alarm management system
to configure the mapping from the IETF Alarm module alarm keys to configure the mapping from the IETF Alarm module alarm keys
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.";
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-10-09 { revision 2018-11-06 {
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 71, line 20 skipping to change at page 72, line 20
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
"/alarms/alarm-profile/". "/alarms/alarm-profile/".
Alarm Reporting Control (ARC): alarm shelving "/alarms/control/ Alarm Reporting Control (ARC): alarm shelving "/alarms/control/
alarm-shelving/" and the ability to control alarm notifications alarm-shelving/" and the ability to control alarm notifications
"/alarms/control/notify-status-changes". "/alarms/control/notify-status-changes". Alarm shelving
corresponds to the use case of turning off alarm reporting for a
specific resource, the NALM state in M.3100.
Appendix G. Alarm Usability Requirements Appendix G. Alarm Usability Requirements
This section defines usability requirements for alarms. Alarm This section defines usability requirements for alarms. Alarm
usability is important for an alarm interface. A data-model will usability is important for an alarm interface. A data-model will
help in defining the format but if the actual alarms are of low value help in defining the format but if the actual alarms are of low value
we have not gained the goal of alarm management. we have not gained the goal of alarm management.
Common alarm problems and the cause of the problems are summarized in Common alarm problems and the cause of the problems are summarized in
Table 2. This summary is adopted to networking based on the ISA Table 2. This summary is adopted to networking based on the ISA
 End of changes. 30 change blocks. 
53 lines changed or deleted 77 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/