< draft-ietf-syslog-protocol-22.txt		draft-ietf-syslog-protocol-23.txt >
	syslog Working Group R. Gerhards		syslog Working Group R. Gerhards
	Internet-Draft Adiscon GmbH		Internet-Draft Adiscon GmbH
	Obsoletes: 3164 (if approved) August 20, 2007		Obsoletes: 3164 (if approved) September 5, 2007
	Intended status: Standards Track		Intended status: Standards Track
	Expires: February 21, 2008		Expires: March 8, 2008
	The syslog Protocol		The syslog Protocol
	draft-ietf-syslog-protocol-22		draft-ietf-syslog-protocol-23
	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 February 21, 2008.		This Internet-Draft will expire on March 8, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes the syslog protocol, which is used to convey		This document describes the syslog protocol, which is used to convey
	event notification messages. This protocol utilizes a layered		event notification messages. This protocol utilizes a layered
	architecture, which allows the use of any number of transport		architecture, which allows the use of any number of transport
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions Used in This Document . . . . . . . . . . . . . . 4		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Basic Principles . . . . . . . . . . . . . . . . . . . . . . . 5		4. Basic Principles . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Example Deployment Scenarios . . . . . . . . . . . . . . . 6		4.1. Example Deployment Scenarios . . . . . . . . . . . . . . . 6
	5. Transport Layer Protocol . . . . . . . . . . . . . . . . . . . 8		5. Transport Layer Protocol . . . . . . . . . . . . . . . . . . . 8
	5.1. Minimum Required Transport Mapping . . . . . . . . . . . . 8		5.1. Minimum Required Transport Mapping . . . . . . . . . . . . 8
	6. Syslog Message Format . . . . . . . . . . . . . . . . . . . . 8		6. Syslog Message Format . . . . . . . . . . . . . . . . . . . . 8
	6.1. Message Length . . . . . . . . . . . . . . . . . . . . . . 9		6.1. Message Length . . . . . . . . . . . . . . . . . . . . . . 10
	6.2. HEADER . . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.2. HEADER . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.2.1. PRI . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.2.1. PRI . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.2.2. VERSION . . . . . . . . . . . . . . . . . . . . . . . 12		6.2.2. VERSION . . . . . . . . . . . . . . . . . . . . . . . 12
	6.2.3. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 12		6.2.3. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 12
	6.2.4. HOSTNAME . . . . . . . . . . . . . . . . . . . . . . . 13		6.2.4. HOSTNAME . . . . . . . . . . . . . . . . . . . . . . . 13
	6.2.5. APP-NAME . . . . . . . . . . . . . . . . . . . . . . . 14		6.2.5. APP-NAME . . . . . . . . . . . . . . . . . . . . . . . 14
	6.2.6. PROCID . . . . . . . . . . . . . . . . . . . . . . . . 15		6.2.6. PROCID . . . . . . . . . . . . . . . . . . . . . . . . 15
	6.2.7. MSGID . . . . . . . . . . . . . . . . . . . . . . . . 15		6.2.7. MSGID . . . . . . . . . . . . . . . . . . . . . . . . 15
	6.3. STRUCTURED-DATA . . . . . . . . . . . . . . . . . . . . . 15		6.3. STRUCTURED-DATA . . . . . . . . . . . . . . . . . . . . . 15
	6.3.1. SD-ELEMENT . . . . . . . . . . . . . . . . . . . . . . 16		6.3.1. SD-ELEMENT . . . . . . . . . . . . . . . . . . . . . . 16
	skipping to change at page 3, line 21 ¶		skipping to change at page 3, line 21 ¶
	7.3.2. sysUpTime . . . . . . . . . . . . . . . . . . . . . . 25		7.3.2. sysUpTime . . . . . . . . . . . . . . . . . . . . . . 25
	7.3.3. language . . . . . . . . . . . . . . . . . . . . . . . 25		7.3.3. language . . . . . . . . . . . . . . . . . . . . . . . 25
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 25		8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	8.1. UNICODE . . . . . . . . . . . . . . . . . . . . . . . . . 25		8.1. UNICODE . . . . . . . . . . . . . . . . . . . . . . . . . 25
	8.2. Control Characters . . . . . . . . . . . . . . . . . . . . 25		8.2. Control Characters . . . . . . . . . . . . . . . . . . . . 25
	8.3. Message Truncation . . . . . . . . . . . . . . . . . . . . 26		8.3. Message Truncation . . . . . . . . . . . . . . . . . . . . 26
	8.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 27		8.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	8.5. Reliable Delivery . . . . . . . . . . . . . . . . . . . . 27		8.5. Reliable Delivery . . . . . . . . . . . . . . . . . . . . 27
	8.6. Congestion Control . . . . . . . . . . . . . . . . . . . . 28		8.6. Congestion Control . . . . . . . . . . . . . . . . . . . . 28
	8.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 28		8.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 28
	8.8. Message Observation . . . . . . . . . . . . . . . . . . . 28		8.8. Message Observation . . . . . . . . . . . . . . . . . . . 29
	8.9. Inappropriate Configuration . . . . . . . . . . . . . . . 29		8.9. Inappropriate Configuration . . . . . . . . . . . . . . . 29
	8.10. Forwarding Loop . . . . . . . . . . . . . . . . . . . . . 29		8.10. Forwarding Loop . . . . . . . . . . . . . . . . . . . . . 29
	8.11. Load Considerations . . . . . . . . . . . . . . . . . . . 29		8.11. Load Considerations . . . . . . . . . . . . . . . . . . . 30
	8.12. Denial of Service . . . . . . . . . . . . . . . . . . . . 30		8.12. Denial of Service . . . . . . . . . . . . . . . . . . . . 30
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	9.1. VERSION . . . . . . . . . . . . . . . . . . . . . . . . . 30		9.1. VERSION . . . . . . . . . . . . . . . . . . . . . . . . . 30
	9.2. SD-IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 30		9.2. SD-IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	10. Working Group . . . . . . . . . . . . . . . . . . . . . . . . 31		10. Working Group . . . . . . . . . . . . . . . . . . . . . . . . 32
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
	12. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 32		12. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 32
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 32		13.1. Normative References . . . . . . . . . . . . . . . . . . . 32
	13.2. Informative References . . . . . . . . . . . . . . . . . . 33		13.2. Informative References . . . . . . . . . . . . . . . . . . 34
	Appendix A. implementer Guidelines . . . . . . . . . . . . . . . 33		Appendix A. implementer Guidelines . . . . . . . . . . . . . . . 34
	A.1. Relationship with BSD Syslog . . . . . . . . . . . . . . . 33		A.1. Relationship with BSD Syslog . . . . . . . . . . . . . . . 34
	A.2. Message Length . . . . . . . . . . . . . . . . . . . . . . 35		A.2. Message Length . . . . . . . . . . . . . . . . . . . . . . 35
	A.3. Severity Values . . . . . . . . . . . . . . . . . . . . . 35		A.3. Severity Values . . . . . . . . . . . . . . . . . . . . . 36
	A.4. TIME-SECFRAC Precision . . . . . . . . . . . . . . . . . . 36		A.4. TIME-SECFRAC Precision . . . . . . . . . . . . . . . . . . 37
	A.5. Case Convention for Names . . . . . . . . . . . . . . . . 36		A.5. Case Convention for Names . . . . . . . . . . . . . . . . 37
	A.6. Syslog Applications Without Knowledge of Time . . . . . . 36		A.6. Syslog Applications Without Knowledge of Time . . . . . . 37
	A.7. Notes on the timeQuality SD-ID . . . . . . . . . . . . . . 37		A.7. Notes on the timeQuality SD-ID . . . . . . . . . . . . . . 37
	A.8. UTF-8 encoding and the BOM . . . . . . . . . . . . . . . . 37		A.8. UTF-8 encoding and the BOM . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	This document describes a layered architecture for syslog. The goal		This document describes a layered architecture for syslog. The goal
	of this architecture is to separate message content from message		of this architecture is to separate message content from message
	transport while enabling easy extensibility for each layer.		transport while enabling easy extensibility for each layer.
	This document describes the standard format for syslog messages and		This document describes the standard format for syslog messages and
	outlines the concept of transport mappings. It also describes		outlines the concept of transport mappings. It also describes
	structured data elements, which can be used to transmit easily		structured data elements, which can be used to transmit easily
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 12 ¶
	|+----------+|		|+----------+|
	+------------+		+------------+
	Diagram 2. Some possible syslog deployment scenarios.		Diagram 2. Some possible syslog deployment scenarios.
	5. Transport Layer Protocol		5. Transport Layer Protocol
	This document does not specify any transport layer protocol.		This document does not specify any transport layer protocol.
	Instead, it describes the format of a syslog message in a transport		Instead, it describes the format of a syslog message in a transport
	layer independent way. Syslog transports are defined in other		layer independent way. Syslog transports are defined in other
	documents. The first transport is defined in [RFCXXXX] and is		documents. The first transport is defined in
	consistent with the traditional UDP transport. This transport is		[I-D.ietf-syslog-transport-udp] and is consistent with the
	needed to maintain interoperability as the UDP transport has		traditional UDP transport. This transport is needed to maintain
	historically been used for the transmission of syslog messages.		interoperability as the UDP transport has historically been used for
			the transmission of syslog messages.
	Any syslog transport protocol MUST NOT deliberately alter the syslog		Any syslog transport protocol MUST NOT deliberately alter the syslog
	message. If the transport protocol needs to perform temporary		message. If the transport protocol needs to perform temporary
	transformations at the transport sender, these transformations MUST		transformations at the transport sender, these transformations MUST
	be reversed by the transport protocol at the transport receiver, so		be reversed by the transport protocol at the transport receiver, so
	that relay or collector will see an exact copy of the message		that relay or collector will see an exact copy of the message
	generated by the originator or relay. Otherwise end-to-end		generated by the originator or relay. Otherwise end-to-end
	cryptographic verifiers (such as signatures) will be broken. Of		cryptographic verifiers (such as signatures) will be broken. Of
	course, message alteration might occur due to transmission errors or		course, message alteration might occur due to transmission errors or
	other problems. Guarding against such alterations is not within the		other problems. Guarding against such alterations is not within the
	scope of this document.		scope of this document.
	5.1. Minimum Required Transport Mapping		5.1. Minimum Required Transport Mapping
	All implementations of this specification MUST support a TLS-based		All implementations of this specification MUST support a TLS-based
	transport as described in [RFCZZZZ].		transport as described in [I-D.ietf-syslog-transport-tls].
	All implementations of this specification SHOULD also support a UDP-		All implementations of this specification SHOULD also support a UDP-
	based transport as described in [RFCXXXX].		based transport as described in [I-D.ietf-syslog-transport-udp].
			It is RECOMMENDED that implementations of this specification use the
			TLS-based transport.
	6. Syslog Message Format		6. Syslog Message Format
	The syslog message has the following ABNF [RFC4234] definition:		The syslog message has the following ABNF [RFC4234] definition:
	SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]		SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG]
	HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME		HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME
	SP APP-NAME SP PROCID SP MSGID		SP APP-NAME SP PROCID SP MSGID
	PRI = "<" PRIVAL ">"		PRI = "<" PRIVAL ">"
	skipping to change at page 28, line 11 ¶		skipping to change at page 28, line 11 ¶
	way that intentionally discards messages when the syslog application		way that intentionally discards messages when the syslog application
	would otherwise block. The advantage of reliable delivery in this		would otherwise block. The advantage of reliable delivery in this
	case is that the syslog originator or relay knowingly discards the		case is that the syslog originator or relay knowingly discards the
	message and is able to notify the relay or collector about that fact.		message and is able to notify the relay or collector about that fact.
	So the relay or collector receives the information that something is		So the relay or collector receives the information that something is
	lost. With unreliable delivery, the message would simply be lost		lost. With unreliable delivery, the message would simply be lost
	without any indication that loss occurred.		without any indication that loss occurred.
	8.6. Congestion Control		8.6. Congestion Control
	If the potentially unrestricted use of syslog data being transferred		Because syslog can generate unlimited amounts of data, transferring
	over UDP in a particular deployment can saturate the link, then the		this data over UDP is generally problematic, because UDP lacks
	network path should be provisioned so the offered load (including		congestion control mechanisms. Congestion control mechanisms that
	syslog packets) does not exceed the path capacity. Otherwise, some		respond to congestion by reducing traffic rates and establish a
	of the syslog packets could be lost, or cause the loss of other UDP		degree of fairness between flows that share the same path are vital
	IP packets.		to the stable operation of the Internet [RFC2914]. This is why the
			syslog TLS transport is REQUIRED to implement and RECOMMENDED for
			general use.
			The only environments where the syslog UDP transport MAY be used as
			an alternative to the TLS transport are managed networks, where the
			network path has been explicitly provisioned for UDP syslog traffic
			through traffic engineering mechanisms, such as rate limiting or
			capacity reservations. In all other environments, the TLS transport
			SHOULD be used.
	In any implementation, the situation may arise in which an originator		In any implementation, the situation may arise in which an originator
	or relay would need to block sending messages. A common case is when		or relay would need to block sending messages. A common case is when
	an internal queue is full. This might happen due to rate-limiting or		an internal queue is full. This might happen due to rate-limiting or
	slow performance of the syslog application. In any event, it is		slow performance of the syslog application. In any event, it is
	highly RECOMMENDED that no messages be dropped but that they should		highly RECOMMENDED that no messages be dropped but that they should
	be temporarily stored until they can be transmitted. However, if		be temporarily stored until they can be transmitted. However, if
	they must be dropped, it is RECOMMENDED that the originator or relay		they must be dropped, it is RECOMMENDED that the originator or relay
	drop messages of lower severity in favor of higher severity messages.		drop messages of lower severity in favor of higher severity messages.
	Messages with a lower numberical SEVERITY value have a higher		Messages with a lower numberical SEVERITY value have a higher
	skipping to change at page 32, line 18 ¶		skipping to change at page 32, line 34 ¶
	Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David		Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David
	Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado		Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado
	Colussi, Clement Mathieu, Didier Dalmasso, and all other people who		Colussi, Clement Mathieu, Didier Dalmasso, and all other people who
	commented on various versions of this proposal.		commented on various versions of this proposal.
	12. Notes to the RFC Editor		12. Notes to the RFC Editor
	This is a note to the RFC editor. This ID is submitted along with		This is a note to the RFC editor. This ID is submitted along with
	draft-ietf-syslog-transport-udp and draft-ietf-syslog-transport-tls.		draft-ietf-syslog-transport-udp and draft-ietf-syslog-transport-tls.
	These documents cross-reference each other. When RFC numbers are		These documents cross-reference each other. When RFC numbers are
	determined for each of these IDs, replace XXXX with the proper RFC		determined for each of these IDs, replace ietf-syslog-transport-udp
	number for draft-ietf-syslog-transport-udp and replace ZZZZ with the		with the proper RFC number for draft-ietf-syslog-transport-udp and
	proper RFC number for draft-ietf-syslog-transport-tls and remove this		replace I-D.ietf-syslog-transport-tls with the proper RFC number for
	note.		draft-ietf-syslog-transport-tls and remove this note.
	This document uses the term "RFCYYYY" for self-references. When a		This document uses the term "RFCYYYY" for self-references. When a
	RFC number is assigned to it, replace YYYY with the proper RFC number		RFC number is assigned to it, replace YYYY with the proper RFC number
	and remove this note.		and remove this note.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[ANSI.X3-4.1968] American National Standards Institute, "USA Code		[ANSI.X3-4.1968] American National Standards
	for Information Interchange", ANSI X3.4, 1968.		Institute, "USA Code for Information
			Interchange", ANSI X3.4, 1968.
	[RFC1034] Mockapetris, P., "Domain names - concepts and		[RFC1034] Mockapetris, P., "Domain names -
	facilities", STD 13, RFC 1034, November 1987.		concepts and facilities", STD 13,
			RFC 1034, November 1987.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names -
	specification", STD 13, RFC 1035, November 1987.		implementation and specification",
			STD 13, RFC 1035, November 1987.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in
	Requirement Levels", BCP 14, RFC 2119, March 1997.		RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119,
			March 1997.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a
	10646", STD 63, RFC 3629, November 2003.		transformation format of ISO 10646",
			STD 63, RFC 3629, November 2003.
	[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for		[RFC4234] Crocker, D., Ed. and P. Overell,
	Syntax Specifications: ABNF", RFC 4234,		"Augmented BNF for Syntax
	October 2005.		Specifications: ABNF", RFC 4234,
			October 2005.
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the		[RFC3339] Klyne, G. and C. Newman, "Date and
	Internet: Timestamps", RFC 3339, July 2002.		Time on the Internet: Timestamps",
			RFC 3339, July 2002.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for		[RFC2434] Narten, T. and H. Alvestrand,
	Writing an IANA Considerations Section in RFCs",		"Guidelines for Writing an IANA
	BCP 26, RFC 2434, October 1998.		Considerations Section in RFCs",
			BCP 26, RFC 2434, October 1998.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC2914] Floyd, S., "Congestion Control
	Architecture", RFC 4291, February 2006.		Principles", BCP 41, RFC 2914,
			September 2000.
	[RFC3418] Presuhn, R., "Management Information Base (MIB) for		[RFC4291] Hinden, R. and S. Deering, "IP
	the Simple Network Management Protocol (SNMP)",		Version 6 Addressing Architecture",
	STD 62, RFC 3418, December 2002.		RFC 4291, February 2006.
	[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying		[RFC3418] Presuhn, R., "Management Information
	Languages", BCP 47, RFC 4646, September 2006.		Base (MIB) for the Simple Network
			Management Protocol (SNMP)", STD 62,
			RFC 3418, December 2002.
	[UNICODE-TR36] Davis, M. and M. Suignard, "UNICODE Security		[RFC4646] Phillips, A. and M. Davis, "Tags for
	Considerations", July 2005,		Identifying Languages", BCP 47,
	<http://www.unicode.org/reports/tr36/tr36-3.html>.		RFC 4646, September 2006.
	[RFCXXXX] Okmianski, A., "Transmission of syslog messages		[UNICODE-TR36] Davis, M. and M. Suignard, "UNICODE
	over UDP", RFC XXXX, November 2006.		Security Considerations", July 2005,
			<http://www.unicode.org/reports/
			tr36/tr36-3.html>.
	[RFCZZZZ] Miao, F. and M. Yuzhi, "TLS Transport Mapping for		[I-D.ietf-syslog-transport-udp] Okmianski, A., "Transmission of
	SYSLOG", RFC ZZZZ, August 2006.		syslog messages over UDP",
			draft-ietf-syslog-transport-udp-10
			(work in progress), August 2007.
			[I-D.ietf-syslog-transport-tls] Miao, F. and Y. Ma, "TLS Transport
			Mapping for Syslog",
			draft-ietf-syslog-transport-tls-10
			(work in progress), May 2007.
	13.2. Informative References		13.2. Informative References
	[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,		[RFC3164] Lonvick, C., "The BSD Syslog
	August 2001.		Protocol", RFC 3164, August 2001.
	Appendix A. implementer Guidelines		Appendix A. implementer Guidelines
	Information in this section is given as an aid to implementers.		Information in this section is given as an aid to implementers.
	While this information is considered to be helpful, it is not		While this information is considered to be helpful, it is not
	normative. As such, an implementation is NOT REQUIRED to follow it		normative. As such, an implementation is NOT REQUIRED to follow it
	in order to claim compliance to this specification.		in order to claim compliance to this specification.
	A.1. Relationship with BSD Syslog		A.1. Relationship with BSD Syslog
End of changes. 31 change blocks.
	67 lines changed or deleted		101 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/