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
Abstract
抽象
This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages.
このメモは、SYSLOGメッセージに簡易ネットワーク管理プロトコル（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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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
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は、イベント通知を通信するために、2つの広く使用されるプロトコルです。つの動作環境でいくつかの管理プロトコルの共存が可能であるが、特定の環境では、すべてのイベント通知は、単一の管理プロトコルを介して、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通知とSYSLOGメッセージ間のマッピングを可能にします。このメモでは、我々は、SYSLOGメッセージ[RFC5424]にSNMPイベント通知[RFC3416]からの具体的なマッピングを指定します。私たちは、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 notification receiver application and a SYSLOG originator running in order to be able to perform the functions of an "SNMP-to-SYSLOG translator".
SNMP通知元からSNMP通知メッセージを受信し、SYSLOGコレクタにSYSLOGメッセージの形式で内部に含まれるSNMPデータを送信する能力を有するシステム「は、SNMPツーSYSLOG翻訳」としてこの文書で参照されます。定義により、そのようなシステムは、SNMP通知受信機アプリケーションと「SNMPツーSYSLOGトランスレータ」の機能を実行できるようにするために実行されているSYSLOG元を有するべきです。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]で見つけることができます。 SNMP管理アーキテクチャは、[RFC3411]に記述されています。管理オブジェクトが仮想情報ストアを介してアクセスされ、管理情報ベースまたは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通知メッセージが生成され、通知発信アプリケーション[RFC3413]の代わりにSNMPエンティティによって送信されます。 SNMP通知は、多くの場合、イベントが発生した論理的にリモートSNMPエンティティにおいて、または特定の条件が存在することを通知する受信機アプリケーションに通知するために使用されます。 SNMP通知メッセージ[RFC3416]に関連付けられているSNMPプロトコル操作の2種類があります。
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]
}
The data member of the SEQUENCE ScopedPDU carries an SNMPv2-Trap-PDU or an InformRequest-PDU. They both have the same structure:
SEQUENCEた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
}
-- variable binding
- 変数バインディング
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 {値ObjectSyntax、不特定NULL、 - 検索要求に - 応答の例外noSuchObject [0] IMPLICIT NULL、noSuchInstance [1] IMPLICIT NULL、endOfMibView [2] IMPLICIT NULL}}
-- variable-binding list
- 変数バインディングリスト
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の変数バインディングリストの最初の2つの変数バインディングは、それぞれsysUpTime.0 [RFC3418]とsnmpTrapOID.0 [RFC3418]です。 OBJECTS句は、対応するNOTIFICATION-TYPEマクロの起動中に存在する場合、対応する各変数は、この通知によってインスタンス化されるように、変数バインディング・フィールドに、順番に、コピーされます。追加の変数は（生成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]で定義された形式であることを前提としています。 [RFC3584]のセクション3.1に記載されているようにSNMPv1の通知形式の通知が変換されなければなりません。
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:
SYSLOGプロトコルは、[RFC5424]で定義されています。メッセージは、グローバルヘッダと構造化されたデータ要素の数を含んでいます。 SYSLOGメッセージの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 (")
UTF-8-STRING = *OCTET ; Any VALID UTF-8 String ; "shortest form" MUST be used
UTF-8-STRING = * OCTET。任意の有効なUTF-8文字列。 「短い形態」を使用しなければなりません
OCTET = %d00-255 SP = %d32 PRINTUSASCII = %d33-126 NILVALUE = "-"
オクテット= = = %% d00255 d33126シュペーnilvalui =のPrintusaspi 32％ " - "
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エンジンによって受信された後、データ部は、通知受信側アプリケーションに転送されます。データ部は、syslogメッセージを生成し、SYSLOGコレクタ（またはプロキシ）に送信するためにSNMPツーSYSLOGトランスレータにSYSLOG元によって使用されるメッセージ、のたscopedPDUを含んでいます。すべての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 |
+------------+ +------------------+
Figure 1: SNMP-to-SYSLOG Translator Deployment
図1：SNMPツーSYSLOG翻訳の展開
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.
一般的な展開シナリオは、SNMPツーSYSLOG翻訳者へのSNMPイベント通知を送信する多くのSNMP通知の発信元が存在することができ、図1に示されています。 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ツーSYSLOGトランスレータはSYSLOGコレクタの透明ではありません。 SNMPツーSYSLOGトランスレータによって生成されたSYSLOGメッセージのグローバルヘッダはSNMPツーSYSLOGトランスレータを実行しているシステムのための固有のパラメータで満たされている、等のデータ部分ホスト名、タイムスタンプ、（用としてたscopedPDU SNMP通知メッセージは、SYSLOGメッセージの構造化データに含まれているののSNMPv1 / SNMPv2cのためのSNMPv3またはPDU）。
Implementations MUST drop invalid SNMP messages before they are passed to the SNMP-to-SYSLOG translator.
彼らはSNMPツーSYSLOG翻訳者に渡される前に、実装は、無効な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通知を含むSYSLOGメッセージの既定の機能レベルは、システムデーモンによって生成されたメッセージに対応する、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メッセージヘッダのタイムスタンプ、ホスト名、APP-NAME、PROCID、およびMSGIDフィールドはSNMPツーSYSLOGトランスレータが実行されているシステムに固有の値で充填されます。 [RFC5424]に記載されているようにヘッダに使用される文字セットは、8ビットのフィールドで7ビットASCIIでなければなりません。
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値％の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。 "国連は=" 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値％のD34。 "AN ="
NUM = NONZERODIGIT 0*DIGIT
NUM = NONZERODIGIT 0 * DIGIT
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ストリング。文字 '"'、 '\' と、 ']' をエスケープしなければならないUTF-8-STRING = * OCTET;。任意の有効なUTF-8文字列; "最短の形は" 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 / 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" で始まります。最初の2 SD-IDのパラメータは、「ctxEngine」と「ctxName」です。コンテキストは、SNMPv3の通知に存在する必要があり、従って、「ctxEngine」および「ctxNameは、」SNMPv3の通知からSNMPツーSYSLOGトランスレータによって生成されたSYSLOGメッセージ内に存在していなければなりません。 contextNameは、UTF8文字列として符号化されている間contextEngineIDは16進数の文字列として符号化されます。
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は、Nは、SNMPメッセージ（位置1を有する第VARBIND）のvarbindリスト内のVARBINDの位置を特定する「VN」パラメータで運ばれます。 MIB対応の実装では、他に関連するMIBオブジェクトプラスインスタンス識別子のサフィックス（もOIDラベルと呼ばれる）の記述を運ぶパラメータ「LN」を生成してもよいです。数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 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.
VARBINDの値を表1に示したルールに従って、そのタイプに応じて符号化され、タイプ固有のパラメータ名は、タイプ情報を伝達するために使用されます。数Nは、再びSNMPメッセージのvarbindリスト内のVARBINDの位置を特定します。 MIB対応の実装では、他に「」ディスクリプタに対応するラベルやオブジェクト識別子値にDISPLAY-ヒントおよび翻訳名前番号を適用することによって得られた値、の交互のテキスト表現を担持するパラメータを生成することができます。 Mは、いくつかの数であり、形式「馬」や「富士山」のDISPLAY-HINTを有するSNMPオブジェクトタイプに対して、MIB対応の実装では、「AN」パラメータを含むように選択することができ、対応する「XN」パラメータを抑制すること。この特殊なケースは、テキストオブジェクトのためのスペースを節約できます。位置Nに一致する値なしで「AN」パラメータを受信する受信機は、明確OCTET STRINGの値に戻って「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標識または代替値の表現を担持する追加パラメータを含めることは、人間の可読性を増加させるが、これは、SYSLOGメッセージの切り詰めを引き起こす可能性が、増加したメッセージサイズを犠牲にしています。したがって、実装は、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 |
+--------------------+------------+--------------------------+
Table 1: Mapping of SNMP Types to SD Params
表1：SD PARAMSにSNMPタイプのマッピング
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ツーSYSLOGトランスレータによって生成されたSYSLOGメッセージは、SNMP-SD要素に加えて、その構造化データ部分の他の構造化されたデータ要素を含むことができます。これらの追加の構造化されたデータ要素は[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のVARBINDから採取してもよく、「enterpriseId」パラメータの適切な値はsnmpTrapOIDのVARBINDから抽出することができます。
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は、UTF-8 [RFC3629]で指定されるように使用してエンコードする必要があります。発信元がUnicodeでMSGをエンコードすることができない場合は、それを
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.
他のエンコーディングを使用するかもしれません。発信者は、MSGの内部で使用される自然言語についての情報を伝えるために、[RFC5424]で定義された「言語」パラメータを使用するかもしれません。
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]はSYSLOGメッセージを表現し、SNMP通知受信者にSNMP通知としてSYSLOGメッセージを送信するためにSNMP MIBモジュールを定義します。このセクションでは、組み合わせて、両方の仕様を使用しての可能性を論じています。
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メッセージにSYSLOG-MSG-MIBモジュールとSNMP通知のマッピングを実装SYSLOGコレクタは、元のSNMP通知にSNMP通知を含む受信SYSLOGメッセージを変換するように構成されてもよいです。この場合、SYSLOG-MSG-MIBの関連するテーブルは、SNMP通知を運ぶSYSLOGメッセージのために読み込まれることはありません。この構成では、事業者はSNMP通知はSYSLOGメッセージを介して「トンネル化」されている転送チェーンを構築することができます。 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メッセージにSYSLOG-MSG-MIBやSNMP通知のマッピングをサポートするSNMP管理アプリケーションは、SYSLOG-MSG-MIBモジュールに記録されたSYSLOGメッセージを表すSYSLOGメッセージを放出するために、SYSLOG-MSG-MIBからの情報を処理することができます。この構成では、事業者は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
リンクアップNOTIFICATION-TYPEオブジェクト{ifIndexの、のifAdminStatus、のifOperStatus} STATUS電流
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部は以下に示す（右の列は、対応するASN.1定義を示している左の列は、基本符号化規則（BER）符号化を示しています）。
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：7（c）配列{04：08：80：00：02：B8：04：61：62：63 800002b804616263 04：04：63：74：78：31 "CTX1" A7：6AのSNMPv2トラップ-PDU {02： 03：6D：08：67 INTEGER 7145575午前2時01分00秒INTEGER 0午前2時01分00秒INTEGER 0〜30：0Fシーケンス{06：08：2B：06：01：02：01：01 {30の5D SEQUENCE。 3時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リンクアップ} 30：0Fシーケンス{06：0A：2B：06：01：02：01：02：02：01：01：03のifIndex .3 2時01分03秒3} 30：0Fシーケンス{06：0A：2B：06：01：02：01：02：02：01：07：03 ifAdminStatus.3午前2時01分01秒まで（1）} 30：0Fシーケンス{06：0A：2B：06：01：02：01：02：02：01：08：03 ifOperStatus.3 2時01分01秒まで（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ツーSYSLOGトランスレータによって生成された対応するSYSLOGメッセージを以下に示します。 （SYSLOG例は、1行にあると考えるべきである。彼らは唯一の読みやすさのために、このドキュメントでは複数行にラップされます。）
<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 = "リンクアップ"
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.
セクション6.2で指定された優先値を計算するためのアルゴリズムによれば、対応するSYSLOGメッセージが3（システムデーモン）のファシリティレベルを意味29の優先順位値、および5（正常ではあるが有意な状態通知）の重大度レベルを有します。 [RFC5424]の1。 SYSLOGメッセージのヘッダー内のフィールドの残りの部分はSNMPツーSYSLOGトランスレータを実行しているシステムに固有のパラメータです。 SYSLOGバージョン1であり、メッセージは22で生成された：14：2003-10-11Tに15.003Zホストによって「mymachine.example.com」。メッセージを生成したSNMPツーSYSLOG翻訳上のアプリケーションは、「にsnmptrapd」でした。そこプロセスIDに関する情報がなく、SNMPツー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メッセージは、これがSNMPイベント通知メッセージのたscopedPDU部であることを意味する「SNMP」のSD-IDを有する1つの構造化データ要素を含みます。通知に含まれるデータは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通知メッセージは、タイプINTEGERおよび3パラメータのV4 =」の値を有するifIndexオブジェクトを運んでいることを意味1.3.6.1.2.1.2.2.1.7.3" D4 = 『1 1.3.6.1.2.1』 SNMP通知メッセージは、タイプINTEGERおよびV5 = 1のパラメータの値を持つオブジェクトのifAdminStatusを運んでいることを意味します " .2.2.1.8.3" D5 = 『1『1』SNMP通知メッセージは、タイプINTEGERの値を持つオブジェクトのifOperStatusを運んでいることを意味します』。
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に記載のSYSLOG構造化データID値のためのレジストリでセクション3.2で指定されたPARAM-NAME値と共にSD-ID値「SNMP」を登録しました。表記は、<N>は、位置番号を示します。
SD-ID PARAM-NAME
snmp OPTIONAL
ctxEngine OPTIONAL
ctxName OPTIONAL
v<N> OPTIONAL
l<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通知が通知のみを受信することが許可されている受信機に送信されることを保証する、アクセス制御メカニズムをサポートしています。 SYSLOGメッセージにSNMP通知のこのマッピングを使用して、ネットワークオペレータは、そうでない場合はアクセスできないでしょうSYSLOGマッピングを経由して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.
マーティンBjorklund、Washamファン、レイナー・ガーハーズ、トム・ペッチ、そしてダンRomascanu：編集者は、このドキュメントのさまざまなバージョンに有益なコメントを提供するための以下の個人に感謝したいです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ハリントン、D.、Presuhn、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]ケース、J.、ハリントン、D.、Presuhn、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]レビ、D.、マイヤー、P.、およびB.スチュワート、 "簡易ネットワーク管理プロトコル（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] Presuhn、R.、STD 62、RFC 3416、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2"。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
、STD 62、RFC 3418、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）" [RFC3418] Presuhn、R.、。
[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]フライ、R.、レヴィ、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]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 5234、2008年1月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards氏、R.、 "Syslogのプロトコル"、RFC 5424、2009年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] Schoenwaelder、J.、Clemm、A.、およびA. Karmakar、RFC 5676、2009年10月 "簡易ネットワーク管理プロトコル（SNMP）通知へのマッピングSYSLOGメッセージのための管理オブジェクトの定義"。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、RFC 2578 "管理情報バージョン2（SMIv2）の構造"、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 2863、2000年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]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
Authors' Addresses
著者のアドレス
Vladislav Marinov Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
ウラジスラフマリノフジェイコブス大学ブレーメンキャンパスリング1 28725ブレーメンドイツ
EMail: v.marinov@jacobs-university.de
メールアドレス：v.marinov@jacobs-university.de
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
ユルゲンSchoenwaelderジェイコブス大学ブレーメンキャンパスリング1 28725ブレーメンドイツ
EMail: j.schoenwaelder@jacobs-university.de
メールアドレス：j.schoenwaelder@jacobs-university.de