Textual Conventions for Syslog Management
draft-ietf-syslog-tc-mib-08
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5427.
|
|
|---|---|---|---|
| Author | Dr. Glenn Mansfield Keeni | ||
| Last updated | 2015-10-14 (Latest revision 2008-05-22) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5427 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Pasi Eronen | ||
| Send notices to | (None) |
draft-ietf-syslog-tc-mib-08
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]