RFC 5427
Textual Conventions for Syslog Management
Textual Conventions for Syslog Management 🎀
okay bestie, this is RFC 5427 and it's giving Standards Track 💅 It was written by G. Keeni from Cyber Solutions Inc., it's part of the Network Working Group, it's dated March 2009, and it's all about textual conventions for syslog management. The title block doesn't list anything it obsoletes or updates, so no drama there 🫶
Status of This Memo ✨
ok so this document is an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 🦋 For where this protocol actually stands in terms of standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the memo can be distributed as much as you want, distribution 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 as they're in effect on the date this document was published, which you can find at http://trustee.ietf.org/license-info. Please read these carefully, bestie, because they explain your rights and restrictions for this document 🎀
This document might include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get a proper license from whoever controls that copyright, this document can't be modified outside the IETF Standards Process, and you can't make derivative works of it outside that process either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🧚
Abstract 🍓
This MIB module defines textual conventions to represent Facility and Severity information that's commonly used in syslog messages 🌸 The idea is that these textual conventions get imported and used by MIB modules that would otherwise have to define their own representations ✨
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 .................................................81. The Internet-Standard Management Framework 🌈
if you want the full scoop on the documents that describe the current Internet-Standard Management Framework, check out section 7 of RFC 3410 [RFC3410] 🧚
Managed objects are accessed through a virtual information store called 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 in the Structure of Management Information (SMI). This memo specifies a MIB module that's 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 🌸
so operating systems, processes, and applications (collectively called "Facilities" from here on) generate messages about their own status or about events that happen. These are known as syslog messages 📨 A syslog message will generally contain, among other things, a code for the Facility that generated it and a code for its Severity. Those Facility and Severity codes are commonly used to categorize and select received syslog messages for processing and display 🔥 The Facility codes have been useful for identifying who originated the content of a message, but sometimes they aren't specific enough to pin down the exact originator 🙈 Implementations of the syslog protocol [RFC5424] that include structured data elements (SDEs) should use those SDEs to clarify which entity originated the content of the message. Main character energy for SDEs, honestly ✨
This document defines a set of textual conventions (TCs) that can represent the 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] 🫶
3. The Syslog Textual Conventions MIB ✨
okay bestie, so this section is where the actual MIB module lives 🎀 it's basically a little dictionary of textual conventions for syslog, and the whole thing is written in SMI so it can be plugged into other MIBs. It's giving structured and very precise 💅
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
}
END4. Security Considerations 💀
okay this part is SERIOUS, bestie 😭 the module itself doesn't define any management objects. It only defines textual conventions that other MIB modules can use to define objects. So any real security considerations can only be written in those modules. This document has therefore no impact on the security of the Internet. 🫶
BUT the TCs can introduce security issues once they're used in objects, so anyone using these TCs should read the security considerations section of [RFC5424]. no skipping, periodt 🔥
5. IANA Considerations 🌸
the MIB modules in this doc use the following IANA-assigned OBJECT IDENTIFIER value, recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
syslogTCMIB { mib-2 173 }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, and the author would like to thank Chris Lonvick, David Harrington, Juergen Schoenwaelder, and Pasi Eronen for their comments and suggestions. the squad 👑
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📦 where this page comes from
- ietf: rfc5427 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms