[要約] RFC 4088は、SNMPのためのURIスキームを定義しています。このRFCの目的は、SNMPエージェントへのアクセスを簡素化し、URIを使用してSNMPオブジェクトを識別することです。
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)
単純なネットワーク管理プロトコル（SNMP）の均一なリソース識別子（URI）スキーム
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).
Copyright（c）The Internet Society（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アクセス（SNMP MIBオブジェクトインスタンスへのアクセスを含む）を指定する必要があります。たとえば、バンド外の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デバイスを管理するために考案されました。この手段では、管理アクセスは主にIPトラフィックの送信と受信に使用されるのと同じインターフェイスを介して行われます。SNMPの幅広い採用により、バンド内のIPアクセス（ファイバーチャネルデバイスなど）をサポートしていない通信デバイスの管理に使用されています。管理には、別のバンド外のIPインターフェイスがよく使用されます。URIは、そのインターフェイスを見つけて、管理に使用するプロトコルを指定する便利な方法を提供します。考えられるシナリオの1つは、バンド内クエリがデバイスの管理方法を示すURIを返すことです。このドキュメントは、SNMP（特定のSNMPコンテキストを含む）をそのようなURIによって管理プロトコルとして指定することを許可する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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
There are two major classes of SNMP URI usage: configuration and gateways between SNMP and other protocols that use SNMP URIs.
SNMP URIの使用には、SNMPの構成とゲートウェイと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:
構成に使用されるSNMP URIは、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 URIを使用して、SNMP URIからSNMPゲートウェイ（このドキュメントのSNMPゲートウェイとも呼ばれます）を介して管理情報を要求します。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]のuserInfo、ホスト、ポート、および（パス）セグメントのABNF構文ルールと[RFC2234]のHEXDIGのABNF構文ルールに基づいて、次のABNF [RFC2234]構文を持っています。
snmp-uri = "snmp://" snmp-authority [ context [ oids ]]
snmp-uri = "snmp：//" snmp-authority [context [oids]]
snmp-authority = [ securityName "@" ] host [ ":" port ]
securityName = userinfo ; SNMP securityName
context = "/" contextName [ ";" contextEngineID ]
contextName = segment ; SNMP contextName
contextEngineID = 1*(HEXDIG HEXDIG) ; SNMP contextEngineID
oids = "/" ( oid / oid-group ) [ suffix ]
oid-group = "(" oid *( "," oid ) ")"
oid = < as specified by [RFC 3061] >
suffix = "+" / ".*"
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.
UserInfoおよび（PATH）セグメントABNFルールは、構文のみで再利用されます。対照的に、ホストとポートには、[RFC3986]で指定された構文とセマンティクスの両方があります。SecurityName、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-authorityの構文は、[RFC3986]のセクション3.2のURI機関の構文と一致し、当局のuserinfoコンポーネント（存在する場合）がSNMPセキュリティ名でなければならないという追加の制限があります。SecurityNameが空であるか、与えられていない場合、SNMP URIを使用するエンティティは、必要な場合に使用するSNMP SecurityNameを知ることが期待されます。URISに認証情報（パスワードなど）を含めることは非推奨です（[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 SHOULD be present if more than one context engine at the designated host and port supports the designated context.
ContextNameが空であるか、与えられていない場合、デフォルトのSNMPコンテキストであるため、ゼロ長文字列（ ""）が想定されます。SNMP ContextEngineIDは、SNMPマネージャーによって通常発見される可変形式のバイナリ要素です。SNMP URIは、一連のバイトに対応する16進数桁としてContextEngineIDをエンコードします。ContextEngineIDが空であるか、与えられていない場合、コンテキストエンジンは、指定されたホストとポートでSNMPエージェントをクエリすることにより発見されます。以下のセクション4.1を参照してください。指定されたホストとポートで複数のコンテキストエンジンが指定されたコンテキストをサポートする場合、URIのContextEngineIDコンポーネントが存在する必要があります。
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では、UTF-8文字をSecurityNameまたはContextNameで使用できます。SNMP URIのすべてのマルチバイトUTF-8文字は、[RFC3986]のセクション2.1および2.5で指定されているようにエンコードされている必要があります。これらの要件は、[RFC3986]のuserInfoとセグメントの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 URISは、一般に、実装の文字列長制限を回避するのに十分なほど短くなります（たとえば、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 URISでの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>
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パーサーが2番目の「//」を正しく処理しない場合、パーサーは壊れているため、修正する必要があります。SNMP URISでの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 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.
一方、絶対SNMP URIでの「//」の2回目の発生は、相対参照の開始時の「//」が常に紹介されるため、そのURIへの相対参照の使用に影響します（[RFC3986]のセクション4.2を参照）。URI Authorityコンポーネント（ホストとオプションのuserInfoおよび/またはポート; [RFC3986]を参照）。具体的には、フォームの相対的な参照// <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.
OIDを含まないSNMP URIは、SNMP管理サービスにアクセスするための通信エンドポイントを指定するため、SNMPサービスURIと呼ばれます。1つ以上のOIDを含むSNMP URIは、SNMP MIBで1つ以上のオブジェクトインスタンスを指定するため、SNMPオブジェクトURIと呼ばれます。SNMP URIを使用する予想される手段は、SNMPマネージャーを使用して、URIによって指定されたホストとポートのSNMPエージェントを介してURIによって指定された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のもう1つの例です。URIのコンテキスト名が空であるか、与えられていない場合、「ゼロ長さの文字列）が想定されます。これは、デフォルトの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プロキシエージェントが含まれていないため、ContextEngineIDを省略（デフォルト）省略することが期待されています。具体的には、SNMPエージェントが管理するネットワークインターフェイスのローカルである場合、エージェントは通常1つのコンテキストエンジンのみを備えています。さらに、ネットワークインターフェイスにローカルである多くの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には、1つ以上のOIDが含まれています。URIは、最初にOIDまたはOIDグループ（前のスラッシュと括弧とサフィックスを含む）を分離し、次にセクション4.1（上記）で指定されたSNMPサービスURIを処理して、アクセスするSNMPコンテキストを決定することで使用されます。その後、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グループに接尾辞があるかどうか、その接尾辞が何であるかに依存します。3つの可能な形式があります。いずれの場合も、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グループセマンティクスは、グループ内の各OIDへの単一のOIDセマンティクスの拡張です（たとえば、「「接尾辞を備えたURI」は、「」の各OIDの字句的に次のインスタンスで構成されるMIBオブジェクトインスタンスのセットを指定します。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がオブジェクトインスタンスを正確に指定し、「「接尾辞」は次のオブジェクトインスタンスを指定し、変更する可能性があるためです。複数の構文的に異なる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オブジェクトURISは、アクセスするために使用される特定のSNMP操作とは対照的に、アクセスするデータを指定します。セクション4.2.1は、SNMP操作を使用してSNMPオブジェクトURIのデータにアクセスする方法の例を示します。それにもかかわらず、GetBulkを含む該当するSNMP操作は、1つまたは複数のSNMPオブジェクトURIのすべてまたは一部のデータにアクセスするために使用できます（たとえば、単一の操作で複数の可変バインディングを使用して）。セクション4.2.1の説明に従うことで結果（返された可変バインディングまたはエラー）が得られた限り、セクション4.2.1で説明されている特定の操作を使用する必要はありません。コンテキスト名（つまり、./ <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セット操作の生成が発生します。この場合、「 "and"。*"接尾辞を使用しないでください。そうする試みは、SNMPセット操作を生成してはならないエラーです。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オブジェクトURISは、SNMP MIBSでデータを指定するため、可能なすべてのSNMPプロトコル操作を生成する手段を提供しません。たとえば、SNMPオブジェクトURIのデータアクセスは、SNMPV2-TRAPまたはInformRequest通知のいずれかを直接生成できませんが、データアクセスの副作用はそのような通知を引き起こす可能性があります（MIBによって）。さらに、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.
SNMPオブジェクトURIに基づくデータアクセスは、URIで指定された各MIBオブジェクトインスタンスのSNMP変数バインディング、または操作が故障した場合のSNMPエラーを返します。SNMP変数バインディングは、変数名（OID）を値またはSNMP例外にバインドします（[RFC3416]を参照）。SNMPオブジェクトURIによって指定されたデータにアクセスするために必要なSNMP操作または操作は、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グループの場合、各OIDを可変バインディング名として使用してSNMP GET操作が生成されます。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グループの場合、各OIDを可変バインディング名として使用してSNMP getNext操作が生成されます。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データアクセスの結果です。返されたすべての可変バインディングには、a）対応するuri oidが語彙的プレフィックスではないOIDまたはb）snmp "endofmibview"例外のいずれかを含む場合、返された変数バインディングは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.
それ以外の場合、getNext操作の結果が保存され、別のSNMP getNext操作が可変バインディング名として新しく返されたOIDを使用して生成されます。これは、getNextから返されたすべての変数バインディングがa）対応するuri oidが語彙的プレフィックスではないか、b）anが含まれるまで、繰り返され（結果を保存し、可変バインディング名として新しく返されたOIDを使用してGetNextを生成します）snmp "endofmibview"例外。すべてのGetNext操作の結果を組み合わせて、URIデータアクセスの全体的な結果になります。これには、OIDが対応するURI OIDの語彙拡張ではない可変バインディングが含まれる場合があります。OIDサブツリー（特定のURI OIDが語彙的プレフィックスであるOIDのセット）がOIDグループのすべてのOIDに対して同じサイズではない場合、最大のサブツリーはこの反復がいつ終了するかを決定します。SNMP GetBulk操作を使用して、この反復アクセスを最適化することができます。
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が語彙的プレフィックスではないOIDまたはSNMP「EndofMibview」の例外が含まれている場合、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 URISの括弧付きのOIDグループは、一貫した結果を確保するために単一のSNMP操作を介したアクセスが必要なMIBオブジェクトインスタンスをサポートすることを目的としています。したがって、SNMP URIのOIDグループ内のOIDは、グループ内の各OIDに対応する可変バインディングを含む単一のSNMP操作にアクセスする必要があります。具体的な例には、[RFC4001]で定義されているイノテタドレスおよびイノテルドレスタイプのテキストコンベンションが含まれます。これは、InetAddressインスタンスの形式が関連するInetAddressTypeインスタンスによって指定されます。このような関連する2つのインスタンスが個別の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.
この単一の操作要件（ "sould"）は、 "。*"接尾辞を備えたSNMP URIの反復アクセスから生じる各OIDグループにも適用されます。SNMP URI OIDグループのメンバーは、それぞれが語彙接頭辞であるOIDの数が異なる場合、この反復は、OIDグループの対応するOIDが語彙的プレフィックスではない多数の可変バインディングを返すことでオーバーランする可能性があります。このようなオーバーランは、単一のSNMP操作で複数のMIBオブジェクトインスタンスにアクセスすることが重要ではない場合に、同じコンテキスト内で相対的な参照を使用することで回避できます。
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]).
このドキュメントでは、UDP以外のSNMPトランスポートに対応することを目的としたトランスポートに依存しない「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]、および関連ドキュメントで指定されているSNMPV3の使用を指定しますが、SNMPの古いバージョンは、このような古いバージョンの使用が避難不可能な場合に[RFC3584]に従って使用できます。SNMPV1およびSNMPV2Cの場合、[RFC3584]に記載されているように、SNMP URIのセキュリティ名、ContextName、およびContextEngineID要素がコミュニティ名にマッピングされます。コミュニティ名が弱い形式の認証として秘密にされている場合、この3つの要素がコミュニティ名に関する情報を明らかにしないように、このマッピングを構成する必要があります。これが行われない場合、秘密のコミュニティ名に関する重要な情報を開示するSNMP URIコンポーネントは省略する必要があります。一部のコミュニティ名には、SNMP URIで使用される場合にエンコードが必要な予約された文字（ "@"）が含まれていることに注意してください。SNMPバージョン（V3）は、SNMPのSNMPの使用を許可するために、SNMP URIスキームから省略されています。
snmp://example.com
snmp：//example.com
This example designates the default SNMP context at the SNMP agent at port 161 of host example.com .
この例では、Host example.comのポート161のSNMPエージェントでデフォルトのSNMPコンテキストを指定します。
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.
この例は、Host example.comのポート8161のSNMPエージェントでデフォルトのSNMPコンテキストを指定し、SNMP SecurityName「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（String deSadecimal値の文字列表現）を介して、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.*
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:
これらの3つの例はすべて、snmpv2-mibまたはrfc1213-mibのsnmpv2-mibまたはrfc1213-mibのsyssuptime.0オブジェクトインスタンスを、sysuptime.0としてexampl.comのsnmpコンテキスト（ ""）のものに指定します。
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が語彙的プレフィックスとして1.3.6.1.2.1.1.3を持っている唯一のMIBオブジェクトインスタンス。
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.
これらの3つの例は、複数の構文的に異なる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の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).*
This example designates all (ifAdminStatus, ifOperStatus) pairs in the IF-MIB in the default SNMP context at example.com.
この例は、Example.comのデフォルトのSNMPコンテキストのIF-MIBのすべて（IfadMintatus、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セキュリティモデル、SNMPセキュリティレベル、SNMPセキュリティ名の資格情報またはキーイング情報をエンコードできないため、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マネージャーは、URIのSecurityNameをSNMP SecurityNameおよびマネージャーが使用するために事前に構成されている関連するセキュリティ情報を一致させる必要があります。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を使用して）、Secureネットワーク上の誰がMIBモジュールのオブジェクトにアクセスして取得/設定/設定（読み取り/変更/作成/削除）を制御できません。実装者は、SNMPV3暗号化メカニズム（認証とプライバシーのため）の完全なサポートを含む、SNMPV3フレームワーク（[RFC3410]、セクション8を参照）を参照）を考慮することをお勧めします（概要についてはセクション8を参照）。これは、副作用があるため、敏感または脆弱性と見なされる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エンティティが、実際に取得または設定する正当な権利を持つプリンシパル（ユーザー）にのみオブジェクトにアクセスできるように適切に構成されていることを保証するのは、顧客/オペレーターの責任です（読み取り/変更/変更を受けるプリンシパル（ユーザー）にのみアクセスできます。/作成/削除）それら。
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 URIのSNMP操作を生成し、SNMPフレームワークを超えて管理情報が伝えられているため、SNMP URIのSNMP操作を生成し、結果をクライアントに返すSNMPゲートウェイに追加のセキュリティに関する考慮事項が適用されます。一般に、SNMPゲートウェイには、SNMPを介してアクセスする管理情報の構造と機能に関するある程度の知識が必要です。他の利点の中でも、これにより、SNMPアクセス制御の障害を回避するためのSNMPゲートウェイが可能になります。これにより、ゲートウェイはSNMP操作を生成する前にそのような障害を引き起こすSNMP URIを拒否できるためです。
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認証資料を自動的に取得または使用してはなりません。代わりに、すべての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アクセスに使用されるSNMP SecuriteLevelに保護されるようにする必要があります（SecurityLevelの詳細については、[RFC3411]のセクション3.4.3を参照）。クライアントが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が読み取りワイトおよび/またはread-CreateであるSNMP MIBSで定義された管理オブジェクトがあります。このようなオブジェクトは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしに非セクチャ環境でのSNMPセット操作の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モジュールの一部の読み取り可能なオブジェクト（つまり、アクセスできないこと以外の最大アクセスを備えたオブジェクト）は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、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] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、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月。
[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] Frye、R.、Levi、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] Berners-Lee、T.、Fielding、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] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[RFC1900] Carpenter、B。およびY. Rekhter、「Nemumbering Needs Work」、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. King、「URLスキーム名の登録手順」、BCP 35、RFC 2717、1999年11月。
[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月。
[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] Lear、E。、「些細なファイル転送プロトコル（TFTP）の統一リソース識別子（URI）スキームおよび適用可能性ステートメント」、RFC 3617、2003年10月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001] Daniele、M.、Haberman、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.
この文書の一部は、Eliot LearのTFTP URIスキーム仕様[RFC3617]から採用されました。セキュリティ上の考慮事項の一部は、MIBモジュールの広く使用されているセキュリティに関する「ボイラープレート」から採用されました。Ted Hardie、Michael Meiling、Larry Masinter、Frank Strauss、Bert Wijnen、Steve Bellovin、The Mreview@ops.ietf.orgメーリングリスト、uri@w3c.orgメーリングリストからのコメントこのドキュメントの以前のバージョンでは、大幅に改善されました。そして感謝されています。
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]。連絡先：David L. Black、以下の著者/変更コントローラーを参照：IESG
Authors' Addresses
著者のアドレス
David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748
David L. Black EMC Corporation 176 South Street Hopkinton、MA 01748
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
Keith McCloghrie Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
Phone: +1 (408) 526-5260
EMail: kzm@cisco.com
Juergen Schoenwaelder International University Bremen P.O. Box 750 561 28725 Bremen Germany
Juergen Schoenwaelder International University Bremen P.O.ボックス750 561 28725ブレーメンドイツ
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。