   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"     --  30 March 2009
       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"     --  30 March 2009
       DESCRIPTION
           "The initial version, published as RFC 5427."

       ::= { 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
