Hi,
Attached please find the updated ID
draft-ietf-syslog-tc-mib-03.txt
This is a work of the ietf-syslog-wg.
I will appreciate it very much if you can
post this to the archives.
Thanks.
Glenn
Syslog Working Group Glenn Mansfield Keeni
INTERNET-DRAFT Cyber Solutions Inc.
Intended Status: Proposed Standard
Expires: May 10, 2008 November 11, 2007
Textual Conventions for Syslog Management
<draft-ietf-syslog-tc-mib-03.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
[EMAIL PROTECTED]
This Internet-Draft will expire on May 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Glenn M. Keeni. Expires: May 10, 2008 [Page 1]
Internet Draft syslogMIB-TC November 2007
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: May 10, 2008 [Page 2]
Internet Draft syslogMIB-TC November 2007
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 source. Implementations of the
syslog protocol [RFCPROT] 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.
For interoperability and backwards compatibility reasons, the mapping
specified in this document between a label which represents a
Facility or a Severity, and the value which represents the
corresponding code, is normative. So the mapping from a label
configured by operators in syslog.conf or equivalent will
consistently map to the same Facility code regardless of
implementation, but the label itself is often semantically
meaningless, because it is impractical to attempt to enumerate all
Glenn M. Keeni. Expires: May 10, 2008 [Page 3]
Internet Draft syslogMIB-TC November 2007
possible facilities, and the mapping (label and corresponding value)
that is used for an actual facility is, and has historically been,
implementation-dependent.
For example, the foobar application might log messages as having come
from local7, even though there is no "local" process on the device,
and the operator can configure syslog.conf to have local7.critical
messages be relayed, even though there might be multiple facilities
using Facility local7. This is typical current practice, and
originators, relays and collectors know how to handle this situation.
For improved accuracy, the foobar application can also include an
APPNAME Structured Data Element [RFCPROT].
Glenn M. Keeni. Expires: May 10, 2008 [Page 4]
Internet Draft syslogMIB-TC November 2007
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 "200706100000Z" -- 10th June, 2007
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: [EMAIL PROTECTED]
Support Group E-mail: [EMAIL PROTECTED]
"
DESCRIPTION
"The MIB module containing textual conventions for syslog
messages.
Copyright (C) The IETF Trust (2007). 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: May 10, 2008 [Page 5]
Internet Draft syslogMIB-TC November 2007
REVISION "200706100000Z" -- 10th June, 2007
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
-- -------------------------------------------------------------
-- The Facilities and Severities of syslog messages are
-- numerically coded with decimal values.
-- Some of the operating system daemons and processes are
-- traditionally designated by the Facility values given below.
-- Daemons and processes that do not have an explicitly
-- assigned Facility may use any of the "local use" Facilities
-- or they may use the "user-level" Facility.
-- For interoperability and backwards compatibility reasons,
-- mapping specified in this document between a label
-- which represents a Facility or a Severity and the value
-- which represents the corresponding code, is normative.
-- So the mapping from a label configured by operators in
-- syslog.conf or equivalent will consistently map to the
-- same Facility code regardless of implementation, but
-- the label itself is often semantically meaningless,
-- because it is impractical to attempt to enumerate all
-- possible facilities, and the enumeration (label and
-- corresponding value) that is used by an actual facility
-- is, and has historically been, implementation-dependent.
--
Glenn M. Keeni. Expires: May 10, 2008 [Page 6]
Internet Draft syslogMIB-TC November 2007
-- For example, the foobar application might log messages
-- as having come from local7, even though there is no
-- "local" process on the device, and the operator can
-- configure syslog.conf to have local7.critical messages
-- be relayed, even though there might be multiple facilities
-- using Facility local7. This is typical current practice,
-- and originators, relays and collectors know how to handle
-- this situation. For improved accuracy, the foobar
-- application can also include an APPNAME Structured Data
-- Element.
Glenn M. Keeni. Expires: May 10, 2008 [Page 7]
Internet Draft syslogMIB-TC November 2007
SyslogFacility ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This textual convention enumerates the facilities
that originate syslog messages.
"
SYNTAX INTEGER
{
kernel (0), -- kernel messages
user (1), -- user-level messages
mail (2), -- mail system messages
daemon (3), -- system daemons' messages
auth1 (4), -- security/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
cron1 (9), -- clock daemon messages
auth2 (10),-- security/authorization messages
ftp (11),-- ftp daemon messages
ntp (12),-- NTP subsystem messages
logAudit (13),-- log audit messages
logAlert (14),-- log alert 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: May 10, 2008 [Page 8]
Internet Draft syslogMIB-TC November 2007
SyslogSeverity ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This textual convention enumerates the severity levels
of syslog messages.
"
SYNTAX INTEGER
{
emergency (0), -- system is unusable
alert (1), -- action must be taken immediately
critical (2), -- critical condition
error (3), -- error condition
warning (4), -- warning condition
notice (5), -- normal but significant condition
info (6), -- informational message
debug (7) -- debug-level messages
}
END
Glenn M. Keeni. Expires: May 10, 2008 [Page 9]
Internet Draft syslogMIB-TC November 2007
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.
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: May 10, 2008 [Page 10]
Internet Draft syslogMIB-TC November 2007
6. References
6.1 Normative References
[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
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.
[RFCPROT] Gerhards, R., "The syslog Protocol",
draft-ietf-syslog-protocol-21.txt, work in progress,
June 2006.
Note: The string "PROT" 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: May 10, 2008 [Page 11]
Internet Draft syslogMIB-TC November 2007
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: [EMAIL PROTECTED]
Glenn M. Keeni. Expires: May 10, 2008 [Page 12]
Internet Draft syslogMIB-TC November 2007
9. Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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: May 10, 2008 [Page 13]
Internet Draft syslogMIB-TC November 2007
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 [EMAIL PROTECTED]
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Glenn M. Keeni. Expires: May 10, 2008 [Page 14]
Internet Draft syslogMIB-TC November 2007
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-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
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: May 10, 2008 [Page 15]
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
