SYSLOG-TC-MIB DEFINITIONS ::= BEGIN

IMPORTS
	MODULE-IDENTITY,
	mib-2
		FROM SNMPv2-SMI		-- [RFC2578]
	TEXTUAL-CONVENTION
		FROM SNMPv2-TC;

-- [RFC2579]

syslogTCMIB MODULE-IDENTITY
	LAST-UPDATED "200903300000Z"	-- Mar 30, 2009 12:00:00 AM
	ORGANIZATION "IETF Syslog Working Group"
	CONTACT-INFO
		"Glenn Mansfield Keeni
		             Postal: Cyber Solutions Inc.
		                     6-6-3, Minami Yoshinari
		                     Aoba-ku, Sendai, Japan 989-3204.
		                Tel: +81-22-303-4012
		                Fax: +81-22-303-4015
		              EMail: glenn@cysols.com

		Support Group EMail: syslog@ietf.org

		"
	DESCRIPTION
		"The MIB module containing textual conventions for syslog
		messages.

		Copyright (c) 2009 IETF Trust and the persons
		identified as authors of the code.  All rights reserved.

		Redistribution and use in source and binary forms, with or
		without modification, are permitted provided that the
		following conditions are met:

		- Redistributions of source code must retain the above
		  copyright notice, this list of conditions and the
		  following disclaimer.

		- Redistributions in binary form must reproduce the above
		  copyright notice, this list of conditions and the
		  following disclaimer in the documentation and/or other
		  materials provided with the distribution.





		- Neither the name of Internet Society, IETF or IETF
		  Trust, nor the names of specific contributors, may be
		  used to endorse or promote products derived from this
		  software without specific prior written permission.

		THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
		CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
		WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
		WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
		PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
		OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
		INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
		(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
		GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
		BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
		LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
		(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
		OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
		POSSIBILITY OF SUCH DAMAGE.

		This version of this MIB module is part of RFC 5427;
		see the RFC itself for full legal notices.

		"
	REVISION "200903300000Z"	-- Mar 30, 2009 12:00:00 AM
	DESCRIPTION
		"The initial version, published as RFC 5427."
	-- 1.3.6.1.2.1.173
	::= { mib-2 173 }


-- -------------------------------------------------------------
-- Textual Conventions
-- -------------------------------------------------------------

SyslogFacility ::= TEXTUAL-CONVENTION
	STATUS  current
	DESCRIPTION
		"This textual convention enumerates the Facilities that
		originate syslog messages.

		The Facilities of syslog messages are numerically coded
		with decimal values.  For interoperability and backwards-
		compatibility reasons, this document specifies a
		normative mapping between a label, which represents a
		Facility, and the corresponding numeric value.  This label
		could be used in, for example, SNMP Manager user
		interfaces.






		The label itself is often semantically meaningless
		because it is impractical to attempt to enumerate all
		possible Facilities, and many daemons and processes do
		not have an explicitly assigned Facility code or label.
		For example, there is no Facility label corresponding to
		an HTTP service.  An HTTP service implementation might log
		messages as coming from, for example, 'local7' or 'uucp'.
		This is typical current practice, and originators, relays,
		and collectors can be configured to properly handle this
		situation.  For improved accuracy, an application can also
		include an APP-NAME structured data element.

		Note that operating system mechanisms for configuring
		syslog, such as syslog.conf, have not yet been standardized
		and might use different sets of Facility labels and/or
		mapping between Facility labels and Facility codes than the
		MIB.

		In particular, the labels corresponding to Facility codes 4,
		10, 13, and 14, and the code corresponding to the Facility
		label 'cron' are known to vary across different operating
		systems.  To distinguish between the labels corresponding
		to Facility codes 9 and 15, a label of 'cron2' is assigned
		to the Facility code 15.  This list is not intended to be
		exhaustive; other differences might exist, and new
		differences might be introduced in the future.

		The mapping specified here MUST be used in a MIB network
		management interface, even though a particular syslog
		implementation might use a different mapping in a
		different network management interface.

		"
	REFERENCE
		"The Syslog Protocol (RFC5424): Table 1"
	SYNTAX INTEGER {
			kern(0),      	-- kernel messages
			user(1),      	-- user-level messages
			mail(2),      	-- mail system messages
			daemon(3),    	-- system daemons' messages
			auth(4),      	-- authorization messages
			syslog(5),    	-- messages generated internally by
				            -- syslogd
			lpr(6),       	-- line printer subsystem messages
			news(7),      	-- network news subsystem messages
			uucp(8),      	-- UUCP subsystem messages
			cron(9),      	-- clock daemon messages
			authpriv(10), 	-- security/authorization messages
			ftp(11),      	-- ftp daemon messages
			ntp(12),      	-- NTP subsystem messages
			audit(13),    	-- audit messages
			console(14),  	-- console messages
			cron2(15),    	-- clock daemon messages
			local0(16),
			local1(17),
			local2(18),
			local3(19),
			local4(20),
			local5(21),
			local6(22),
			local7(23) }


SyslogSeverity ::= TEXTUAL-CONVENTION
	STATUS  current
	DESCRIPTION
		"This textual convention enumerates the Severity levels
		of syslog messages.

		The Severity levels of syslog messages are numerically
		coded with decimal values.  For interoperability and
		backwards-compatibility reasons, this document specifies
		a normative mapping between a label, which represents a
		Severity level, and the corresponding numeric value.
		This label could be used in, for example, SNMP Manager
		user interfaces.

		The label itself is often semantically meaningless
		because it is impractical to attempt to strictly define
		the criteria for each Severity level, and the criteria
		that is used by syslog originators is, and has
		historically been, implementation-dependent.

		Note that operating system mechanisms for configuring
		syslog, such as syslog.conf, have not yet been standardized
		and might use different sets of Severity labels and/or
		mapping between Severity labels and Severity codes than the
		MIB.

		For example, the foobar application might log messages as
		'crit' based on some subjective criteria.  Yet the operator
		can configure syslog to forward these messages, even though
		the criteria for 'crit' may differ from one originator to
		another.  This is typical current practice, and originators,
		relays, and collectors can be configured to properly handle
		this situation.





		"
	REFERENCE
		"The Syslog Protocol (RFC5424): Table 2"
	SYNTAX INTEGER {
			emerg(0),   	-- emergency; system is unusable
			alert(1),   	-- action must be taken immediately
			crit(2),    	-- critical condition
			err(3),     	-- error condition
			warning(4), 	-- warning condition
			notice(5),  	-- normal but significant condition
			info(6),    	-- informational message
			debug(7)   	-- debug-level messages
			}


END
