Network Working Group V. Marinov
Request for Comments: 5675 J. Schoenwaelder
Category: Standards Track Jacobs University Bremen
October 2009
Network Working Group V. Marinov
Request for Comments: 5675 J. Schoenwaelder
Category: Standards Track Jacobs University Bremen
October 2009
Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages
将简单网络管理协议（SNMP）通知映射到系统日志消息
Abstract
摘要
This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages.
此备忘录定义了从简单网络管理协议（SNMP）通知到系统日志消息的映射。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3
2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5
3. Mapping SNMP Notifications to SYSLOG Messages . . . . . . . . 5
3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7
3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Relationship to the SYSLOG-MSG-MIB . . . . . . . . . . . . . . 10
5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3
2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5
3. Mapping SNMP Notifications to SYSLOG Messages . . . . . . . . 5
3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7
3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Relationship to the SYSLOG-MSG-MIB . . . . . . . . . . . . . . 10
5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
SNMP and SYSLOG are two widely used protocols to communicate event notifications. Although co-existence of several management protocols in one operational environment is possible, certain environments require that all event notifications be collected by a single system daemon, such as a SYSLOG collector or an SNMP notification receiver, via a single management protocol. In such environments, it is necessary to translate event notifications between management protocols.
SNMP和SYSLOG是两种广泛用于通信事件通知的协议。虽然在一个操作环境中可以同时存在多个管理协议，但某些环境要求所有事件通知都由单个系统守护程序（如SYSLOG收集器或SNMP通知接收器）通过单个管理协议收集。在这样的环境中，有必要在管理协议之间转换事件通知。
The latest version of SYSLOG, specified in [RFC5424], supports a structured data element format. Structured data elements allow us to map between SNMP notifications and SYSLOG messages without losing information. In this memo, we specify a concrete mapping from SNMP event notifications [RFC3416] into SYSLOG messages [RFC5424]. We specify how the SYSLOG message format should be utilized to carry the information contained in an SNMP notification message. A new SYSLOG structured data element is defined, which carries the PDU portion of an SNMP notification message.
[RFC5424]中指定的最新版本的SYSLOG支持结构化数据元素格式。结构化数据元素允许我们在SNMP通知和系统日志消息之间进行映射，而不会丢失信息。在本备忘录中，我们指定了从SNMP事件通知[RFC3416]到系统日志消息[RFC5424]的具体映射。我们指定应如何使用SYSLOG消息格式来传输SNMP通知消息中包含的信息。定义了一个新的SYSLOG结构化数据元素，它承载SNMP通知消息的PDU部分。
A system that has the capability of receiving SNMP notification messages from an SNMP notification originator and sending the SNMP data contained inside in a SYSLOG message format to a SYSLOG collector is referred to in this memo as an "SNMP-to-SYSLOG translator". By definition, such a system should have an SNMP
能够从SNMP通知发起人接收SNMP通知消息并将系统日志消息格式中包含的SNMP数据发送到系统日志收集器的系统在本备忘录中称为“SNMP到系统日志转换器”。根据定义，这样的系统应该具有SNMP
notification receiver application and a SYSLOG originator running in order to be able to perform the functions of an "SNMP-to-SYSLOG translator".
通知接收器应用程序和系统日志发起者运行，以便能够执行“SNMP到系统日志转换器”的功能。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
A detailed introduction to the SNMP Management Framework can be found in [RFC3410]. The SNMP Management Architecture is described in [RFC3411]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB [RFC3418]. Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI) [RFC2578].
有关SNMP管理框架的详细介绍，请参见[RFC3410]。[RFC3411]中描述了SNMP管理体系结构。托管对象通过虚拟信息存储（称为管理信息库或MIB[RFC3418]）进行访问。MIB中的对象是使用管理信息结构（SMI）[RFC2578]中定义的机制定义的。
An SNMP notification message is generated and transmitted by an SNMP entity on behalf of a notification originator application [RFC3413]. SNMP notifications are often used to notify a notification receiver application at a logically remote SNMP entity that an event has occurred or that a certain condition is present. There are two types of SNMP protocol operations that are associated with SNMP notification messages [RFC3416]:
SNMP通知消息由SNMP实体代表通知发起人应用程序生成和传输[RFC3413]。SNMP通知通常用于通知逻辑远程SNMP实体上的通知接收器应用程序已发生事件或存在特定条件。有两种类型的SNMP协议操作与SNMP通知消息[RFC3416]关联：
o SNMPv2-Trap-PDU, an unconfirmed notification delivery mechanism
o SNMPv2陷阱PDU，一种未经确认的通知传递机制
o InformRequest-PDU, a confirmed notification delivery mechanism
o InformRequest PDU，一种确认通知传递机制
The scopedPDU portion of an SNMPv3 trap or inform message has the following format [RFC3412]:
SNMPv3陷阱或通知消息的scopedPDU部分具有以下格式[RFC3412]：
ScopedPDU ::= SEQUENCE {
contextEngineID OCTET STRING,
contextName OCTET STRING,
data ANY -- e.g., PDUs as defined in [RFC3416]
}
ScopedPDU ::= SEQUENCE {
contextEngineID OCTET STRING,
contextName OCTET STRING,
data ANY -- e.g., PDUs as defined in [RFC3416]
}
The data member of the SEQUENCE ScopedPDU carries an SNMPv2-Trap-PDU or an InformRequest-PDU. They both have the same structure:
序列ScopedPDU的数据成员携带SNMPv2陷阱PDU或InformRequest PDU。它们都具有相同的结构：
PDUs ::= [7] IMPLICIT SEQUENCE {
request-id INTEGER,
error-status INTEGER, -- ignored in notifications
error-index INTEGER, -- ignored in notifications
variable-bindings VarBindList
}
PDUs ::= [7] IMPLICIT SEQUENCE {
request-id INTEGER,
error-status INTEGER, -- ignored in notifications
error-index INTEGER, -- ignored in notifications
variable-bindings VarBindList
}
-- variable binding
--变量绑定
VarBind ::= SEQUENCE {
name ObjectName,
VarBind ::= SEQUENCE {
name ObjectName,
CHOICE {
value ObjectSyntax,
unSpecified NULL, -- in retrieval requests
-- exceptions in responses
noSuchObject [0] IMPLICIT NULL,
noSuchInstance [1] IMPLICIT NULL,
endOfMibView [2] IMPLICIT NULL
}
}
CHOICE {
value ObjectSyntax,
unSpecified NULL, -- in retrieval requests
-- exceptions in responses
noSuchObject [0] IMPLICIT NULL,
noSuchInstance [1] IMPLICIT NULL,
endOfMibView [2] IMPLICIT NULL
}
}
-- variable-binding list
--变量绑定列表
VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind
VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind
The first two variable bindings in the variable binding list of an SNMPv2-Trap-PDU or InformRequest-PDU are sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418], respectively. If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable, as instantiated by this notification, is copied, in order, to the variable-bindings field. If any additional variables are being included (at the option of the generating SNMP entity), then each is copied to the variable-bindings field.
SNMPv2陷阱PDU或InformRequest PDU的变量绑定列表中的前两个变量绑定分别是sysUpTime.0[RFC3418]和snmpTrapOID.0[RFC3418]。如果OBJECTS子句出现在相应NOTIFICATION-TYPE宏的调用中，则此通知实例化的每个相应变量都会按顺序复制到variable bindings字段。如果包含任何其他变量（根据生成SNMP实体的选项），则每个变量都会复制到变量绑定字段。
In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID and the contextName parameters are not present in notification messages.
对于SNMPv1或SNMPv2c通知，通知消息中不存在contextEngineID和contextName参数。
This document assumes that notifications are in the format defined in [RFC3416]. Notifications in the SNMPv1 notification format MUST be translated as described in Section 3.1 of [RFC3584].
本文档假设通知采用[RFC3416]中定义的格式。SNMPv1通知格式的通知必须按照[RFC3584]第3.1节所述进行翻译。
The SYSLOG protocol is defined in [RFC5424]. The message contains a global header and a number of structured data elements. The ABNF [RFC5234] representation of a SYSLOG message is defined in RFC 5424 [RFC5424]. The relevant productions for structured data elements are:
系统日志协议在[RFC5424]中定义。该消息包含一个全局标头和许多结构化数据元素。系统日志消息的ABNF[RFC5234]表示在RFC 5424[RFC5424]中定义。结构化数据元素的相关产品包括：
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME
PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
SD-NAME = 1*32PRINTUSASCII
; except '=', SP, ']', %d34 (")
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID = SD-NAME
PARAM-NAME = SD-NAME
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
SD-NAME = 1*32PRINTUSASCII
; except '=', SP, ']', %d34 (")
UTF-8-STRING = *OCTET ; Any VALID UTF-8 String
; "shortest form" MUST be used
UTF-8-STRING = *OCTET ; Any VALID UTF-8 String
; "shortest form" MUST be used
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NILVALUE = "-"
OCTET = %d00-255
SP = %d32
PRINTUSASCII = %d33-126
NILVALUE = "-"
In this section, we define how the scopedPDU portion from an SNMP notification message is used to generate a message in the SYSLOG format. The notification receiver application at the SNMP-to-SYSLOG translator is listening for incoming notifications. After a notification is received by the SNMP engine, the data portion is forwarded to the notification receiver application. The data portion contains the scopedPDU of the message, which is used by the SYSLOG originator on the SNMP-to-SYSLOG translator to generate a SYSLOG message and send it to a SYSLOG collector (or proxy). Note that every SNMP notification maps to exactly one SYSLOG message.
在本节中，我们将定义如何使用SNMP通知消息中的scopedPDU部分生成SYSLOG格式的消息。SNMP到SYSLOG转换器上的通知接收器应用程序正在侦听传入的通知。SNMP引擎接收到通知后，数据部分被转发到通知接收器应用程序。数据部分包含消息的scopedPDU，SNMP到SYSLOG转换器上的SYSLOG发起人使用它生成SYSLOG消息并将其发送到SYSLOG收集器（或代理）。请注意，每个SNMP通知只映射到一条SYSLOG消息。
+------------+ +------------------+
|snmp | snmp | | syslog +---------+
|notification| notification | +------------+ | message |syslog |
|originator |------------->| |syslog | |-------->|collector|
+------------+ | |originator | | +---------+
+------------+ | +------------+ |
|snmp | snmp | +------------+ | syslog +---------+
|notification| notification | |snmp | | message |syslog |
|originator |------------->| |notification| |-------->|collector|
+------------+ | |receiver | | +---------+
+------------+ | +------------+ |
|snmp | snmp | |
|notification| notification | SNMP-to-SYSLOG |
|originator |------------->| translator |
+------------+ +------------------+
+------------+ +------------------+
|snmp | snmp | | syslog +---------+
|notification| notification | +------------+ | message |syslog |
|originator |------------->| |syslog | |-------->|collector|
+------------+ | |originator | | +---------+
+------------+ | +------------+ |
|snmp | snmp | +------------+ | syslog +---------+
|notification| notification | |snmp | | message |syslog |
|originator |------------->| |notification| |-------->|collector|
+------------+ | |receiver | | +---------+
+------------+ | +------------+ |
|snmp | snmp | |
|notification| notification | SNMP-to-SYSLOG |
|originator |------------->| translator |
+------------+ +------------------+
Figure 1: SNMP-to-SYSLOG Translator Deployment
图1:SNMP到系统日志转换器部署
A common deployment scenario is shown in Figure 1. There can be many SNMP notification originators that send SNMP event notifications to an SNMP-to-SYSLOG translator. The SNMP-to-SYSLOG translator extracts the data portion of the notification, generates a SYSLOG message, and sends the SYSLOG message to a SYSLOG collector, which is responsible for collecting and storing all notification messages. The arrows in Figure 1 indicate message flows, not individual messages.
图1显示了一个常见的部署场景。可以有许多SNMP通知发起人将SNMP事件通知发送到SNMP-to-SYSLOG转换器。SNMP到SYSLOG转换器提取通知的数据部分，生成SYSLOG消息，并将SYSLOG消息发送到SYSLOG收集器，该收集器负责收集和存储所有通知消息。图1中的箭头表示消息流，而不是单个消息。
The SNMP-to-SYSLOG translator is not transparent for a SYSLOG collector. The global header of the SYSLOG message generated by the SNMP-to-SYSLOG translator is filled with parameters that are specific for the system running the SNMP-to-SYSLOG translator, such as its hostname, timestamp, etc. The data portion (scopedPDU for SNMPv3 or PDU for SNMPv1/SNMPv2c) of the SNMP notification message is contained in the structured data of the SYSLOG message.
SNMP到系统日志转换器对于系统日志收集器是不透明的。SNMP到SYSLOG转换器生成的SYSLOG消息的全局标头填充了运行SNMP到SYSLOG转换器的系统特定的参数，例如其主机名、时间戳等。数据部分（SNMPv3的scopedPDU或SNMPv1/SNMPv2c的PDU）SNMP通知消息的格式包含在SYSLOG消息的结构化数据中。
Implementations MUST drop invalid SNMP messages before they are passed to the SNMP-to-SYSLOG translator.
实现必须删除无效的SNMP消息，然后才能将其传递到SNMP到系统日志转换器。
The SNMP-to-SYSLOG translator fills the HEADER field of a SYSLOG message with parameters specific to the system on which it is running. The default facility level for SYSLOG messages containing SNMP notifications SHOULD be 3, which corresponds to messages generated by system daemons. The default severity level SHOULD be 5, which corresponds to "Notice: normal but significant condition". If the SNMP-to-SYSLOG translator has a notion of the type of notification that has been received, it might choose other values for facility and severity level.
SNMP到SYSLOG转换器使用特定于运行它的系统的参数填充SYSLOG消息的标题字段。包含SNMP通知的系统日志消息的默认设施级别应为3，这与系统守护进程生成的消息相对应。默认严重性级别应为5，对应于“注意：正常但重要条件”。如果SNMP到SYSLOG转换器具有已接收通知类型的概念，则它可能会为设备和严重性级别选择其他值。
The VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, and MSGID fields in the SYSLOG message header are filled with values that are specific to the system on which the SNMP-to-SYSLOG translator is running. The character set used in the HEADER MUST be seven-bit ASCII in an eight-bit field, as described in [RFC5424].
SYSLOG消息头中的VERSION、TIMESTAMP、HOSTNAME、APP-NAME、PROCID和MSGID字段由特定于运行SNMP-to-SYSLOG转换器的系统的值填充。标头中使用的字符集必须是八位字段中的七位ASCII，如[RFC5424]中所述。
The STRUCTURED-DATA field of a SYSLOG message carries the ScopedPDU (or PDU) portion of an SNMP notification message. For the purpose of carrying SNMP notification data, a new SD-ID element is defined. The ABNF [RFC5234] representation of the new structured element is:
SYSLOG消息的结构化数据字段包含SNMP通知消息的ScopedPDU（或PDU）部分。为了承载SNMP通知数据，定义了一个新的SD-ID元素。新结构元素的ABNF[RFC5234]表示为：
SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]"
SNMP-SD-ID = %x73.6E.6D.70 ; snmp
CTX = CTXENGINE CTXNAME
CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34
CTXNAME = SP "ctxName=" %d34 PARAM-VALUE %d34
VARBIND = SP VARNAME [SP VARLABEL] SP VARVALUE [SP VALSTRING]
VARNAME = %d118 NUM "=" %d34 OID %d34 ; "vN="
VARLABEL = %d108 NUM "=" %d34 PARAM-VALUE %d34 ; "lN="
VARVALUE = VALOID / VALHEXSTRING / VALCOUNTER32 / VALCOUNTER64
/ VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL
/ VALOPAQUE / VALTIMETICKS / VALSTRING
SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] *VARBIND "]"
SNMP-SD-ID = %x73.6E.6D.70 ; snmp
CTX = CTXENGINE CTXNAME
CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34
CTXNAME = SP "ctxName=" %d34 PARAM-VALUE %d34
VARBIND = SP VARNAME [SP VARLABEL] SP VARVALUE [SP VALSTRING]
VARNAME = %d118 NUM "=" %d34 OID %d34 ; "vN="
VARLABEL = %d108 NUM "=" %d34 PARAM-VALUE %d34 ; "lN="
VARVALUE = VALOID / VALHEXSTRING / VALCOUNTER32 / VALCOUNTER64
/ VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL
/ VALOPAQUE / VALTIMETICKS / VALSTRING
VALOID = %d111 NUM "=" %d34 OID %d34 ; "oN="
VALHEXSTRING = %d120 NUM "=" %d34 HEXSTRING %d34 ; "xN="
VALCOUNTER32 = %d99 NUM "=" %d34 UNSIGNED32 %d34 ; "cN="
VALCOUNTER64 = %d67 NUM "=" %d34 UNSIGNED64 %d34 ; "CN="
VALUNSIGNED32 = %d117 NUM "=" %d34 UNSIGNED32 %d34 ; "uN="
VALINTEGER32 = %d100 NUM "=" %d34 INTEGER32 %d34 ; "dN="
VALIP = %d105 NUM "=" %d34 IPV4ADDRESS %d34 ; "iN="
VALNULL = %d110 NUM "=" %d34 %d34 ; "nN="
VALOPAQUE = %d112 NUM "=" %d34 HEXSTRING %d34 ; "pN="
VALTIMETICKS = %d116 NUM "=" %d34 UNSIGNED32 %d34 ; "tN="
VALSTRING = %d97 NUM "=" %d34 PARAM-VALUE %d34 ; "aN="
VALOID = %d111 NUM "=" %d34 OID %d34 ; "oN="
VALHEXSTRING = %d120 NUM "=" %d34 HEXSTRING %d34 ; "xN="
VALCOUNTER32 = %d99 NUM "=" %d34 UNSIGNED32 %d34 ; "cN="
VALCOUNTER64 = %d67 NUM "=" %d34 UNSIGNED64 %d34 ; "CN="
VALUNSIGNED32 = %d117 NUM "=" %d34 UNSIGNED32 %d34 ; "uN="
VALINTEGER32 = %d100 NUM "=" %d34 INTEGER32 %d34 ; "dN="
VALIP = %d105 NUM "=" %d34 IPV4ADDRESS %d34 ; "iN="
VALNULL = %d110 NUM "=" %d34 %d34 ; "nN="
VALOPAQUE = %d112 NUM "=" %d34 HEXSTRING %d34 ; "pN="
VALTIMETICKS = %d116 NUM "=" %d34 UNSIGNED32 %d34 ; "tN="
VALSTRING = %d97 NUM "=" %d34 PARAM-VALUE %d34 ; "aN="
NUM = NONZERODIGIT 0*DIGIT
NUM=非零位0*位
OID = OIDSTART *("." OIDSUBID)
OIDSTART = (("0." / "1.") [%d49-51] DIGIT) / ("2." OIDSUBID)
OIDSUBID = ZERO / (NONZERODIGIT *DIGIT)
OID = OIDSTART *("." OIDSUBID)
OIDSTART = (("0." / "1.") [%d49-51] DIGIT) / ("2." OIDSUBID)
OIDSUBID = ZERO / (NONZERODIGIT *DIGIT)
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
UTF-8-STRING = *OCTET ; Any VALID UTF-8 String
; "shortest form" MUST be used
HEXSTRING = *HEX
PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and
; ']' MUST be escaped.
UTF-8-STRING = *OCTET ; Any VALID UTF-8 String
; "shortest form" MUST be used
HEXSTRING = *HEX
INTEGER32 = ["-"] NONZERODIGIT 0*DIGIT
UNSIGNED32 = NONZERODIGIT 0*DIGIT
UNSIGNED64 = NONZERODIGIT 0*DIGIT
IPV4ADDRESS = d8 "." d8 "." d8 "." d8
INTEGER32 = ["-"] NONZERODIGIT 0*DIGIT
UNSIGNED32 = NONZERODIGIT 0*DIGIT
UNSIGNED64 = NONZERODIGIT 0*DIGIT
IPV4ADDRESS = d8 "." d8 "." d8 "." d8
d8 = DIGIT ; 0-9
/ %d49-57 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %d48-52 DIGIT ; 200-249
/ "25" %d48-53 ; 250-255
d8 = DIGIT ; 0-9
/ %d49-57 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %d48-52 DIGIT ; 200-249
/ "25" %d48-53 ; 250-255
HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
NONZERODIGIT = %d49-57
ZERO = %d48
DIGIT = ZERO / NONZERODIGIT
SP = %d32
HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
NONZERODIGIT = %d49-57
ZERO = %d48
DIGIT = ZERO / NONZERODIGIT
SP = %d32
Each SNMP-SD-ELEMENT starts with the SD-ID "snmp". The first two SD-ID parameters are "ctxEngine" and "ctxName". The context MUST be present in an SNMPv3 notification and therefore "ctxEngine" and "ctxName" MUST be present in a SYSLOG message generated by an SNMP-to-SYSLOG translator from an SNMPv3 notification. The contextEngineID is encoded as an hexadecimal string while the contextName is encoded as a UTF8 string.
每个SNMP-SD-ELEMENT都以SD-ID“SNMP”开头。前两个SD-ID参数是“ctxEngine”和“ctxName”。上下文必须存在于SNMPv3通知中，因此“ctxEngine”和“ctxName”必须存在于SNMP到SYSLOG转换器从SNMPv3通知生成的SYSLOG消息中。contextEngineID编码为十六进制字符串，而contextName编码为UTF8字符串。
The remaining parameters in the "snmp" SD-ID correspond to the varbind list elements contained in the SNMP PDU. The name of a varbind is encoded as an OID in dotted notation. The rendered OID is carried in a "vN" parameter, where N identifies the position of the varbind in the varbind list of the SNMP message (the first varbind having the position 1). A MIB-aware implementation may in addition generate a parameter "lN" carrying the descriptor of the associated MIB object plus the instance identifier suffix (also called an OID label). The number N again identifies the position of the varbind in the varbind list of the SNMP message.
“snmp”SD-ID中的其余参数对应于snmp PDU中包含的varbind列表元素。varbind的名称以虚线表示法编码为OID。呈现的OID包含在“vN”参数中，其中N标识SNMP消息的varbind列表中的varbind位置（第一个varbind的位置为1）。MIB感知实现还可以生成一个参数“lN”，该参数携带相关MIB对象的描述符和实例标识符后缀（也称为OID标签）。数字N再次标识了在SNMP消息的varbind列表中varbind的位置。
The value of a varbind is encoded depending on its type according to the rules shown in Table 1, and type-specific parameter names are used to convey the type information. The number N again identifies the position of the varbind in the varbind list of the SNMP message. A MIB-aware implementation may in addition generate a parameter "aN" carrying an alternate textual representation of the value, which is obtained by applying DISPLAY-HINTs and translating named numbers into corresponding labels or OBJECT IDENTIFIER values to descriptors. For SNMP object types that have a DISPLAY-HINT of the form 'Ma' or 'Mt', where M is some number, a MIB-aware implementation can choose to include the "aN" parameter and to suppress the corresponding "xN" parameter. This special case saves space for textual objects. A
varbind的值根据表1所示的规则根据其类型进行编码，并使用特定于类型的参数名来传递类型信息。数字N再次标识了在SNMP消息的varbind列表中varbind的位置。MIB感知的实现还可以生成一个参数“aN”，该参数携带值的替代文本表示，该值是通过应用显示提示并将命名数字转换为对应的标签或对象标识符值到描述符来获得的。对于具有“Ma”或“Mt”形式的显示提示的SNMP对象类型，其中M是某个数字，MIB感知实现可以选择包括“aN”参数并抑制相应的“xN”参数。这种特殊情况为文本对象节省了空间。A.
receiver receiving an "aN" parameter without a matching value at position N can unambiguously convert the value carried in the "aN" parameter back to an OCTET STRING value.
接收到位置N处没有匹配值的“an”参数的接收器可以明确地将“an”参数中包含的值转换回八进制字符串值。
While the inclusion of additional parameters carrying OID labels or alternate value representations increases human readability, this comes at the cost of increased message size, which may cause truncation of SYSLOG messages. Therefore, implementations SHOULD provide a configuration mechanism to enable/disable the generation of parameters carrying OID labels or alternate value representations.
虽然包含带有OID标签或替代值表示的附加参数增加了人的可读性，但这是以增加消息大小为代价的，这可能会导致系统日志消息的截断。因此，实现应该提供一种配置机制来启用/禁用携带OID标签或替代值表示的参数的生成。
+--------------------+------------+--------------------------+
| SNMP Type | PARAM-NAME | Value Encoding |
+--------------------+------------+--------------------------+
| OBJECT IDENTIFIER | oN | dotted-decimal notation |
| OCTET STRING | xN | hexadecimal string |
| Counter32 | cN | unsigned decimal number |
| Counter64 | CN | unsigned decimal number |
| Unsigned32 | uN | unsigned decimal number |
| INTEGER, Integer32 | dN | signed decimal number |
| IpAddress | iN | dotted quad notation |
| Opaque | pN | hexadecimal (BER) string |
| TimeTicks | tN | unsigned decimal number |
| NULL | nN | zero-length string |
+--------------------+------------+--------------------------+
+--------------------+------------+--------------------------+
| SNMP Type | PARAM-NAME | Value Encoding |
+--------------------+------------+--------------------------+
| OBJECT IDENTIFIER | oN | dotted-decimal notation |
| OCTET STRING | xN | hexadecimal string |
| Counter32 | cN | unsigned decimal number |
| Counter64 | CN | unsigned decimal number |
| Unsigned32 | uN | unsigned decimal number |
| INTEGER, Integer32 | dN | signed decimal number |
| IpAddress | iN | dotted quad notation |
| Opaque | pN | hexadecimal (BER) string |
| TimeTicks | tN | unsigned decimal number |
| NULL | nN | zero-length string |
+--------------------+------------+--------------------------+
Table 1: Mapping of SNMP Types to SD Params
表1:SNMP类型到SD参数的映射
The SYSLOG message generated by the SNMP-to-SYSLOG translator may, in addition to the SNMP-SD-ELEMENT, include other structured data elements in its structured data part. These additional structured data elements MUST comply with the specification in [RFC5424].
SNMP-to-SYSLOG转换器生成的系统日志消息，除了SNMP-SD-ELEMENT之外，还可以在其结构化数据部分包含其他结构化数据元素。这些额外的结构化数据元素必须符合[RFC5424]中的规范。
In particular, the parameters in the "origin" SD-ID SHOULD identify the originator of the SNMP notification. A suitable value for the "ip" parameter MAY be taken from the snmpTrapAddress varbind if present, and a suitable value for the "enterpriseId" parameter MAY be extracted from the snmpTrapOID varbind.
特别是，“源”SD-ID中的参数应标识SNMP通知的发起人。“ip”参数的合适值可以从snmpTrapAddress变量绑定（如果存在）中获取，而“enterpriseId”参数的合适值可以从snmpTrapOID变量绑定中提取。
The MSG part of the SYSLOG message is optional and may contain a free-form message that provides a textual description of the SNMP event notification. According to [RFC5424], the character set used in MSG SHOULD be Unicode, encoded using UTF-8 as specified in [RFC3629]. If the originator cannot encode the MSG in Unicode, it
SYSLOG消息的MSG部分是可选的，可能包含自由格式的消息，该消息提供SNMP事件通知的文本描述。根据[RFC5424]，MSG中使用的字符集应为Unicode，使用[RFC3629]中规定的UTF-8编码。如果发起者不能用Unicode编码消息，则它
MAY use any other encoding. The originator MAY use the "language" parameters defined in [RFC5424] to convey information about the natural language used inside MSG.
可以使用任何其他编码。发端人可以使用[RFC5424]中定义的“语言”参数来传达有关MSG中使用的自然语言的信息。
A companion document [RFC5676] defines an SNMP MIB module to represent SYSLOG messages and to send SYSLOG messages as SNMP notifications to SNMP notification receivers. This section discusses the possibilities of using both specifications in combination.
附带文档[RFC5676]定义了一个SNMP MIB模块，用于表示系统日志消息，并将系统日志消息作为SNMP通知发送给SNMP通知接收器。本节讨论结合使用这两种规范的可能性。
A SYSLOG collector implementing the SYSLOG-MSG-MIB module and the mapping of SNMP notifications to SYSLOG messages may be configured to translate received SYSLOG messages containing SNMP notifications back into the original SNMP notification. In this case, the relevant tables of the SYSLOG-MSG-MIB will not be populated for SYSLOG messages carrying SNMP notifications. This configuration allows operators to build a forwarding chain where SNMP notifications are "tunneled" through SYSLOG messages. Due to size restrictions of the SYSLOG transports and the more verbose textual encoding used by SYSLOG, there is a possibility that SNMP notification content will get truncated when tunneled through SYSLOG, and thus the resulting SNMP notification may be incomplete.
可以将实现SYSLOG-MSG-MIB模块和SNMP通知到SYSLOG消息的映射的SYSLOG收集器配置为将接收到的包含SNMP通知的SYSLOG消息转换回原始SNMP通知。在这种情况下，不会为承载SNMP通知的SYSLOG消息填充SYSLOG-MSG-MIB的相关表。此配置允许操作员构建转发链，其中SNMP通知通过系统日志消息“隧道化”。由于SYSLOG传输的大小限制以及SYSLOG使用的更详细的文本编码，当通过SYSLOG进行隧道传输时，SNMP通知内容可能会被截断，因此生成的SNMP通知可能不完整。
An SNMP management application supporting the SYSLOG-MSG-MIB and the mapping of SNMP notifications to SYSLOG messages may process information from the SYSLOG-MSG-MIB in order to emit a SYSLOG message representing the SYSLOG message recorded in the SYSLOG-MSG-MIB module. This configuration allows operators to build a forwarding chain where SYSLOG messages are "tunneled" through SNMP messages. A notification receiver can determine whether a syslogMsgNotification contained all structured data element parameters of a SYSLOG message. In case parameters are missing, a forwarding application MUST retrieve the missing parameters from the SYSLOG-MSG-MIB. Regular polling of the SYSLOG-MSG-MIB can be used to take care of any lost SNMP notifications.
支持SYSLOG-MSG-MIB和SNMP通知到SYSLOG消息的映射的SNMP管理应用程序可以处理来自SYSLOG-MSG-MIB的信息，以便发出表示SYSLOG-MSG-MIB模块中记录的SYSLOG消息的SYSLOG消息。此配置允许操作员构建转发链，其中系统日志消息通过SNMP消息“隧道化”。通知接收方可以确定syslogMsgNotification是否包含SYSLOG消息的所有结构化数据元素参数。如果缺少参数，转发应用程序必须从SYSLOG-MSG-MIB中检索缺少的参数。SYSLOG-MSG-MIB的定期轮询可用于处理任何丢失的SNMP通知。
Here we provide an example of how an SNMP linkUp trap message is mapped into a SYSLOG message by using the mappings defined in Section 3.1 and Section 3.2.
这里我们提供一个示例，说明如何使用第3.1节和第3.2节中定义的映射将SNMP链接陷阱消息映射到SYSLOG消息。
The linkUp notification is defined in [RFC2863] as follows:
[RFC2863]中对连接通知的定义如下：
linkUp NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current
链接通知类型对象{ifIndex，ifAdminStatus，ifOperStatus}状态当前
DESCRIPTION
"A linkUp trap signifies that the SNMP entity, acting in an
agent role, has detected that the ifOperStatus object for
one of its communication links left the down state and
transitioned into some other state (but not into the
notPresent state). This other state is indicated by the
included value of ifOperStatus."
::= { snmpTraps 4 }
DESCRIPTION
"A linkUp trap signifies that the SNMP entity, acting in an
agent role, has detected that the ifOperStatus object for
one of its communication links left the down state and
transitioned into some other state (but not into the
notPresent state). This other state is indicated by the
included value of ifOperStatus."
::= { snmpTraps 4 }
The scopedPDU portion of an SNMP linkUp trap sent using the SNMPv3 message format is shown below (the left column shows the Basic Encoding Rules (BER) encoding, while the right column indicates the corresponding ASN.1 definitions):
使用SNMPv3消息格式发送的SNMP链接陷阱的scopedPDU部分如下所示（左栏显示基本编码规则（BER）编码，右栏显示相应的ASN.1定义）：
30:7C SEQUENCE {
04:08:80:00:02:B8:04:61:62:63 800002b804616263
04:04:63:74:78:31 "ctx1"
A7:6A SNMPv2-Trap-PDU {
02:03:6D:08:67 INTEGER 7145575
02:01:00 INTEGER 0
02:01:00 INTEGER 0
30:5D SEQUENCE OF {
30:0F SEQUENCE {
06:08:2B:06:01:02:01:01:03:00 sysUpTime.0
43:03:01:72:8C 94860 }
30:17 SEQUENCE {
06:0A:2B:06:01:06:03:01:01:04:01:00 snmpTrapOID.0
06:09:2B:06:01:06:03:01:01:05:04 linkUp }
30:0F SEQUENCE {
06:0A:2B:06:01:02:01:02:02:01:01:03 ifIndex.3
02:01:03 3 }
30:0F SEQUENCE {
06:0A:2B:06:01:02:01:02:02:01:07:03 ifAdminStatus.3
02:01:01 up(1) }
30:0F SEQUENCE {
06:0A:2B:06:01:02:01:02:02:01:08:03 ifOperStatus.3
02:01:01 up(1) } } } }
30:7C SEQUENCE {
04:08:80:00:02:B8:04:61:62:63 800002b804616263
04:04:63:74:78:31 "ctx1"
A7:6A SNMPv2-Trap-PDU {
02:03:6D:08:67 INTEGER 7145575
02:01:00 INTEGER 0
02:01:00 INTEGER 0
30:5D SEQUENCE OF {
30:0F SEQUENCE {
06:08:2B:06:01:02:01:01:03:00 sysUpTime.0
43:03:01:72:8C 94860 }
30:17 SEQUENCE {
06:0A:2B:06:01:06:03:01:01:04:01:00 snmpTrapOID.0
06:09:2B:06:01:06:03:01:01:05:04 linkUp }
30:0F SEQUENCE {
06:0A:2B:06:01:02:01:02:02:01:01:03 ifIndex.3
02:01:03 3 }
30:0F SEQUENCE {
06:0A:2B:06:01:02:01:02:02:01:07:03 ifAdminStatus.3
02:01:01 up(1) }
30:0F SEQUENCE {
06:0A:2B:06:01:02:01:02:02:01:08:03 ifOperStatus.3
02:01:01 up(1) } } } }
The corresponding SYSLOG message generated by the SNMP-to-SYSLOG translator is shown below. (SYSLOG examples should be considered to be on one line. They are wrapped on multiple lines in this document for readability purposes only.)
SNMP到系统日志转换器生成的相应系统日志消息如下所示。（应将系统日志示例视为一行。在本文档中，它们被包装在多行中，仅用于可读性目的。）
<29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47
[snmp ctxEngine="800002b804616263" ctxName="ctx1"
v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860"
v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0"
o2="1.3.6.1.6.3.1.1.5.4" a2="linkUp"
<29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47
[snmp ctxEngine="800002b804616263" ctxName="ctx1"
v1="1.3.6.1.2.1.1.3.0" l1="sysUpTime.0" d1="94860"
v2="1.3.6.1.6.3.1.1.4.1.0" l2="snmpTrapOID.0"
o2="1.3.6.1.6.3.1.1.5.4" a2="linkUp"
v3="1.3.6.1.2.1.2.2.1.1.3" d3="3"
v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" a4="up"
v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" a5="up"]
v3="1.3.6.1.2.1.2.2.1.1.3" d3="3"
v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" a4="up"
v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" a5="up"]
The corresponding SYSLOG message has a priority value of 29, which means a facility level of 3 (system daemons) and a severity level of 5 (Notice: normal but significant condition) according to the algorithm for calculation of priority value specified in Section 6.2.1 of [RFC5424]. The rest of the fields in the header of the SYSLOG message are parameters that are specific to the system running the SNMP-to-SYSLOG translator. The SYSLOG version is 1 and the message was generated at 22:14:15.003Z on 2003-10-11T by the host "mymachine.example.com". The application on the SNMP-to-SYSLOG translator that generated the message was "snmptrapd"; there is no information about the process id, and the message on the SNMP-to-SYSLOG system is identified with the MSGID of ID47.
根据[RFC5424]第6.2.1节中规定的优先级值计算算法，相应的系统日志消息的优先级值为29，这意味着设施级别为3（系统守护进程），严重性级别为5（注意：正常但有效的条件）。SYSLOG消息头中的其余字段是特定于运行SNMP-to-SYSLOG转换器的系统的参数。SYSLOG版本为1，消息由主机“mymachine.example.com”于2003年10月11日22:14:15.003Z生成。生成消息的SNMP-to-SYSLOG转换器上的应用程序是“snmptrapd”；没有关于进程id的信息，SNMP to SYSLOG系统上的消息用ID47的MSGID标识。
The SYSLOG message contains one structured data element with an SD-ID of "snmp", which means that this is the scopedPDU portion of an SNMP event notification message. The data that is contained in the notification is associated with the ContextEngineID "123456" and ContextName "ctx1". The request-id of the SNMP notification message was "7145575". Then follows the data portion of the scopedPDU. The first two variables contained in the data portion are always the sysUpTime.0 and snmpTrapOID.0. An snmpTrapOID.0 with a value of "1.3.6.1.6.3.1.1.5.4" means that this is a linkUp trap. The parameters v3="1.3.6.1.2.1.2.2.1.1.3" d3="3" mean that the SNMP notification message is carrying the ifIndex object, which has a type INTEGER and a value of 3. The parameters v4="1.3.6.1.2.1.2.2.1.7.3" d4="1" mean that the SNMP notification message is carrying the object ifAdminStatus, which has a type INTEGER and a value of 1. The parameters v5="1.3.6.1.2.1.2.2.1.8.3" d5="1" mean that the SNMP notification message is carrying the object ifOperStatus, which has a type INTEGER and a value of "1".
SYSLOG消息包含一个SD-ID为“snmp”的结构化数据元素，这意味着这是snmp事件通知消息的scopedPDU部分。通知中包含的数据与ContextEngineID“123456”和ContextName“ctx1”关联。SNMP通知消息的请求id为“7145575”。然后跟随scopedPDU的数据部分。数据部分中包含的前两个变量始终是sysUpTime.0和snmpTrapOID.0。值为“1.3.6.1.6.3.1.1.5.4”的snmpTrapOID.0表示这是一个连接陷阱。参数v3=“1.3.6.1.2.1.2.2.1.1.3”d3=“3”表示SNMP通知消息携带ifIndex对象，该对象的类型为整数，值为3。参数v4=“1.3.6.1.2.1.2.2.1.7.3”d4=“1”表示SNMP通知消息携带对象ifAdminStatus，该对象的类型为整数，值为1。参数v5=“1.3.6.1.2.1.2.2.1.8.3”d5=“1”表示SNMP通知消息携带对象ifOperStatus，其类型为整数，值为“1”。
IANA registered the SD-ID value "snmp" together with the PARAM-NAME values specified in Section 3.2 in the registry for SYSLOG Structured Data ID Values according to Section 9 in [RFC5424]. The notation <N> indicates a position number.
IANA根据[RFC5424]第9节，将SD-ID值“snmp”与第3.2节中指定的参数名称值一起注册到SYSLOG结构化数据ID值注册表中。符号<N>表示位置编号。
SD-ID PARAM-NAME snmp OPTIONAL ctxEngine OPTIONAL ctxName OPTIONAL v<N> OPTIONAL l<N> OPTIONAL
SD-ID参数名称snmp可选ctxEngine可选ctxName可选v<N>可选l<N>可选
o<N> OPTIONAL
x<N> OPTIONAL
c<N> OPTIONAL
C<N> OPTIONAL
u<N> OPTIONAL
d<N> OPTIONAL
i<N> OPTIONAL
n<N> OPTIONAL
p<N> OPTIONAL
t<N> OPTIONAL
a<N> OPTIONAL
o<N> OPTIONAL
x<N> OPTIONAL
c<N> OPTIONAL
C<N> OPTIONAL
u<N> OPTIONAL
d<N> OPTIONAL
i<N> OPTIONAL
n<N> OPTIONAL
p<N> OPTIONAL
t<N> OPTIONAL
a<N> OPTIONAL
The security considerations discussed in [RFC5424] apply to this document.
[RFC5424]中讨论的安全注意事项适用于本文件。
The SNMP architecture supports an access control mechanism, ensuring that SNMP notifications are only sent to receivers who are authorized to receive the notification. Network operators using this mapping of SNMP notifications to SYSLOG messages should enforce a consistent policy, preventing people from accessing SNMP notifications via the SYSLOG mapping that would otherwise not be accessible.
SNMP体系结构支持访问控制机制，确保SNMP通知仅发送给有权接收通知的接收者。使用此SNMP通知到系统日志消息映射的网络运营商应实施一致的策略，防止人们通过系统日志映射访问SNMP通知，否则将无法访问这些通知。
The editors wish to thank the following individuals for providing helpful comments on various versions of this document: Martin Bjorklund, Washam Fan, Rainer Gerhards, Tom Petch, and Dan Romascanu.
编辑们希望感谢以下个人对本文件的不同版本提供了有益的意见：马丁·比约克隆德、瓦沙姆·范、雷纳·格哈德斯、汤姆·佩奇和丹·罗马斯坎努。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[RFC3412]Case，J.，Harrington，D.，Presohn，R.，和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]Levi，D.，Meyer，P.，和B.Stewart，“简单网络管理协议（SNMP）应用”，STD 62，RFC 3413，2002年12月。
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416]Presohn，R.，“简单网络管理协议（SNMP）协议操作的第2版”，STD 62，RFC 3416，2002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418]Presohn，R.，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584]Frye，R.，Levi，D.，Routhier，S.，和B.Wijnen，“互联网标准网络管理框架版本1，版本2和版本3之间的共存”，BCP 74，RFC 3584，2003年8月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 5234，2008年1月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", RFC 5676, October 2009.
[RFC5676]Schoenwaeld，J.，Clemm，A.，和A.Karmakar，“将系统日志消息映射到简单网络管理协议（SNMP）通知的受管对象的定义”，RFC 5676，2009年10月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“管理信息的结构版本2（SMIv2）”，RFC 2578，STD 58，1999年4月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863]McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 28632000年6月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
Authors' Addresses
作者地址
Vladislav Marinov Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
弗拉迪斯拉夫·马里诺夫·雅各布斯大学不来梅校区环128725德国不来梅
EMail: v.marinov@jacobs-university.de
EMail: v.marinov@jacobs-university.de
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
德国不来梅大学校园环128725
EMail: j.schoenwaelder@jacobs-university.de
EMail: j.schoenwaelder@jacobs-university.de