[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 5427

Syslog Working Group                               Glenn Mansfield Keeni
INTERNET-DRAFT                                      Cyber Solutions Inc.
Intended Status: Proposed Standard
Expires: November 22, 2008                                  May 23, 2008

               Textual Conventions for Syslog Management
                   <draft-ietf-syslog-tc-mib-08.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is a product of the syslog Working Group. Comments
   should be addressed to the authors or the mailing list at
   syslog@ietf.org

   This Internet-Draft will expire on November 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).








Glenn M. Keeni.       Expires: November 22, 2008                [Page 1]

Internet Draft                syslogMIB-TC                      May 2008


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.




Table of Contents

        1. The Internet-Standard Management Framework ....  3
        2. Background ....................................  3
        3. The Syslog Textual Conventions MIB ............  4
        4. Security Considerations .......................  8
        5. IANA Considerations ...........................  8
        6. References ....................................  9
        7  Acknowledgments ............................... 10
        8. Author's Addresses ............................ 10
        9. Full Copyright Statement ...................... 11
           Appendix ...................................... 13

























Glenn M. Keeni.       Expires: November 22, 2008                [Page 2]

Internet Draft                syslogMIB-TC                      May 2008


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 [RFCZZZZ] 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.

   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].








Glenn M. Keeni.       Expires: November 22, 2008                [Page 3]

Internet Draft                syslogMIB-TC                      May 2008


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 "200805230000Z"     --  23rd May, 2008
       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
                      E-mail: glenn@cysols.com

        Support Group E-mail: syslog@ietf.org
        "

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

            Copyright (C) The IETF Trust (2008). This version of
            this MIB module is part of RFC XXXX; see the RFC itself for
            full legal notices.
           "
      -- RFC Ed.: replace XXXX with the actual RFC number & remove this
      -- note












Glenn M. Keeni.       Expires: November 22, 2008                [Page 4]

Internet Draft                syslogMIB-TC                      May 2008


       REVISION "200805230000Z"     --  23rd May, 2008
       DESCRIPTION
           "The initial version, published as RFC XXXX."

      -- RFC Ed.: replace XXXX with the actual RFC number & remove this
      -- note


       ::= { mib-2 YYYY }     -- Will be assigned by IANA

      -- IANA Reg.: Please assign a value for "YYYY" under the
      -- 'mib-2' subtree and record the assignment in the SMI
      -- Numbers registry.

      -- RFC Ed.: When the above assignment has been made, please
      --     remove the above note
      --     replace "YYYY" here with the assigned value and
      --     remove this note.



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
























Glenn M. Keeni.       Expires: November 22, 2008                [Page 5]

Internet Draft                syslogMIB-TC                      May 2008


   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
            a HTTP service. A 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 APPNAME Structured Data Element.

            Note that operating system mechanisms for configuring
            syslog, such as syslog.conf, have not yet been standardized
            and might use different set 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. 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 SNMP contexts,
            even though a particular syslog implementation would use
            a different mapping.
           "
       REFERENCE "The syslog Protocol (RFCZZZZ): Table 1"
       SYNTAX  INTEGER
            {



Glenn M. Keeni.       Expires: November 22, 2008                [Page 6]

Internet Draft                syslogMIB-TC                      May 2008


              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)
            }






















Glenn M. Keeni.       Expires: November 22, 2008                [Page 7]

Internet Draft                syslogMIB-TC                      May 2008


   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 set 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 (RFCZZZZ): 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



Glenn M. Keeni.       Expires: November 22, 2008                [Page 8]

Internet Draft                syslogMIB-TC                      May 2008


            }


   END












































Glenn M. Keeni.       Expires: November 22, 2008                [Page 9]

Internet Draft                syslogMIB-TC                      May 2008


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
   [RFCZZZZ].


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 YYYY }

   IANA Reg.: Please assign a value under the 'mib-2' subtree
              for the 'syslogTCMIB' MODULE-IDENTITY  and record
              the assignment in the SMI Numbers registry.

   RFC Ed.: When the above assignments have been made, please
              - remove the above note
              - replace "YYYY" here with the assigned values and
              - remove this note.
















