Network Working Group J. Schoenwaelder
Request for Comments: 5343 Jacobs University Bremen
Updates: 3411 September 2008
Category: Standards Track
Simple Network Management Protocol (SNMP) Context EngineID Discovery
簡易ネットワーク管理プロトコル（SNMP）コンテキストENGINEID発見
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.
簡易ネットワーク管理プロトコル（SNMP）バージョン3（SNMPv3）は、アプリケーションがリモートSNMPエンティティに維持するオブジェクトを取得または操作するために、リモートSNMPプロトコルエンジンの識別子（でsnmpEngineIDを）知っている必要があります。
This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.
この文書では、よく知られたlocalEngineIDとリモートSNMPプロトコルエンジンのでsnmpEngineIDを学ぶために使用することができるという発見メカニズムを導入しています。提案されたメカニズムは、SNMPのセキュリティモデルによって提供される機能とは独立しており、また、管理オブジェクトへのアクセスを提供する他のプロトコルインタフェースによって使用されてもよいです。
This document updates RFC 3411.
この文書は、RFC 3411に更新します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Local EngineID . . . . . . . . . . . . . . . . . . . . . . 4
3.2. EngineID Discovery . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
To retrieve or manipulate management information using the third version of the Simple Network Management Protocol (SNMPv3) [RFC3410], it is necessary to know the identifier of the remote SNMP protocol engine, the so-called snmpEngineID [RFC3411]. While an appropriate snmpEngineID can in principle be configured on each management application for each SNMP agent, it is often desirable to discover the snmpEngineID automatically.
簡易ネットワーク管理プロトコル（SNMPv3の）の3番目のバージョン[RFC3410]を使用して管理情報を取得したり操作するために、リモートSNMPプロトコルエンジン、いわゆるのsnmpEngineID [RFC3411]の識別子を知る必要があります。適切なのsnmpEngineIDは原則として各SNMPエージェントの各管理アプリケーション上で設定することができますが、自動的でsnmpEngineIDを発見することが望ましい場合が多いです。
This document introduces a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models. The mechanism has been designed to coexist with discovery mechanisms that may exist in SNMP security models, such as the authoritative engine identifier discovery of the User-based Security Model (USM) of SNMP [RFC3414].
この文書では、リモートSNMPプロトコルエンジンのでsnmpEngineIDを学ぶために使用することができるという発見メカニズムを導入しています。提案されたメカニズムは、SNMPのセキュリティモデルが提供する機能とは無関係です。機構は、SNMP [RFC3414]のユーザーベースのセキュリティモデル（USM）の権威機関識別子の発見として、SNMPのセキュリティモデルで存在することができるディスカバリメカニズムと共存するように設計されています。
This document updates RFC 3411 [RFC3411] by clarifying the IANA rules for the maintenance of the SnmpEngineID format registry.
このドキュメントの更新RFC 3411 [RFC3411]のsnmpEngineID形式レジストリのメンテナンスのためにIANAのルールを明確にすることによって。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Within an administrative domain, an SNMP engine is uniquely identified by an snmpEngineID value [RFC3411]. An SNMP entity, which consists of an SNMP engine and several SNMP applications, may provide access to multiple contexts.
管理ドメイン内に、SNMPエンジンは一意のsnmpEngineID値[RFC3411]によって識別されます。 SNMPエンジンと、いくつかのSNMPアプリケーションで構成SNMPエンティティは、複数のコンテキストへのアクセスを提供することができます。
An SNMP context is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context and an SNMP entity potentially has access to many contexts [RFC3411]. A context is identified by the snmpEngineID value of the entity hosting the management information (also called a contextEngineID) and a context name that identifies the specific context (also called a contextName).
SNMPコンテキストは、SNMPエンティティからアクセス可能な管理情報のコレクションです。管理情報の項目は、複数のコンテキスト内に存在してもよいし、SNMPエンティティは、潜在的に多くの状況[RFC3411]へのアクセスを有します。コンテキストは、管理情報をホストエンティティのsnmpEngineID値によって識別され、（ものcontextName呼ばれる）特定のコンテキストを識別するコンテキスト名（contextEngineIDも呼ばれます）。
To identify an individual item of management information within an administrative domain, a four tuple is used consisting of
管理ドメイン内の管理情報の個々のアイテムを識別するためには、4つのタプルは、以下からなる使用され
The last two elements are encoded in an object identifier (OID) value. The contextName is a character string (following the SnmpAdminString textual convention of the SNMP-FRAMEWORK-MIB [RFC3411]) while the contextEngineID is an octet string constructed according to the rules defined as part of the SnmpEngineID textual convention of the SNMP-FRAMEWORK-MIB [RFC3411].
最後の二つの要素は、オブジェクト識別子（OID）値で符号化されます。 contextEngineIDはSNMP-FRAMEWORK-MIBののsnmpEngineIDテキストの表記法の一部として定義された規則に従って構築オクテットストリングであるのcontextNameは（SNMP-FRAMEWORK-MIB [RFC3411]のれるSnmpAdminStringテキストの表記法以下）の文字列であります[RFC3411]。
The SNMP protocol operations and the protocol data units (PDUs) operate on OIDs and thus deal with object types and instances [RFC3416]. The SNMP architecture [RFC3411] introduces the concept of a scopedPDU as a data structure containing a contextEngineID, a contextName, and a PDU. The SNMP version 3 (SNMPv3) message format uses ScopedPDUs to exchange management information [RFC3412].
SNMPプロトコル操作とプロトコルデータユニット（PDU）は、OIDに動作し、従ってオブジェクトタイプとインスタンス[RFC3416]に対処します。 SNMPアーキテクチャ[RFC3411]はcontextEngineID、contextNameは、およびPDUを含むデータ構造としてたscopedPDUの概念を導入します。 SNMPバージョン3（SNMPv3の）メッセージのフォーマットは、管理情報[RFC3412]を交換するScopedPDUsを使用します。
Within the SNMP framework, contextEngineIDs serve as end-to-end identifiers. This becomes important in situations where SNMP proxies are deployed to translate between protocol versions or to cross middleboxes such as network address translators. In addition, snmpEngineIDs separate the identification of an SNMP engine from the transport addresses used to communicate with an SNMP engine. This property can be used to correlate management information easily, even in situations where multiple different transports were used to retrieve the information or where transport addresses can change dynamically.
SNMPの枠組みの中で、contextEngineIDsは、エンドツーエンドの識別子として機能します。これは、SNMPプロキシは、プロトコルのバージョン間で翻訳したり、そのようなネットワークアドレス変換器としてミドルボックスと交差するように配置されている状況では重要になります。また、snmpEngineIDsは、SNMPエンジンとの通信に使用するトランスポート・アドレスからSNMPエンジンの識別を分離します。このプロパティは、さらに、複数の異なるトランスポートは、情報や場所のトランスポートアドレスを動的に変更することができますを取得するために使用された状況で、簡単に管理情報を相関させるために使用することができます。
To retrieve data from an SNMPv3 agent, it is necessary to know the appropriate contextEngineID. The User-based Security Model (USM) of SNMPv3 provides a mechanism to discover the snmpEngineID of the remote SNMP engine, since this is needed for security processing reasons. The discovered snmpEngineID can subsequently be used as a contextEngineID in a ScopedPDU to access management information local to the remote SNMP engine. Other security models, such as the Transport Security Model (TSM) [TSM], lack such a procedure and may use the discovery mechanism defined in this memo.
SNMPv3エージェントからデータを取得するには、適切なcontextEngineIDを知る必要があります。 SNMPv3のユーザベースセキュリティモデル（USM）これは、セキュリティ処理上の理由から必要とされているため、リモートSNMPエンジンのでsnmpEngineIDを発見するためのメカニズムを提供します。発見のsnmpEngineIDはその後、リモートSNMPエンジンのローカル管理情報にアクセスするたscopedPDUにcontextEngineIDとして使用することができます。そのようなトランスポート・セキュリティモデル（TSM）[TSM]、などの他のセキュリティモデルは、このような手順を欠いており、このメモで定義された発見メカニズムを使用することができます。
The proposed discovery mechanism consists of two parts, namely (i) the definition of a special well-known snmpEngineID value, called the localEngineID, which always refers to a local default context, and (ii) the definition of a procedure to acquire the snmpEngineID scalar of the SNMP-FRAMEWORK-MIB [RFC3411] using the special well-known local localEngineID value.
提案された検出メカニズムは、2つの部分、すなわち（I）の特別な周知のsnmpEngineID値の定義から構成され、常にローカルデフォルトコンテキストを指すlocalEngineIDと呼ばれる、及び（ii）の手順の定義のsnmpEngineIDを取得します特別な周知ローカルlocalEngineID値を使用してSNMP-FRAMEWORK-MIB [RFC3411]のスカラー。
An SNMP command responder implementing this specification MUST register their pduTypes using the localEngineID snmpEngineID value (defined below) by invoking the registerContextEngineID() Abstract Service Interface (ASI) defined in RFC 3412 [RFC3412]. This registration is done in addition to the normal registration under the SNMP engine's snmpEngineID. This is consistent with the SNMPv3 specifications since they explicitly allow registration of multiple engineIDs and multiple pduTypes [RFC3412].
この仕様を実装応答SNMPコマンドは、RFC 3412 [RFC3412]で定義registerContextEngineID（）アブストラクトサービスインターフェイス（ASI）を呼び出すことによってlocalEngineIDのsnmpEngineID値（以下に定義）を使用してpduTypesを登録しなければなりません。この登録は、SNMPエンジンのでsnmpEngineIDの下で通常の登録に加えて行われます。彼らは明示的に複数のengineIDsと複数のpduTypes [RFC3412]の登録を許可するので、これは、SNMPv3の仕様と一致しています。
The SnmpEngineID textual convention [RFC3411] defines that an snmpEngineID value MUST be between 5 and 32 octets long. This specification proposes to use the variable length format 3) of the SnmpEngineID textual convention and to allocate the reserved, unused format value 6, using the enterprise ID 0 for the localEngineID. An ASN.1 definition for localEngineID would look like this:
snmpEngineIDテキストの表記法[RFC3411]はのsnmpEngineID値が長い5および32オクテットの間になければならないことを規定しています。この仕様は、のsnmpEngineIDテキストの表記法の可変長フォーマット3）を使用するとlocalEngineIDのエンタープライズID 0を使用して、予約済み、未フォーマット値6を割り当てることを提案します。 localEngineIDのためのASN.1定義は次のようになります。
localEngineID OCTET STRING ::= '8000000006'H
The localEngineID value always provides access to the default context of an SNMP engine. Note that the localEngineID value is intended to be used as a special value for the contextEngineID field in the ScopedPDU. It MUST NOT be used as a value to identify an SNMP engine; that is, this value MUST NOT be used in the snmpEngineID.0 scalar [RFC3418] or in the msgAuthoritativeEngineID field in the securityParameters of the User-based Security Model (USM) [RFC3414].
localEngineID値は常にSNMPエンジンのデフォルトのコンテキストへのアクセスを提供します。 localEngineID値がたscopedPDUにcontextEngineIDフィールドの特殊値として使用されることが意図されていることに留意されたいです。 SNMPエンジンを識別するための値として使用してはいけません。つまり、この値は、ユーザベースのセキュリティモデル（USM）[RFC3414]のsecurityParametersにsnmpEngineID.0スカラー[RFC3418]またはmsgAuthoritativeEngineIDフィールドで使用してはいけません。
Discovery of the snmpEngineID is done by sending a Read Class protocol operation (see Section 2.8 of [RFC3411]) to retrieve the snmpEngineID scalar using the localEngineID defined above as a contextEngineID value. Implementations SHOULD only perform this discovery step when it is needed. In particular, if security models are used that already discover the remote snmpEngineID (such as USM), then no further discovery is necessary. The same is true in situations where the application already knows a suitable snmpEngineID value.
snmpEngineIDの発見はcontextEngineID値を上記のように定義localEngineIDを使用してのsnmpEngineIDスカラーを取得する（[RFC3411]のセクション2.8を参照）を読むクラスプロトコルオペレーションを送信することによって行われます。それが必要とされるとき、実装は、この発見ステップを実行する必要があります。セキュリティモデルが使用される場合、特に、既に（例えばUSMのように）リモートのsnmpEngineIDを発見すること、次いで、更なる発見は必要ではありません。同じことは、アプリケーションがすでに、適切なのsnmpEngineID値を知っている状況では真実です。
The procedure to discover the snmpEngineID of a remote SNMP engine can be described as follows:
次のようにリモートSNMPエンジンのsnmpEngineIDを発見する手順を記述することができます。
1. Check whether a suitable contextEngineID value is already known. If yes, use the provided contextEngineID value and stop the discovery procedure.
適したcontextEngineID値が既に知られているかどうかを確認してください1.。そうならば、提供contextEngineID値を使用し、発見手順を停止します。
2. Check whether the selected security model supports discovery of the remote snmpEngineID (e.g., USM with its discovery mechanism). If yes, let the security model perform the discovery. If the remote snmpEngineID value has been successfully determined, assign it to the contextEngineID and stop the discovery procedure.
選択されたセキュリティモデルは、リモートのsnmpEngineIDの発見をサポートしているかどうか2.チェック（例えば、USMその発見機構付）。そうならば、セキュリティモデルは、検出を実行してみましょう。リモートのsnmpEngineID値が正常と判定された場合は、contextEngineIDにそれを割り当て、発見手順を停止します。
3. Send a Read Class operation to the remote SNMP engine using the localEngineID value as the contextEngineID in order to retrieve the scalar snmpEngineID.0 of the SNMP-FRAMEWORK-MIB [RFC3411]. If successful, set the contextEngineID to the retrieved value and stop the discovery procedure.
3. SNMP-FRAMEWORK-MIB [RFC3411]のスカラーsnmpEngineID.0を取得するためにcontextEngineIDとしてlocalEngineID値を使用してリモートSNMPエンジンに読む級動作を送ります。成功した場合、取得した値にcontextEngineIDを設定し、発見手順を停止します。
4. Return an error indication that a suitable contextEngineID could not be discovered.
4.適したcontextEngineIDを発見することができませんでしたエラー表示を返します。
The procedure outlined above is an example and can be modified to retrieve more variables in step 3, such as the sysObjectID.0 scalar or the snmpSetSerialNo.0 scalar of the SNMPv2-MIB [RFC3418].
上記で概説した手順は一例であり、このようなsysObjectID.0スカラーとSNMPv2-MIB [RFC3418]のsnmpSetSerialNo.0スカラーとしてステップ3において複数の変数を取得するために修飾することができます。
RFC 3411 requested that IANA create a registry for SnmpEngineID formats. However, RFC 3411 did not ask IANA to record the initial assignments made by RFC 3411 nor did RFC 3411 spell out the precise allocation rules. To address this issue, the following rules are hereby established.
RFC 3411は、IANAがでsnmpEngineID形式のレジストリを作成することを要求しました。しかし、RFC 3411は、RFC 3411で作られた最初の割り当てを記録するためにIANAを要求していないにもRFC 3411には、正確な割り当て規則を綴るんでした。この問題に対処するには、次の規則をここに確立されています。
IANA maintains a registry for SnmpEngineID formats. The first four octets of an SnmpEngineID carry an enterprise number, while the fifth octet in a variable length SnmpEngineID value, called the format octet, indicates how the following octets are formed. The following format values were allocated in [RFC3411]:
IANAはのsnmpEngineID形式のレジストリを維持します。 snmpEngineIDの最初の4つのオクテットは、可変長のsnmpEngineID値の第五のオクテットは、フォーマットオクテットと呼ばれながら、次のオクテットが形成されているかを示す、エンタープライズ番号を運びます。次の形式の値は[RFC3411]に割り当てられました：
Format Description References
------- ----------- ----------
0 reserved, unused [RFC3411]
1 IPv4 address [RFC3411]
2 IPv6 address [RFC3411]
3 MAC address [RFC3411]
4 administratively assigned text [RFC3411]
5 administratively assigned octets [RFC3411]
6-127 reserved, unused [RFC3411]
128-255 enterprise specific [RFC3411]
IANA can assign new format values out of the originally assigned and reserved number space 1-127. For new assignments in this number space, a specification is required as per [RFC5226]. The number space 128-255 is enterprise specific and is not controlled by IANA.
IANAは、もともと割り当てられ、予約番号空間1-127のうち、新しい形式の値を割り当てることができます。この数空間における新たな割り当てのために、仕様は[RFC5226]に従って必要とされます。番号空間128-255は、企業固有のものであり、IANAによって制御されていません。
Per this document, IANA has made the following assignment:
このドキュメントごとに、IANAは、次の割り当てを行っています。
Format Description References
------- ----------- ----------
6 local engine [RFC5343]
SNMP version 3 (SNMPv3) provides cryptographic security to protect devices from unauthorized access. This specification recommends use of the security services provided by SNMPv3. In particular, it is RECOMMENDED to protect the discovery exchange.
SNMPバージョン3（SNMPv3）は、不正なアクセスからデバイスを保護するための暗号化セキュリティを提供します。この仕様は、SNMPv3のが提供するセキュリティ・サービスを使用することを推奨しています。特に、発見交換を保護することをお勧めします。
An snmpEngineID can contain information such as a device's MAC address, IPv4 address, IPv6 address, or administratively assigned text. An attacker located behind a router / firewall / network address translator may not be able to obtain this information directly, and he therefore might discover snmpEngineID values in order to obtain this kind of device information.
snmpEngineIDは、デバイスのMACアドレス、IPv4アドレス、IPv6アドレス、または管理上割り当てられたテキストなどの情報を含めることができます。ルータ/ファイアウォール/ネットワークアドレス変換器の背後にある攻撃者がこの情報を直接入手することができないかもしれない、と彼はそのため、デバイスのこの種の情報を得るためにでsnmpEngineID値を発見するかもしれません。
In many environments, making snmpEngineID values accessible via a security level of noAuthNoPriv will benefit legitimate tools that try to algorithmically determine some basic information about a device. For this reason, the default View-based Access Control Model (VACM) configuration in Appendix A of RFC 3415 [RFC3415] gives noAuthNoPriv read access to the snmpEngineID. Furthermore, the USM discovery mechanism defined in RFC 3414 [RFC3414] uses unprotected messages and reveals snmpEngineID values.
多くの環境では、noAuthNoPrivというのセキュリティレベルを経由してのsnmpEngineID値がアクセスできるようにすることは、アルゴリズムのデバイスに関する基本的な情報を決定しようとする合法的なツールの利益になります。このため、RFC 3415の付録A [RFC3415]でデフォルトのビューベースアクセス制御モデル（VACM）の構成はnoAuthNoPrivにはでsnmpEngineIDへの読み取りアクセスを提供します。また、USM発見メカニズムは、RFC 3414 [RFC3414]で定義された保護されていないメッセージを使用してのsnmpEngineID値を明らかにする。
In highly secure environments, snmpEngineID values can be protected by using the discovery mechanism described in this document together with a security model that does not exchange cleartext SNMP messages, such as the Transport Security Model (TSM) [TSM].
安全性の高い環境では、のsnmpEngineID値は、このようなトランスポート・セキュリティモデル（TSM）として平文SNMPメッセージ、[TSM]を交換しませんセキュリティモデルと一緒に、この文書で説明する検出メカニズムを使用して保護することができます。
The isAccessAllowed() abstract service primitive of the SNMP access control subsystem does not take the contextEngineID into account when checking access rights [RFC3411]. As a consequence, it is not possible to define a special view for context engineID discovery. A request with a localEngineID is thus treated like a request with the correct snmpEngineID by the access control subsystem. This is inline with the SNMPv3 design where the authenticated identity is the securityName (together with the securityModel and securityLevel information), and transport addresses or knowledge of contextEngineID values do not impact the access-control decision.
アクセス権限をチェックする際にSNMPアクセス制御サブシステムの原始のisAccessAllowed（）抽象的なサービスのアカウントに[RFC3411]をcontextEngineIDを負いません。その結果、コンテキストエンジンID発見のための特別なビューを定義することはできません。 localEngineID有する要求は、このように、アクセス制御サブシステムによって正しいのsnmpEngineIDで要求のように扱われます。これは、認証されたアイデンティティは（一緒にsecurityModelやたsecurityLevel情報付き）のsecurityNameであり、トランスポートアドレスまたはcontextEngineID値の知識は、アクセス制御決定に影響を与えないSNMPv3の設計とインラインです。
Dave Perkins suggested the introduction of a "local" contextEngineID during the interim meeting of the ISMS (Integrated Security Model for SNMP) working group in Boston, 2006. Joe Fernandez, David Harrington, Dan Romascanu, and Bert Wijnen provided helpful review and feedback, which helped to improve this document.
デーヴパーキンスは、ISMSの暫定会議中に「ローカル」contextEngineID（SNMPのための統合セキュリティモデル）の導入ボストンのワーキンググループを提案し、2006年ジョー・フェルナンデス、デヴィッド・ハリントン、ダンRomascanu、およびバートWijnenは役に立つレビューとフィードバックを提供し、これは、このドキュメントを改善するために役立ちました。
[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月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
、STD 62、RFC 3414、2002年12月 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）" [RFC3414]ブルーメンソール、U.とB. Wijnenの、。
[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.、。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[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月。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415] Wijnenの、B.、Presuhn、R.、およびK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（VACM）（SNMP）"、STD 62、RFC 3415、2002年12月。
[TSM] Harrington, D., "Transport Security Model for SNMP", Work in Progress, July 2008.
[TSM]ハリントン、D.、 "SNMPのためのトランスポート・セキュリティモデル"、進歩、2008年7月に作業。
Author's Address
著者のアドレス
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
ユルゲンSchoenwaelderジェイコブス大学ブレーメンキャンパスリング1 28725ブレーメンドイツ
Phone: +49 421 200-3587 EMail: j.schoenwaelder@jacobs-university.de
電話：+49 421 200-3587 Eメール：j.schoenwaelder@jacobs-university.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。