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
Remote Network Monitoring MIB Protocol Identifier Reference Extensions
リモートネットワーク監視MIBプロトコル識別子参照拡張
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
このメモは、アプリケーション動詞情報を識別するためのプロトコル識別子参照文書への拡張を定義します。これは、プロトコル識別子リファレンスドキュメントを更新しますが、その文書のいかなる部分時代遅れはしません。特に、このようなリモートネットワーク監視MIBバージョン2、RFC 2021としてのMIBで管理プロトコルカプセル化プロトコルの中に操作（動詞）を識別するために必要なアルゴリズムを記載しています。
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
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
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5つの主要コンポーネントから構成されています。
o An overall architecture, described in RFC 2571 [RFC2571].
Oの全体的なアーキテクチャは、RFC 2571 [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。管理情報（SMI）のこの構造体の最初のバージョンはでSMIv1と呼ばれ、STD 16、RFC 1155 [RFC1155]、STD 16、RFC 1212 [RFC1212]に記載されています
RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580].
RFC 1215 [RFC1215]。 SMIv2のと呼ばれる第二のバージョンは、STD 58、RFC 2578 [RFC2578]、RFC 2579 [RFC2579]及びRFC 2580 [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と呼ばれ、STD 15、RFC 1157 [RFC1157]に記載されています。インターネット標準トラックプロトコルでないSNMPメッセージプロトコルの第2のバージョンは、SNMPv2cのと呼ばれ、RFC 1901 [RFC1901]及びRFC 1906 [RFC1906]に記載されています。メッセージプロトコルのバージョン3は、RFC 2572 [RFC2572]及びRFC 2574 [RFC2574]、[RFC1906]のSNMPv3と呼ばれ、RFC 1906年に記載されています。
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形式の第一セットは、STD 15、RFC 1157 [RFC1157]に記載されています。プロトコル操作と関連PDU形式の第2のセットは、RFC 1905 [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基本的なアプリケーションのセットは、RFC 2573 [RFC2573]に記載されています。ビューベースアクセス制御メカニズムは、RFC 2575 [RFC2575]に記載されています。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].
現在のSNMP Management Frameworkへの、より詳細な紹介は、RFC 2570 [RFC2570]で見つけることができます。
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.
管理対象オブジェクトが仮想情報店を介してアクセスされ、管理情報ベースまたはMIBと呼ばれます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用して定義されています。
This memo does not specify a MIB module.
このメモはMIBモジュールを指定していません。
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]の拡張機能を定義し、更新することが意図され、廃止されていない、既存のプロトコル識別子エンコーディング規則。
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 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).
RMONプロトコル識別子（PI）構造[RFC2895]はレイヤ識別子の可変数を可能にします。各レイヤはプロトコルディレクトリオクテット文字列とprotocolDirParametersオクテットストリングに1つのオクテット4〜オクテット寄与する。これら二つのMIBオブジェクトがprotocolDirTable [RFC2021]のインデックスを含み、特定のプロトコルカプセル化のためのグローバル一意識別子を表す（またはワイルドカードベース層を使用する場合のカプセル化の設定します）。
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つのオクテットを超えることができ、文字列として定義されているので、整数マッピングは各弦のために提供されなければなりません。このメモは動詞の層が構造化される方法を指定するだけでなく、整数へのマッピング動詞名の指定のための動詞識別子マクロ構文。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This document uses some terms defined in the RMON Protocol Identifier Reference document [RFC2895] and some new terms that need introduction here.
この文書では、RMONプロトコル識別子リファレンスドキュメント[RFC2895]、ここで紹介する必要があるいくつかの新しい用語で定義されたいくつかの用語を使用しています。
Application Verb Also called simply 'verb'. Refers to one of potentially many protocol operations that are defined by a particular application protocol.
アプリケーション動詞はまた、「動詞」単にと呼ばれます。特定のアプリケーションプロトコルによって定義され、潜在的に多くのプロトコル操作のいずれかを指します。
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を含むパケット内のアプリケーションプロトコルサブコマンドまたはオペコードと等価ではないことに留意されたいです。アプリケーション動詞は、トランザクション型であり、アプリケーションプロトコル（例えば、SNMPのGet-PDUと応答-PDU）内のいくつかのPDUタイプを含むことができます。いくつかの用途では、動詞は、プロトコルディレクトリ（例えば、FTPやFTPデータ）における複数のプロトコル・エントリに関連するプロトコル動作を包含し得ます。
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.
動詞接続またはセッションのセットアップとティアダウンのトラフィックに関連した特別なアプリケーション動詞接続、およびアプリケーションのための任意の他の動詞に起因しません。この動詞は、暗黙的にすべてのアプリケーションプロトコルのために定義されているゼロの列挙値を割り当て、そして動詞は「（0）接続」されています。
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.
親アプリケーション特定のアプリケーションプロトコルを識別し、潜在的に多くのプロトコルカプセル化の一つ。この用語は、アプリケーション動詞の所与のセットのための任意のまたは全てのそのようなカプセル化に一般的に指します。
Verb Layer The portion of the protocol identifier octet string which identifies the application verb.
動詞は、アプリケーション動詞を識別するプロトコル識別子オクテットストリングの部分レイヤ。
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.
動詞は、特定のアプリケーションプロトコルの列挙動詞のグループを設定します。特定の動詞識別子マクロ呼び出し内の動詞の文字列のリストは、その動詞の識別子に設定動詞と呼ばれています。
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を利用及び/又はそれが表すプロトコル識別子マクロは、この文書に含まれるアプリケーション動詞マクロ定義を利用することができる他の仕様。
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プロトコル識別子リファレンス[RFC2895]はRMONプロトコル識別子マクロ仕様言語ならびにプロトコルディレクトリとprotocolDirParameters OCTET文字列の符号化規則を定義します。このメモは、アプリケーション動詞情報を識別するためのプロトコル識別子リファレンスへの拡張を定義します。これは、プロトコル識別子参照文書の任意の部分を時代遅れにしません。
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.
以下の例では、動詞識別子マクロを導入するためのものです。このマクロのような構築物は、特定の親アプリケーションのためのプロトコルの動詞を表すために使用されます。
The following keyword is added to the PI language:
以下のキーワードは、PI言語に追加されます。
VERB-IDENTIFIER
VERB-IDENTIFIER
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> ]...
-- a PI definition
<piVerbDefinition> =
[<wspace>] <parentProtoName> <wspace> "VERB-IDENTIFIER"
<wspace> "DESCRIPTION" <wspace> string
[ <wspace> "REFERENCE" <wspace> string ]
[<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
- ゼロ未満16,777,216より大きい正の整数<posNum> =任意の整数値
-- <piDefinition> syntax is defined in [RFC2895]
- <piDefinition>構文は[RFC2895]で定義されています
-- <protoName> syntax is defined in [RFC2895] -- <wspace> syntax is defined in [RFC2895] -- <lcname> syntax is defined in [RFC2895]
- <wspace>構文は[RFC2895]で定義されている - - <protoName>構文は[RFC2895]で定義される<lcname>構文は[RFC2895]で定義されています
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>.
「親プロトコル名」と呼ばれる「parentProtoName」値は、1〜64文字からなるASCII文字列であるべきです。プロトコル名フィールドのマッピングのために[RFC2895]のセクション6.2.4で指定されるように（UTF-8の使用が適切でないので、これらの名前は、IETFドキュメントに表示されるように意図されている。）符号化規則は、正確です。 [RFC2895]のセクション3.2.4に<protoName>に指定されたように（「親プロトコル名」と呼ばれる）<parentProtoName>の値は、定義されたプロトコル識別子の値でなければなりません。 <parentProtoName>の値<protoName> <piFile>で定義を指定しなければなりません。
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>に存在する場合、プロトコル識別子マクロは、親アプリケーションプロトコルの少なくとも一つのカプセル化<piFile>に存在する必要があります。
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.
記述節は、このマクロによって識別プロトコル動詞セットのテキスト記述を提供します。これは、REFERENCE句でカバー項目の詳細を含めることはできません。記述句は、すべての動詞識別子マクロ宣言で存在していなければなりません。
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.
公に利用可能な参照文書は、アプリケーションプロトコルの動詞のこのセットのために存在している場合、それはここに書かれています。通常、これは、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句は任意であるが、正式の参照は、このマクロの<verbList>セクションで定義されたアプリケーションプロトコルの動詞を指定する存在する場合に存在しなければなりません。
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).
動詞リスト句が存在しなければなりません。アプリケーションの動詞名のリストを識別し、各動詞の名前で数値定数を関連付けるために使用されます。少なくとも一つの動詞を指定する必要があり、最大（2 ^^ 24から1）16,777,215の動詞を指定することができます。この列挙リストは、密に（つまり、「N」がマクロで定義された動詞の総数である「N」に「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>フィールドでは大文字と小文字を区別し、各アプリケーションの動詞のための最も適切な文字列名に設定する必要があります。そのような記述文字列が権威文書に定義されている場合、その文字列を使用すべきです。そのような文字列が次に存在しない場合、適切なしかし、任意の文字列がこの値のために選択されるべきです。
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）接続」ことに留意されたいです。これは、プロトコルの存在、ならびに暗黙の動詞「（0）を接続」する（例えば、HTTPの「（8）接続」）この動詞の明示的な定義が可能です。
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>フィールドは、特定の親アプリケーションに関連付けられているすべての動詞に対して一意でなければなりません。このフィールドは、「1」と'16、777215' までの間の値を含むべきです。
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オブジェクトを実装しなければなりません。
The verb layer consists of the 4 octets within the protocolDirID INDEX field which identify a particular application verb.
動詞層は、特定のアプリケーション動詞を識別するプロトコルディレクトリインデックスフィールド内の4つのオクテットで構成されています。
Figure 1
Verb Layer Format
-----------------
protocolDirID string fragment
---+--------+--------+--------+--------+
| resrvd | |
.. | set to | verb enumeration value |
| zero | (a) (b) (c) |
---+--------+--------+--------+--------+ octet
| 1 | 3 | count
The first octet is reserved for future use and MUST be set to zero.
最初のオクテットは、将来の使用のために予約され、ゼロに設定されなければなりません。
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」部分）動詞識別子マクロ動詞のリストで再定義してはいけません。動詞名「接続」が予約されていないと動詞リストで再定義されるかもしれないことに注意してください。
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.
特定のアプリケーション動詞のプロトコルディレクトリのOCTET STRING値は動詞の層の識別子の値が付加親アプリケーションのプロトコルディレクトリ値によって表されます。
Figure 2
ProtocolDirID Format for Verbs
------------------------------
protocolDirID string
+--------+--------+--------+--------+
| parent | verb |
| protocolDirID | layer |
| string | value |
+--------+--------+--------+--------+ octet
| length of parent ID | 4 | count
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.
プロトコルディレクトリオブジェクトは、動詞の層を表す4つの追加のオクテットが続く親アプリケーションのプロトコルディレクトリ値として符号化されます。動詞層値は[0.abc]ここで、 '上位バイト、「B」は中位バイトであり、「C」は、特定のアプリケーションのための<verbEnum>フィールドの下位バイトであるとして符号化されます動詞値。有効PI動詞列挙は特別な値「0.0.0.0」が暗黙的に定義するために予約される「0.255.255.255」は、動詞「（0）を接続」する範囲「0.0.0.0」で符号化されます。
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値によって表されます。実際に使用されていないが、このフィールドは、プロトコル識別子リファレンス[RFC2895]で定義された符号化規則に準拠するために含まれています。
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値を割り当てる必要があります。
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>値を伝えなければなりません。このオブジェクトは、<verbName>フィールドに含まれている正確なテキストが続く「ドット」文字が付加親アプリケーションのprotocolDirDescr値として符号化されるべきです。
The agent MUST set the protocolDirType object for each application verb to the value representing the empty bit set ( {} ).
エージェントは、空のビットセット（{}）を表す値に各アプリケーション動詞用protocolDirTypeオブジェクトを設定しなければなりません。
The agent MUST set the protocolDirAddressMapConfig object for each application verb to the value 'notSupported(1)'.
エージェントは、「（1）です。notSupported」の値に各アプリケーション動詞用protocolDirAddressMapConfigオブジェクトを設定しなければなりません。
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オブジェクトに設定されエージェントが同じ値にこのオブジェクトを設定してもよいです。エージェントは、値がこのオブジェクトを移行するのを選ぶかもしれ「へsupportedOn（2）」「supportedOff（3）」親出願protocolDirHostConfig「はsupportedOff（3）」と「supportedOn（2）」から最初の遷移オブジェクト場合。
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オブジェクトに設定されエージェントが同じ値にこのオブジェクトを設定してもよいです。エージェントは、値がこのオブジェクトを移行するのを選ぶかもしれ「へsupportedOn（2）」「supportedOff（3）」親出願protocolDirMatrixConfig「はsupportedOff（3）」と「supportedOn（2）」から最初の遷移オブジェクト場合。
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].
この目的は、RMON-2 MIB [RFC2021]で指定された規則に従って、他のprotocolDirTableエントリのようなアプリケーション動詞用のまったく同じ符号化されます。
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].
この目的は、RMON-2 MIB [RFC2021]で指定された規則に従って、他のprotocolDirTableエントリのようなアプリケーション動詞用のまったく同じ符号化されます。
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コレクションをサポートするエージェントの実装への影響について説明します。
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の実装は、多くのプロトコルのために、正確に1つの動詞または別に「属する」としてパケットを分類するために、状態情報を維持する必要があります。以下の実施例は、この点を例示します。
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の場合、SNMPの応答-PDUは、PDUは、取得のGetnext-PDUの応答-PDUと区別することはできません。プローブは、AからBへの以前の要求とにBからの応答-PDUを相関させるために、状態情報を維持する必要があります
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、いくつかのパケットにまたがることができ、アプリケーションの動詞を識別するために必要な情報として、ストリームベースのトランスポートを介して搬送されるアプリケーションプロトコルのために。プローブが正しくアプリケーション層のデータを解析するために、トランスポート層の流れを追跡する必要があります。
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 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.
動詞層プロトコル・ディレクトリ・フィルタリングに基づくパケットキャプチャのために、キャプチャバッファ内のパケットを含むように決定は、パケットが決定的に特定の動詞に帰することができるまで延期される必要があるかもしれません。プローブが含まれたり、まだ到着していない他のパケットに基づいて、キャプチャから除外することを決定しながら、パケット・バッファを事前にする必要があります。
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.
そのようなプロトコル分布またはアプリケーション層ホストテーブル（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動詞の種類、したがって、プロトコルディレクトリエントリを選択する必要があります。
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:
これは、複数の動詞形は、そのパケット内に存在する場合にはパケットを識別するために選択する動詞は、エージェントを入力するように実装特有の問題です。いくつかの可能な選択肢は次のとおりです。
- 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).
- （そのアプリケーションプロトコルの知識に基づいて）パケットの中で最も「面白い」動詞タイプ。
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は、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
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専務に情報を扱ってください。
This memo is a product of the RMONMIB WG.
このメモはRMONMIB WGの製品です。
[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、 "簡易ネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、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ワーキンググループ、ケース、RFC 1906、1996年1月J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のためのマッピングを輸送します"。
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)", RFC 2021, January 1997.
[RFC2021] Waldbusser、S.、 "リモートネットワーク監視MIB（RMON-2）"、RFC 2021、1997年1月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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管理フレームワークを記述するためのアーキテクチャ"、RFC 2571、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）のための派遣"、RFC 2572、1999年4月。
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
[RFC2573]レビ、D.、マイヤー、P.とB.スチュワート、 "SNMPv3のアプリケーション"、RFC 2573、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.
、RFC 2574、1999年4月 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）" [RFC2574]ブルーメンソール、U.とB. Wijnenの、。
[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）"、RFC 2575、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）の構造"、STD 58、RFC 2578、 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のためのテキストの表記法"、STD 58、RFC 2579、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のための適合性宣言"、STD 58、RFC 2580、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プロトコル識別子"、RFC 2895、2000年8月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[RFC1155]ローズ、M.、およびK. McCloghrie、 "構造とTCP / IPベースのインターネットのための経営情報の識別"、STD 16、RFC 1155、1990年5月。
[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.デーヴィン、 "簡単なネットワーク管理プロトコル"、STD 15、RFC 1157、1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[RFC1212]ローズ、M.、およびK. McCloghrie、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。
[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の概要"、RFC 1901、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への序論"、RFC 2570、1999年4月。
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.
この時点では、このドキュメントの将来のバージョンでは、 "で割り当てを要求するアプリケーションの動詞の定義が含まれていることをリモートで可能であるRFC 2895.で見つかった「ianaAssigned」プロトコル識別子に似たIANA登録を必要と定義されたアプリケーションプロトコルの動詞はありませんianaAssigned」プロトコル識別子サブツリー。
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.
このメモは、リモートモニタリングMIBフレームワークの部分の構造を定義するが、任意のMIBオブジェクトまたはプロトコル操作を定義していません。代わりに、RMONプロトコル識別子でアプリケーションプロトコル動詞を表すためのアルゴリズムを定義します。これは、管理対象システムに新たなセキュリティリスクを導入しません。
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.
MIBコレクションはプロトコル識別子のこのタイプを利用するように設計されている場合は、そのようなコレクションは、アプリケーションプロトコルで動詞がネットワークで使用されて露出させることができます。この追加情報を含めることで、保護のためのより多くの配慮が必要な場合があります。 MIBの作家は、このような考慮事項に対処すべきです。
Appendix A: Usage Examples
付録A：使用例
The following examples are listed to demonstrate how RMON verb identifiers are declared.
次の例は、RMON動詞識別子が宣言されている方法を示すために記載されています。
A.1 FTP Example
A.1 FTP例
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.
RFC 959で定義され、RFC 2228およびRFCによって<verbName>フィールドで指定された動詞名の文字列の長さは4つの文字に制限されていない2640注意を更新し、この例では、ファイル転送プロトコルのための動詞列挙値を定義します。 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 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
}
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.
RFC 1939で定義され、RFC 2449で更新され、この例では、ポストオフィスプロトコル、バージョン3のための動詞列挙値を定義します。
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), apop(10),
top(11),
uidl(12),
capa(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.
RFC 1905で定義されているこの例では、簡易ネットワーク管理プロトコルのための動詞列挙値を定義します。
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)
}
A.4 HTTP Example
A.4 HTTP例
This example defines verb enumeration values for the Hypertext Transfer Protocol, version 1.1, as defined in RFC 2616.
RFC 2616で定義されるように、この例では、ハイパーテキスト転送プロトコル、バージョン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動詞識別子DESCRIPTION「HTTPの動詞のセットは、大文字と小文字を区別した文字列によって識別されたハイパーテキスト転送プロトコル、のために定義されたメソッドのリストに由来する。コマンドは、単にHTTP / 1.1マニュアルに見出すために記載されています一般にHTTP / 1.0で使用される。方法は、HTTP / 1.1で使用されるものの適切なサブセットである。プロトコルの両方のバージョンは、現在使用されています「。 REFERENCE「ハイパーテキスト転送プロトコル - HTTP / 1.1、RFC 2616、
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
}
A.5 SMTP Example
A.5 SMTP例
This example defines verb enumeration values for the Simple Mail Transfer Protocol as defined in RFC 2821.
RFC 2821で定義されるように、この例では、簡易メール転送プロトコルの動詞列挙値を定義します。
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)
}
Authors' Addresses
著者のアドレス
Andy Bierman Cisco Systems, Inc. 170 West Tasman Dr San Jose, CA USA 95134
アンディBiermanシスコシステムズ、株式会社170西タスマン博士サンノゼ、CA USA 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
クリス・ブッチシスコシステムズ、株式会社170西タスマン博士サンノゼ、CA USA 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大学アベニューロスガトス、CA、USA 95032から7695
Phone: +1 408-399-3623 EMail: rdietz@hifn.com
電話：+1 408-399-3623電子メール：rdietz@hifn.com
Albin Warth
アルビンヴァース
EMail: dahoss@earthlink.net
メールアドレス：dahoss@earthlink.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。