RFC3395 日本語訳
3395 Remote Network Monitoring MIB Protocol Identifier ReferenceExtensions. A. Bierman, C. Bucci, R. Dietz, A. Warth. September 2002. (Format: TXT=43862 bytes) (Updates RFC2895) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Bierman
Request for Comments: 3395 C. Bucci
Updates: 2895 Cisco Systems, Inc.
Category: Standards Track R. Dietz
Hifn, Inc.
A. Warth
September 2002
Biermanがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3395のC.ブッチアップデート: 2895年のシスコシステムズInc.カテゴリ: 標準化過程R.ディーツHifn Inc.A.Warth2002年9月
Remote Network Monitoring MIB Protocol Identifier Reference Extensions
リモートネットワーク監視MIBプロトコル識別子参照拡張子
Status of this Memo
この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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This memo defines extensions to the Protocol Identifier Reference document for the identification of application verb information. It updates the Protocol Identifier Reference document but does not obsolete any portion of that document. In particular, it describes the algorithms required to identify protocol operations (verbs) within the protocol encapsulations managed with MIBs such as the Remote Network Monitoring MIB Version 2, RFC 2021.
このメモはアプリケーション動詞の情報の識別のためのプロトコルIdentifier Referenceドキュメントと拡大を定義します。 それは、プロトコルIdentifier Referenceドキュメントをアップデートしますが、そのドキュメントのどんな部分も時代遅れにしません。 特に、それはRemote Network Monitoring MIBバージョン2など(RFC2021)のMIBsと共に管理されたプロトコルカプセル化の中でプロトコル操作(動詞)を特定するのに必要であるアルゴリズムを説明します。
Table of Contents
目次
1. The SNMP Network Management Framework ..........................2 2. Overview .......................................................3 2.1 Protocol Identifier Framework .................................3 2.2 Protocol Identifier Extensions for Application Verbs ..........4 2.3 Terms .........................................................4 2.4 Relationship to the RMON-2 MIB ................................5 2.5 Relationship to the RMON MIB Protocol Identifier Reference.....5 3. Definitions ....................................................5 3.1 Verb Identifier Macro Format ..................................5 3.1.1 Lexical Conventions .........................................6 3.1.2 Extended Grammar for the PI Language ........................6 3.1.3 Mapping of the Parent Protocol Name .........................7 3.1.4 Mapping of the DESCRIPTION Clause ...........................7
1. SNMPネットワークマネージメントフレームワーク…2 2. 概要…3 2.1 識別子フレームワークについて議定書の中で述べてください…3 2.2 アプリケーション動詞のための識別子拡張子について議定書の中で述べてください…4 2.3の用語…4 RMON-2 MIBとの2.4関係…5 2.5 RMON MIBとの関係は識別子参照について議定書の中で述べます…5 3. 定義…5 3.1 識別子マクロ書式を動詞化してください…5 3.1 .1 語彙コンベンション…6 3.1 .2はパイ言語のために文法を広げました…6 3.1 親プロトコル名に関する.3マッピング…7 3.1 記述節に関する.4マッピング…7
Bierman, et. al. Standards Track [Page 1] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[1ページ]RFC3395RMONは識別子2002年9月に動詞化します。
3.1.5 Mapping of the REFERENCE Clause .............................7 3.1.6 Mapping of the Verb List Clause .............................7 3.1.6.1 Mapping of the Verb Name Field ............................8 3.1.6.2 Mapping of the Verb Enum Field ............................8 3.2 Protocol Directory Requirements ...............................8 3.2.1 Mapping of the Verb Layer Numbering Space ...................8 3.2.2 Mapping of the ProtocolDirID object .........................9 3.2.3 Mapping of the ProtocolDirParameters object .................9 3.2.4 Mapping of the ProtocolDirLocalIndex object ................10 3.2.5 Mapping of the protocolDirDescr object .....................10 3.2.6 Mapping of the protocolDirType object ......................10 3.2.7 Mapping of the protocolDirAddressMapConfig object ..........10 3.2.8 Mapping of the protocolDirHostConfig object ................10 3.2.9 Mapping of the protocolDirMatrixConfig object ..............10 3.2.10 Mapping of the protocolDirOwner object ....................11 3.2.11 Mapping of the protocolDirStatus object ...................11 4. Implementation Considerations .................................11 4.1 Stateful Protocol Decoding ...................................11 4.2 Packet Capture ...............................................11 4.3 RMON-2 MIB Collections .......................................12 5. Intellectual Property .........................................12 6. Acknowledgements ..............................................13 7. Normative References ..........................................13 8. Informative References ........................................14 9. IANA Considerations ...........................................15 10. Security Considerations ......................................15 Appendix A: Usage Examples .......................................16 A.1 FTP Example ..................................................16 A.2 POP3 Example .................................................17 A.3 SNMP Example .................................................18 A.4 HTTP Example .................................................18 A.5 SMTP Example .................................................19 Authors' Addresses ...............................................20 Full Copyright Statement..........................................21
3.1.5 参照節に関するマッピング…7 3.1 動詞のリスト節に関する.6マッピング…7 3.1 .6 動詞の名前欄に関する.1マッピング…8 3.1 .6 動詞のEnum分野に関する.2マッピング…8 3.2 ディレクトリ要件について議定書の中で述べてください…8 3.2 動詞の層の付番スペースに関する.1マッピング…8 3.2 ProtocolDirIDオブジェクトに関する.2マッピング…9 3.2 ProtocolDirParametersオブジェクトに関する.3マッピング…9 3.2 ProtocolDirLocalIndexオブジェクトに関する.4マッピング…10 3.2 protocolDirDescrオブジェクトに関する.5マッピング…10 3.2 protocolDirTypeオブジェクトに関する.6マッピング…10 3.2 protocolDirAddressMapConfigオブジェクトに関する.7マッピング…10 3.2 protocolDirHostConfigオブジェクトに関する.8マッピング…10 3.2 protocolDirMatrixConfigオブジェクトに関する.9マッピング…10 3.2 protocolDirOwnerオブジェクトに関する.10マッピング…11 3.2 protocolDirStatusオブジェクトに関する.11マッピング…11 4. 実装問題…11 4.1 Statefulは解読について議定書の中で述べます…11 4.2 パケット捕獲…11 4.3 RMON-2 MIB収集…12 5. 知的所有権…12 6. 承認…13 7. 標準の参照…13 8. 有益な参照…14 9. IANA問題…15 10. セキュリティ問題…15 付録A: 用法の例…16A.1FTPの例…16A.2 POP3の例…17A.3 SNMPの例…18A.4HTTPの例…18A.5 SMTPの例…19人の作者のアドレス…20 完全な著作権宣言文…21
1. The SNMP Network Management Framework
1. SNMPネットワークマネージメントフレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [RFC2571].
o RFC2571[RFC2571]で説明された総合的なアーキテクチャ。
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and is described
in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and
o オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 そしてManagement情報(SMI)のこのStructureの最初のバージョンは、SMIv1と呼ばれて、STD16で説明されます、RFC1155[RFC1155]、STD16、RFC1212[RFC1212]。
Bierman, et. al. Standards Track [Page 2] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[2ページ]RFC3395RMONは識別子2002年9月に動詞化します。
RFC 1215 [RFC1215]. The second version, called SMIv2, is
described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and
RFC 2580 [RFC2580].
RFC1215[RFC1215]。 SMIv2と呼ばれる第2バージョンはSTD58、RFC2578[RFC2578]、RFC2579[RFC2579]、およびRFC2580[RFC2580]で説明されます。
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
is described in STD 15, RFC 1157 [RFC1157]. A second version
of the SNMP message protocol, which is not an Internet
standards track protocol, is called SNMPv2c and is described in
RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version
of the message protocol is called SNMPv3 and is described in
RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o 経営情報を移すためのメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、SNMPv1と呼ばれて、STD15、RFC1157[RFC1157]で説明されます。 SNMPメッセージプロトコルの第2のバージョンは、SNMPv2cと呼ばれて、RFC1901[RFC1901]とRFC1906[RFC1906]で説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、SNMPv3と呼ばれて、RFC1906[RFC1906]、RFC2572[RFC2572]、およびRFC2574[RFC2574]で説明されます。
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
o 経営情報にアクセスするための操作について議定書の中で述べてください。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[RFC1157]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[RFC1905]で説明されます。
o A set of fundamental applications is described in RFC 2573
[RFC2573]. The view-based access control mechanism is
described in RFC 2575 [RFC2575].
o 1セットの基礎的応用はRFC2573[RFC2573]で説明されます。 視点ベースのアクセス管理機構はRFC2575[RFC2575]で説明されます。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].
RFC2570[RFC2570]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
This memo does not specify a MIB module.
このメモはMIBモジュールを指定しません。
2. Overview
2. 概要
There is a need for a standardized way of identifying the protocol operations defined for particular application protocols. Different protocol operations can have very different performance characteristics, and it is desirable to collect certain metrics at this level of granularity. This memo defines extensions to the existing protocol identifier structure [RFC2895] and is intended to update, not obsolete, the existing protocol identifier encoding rules.
特定用途プロトコルのために定義されたプロトコル操作を特定する標準化された方法の必要があります。 異なったプロトコル操作は非常に異なった性能の特性を持つことができます、そして、このレベルの粒状で、ある測定基準を集めるのは望ましいです。 このメモは、既存のプロトコル識別子構造[RFC2895]と拡大を定義して、時代遅れにではなく、既存のプロトコル識別子符号化規則をアップデートすることを意図します。
2.1 Protocol Identifier Framework
2.1 プロトコル識別子フレームワーク
The RMON Protocol Identifier (PI) structure [RFC2895] allows for a variable number of layer identifiers. Each layer contributes 4 octets to the protocolDirID OCTET STRING and one octet to the
プロトコルIdentifier(PI)が構造化するRMON[RFC2895]は可変数の層の識別子を考慮します。 各層はprotocolDirID OCTET STRINGとある八重奏への4つの八重奏を寄付します。
Bierman, et. al. Standards Track [Page 3] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[3ページ]RFC3395RMONは識別子2002年9月に動詞化します。
protocolDirParameters OCTET STRING. These two MIB objects comprise the index in the protocolDirTable [RFC2021] and represent a globally unique identifier for a particular protocol encapsulation (or set of encapsulations if the wild-card base layer is used).
protocolDirParameters八重奏ストリング。 これらの2個のMIBオブジェクトが、protocolDirTable[RFC2021]にインデックスを含んで、特定のプロトコルカプセル化のためにグローバルにユニークな識別子を表します(カプセル化のセットはワイルドカード基層であるなら使用されています)。
2.2 Protocol Identifier Extensions for Application Verbs
2.2 アプリケーション動詞のためのプロトコル識別子拡張子
The existing RMON protocol identifier architecture requires that an application verb be represented by one additional protocol layer, appended to the protocol identifier for the parent application. Since some application verbs are defined as strings which can exceed 4 octets in length, an integer mapping must be provided for each string. This memo specifies how the verb layer is structured, as well as a verb identifier macro syntax for specification of verb name to integer mappings.
既存のRMONプロトコル識別子アーキテクチャは、アプリケーション動詞が親出願のためのプロトコル識別子に追加された1つの追加議定書層のそばに表されるのを必要とします。 いくつかのアプリケーション動詞が長さにおける4つの八重奏を超えることができるストリングと定義されるので、整数マッピングを各ストリングに提供しなければなりません。 このメモは動詞の層がどう構造化されるかを指定します、整数マッピングへの動詞の名の仕様のための動詞の識別子マクロ構文と同様に。
2.3 Terms
2.3 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
This document uses some terms defined in the RMON Protocol Identifier Reference document [RFC2895] and some new terms that need introduction here.
このドキュメントはRMONプロトコルIdentifier Referenceドキュメント[RFC2895]で定義されたいくつかの用語とここで序論を必要とするいくつかの新学期を費やします。
Application Verb
Also called simply 'verb'. Refers to one of potentially many
protocol operations that are defined by a particular application
protocol.
単に呼ばれるアプリケーションVerb Alsoは'動詞化します'。 特定用途プロトコルによって定義される潜在的に多くのプロトコル操作の1つについて言及します。
Note that an application verb is not equivalent to an application
protocol sub-command or opcode within a packet containing a PDU
for the application. An application verb is a transaction type
and may involve several PDU types within the application protocol
(e.g., SNMP Get-PDU and Response-PDU). In some applications, a
verb may encompass protocol operations pertaining to more than one
protocol entry in the protocol directory (e.g., ftp and ftp-data).
アプリケーションのためのPDUを含んでいて、アプリケーション動詞がパケットの中でアプリケーション・プロトコルサブコマンドかopcodeに同等でないことに注意してください。 アプリケーション動詞は、トランザクションタイプであり、アプリケーション・プロトコル(例えば、SNMP Get-PDUとResponse-PDU)の中でいくつかのPDUタイプにかかわるかもしれません。 使用目的によっては、動詞はプロトコルディレクトリ(例えば、ftpとftp-データ)における1つ以上のプロトコルエントリーに関係するプロトコル操作を成就するかもしれません。
Connect Verb
The special application verb associated with connection or session
setup and tear-down traffic, and not attributed to any other verb
for the application. This verb is assigned the enumeration value
of zero, and the verb 'connect(0)' is implicitly defined for all
application protocols.
接続かセッションセットアップと分解トラフィックに関連づけられて、アプリケーションのためのいかなる他の動詞も結果と考えられないで、特別なアプリケーションが動詞化するVerbを接続してください。 ゼロの列挙値はこの動詞に割り当てられます、そして、'(0)を接続する'という動詞はすべてのアプリケーション・プロトコルのためにそれとなく定義されます。
Bierman, et. al. Standards Track [Page 4] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[4ページ]RFC3395RMONは識別子2002年9月に動詞化します。
Parent Application
One of potentially many protocol encapsulations which identifies a
particular application protocol. This term refers generically to
any or all such encapsulations for a given set of application
verbs.
潜在的に多くの親Application Oneはカプセル化について議定書の中で述べます(特定用途プロトコルを特定します)。 今期は与えられたセットのアプリケーション動詞について一般的にいずれかそのようなすべてのカプセル化について言及します。
Verb Layer
The portion of the protocol identifier octet string which
identifies the application verb.
Layerを動詞化してください。アプリケーション動詞を特定するプロトコル識別子八重奏ストリングの一部。
Verb Set
The group of verbs enumerated for a particular application
protocol. The list of verb strings within a particular verb-
identifier macro invocation is also called the verb set for that
verb identifier.
Setを動詞化してください。動詞のグループは特定用途のためにプロトコルを列挙しました。 また、特定の動詞の識別子マクロ実施の中の動詞のストリングのリストはその動詞の識別子のために動詞のセットと呼ばれます。
2.4 Relationship to the RMON-2 MIB
2.4 RMON-2 MIBとの関係
The RMON-2 MIB [RFC2021] contains the protocolDirTable MIB objects used to identify all protocol encapsulations that can be monitored by a particular RMON agent.
RMON-2 MIB[RFC2021]は特定のRMONエージェントがモニターできるすべてのプロトコルカプセル化を特定するのに使用されるprotocolDirTable MIBオブジェクトを含んでいます。
This memo describes how these MIB objects are mapped by an implementation for entries which identify application verbs. This document does not define any new MIB objects to identify application verbs. The applicability of the definitions in this document is not limited to the RMON-2 MIB. Other specifications which utilize the RMON-2 protocolDirTable and/or the protocol identifier macros which it represents can also utilize the application verb macro definitions contained in this document.
このメモはこれらのMIBオブジェクトが実装によってどう写像されるかをアプリケーション動詞を特定するエントリーに説明します。 このドキュメントは、アプリケーション動詞を特定するためにどんな新しいMIBオブジェクトも定義しません。 定義の適用性は本書ではRMON-2 MIBに制限されません。 また、RMON-2 protocolDirTableを利用する他の仕様、そして/または、それが表すプロトコル識別子マクロは本書では含まれたアプリケーション動詞のマクロ定義を利用できます。
2.5 Relationship to the RMON MIB Protocol Identifier Reference
2.5 RMON MIBプロトコル識別子参照との関係
The RMON MIB Protocol Identifier Reference [RFC2895] defines the RMON Protocol Identifier Macro Specification Language as well as the encoding rules for the ProtocolDirID and protocolDirParameters OCTET STRINGs. This memo defines extensions to the Protocol Identifier Reference for the identification of application verb information. It does not obsolete any portion of the Protocol Identifier Reference document.
RMON MIBプロトコルIdentifier Reference[RFC2895]はProtocolDirIDとprotocolDirParameters OCTET STRINGsのための符号化規則と同様にRMONプロトコルIdentifier Macro Specification Languageを定義します。 このメモはアプリケーション動詞の情報の識別のためにプロトコルIdentifier Referenceと拡大を定義します。 それはプロトコルIdentifier Referenceドキュメントのどんな部分も時代遅れにしません。
3. Definitions
3. 定義
3.1 Verb Identifier Macro Format
3.1 動詞の識別子マクロ形式
The following example is meant to introduce the verb-identifier macro. This macro-like construct is used to represent protocol verbs for a specific parent application.
以下の例は動詞識別子マクロを導入することになっています。 このマクロのような構造物は、特定の親出願のためのプロトコル動詞を表すのに使用されます。
Bierman, et. al. Standards Track [Page 5] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[5ページ]RFC3395RMONは識別子2002年9月に動詞化します。
3.1.1 Lexical Conventions
3.1.1 語彙コンベンション
The following keyword is added to the PI language:
以下のキーワードはPI言語に追加されます:
VERB-IDENTIFIER
動詞識別子
3.1.2 Extended Grammar for the PI Language
3.1.2 パイ言語のための拡張文法
The following is the extended BNF notation for the grammar with starting symbol <piFile>. It is for representing verb identifier macros. Note that only the term <piFile> is actually modified from the definition in [RFC2895]. The <piDefinition> syntax is not reproduced here, since this memo is intended to extend that definition, not replace it.
↓これは始めのシンボル<piFile>がある文法のための拡張BNF記法です。 それは、動詞の識別子マクロを表すものです。 >という用語だけ<piFileが実際に[RFC2895]との定義から変更されることに注意してください。 このメモがそれを取り替えるのではなく、その定義を広げることを意図するので、<piDefinition>構文はここで再生しません。
-- a file containing one or more
-- Protocol Identifier (PI) definitions
<piFile> = [ <piDefinition> | <piVerbDefinition> ]...
-- 1つ以上を含むファイル--Identifier(PI)定義<piFile>=[<piDefinition>| <piVerbDefinition>]について議定書の中で述べてください…
-- a PI definition
<piVerbDefinition> =
[<wspace>] <parentProtoName> <wspace> "VERB-IDENTIFIER"
<wspace> "DESCRIPTION" <wspace> string
[ <wspace> "REFERENCE" <wspace> string ]
[<wspace>] "::=" [<wspace>]
"{" [<wspace>] <verbList> [<wspace>] "}" [<wspace>]
-- 「PI定義<piVerbDefinition>=[<wspace>]<parentProtoName><wspace>「動詞識別子」<wspace>「記述」<wspace>ストリング[「参照」<wspace>が結ぶ<wspace>][<wspace>]」:、:=「[<wspace>]「「[<wspace>]<verbList>[<wspace>]」」」[<wspace>]
-- a list of verb identifier string
<verbList> = <verbId> [ [<wspace>] "," [<wspace>] <verbId> ]...
-- 」 「動詞の識別子ストリング<verbList>=<verbId>[<wspace>]のリスト」、[<wspace>] <verbId>]…
-- a verb identifier string
<verbId> = <verbName> [<wspace>] "(" [<wspace>]
<verbEnum> [<wspace>] ")" [<wspace>]
-- 動詞の識別子ストリング<verbId>は<verbName>[<wspace>]と等しいです「(「[<wspace>]<verbEnum>[<wspace>]」)」という。[<wspace>]
-- a protocol name
<parentProtoName> = <protoName>
-- プロトコル名前<parentProtoName>は<protoName>と等しいです。
-- a verb name
<verbName> = <lcname>
-- 動詞の名前<verbName>は<lcname>と等しいです。
-- a verb enumeration
<verbEnum> = <posNum>
-- 動詞の列挙<verbEnum>は<posNum>と等しいです。
-- a positive integer
<posNum> = any integer value greater than zero and
less than 16,777,216
-- ゼロより大きいどんな整数値と<posNum>=1677万7216未満の正の整数
-- <piDefinition> syntax is defined in [RFC2895]
-- 構文が定義される<piDefinition>。[RFC2895]
Bierman, et. al. Standards Track [Page 6] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[6ページ]RFC3395RMONは識別子2002年9月に動詞化します。
-- <protoName> syntax is defined in [RFC2895]
-- <wspace> syntax is defined in [RFC2895]
-- <lcname> syntax is defined in [RFC2895]
-- <protoName>構文は[RFC2895]--構文が定義される<wspace>[RFC2895]-->構文が定義される<lcnameで定義されます。[RFC2895]
3.1.3 Mapping of the Parent Protocol Name
3.1.3 親プロトコル名に関するマッピング
The "parentProtoName" value, called the "parent protocol name", SHOULD be an ASCII string consisting of 1 to 64 characters. (These names are intended to appear in IETF documentation, so the use of UTF-8 is not appropriate.) The encoding rules are exactly as specified in section 6.2.4 of [RFC2895] for the mapping of the protocol name field. The value for <parentProtoName> (which is called the "parent protocol name") MUST be the value of a protocol identifier defined as specified for <protoName> in section 3.2.4 of [RFC2895]. The value of <parentProtoName> MUST specify a <protoName> defined in the <piFile>.
ASCIIストリングが成ることであったなら1〜64のキャラクタで「親プロトコル名」、SHOULDと呼ばれる"parentProtoName"値。 (これらの名前がIETFドキュメンテーションに載っていることを意図するので、UTF-8の使用は適切ではありません。) 符号化規則はまさに.4セクション6.2[RFC2895]でプロトコル名前欄に関するマッピングに指定されるようにそうです。 <parentProtoName>(「親プロトコル名」と呼ばれる)のための値は.4セクション3.2[RFC2895]の<protoName>に指定されるように定義されたプロトコル識別子の値でなければなりません。 <parentProtoName>の値は<piFile>で定義された<protoName>を指定しなければなりません。
A protocol identifier macro SHOULD exist in the <piFile> for at least one encapsulation of the parent application protocol if any verb identifier macros referencing that parent application are present in the <piFile>.
その親出願に参照をつける何か動詞の識別子マクロが<piFile>に存在しているなら、プロトコル識別子マクロSHOULDは親アプリケーション・プロトコルの少なくとも1つのカプセル化のための<piFile>に存在しています。
3.1.4 Mapping of the DESCRIPTION Clause
3.1.4 記述節に関するマッピング
The DESCRIPTION clause provides a textual description of the protocol verb set identified by this macro. It SHOULD NOT contain details about items covered by the REFERENCE clause. The DESCRIPTION clause MUST be present in all verb-identifier macro declarations.
記述節はこのマクロによって特定されたプロトコル動詞のセットの原文の記述を提供します。 それ、SHOULD NOTはREFERENCE節でカバーされた項目に関する詳細を含んでいます。 記述節はすべての動詞識別子マクロ宣言で存在していなければなりません。
3.1.5 Mapping of the REFERENCE Clause
3.1.5 参照節に関するマッピング
If a publicly available reference document exists for this set of application protocol verbs, it SHOULD be listed here. Typically this will be a URL, otherwise it will be the name and address of the controlling body.
公的に利用可能な参考書類はaであるならこのセットのアプリケーション・プロトコル動詞のために存在していて、それはSHOULDです。ここに、記載されています。 さもなければ、それは、これが通常、URLになって、制御ボディーの名前とアドレスになるでしょう。
The REFERENCE clause is optional but SHOULD be present if an authoritative reference exists which specifies the application protocol verbs defined in the <verbList> section of this macro.
REFERENCE節が任意である、SHOULD、このマクロの<verbList>部で定義されたアプリケーション・プロトコル動詞を指定する正式の参照が存在するなら、存在してください。
3.1.6 Mapping of the Verb List Clause
3.1.6 動詞のリスト節に関するマッピング
The verb list clause MUST be present. It is used to identify a list of application verb names and associate a numeric constant with each verb name. At least one verb MUST be specified and a maximum of 16,777,215 (2^^24 - 1) verbs MAY be specified. This enumerated list SHOULD be densely numbered (i.e., valued from '1' to 'N', where 'N' is the total number of verbs defined in the macro).
動詞のリスト節は存在していなければなりません。 それは、アプリケーション動詞の名のリストを特定して、それぞれの動詞の名に数値定数を関連づけるのに使用されます。 少なくとも1つの動詞を指定しなければなりません、そして、最大1677万7215(2^^24--1)の動詞が指定されるかもしれません。 'この列挙されたリストSHOULDが密にそうである、番号付、(すなわち、'1'から評価される、'、どこ、'動詞の総数がマクロで定義されるか、)
Bierman, et. al. Standards Track [Page 7] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[7ページ]RFC3395RMONは識別子2002年9月に動詞化します。
3.1.6.1 Mapping of the Verb Name Field
3.1.6.1 動詞の名前欄に関するマッピング
The <verbName> field is case-sensitive and SHOULD be set to the most appropriate string name for each application verb. If such a descriptive string is defined in an authoritative document then that string SHOULD be used. If no such string exists then an appropriate but arbitrary string should be selected for this value.
<verbName>分野が大文字と小文字を区別している、SHOULD、それぞれのアプリケーション動詞のために最も適切なストリング名に設定されてください。 そのような描写的であるストリングがストリングSHOULDが使用されるのについてその時信頼すべき文書で定義されるなら。 どれかそのようなストリングが存在していないなら、適切な、しかし、任意のストリングはこの値のために選択されるべきです。
Verb names MUST be unique for a particular parent application. Note that the special 'connect(0)' verb is implicitly defined for each application protocol. It is possible for an explicit definition of this verb (e.g., 'connect(8)' for http) to exist for a protocol, as well as the implicit 'connect(0)' verb.
特定の親出願に、動詞の名はユニークであるに違いありません。 '(0)を接続する'という特別番組が動詞化するというメモは各アプリケーション・プロトコルのためにそれとなく定義されます。 この動詞(例えば、httpのために'(8)を接続する')の明白な定義がプロトコルのために存在するのは、可能です、'(0)を接続してください'という暗黙の動詞と同様に。
3.1.6.2 Mapping of the Verb Enum Field
3.1.6.2 動詞のEnum分野に関するマッピング
The <verbEnum> field MUST be unique for all verbs associated with a particular parent application. This field SHOULD contain a value between '1' and '16,777,215' inclusive.
特定の親出願に関連しているすべての動詞に、<verbEnum>分野はユニークであるに違いありません。 この分野SHOULDは'1'と'1677万7215'の間に包括的に値を含んでいます。
3.2 Protocol Directory Requirements
3.2 プロトコルディレクトリ要件
This section defines how the protocolDirTable should be populated for any application verb identified with a verb-identifier macro.
このセクションはprotocolDirTableが動詞識別子マクロと同一視されたどんなアプリケーション動詞のためにもどう居住されるべきであるかを定義します。
An agent MUST implement all applicable protocolDirTable MIB objects on behalf of each supported application verb.
エージェントはそれぞれのサポートしているアプリケーション動詞を代表してすべての適切なprotocolDirTable MIBオブジェクトを実装しなければなりません。
3.2.1 Mapping of the Verb Layer Numbering Space
3.2.1 動詞の層の付番スペースに関するマッピング
The verb layer consists of the 4 octets within the protocolDirID INDEX field which identify a particular application verb.
動詞の層はprotocolDirID INDEX分野の中の特定用途動詞を特定する4つの八重奏から成ります。
Figure 1
Verb Layer Format
-----------------
図1 動詞の層の形式-----------------
protocolDirID string fragment
---+--------+--------+--------+--------+
| resrvd | |
.. | set to | verb enumeration value |
| zero | (a) (b) (c) |
---+--------+--------+--------+--------+ octet
| 1 | 3 | count
protocolDirIDストリング断片---+--------+--------+--------+--------+ | resrvd| | .. | セットされます。| 動詞の列挙価値| | ゼロ| (a) (b) (c) | ---+--------+--------+--------+--------+ 八重奏| 1 | 3 | カウント
The first octet is reserved for future use and MUST be set to zero.
最初の八重奏を今後の使用のために控えられて、ゼロに設定しなければなりません。
Bierman, et. al. Standards Track [Page 8] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[8ページ]RFC3395RMONは識別子2002年9月に動詞化します。
The next three octets identify the <verbEnum> field used to enumerate the particular application verb represented by the <verbName> field. This field is a 24-bit unsigned integer, encoded in network byte order.
次の3つの八重奏が<verbName>分野によって表された特定用途動詞を列挙するのに使用される<verbEnum>分野を特定します。 この分野はネットワークバイトオーダーでコード化された24ビットの符号のない整数です。
The value zero is reserved to identify the special 'connect(0)' verb. This verb enumeration value (i.e., '0' part of 'connect(0)') MUST NOT be redefined in a verb identifier macro verb list. Note that the verb name 'connect' is not reserved and MAY be redefined in a verb list.
値ゼロは、'(0)を接続してください'という特別な動詞を特定するために予約されます。 この動詞の列挙価値(すなわち、'(0)を接続してください'の'0'部分)を動詞の識別子マクロ動詞のリストに再定義してはいけません。 '接続'という動詞の名が予約されていなくて、動詞のリストに再定義されるかもしれないことに注意してください。
3.2.2 Mapping of the ProtocolDirID object
3.2.2 ProtocolDirIDオブジェクトに関するマッピング
The protocolDirID OCTET STRING value for a particular application verb is represented by the protocolDirID value for the parent application, appended with the verb's layer identifier value.
特定用途動詞のためのprotocolDirID OCTET STRING値は動詞の層の識別子価値と共に追加された親出願のためにprotocolDirID値によって表されます。
Figure 2
ProtocolDirID Format for Verbs
------------------------------
図2 動詞のためのProtocolDirID形式------------------------------
protocolDirID string
+--------+--------+--------+--------+
| parent | verb |
| protocolDirID | layer |
| string | value |
+--------+--------+--------+--------+ octet
| length of parent ID | 4 | count
protocolDirIDストリング+--------+--------+--------+--------+ | 親| 動詞| | protocolDirID| 層| | ストリング| 値| +--------+--------+--------+--------+ 八重奏| 親IDの長さ| 4 | カウント
The protocolDirID object is encoded as the protocolDirID value of the parent application, followed by four additional octets representing the verb layer. The verb layer value is encoded as [0.a.b.c] where 'a' is the high order byte, 'b' is the middle order byte, and 'c' is the low order byte of the <verbEnum> field for the specific application verb value. A valid PI verb enumeration will be encoded in the range "0.0.0.0" to "0.255.255.255", where the special value "0.0.0.0" is reserved for the implicitly defined 'connect(0)' verb.
protocolDirIDオブジェクトは動詞の層を表す4つの追加八重奏があとに続いた親出願のprotocolDirID値としてコード化されます。 動詞の層の価値は特定のアプリケーション動詞の価値のために[0.a.b.c]として'a'が高位バイトであり、'b'が中くらいのオーダーバイトであり、'c'が<verbEnum>分野の下位バイトであるところでコード化されます。 有効なPI動詞の列挙が範囲でコード化される、「0.0、.0、0インチ、「0.255、.255、0.255インチ、特別番組が評価するどこ、「0.0 .0 それとなく定義されているのが'(0) '動詞を接続する」ので、0インチは予約されているか。
3.2.3 Mapping of the ProtocolDirParameters object
3.2.3 ProtocolDirParametersオブジェクトに関するマッピング
The protocolDirParameters OCTET STRING value for a particular application verb is represented by the protocolDirParameters value for the parent application, appended with one octet containing the value zero. Although not actually used, this field is included to conform to the encoding rules defined in the Protocol Identifiers Reference [RFC2895].
特定用途動詞のためのprotocolDirParameters OCTET STRING値は1つの八重奏が値ゼロを含んでいて追加された親出願のためにprotocolDirParameters値によって表されます。 実際に使用されませんが、この分野は、プロトコルIdentifiers Reference[RFC2895]で定義された符号化規則に従うために含まれています。
Bierman, et. al. Standards Track [Page 9] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[9ページ]RFC3395RMONは識別子2002年9月に動詞化します。
3.2.4 Mapping of the ProtocolDirLocalIndex object
3.2.4 ProtocolDirLocalIndexオブジェクトに関するマッピング
The agent MUST assign an appropriate protocolDirLocalIndex value for each application verb according to the encoding rules defined for this object in [RFC2021] and [RFC2895].
[RFC2021]と[RFC2895]のこのオブジェクトのために定義された符号化規則によると、エージェントはそれぞれのアプリケーション動詞のために適切なprotocolDirLocalIndex値を割り当てなければなりません。
3.2.5 Mapping of the protocolDirDescr object
3.2.5 protocolDirDescrオブジェクトに関するマッピング
The agent MUST convey the <verbName> value for a particular application verb in the protocolDirDescr object. This object SHOULD be encoded as the protocolDirDescr value for the parent application appended with a 'dot' character, followed by the exact text contained in the <verbName> field.
エージェントはprotocolDirDescrオブジェクトの特定用途動詞のために<verbName>価値を伝えなければなりません。 protocolDirDescrが'ドット'キャラクタと共に追加された親出願のために評価するようにこのオブジェクトSHOULDがコード化されて、正確があとに続いていて、テキストは<にverbName>分野を含みました。
3.2.6 Mapping of the protocolDirType object
3.2.6 protocolDirTypeオブジェクトに関するマッピング
The agent MUST set the protocolDirType object for each application
verb to the value representing the empty bit set ( {} ).
エージェントが空のビットが設定した値の表すことへのそれぞれのアプリケーション動詞にprotocolDirTypeオブジェクトを設定しなければならない、()
3.2.7 Mapping of the protocolDirAddressMapConfig object
3.2.7 protocolDirAddressMapConfigオブジェクトに関するマッピング
The agent MUST set the protocolDirAddressMapConfig object for each application verb to the value 'notSupported(1)'.
エージェントは値の'notSupported(1)'へのそれぞれのアプリケーション動詞にprotocolDirAddressMapConfigオブジェクトを設定しなければなりません。
3.2.8 Mapping of the protocolDirHostConfig object
3.2.8 protocolDirHostConfigオブジェクトに関するマッピング
The agent MUST set the protocolDirHostConfig object for each application verb present in the protocol directory according to the monitoring capabilities for each verb. The agent MAY set this object to the same value as configured in the parent application protocolDirHostConfig object. The agent MAY choose to transition this object from the value 'supportedOn(2)' to 'supportedOff(3)' if the parent application protocolDirHostConfig object first transitions from 'supportedOn(2)' to 'supportedOff(3)'.
エージェントはモニターしている能力に従った各動詞のためのプロトコルディレクトリの現在のそれぞれのアプリケーション動詞にprotocolDirHostConfigオブジェクトを設定しなければなりません。 エージェントは親出願protocolDirHostConfigオブジェクトの構成されるのと同じ値にこのオブジェクトを設定するかもしれません。 親出願protocolDirHostConfigオブジェクトが最初に'supportedOn(2)'から'supportedOff(3)'に移行するなら、エージェントはこの値の'supportedOn(2)'から'supportedOff(3)'までのオブジェクトを変遷に選ぶかもしれません。
3.2.9 Mapping of the protocolDirMatrixConfig object
3.2.9 protocolDirMatrixConfigオブジェクトに関するマッピング
The agent MUST set the protocolDirMatrixConfig object for each application verb according to the monitoring capabilities for each verb. The agent MAY set this object to the same value as configured in the parent application protocolDirMatrixConfig object. The agent MAY choose to transition this object from the value 'supportedOn(2)' to 'supportedOff(3)' if the parent application protocolDirMatrixConfig object first transitions from 'supportedOn(2)' to 'supportedOff(3)'.
モニターしている能力に従って、エージェントは各動詞のためにそれぞれのアプリケーション動詞にprotocolDirMatrixConfigオブジェクトを設定しなければなりません。 エージェントは親出願protocolDirMatrixConfigオブジェクトの構成されるのと同じ値にこのオブジェクトを設定するかもしれません。 親出願protocolDirMatrixConfigオブジェクトが最初に'supportedOn(2)'から'supportedOff(3)'に移行するなら、エージェントはこの値の'supportedOn(2)'から'supportedOff(3)'までのオブジェクトを変遷に選ぶかもしれません。
Bierman, et. al. Standards Track [Page 10] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[10ページ]RFC3395RMONは識別子2002年9月に動詞化します。
3.2.10 Mapping of the protocolDirOwner object
3.2.10 protocolDirOwnerオブジェクトに関するマッピング
This object is encoded exactly the same for application verbs as for other protocolDirTable entries, according to the rules specified in the RMON-2 MIB [RFC2021].
このオブジェクトはアプリケーション動詞のためにまさに他のprotocolDirTableエントリーのように同じようにコード化されます、RMON-2 MIB[RFC2021]で指定された規則に従って。
3.2.11 Mapping of the protocolDirStatus object
3.2.11 protocolDirStatusオブジェクトに関するマッピング
This object is encoded exactly the same for application verbs as for other protocolDirTable entries, according to the rules specified in RMON-2 MIB [RFC2021].
このオブジェクトはアプリケーション動詞のためにまさに他のprotocolDirTableエントリーのように同じようにコード化されます、RMON-2 MIB[RFC2021]で指定された規則に従って。
4. Implementation Considerations
4. 実装問題
This section discusses the implementation implications for agents which support verbs in the protocol directory and the RMON collections which utilize the protocol directory.
このセクションはエージェントのためのプロトコルディレクトリの動詞をサポートする実装含意とプロトコルディレクトリを利用するRMON収集について論じます。
4.1 Stateful Protocol Decoding
4.1 Statefulプロトコル解読
Implementations of the RMON-2 MIB for application layer and network layer protocols typically require little if any state to be maintained by the probe. The probe can generally decide whether to count a packet and its octets on the packet's own merits, without referencing or updating any state information.
応用層とネットワーク層プロトコルのためのRMON-2 MIBの実装は、まずの状態が徹底的調査で維持されるのを通常必要とします。 一般に、徹底的調査は、パケットの自己の長所でパケットとその八重奏を数えるかどうか決めることができます、どんな州の情報も参照をつけるか、またはアップデートしないで。
Implementations of the RMON-2 MIB at the verb layer will, for many protocols, need to maintain state information in order to correctly classify a packet as "belonging" to one verb or another. The examples below illustrate this point.
動詞の層のRMON-2 MIBの実装は、多くのプロトコルに何らかの動詞への「属します」として正しくパケットを分類するために州の情報を保守する必要があるでしょう。 以下の例はこのポイントを例証します。
For SNMP over UDP, a Response-PDU for an SNMP Get-PDU can't be distinguished from a Response-PDU for a Getnext-PDU. A probe would need to maintain state information in order to correlate a Response- PDU from B to A with a previous request from A to B.
UDPの上のSNMPに関しては、Getnext-PDUのためにResponse-PDUとSNMP Get-PDUのためのResponse-PDUを区別できません。 徹底的調査は、前のAからBまでの要求でResponse- PDUをBからAまで関連させるように州の情報を保守する必要があるでしょう。
For application protocols carried over a stream-based transport such as TCP, the information required to identify an application verb can span several packets. A probe would need to follow the transport- layer flow in order to correctly parse the application-layer data.
TCPなどのストリームベースの輸送の上まで運ばれたアプリケーション・プロトコルのために、アプリケーション動詞を特定するのに必要である情報はいくつかのパケットにかかることができます。 徹底的調査は、正しく応用層データを分析するために輸送層の流動に続く必要があるでしょう。
4.2 Packet Capture
4.2 パケット捕獲
For packet capture based on verb-layer protocol directory filtering, the decision to include a packet in the capture buffer may need to be deferred until the packet can be conclusively attributed to a
動詞層のプロトコルディレクトリフィルタリングに基づくパケット捕獲のために、捕獲バッファにパケットを含んでいるという決定は、最終的にパケットをaの結果と考えることができるまで延期される必要があるかもしれません。
Bierman, et. al. Standards Track [Page 11] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[11ページ]RFC3395RMONは識別子2002年9月に動詞化します。
particular verb. A probe may need to pre-buffer packets while deciding to include or exclude them from capture based on other packets that have not yet arrived.
特定の動詞。 徹底的調査は、まだ到着していない他のパケットに基づく捕獲からそれらを含んでいるか、または除くと決めている間、パケットをあらかじめバッファリングする必要があるかもしれません。
4.3 RMON-2 MIB Collections
4.3 RMON-2 MIB収集
Data collections such as the protocol distribution or Application Layer Host Table (alHostTable) require that each packet is counted only once, i.e., a given packet is fully classified as a single protocol encapsulation which resolves to a single leaf entry in the protocol directory. Also, octet counters related to protocol classification are incremented by the entire size of packet, not just the octets associated with a particular encapsulation layer.
プロトコル分配かApplication Layer Host Table(alHostTable)などのデータ収集は、各パケットが一度だけ数えられて、すなわち、当然のことのパケットが中の単葉エントリーにプロトコルディレクトリを決議するただ一つのプロトコルカプセル化として完全に分類されるのを必要とします。 また、プロトコル分類に関連する八重奏カウンタは特定のカプセル化層に関連している八重奏だけではなく、パケットの全体のサイズによって増加されます。
It is possible that particular application protocols will allow multiple types of verbs to be present in a single packet. In this case, the agent MUST choose one verb type, and therefore one protocol directory entry, in order to properly count such a packet.
特定用途プロトコルが、複数のタイプの動詞が単一のパケットで現在であるのを許容するのは、可能です。 エージェントは、この場合1つの動詞のタイプを選んで、したがって、1つのプロトコルディレクトリエントリを選ばなければなりません、適切にそのようなパケットを数えるために。
It is an implementation-specific matter as to which verb type an agent selects to identify a packet in the event more than one verb type is present in that packet. Some possible choices include:
それはエージェントがイベントの1つ以上の動詞のタイプでパケットを特定するのに選ぶ動詞のタイプがそのパケットに出席している実装特有の問題です。 いくつかの可能な選択は:
- the first verb type encountered in the packet
- パケットで遭遇する最初の動詞のタイプ
- the verb type with the most instances in the packet
- 最も多くのインスタンスがパケットにある動詞のタイプ
- the verb type using the largest number of octets in the packet
- パケットの八重奏の最多数を使用している動詞のタイプ
- the most 'interesting' verb type in the packet (based on
knowledge of that application protocol).
- パケット(そのアプリケーション・プロトコルに関する知識に基づいている)で最も'おもしろい'動詞のタイプ。
5. Intellectual Property
5. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
Bierman, et. al. Standards Track [Page 12] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[12ページ]RFC3395RMONは識別子2002年9月に動詞化します。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
6. Acknowledgements
6. 承認
This memo is a product of the RMONMIB WG.
このメモはRMONMIB WGの製品です。
7. Normative References
7. 引用規格
[RFC1905] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.
and S. Waldbusser, "Protocol Operations for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC 1905,
January 1996.
[RFC1905]SNMPv2作業部会、ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[RFC1906] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.
and S. Waldbusser, "Transport Mappings for Version 2 of
the Simple Network Management Protocol (SNMPv2)", RFC 1906,
January 1996.
[RFC1906]SNMPv2作業部会、ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)",
RFC 2021, January 1997.
S.、「リモートネットワーク監視MIB(RMON-2)」、RFC2021 1997年1月の[RFC2021]Waldbusser。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[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月。
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
for Describing SNMP Management Frameworks", RFC 2571, April
1999.
[RFC2571] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、1999年4月。
[RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", RFC 2572, April 1999.
[RFC2572] ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications",
RFC 2573, April 1999.
[RFC2573] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2573、1999年4月。
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC2574]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年4月。
Bierman, et. al. Standards Track [Page 13] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[13ページ]RFC3395RMONは識別子2002年9月に動詞化します。
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2575] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年4月。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2895] Bierman, A., Bucci, C. and R. Iddon, "Remote Network
Monitoring MIB Protocol Identifiers", RFC 2895, August
2000.
[RFC2895] BiermanとA.とブッチとC.とR.Iddon、「リモートネットワーク監視MIBプロトコル識別子」、RFC2895、2000年8月。
8. Informative References
8. 有益な参照
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets", STD
16, RFC 1155, May 1990.
M.とK.McCloghrie、[RFC1155]は上昇して、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1157] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD
16, RFC 1212, March 1991.
[RFC1212] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、1991年3月のM.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[RFC1901] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.
and S. Waldbusser, "Introduction to Community-based
SNMPv2", RFC 1901, January 1996.
[RFC1901] SNMPv2作業部会とケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction to Version 3 of the Internet-standard Network
Management Framework", RFC 2570, April 1999.
[RFC2570]ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメントフレームワークのバージョン3への序論」RFC2570(1999年4月)。
Bierman, et. al. Standards Track [Page 14] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[14ページ]RFC3395RMONは識別子2002年9月に動詞化します。
9. IANA Considerations
9. IANA問題
At this time there are no application protocol verbs defined that require IANA registration, similar to the 'ianaAssigned' protocol identifiers found in RFC 2895. It is remotely possible that a future version of this document will contain application verb definitions which require assignment in the 'ianaAssigned' protocol identifier subtree.
このとき、IANA登録を必要とする定義されたアプリケーション・プロトコル動詞が全くありません、RFC2895で見つけられた'ianaAssigned'プロトコル識別子と同様です。 このドキュメントの将来のバージョンが'ianaAssigned'プロトコル識別子下位木における課題を必要とするアプリケーション動詞の定義を含むのは、離れて可能です。
10. Security Considerations
10. セキュリティ問題
This memo defines the structure of a portion of the Remote Monitoring MIB framework, but does not define any MIB objects or protocol operations. Instead, it defines algorithms for representing application protocol verbs in RMON Protocol Identifiers. It does not introduce any new security risks into a managed system.
このメモは、Remote Monitoring MIBフレームワークの部分の構造を定義しますが、少しのMIBオブジェクトやプロトコル操作も定義しません。 代わりに、それはRMONプロトコルIdentifiersのアプリケーション・プロトコル動詞を表すためのアルゴリズムを定義します。 それはどんな新しいセキュリティ危険も管理されたシステムに取り入れません。
However, if an MIB collection is designed which utilizes this type of Protocol Identifier, then such a collection may expose which verbs in an application protocol are used in a network. Inclusion of this additional information may require more consideration for protection. MIB writers should address such considerations.
しかしながら、プロトコルIdentifierのこのタイプを利用するMIB収集が設計されるなら、収集が暴露するかもしれないアプリケーション・プロトコルで動詞化するそのようなものはネットワークに使用されます。 この追加情報の包含は保護のための、より多くの考慮を必要とするかもしれません。 MIB作家はそのような問題を扱うべきです。
Bierman, et. al. Standards Track [Page 15] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[15ページ]RFC3395RMONは識別子2002年9月に動詞化します。
Appendix A: Usage Examples
付録A: 使用例
The following examples are listed to demonstrate how RMON verb identifiers are declared.
以下の例は、RMON動詞の識別子がどう宣言されるかを示すためにリストアップされています。
A.1 FTP Example
A.1FTPの例
This example defines verb enumeration values for the File Transfer Protocol as defined in RFC 959 and updated by RFC 2228 and RFC 2640. Note that verb name strings specified in the <verbName> field are not limited to 4 characters in length. In the FTP protocol, all the command names are 4 characters in length and the verb name string should match the official command name as closely as possible.
この例はRFC959で定義されて、RFC2228とRFC2640によってアップデートされるFile Transferプロトコルのために動詞の列挙値を定義します。 <verbName>分野で指定された動詞の名前ストリングが長さが4つのキャラクタに制限されないことに注意してください。 FTPプロトコルでは、すべてのコマンド名が長さが4つのキャラクタです、そして、ストリングという動詞の名はできるだけ密接に公式のコマンド名に合うべきです。
ftp VERB-IDENTIFIER
DESCRIPTION
"The set of verbs for FTP is derived from the list
of commands defined for the File Transfer Protocol,
which are identified by case-insensitive strings.
The commands are simply listed in the order found
in the FTP documentation."
REFERENCE
"File Transfer Protocol, RFC 959, Section 4.1;
FTP Security Extensions, RFC 2228, Section 3;
Internationalization of the File Transfer Protocol,
RFC 2640, Section 4.1."
::= {
user(1), -- USER NAME
pass(2), -- PASSWORD
acct(3), -- ACCOUNT
cwd(4), -- CHANGE WORKING DIRECTORY
cdup(5), -- CHANGE TO PARENT DIRECTORY
smnt(6), -- STRUCTURE MOUNT
rein(7), -- REINITIALIZE
quit(8), -- LOGOUT
port(9), -- DATA PORT
pasv(10), -- PASSIVE
type(11), -- REPRESENTATION TYPE
stru(12), -- FILE STRUCTURE
mode(13), -- TRANSFER MODE
retr(14), -- RETRIEVE
stor(15), -- STORE
stou(16), -- STORE UNIQUE
appe(17), -- APPEND (with create)
allo(18), -- ALLOCATE
rest(19), -- RESTART
rnfr(20), -- RENAME FROM
rnto(21), -- RENAME TO
ftp VERB-IDENTIFIER記述、「大文字と小文字を区別しないストリングによって特定されるFile Transferプロトコルのために定義されたコマンドのリストからFTPのための動詞のセットを得ます」。 「コマンドはFTPドキュメンテーションで見つけられたオーダーに単に記載されています。」 「ファイル転送プロトコル、RFC959、セクション4.1」という参照。 FTPセキュリティ拡大、RFC2228、セクション3。 「ファイル転送プロトコル、RFC2640、セクション4.1の国際化。」 ::= ユーザ(1)--USER NAMEパス(2)--PASSWORD acct(3)--ACCOUNT cwd(4)--CHANGE WORKING DIRECTORY cdup(5)--CHANGE TO PARENT DIRECTORY smnt(6)--STRUCTURE MOUNTたづな(7)--REINITIALIZEは(8)、--LOGOUTポート(9)--DATA PORT pasv(10)をやめます; PASSIVEは(11)--REPRESENTATION TYPE stru(12)--FILE STRUCTUREモード(13)--TRANSFER MODE retr(14)--RETRIEVE stor(15)--ストアstou(16)--ストアUNIQUE appe(17)をタイプします--、APPEND、(作成、)、異(18)--ALLOCATE休息(19)--RESTART rnfr(20)--RENAME FROM rnto(21)--RENAME TO
Bierman, et. al. Standards Track [Page 16] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[16ページ]RFC3395RMONは識別子2002年9月に動詞化します。
abor(22), -- ABORT
dele(23), -- DELETE
rmd(24), -- REMOVE DIRECTORY
mkd(25), -- MAKE DIRECTORY
pwd(26), -- PRINT WORKING DIRECTORY
list(27), -- LIST
nlst(28), -- NAME LIST
site(29), -- SITE PARAMETERS
syst(30), -- SYSTEM
stat(31), -- STATUS
help(32), -- HELP
noop(33), -- NOOP
auth(34), -- AUTHENTICATION/SECURITY MECHANISM
adat(35), -- AUTHENTICATION/SECURITY DATA
pbsz(36), -- PROTECTION BUFFER SIZE
prot(37), -- DATA CHANNEL PROTECTION LEVEL
ccc(38), -- CLEAR COMMAND CHANNEL
mic(39), -- INTEGRITY PROTECTED COMMAND
conf(40), -- CONFIDENTIALITY PROTECTED COMMAND
enc(41), -- PRIVACY PROTECTED COMMAND
lang(42) -- LANGUAGE
}
abor(22)--ABORT dele(23)--DELETE rmd(24)--削除、ディレクトリmkd(25)--MAKE DIRECTORY pwd(26)--PRINT WORKING DIRECTORYは(27)--LIST nlst(28)--NAME LISTサイト(29)、--SITE PARAMETERS syst(30)--SYSTEMスタット(31)を記載します; STATUSは(32)を助けます--noop(33)--NOOP auth(34)--AUTHENTICATION/SECURITY MECHANISM adat(35)--AUTHENTICATION/SECURITY DATA pbsz(36)--PROTECTION BUFFER SIZE prot(37)--DATA CHANNEL PROTECTION LEVEL ccc(38)--CLEAR COMMAND CHANNEL mic(39)--INTEGRITY PROTECTED COMMAND conf(40)--CONFIDENTIALITY PROTECTED COMMAND enc(41)--PRIVACY PROTECTED COMMAND lang(42)--ヘルプ、LANGUAGE
A.2 POP3 Example
A.2 POP3の例
This example defines verb enumeration values for the Post Office Protocol, Version 3, as defined in RFC 1939 and updated by RFC 2449.
この例はポストオフィスプロトコルのために動詞の列挙値を定義します、バージョン3、RFC1939で定義されて、RFC2449によってアップデートされるように。
pop3 VERB-IDENTIFIER
DESCRIPTION
"The set of verbs for POP3 is derived from the list
of commands defined for the Post Office Protocol,
which are identified by case-insensitive strings.
The commands are simply listed in the order found
in the POP3 command summary."
REFERENCE
"Post Office Protocol, Version 3, RFC 1939, Section 9;
POP3 Extension Mechanism, RFC 2449, Section 5."
::= {
user(1),
pass(2),
quit(3),
stat(4),
list(5),
retr(6),
dele(7),
noop(8),
rset(9),
pop3 VERB-IDENTIFIER記述、「大文字と小文字を区別しないストリングによって特定されるポストオフィスプロトコルのために定義されたコマンドのリストからPOP3のための動詞のセットを得ます」。 「コマンドはPOP3コマンド概要で見つけられたオーダーに単に記載されています。」 「POP、バージョン3、RFC1939、セクション9」という参照。 「POP3拡張機能、RFC2449、セクション5。」 ::= (5)、retr(6)、dele(7)、noop(8)、rset(9)は、ユーザ(1)(パス(2))が(3)、スタット(4)をやめたと記載します。
Bierman, et. al. Standards Track [Page 17] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[17ページ]RFC3395RMONは識別子2002年9月に動詞化します。
apop(10),
top(11),
uidl(12),
capa(13)
}
apop(10)、先端(11)、uidl(12)、高級キューバタバコ(13)
A.3 SNMP Example
A.3 SNMPの例
This example defines verb enumeration values for the Simple Network Management Protocol, as defined in RFC 1905.
この例はSimple Network ManagementプロトコルのためにRFC1905で定義されるように動詞の列挙値を定義します。
snmp VERB-IDENTIFIER
DESCRIPTION
"The set of verbs for SNMP is derived from the list
of PDU transaction types in the Protocol Operations
document for SNMPv2. Note that the 'Response'
and 'Report' PDUs are not considered verbs, but are
classified as belonging to the transaction type
associated with the request PDU."
REFERENCE
"Protocol Operations for Version 2 of the
Simple Network Management Protocol (SNMPv2),
RFC 1905, Section 3."
::= {
get(1),
get-next(2),
get-bulk(3),
set(4),
inform-request(5),
trap(6)
}
snmp VERB-IDENTIFIER記述、「SNMPv2のためのプロトコルOperationsドキュメントのPDUトランザクションタイプのリストからSNMPのための動詞のセットを得ます」。 「'応答'と'レポート'PDUsが動詞であることは考えられませんが、要求PDUに関連づけられたトランザクションタイプに属すとして分類されることに注意してください。」 「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2、RFC1905、セクション3のためのプロトコル操作」という参照。 ::= (1)、次の(2)を得ていて、大量(3)、セット(4)を得ていて、要求(5)を知らせている罠(6)を手に入れてください。
A.4 HTTP Example
A.4HTTPの例
This example defines verb enumeration values for the Hypertext Transfer Protocol, version 1.1, as defined in RFC 2616.
この例はRFC2616で定義されるようにハイパーテキストTransferプロトコルのための動詞の列挙値、バージョン1.1を定義します。
http VERB-IDENTIFIER
DESCRIPTION
"The set of verbs for HTTP is derived from the list
of methods defined for the Hypertext Transfer Protocol,
which are identified by case-sensitive strings.
The commands are simply listed in the order found
in the HTTP/1.1 documentation. Methods commonly used
in HTTP/1.0 are a proper subset of those used in HTTP/1.1.
Both versions of the protocol are in current use."
REFERENCE
"Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616,
http VERB-IDENTIFIER記述、「大文字と小文字を区別するストリングによって特定されるハイパーテキストTransferプロトコルのために定義されたメソッドのリストからHTTPのための動詞のセットを得ます」。 コマンドはHTTP/1.1ドキュメンテーションで見つけられたオーダーに単に記載されています。 HTTP/1.0に一般的に使用されるメソッドはHTTP/1.1に使用されるものの真部分集合です。 「プロトコルの両方のバージョンは現在、使用中です。」 「HTTP/1.1、RFCハイパーテキスト転送プロトコル--2616」という参照
Bierman, et. al. Standards Track [Page 18] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[18ページ]RFC3395RMONは識別子2002年9月に動詞化します。
Section 9; Hypertext Transfer Protocol -- HTTP/1.0, RFC
1945, Section 8."
::= {
options(1),
get(2),
head(3),
post(4),
put(5),
delete(6),
trace(7),
connect(8) -- reserved for future use by HTTP/1.1
}
セクション9。 「ハイパーテキストはプロトコルを移します--HTTP/1.0、RFC1945、セクション8。」 ::= HTTP/1.1(1)をゆだねて、(2)、ヘッド(3)、ポスト(4)、かかっている(5)を得て、(6)、跡の(7)を削除して、(8)--今後の使用のために予約されるのを接続します。
A.5 SMTP Example
A.5 SMTPの例
This example defines verb enumeration values for the Simple Mail Transfer Protocol as defined in RFC 2821.
この例はRFC2821で定義されるシンプルメールトランスファプロトコルのために動詞の列挙値を定義します。
smtp VERB-IDENTIFIER
DESCRIPTION
"The set of verbs for SMTP is derived from the set of commands
defined for the protocol. These commands are identified
by case-insensitive strings. Commands are listed in the
order found in RFC 2821. The special "xcmd" verb is defined
here as a catch-all for private-use commands, which must
start with the letter 'X'."
REFERENCE
"Simple Mail Transfer Protocol -- RFC 2821, sections 4.1.1
and 4.1.5."
::= {
ehlo(1), -- Extended HELLO (4.1.1.1)
helo(2), -- HELLO (4.1.1.1)
mail(3), -- MAIL (4.1.1.2)
rcpt(4), -- RECIPIENT (4.1.1.3)
data(5), -- DATA (4.1.1.4)
rset(6), -- RESET (4.1.1.5)
vrfy(7), -- VERIFY (4.1.1.6)
expn(8), -- EXPAND (4.1.1.7)
help(9), -- HELP (4.1.1.8)
noop(10), -- NOOP (4.1.1.9)
quit(11), -- QUIT (4.1.1.10)
xcmd(12) -- Catch-all for private-use "X" commands (4.1.5)
}
smtp VERB-IDENTIFIER記述、「プロトコルのために定義されたコマンドのセットからSMTPのための動詞のセットを得ます」。 これらのコマンドは大文字と小文字を区別しないストリングによって特定されます。 コマンドはRFC2821で見つけられたオーダーに記載されています。 「特別な"xcmd"動詞はここで文字'X'から始まらなければならない私用コマンドのためのキャッチとすべて、定義されます。」 REFERENCE、「セクション4.1 RFCシンプルメールトランスファプロトコル--2821、.1と4.1、.5インチ。 ::= { ehlo(1), -- Extended HELLO (4.1.1.1) helo(2), -- HELLO (4.1.1.1) mail(3), -- MAIL (4.1.1.2) rcpt(4), -- RECIPIENT (4.1.1.3) data(5), -- DATA (4.1.1.4) rset(6), -- RESET (4.1.1.5) vrfy(7), -- VERIFY (4.1.1.6) expn(8), -- EXPAND (4.1.1.7) help(9), -- HELP (4.1.1.8) noop(10), -- NOOP (4.1.1.9) quit(11), -- QUIT (4.1.1.10) xcmd(12) -- Catch-all for private-use "X" commands (4.1.5) }
Bierman, et. al. Standards Track [Page 19] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[19ページ]RFC3395RMONは識別子2002年9月に動詞化します。
Authors' Addresses
作者のアドレス
Andy Bierman Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA USA 95134
カリフォルニア米国 アンディBiermanシスコシステムズInc.170の西タスマン博士サンノゼ、95134
Phone: +1 408-527-3711 EMail: abierman@cisco.com
以下に電話をしてください。 +1 408-527-3711 メールしてください: abierman@cisco.com
Chris Bucci Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA USA 95134
カリフォルニア米国 クリスブッチシスコシステムズInc.170の西タスマン博士サンノゼ、95134
Phone: +1 408-527-5337 EMail: cbucci@cisco.com
以下に電話をしてください。 +1 408-527-5337 メールしてください: cbucci@cisco.com
Russell Dietz Hifn, Inc. 750 University Ave Los Gatos, CA, USA 95032-7695
ラッセルディーツHifn Inc.750大学Aveロスガトス(カリフォルニア)、米国95032-7695
Phone: +1 408-399-3623 EMail: rdietz@hifn.com
以下に電話をしてください。 +1 408-399-3623 メールしてください: rdietz@hifn.com
Albin Warth
Albin Warth
EMail: dahoss@earthlink.net
メール: dahoss@earthlink.net
Bierman, et. al. Standards Track [Page 20] RFC 3395 RMON Verb Identifiers September 2002
et Bierman、アル。 標準化過程[20ページ]RFC3395RMONは識別子2002年9月に動詞化します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bierman, et. al. Standards Track [Page 21]
et Bierman、アル。 標準化過程[21ページ]
一覧
スポンサーリンク
