draft-ietf-opsawg-syslog-alarm-00.txt		draft-ietf-opsawg-syslog-alarm-01.txt
	Network Working Group S. Chisholm		Network Working Group S. Chisholm
	Internet-Draft Nortel		Internet-Draft Nortel
	Intended status: Standards Track R. Gerhards		Intended status: Standards Track R. Gerhards
	Expires: December 21, 2008 Adiscon GmbH		Expires: May 6, 2009 Adiscon GmbH
	June 19, 2008		November 2, 2008
	Alarms in SYSLOG		Alarms in SYSLOG
	draft-ietf-opsawg-syslog-alarm-00.txt		draft-ietf-opsawg-syslog-alarm-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 21, 2008.		This Internet-Draft will expire on May 6, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document describes how to send alarm information in syslog. It		This document describes how to send alarm information in syslog. It
	includes the mapping of ITU perceived severities onto syslog message		includes the mapping of ITU perceived severities onto syslog message
	fields.		fields.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Severity Mapping . . . . . . . . . . . . . . . . . . . . . 3		2. Severity Mapping . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Alarm STRUCTURED-DATA Elements . . . . . . . . . . . . . . . . 4		3. Alarm STRUCTURED-DATA Elements . . . . . . . . . . . . . . . . 5
	2.1. alarmedResource . . . . . . . . . . . . . . . . . . . . . 4		3.1. alarmedResource . . . . . . . . . . . . . . . . . . . . . 5
	2.2. probableCause . . . . . . . . . . . . . . . . . . . . . . 4		3.2. probableCause . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. perceivedSeverity . . . . . . . . . . . . . . . . . . . . 4		3.3. perceivedSeverity . . . . . . . . . . . . . . . . . . . . 5
	2.4. eventType . . . . . . . . . . . . . . . . . . . . . . . . 5		3.4. eventType . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.5. trendIndication . . . . . . . . . . . . . . . . . . . . . 5		3.5. trendIndication . . . . . . . . . . . . . . . . . . . . . 6
	2.6. resourceMapping . . . . . . . . . . . . . . . . . . . . . 5		3.6. resourceMapping . . . . . . . . . . . . . . . . . . . . . 6
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	6.2. Informative References . . . . . . . . . . . . . . . . . . 9		7.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . . . 11		Intellectual Property and Copyright Statements . . . . . . . . . . 12
	1. Introduction		1. Introduction
	In addition to sending out alarm information asynchronously via		In addition to sending out alarm information asynchronously via
	protocols such as SNMP or Netconf, many implementations also log		protocols such as SNMP or Netconf, many implementations also log
	alarms via syslog. This memo defines a set of SD-PARAM to support		alarms via syslog. This memo defines a set of SD-PARAM to support
	logging and defines a mapping of syslog severity to the severity of		logging and defines a mapping of syslog severity to the severity of
	the alarm.		the alarm.
	1.1. terminology		1.1. terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	Alarm related terminology is defined in [RFC3877].		Alarm related terminology is defined in [RFC3877].
	1.2. Severity Mapping		2. Severity Mapping
	The Alarm MIB RFC3877 [RFC3877] defines ITU perceived severities		The Alarm MIB RFC3877 [RFC3877] defines ITU perceived severities
	which are useful to be able to relate to the syslog message fields,		which are useful to be able to relate to the syslog message fields,
	particularly in the case where alarms are being logged. This memo		particularly in the case where alarms are being logged. This memo
	describes the representation of ITU perceived severities in		describes the representation of ITU perceived severities in
	appropriate syslog fields described in [Syslog]. Syslog offers both		appropriate syslog fields described in [Syslog]. Syslog offers both
	a so-called SEVERITY as well as STRUCTURED-DATA. Due to constraints		a so-called SEVERITY as well as STRUCTURED-DATA. Due to constraints
	in syslog, there is no one-to-one mapping possible for SEVERITY. A		in syslog, there is no one-to-one mapping possible for SEVERITY. A
	STRUCTURED-DATA element is defined to allow inclusion of the		STRUCTURED-DATA element is defined to allow inclusion of the
	unmodified ITU perceived severity.		unmodified ITU perceived severity.
	skipping to change at page 4, line 5		skipping to change at page 5, line 5
	ITU Perceived Severity syslog SEVERITY (Name)		ITU Perceived Severity syslog SEVERITY (Name)
	Critical 1 (Alert)		Critical 1 (Alert)
	Major 2 (Critical)		Major 2 (Critical)
	Minor 3 (Error)		Minor 3 (Error)
	Warning 4 (Warning)		Warning 4 (Warning)
	Indeterminate 5 (Notice)		Indeterminate 5 (Notice)
	Cleared 5 (Notice)		Cleared 5 (Notice)
	Table 1. ITUPerceivedSeverity to syslog SEVERITY mapping.		Table 1. ITUPerceivedSeverity to syslog SEVERITY mapping.
	2. Alarm STRUCTURED-DATA Elements		3. Alarm STRUCTURED-DATA Elements
	STRUCTURED-DATA allows to include any structured information into a		STRUCTURED-DATA allows to include any structured information into a
	syslog message. The following are defined to support structuring		syslog message. The following are defined to support structuring
	alarm information.		alarm information.
	o Resource Under Alarm		o Resource Under Alarm
	o Probable Cause		o Probable Cause
	o Event Type		o Event Type
	o Perceived Severity		o Perceived Severity
	o Trend Indication		o Trend Indication
	o Resource Mapping		o Resource Mapping
	Support of the alarm SD-ID is optional, but once supported some of		Support of the alarm SD-ID is optional, but once supported some of
	the SD-PARARMS are mandatory.		the SD-PARARMS are mandatory.
	2.1. alarmedResource		3.1. alarmedResource
	If the alarm SD-ID is supported, the alarmResource SD-PARAM MUST be		If the alarm SD-ID is supported, the alarmResource SD-PARAM MUST be
	supported. This item uniquely identifies the resource under alarm		supported. This item uniquely identifies the resource under alarm
	within the scope of a network element.		within the scope of a network element.
	2.2. probableCause		3.2. probableCause
	If the alarm SD-ID is supported, the probableCause SD-PARAM MUST be		If the alarm SD-ID is supported, the probableCause SD-PARAM MUST be
	supported. This parameter is the mnemonic associated with the		supported. This parameter is the mnemonic associated with the
	IANAItuProbableCause object defined within [RFC3877] and any		IANAItuProbableCause object defined within [RFC3877] and any
	subsequent extensions defined by IANA. For example,		subsequent extensions defined by IANA. For example,
	IANAItuProbableCause defines a transmission failure to a probable		IANAItuProbableCause defines a transmission failure to a probable
	cause of 'transmissionError (10)'. The value of the parameter in		cause of 'transmissionError (10)'. The value of the parameter in
	this case would be 'transmissionError'"		this case would be 'transmissionError'"
	2.3. perceivedSeverity		3.3. perceivedSeverity
	If the alarm SD-ID is supported, the perceivedSeverity SD-PARAM MUST		If the alarm SD-ID is supported, the perceivedSeverity SD-PARAM MUST
	be supported. Similar to the definition of perceived severity in		be supported. Similar to the definition of perceived severity in
	[X.736] and [RFC3877], this object can take the following values:		[X.736] and [RFC3877], this object can take the following values:
	o cleared		o cleared
	o indeterminate		o indeterminate
	o critical		o critical
	o major		o major
	o minor		o minor
	o warning		o warning
	See section X.X for the relationship between this severity and syslog		See section 2 for the relationship between this severity and syslog
	severity.		severity.
	2.4. eventType		3.4. eventType
	If the alarm SD-ID is supported, the eventType SD-PARAM SHOULD be		If the alarm SD-ID is supported, the eventType SD-PARAM SHOULD be
	supported. This parameter is the mnemonic associated with the		supported. This parameter is the mnemonic associated with the
	IANAItuEventType object defined within [RFC3877] and any subsequent		IANAItuEventType object defined within [RFC3877] and any subsequent
	extensions defined by IANA. For example, IANAItuEventType defines a		extensions defined by IANA. For example, IANAItuEventType defines a
	environmental alarm to a event type of 'environmentalAlarm (6)'. The		environmental alarm to a event type of 'environmentalAlarm (6)'. The
	value of the parameter in this case would be 'environmentalAlarm'"		value of the parameter in this case would be 'environmentalAlarm'"
	2.5. trendIndication		3.5. trendIndication
	If the alarm SD-ID is supported, the trendIndication SD-PARAM SHOULD		If the alarm SD-ID is supported, the trendIndication SD-PARAM SHOULD
	be supported. Similar to the definition of perceived severity in		be supported. Similar to the definition of perceived severity in
	[X.733] and [RFC3877], this object can take the following values:		[X.733] and [RFC3877], this object can take the following values:
	o moreSevere		o moreSevere
	o noChange		o noChange
	o lessSevere		o lessSevere
	2.6. resourceMapping		3.6. resourceMapping
	If the alarm SD-ID is supported, the resourceMapping SD-PARAM SHOULD		If the alarm SD-ID is supported, the resourceMapping SD-PARAM SHOULD
	be supported. This item uniquely identifies the resource under alarm		be supported. This item uniquely identifies the resource under alarm
	within the scope of a network element. This must be the same value		within the scope of a network element. This must be the same value
	as alarmActiveResourceId [RFC3877] for this alarm or follow similar		as alarmActiveResourceId [RFC3877] for this alarm or follow similar
	semantics if the Alarm MIB is not supported.		semantics if the Alarm MIB is not supported.
	3. Security Considerations		4. Security Considerations
	In addition to general syslog security considerations discussed in		In addition to general syslog security considerations discussed in
	[Syslog], the information contained with alarms may provide hackers		[Syslog], the information contained with alarms may provide hackers
	with helpful information about parts of the system currently		with helpful information about parts of the system currently
	experiencing stress as well as general information about the system		experiencing stress as well as general information about the system
	such as inventory.		such as inventory.
	Users should not have access to information in alarms that their		Users should not have access to information in alarms that their
	normal access permissions would not permit if the information was		normal access permissions would not permit if the information was
	accessed in another manner.		accessed in another manner.
	4. IANA Considerations		5. IANA Considerations
	IANA is requested to register the SD-IDs and PARAM-NAMEs shown below:		IANA is requested to register the SD-IDs and PARAM-NAMEs shown below:
	SD-ID PARAM-NAME		SD-ID PARAM-NAME
	alarm OPTIONAL		alarm OPTIONAL
	alarmedResource MANDATORY		alarmedResource MANDATORY
	probableCause MANDATORY		probableCause MANDATORY
	perceivedSeverity MANDATORY		perceivedSeverity MANDATORY
	eventType OPTIONAL		eventType OPTIONAL
	trendIndication OPTIONAL		trendIndication OPTIONAL
	resourceMapping OPTIONAL		resourceMapping OPTIONAL
	5. Acknowledgments		6. Acknowledgments
	Thanks to members of the Syslog work group who contributed to this		Thanks to members of the Syslog and OPSAWG work group who contributed
	specification.		to this specification.
	6. References		7. References
	6.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements		[RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements
	Levels", RFC 2119, March 1997.		Levels", RFC 2119, March 1997.
	[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management		[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management
	Information Base (MIB)", RFC 3877, September 2004.		Information Base (MIB)", RFC 3877, September 2004.
	[Syslog] Gerhards, Rainer., "The syslog Protocol",		[Syslog] Gerhards, Rainer., "The syslog Protocol",
	ID draft-ietf-syslog-protocol-19.txt, November 2006.		ID draft-ietf-syslog-protocol-19.txt, November 2006.
	6.2. Informative References		7.2. Informative References
	[X.733] ITU-T, ""Information Technology - Open Systems		[X.733] ITU-T, ""Information Technology - Open Systems
	Interconnection - System Management: Alarm Reporting		Interconnection - System Management: Alarm Reporting
	Function"", ITU-T X.733, 1992.		Function"", ITU-T X.733, 1992.
	[X.736] ITU-T, ""Information Technology - Open Systems		[X.736] ITU-T, ""Information Technology - Open Systems
	Interconnection - System Management: Security Alarm		Interconnection - System Management: Security Alarm
	Reporting Function"", ITU-T X.736, 1992.		Reporting Function"", ITU-T X.736, 1992.
	Authors' Addresses		Authors' Addresses
End of changes. 20 change blocks.
	37 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/