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/