RFC4088 日本語訳
4088 Uniform Resource Identifier (URI) Scheme for the Simple NetworkManagement Protocol (SNMP). D. Black, K. McCloghrie, J.Schoenwaelder. June 2005. (Format: TXT=43019 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループのD.の黒い要求をネットワークでつないでください: 4088年のEMC社のカテゴリ: 大学ブレーメン2005年6月の国際の標準化過程K.McCloghrieシスコシステムズJ.Schoenwaelder
Uniform Resource Identifier (URI) Scheme for the
Simple Network Management Protocol (SNMP)
簡単なネットワーク管理プロトコルのUniform Resource Identifier(URI)体系(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
Simple Network Managementプロトコル(SNMP)とインターネットStandard Management Frameworkは通信装置の管理に広く使用されます、非SNMP経営環境からSNMPアクセス(SNMP MIBオブジェクトインスタンスへのアクセスを含んでいる)を指定する必要性を作成して。 IP管理が別々の管理インタフェース(例えば、バンドにおけるIPアクセスをサポートしないデバイスのための)を通してバンドの外で使用されるとき、例えば、管理のためのデバイスに連絡する方法を示す一定の方法が必要です。 Uniform Resource Identifier(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オブジェクトインスタンスを指定できます。
Black, et al. Standards Track [Page 1] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[1ページ]。
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
1. 序論… 2 2. 用法… 3 3. SNMP URIの構文… 4 3.1. 相対参照問題… 5 4. 意味論と操作… 6 4.1. SNMPはURIを修理します… 6 4.2. SNMPオブジェクトURI… 7 4.2.1. SNMPオブジェクトURIデータ・アクセス… 8 4.3. OIDはSNMP URIで分類します… 10 4.4. 相互運用性問題… 10 5. 例… 11 6. セキュリティ問題… 12 6.1. SNMPゲートウェイセキュリティ問題へのSNMP URI… 13 7. IANA問題… 14 8. 標準の参照… 14 9. 有益な参照… 15 10. 承認… 16付録A.登録テンプレート… 17
1. Introduction
1. 序論
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とインターネット標準のManagement Frameworkは元々バンドにおける手段でIPデバイスを管理するために工夫されました、管理アクセスが主としてIPトラフィックを送って、受けるのに使用される同じインタフェースを通したどれであるかで。 SNMPの広い採用はバンドにおけるIPアクセスが(例えば、Fibre Channelデバイス)であるとサポートしない通信装置を管理する使用をもたらしました。 別々のバンドで出かけているIPインタフェースは管理にしばしば使用されます。 URIは管理に使用されるためにそのインタフェースの場所を見つけて、プロトコルを指定する便利な方法を提供します。 1つの可能なシナリオはバンドにおける質問がデバイスがどう管理されるかを示すURIを返すことです。 このドキュメントは、管理がそのような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].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概要について、[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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Black, et al. Standards Track [Page 2] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[2ページ]。
2. Usage
2. 用法
There are two major classes of SNMP URI usage: configuration and gateways between SNMP and other protocols that use SNMP URIs.
SNMP URI用法の2つの主要なクラスがあります: SNMP URIを使用するSNMPと他のプロトコルの間の構成とゲートウェイ。
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 ------------+
*********** SNMP-要求***********========>* * URI---------->* マネージャ**エージェント***<。================* * *********** SNMP-Response ********* ^ | 他のコンフィグインフォメーション------------+
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 ------------+
SNMPゲートウェイ**********URI***********SNMP-要求***********= = = = =は>*と等しいです。 *========>* * * クライアント**マネージャ**エージェント***<。===========* =*<=======* * ********** Info *********** SNMP-Response ********* ^ | 他のコンフィグインフォメーション------------+
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
URIに使用されるのを除いて、インタフェースを通して追加設定情報(例えば、セキュリティ秘密かキー)を提供するかもしれません。 例えば、秘密を含む何人かのタイプのセキュリティ情報
Black, et al. Standards Track [Page 3] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[3ページ]。
and keys, should be pre-configured in or pre-authorized to the manager rather than be provided by the client; see Section 6.
そして、マネージャにとって、キーは、クライアントによって提供されるよりむしろあらかじめ設定されているか、またはプレ認可されているべきです。 セクション6を見てください。
3. Syntax of an SNMP URI
3. SNMP URIの構文
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には、以下のABNF[RFC2234]構文があります、userinfo、ホスト、ポート、および[RFC3986]の(経路)セグメントのためのABNFシンタックス・ルールと[RFC2234]のHEXDIGのためのABNFシンタックス・ルールに基づいて:
snmp-uri = "snmp://" snmp-authority [ context [ oids ]]
snmp-uriは「snmp://」snmp-権威と等しいです。[文脈[oids]]
snmp-authority = [ securityName "@" ] host [ ":" port ]
securityName = userinfo ; SNMP securityName
snmp-権威=[securityName"@"]ホスト[「:」 ポート]securityNameはuserinfoと等しいです。 SNMP securityName
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 = "+" / ".*"
「oidsは」 /と等しい」という(oid / oid-グループ)[接尾語]oid-グループが等しい、「(「oid*、(「」 oid、)、」、)、」 指定されるとしての[RFC3061]>接尾語によるoid=<が「+ 」 /」と等しい、*、」
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と(経路)セグメント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-権威構文は[RFC3986]のセクション3.2のURI権威構文に合っています、権威(存在しているとき)のuserinfoの部品がSNMP securityNameであるに違いないという追加制限で。 securityNameが空であるか考えないで、1が必要であるなら、SNMP URIを利用する実体が、どんなSNMP securityNameを使用したらよいかを知っていると予想されます。 URIでの認証情報(例えば、パスワード)の包含が推奨しないので(.1セクション3.2[RFC3986]を見てください)、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マネージャによって発見される可変長形式2進素子です。 SNMP URIはバイトの系列に対応する16進数字としてcontextEngineIDをコード化します。 contextEngineIDが空であるか考えないで、文脈エンジンは指定されたホストとポートでSNMPエージェントについて質問することによって、発見されることになっています。 以下のセクション4.1を見てください。 URIのcontextEngineIDの部品
Black, et al. Standards Track [Page 4] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[4ページ]。
SHOULD be present if more than one context engine at the designated host and port supports the designated context.
SHOULDは指定されたホストの1台以上の文脈エンジンであるなら存在していて、サポートを移植します。指定された文脈。
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].
SNMP URIに[RFC3986]で指定された符号化規則を使用しなければなりません、パーセントのURIで許容されなかった[RFC3986]と少しのキャラクタでも予約されるように定義されたキャラクタの代理をするために必要に応じて(2十六進法ケタがあとに続いた「%」)をコード化する使用を含んでいて。 SNMPは、どんなUTF-8キャラクタもsecurityNameかcontextNameで使用されるのを可能にします。 すべてのマルチバイトUTF-8キャラクタ、SNMP URI MUSTでは、[RFC3986]のセクション2.1と2.5で指定されるようにコード化されたパーセントになってください。 これらの要件はuserinfoとセグメントのために[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]を見てください)。
3.1. Relative Reference Considerations
3.1. 相対参照問題
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:
URIで「SNMP URIの中のSNMPデフォルト文脈(ゼロ長ストリング)の使用は」 //の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
「他方では、」 //の2番目の発生、」、絶対SNMP URIでそのURI([RFC3986]のセクション4.2を見る)の相対参照の用法に影響する、a」//、」 相対参照の始めでは、いつもURI権威コンポーネント(そのうえ、任意のuserinfo、そして/または、ポートを接待してください; [RFC3986]を見る)を導入します。 明確に親類
Black, et al. Standards Track [Page 5] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[5ページ]。
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.
URI権威として分析されるべき//」 ウィル原因<oid2>、パーサであるときに構文エラーをもたらすのは<oid2>でホストを見つけません。URI権威コンポーネントを含まないでください。「フォーム//<oid2>の参照が利かない、」 この問題を避けるために、親類は」 //でその始めに参照をつけます」、使用されてはいけません。 「前に置くことで相対参照が禁じられたどんなそのようなものにも同等な機能性を得ることができます」。. 」 」 . . 」 禁制の相対参照(. . 例えば、//<oid2>)に。 使用する接頭語はベースURIによります。
4. Semantics and Operations
4. 意味論と操作
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経営指導へのアクセスのためにコミュニケーション終点を指定するので、少しのOIDsも含んでいないSNMP URIはSNMPサービスURIと呼ばれます。 SNMP MIBの1つ以上のオブジェクトインスタンスを指定するので、1OIDsを含んでいるSNMP URIはSNMPオブジェクトURIと呼ばれます。 SNMP URIを使用する予想された手段はURIによって任命されたホストとポートのSNMPエージェントを通してURIによって指定されたSNMP文脈にアクセスするためにSNMPマネージャを雇うことです。
4.1. SNMP Service URIs
4.1. SNMPサービスURI
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.
SNMPサービスURIでcontextEngineIDを与えるなら、それが指定する文脈エンジンは使用されていることになっています。 contextEngineIDがないかURIで考えないで、文脈エンジンは発見されることになっています。 使用されるべき文脈エンジンはURIによって指定された文脈をサポートするものです。 URI SHOULDのcontextEngineIDの部品は、指定されたホストの1台以上の文脈エンジンであるなら存在していて、サポートを移植します。指定された文脈。
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プロキシエージェント、どれが複数のSNMP文脈エンジンが独身のホストに存在する最も一般的な理由であるか、そして、およびポートにかかわらないのでSNMP URIの多くの一般的な用途がcontextEngineIDを省略する(すなわち、デフォルトとする)と予想されます。 SNMPエージェントがそれが管理するネットワーク・インターフェースに地元であるときに、明確に、通常、エージェントは1台の文脈エンジンしか持たないでしょう、その場合、SNMP URIのcontextEngineIDの部品を省略するのが安全です。 さらに、多くのネットワーク・インターフェースに地元であるSNMPエージェントが、唯一のデフォルトがSNMP文脈(ゼロ長ストリング)であるとサポートします。
Black, et al. Standards Track [Page 6] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[6ページ]。
4.2. SNMP Object URIs
4.2. SNMPオブジェクトURI
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は1OIDsを含んでいます。 URIは、OIDかOIDグループ(どんなスラッシュに先行して、括弧と接尾語も含んでいる)を切り離して、次に、SNMP文脈がアクセスされることを決定するためにセクション4.1(above)の指定されるとしての結果として起こる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グループには接尾語があるかどうかと、その接尾語が何であるかによります。 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) a」 *がある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グループは括弧でOIDsの1セットから成ります。 それぞれでは、ケース、OIDグループ意味論はグループにおける各OIDへのただ一つのOID意味論の拡大(例えば、「+」接尾語があるURIはOIDグループにおける各OIDのために辞書的に次のインスタンスから成るMIBオブジェクトインスタンスのセットを指定する)です。
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 SHOULD NOTがインスタンスの同じMIBオブジェクトインスタンスかセットを指定するのに使用されて、これがURIベースのシステムの予期しなかった結果にそれを引き起こすかもしれないようにストリング比較を使用して、平等がないかどうかURIをテストしてください。
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,
SNMPオブジェクトURIは特定のSNMP操作と対照的にアクセスに使用されるためにアクセスされるためにデータを指定します。 セクション4.2 .1 SNMPオブジェクトURIのためにデータにアクセスするのにどうSNMP操作を使用できるかに関する例を提供します。 それにもかかわらず、どんな適切なSNMP操作
Black, et al. Standards Track [Page 7] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[7ページ]。
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.
GetBulkを含んでいて、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 MIBsのデータを指定して、したがって、すべての可能なSNMPプロトコルが操作であると生成する手段を提供しません。 例えば、SNMPオブジェクトURIのためのデータ・アクセスは直接Snmpv2-罠かInformRequest通知のどちらかを生成することができません、データ・アクセスの副作用がそのような通知を引き起こす場合がありましたが(MIBによって)。 どのようにGetBulkはSNMPオブジェクトURIにa」で使用されるか。そして、さらに、「*」 接尾語は実装詳細です。
4.2.1. SNMP Object URI Data Access
4.2.1. 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.
操作が失敗するなら、データ・アクセスはそれぞれのMIBオブジェクトインスタンスのためのSNMP変項束縛がURI、またはSNMP誤りで指定したオブジェクトURIリターンを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"例外を含むかもしれないことに注意してください。
Black, et al. Standards Track [Page 8] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[8ページ]。
(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.
「a」 *があるOIDかOIDグループのための(3)」接尾語、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操作の結果は節約されます、そして、変項束縛名として新たに返されたOIDsを使用するのは別のSNMP GetNext操作に生成されます。 GetNextからのすべての返された変項束縛がa) 対応するURI OIDが語彙接頭語でないOIDかb)SNMP"endOfMibView"例外のどちらかを含むまで、これは繰り返されます(新たに返されたOIDsと共に変項束縛名として結果を節約して、GetNextを生成します)。 GetNext操作のすべてからの結果はURIデータ・アクセスの総合的な結果になるように結合されます。 これはOIDが対応するURI OIDの語彙拡大でない変項束縛を含むかもしれません。 OID下位木(特定のURI OIDが語彙接頭語であるOIDsのセット)がOIDグループにおけるすべてのOIDsのための同じサイズでないなら、最も大きい下位木は、この繰り返しがいつ終わるかを決定します。 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が語彙接頭語でなくて、またまたはSNMP"endOfMibView"例外でもないOIDを含んでいるときはいつも、OIDグループのその要素の繰り返しはやむかもしれません、その後のGetNext操作に使用される変項束縛の数を減少させて。 この場合、SNMP URIのためのURIデータ・アクセスの結果はOIDがサイズで分類しているセットの変項束縛から完全に成らないでしょう。 これが起こらないでも、一般に、OIDグループの各メンバーのために返された最後の変項束縛はSNMP"endOfMibView"例外か対応するURI OIDが語彙接頭語でないOIDを含むでしょう。
Black, et al. Standards Track [Page 9] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[9ページ]。
4.3. OID Groups in SNMP URIs
4.3. SNMP URIにおける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におけるParenthesized OIDグループがただ一つのSNMP操作を通したアクセスが一貫した結果を確実にするのに必要であるオブジェクトインスタンスをMIBにサポートすることを意図します。 したがって、アクセスされていて、グループに各OIDに対応する変項束縛を含んでいて、OIDの中のOIDsはSNMP URI SHOULDでただ一つのSNMP操作で分類します。 特定の例は原文のコンベンションがInetAddressインスタンスの形式が関連InetAddressTypeインスタンスによって指定される[RFC4001]で定義したInetAddressとInetAddressTypeにかかわります。 そのような2つの関連インスタンスが別々のSNMP操作で読まれるなら、結果として起こる値は矛盾しているかもしれません(例えば、介入しているSetによる)、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ユリのためにa」 *で繰り返されたアクセスから生じるそれぞれのOIDグループに適用される」接尾語。 SNMP URI OIDグループのメンバーがそれぞれが語彙接頭語であるOIDsの数において異なると、OIDグループにおける対応するOIDが語彙接頭語でない戻っている頻繁な変項束縛でオーバランして、この繰り返しは異なります。 ただ一つのSNMP操作における複数のMIBオブジェクトインスタンスにアクセスするのが重要でないときに同じ文脈(. /<oid>すなわち、*)の中で相対参照を使用することによって、そのような超過を避けることができます。
4.4. Interoperability Considerations
4.4. 相互運用性問題
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によって既存の用法との後方の互換性に指定された情報入手のためのデフォルト輸送ですが、他の輸送は使用されるかもしれません。 1つ以上の輸送を使用できるなら、SNMP URI SHOULD NOTによって指定された(例えば、UDPの上のSNMPに加えたTCP[RFC3430]の上のSNMP)、情報または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
SNMP URIは指定されるとSNMPv3の使用を指定します。[RFC3416]、[RFC3417]、およびしかし、関連するドキュメント、SNMP MAYの旧式のバージョンで、そのような旧式のバージョンの用法が避けられない[RFC3584]に従って、使用されてください。 SNMPv1とSNMPv2cに関しては、SNMP URIのsecurityName、contextName、およびcontextEngineID要素は共同体名からの/に写像されます、[RFC3584]で説明されるように。 共同体名が認証の弱形として秘密にされるとき、このマッピングが構成されるべきであるので、これらの3つの要素は共同体名の情報を明らかにしません。 これが完了していないなら、秘密の共同体の重要な情報を明らかにするどんなSNMP URIの部品もSHOULDを命名します。省略されます。 注意
Black, et al. Standards Track [Page 10] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[10ページ]。
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に使用されるときパーセントコード化を必要とするキャラクタ(例えば、"@")を予約しました。 SNMPバージョン(例えば、v3)はSNMPの旧式のバージョンの使用を可能にするためにSNMP URI体系から省略されました、SNMPv3のどんな可能な将来の後継者と同様に。
5. Examples
5. 例
snmp://example.com
snmp://example.com
This example designates the default SNMP context at the SNMP agent at port 161 of host example.com .
この例はポートのSNMPエージェントのデフォルトSNMP文脈を161ホストexample.comに指定します。
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.
この例がポートのSNMPエージェントのデフォルトSNMP文脈を8161ホストexample.comに指定して、それを示す、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の部品が省略されるので、そこでは、SHOULDは高々省略されます。「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://example.com//1.3.6.1.2.1.1.3.0snmp://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つの例がすべて、デフォルトSNMP文脈のためにSNMPv2-MIBかRFC1213-MIBでsysUpTime.0オブジェクトインスタンスを指定する、(「「)、sysUpTimeとしてのexample.comでは、.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
そしてOID1.3.6の後に.1を例証する、b) 辞書的に次のMIBが、反対する.2 .1 .1 .3。
Black, et al. Standards Track [Page 11] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[11ページ]。
c) the only MIB object instance whose OID has 1.3.6.1.2.1.1.3 as a
lexical prefix.
OIDはそうしました。c) 唯一の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.
これらの3つの例を説明に役立った目的だけに提供して、複数のシンタクス上異なったURI SHOULD NOTとして、使用して、同じMIBオブジェクトインスタンスを指定してください、平等がないかどうかURIをテストするのにストリング比較を使用するURIベースのシステムの予期しなかった結果を避けるために。
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.
この例がifOperStatusコラムを指定する、-、MIB、example.comのbridge1 SNMP文脈で。
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.
この例がすべて(ifAdminStatus、ifOperStatus)を組に指定する、-、MIB、example.comのデフォルトSNMP文脈で。
6. Security Considerations
6. セキュリティ問題
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 URI構文がSNMP securityNamesのための情報を合わせることができないとき。 他の手段がそのような情報を提供するのに必要です。 ある可能性はセクション2のダイヤグラムで示されるように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でのsecurityNameの存在自体は、そのsecurityNameの使用が経営情報にアクセスするのを認可しません。 代わりに、SNMPマネージャSHOULDはURIで使用のためにマネージャによってあらかじめ設定されたSNMP securityNameと関連セキュリティ情報にsecurityNameを合わせます。 SNMP URIがaを含んでいるなら、SNMPマネージャをあるsecurityNameはそのURI SHOULD NOTのために使用、SNMPに操作に食糧を供給しませんでした。生成されます。
Black, et al. Standards Track [Page 12] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[12ページ]。
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の使用で)、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが安全なネットワークにMIBモジュールでだれに許容されているかのコントロールが全くありません。 implementersがSNMPv3フレームワークによって提供されたセキュリティ機能を考えるのは([RFC3410]を見てください、セクション8、概要のために)、RECOMMENDEDです、SNMPv3の暗号のメカニズム(認証とプライバシーのための)の全面的な支援を含んでいて。 これはGETsには副作用があるので敏感であるか、または被害を受け易いと考えられた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バージョンの展開はNOT RECOMMENDEDです。 代わりに、それはSNMPv3を配布して、暗号のセキュリティを可能にするRECOMMENDEDです。 そして、MIBモジュールインスタンスへのアクセスを与えるSNMP実体が本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(読むか、変える、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
6.1. SNMP URI to SNMP Gateway Security Considerations
6.1. SNMPゲートウェイセキュリティ問題へのSNMP URI
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フレームワークを超えて伝えられるのでSNMP URIとリターンのためのSNMP操作が結果であるとクライアント(セクション2を見ます)に生成する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ゲートウェイSHOULDは承認かアクセス制御チェックをすべてのクライアントに課します。 SNMPゲートウェイが承認かアクセス制御を課さないなら、ゲートウェイは、任意のsecurityNamesに自動的にSNMP認証の材料を得てはいけませんし、また使用してはいけません、そうするのがSNMPのアクセス制御を破るだろうというとき。 代わりに、すべてのSNMPゲートウェイSHOULDが、そのクライアントを代表してsecurityNameを使用する前にSNMP URIでsecurityNameを使用するために各クライアントを認証して、クライアントの承認をチェックします。
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
また、コミュニケーションのすべてが適切に機密保護されるのを確実にするのにSNMPゲートウェイも原因となります。 明確に、SHOULDがどんなクライアントと共にも経営情報に関するそのコミュニケーションを確実にするSNMPゲートウェイは少なくとも対応するSNMPアクセス(securityLevelの詳しい情報に関して.3セクション3.4[RFC3411]を見る)に使用されるSNMP securityLevelに保護されます。 クライアントがセキュリティ情報をSNMPに供給して、SNMPゲートウェイSHOULDがクライアントを認証して、SHOULDが、認証された暗号の保全がチェックするのを確実にするなら
Black, et al. Standards Track [Page 13] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[13ページ]。
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ゲートウェイSHOULDは、そのコミュニケーションがキーか秘密の公開を防ぐのに暗号化が保全チェックに加えて使用されるのを確実にします。
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.
マックス-ACCESSがあるSNMP MIBsで定義された管理オブジェクトがあります。読書して書く、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境における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モジュール(すなわち、アクセスしやすくないのを除いたマックスACCESSがあるオブジェクト)によるいくつかの読み込み可能なオブジェクトがいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 ネットワークの上にそれらを送るとき、その結果、SNMPゲートウェイを通してこれらのオブジェクトへのGETアクセスさえ制御して、ことによるとこれらのオブジェクトの値を暗号化するのさえ重要です。 独特のMIBモジュール仕様、および特にそれらのセキュリティ問題は詳細のために相談されるべきです。 また、この考慮は読まれて、操作には副作用があるオブジェクトに適用されます。
7. IANA Considerations
7. IANA問題
The IANA has registered the URL registration template found in Appendix A in accordance with [RFC2717].
IANAは[RFC2717]に従ってAppendix Aで見つけられたURL登録テンプレートを登録しました。
8. Normative References
8. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", RFC
3061, February 2001.
[RFC3061] 食事、M.、「オブジェクト識別子のつぼの名前空間」、RFC3061、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、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411(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.、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMP)について議定書の中で述べます」、STD62、RFC3416、2002年12月。
Black, et al. Standards Track [Page 14] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[14ページ]。
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December
2002.
[RFC3417] Presuhn、R.、「簡単なネットワーク管理プロトコル(SNMP)のための輸送マッピング」、STD62、RFC3417、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の間の共存」BCP74、RFC3584(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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
9. Informative References
9. 有益な参照
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[RFC1900] 大工とB.とY.Rekhter、「番号を付け替えるのは仕事を必要とである」RFC1900、1996年2月。
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC2717]Petke、R.とI.キング、「URL体系名のための登録手順」BCP35、1999年11月のRFC2717。
[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.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」、RFC3410(2002年12月)。
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol Over
Transmission Control Protocol Transport Mapping", RFC 3430,
December 2002.
[RFC3430] Schoenwaelder、J.、「通信制御プロトコル輸送マッピングの上の簡単なネットワーク管理プロトコル」、RFC3430、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.と、「Uniform Resource Identifier(URI)体系とトリビアル・ファイル転送プロトコル(TFTP)のための適用性証明」、RFC3617(2003年10月)
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
Black, et al. Standards Track [Page 15] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[15ページ]。
10. Acknowledgements
10. 承認
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 メーリングリストからのコメントは、かなりの改善をもたらして、感謝して承諾されます。
Black, et al. Standards Track [Page 16] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[16ページ]。
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 Intended用法: セクション1と2 この体系を使用するApplications、そして/または、プロトコル: SNMP(すべてのバージョン)は[RFC3410]と[RFC3584]を見ます。 SNMP、もTCPの上では、[RFC3430]を見てください。 相互運用性問題: セクション4.4 Security問題: セクション6 Relevant刊行物: [RFC3410]繰返し要素の並びを見てください。 [RFC3430]とも[RFC3584。] 接触: デヴィッドL.Black、Author/変化Controllerの下で見てください: 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 メールしてください: black_david@emc.com
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
カリフォルニア米国 キースMcCloghrieシスコシステムズInc.170の西タスマン・Driveサンノゼ、95134
Phone: +1 (408) 526-5260 EMail: kzm@cisco.com
以下に電話をしてください。 +1 (408) 526-5260 メールしてください: 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 3587年の421 200メール: j.schoenwaelder@iu-bremen.de
Black, et al. Standards Track [Page 17] RFC 4088 URI Scheme for SNMP June 2005
黒、他 規格は2005年6月にSNMPのRFC4088URI体系を追跡します[17ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Black, et al. Standards Track [Page 18]
黒、他 標準化過程[18ページ]
一覧
スポンサーリンク
