GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5427

Network Working Group G. Keeni Request for Comments: 5427 Cyber Solutions Inc. Category: Standards Track March 2009

             Textual Conventions for Syslog Management

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (c) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents in effect on the date of
 publication of this document (http://trustee.ietf.org/license-info).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Abstract

 This MIB module defines textual conventions to represent Facility and
 Severity information commonly used in syslog messages.  The intent is
 that these textual conventions will be imported and used in MIB
 modules that would otherwise define their own representations.

Keeni Standards Track [Page 1] RFC 5427 Syslog MIB-TC March 2009

Table of Contents

 1. The Internet-Standard Management Framework ......................2
 2. Background ......................................................2
 3. The Syslog Textual Conventions MIB ..............................3
 4. Security Considerations .........................................7
 5. IANA Considerations .............................................7
 6. References ......................................................8
    6.1. Normative References .......................................8
    6.2. Informative References .....................................8
 7. Acknowledgments .................................................8

1. The Internet-Standard Management Framework

 For a detailed overview of the documents that describe the current
 Internet-Standard Management Framework, please refer to section 7 of
 RFC 3410 [RFC3410].
 Managed objects are accessed via a virtual information store, termed
 the Management Information Base or MIB.  MIB objects are generally
 accessed through the Simple Network Management Protocol (SNMP).
 Objects in the MIB are defined using the mechanisms defined in the
 Structure of Management Information (SMI).  This memo specifies a MIB
 module that is compliant to the SMIv2, which is described in STD 58,
 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
 [RFC2580].

2. Background

 Operating systems, processes, and applications, collectively termed
 "Facilities" in the following, generate messages indicating their own
 status or the occurrence of events.  These messages have come to be
 known as syslog messages.  A syslog message in general will contain
 among other things a code representing the Facility that generated
 the message and a code representing the Severity of the message.  The
 Facility and the Severity codes are commonly used to categorize and
 select received syslog messages for processing and display.  The
 Facility codes have been useful in qualifying the originator of the
 content of the messages but in some cases they are not specific
 enough to explicitly identify the originator.  Implementations of the
 syslog protocol [RFC5424] that contain structured data elements
 (SDEs) should use these SDEs to clarify the entity that originated
 the content of the message.
 This document defines a set of textual conventions (TCs) that can be
 used to represent Facility and Severity codes commonly used in syslog
 messages.

Keeni Standards Track [Page 2] RFC 5427 Syslog MIB-TC March 2009

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

3. The Syslog Textual Conventions MIB

 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:
  1. Redistributions of source code must retain the above

copyright notice, this list of conditions and the

            following disclaimer.
  1. 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.

Keeni Standards Track [Page 3] RFC 5427 Syslog MIB-TC March 2009

  1. 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 }
  1. - ————————————————————-
  2. - Textual Conventions
  3. - ————————————————————-
 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.

Keeni Standards Track [Page 4] RFC 5427 Syslog MIB-TC March 2009

          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

Keeni Standards Track [Page 5] RFC 5427 Syslog MIB-TC March 2009

            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.

Keeni Standards Track [Page 6] RFC 5427 Syslog MIB-TC March 2009

         "
     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

4. Security Considerations

 This module does not define any management objects.  Instead, it
 defines a set of textual conventions which may be used by other MIB
 modules to define management objects.  Meaningful security
 considerations can only be written in the MIB modules that define
 management objects.  This document has therefore no impact on the
 security of the Internet.  Since objects defined using the TCs
 defined in this document may introduce security issues, the user of
 these TCs should read the security considerations section of
 [RFC5424].

5. IANA Considerations

 The MIB modules in this document use the following IANA-assigned
 OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
 Descriptor        OBJECT IDENTIFIER value
 ----------        -----------------------
 syslogTCMIB       { mib-2 173 }

Keeni Standards Track [Page 7] RFC 5427 Syslog MIB-TC March 2009

6. References

6.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
            "Structure of Management Information Version 2 (SMIv2)",
            STD 58, RFC 2578, April 1999.
 [RFC2579]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
            "Textual Conventions for SMIv2", STD 58, RFC 2579, April
            1999.
 [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
            "Conformance Statements for SMIv2", STD 58, RFC 2580,
            April 1999.
 [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.

6.2. Informative References

 [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
            "Introduction and Applicability Statements for Internet-
            Standard Management Framework", RFC 3410, December 2002.

7. Acknowledgments

 This document is a product of the Syslog Working Group.  The author
 would like to thank Chris Lonvick, David Harrington, Juergen
 Schoenwaelder, and Pasi Eronen for their comments and suggestions.

Author's Address

 Glenn Mansfield Keeni
 Cyber Solutions Inc.
 6-6-3 Minami Yoshinari
 Aoba-ku, Sendai 989-3204
 Japan
 Phone: +81-22-303-4012
 EMail: glenn@cysols.com

Keeni Standards Track [Page 8]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5427.txt · Last modified: 2009/03/31 18:32 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki