draft-ietf-ccamp-alarm-module-06.txt   draft-ietf-ccamp-alarm-module-07.txt 
Network Working Group S. Vallin Network Working Group S. Vallin
Internet-Draft Stefan Vallin AB Internet-Draft Stefan Vallin AB
Intended status: Standards Track M. Bjorklund Intended status: Standards Track M. Bjorklund
Expires: May 26, 2019 Cisco Expires: August 1, 2019 Cisco
November 22, 2018 January 28, 2019
YANG Alarm Module YANG Alarm Module
draft-ietf-ccamp-alarm-module-06 draft-ietf-ccamp-alarm-module-07
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 May 26, 2019. This Internet-Draft will expire on August 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Identifying the Alarming Resource . . . . . . . . . . . . 7 3.3. Identifying the Alarming Resource . . . . . . . . . . . . 8
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
3.7. Alarm Shelving . . . . . . . . . . . . . . . . . . . . . 11 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.7. Alarm Shelving . . . . . . . . . . . . . . . . . . . . . 12
3.8. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 12 3.8. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 12
4. Alarm Data Model . . . . . . . . . . . . . . . . . . . . . . 12 4. Alarm Data Model . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Alarm Control . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Alarm Control . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Alarm Shelving . . . . . . . . . . . . . . . . . . . 14 4.1.1. Alarm Shelving . . . . . . . . . . . . . . . . . . . 14
4.2. Alarm Inventory . . . . . . . . . . . . . . . . . . . . . 14 4.2. Alarm Inventory . . . . . . . . . . . . . . . . . . . . . 15
4.3. Alarm Summary . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Alarm Summary . . . . . . . . . . . . . . . . . . . . . . 15
4.4. The Alarm List . . . . . . . . . . . . . . . . . . . . . 16 4.4. The Alarm List . . . . . . . . . . . . . . . . . . . . . 16
4.5. The Shelved Alarms List . . . . . . . . . . . . . . . . . 18 4.5. The Shelved Alarms List . . . . . . . . . . . . . . . . . 18
4.6. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 18 4.6. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 18
4.7. Operations . . . . . . . . . . . . . . . . . . . . . . . 19 4.7. Operations . . . . . . . . . . . . . . . . . . . . . . . 19
4.8. Notifications . . . . . . . . . . . . . . . . . . . . . . 19 4.8. Notifications . . . . . . . . . . . . . . . . . . . . . . 19
5. Relationship to the ietf-hardware YANG module . . . . . . . . 19 5. Relationship to the ietf-hardware YANG module . . . . . . . . 19
6. Alarm YANG Module . . . . . . . . . . . . . . . . . . . . . . 20 6. Alarm YANG Module . . . . . . . . . . . . . . . . . . . . . . 20
7. X.733 Extensions . . . . . . . . . . . . . . . . . . . . . . 50 7. X.733 Extensions . . . . . . . . . . . . . . . . . . . . . . 51
8. The X.733 Mapping Module . . . . . . . . . . . . . . . . . . 51 8. The X.733 Mapping Module . . . . . . . . . . . . . . . . . . 51
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
10. Security Considerations . . . . . . . . . . . . . . . . . . . 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 64
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 65
12.1. Normative References . . . . . . . . . . . . . . . . . . 64 12.1. Normative References . . . . . . . . . . . . . . . . . . 65
12.2. Informative References . . . . . . . . . . . . . . . . . 65 12.2. Informative References . . . . . . . . . . . . . . . . . 66
Appendix A. Vendor-specific Alarm-Types Example . . . . . . . . 66 Appendix A. Vendor-specific Alarm-Types Example . . . . . . . . 67
Appendix B. Alarm Inventory Example . . . . . . . . . . . . . . 67 Appendix B. Alarm Inventory Example . . . . . . . . . . . . . . 68
Appendix C. Alarm List Example . . . . . . . . . . . . . . . . . 68 Appendix C. Alarm List Example . . . . . . . . . . . . . . . . . 69
Appendix D. Alarm Shelving Example . . . . . . . . . . . . . . . 69 Appendix D. Alarm Shelving Example . . . . . . . . . . . . . . . 70
Appendix E. X.733 Mapping Example . . . . . . . . . . . . . . . 70 Appendix E. X.733 Mapping Example . . . . . . . . . . . . . . . 71
Appendix F. Relationship to other alarm standards . . . . . . . 71 Appendix F. Relationship to other alarm standards . . . . . . . 72
F.1. Alarm definition . . . . . . . . . . . . . . . . . . . . 71 F.1. Alarm definition . . . . . . . . . . . . . . . . . . . . 72
F.2. Data model . . . . . . . . . . . . . . . . . . . . . . . 73 F.2. Data model . . . . . . . . . . . . . . . . . . . . . . . 74
F.2.1. X.733 . . . . . . . . . . . . . . . . . . . . . . . . 73 F.2.1. X.733 . . . . . . . . . . . . . . . . . . . . . . . . 74
F.2.2. RFC 3877, the Alarm MIB . . . . . . . . . . . . . . . 73 F.2.2. RFC 3877, the Alarm MIB . . . . . . . . . . . . . . . 74
F.2.3. 3GPP Alarm IRP . . . . . . . . . . . . . . . . . . . 74 F.2.3. 3GPP Alarm IRP . . . . . . . . . . . . . . . . . . . 75
F.2.4. G.7710 . . . . . . . . . . . . . . . . . . . . . . . 74 F.2.4. G.7710 . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix G. Alarm Usability Requirements . . . . . . . . . . . . 74 Appendix G. Alarm Usability Requirements . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79
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 10, line 50 skipping to change at page 11, line 7
in the alarm list. in the alarm list.
Alarms can be compressed. Compressing an alarm deletes all entries Alarms can be compressed. Compressing an alarm deletes all entries
in the alarm's "status-change" list except for the last status in the alarm's "status-change" list except for the last status
change. A client can perform this using the "compress-alarms" change. A client can perform this using the "compress-alarms"
action. The server may also perform these operations based on other action. The server may also perform these operations based on other
policies, but how that is done is out of scope for this document. policies, but how that is done is out of scope for this document.
3.6. Root Cause, Impacted Resources and Related Alarms 3.6. Root Cause, Impacted Resources and Related Alarms
The alarm module does not mandate any requirements for the system to
support alarm correlation or root-cause and service-impact analysis.
However, if such features are supported, this section describes how
the results of such analysis are represented in the data model.
These parts of the model are optional. The module supports three
scenarios:
Root cause analysis: An alarm can indicate candidate root cause
resources, for example: a database issue alarm referring to a full
disc partition.
Service impact analysis: An alarm can refer to potential impacted
resources, for example: an interface alarm referring to impacted
network services
Alarm correlation: Dependencies between alarms, several alarms can
be grouped as relating to each other, for example a streaming
media alarm relating to a high jitter alarm.
Different systems have various degrees of alarm correlation and
analysis capabilities, and the intent of the alarm module is to
enable any capability, including none.
The general principle of this alarm module is to limit the amount of The general principle of this alarm module is to limit the amount of
alarms. In many cases several resources are affected for a given alarms. In many cases several resources are affected for a given
underlying problem. A full disk will of course impact databases and underlying problem. A full disk will of course impact databases and
applications as well. The recommendation is not have a single alarm applications as well. The recommendation is to have a single alarm
for the underlying problem an 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 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.
skipping to change at page 12, line 5 skipping to change at page 12, line 33
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 this 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. alarms do not generate notifications but the shelved alarm list is
updated with any alarm state changes.
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.
skipping to change at page 14, line 24 skipping to change at page 14, line 24
The length of this list is controlled by "/alarms/control/max-alarm- The length of this list is controlled by "/alarms/control/max-alarm-
status-changes". status-changes".
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
+--rw alarm-type-id? alarm-type-id +--rw alarm-type*
+--rw alarm-type-qualifier-match? string | [alarm-type-id alarm-type-qualifier-match]
+--rw description? string | +--rw alarm-type-id alarm-type-id
| +--rw alarm-type-qualifier-match string
+--rw description? string
Shelved alarms are shown in a dedicated shelved alarm list. The Shelved alarms are shown in a dedicated shelved alarm list. The
instrumentation MUST move shelved alarms from the alarm list instrumentation MUST move shelved alarms from the alarm list
(/alarms/alarm-list) to the shelved alarm list (/alarms/shelved- (/alarms/alarm-list) to the shelved alarm list (/alarms/shelved-
alarms/). Shelved alarms do not generate any notifications. When alarms/). Shelved alarms do not generate any notifications. When
the shelving criteria is removed or changed the alarm list MUST be the shelving criteria is removed or changed the alarm list MUST be
updated to the correct actual state of the alarms. updated to the correct actual state of the alarms.
Shelving and unshelving can only be performed by editing the shelf Shelving and unshelving can only be performed by editing the shelf
configuration. It cannot be performed on individual alarms. The configuration. It cannot be performed on individual alarms. The
server will add an operator state indicating that the alarm was server will add an operator state indicating that the alarm was
shelved/unshelved. shelved/unshelved.
A leaf (/alarms/summary/shelfs-active) in the alarm summary indicates A leaf (/alarms/summary/shelves-active) in the alarm summary
if there are shelved alarms. indicates if there are shelved alarms.
A system can select to not support the shelving feature. A system can select to not support the shelving feature.
4.2. Alarm Inventory 4.2. Alarm Inventory
The alarm inventory represents all possible alarm types that may The alarm inventory represents all possible alarm types that may
occur in the system. A management system may use this to build alarm occur in the system. A management system may use this to build alarm
procedures. The alarm inventory is relevant for several reasons: procedures. The alarm inventory is relevant for several reasons:
The system might not instrument all defined alarm type identities, The system might not instrument all defined alarm type identities,
skipping to change at page 16, line 41 skipping to change at page 16, line 41
+--ro alarm-list +--ro alarm-list
+--ro number-of-alarms? yang:gauge32 +--ro number-of-alarms? yang:gauge32
+--ro last-changed? yang:date-and-time +--ro last-changed? yang:date-and-time
+--ro alarm* [resource alarm-type-id alarm-type-qualifier] +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
| +--ro resource resource | +--ro resource resource
| +--ro alarm-type-id alarm-type-id | +--ro alarm-type-id alarm-type-id
| +--ro alarm-type-qualifier alarm-type-qualifier | +--ro alarm-type-qualifier alarm-type-qualifier
| +--ro alt-resource* resource | +--ro alt-resource* resource
| +--ro related-alarm* | +--ro related-alarm*
| | [resource alarm-type-id alarm-type-qualifier] | | [resource alarm-type-id alarm-type-qualifier]
| | {alarm-correlation}?
| | +--ro resource | | +--ro resource
| | | -> /alarms/alarm-list/alarm/resource | | | -> /alarms/alarm-list/alarm/resource
| | +--ro alarm-type-id leafref | | +--ro alarm-type-id leafref
| | +--ro alarm-type-qualifier leafref | | +--ro alarm-type-qualifier leafref
| +--ro impacted-resource* resource | +--ro impacted-resource* resource
| | {service-impact-analysis}?
| +--ro root-cause-resource* resource | +--ro root-cause-resource* resource
| | {root-cause-analysis}?
| +--ro time-created yang:date-and-time | +--ro time-created yang:date-and-time
| +--ro is-cleared boolean | +--ro is-cleared boolean
| +--ro last-raised yang:date-and-time | +--ro last-raised yang:date-and-time
| +--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
skipping to change at page 17, line 25 skipping to change at page 17, line 28
| | +---w input | | +---w input
| | +---w state writable-operator-state | | +---w state writable-operator-state
| | +---w text? string | | +---w text? string
| +---n operator-action {operator-actions}? | +---n operator-action {operator-actions}?
| +-- time yang:date-and-time | +-- time yang:date-and-time
| +-- operator string | +-- operator string
| +-- state operator-state | +-- state operator-state
| +-- text? string | +-- text? string
+---x purge-alarms +---x purge-alarms
| +---w input | +---w input
| | +---w alarm-status enumeration | | +---w alarm-clearance-status enumeration
| | +---w older-than! | | +---w older-than!
| | | +---w (age-spec)? | | | +---w (age-spec)?
| | | +--:(seconds) | | | +--:(seconds)
| | | | +---w seconds? uint16 | | | | +---w seconds? uint16
| | | +--:(minutes) | | | +--:(minutes)
| | | | +---w minutes? uint16 | | | | +---w minutes? uint16
| | | +--:(hours) | | | +--:(hours)
| | | | +---w hours? uint16 | | | | +---w hours? uint16
| | | +--:(days) | | | +--:(days)
| | | | +---w days? uint16 | | | | +---w days? uint16
skipping to change at page 20, line 20 skipping to change at page 20, 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@2018-11-22.yang" <CODE BEGINS> file "ietf-alarms@2019-01-27.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.";
} }
organization organization
"IETF CCAMP Working Group"; "IETF CCAMP Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/ccamp> "WG Web: <http://tools.ietf.org/wg/ccamp>
WG List: <mailto:ccamp@ietf.org> WG List: <mailto:ccamp@ietf.org>
Editor: Stefan Vallin Editor: Stefan Vallin
<mailto:stefan@wallan.se> <mailto:stefan@wallan.se>
skipping to change at page 22, line 29 skipping to change at page 22, line 31
closed) closed)
Administrative actions like removing closed alarms older than a Administrative actions like removing closed alarms older than a
given time is supported. given time is supported.
This alarm module does not define how the underlying This alarm module does not define how the underlying
instrumentation detects and clears the specific alarms. That instrumentation detects and clears the specific alarms. That
belongs to the SDO or enterprise that owns that specific belongs to the SDO or enterprise that owns that specific
technology. technology.
Copyright (c) 2018 IETF Trust and the persons identified as The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in the module text are to be interpreted
as described in BCP 14 [RFC 2119] [RFC8174] when, and only when,
they appear in all capitals, as shown here.
This version of this YANG module is part of RFC XXXX 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 2018-11-22 {
revision 2010-01-27 {
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
states on alarms."; states on alarms.";
skipping to change at page 23, line 50 skipping to change at page 24, line 4
description description
"The system supports clients to configure further information "The system supports clients to configure further information
to each alarm type."; to each alarm type.";
} }
feature severity-assignment { feature severity-assignment {
description description
"The system supports configurable alarm severity levels."; "The system supports configurable alarm severity levels.";
reference reference
"M.3160/M.3100 Alarm Severity Assignment Profile, ASAP"; "M.3160/M.3100 Alarm Severity Assignment Profile, ASAP";
}
feature root-cause-analysis {
description
"The system supports identifying candidate root-cause
resources for an alarm, for example a disc partition
root cause for a logger failure alarm.";
}
feature service-impact-analysis {
description
"The system supports identifiying candidate impacted
resources for an alarm, for exampla a link being impacted
by an interface alarm.";
} }
feature alarm-correlation {
description
"The system supports correlating/grouping alarms
that belong together.";
}
/* /*
* Identities * Identities
*/ */
identity alarm-type-id { identity alarm-type-id {
description description
"Base identity for alarm types. A unique identification of the "Base identity for alarm types. A unique identification of the
alarm, not including the resource. Different resources can alarm, not including the resource. Different resources can
share alarm types. If the resource reports the same alarm share alarm types. If the resource reports the same alarm
type, it is to be considered to be the same alarm. The alarm type, it is to be considered to be the same alarm. The alarm
skipping to change at page 25, line 12 skipping to change at page 25, line 34
If the resource is an SNMP object, the type will be an If the resource is an SNMP object, the type will be an
object-identifier. object-identifier.
If the resource is anything else, for example a distinguished If the resource is anything else, for example a distinguished
name or a CIM path, this type will be a string. name or a CIM path, this type will be a string.
If the alarming object is identified by a UUID use the uuid If the alarming object is identified by a UUID use the uuid
type. Be cautious when using this type, since a UUID is hard type. Be cautious when using this type, since a UUID is hard
to use for an operator. to use for an operator.
If the server supports several models, the presedence should If the server supports several models, the precedence should
be in the order as given in the union definition."; be in the order as given in the union definition.";
} }
typedef resource-match { typedef resource-match {
type union { type union {
type yang:xpath1.0; type yang:xpath1.0;
type yang:object-identifier; type yang:object-identifier;
type string; type string;
} }
description description
skipping to change at page 26, line 51 skipping to change at page 27, line 26
} }
typedef severity { typedef severity {
type enumeration { type enumeration {
enum indeterminate { enum indeterminate {
value 2; value 2;
description description
"Indicates that the severity level could not be "Indicates that the severity level could not be
determined. This level SHOULD be avoided."; determined. This level SHOULD be avoided.";
} }
enum minor { enum warning {
value 3; value 3;
description description
"The 'warning' severity level indicates the detection of a
potential or impending service affecting fault, before any
significant effects have been felt. Action should be
taken to further diagnose (if necessary) and correct the
problem in order to prevent it from becoming a more
serious service affecting fault.";
}
enum minor {
value 4;
description
"The 'minor' severity level indicates the existence of a "The 'minor' severity level indicates the existence of a
non-service affecting fault condition and that corrective non-service affecting fault condition and that corrective
action should be taken in order to prevent a more serious action should be taken in order to prevent a more serious
(for example, service affecting) fault. Such a severity (for example, service affecting) fault. Such a severity
can be reported, for example, when the detected alarm can be reported, for example, when the detected alarm
condition is not currently degrading the capacity of the condition is not currently degrading the capacity of the
resource."; resource.";
} }
enum warning {
value 4;
description
"The 'warning' severity level indicates the detection of a
potential or impending service affecting fault, before any
significant effects have been felt. Action should be
taken to further diagnose (if necessary) and correct the
problem in order to prevent it from becoming a more
serious service affecting fault.";
}
enum major { enum major {
value 5; value 5;
description description
"The 'major' severity level indicates that a service "The 'major' severity level indicates that a service
affecting condition has developed and an urgent corrective affecting condition has developed and an urgent corrective
action is required. Such a severity can be reported, for action is required. Such a severity can be reported, for
example, when there is a severe degradation in the example, when there is a severe degradation in the
capability of the resource and its full capability must be capability of the resource and its full capability must be
restored."; restored.";
} }
skipping to change at page 30, line 43 skipping to change at page 31, line 19
case, and this leaf is the empty string."; case, and this leaf is the empty string.";
} }
leaf-list alt-resource { leaf-list alt-resource {
type resource; type resource;
description description
"Used if the alarming resource is available over other "Used if the alarming resource is available over other
interfaces. This field can contain SNMP OID's, CIM paths or interfaces. This field can contain SNMP OID's, CIM paths or
3GPP Distinguished names for example."; 3GPP Distinguished names for example.";
} }
list related-alarm { list related-alarm {
if-feature "alarm-correlation";
key "resource alarm-type-id alarm-type-qualifier"; key "resource alarm-type-id alarm-type-qualifier";
description description
"References to related alarms. Note that the related alarm "References to related alarms. Note that the related alarm
might have been purged from the alarm list."; might have been purged from the alarm list.";
leaf resource { leaf resource {
type leafref { type leafref {
path "/alarms/alarm-list/alarm/resource"; path "/alarms/alarm-list/alarm/resource";
require-instance false; require-instance false;
} }
description description
skipping to change at page 31, line 27 skipping to change at page 32, line 4
leaf alarm-type-qualifier { leaf alarm-type-qualifier {
type leafref { type leafref {
path "/alarms/alarm-list/alarm" path "/alarms/alarm-list/alarm"
+ "[resource=current()/../resource]" + "[resource=current()/../resource]"
+ "[alarm-type-id=current()/../alarm-type-id]" + "[alarm-type-id=current()/../alarm-type-id]"
+ "/alarm-type-qualifier"; + "/alarm-type-qualifier";
require-instance false; require-instance false;
} }
description description
"The alarm qualifier for the related alarm."; "The alarm qualifier for the related alarm.";
} }
} }
leaf-list impacted-resource { leaf-list impacted-resource {
if-feature "service-impact-analysis";
type resource; type resource;
description description
"Resources that might be affected by this alarm. If the "Resources that might be affected by this alarm. If the
system creates an alarm on a resource and also has a mapping system creates an alarm on a resource and also has a mapping
to other resources that might be impacted, these resources to other resources that might be impacted, these resources
can be listed in this leaf-list. In this way the system can can be listed in this leaf-list. In this way the system can
create one alarm instead of several. For example, if an create one alarm instead of several. For example, if an
interface has an alarm, the 'impacted-resource' can interface has an alarm, the 'impacted-resource' can
reference the aggregated port channels."; reference the aggregated port channels.";
} }
leaf-list root-cause-resource { leaf-list root-cause-resource {
if-feature "root-cause-analysis";
type resource; type resource;
description description
"Resources that are candidates for causing the alarm. If the "Resources that are candidates for causing the alarm. If the
system has a mechanism to understand the candidate root system has a mechanism to understand the candidate root
causes of an alarm, this leaf-list can be used to list the causes of an alarm, this leaf-list can be used to list the
root cause candidate resources. In this way the system can root cause candidate resources. In this way the system can
create one alarm instead of several. An example might be a create one alarm instead of several. An example might be a
logging system (alarm resource) that fails, the alarm can logging system (alarm resource) that fails, the alarm can
reference the file-system in the 'root-cause-resource' reference the file-system in the 'root-cause-resource'
leaf-list. Note that the intended use is not to also send leaf-list. Note that the intended use is not to also send
skipping to change at page 35, line 4 skipping to change at page 35, line 31
state change. state change.
The following state changes creates an entry in this The following state changes creates an entry in this
list: list:
- changed severity (warning, minor, major, critical) - changed severity (warning, minor, major, critical)
- clearance status, this also updates the 'is-cleared' - clearance status, this also updates the 'is-cleared'
leaf leaf
- alarm text update"; - alarm text update";
uses alarm-state-change-parameters; uses alarm-state-change-parameters;
} }
} }
grouping filter-input { grouping filter-input {
description description
"Grouping to specify a filter construct on alarm information."; "Grouping to specify a filter construct on alarm information.";
leaf alarm-status { leaf alarm-clearance-status {
type enumeration { type enumeration {
enum any { enum any {
description description
"Ignore alarm clearance status."; "Ignore alarm clearance status.";
} }
enum cleared { enum cleared {
description description
"Filter cleared alarms."; "Filter cleared alarms.";
} }
enum not-cleared { enum not-cleared {
skipping to change at page 38, line 50 skipping to change at page 39, line 28
type severity; type severity;
description description
"Only send notifications for alarm state changes crossing "Only send notifications for alarm state changes crossing
the specified level. Always send clear notifications."; 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 server will move any alarms (block/filter) alarms. The first matching shelf is used,
corresponding to the shelving criteria from the and an alarm is shelved only for this first match.
The server will move any alarms corresponding to the
shelving criteria from the
alarms/alarm-list/alarm list to the alarms/alarm-list/alarm list to the
alarms/shelved-alarms/shelved-alarm list. It will also alarms/shelved-alarms/shelved-alarm list. It will also
stop sending notifications for the shelved alarms. The stop sending notifications for the shelved alarms. The
conditions in the shelf criteria are logically ANDed. conditions in the shelf criteria are logically ANDed.
When the shelving criteria is deleted or changed, the When the shelving criteria is deleted or changed, the
non-matching alarms MUST appear in the non-matching alarms MUST appear in the
alarms/alarm-list/alarm list according to the real state. alarms/alarm-list/alarm list according to the real state.
This means that the instrumentation MUST maintain states This means that the instrumentation MUST maintain states
for the shelved alarms. Alarms that match the criteria for the shelved alarms. Alarms that match the criteria
shall have an operator-state 'shelved'. When the shelf shall have an operator-state 'shelved'. When the shelf
configuration removes an alarm from the shelf the configuration removes an alarm from the shelf the
server shall add an operator state 'unshelved'."; server shall add an operator state 'unshelved'.";
list shelf { list shelf {
key "name"; key "name";
ordered-by user;
leaf name { leaf name {
type string; type string;
description description
"An arbitrary name for the alarm shelf."; "An arbitrary name for the alarm shelf.";
} }
description description
"Each entry defines the criteria for shelving alarms. "Each entry defines the criteria for shelving alarms.
Criteria are ANDed. If no criteria are specified, Criteria are ANDed. If no criteria are specified,
all alarms will be shelved."; all alarms will be shelved.";
leaf-list resource { leaf-list resource {
type resource-match; type resource-match;
description description
"Shelve alarms for matching resources."; "Shelve alarms for matching resources.";
} }
skipping to change at page 39, line 32 skipping to change at page 40, line 15
} }
description description
"Each entry defines the criteria for shelving alarms. "Each entry defines the criteria for shelving alarms.
Criteria are ANDed. If no criteria are specified, Criteria are ANDed. If no criteria are specified,
all alarms will be shelved."; all alarms will be shelved.";
leaf-list resource { leaf-list resource {
type resource-match; type resource-match;
description description
"Shelve alarms for matching resources."; "Shelve alarms for matching resources.";
} }
leaf alarm-type-id { list alarm-type {
type alarm-type-id; key "alarm-type-id alarm-type-qualifier-match";
description
"Shelve all alarms that have an alarm-type-id that is
equal to or derived from the given alarm-type-id.";
}
leaf alarm-type-qualifier-match {
type string;
description description
"A W3C regular expression that is used to match an "Any alarm matching the combined criteria of
alarm type qualifier. Shelve all alarms that matches alarm-type-id and alarm-type-qualifier-match
this regular expression for the alarm type MUST be matched.";
qualifier."; leaf alarm-type-id {
type alarm-type-id;
description
"Shelve all alarms that have an alarm-type-id that is
equal to or derived from the given alarm-type-id.";
}
leaf alarm-type-qualifier-match {
type string;
description
"A W3C regular expression that is used to match an
alarm type qualifier. Shelve all alarms that
matches this regular expression for the alarm type
qualifier.";
}
} }
leaf description { leaf description {
type string; type string;
description description
"An optional textual description of the shelf. This "An optional textual description of the shelf. This
description should include the reason for shelving description should include the reason for shelving
these alarms."; these alarms.";
} }
} }
} }
} }
container alarm-inventory { container alarm-inventory {
config false; config false;
description description
"This alarm-inventory/alarm-type list contains all possible "This alarm-inventory/alarm-type list contains all possible
alarm types for the system. alarm types for the system.
skipping to change at page 51, line 12 skipping to change at page 51, line 48
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@2018-11-22.yang" <CODE BEGINS> file "ietf-alarms-x733@2019-01-27.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;
reference "RFC 6991: Common YANG Data Types"; reference
"RFC 6991: Common YANG Data Types";
} }
organization organization
"IETF CCAMP Working Group"; "IETF CCAMP Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/ccamp> "WG Web: <http://tools.ietf.org/wg/ccamp>
WG List: <mailto:ccamp@ietf.org> WG List: <mailto:ccamp@ietf.org>
Editor: Stefan Vallin Editor: Stefan Vallin
<mailto:stefan@wallan.se> <mailto:stefan@wallan.se>
skipping to change at page 52, line 15 skipping to change at page 53, line 5
The mapping does not include a corresponding X.733 specific The mapping does not include a corresponding X.733 specific
problem value. The recommendation is to use the problem value. The recommendation is to use the
'alarm-type-qualifier' leaf which serves the same purpose. 'alarm-type-qualifier' leaf which serves the same purpose.
The module uses an integer and a corresponding string for The module uses an integer and a corresponding string for
probable cause instead of a globally defined enumeration, in probable cause instead of a globally defined enumeration, in
order to be able to manage conflicting enumeration definitions. order to be able to manage conflicting enumeration definitions.
A single globally defined enumeration is challenging to A single globally defined enumeration is challenging to
maintain. maintain.
Copyright (c) 2018 IETF Trust and the persons identified as The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in the module text are to be interpreted
as described in BCP 14 [RFC 2119] [RFC8174] when, and only when,
they appear in all capitals, as shown here.
This version of this YANG module is part of RFC XXXX 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 2018-11-22 { revision 2019-01-27 {
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 {
description description
"The system supports configurable X733 mapping from "The system supports configurable X733 mapping from
the IETF alarm module alarm-type to X733 event-type the IETF alarm module alarm-type to X733 event-type
skipping to change at page 63, line 23 skipping to change at page 64, line 13
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
[RFC5246]. [RFC8446].
The NETCONF access control model [RFC6536] provides the means to The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. 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
skipping to change at page 64, line 39 skipping to change at page 65, line 34
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008, <https://www.rfc-editor.org/info/
rfc5246>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, DOI
10.17487/RFC6536, March 2012, <https://www.rfc-
editor.org/info/rfc6536>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC
6991, DOI 10.17487/RFC6991, July 2013, 6991, DOI 10.17487/RFC6991, July 2013,
<http://www.rfc-editor.org/info/rfc6991>. <http://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<http://www.rfc-editor.org/info/rfc7950>. <http://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>. <http://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, DOI 10.17487/
RFC8341, March 2018, <https://www.rfc-editor.org/info/
rfc8341>.
[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
YANG Data Model for Hardware Management", RFC 8348, DOI YANG Data Model for Hardware Management", RFC 8348, DOI
10.17487/RFC8348, March 2018, <https://www.rfc- 10.17487/RFC8348, March 2018, <https://www.rfc-
editor.org/info/rfc8348>. editor.org/info/rfc8348>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[X.721] International Telecommunications Union, "Information [X.721] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - Structure of Technology - Open Systems Interconnection - Structure of
management information: Definition of management management information: Definition of management
information", ITU-T Recommendation X.721, 1992. information", ITU-T Recommendation X.721, 1992.
[X.733] International Telecommunications Union, "Information [X.733] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - Systems Technology - Open Systems Interconnection - Systems
Management: Alarm Reporting Function", ITU-T Management: Alarm Reporting Function", ITU-T
Recommendation X.733, 1992. Recommendation X.733, 1992.
skipping to change at page 70, line 18 skipping to change at page 71, line 18
<control> <control>
<alarm-shelving> <alarm-shelving>
<shelf> <shelf>
<name>FE10</name> <name>FE10</name>
<resource> <resource>
/dev:interfaces/dev:interface[name='FastEthernet1/0'] /dev:interfaces/dev:interface[name='FastEthernet1/0']
</resource> </resource>
</shelf> </shelf>
<shelf> <shelf>
<name>detectortest</name> <name>detectortest</name>
<alarm-type-id>xyz-al:environmental-alarm</alarm-type-id> <alarm-type>
<alarm-type-qualifier-match> <alarm-type-id>
smoke-alarm xyz-al:environmental-alarm
</alarm-type-qualifier-match> </alarm-type-id>
<alarm-type-qualifier-match>
smoke-alarm
</alarm-type-qualifier-match>
</alarm-type>
</shelf> </shelf>
</alarm-shelving> </alarm-shelving>
</control> </control>
</alarms> </alarms>
Appendix E. X.733 Mapping Example Appendix E. X.733 Mapping Example
This example shows how to map a dynamic alarm type (alarm-type- This example shows how to map a dynamic alarm type (alarm-type-
identity=environmental-alarm, alarm-type-qualifier=smoke-alarm) to identity=environmental-alarm, alarm-type-qualifier=smoke-alarm) to
the corresponding X.733 event-type and probable cause parameters. the corresponding X.733 event-type and probable cause parameters.
 End of changes. 57 change blocks. 
110 lines changed or deleted 182 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/