rfc-5427

Textual Conventions for Syslog Management

G. Keeni
date2009-03 streamIETF areasec wgsyslog statusPROPOSED STANDARD pages8 canonicalhttps://www.rfc-editor.org/rfc/rfc5427 doi10.17487/RFC5427
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. [STANDARDS-TRACK]

Extracted elements (10)

design-rationale §3

Severity labels in SyslogSeverity are noted as semantically meaningless because the criteria for each level are and have historically been implementation-dependent. Originators, relays, and collectors must be configured to handle varying severity interpretations across implementations.

syslog

design-rationale §3

The SyslogFacility TC was designed for use in SNMP Manager user interfaces, providing a stable normative mapping even though OS syslog.conf files may vary. The label 'cron2' was introduced specifically to distinguish between the two facility codes (9 and 15) that both represent clock daemon messages in different implementations.

syslog, snmp

interoperability-note §3

Facility labels are often semantically meaningless because it is impractical to enumerate all possible facilities; many daemons have no explicitly assigned facility code. For improved accuracy, applications should include an APP-NAME structured data element (per RFC 5424) to clarify the originating entity.

syslog

interoperability-note §3

Facility labels for codes 4, 10, 13, and 14 and the label 'cron' are known to vary across different operating systems. To disambiguate codes 9 and 15, RFC 5427 assigns the label 'cron2' to facility code 15. OS syslog.conf mechanisms are not standardized and may use different label sets or mappings than the MIB.

syslog, snmp

normative-requirement §3 MUST

The label-to-numeric mapping specified in SyslogFacility MUST be used in a MIB network management interface, even if a particular syslog implementation uses a different mapping in a different network management interface.

syslog, snmp

protocol-element §3

SYSLOG-TC-MIB defines two textual conventions — SyslogFacility and SyslogSeverity — for use by other MIB modules managing syslog data, assigned OID mib-2 173. The intent is that MIB modules import these TCs rather than defining their own representations.

syslog, snmp, registry

protocol-element §3

SyslogFacility is a TEXTUAL-CONVENTION enumerating 24 facility codes (0–23): kern(0), user(1), mail(2), daemon(3), auth(4), syslog(5), lpr(6), news(7), uucp(8), cron(9), authpriv(10), ftp(11), ntp(12), audit(13), console(14), cron2(15), local0–local7(16–23). It provides a normative label-to-numeric mapping for use in SNMP management interfaces.

syslog, snmp

protocol-element §3

SyslogSeverity is a TEXTUAL-CONVENTION enumerating 8 severity levels (0–7): emerg(0), alert(1), crit(2), err(3), warning(4), notice(5), info(6), debug(7). It provides a normative label-to-numeric mapping for SNMP management interfaces, referencing RFC 5424 Table 2.

syslog, snmp

registry §5

RFC 5427 registers the syslogTCMIB module with OBJECT IDENTIFIER value { mib-2 173 } in the IANA SMI Numbers registry.

syslog, snmp, registry

security-consideration §4

The SYSLOG-TC-MIB module defines no management objects, only textual conventions, so it has no direct impact on Internet security. However, MIB modules that use these TCs to define management objects may introduce security issues; users of these TCs should consult the security considerations of RFC 5424.

syslog, snmp, security