Network Working Group D. Black
Request for Comments: 4088 EMC Corporation
Category: Standards Track K. McCloghrie
Cisco Systems
J. Schoenwaelder
International University Bremen
June 2005
Uniform Resource Identifier (URI) Scheme for the
Simple Network Management Protocol (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) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.
簡易ネットワーク管理プロトコル（SNMP）とインターネット標準管理フレームワークは、広く非SNMP管理環境から（SNMP MIBオブジェクトインスタンスへのアクセスを含む）SNMPアクセスを指定する必要が作成し、通信機器の管理に使用されています。アウトオブバンドIP管理が（例えば、インバンドIPアクセスをサポートしていないデバイスのために）別の管理インターフェースを介して使用される場合、例えば、管理するための装置に連絡する方法を示すための統一された方法が必要です。ユニフォームリソース識別子（URI）、彼らはIPベースのプロトコルの多種多様のための管理アクセス通信エンドポイントを示すために、単一のテキスト文字列を許可するよう、よくこのニーズに合います。
This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances.
SNMPは、管理のために使用されるプロトコルとして指定することができるように、この文書は、URIスキームを定義します。スキームはまた、URIは、1つ以上のMIBオブジェクトインスタンスを指定することを可能にします。
Table of Contents
目次
1. Introduction.................................................. 2
2. Usage......................................................... 3
3. Syntax of an SNMP URI......................................... 4
3.1. Relative Reference Considerations........................ 5
4. Semantics and Operations...................................... 6
4.1. SNMP Service URIs........................................ 6
4.2. SNMP Object URIs......................................... 7
4.2.1. SNMP Object URI Data Access....................... 8
4.3. OID Groups in SNMP URIs.................................. 10
4.4. Interoperability Considerations.......................... 10
5. Examples...................................................... 11
6. Security Considerations....................................... 12
6.1. SNMP URI to SNMP Gateway Security Considerations......... 13
7. IANA Considerations........................................... 14
8. Normative References.......................................... 14
9. Informative References........................................ 15
10. Acknowledgements............................................. 16
Appendix A. Registration Template................................ 17
SNMP and the Internet-Standard Management Framework were originally devised to manage IP devices via in-band means, in which management access is primarily via the same interface(s) used to send and receive IP traffic. SNMP's wide adoption has resulted in its use for managing communication devices that do not support in-band IP access (e.g., Fibre Channel devices); a separate out-of-band IP interface is often used for management. URIs provide a convenient way to locate that interface and specify the protocol to be used for management; one possible scenario is for an in-band query to return a URI that indicates how the device is managed. This document specifies a URI scheme to permit SNMP (including a specific SNMP context) to be designated as the management protocol by such a URI. This scheme also allows a URI to refer to specific object instances within an SNMP MIB.
SNMPおよびインターネット標準管理フレームワークは、もともと管理アクセスが同じインターフェイス（複数可）を経由して、主である、インバンド手段を介してIPデバイスを管理するために考案されたIPトラフィックを送受信するために使用。 SNMPの幅広い採用は、インバンドIPアクセス（例えば、ファイバチャネルデバイス）をサポートしていない通信機器を管理するためのその使用をもたらしました。別のアウトオブバンドIPインタフェースは、多くの場合、管理のために使用されています。 URIはそのインターフェイスを検索し、管理するために使用されるプロトコルを指定するための便利な方法を提供します。帯域内のクエリは、デバイスが管理されているかを示すURIを返すようにするための1つの可能なシナリオがあります。この文書では、そのようなURIによって管理プロトコルとして指定される（特定のSNMPコンテキストを含む）SNMPを許可するURIスキームを指定します。このスキームはまた、URIはSNMP MIB内の特定のオブジェクトインスタンスを参照することを可能にします。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of [RFC3410].
現在のインターネット標準の管理フレームワークを記述したドキュメントの詳細な概要については、[RFC3410]のセクション7を参照してください。
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]に記載されているように解釈されます。
There are two major classes of SNMP URI usage: configuration and gateways between SNMP and other protocols that use SNMP URIs.
SNMPおよびSNMP URIを使用する他のプロトコル間の構成およびゲートウェイ：SNMP URIの使用法の2つの主要なクラスがあります。
An SNMP URI used for configuration indicates the location of management information as part of the configuration of an application containing an SNMP manager. The URI can be obtained from a configuration file or may be provided by a managed device (see Section 1 for an example). Management information is exchanged between the SNMP manager and agent, but it does not flow beyond the manager, as shown in the following diagram:
URIを構成するために使用されるSNMPは、SNMPマネージャを含むアプリケーションの構成の一部として、管理情報の位置を示します。 URIは、構成ファイルから取得することができ、または管理デバイス（例えば、セクション1を参照）によって提供されてもよいです。次の図に示すように、管理情報は、SNMPマネージャとエージェントの間で交換されるが、それはマネージャーを超えて流れることはありません。
*********** SNMP-Request *********
* *================>* *
URI ---------->* Manager * * Agent *
* *<================* *
*********** SNMP-Response *********
^
|
Other Config Info ------------+
Additional configuration information (e.g., a security secret or key) may be provided via an interface other than that used for the URI. For example, when a managed device provides an SNMP URI in an unprotected fashion, that device should not provide a secret or key required to use the URI. The secret or key should instead be pre-configured in or pre-authorized to the manager; see Section 6.
追加の構成情報（例えば、セキュリティ秘密またはキー）をURIに使用されるもの以外のインターフェイスを介して提供することができます。管理対象デバイスは、保護されていないやり方でSNMP URIを提供する場合、例えば、そのデバイスは、URIを使用するために必要な秘密またはキーを提供してはなりません。秘密鍵または代わりに予め設定されるか、または管理者に事前許可されるべきです。第6章を参照してください。
For gateway usage, clients employ SNMP URIs to request management information via an SNMP URI to SNMP gateway (also called an SNMP gateway in this document). The SNMP manager within the SNMP gateway accesses the management information and returns it to the requesting client, as shown in the following diagram:
ゲートウェイの使用のために、クライアントは、SNMPゲートウェイ（この文書に記載されているSNMPゲートウェイと呼ばれる）にSNMP URIを介して管理情報を要求するSNMP URIを使用します。 SNMPゲートウェイ内のSNMPマネージャは、管理情報にアクセスし、以下の図に示すように、要求元のクライアントに返します。
SNMP gateway
********** URI *********** SNMP-Request *********
* *===========>* *================>* *
* Client * * Manager * * Agent *
* *<===========* *<================* *
********** Info *********** SNMP-Response *********
^
|
Other Config Info ------------+
Additional configuration information (e.g., security secrets or keys) may be provided via an interface other than that used for the URI. For example, some types of security information, including secrets and keys, should be pre-configured in or pre-authorized to the manager rather than be provided by the client; see Section 6.
追加の構成情報（例えば、セキュリティ秘密またはキー）をURIに使用されるもの以外のインターフェイスを介して提供することができます。例えば、秘密およびキーを含むセキュリティ情報のいくつかのタイプは、で事前構成するか、管理者に事前許可ではなく、クライアントによって提供されています。第6章を参照してください。
An SNMP URI has the following ABNF [RFC2234] syntax, based on the ABNF syntax rules for userinfo, host, port, and (path) segment in [RFC3986] and the ABNF syntax rule for HEXDIG in [RFC2234]:
SNMP URIは、ユーザー情報、ホスト、ポート、および[RFC3986]に（パス）セグメントと[RFC2234]でHEXDIGためのABNF構文ルールのABNF構文規則に基づいて、以下のABNF [RFC2234]の構文を有します。
snmp-uri = "snmp://" snmp-authority [ context [ oids ]]
SNMP-URI = "SNMP：//" のsnmp-権限[コンテキスト[OIDは]]
snmp-authority = [ securityName "@" ] host [ ":" port ] securityName = userinfo ; SNMP securityName
SNMP-権限は= [セキュリティ名 "@"]ホスト[ "：" ポート]のsecurityName = userinfoを。 SNMPセキュリティ名
context = "/" contextName [ ";" contextEngineID ] contextName = segment ; SNMP contextName contextEngineID = 1*(HEXDIG HEXDIG) ; SNMP contextEngineID
コンテキスト= "/" のcontextName [ ";" contextEngineID]のcontextName =セグメント。 SNMPのcontextName contextEngineID = 1 *（HEXDIG HEXDIG）。 SNMP contextEngineID
oids = "/" ( oid / oid-group ) [ suffix ] oid-group = "(" oid *( "," oid ) ")" oid = < as specified by [RFC 3061] > suffix = "+" / ".*"
OID = "/"（OID / OIDグループ）[サフィックス] OID基= "（" OID *（ "" OID） "）、" OID = <によって指定されるように、[RFC 3061]>接尾辞= "+" / "*"
The userinfo and (path) segment ABNF rules are reused for syntax only. In contrast, host and port have both the syntax and semantics specified in [RFC3986]. See [RFC3411] for the semantics of securityName, contextEngineID, and contextName.
ユーザー情報と（パス）セグメントABNFルールのみ構文に再利用されます。これとは対照的に、ホストとポートは、[RFC3986]で指定された構文と意味の両方を持っています。セキュリティ名、contextEngineID、とのcontextNameのセマンティクスのために[RFC3411]を参照してください。
The snmp-authority syntax matches the URI authority syntax in Section 3.2 of [RFC3986], with the additional restriction that the userinfo component of an authority (when present) MUST be an SNMP securityName. If the securityName is empty or not given, the entity making use of an SNMP URI is expected to know what SNMP securityName to use if one is required. Inclusion of authentication information (e.g., passwords) in URIs has been deprecated (see Section 3.2.1 of [RFC3986]), so any secret or key required for SNMP access must be provided via other means that may be out-of-band with respect to communication of the URI. If the port is empty or not given, port 161 is assumed.
SNMP-権限構文は、権限（存在する場合）のユーザー情報コンポーネントがSNMPのsecurityNameする必要がある追加の制限、[RFC3986]のセクション3.2にURI権限構文と一致します。セキュリティ名が与えられた空かそうでない場合は、SNMP URIを利用したエンティティは1が必要な場合は、SNMPセキュリティ名を使用するかを知ることが予想されます。 URIの中の認証情報（例えば、パスワード）を含めると、（[RFC3986]の3.2.1項を参照してください）推奨されていませんので、任意の秘密やSNMPアクセスに必要な鍵は、アウト・オブ・バンドであることも、他の手段を介して提供されなければなりませんURIの通信に対して。ポートが指定された空かそうでない場合は、ポート161を想定しています。
If the contextName is empty or not given, the zero-length string ("") is assumed, as it is the default SNMP context. An SNMP contextEngineID is a variable-format binary element that is usually discovered by an SNMP manager. An SNMP URI encodes a contextEngineID as hexadecimal digits corresponding to a sequence of bytes. If the contextEngineID is empty or not given, the context engine is to be discovered by querying the SNMP agent at the specified host and port; see Section 4.1 below. The contextEngineID component of the URI
contextNameが所定空であるかどうか、それがデフォルトSNMPコンテキストであるように、長さゼロの文字列（「」）は、想定しています。 SNMP contextEngineIDは、通常、SNMPマネージャによって発見された可変フォーマットのバイナリ要素です。 SNMP URIは、バイトの配列に対応する16進数としてcontextEngineIDをコードします。 contextEngineIDは、与えられた空かそうでない場合は、コンテキスト・エンジンは、指定されたホストとポートでSNMPエージェントを照会することによって発見されます。以下のセクション4.1を参照してください。 URIのcontextEngineID成分
SHOULD be present if more than one context engine at the designated host and port supports the designated context.
指定されたホストとポートに複数のコンテキスト・エンジンは、指定されたコンテキストをサポートしている場合に存在しなければなりません。
An SNMP URI that designates the default SNMP context ("") MAY end with the "/" character that introduces the contextName component. An SNMP URI MUST NOT end with the "/" character that introduces an oid or oid-group component, as the empty string is not a valid OID for SNMP.
デフォルトのSNMPコンテキストを指定SNMP URIは、（「」）のcontextNameコンポーネントを紹介/「文字で終わるかもしれません」。 SNMP URIは、空の文字列は、SNMPの有効なOIDではないとして、OIDまたはOIDグループコンポーネントを紹介し、「/」文字で終了することはできません。
The encoding rules specified in [RFC3986] MUST be used for SNMP URIs, including the use of percent encoding ("%" followed by two hex digits) as needed to represent characters defined as reserved in [RFC3986] and any characters not allowed in a URI. SNMP permits any UTF-8 character to be used in a securityName or contextName; all multi-byte UTF-8 characters in an SNMP URI MUST be percent encoded as specified in Sections 2.1 and 2.5 of [RFC3986]. These requirements are a consequence of reusing the ABNF syntax rules for userinfo and segment from [RFC3986].
[RFC3986]で指定された符号化規則[RFC3986]に予約済みとして定義されている文字を表すために、必要に応じて（「％」は、2進数字が続く）パーセントエンコーディングの使用を含む、SNMPのURIのために使用しなければならなくて、で許可されていない文字URI。 SNMPは、セキュリティ名またはのcontextNameに使用される任意のUTF-8文字を許可します。セクション2.1で指定して、[RFC3986]の2.5としてSNMP URI内のすべてのマルチバイトUTF-8文字がパーセントコード化しなければなりません。これらの要件は[RFC3986]からユーザー情報とセグメントのABNF構文規則を再利用の結果です。
SNMP URIs will generally be short enough to avoid implementation string-length limits (e.g., that may occur at 255 characters). Such limits may be a concern for large OID groups; relative references to URIs (see Section 4.2 of [RFC3986]) may provide an alternative in some circumstances.
SNMP URIは、一般的に実装文字列の長さの制限を回避するのに十分に短いであろう（例えば、255文字で起こり得ること）。そのような制限は、大OIDグループの懸念であってもよいです。 URIに相対参照は、（[RFC3986]のセクション4.2を参照）、いくつかの状況での代替を提供することができます。
Use of IP addresses in SNMP URIs is acceptable in situations where dependence on availability of DNS service is undesirable or must be avoided; otherwise, IP addresses should not be used (see [RFC1900] for further explanation).
SNMPのURIでのIPアドレスを使用すると、DNSサービスの可用性への依存度が望ましくないか、避けなければならない状況で受け入れ可能です。そうでない場合、IPアドレスは、（更なる説明のために[RFC1900]を参照）を使用すべきではありません。
Use of the SNMP default context (zero-length string) within an SNMP URI can result in a second instance of "//" in the URI, such as the following:
SNMP URI内のSNMPのデフォルトコンテキスト（長さゼロの文字列）の使用は、以下のような、URIで「//」の2番目のインスタンスをもたらすことができます。
snmp://<host>//<oid>
SNMP：// <ホスト> // <OID>
This is allowed by [RFC3986] syntax; if a URI parser does not handle the second "//" correctly, the parser is broken and needs to be fixed. This example is important because use of the SNMP default context in SNMP URIs is expected to be common.
これは、[RFC3986]構文によって許可されています。 URIパーサが第二を処理しない場合は、「//」が正しく、パーサは壊れていると固定する必要があります。 SNMPのURIでのSNMPのデフォルトコンテキストの使用が一般的になることが予想されるため、この例では重要です。
On the other hand, the second occurrence of "//" in an absolute SNMP URI affects usage of relative references to that URI (see Section 4.2 of [RFC3986]) because a "//" at the start of a relative reference always introduces a URI authority component (host plus optional userinfo and/or port; see [RFC3986]). Specifically, a relative
一方、絶対SNMP URIで「//」の第二の発生は、そのURIに対する相対参照の使用に影響を与える（[RFC3986]のセクション4.2を参照）「//」なぜなら相対参照の開始時に常に発表URIの権限コンポーネント（ホストとオプションユーザー情報及び/又はポート; [RFC3986]を参照）。具体的には、相対
reference of the form //<oid2> will not work, because the "//" will cause <oid2> to be parsed as a URI authority, resulting in a syntax error when the parser fails to find a host in <oid2> . To avoid this problem, relative references that start with "//" but do not contain a URI authority component MUST NOT be used. Functionality equivalent to any such forbidden relative reference can be obtained by prefixing "." or ".." to the forbidden relative reference (e.g., ..//<oid2>). The prefix to use depends on the base URI.
「//」は<oid2>は、パーサは<oid2>でホストを見つけるのに失敗した時に構文エラーが生じ、URIの権限として解析されるようになりますので、フォームの参照は// <oid2>、機能しません。この問題を回避するには、「//」で始まるが、URIの権限コンポーネントが含まれていない相対参照を使用してはいけません。そのような禁止相対基準と同等の機能を付けることによって得ることができます「」または ".." 禁止相対参照に（例えば、..// <oid2>）。使用する接頭辞は、ベースURIに依存します。
An SNMP URI that does not include any OIDs is called an SNMP service URI because it designates a communication endpoint for access to SNMP management service. An SNMP URI that includes one or more OIDs is called an SNMP object URI because it designates one or more object instances in an SNMP MIB. The expected means of using an SNMP URI is to employ an SNMP manager to access the SNMP context designated by the URI via the SNMP agent at the host and port designated by the URI.
それはSNMP管理サービスにアクセスするための通信エンドポイントを指定しているため任意のOIDを含んでいないSNMP URIは、SNMPサービスURIと呼ばれています。それはSNMP MIB内の1つまたは複数のオブジェクトインスタンスを指定しているため一の以上のOIDを含んでSNMP URIは、SNMPオブジェクトURIと呼ばれています。 SNMP URIを使用することの予想手段は、URIによって指定されたホストおよびポートでSNMPエージェントを介して、URIによって指定されたSNMPコンテキストにアクセスするためにSNMPマネージャを使用することです。
An SNMP service URI does not designate a data object, but rather an SNMP context to be accessed by a service; the telnet URI scheme [RFC1738] is another example of URIs that designate service access. If the contextName in the URI is empty or not given, "" (the zero-length string) is assumed, as it is the default SNMP context.
SNMPサービスURIは、データオブジェクトを指定しない、むしろSNMPコンテキストは、サービスがアクセスされます。 TelnetのURIスキーム[RFC1738]は、サービスへのアクセスを指定するURIの別の例です。 URI内のcontextNameは、所与の空であるかどうか、「」（長さゼロの文字列）がデフォルトSNMPコンテキストであるとして、想定されます。
If a contextEngineID is given in an SNMP service URI, the context engine that it designates is to be used. If the contextEngineID is empty or not given in the URI, the context engine is to be discovered; the context engine to be used is the one that supports the context designated by the URI. The contextEngineID component of the URI SHOULD be present if more than one context engine at the designated host and port supports the designated context.
contextEngineIDは、SNMPサービスURIで指定された場合、それが指定するコンテキストエンジンが使用されます。 contextEngineIDが空またはURIで与えられていない場合は、コンテキスト・エンジンが発見されます。使用するコンテキスト・エンジンは、URIで指定されたコンテキストをサポートするものです。指定されたホストおよびポートで複数のコンテキストエンジンは、指定されたコンテキストをサポートする場合URIのcontextEngineID成分が存在すべきです。
Many common uses of SNMP URIs are expected to omit (i.e., default) the contextEngineID because they do not involve SNMP proxy agents, which are the most common reason for multiple SNMP context engines to exist at a single host and port. Specifically, when an SNMP agent is local to the network interface that it manages, the agent will usually have only one context engine, in which case it is safe to omit the contextEngineID component of an SNMP URI. In addition, many SNMP agents that are local to a network interface support only the default SNMP context (zero-length string).
SNMP URIの多くの一般的な用途は、それらが単一のホストとポートに存在する複数のSNMPコンテキストエンジンのための最も一般的な理由ですSNMPプロキシエージェントを含まないので（つまり、デフォルト）contextEngineIDを省略することが期待されています。 SNMPエージェントは、それが管理するネットワークインターフェースに対してローカルである場合、具体的に、薬剤は、通常、SNMP URIのcontextEngineID成分を省略しても安全である場合にのみコンテキストエンジンを有することになります。唯一のデフォルトSNMPコンテキスト（長さゼロの文字列）ネットワークインターフェースのサポートにローカルで加えて、多くのSNMPエージェント。
An SNMP object URI contains one or more OIDs. The URI is used by first separating the OID or OID group (including its preceding slash plus any parentheses and suffix) and then processing the resulting SNMP service URI as specified in Section 4.1 (above) to determine the SNMP context to be accessed. The OID or OID group is then used to generate SNMP operations directed to that SNMP context.
SNMPオブジェクトURIは、一の以上のOIDが含まれています。 URIは、最初に（その前のスラッシュプラス任意の括弧とサフィックスを含む）OIDまたはOIDグループを分離した後、4.1項（上記）で指定されるようにアクセスするSNMPコンテキストを決定するために、得られたSNMPサービスURIを処理することにより使用されます。 OIDまたはOIDグループは、そのSNMPコンテキストに向けSNMP動作を生成するために使用されます。
The semantics of an SNMP object URI depend on whether the OID or OID group has a suffix and what that suffix is. There are three possible formats; in each case, the MIB object instances are designated within the SNMP context specified by the service URI portion of the SNMP object URI. The semantics of an SNMP object URI that contains a single OID are as follows:
SNMPオブジェクトURIのセマンティクスは、OIDまたはOIDグループは接尾辞と何という接尾辞があるがあるかどうかによって異なります。三つの可能なフォーマットがあります。各場合において、MIBオブジェクトインスタンスは、SNMPオブジェクトURIのサービスURI部によって指定されたSNMPコンテキスト内で指定されています。次のように単一のOIDが含まれているSNMPオブジェクトURIの意味は以下のとおりです。
(1) An OID without a suffix designates the MIB object instance named by the OID.
（1）サフィックスなしのOIDは、OIDによって指定されたMIBオブジェクトのインスタンスを指定します。
(2) An OID with a "+" suffix designates the lexically next MIB object instance following the OID.
（2）「+」接尾辞OIDは、OID以下字句次のMIBオブジェクトのインスタンスを指定します。
(3) An OID with a ".*" suffix designates the set of MIB object instances for which the OID is a strict lexical prefix; this does not include the MIB object instance named by the OID.
（3）とのOIDサフィックスは、OIDが厳しい語彙接頭されたMIBオブジェクトインスタンスのセットを指定します「*。」;これはOIDで指定されたMIBオブジェクトのインスタンスが含まれていません。
An OID group in an SNMP URI consists of a set of OIDs in parentheses. In each case, the OID group semantics are the extension of the single OID semantics to each OID in the group (e.g., a URI with a "+" suffix designates the set of MIB object instances consisting of the lexically next instance for each OID in the OID group).
SNMP URIでのOIDグループは、括弧内のOIDのセットで構成されます。各場合において、OIDグループセマンティクスは、例えば、「+」接尾辞URIは、各OIDにするための字句の次のインスタンスからなるMIBオブジェクトインスタンスのセットを指定する（グループ内の各OIDに単一OIDセマンティクスの拡張でありますOIDグループ）。
When there is a choice among URI formats to designate the same MIB object instance or instances, the above list is in order of preference (no suffix is most preferable), as it runs from most precise to least precise. This is because an OID without a suffix precisely designates an object instance, whereas a "+" suffix designates the next object instance, which may change, and the ".*" suffix could designate multiple object instances. Multiple syntactically distinct SNMP URIs SHOULD NOT be used to designate the same MIB object instance or set of instances, as this may cause unexpected results in URI-based systems that use string comparison to test URIs for equality.
同じMIBオブジェクトインスタンスまたはインスタンスを指定するURIフォーマットのうちの選択がある場合、それは最も正確から少なくとも正確に実行されるように、上記のリストは、（接尾辞が最も好ましいない）優先順位です。 「+」接尾辞が変更される可能性があり、次のオブジェクトのインスタンスを指定するのに対し、サフィックスなしのOIDを正確に、オブジェクトのインスタンスを指定し、「*」サフィックスは、複数のオブジェクトインスタンスを指定する可能性があるためです。これは等価のURIをテストするために、文字列比較を使用してURIベースのシステムで予期しない結果を引き起こす可能性として複数の構文的に異なるSNMP URIは、同じMIBオブジェクトインスタンスまたはインスタンスのセットを指定するために用いるべきではありません。
SNMP object URIs designate the data to be accessed, as opposed to the specific SNMP operations to be used for access; Section 4.2.1 provides examples of how SNMP operations can be used to access data for SNMP object URIs. Nonetheless, any applicable SNMP operation, including GetBulk, MAY be used to access data for all or part of one or more SNMP object URIs (e.g., via use of multiple variable bindings in a single operation); it is not necessary to use the specific operations described in Section 4.2.1 as long as the results (returned variable bindings or error) could have been obtained by following Section 4.2.1's descriptions. The use of relative references that do not change the contextName (i.e., ./<oid>) should be viewed as a hint that optimization of SNMP access across multiple SNMP URIs may be possible.
アクセスに使用される特定のSNMP操作とは対照的に、SNMPオブジェクトのURIは、データにアクセスする指定します。 4.2.1は、SNMP操作がSNMPオブジェクトのURIのデータにアクセスするために使用することができる方法の例を提供します。それにもかかわらず、のGetBulkを含む任意の適用可能なSNMP動作は、（単一の操作で複数の変数のバインディングの使用を介して、例えば、）は、1つ以上のSNMPオブジェクトのURIの全部または一部のデータをアクセスするために使用され得ます。限り結果（返される変数バインディングまたはエラー）が4.2.1項の説明に従うことによって得られている可能性があるので、セクション4.2.1に記載されている特定の操作を使用する必要はありません。 contextName（すなわち、./ <OID>）を変更しない相対参照の使用は、複数のSNMPのURIを横切るSNMPアクセスの最適化が可能であり得ることをヒントとして見られるべきです。
An SNMP object URI MAY also be used to specify a MIB object instance or instances to be written; this causes generation of an SNMP Set operation instead of a Get. The "+" and ".*" suffixes MUST NOT be used in this case; any attempt to do so is an error that MUST NOT generate any SNMP Set operations. Values to be written to the MIB object instance or instances are not specified within an SNMP object URI.
SNMPオブジェクトURIはまた、MIBオブジェクトインスタンスまたはインスタンス書き込み対象を指定するために使用されるかもしれません。これは、代わりのGetのSNMP Set操作を発生させます。 「*」「+」と接尾辞は、この場合には使用してはいけません。そうしようとすると、任意のSNMP Set操作を生成してはならないエラーです。 MIBオブジェクトインスタンスまたはインスタンスに書き込まれる値は、SNMPオブジェクトURI内で指定されていません。
SNMP object URIs designate data in SNMP MIBs and hence do not provide the means to generate all possible SNMP protocol operations. For example, data access for an SNMP object URI cannot directly generate either Snmpv2-Trap or InformRequest notifications, although side effects of data access could cause such notifications (depending on the MIB). In addition, whether and how GetBulk is used for an SNMP object URI with a ".*" suffix is implementation specific.
SNMPオブジェクトのURIは、SNMP MIBの中のデータを指定し、したがって、すべての可能なSNMPプロトコルの動作を生成する手段を提供しません。データ・アクセスの副作用は（MIBに応じて）、そのような通知を引き起こす可能性があるが、例えば、データアクセスSNMPオブジェクトのURIを直接、SNMPv2のトラップまたはInformRequest通知のいずれかを生成することができません。そしてどのようにのGetBulkがSNMPオブジェクトに使用されているかどうかを加えて、「*」サフィックスを持つURIは実装固有のものです。
Data access based on an SNMP object URI returns an SNMP variable binding for each MIB object instance designated by the URI, or an SNMP error if the operation fails. An SNMP variable binding binds a variable name (OID) to a value or an SNMP exception (see [RFC3416]). The SNMP operation or operations needed to access data designated by an SNMP object URI depend on the OID or OID group suffix or absence thereof. The following descriptions are not the only method of performing data access for an SNMP object URI; any suitable SNMP operations may be used as long as the results (returned variable bindings or error) are functionally equivalent.
データアクセス動作が失敗した場合、URIは、URIによって指定された各MIBオブジェクトインスタンスの結合SNMP変数、またはSNMPエラーを返すSNMPオブジェクトに基づきます。 SNMP変数バインディングは、（[RFC3416]を参照）の値またはSNMPの例外変数名（OID）に結合します。 SNMP操作またはSNMPオブジェクトURIによって指定されたデータにアクセスするために必要な操作は、そのOIDまたはOIDグループ接尾辞または不在に依存します。以下の説明は、SNMPオブジェクトURIのデータアクセスを実行する唯一の方法ではありません。結果は、機能的に等価である（変数バインディングまたはエラーを返した）のような任意の適切なSNMP操作があれば使用することができます。
(1) For an OID or OID group without a suffix, an SNMP Get operation is generated using each OID as a variable binding name. If an SNMP error occurs, that error is the result of URI data access; otherwise, the returned variable binding or bindings are the result of URI data access. Note that any returned variable binding may contain an SNMP "noSuchObject" or "noSuchInstance" exception.
（1）サフィックスなしOIDまたはOIDグループの場合、SNMP操作が変数バインディング名として各OIDを使用して生成される取得します。 SNMPエラーが発生した場合、そのエラーはURIデータアクセスの結果です。それ以外の場合は、返される変数バインディングまたはバインディングがURIデータアクセスの結果です。いずれかの変数バインディングは、SNMP「noSuchObject」または「noSuchInstance」の例外を含むことが返されていることに注意してください。
(2) For an OID or OID group with a "+" suffix, an SNMP GetNext operation is generated using each OID as a variable binding name. If an SNMP error occurs, that error is the result of URI data access; otherwise, the returned variable binding or bindings are the result of URI data access. Note that any returned variable binding may contain an SNMP "endOfMibView" exception.
（2）「+」接尾辞OIDまたはOIDグループの場合、SNMP GETNEXT操作は、変数バインディング名として各OIDを使用して生成されます。 SNMPエラーが発生した場合、そのエラーはURIデータアクセスの結果です。それ以外の場合は、返される変数バインディングまたはバインディングがURIデータアクセスの結果です。いずれかの変数バインディングは、SNMP「endOfMibView」例外が含まれていてもよい戻っていることに注意してください。
(3) For an OID or OID group with a ".*" suffix, an SNMP GetNext operation is initially generated using each OID as a variable binding name. If the result is an SNMP error, that error is the result of URI data access. If all returned variable bindings contain either a) an OID for which the corresponding URI OID is not a lexical prefix or b) an SNMP "endOfMibView" exception, then the returned variable bindings are the result of URI data access.
（3）「*」接尾辞OIDまたはOIDグループの場合、SNMP GETNEXT操作は、最初の変数バインディング名として各OIDを使用して生成されます。結果は、SNMPエラーがある場合は、そのエラーはURIデータアクセスの結果です。すべての変数バインディングは、対応するURI OIDは、字句プレフィックスまたはb）SNMP「endOfMibView」例外されていないa）のOIDのいずれかが含まれて返された場合、返される変数バインディングがURIデータアクセスの結果です。
Otherwise, the results of the GetNext operation are saved, and
another SNMP GetNext operation is generated using the newly
returned OIDs as variable binding names. This is repeated
(save the results and generate a GetNext with newly returned
OIDs as variable binding names) until all the returned
variable bindings from a GetNext contain either a) an OID for
which the corresponding URI OID is not a lexical prefix or b)
an SNMP "endOfMibView" exception. The results from all of the
GetNext operations are combined to become the overall result
of URI data access; this may include variable bindings whose
OID is not a lexical extension of the corresponding URI OID.
If the OID subtrees (set of OIDs for which a specific URI OID
is a lexical prefix) are not the same size for all OIDs in the
OID group, the largest subtree determines when this iteration
ends. SNMP GetBulk operations MAY be used to optimize this
iterated access.
Whenever a returned variable binding contains an OID for which the corresponding URI OID is not a lexical prefix or an SNMP "endOfMibView" exception, iteration of that element of the OID group MAY cease, reducing the number of variable bindings used in subsequent GetNext operations. In this case, the results of URI data access for the SNMP URI will not consist entirely of OID-group-sized sets of variable bindings. Even if this does not occur, the last variable binding returned for each member of the OID group will generally contain an SNMP "endOfMibView" exception or an OID for which the corresponding URI OID is not a lexical prefix.
返される変数バインディングは、対応するURI OIDが語彙プレフィックスまたはSNMP「endOfMibView」例外されていないOIDが含まれているときはいつでも、OID群の要素の反復は、後続のGetNextの操作に使用される変数バインディングの数を減らす、止めてもよいです。この場合、SNMP URIのURIデータアクセスの結果は、変数バインディングのOIDグループサイズのセットから完全に構成されません。これが発生していない場合であっても、バインディングはOIDグループの各メンバーのために返される最後の変数は、一般的にSNMP「endOfMibView」例外または対応するURI OIDは字句プレフィックスされていないOIDが含まれます。
Parenthesized OID groups in SNMP URIs are intended to support MIB object instances for which access via a single SNMP operation is required to ensure consistent results. Therefore, the OIDs within an OID group in an SNMP URI SHOULD be accessed by a single SNMP operation containing a variable binding corresponding to each OID in the group. A specific example involves the InetAddress and InetAddressType textual conventions defined in [RFC4001], for which the format of an InetAddress instance is specified by an associated InetAddressType instance. If two such associated instances are read via separate SNMP operations, the resulting values could be inconsistent (e.g., due to an intervening Set), causing the InetAddress value to be interpreted incorrectly.
SNMPのURIにおける括弧OIDグループは、単一のSNMP操作を介してアクセスするためのMIBオブジェクトインスタンスをサポートすることを意図している一貫性のある結果を確保するために必要とされます。したがって、SNMP URIでOIDグループ内のOIDは、グループ内の各OIDに対応するバインディング変数を含む単一のSNMP動作によってアクセスされるべきです。特定の例では、InetAddressのインスタンスの形式が関連付けられたInetAddressTypeインスタンスで指定された[RFC4001]で定義のInetAddressとInetAddressTypeのテキストの表記法を、含みます。二つのそのような関連するインスタンスが別のSNMP操作を介して読み出されている場合、結果の値は、InetAddressの値が誤って解釈させる、（による介在設定する、例えば）矛盾する可能性があります。
This single operation requirement ("SHOULD") also applies to each OID group resulting from iterated access for an SNMP URI with a ".*" suffix. When members of an SNMP URI OID group differ in the number of OIDs for which each is a lexical prefix, this iteration may overrun by returning numerous variable bindings for which the corresponding OID in the OID group is not a lexical prefix. Such overrun can be avoided by using relative references within the same context (i.e., ./<oid>.* ) when it is not important to access multiple MIB object instances in a single SNMP operation.
この単一の動作要件は、（「SHOULD」）も「*」サフィックスを持つSNMP URIのための反復アクセスによって生じる各OIDのグループに適用されます。 SNMP OID URIグループのメンバーは、それぞれ語彙接頭されたOIDの数が異なる場合、この反復は、OIDグループに対応するOIDは字句プレフィックスされていない多数の変数バインディングを返すことによって、オーバーランしてもよいです。そのようなオーバーランは、単一のSNMP操作で複数のMIBオブジェクトインスタンスにアクセスすることが重要でない場合、同じコンテキスト（すなわち、./<oid>.*）内の相対参照を使用することによって回避することができます。
This document defines a transport-independent "snmp" scheme that is intended to accommodate SNMP transports other than UDP. UDP is the default transport for access to information specified by an SNMP URI for backward compatibility with existing usage, but other transports MAY be used. If more than one transport can be used (e.g., SNMP over TCP [RFC3430] in addition to SNMP over UDP), the information or SNMP service access designated by an SNMP URI SHOULD NOT depend on which transport is used (for SNMP over TCP, this is implied by Section 2 of [RFC3430]).
この文書では、SNMPは、UDP以外のトランスポートに対応することを意図しているトランスポートに依存しない「SNMP」のスキームを定義します。 UDPは、既存の用法との後方互換性のためにSNMP URIで指定された情報にアクセスするためのデフォルトのトランスポートですが、他のトランスポートを使用することができます。複数のトランスポートは（UDP上のSNMPに加えて、TCP経由例えば、SNMP [RFC3430]）を使用することができる場合は、SNMP URIで指定された情報や、SNMPサービスのアクセスは、TCP上でSNMPのために（使用される輸送に依存してはなりませんこれは、[RFC3430]のセクション2によって暗示されています）。
An SNMP URI designates use of SNMPv3 as specified by [RFC3416], [RFC3417], and related documents, but older versions of SNMP MAY be used in accordance with [RFC3584] when usage of such older versions is unavoidable. For SNMPv1 and SNMPv2c, the securityName, contextName, and contextEngineID elements of an SNMP URI are mapped to/from the community name, as described in [RFC3584]. When the community name is kept secret as a weak form of authentication, this mapping should be configured so that these three elements do not reveal information about the community name. If this is not done, then any SNMP URI component that would disclose significant information about a secret community name SHOULD be omitted. Note that some community names contain reserved characters (e.g., "@") that require percent encoding when they are used in an SNMP URI. SNMP versions (e.g., v3) have been omitted from the SNMP URI scheme to permit use of older versions of SNMP, as well as any possible future successor to SNMPv3.
SNMP URIは、[RFC3416]、[RFC3417]、および関連するドキュメントで指定され、そのような古いバージョンの使用が避けられない場合、SNMPの古いバージョンは[RFC3584]に従って使用することができるとしてのSNMPv3の使用を指定します。 [RFC3584]に記載されているようにSNMPv1とSNMPv2cの、セキュリティ名、のcontextName、およびSNMP URIのcontextEngineID要素に対して、コミュニティ名に/からマップされます。コミュニティ名は、認証の弱い形として秘密にされている場合、これらの三つの要素は、コミュニティ名に関する情報を明らかにしないように、このマッピングを設定する必要があります。これを行わない場合には、秘密のコミュニティ名に関する重要な情報を開示する任意のSNMP URIコンポーネントは省略する必要があります。いくつかのコミュニティ名は、予約文字が含まれていることに注意してください（例えば、「@」）これらはSNMP URIで使用されている場合パーセントエンコーディングを必要とします。 （例えば、V3）SNMP URIスキームから省略されているSNMPのバージョンはSNMPの旧バージョンと同様に、SNMPv3のすべての可能な将来の後継者の使用を許可します。
snmp://example.com
SNMP：//example.com
This example designates the default SNMP context at the SNMP agent at port 161 of host example.com .
この例では、ホストexample.comのポート161でSNMPエージェントのデフォルトSNMPコンテキストを指定します。
snmp://tester5@example.com:8161
SNMP：//tester5@example.com：8161
This example designates the default SNMP context at the SNMP agent at port 8161 of host example.com and indicates that the SNMP securityName "tester5" is to be used to access that agent. A possible reason to use a non-standard port is for testing a new version of SNMP agent code.
この例では、ホストexample.comのポート8161でのSNMPエージェントのデフォルトSNMPコンテキストを指定し、SNMPセキュリティ名「tester5」はそのエージェントにアクセスするために使用されることを示します。非標準のポートを使用することが可能な理由は、SNMPエージェントコードの新しいバージョンをテストするためです。
snmp://example.com/bridge1
SNMP：//example.com/bridge1
This example designates the "bridge1" SNMP context at example.com. Because the contextEngineID component of the URI is omitted, there SHOULD be at most one SNMP context engine at example.com that supports the "bridge1" context.
この例ではexample.comで「bridge1」SNMPコンテキストを指定します。 URIのcontextEngineIDコンポーネントが省略されているので、「bridge1」コンテキストをサポートしていexample.comで最大1つのSNMPコンテキスト・エンジンがあるはずです。
snmp://example.com/bridge1;800002b804616263
SNMP：//example.com/bridge1; 800002b804616263
This example designates the "bridge1" context at snmp.example.com via the SNMP context engine 800002b804616263 (string representation of a hexadecimal value). This avoids ambiguity if any other context engine supports a "bridge1" context. The above two examples are based on the figure in Section 3.3 of [RFC3411].
この例では、SNMPコンテキストエンジン800002b804616263（16進数の文字列表現）を介しsnmp.example.comにおける「bridge1」コンテキストを指定します。他のコンテキスト・エンジンは「bridge1」コンテキストをサポートしている場合、これはあいまいさを避けることができます。上記の2つの例は、[RFC3411]のセクション3.3の図に基づいています。
snmp://example.com//1.3.6.1.2.1.1.3.0 snmp://example.com//1.3.6.1.2.1.1.3+ snmp://example.com//1.3.6.1.2.1.1.3.*
SNMP：SNMP //example.com//1.3.6.1.2.1.1.3.0：//example.com//1.3.6.1.2.1.1.3+ SNMP：//example.com//1.3.6.1.2.1。 1.3。*
These three examples all designate the sysUpTime.0 object instance in the SNMPv2-MIB or RFC1213-MIB for the default SNMP context ("") at example.com as sysUpTime.0 is:
sysUpTime.0は、これら3つの例は、すべてのexample.comでデフォルトSNMPコンテキストのためのSNMPv2-MIBまたはRFC1213-MIB（「」）でsysUpTime.0オブジェクトのインスタンスを指定します。
a) designated directly by OID 1.3.6.1.2.1.1.3.0,
a）のOID 1.3.6.1.2.1.1.3.0によって直接指定されました、
b) the lexically next MIB object instance after the OID 1.3.6.1.2.1.1.3, and
B）OID 1.3.6.1.2.1.1.3後字句の次のMIBオブジェクトインスタンス、および
c) the only MIB object instance whose OID has 1.3.6.1.2.1.1.3 as a lexical prefix.
C）そのOIDのみMIBオブジェクトインスタンスは、字句接頭辞として1.3.6.1.2.1.1.3を有しています。
These three examples are provided for illustrative purposes only, as multiple syntactically distinct URIs SHOULD NOT be used to designate the same MIB object instance, in order to avoid unexpected results in URI-based systems that use string comparison to test URIs for equality.
複数の構文的に異なるURIが等価のURIをテストするために、文字列比較を使用してURIベースのシステムで予期しない結果を回避するために、同じMIBオブジェクトのインスタンスを指定するために使用されるべきではないこれらの三つの実施例は、例示の目的のみのために提供されます。
snmp://example.com/bridge1/1.3.6.1.2.1.2.2.1.8.*
SNMP：//example.com/bridge1/1.3.6.1.2.1.2.2.1.8.*
This example designates the ifOperStatus column of the IF-MIB in the bridge1 SNMP context at example.com.
この例では、example.comでbridge1 SNMPコンテキストでIF-MIBののifOperStatus列を指定します。
snmp://example.com//(1.3.6.1.2.1.2.2.1.7,1.3.6.1.2.1.2.2.1.8).*
SNMP：//example.com//（1.3.6.1.2.1.2.2.1.7,1.3.6.1.2.1.2.2.1.8）*。
This example designates all (ifAdminStatus, ifOperStatus) pairs in the IF-MIB in the default SNMP context at example.com.
この例では、example.comでデフォルトSNMP文脈におけるIF-MIB内のすべて（のifAdminStatus、のifOperStatus）のペアを指定します。
An intended use of this URI scheme is designation of the location of management access to communication devices. Such location information may be considered sensitive in some environments, making it important to control access to this information and possibly even to encrypt it when it is sent over the network. All uses of this URI scheme should provide security mechanisms appropriate to the environments in which such uses are likely to be deployed.
このURIスキームの使用目的は、通信デバイスへの管理アクセスの場所の名称です。そのような位置情報は、重要情報へのアクセスを制御するために、おそらく、それがネットワークを介して送信されたときにも、それを暗号化すること、いくつかの環境で敏感と考えることができます。このURIスキームのすべての用途は、このような用途が展開されそうである、環境に適切なセキュリティメカニズムを提供する必要があります。
The SNMP architecture includes control of access to management information (see Section 4.3 of [RFC3411]). An SNMP URI does not contain sufficient security information to obtain access in all situations, as the SNMP URI syntax is incapable of encoding SNMP securityModels, SNMP securityLevels, and credential or keying information for SNMP securityNames. Other means are necessary to provide such information; one possibility is out-of-band pre-configuration of the SNMP manager, as shown in the diagrams in Section 2.
SNMPアーキテクチャは、管理情報へのアクセスの制御（[RFC3411]のセクション4.3を参照）を含みます。 SNMP URIの構文はSNMP securityModels、SNMP securityLevels、および資格情報をコード化するか、SNMP securityNamesための情報をキーイングすることができないとして、SNMP URIは、すべての状況でのアクセスを得るために、十分なセキュリティ情報が含まれていません。他の手段は、そのような情報を提供するために必要です。第2に図に示すように、1つの可能性は、SNMPマネージャのアウトオブバンド事前設定です。
By itself, the presence of a securityName in an SNMP URI does not authorize use of that securityName to access management information. Instead, the SNMP manager SHOULD match the securityName in the URI to an SNMP securityName and associated security information that have been pre-configured for use by the manager. If an SNMP URI contains a securityName that the SNMP manager is not provisioned to use, SNMP operations for that URI SHOULD NOT be generated.
それ自体で、SNMP URIにおけるセキュリティ名の存在は、管理情報にアクセスするには、そのセキュリティ名の使用を許可していません。代わりに、SNMPマネージャは、SNMPセキュリティ名と管理者が使用するために事前に設定されている関連するセキュリティ情報にURIでセキュリティ名と一致する必要があります。 SNMP URIは、SNMPマネージャが使用するようにプロビジョニングされていないセキュリティ名が含まれている場合は、そのURIのためのSNMP操作は、生成されるべきではありません。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, via use of IPsec), there is no control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in MIB modules. It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], Section 8, for an overview), including full support for SNMPv3 cryptographic mechanisms (for authentication and privacy). This is of additional importance for MIB elements considered sensitive or vulnerable because GETs have side effects.
SNMPv3の前のSNMPバージョンは十分なセキュリティを含んでいませんでした。ネットワーク自体が安全であっても（例えば、IPsecの使用を経由して）、セキュアなネットワーク上のMIBモジュールに/ SET（読む/変更/作成/削除）オブジェクトにアクセスしてGETを許可するユーザーに対する制御はありません。 implementersがSNMPv3フレームワークで提供されるセキュリティ機能を考えるのは（認証とプライバシーのため）SNMPv3の暗号のメカニズムのためのフルサポートを含む、（概要については、第8節、[RFC3410]を参照）が推奨されます。これは副作用を持って取得しますので、機密情報や脆弱と考えMIB要素のための追加的な重要です。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to a MIB module instance is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (read/change/create/delete) them.
さらに、SNMPv3の前のSNMPバージョンの展開はお勧めしません。代わりに、SNMPv3を展開すると、暗号化セキュリティを有効にすることをお勧めします。その後、MIBモジュールのインスタンスへのアクセスを与えるSNMP実体が適切にのみ校長確かに正当な権利を持っている（ユーザー）にオブジェクトへのアクセス権を与えるように構成されていることを確実にするために、顧客/オペレータ責任です/変更を読む（GETまたはSET /）/削除、それらを作成します。
Additional security considerations apply to SNMP gateways that generate SNMP operations for SNMP URIs and return the results to clients (see Section 2) because management information is communicated beyond the SNMP framework. In general, an SNMP gateway should have some knowledge of the structure and function of the management information that it accesses via SNMP. Among other benefits, this allows an SNMP gateway to avoid SNMP access control failures because the gateway can reject an SNMP URI that will cause such failures before generating any SNMP operations.
管理情報をSNMPの枠組みを超えて伝達されるため、追加のセキュリティの考慮事項は、（第2節を参照）SNMPのURIのためのSNMP操作を生成するSNMPゲートウェイに適用され、クライアントに結果を返します。一般に、SNMPゲートウェイは、SNMPを介してアクセスする管理情報の構造と機能のいくつかの知識を有していなければなりません。他の利点の中で、これは、ゲートウェイが任意のSNMP操作を生成する前に、このような故障の原因となりますSNMP URIを拒否することができるので、SNMPゲートウェイは、SNMPアクセス制御の失敗を避けることができます。
SNMP gateways SHOULD impose authorization or access-control checks on all clients. If an SNMP gateway does not impose authorization or access controls, the gateway MUST NOT automatically obtain or use SNMP authentication material for arbitrary securityNames, as doing so would defeat SNMP's access controls. Instead, all SNMP gateways SHOULD authenticate each client and check the client's authorization to use a securityName in an SNMP URI before using the securityName on behalf of that client.
SNMPゲートウェイは、すべてのクライアントに認証やアクセス制御のチェックを課すべきです。 SNMPゲートウェイは、認証やアクセス制御を課していない場合は、ゲートウェイが自動的に取得してはならないか、そうすることがSNMPのアクセス制御を台無しにしてしまうと、任意securityNames用SNMP認証材を使用しています。代わりに、すべてのSNMPゲートウェイは、各クライアントを認証し、そのクライアントに代わってセキュリティ名を使用する前に、SNMP URIにおけるセキュリティ名を使用するようにクライアントの認証を確認する必要があります。
An SNMP gateway is also responsible for ensuring that all of its communication is appropriately secured. Specifically, an SNMP gateway SHOULD ensure that communication of management information with any client is protected to at least the SNMP securityLevel used for the corresponding SNMP access (see Section 3.4.3 of [RFC3411] for more information on securityLevel). If the client provides SNMP security information, the SNMP gateway SHOULD authenticate the client and SHOULD ensure that an authenticated cryptographic integrity check is used for that communication to prevent modification of the security information. In addition, if a client provides any key or secret, the SNMP gateway SHOULD ensure that encryption is used in addition to the integrity check for that communication to prevent disclosure of keys or secrets.
SNMPゲートウェイは、その通信の全てが適切に確保されることを保証する責任があります。具体的には、SNMPゲートウェイは、任意のクライアントと管理情報の通信は、少なくともSNMPたsecurityLevelに保護されていることを確認すべきである（たsecurityLevelの詳細については、[RFC3411]のセクション3.4.3を参照）に対応するSNMPアクセスに使用されます。クライアントは、SNMPのセキュリティ情報を提供している場合は、SNMPゲートウェイはクライアントを認証すべきであると認証された暗号の整合性チェックは、セキュリティ情報の変更を防ぐために、その通信に使用されていることを確認する必要があります。クライアントは、任意のキーや秘密を提供する場合また、SNMPゲートウェイは、暗号化が鍵や秘密の開示を防ぐために、その通信のための整合性チェックに加えて使用されていることを確認すべきです。
There are management objects defined in SNMP MIBs whose MAX-ACCESS is read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. SNMP gateway support for SNMP SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The individual MIB module specifications, and especially their security considerations, should be consulted for further information.
そのMAX-ACCESSの読み取りと書き込み、および/またはリード作成であるSNMP MIBで定義された管理オブジェクトがあります。そのようなオブジェクトは、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。適切な保護のない非安全な環境でのSNMP SET操作のためのSNMPゲートウェイのサポートはネットワーク操作のときにマイナスの影響を持つことができます。個々のMIBモジュールの仕様、および特にそのセキュリティの考慮事項は、詳細について相談する必要があります。
Some readable objects in some MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET access to these objects via an SNMP gateway and possibly to even encrypt the values of these objects when they are sent over the network. The individual MIB module specifications, and especially their security considerations, should be consulted for further information. This consideration also applies to objects for which read operations have side effects.
いくつかのMIBモジュールにおける一部可読オブジェクト（すなわち、アクセス可能ではない以外MAX-ACCESS持つオブジェクト）は、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。それも、それらがネットワークを介して送信された場合でも、これらのオブジェクトの値を暗号化するためにSNMPゲートウェイを経由して、おそらく、これらのオブジェクトへのアクセスを取得制御することが重要です。個々のMIBモジュールの仕様、および特にそのセキュリティの考慮事項は、詳細について相談する必要があります。この考慮事項も操作が副作用を持って読んでいるオブジェクトに適用されます。
The IANA has registered the URL registration template found in Appendix A in accordance with [RFC2717].
IANAは[RFC2717]に従って、付録Aで見つかったURLの登録テンプレートを登録しています。
[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月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001.
[RFC3061] Mealling、M.、 "オブジェクト識別子のURN名前空間"、RFC 3061、2001年2月。
[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の、STD 62、RFC 3411、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"。
[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"。
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417] Presuhn、R.、 "簡易ネットワーク管理プロトコルのためのマッピングを輸送します（SNMP）"、STD 62、RFC 3417、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]フライ、R.、レヴィ、D.、Routhier、S.、およびB. Wijnenの、 "バージョン1、バージョン2、及びインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存"、BCP 74、RFC 3584 、2003年8月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]バーナーズ=リー、T.、Masinter、L.、およびM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[RFC1900]大工、B.およびY. Rekhter、 "リナンバリングは作業が必要"、RFC 1900、1996年2月。
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC2717] Petke、R.とI.キング、BCP 35、RFC 2717、1999年11月 "URLスキーム名の登録手順"。
[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月。
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping", RFC 3430, December 2002.
[RFC3430] Schoenwaelder、J.、 "簡易ネットワーク管理プロトコルを介して伝送制御プロトコル交通マッピング"、RFC 3430、2002年12月。
[RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)", RFC 3617, October 2003.
[RFC3617]リア、E.、RFC 3617、2003年10月 "簡易ファイル転送プロトコル（TFTP）のURI（Uniform Resource Identifier）スキームと適用性声明"。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001]ダニエル、M.、ハーバーマン、B.、Routhier、S.、およびJ. Schoenwaelder、 "インターネットネットワークアドレスのためのテキストの表記法"、RFC 4001、2005年2月。
Portions of this document were adapted from Eliot Lear's TFTP URI scheme specification [RFC3617]. Portions of the security considerations were adapted from the widely used security considerations "boilerplate" for MIB modules. Comments from Ted Hardie, Michael Mealing, Larry Masinter, Frank Strauss, Bert Wijnen, Steve Bellovin, the mreview@ops.ietf.org mailing list and the uri@w3c.org mailing list on earlier versions of this document have resulted in significant improvements and are gratefully acknowledged.
この文書の部分は、エリオット・リアのTFTP URIスキーム仕様[RFC3617]から適合させました。セキュリティの考慮事項の一部は、MIBモジュールのために広く使用されているセキュリティ上の考慮事項「定型文」から適応させました。テッド・ハーディ、マイケルMealing、ラリーMasinter、フランク・シュトラウス、バートWijnen、スティーブBellovin氏、mreview@ops.ietf.orgメーリングリストと、このドキュメントの以前のバージョンにuri@w3c.orgメーリングリストからのコメントは大幅な改善をもたらしましたそして、深く感謝しています。
Appendix A. Registration Template
付録A.登録テンプレート
URL scheme name: snmp URL scheme syntax: Section 3 Character encoding considerations: Section 3 Intended usage: Sections 1 and 2 Applications and/or protocols which use this scheme: SNMP, all versions, see [RFC3410] and [RFC3584]. Also SNMP over TCP, see [RFC3430]. Interoperability considerations: Section 4.4 Security considerations: Section 6 Relevant publications: See [RFC3410] for list. Also [RFC3430] and [RFC3584]. Contact: David L. Black, see below Author/Change Controller: IESG
URLのスキーム名：SNMPのURLスキームの構文：セクション3つの文字エンコーディングの考慮事項：第3節意図している用法：セクション1と2のアプリケーションおよび/またはこの方式を使用するプロトコル：SNMP、すべてのバージョン、[RFC3410]と[RFC3584]を参照してください。また、TCP上のSNMPは、[RFC3430]を参照してください。相互運用性に関する注意事項：セクション4.4のセキュリティ上の考慮事項：第6章関連資料：リストについては、[RFC3410]を参照してください。また、[RFC3430]と[RFC3584]。連絡先：デビッドL.ブラック、著者/変更コントローラー以下を参照してください。IESG
Authors' Addresses
著者のアドレス
David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748
デビッドL.ブラックEMCコーポレーション176サウスストリートホプキントン、MA 01748
Phone: +1 (508) 293-7953 EMail: black_david@emc.com
電話：+1（508）293-7953 Eメール：black_david@emc.com
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
キースMcCloghrieシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA USA 95134
Phone: +1 (408) 526-5260 EMail: kzm@cisco.com
電話：+1（408）526-5260 Eメール：kzm@cisco.com
Juergen Schoenwaelder International University Bremen P.O. Box 750 561 28725 Bremen Germany
ユルゲンSchoenwaelder国際大学ブレーメン私書箱750 561 28725ブレーメンドイツ箱
Phone: +49 421 200 3587 EMail: j.schoenwaelder@iu-bremen.de
電話：+49 421 200 3587 Eメール：j.schoenwaelder@iu-bremen.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。