[要約] RFC 5343は、SNMPコンテキストエンジンIDの発見に関する標準仕様であり、SNMPエージェントのエンジンIDを特定するための手法を提供します。このRFCの目的は、SNMPベースのネットワーク管理システムがエージェントのエンジンIDを正確に特定できるようにすることです。
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 Discovery
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.
このドキュメントでは、リモート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.
Simple Network Management Protocol（SNMPV3）[RFC3410]の3番目のバージョンを使用して管理情報を取得または操作するには、リモート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.
このドキュメントは、SNMPENGINEID形式のレジストリのメンテナンスに関するIANAルールを明確にすることにより、RFC 3411 [RFC3411]を更新します。
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]。コンテキストは、管理情報（ContextEngineIDとも呼ばれます）をホストするエンティティのSNMPENGINEID値と、特定のコンテキスト（コンテキスト名とも呼ばれる）を識別するコンテキスト名によって識別されます。
To identify an individual item of management information within an administrative domain, a four tuple is used consisting of
管理ドメイン内の個々の管理情報を特定するために、4タプルが使用されています
1. a contextEngineID,
1. ContextEngineID、
2. a contextName, 3. an object type, and
2. コンテキスト名、3。オブジェクトタイプ、および
4. its instance identification.
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].
最後の2つの要素は、オブジェクト識別子（OID）値でエンコードされます。ContextNameは文字文字列です（SNMP-FrameWork-Mib [RFC3411]のsnmpadminstringテキスト条約に続く）contextengineidは、snmp-framework-mibのsnmpengineidテキスト条約の一部として定義されたルールに従って構築されたオクテット文字列です。[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）メッセージ形式では、ScopedPDUSを使用して管理情報[RFC3412]を交換します。
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フレームワーク内では、コンテキストエンジンIDSはエンドツーエンドの識別子として機能します。これは、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は、その後、ScopedPDUのContextEngineIDとして使用して、リモートSNMPエンジンにローカルな管理情報にアクセスできます。トランスポートセキュリティモデル（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.
提案された発見メカニズムは、（i）常にローカルデフォルトコンテキストを指すLocalEngineIDと呼ばれる特別な有名なSNMPengineID値の定義、および（ii）SNMPengineIDを取得する手順の定義を指す2つの部分で構成されています。特別な有名なローカルエンジンの値を使用して、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（）Abstract Service Interface（ASI）を呼び出すことにより、LocalEngineID SNMPengineID値（以下に定義）を使用してPDUTypesを登録する必要があります。この登録は、SNMPエンジンのSNMPENGINEIDに基づく通常の登録に加えて行われます。これは、SNMPV3仕様と一致しています。これは、複数のEngineIDと複数のPDUTYPE [RFC3412]の登録を明示的に許可するためです。
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エンジンを識別する値として使用してはなりません。つまり、この値は、SNMPENGINEID.0スカラー[RFC3418]またはユーザーベースのセキュリティモデル（USM）[RFC3414]のセキュリティパラメーターの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を参照）を送信することによって行われます。実装は、必要な場合にのみこの発見ステップを実行する必要があります。特に、リモートSNMPENGINEID（USMなど）をすでに発見したセキュリティモデルが使用されている場合、それ以上の発見は必要ありません。同じことが、アプリケーションが既に適切な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.
1. 適切なContextEngineID値が既にわかっているかどうかを確認してください。はいの場合、提供された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.
2. 選択したセキュリティモデルがリモートSNMPENGINEIDの発見をサポートしているかどうかを確認します（たとえば、その発見メカニズムを備えた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値を使用して、Remote 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のSNMPSETSERIALNO.0スカラーなど、ステップ3でより多くの変数を取得するように変更できます[RFC3418]。
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は、IANAにRFC 3411による最初の割り当てを記録するように依頼しませんでした。また、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オクテットにはエンタープライズ番号がありますが、Forable Lengs Snmpengineid値の5番目のオクテットは、フォーマットOctetと呼ばれ、次のオクテットの形成方法を示します。次の形式の値は[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]に従って仕様が必要です。Number Space 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.
多くの環境では、SNMPENGINEID値をセキュリティレベルのNOAUTHNOPRIVでアクセスできるようにすると、デバイスに関する基本情報をアルゴリズム的に決定しようとする合法的なツールに利益をもたらします。このため、RFC 3415 [RFC3415]の付録Aのデフォルトのビューベースのアクセス制御モデル（VACM）構成により、noAuthnoprivはsnmpengineidへの読み取りアクセスを提供します。さらに、RFC 3414 [RFC3414]で定義されたUSM発見メカニズムは、保護されていないメッセージを使用し、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値を保護でき、ClearText SNMPメッセージを交換しないセキュリティモデル（Transports Security Model（TSM）[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（）要約サービスプリミティブは、アクセス権をチェックする際にContextEngineIDを考慮しません[RFC3411]。結果として、コンテキストEngineID発見の特別なビューを定義することはできません。したがって、LocalEngineIDを使用したリクエストは、Access Controlサブシステムによって正しいSNMPengineIDを使用したリクエストのように扱われます。これは、認証されたアイデンティティがセキュリティ名（SecurityModelおよびSecurityLevel情報とともに）であるSNMPV3デザインとインラインで、ContextEngineID値の輸送住所または知識がアクセス制御の決定に影響を与えません。
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.
Dave Perkinsは、2006年ボストンで開催されたISMS（SNMPの統合セキュリティモデル）ワーキンググループの暫定会議中に「ローカル」コンテキストエンジンの導入を提案しました。このドキュメントの改善に役立ちました。
[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.、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] Case、J.、Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）のメッセージ処理とディスパッチ」、2002年12月、STD 62、RFC 3412、RFC 3412。
[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.
[RFC3414] Blumenthal、U.およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、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。、「Simple Network Management Protocol（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] Presuhn、R。、「単純なネットワーク管理プロトコル（SNMP）の管理情報基盤（MIB）」、STD 62、RFC 3418、2002年12月。
[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] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、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、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、2002年12月、RFC 3415、RFC 3415。
[TSM] Harrington, D., "Transport Security Model for SNMP", Work in Progress, July 2008.
[TSM] Harrington、D。、「SNMPの輸送セキュリティモデル」、2008年7月の進行中の作業。
Author's Address
著者の連絡先
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725ブレーメンドイツ
Phone: +49 421 200-3587
EMail: j.schoenwaelder@jacobs-university.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。