Glenn M. Keeni.       Expires: November 22, 2008               [Page 10]

Internet Draft                syslogMIB-TC                      May 2008


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., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Structure of Management
            Information Version 2 (SMIv2)", STD 58, RFC 2578,
            April 1999

[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Textual Conventions for
            SMIv2", STD 58, RFC 2579, April 1999

[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Conformance Statements for
            SMIv2", STD 58, RFC 2580, April 1999

[RFCZZZZ]   Gerhards, R., "The syslog Protocol",
            draft-ietf-syslog-protocol-23.txt, work in progress,
            September 2007.

6.2  Informative References

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

Note: The string "ZZZZ" in this
      document will be replaced by the RFC number assigned
      to the latest version of
          draft-ietf-syslog-protocol-*.txt
      and this note will be removed.












Glenn M. Keeni.       Expires: November 22, 2008               [Page 11]

Internet Draft                syslogMIB-TC                      May 2008


7.  Acknowledgments
    This document is a product of the Syslog Working Group.

8.  Author's Addresses

   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



































Glenn M. Keeni.       Expires: November 22, 2008               [Page 12]

Internet Draft                syslogMIB-TC                      May 2008


9.  Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
   RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.
































Glenn M. Keeni.       Expires: November 22, 2008               [Page 13]

Internet Draft                syslogMIB-TC                      May 2008


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to
   rights in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).




















Glenn M. Keeni.       Expires: November 22, 2008               [Page 14]

Internet Draft                syslogMIB-TC                      May 2008


                                APPENDIX


This section documents the development of the draft. It will be
deleted when the draft becomes an RFC.

Revision History:
Changes from draft-ietf-syslog-tc-mib-07.txt
          to draft-ietf-syslog-tc-mib-08.txt
1. Polished the DESCRIPTION clauses of the textual
   conventions.
2. Fixed authPriv -> authpriv

Changes from draft-ietf-syslog-tc-mib-06.txt
          to draft-ietf-syslog-tc-mib-07.txt
1. Aligned the Facility and Severity labels with
   POSIX labels.
2. Added comment to DESCRIPTION of Facility
   textual convention cautioning the user that the
   the label of a Facility in this textual
   convention may not match the corresponding label
   used by some operating system.
3. Editorial nits.

Changes from draft-ietf-syslog-tc-mib-02.txt
          to draft-ietf-syslog-tc-mib-03.txt
1. Moved comments on the Facility and
   Severity TCs to the DESCRIPTION clauses
2. Added text to Severity clause
3. Added REFERENCE clauses
4. Added text to the Security Considerations
   section

Changes from draft-ietf-syslog-tc-mib-01.txt
          to draft-ietf-syslog-tc-mib-02.txt
1. WG stance: The Facility codes are normative.
   - added explanation in the Background part.
   - removed comment in the MIB which said that the
     Facility code is not normative.
2. Added reference RFCPROT.

Changes from draft-ietf-syslog-tc-mib-00.txt
          to draft-ietf-syslog-tc-mib-01.txt

1. Revised the Background section. Added



Glenn M. Keeni.       Expires: November 22, 2008               [Page 15]

Internet Draft                syslogMIB-TC                      May 2008


   The Facility and the Severity codes are commonly used to
   categorize and select received syslog messages for processing and
   display.

2. Revised the comments in the MIB. Added
 -- Facility and Severity values are not normative but often used.
 -- Some of the operating system daemons and processes are
 -- traditionally designated by the Facility values given below.

3. Revised the DESCRIPTION and SYNTAX of SyslogFacility
   Removed the "NoMap    99" enumeration.

4. Removed the reference to Syslog Protocol [RFCPROT].



































Glenn M. Keeni.       Expires: November 22, 2008               [Page 16]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/