Network Working Group A. Bierman
Request for Comments: 2895 C. Bucci
Obsoletes: 2074 Cisco Systems, Inc.
Category: Standards Track R. Iddon
3Com, Inc.
August 2000
Remote Network Monitoring MIB Protocol Identifier Reference
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This memo defines a notation describing protocol layers in a protocol encapsulation, specifically for use in encoding INDEX values for the protocolDirTable, found in the RMON-2 MIB (Remote Network Monitoring Management Information Base) [RFC2021]. The definitions for the standard protocol directory base layer identifiers are also included.
このメモは、（管理情報ベース監視リモートネットワーク）[RFC2021]具体RMON-2 MIBに見出さprotocolDirTable、のインデックス値を符号化する際に使用するために、プロトコルカプセル化のプロトコル層を説明表記法を定義します。標準プロトコルディレクトリベースレイヤ識別子の定義も含まれます。
The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion (this document), and an Informational document. The RMON Protocol Identifier Macros document [RFC2896] now contains the non-normative portion of that specification.
RMONプロトコル識別子文献[RFC2074]の最初のバージョンは、標準トラックリファレンス部（本書）、そして情報の文書に分割されています。 RMONプロトコル識別子マクロドキュメント[RFC2896]は、今、その仕様の非規範的部分を含みます。
This document obsoletes RFC 2074.
この文書はRFC 2074を廃止します。
Table of Contents
目次
1 The SNMP Network Management Framework .......................... 3
2 Overview ....................................................... 3
2.1 Terms ........................................................ 4
2.2 Relationship to the Remote Network Monitoring MIB ............ 6
2.3 Relationship to the RMON Protocol Identifier Macros Document . 6
2.4 Relationship to the ATM-RMON MIB ............................. 7
2.4.1 Port Aggregation ........................................... 7
2.4.2 Encapsulation Mappings ..................................... 7
2.4.3 Counting ATM Traffic in RMON-2 Collections ................. 8
2.5 Relationship to Other MIBs ................................... 9
3 Protocol Identifier Encoding ................................... 9
3.1 ProtocolDirTable INDEX Format Examples ....................... 11
3.2 Protocol Identifier Macro Format ............................. 12
3.2.1 Lexical Conventions ........................................ 12
3.2.2 Notation for Syntax Descriptions ........................... 13
3.2.3 Grammar for the PI Language ................................ 13
3.2.4 Mapping of the Protocol Name ............................... 15
3.2.5 Mapping of the VARIANT-OF Clause ........................... 16
3.2.6 Mapping of the PARAMETERS Clause ........................... 17
3.2.6.1 Mapping of the 'countsFragments(0)' BIT .................. 18
3.2.6.2 Mapping of the 'tracksSessions(1)' BIT ................... 18
3.2.7 Mapping of the ATTRIBUTES Clause ........................... 18
3.2.8 Mapping of the DESCRIPTION Clause .......................... 19
3.2.9 Mapping of the CHILDREN Clause ............................. 19
3.2.10 Mapping of the ADDRESS-FORMAT Clause ...................... 20
3.2.11 Mapping of the DECODING Clause ............................ 20
3.2.12 Mapping of the REFERENCE Clause ........................... 20
3.3 Evaluating an Index of the ProtocolDirTable .................. 21
4 Base Layer Protocol Identifier Macros .......................... 22
4.1 Base Identifier Encoding ..................................... 22
4.1.1 Protocol Identifier Functions .............................. 22
4.1.1.1 Function 0: None ......................................... 23
4.1.1.2 Function 1: Protocol Wildcard Function ................... 23
4.2 Base Layer Protocol Identifiers .............................. 24
4.3 Encapsulation Layers ......................................... 31
4.3.1 IEEE 802.1Q ................................................ 31
5 Intellectual Property .......................................... 34
6 Acknowledgements ............................................... 35
7 References ..................................................... 35
8 IANA Considerations ............................................ 39
9 Security Considerations ........................................ 39
10 Authors' Addresses ............................................ 40
Appendix A ....................................................... 41
11 Full Copyright Statement ...................................... 42
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 described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理の目的のためにオブジェクトとイベントを記述し、命名するためのメカニズムO。管理情報（SMI）のこの構造体の最初のバージョンはでSMIv1と呼ばれ、STD 16、RFC 1155 [RFC1155]、STD 16、RFC 1212 [RFC1212]及びRFC 1215 [RFC1215]に記載されています。 SMIv2のと呼ばれる第二のバージョンは、STD 58、RFC 2578 [RFC2578]、STD 58、RFC 2579 [RFC2579]とSTD 58、RFC 2580 [RFC2580]に記載されています。
o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and 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 described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and 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 described in RFC 2573 [RFC2573] and the view-based access control mechanism 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モジュールを指定していません。
The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs to globally identify individual protocol encapsulations in the protocolDirTable.
RMON-2 MIB [RFC2021]はprotocolDirTableにおける個々のプロトコルカプセル化を識別するグローバルに階層的にフォーマットされたOCTET文字列を使用します。
This guide contains algorithms and the authoritative set of base layer protocol identifier macros, for use within INDEX values in the protocolDirTable.
このガイドは、protocolDirTableにおけるインデックス値内で使用するアルゴリズムとベース層プロトコル識別子マクロの権限のセットを含んでいます。
This is the second revision of this document, and is intended to replace the first half of the first RMON-2 Protocol Identifiers document. [RFC2074].
これは、この文書の第二の改正であり、第1 RMON-2プロトコル識別子の文書の最初の半分を置き換えることを目的としています。 [RFC2074]。
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]に記載されているように解釈されます。
Several terms are used throughout this document, as well as in the RMON-2 MIB [RFC2021], that should be introduced:
いくつかの用語は、同様に導入されるべきであるRMON-2 MIB [RFC2021]でこの文書全体を通して使用されます：
parent protocol: Also called 'parent'; The encapsulating protocol identifier for a specific protocol layer, e.g., IP is the parent protocol of UDP. Note that base layers cannot have parent protocols. This term may be used to refer to a specific encapsulating protocol, or it may be used generically to refer to any encapsulating protocol.
親プロトコル：また、「親」と呼ばれます。特定のプロトコル層のためのカプセル化プロトコル識別子は、例えば、IPは、UDPの親プロトコルです。ベース層は、親プロトコルを持つことができないことに注意してください。この用語は、特定のカプセル化プロトコルを指すために使用することができる、または任意のカプセル化プロトコルを指すために一般的に使用されてもよいです。
child protocol: Also called 'child'; An encapsulated protocol identifier for a specific protocol layer. e.g., UDP is a child protocol of IP. This term may be used to refer to a specific encapsulated protocol, or it may be used generically to refer to any encapsulated protocol.
子プロトコル：また、「子」と呼ばれます。特定のプロトコル層のためのカプセル化プロトコル識別子。例えば、UDPはIPの子プロトコルです。この用語は、特定のカプセル化されたプロトコルを参照するために使用することができる、または任意のカプセル化されたプロトコルを指すために一般的に使用されてもよいです。
layer-identifier: An octet string fragment representing a particular protocol encapsulation layer or sub-layer. A fragment consists of exactly four octets, encoded in network byte order. If present, child layer-identifiers for a protocol MUST have unique values among each other. (See section 3.3 for more details.)
レイヤ識別子：特定のプロトコルカプセル化層またはサブ層を表すオクテット文字列フラグメント。フラグメントは、ネットワークバイト順で符号化され、正確に4つのオクテットで構成されています。存在する場合、プロトコルの子レイヤ識別子がお互いの間で一意の値を持たなければなりません。 （詳細はセクション3.3を参照）。
protocol: A particular protocol layer, as specified by encoding rules in this document. Usually refers to a single layer in a given encapsulation. Note that this term is sometimes used in the RMON-2 MIB [RFC2021] to name a fully-specified protocol-identifier string. In such a case, the protocol-identifier string is named for its upper-most layer. A named protocol may also refer to any encapsulation of that protocol.
プロトコル：特定のプロトコル層は、この文書のルールをコードによって指定されます。通常、与えられたカプセル内の単一の層を意味します。この用語は、時には完全に指定されたプロトコル識別子文字列の名前をRMON-2 MIB [RFC2021]で使用されることに注意してください。このような場合には、プロトコル識別子ストリングは、その最上層にちなんで命名されています。名前のプロトコルは、そのプロトコルのいずれかのカプセル化を参照してもよいです。
protocol-identifier string: An octet string representing a particular protocol encapsulation, as specified by the encoding rules in this document. This string is identified in the RMON-2 MIB [RFC2021] as the protocolDirID object. A protocol-identifier string is composed of one or more layer-identifiers read from left to right. The left-most layer-identifier specifies a base layer encapsulation. Each layer-identifier to the right specifies a child layer protocol encapsulation.
プロトコル識別子ストリング：特定のプロトコルカプセル化を表すオクテットストリング、この文書の符号化規則によって指定されるように。この文字列は、プロトコルディレクトリオブジェクトとしてRMON-2 MIB [RFC2021]で識別されます。プロトコル識別子列は左から右に読み出された1または複数の層の識別子で構成されています。一番左の層識別子は、ベース層のカプセル化を指定します。右の各レイヤ識別子は、子層プロトコルカプセル化を指定します。
protocol-identifier macro: Also called a PI macro; A macro-like textual construct used to describe a particular networking protocol. Only protocol attributes which are important for RMON use are documented. Note that the term 'macro' is historical, and PI macros are not real macros, nor are they ASN.1 macros. The current set of published RMON PI macros can be found in the RMON Protocol Identifier Macros document [RFC2896].
プロトコル識別子マクロ：また、PIマクロと呼ばれます。マクロのようなテキスト構築物は、特定のネットワーク・プロトコルを記述するために使用されます。 RMONの使用のために重要な唯一のプロトコル属性が文書化されています。用語「マクロ」は、歴史的であることに注意してください、とPIマクロは、実際のマクロしているわけではなく、マクロをASN.1です。公表されたRMON PIマクロの現在のセットは、RMONプロトコル識別子マクロドキュメント[RFC2896]で見つけることができます。
The PI macro serves several purposes:
PIマクロは、いくつかの目的があります。
- Names the protocol for use within the RMON-2 MIB [RFC2021]. - Describes how the protocol is encoded into an octet string. - Describes how child protocols are identified (if applicable), and encoded into an octet string. - Describes which protocolDirParameters are allowed for the protocol. - Describes how the associated protocolDirType object is encoded for the protocol. - Provides reference(s) to authoritative documentation for the protocol.
- 名前RMON-2 MIB [RFC2021]内で使用するためのプロトコル。 - プロトコルは、オクテットストリングに符号化される方法を説明します。 - 子供プロトコルは（該当する場合）を同定し、そしてオクテット文字列にエンコードされている方法を説明します。 - プロトコルのために許可されるprotocolDirParameters記述する。 - 関連protocolDirTypeオブジェクトがプロトコルのために符号化される方法を説明します。 - プロトコルの権威文書への参照（複数可）を提供します。
protocol-variant-identifier macro: Also called a PI-variant macro; A special kind of PI macro, used to describe a particular protocol layer, which cannot be identified with a deterministic, and (usually) hierarchical structure, like most networking protocols.
プロトコルバリアント識別子マクロ：また、PI-変異マクロと呼ばれます。ほとんどのネットワーク・プロトコルのような決定論的で識別することができない特定のプロトコル層、および（通常は）階層構造を記述するために使用PIマクロの特別な種類、。
Note that the PI-variant macro and the PI-macro are defined with
a single set of syntax rules (see section 3.2), except that
different sub-clauses are required for each type.
A protocol identified with a PI-variant macro is actually a variant of a well known encapsulation that may be present in the protocolDirTable. This is used to document the IANA assigned protocols, which are needed to identify protocols which cannot be practically identified by examination of 'appropriate network traffic' (e.g. the packets which carry them). All other protocols (which can be identified by examination of appropriate network traffic) SHOULD be documented using the protocol-identifier macro. (See section 3.2 for details.)
PI-バリアントマクロで識別されたプロトコルは、実際protocolDirTableで存在することができる周知のカプセル化の変異体です。これは実質的に「適切なネットワークトラフィック」（それらを運ぶ例えばパケット）の検査によって識別することができないプロトコルを識別するために必要とされるIANA割り当てプロトコルを文書化するために使用されます。 （適切なネットワークトラフィックの検査によって同定することができる）他のすべてのプロトコルは、プロトコル識別子マクロを使用して文書化されるべきです。 （詳細はセクション3.2を参照してください。）
protocol-parameter: A single octet, corresponding to a specific layer-identifier in the protocol-identifier. This octet is a bit-mask indicating special functions or capabilities that this agent is providing for the corresponding protocol. (See section 3.2.6 for details.)
プロトコルパラメータ：単一オクテット、プロトコル識別子で特定レイヤ識別子に対応します。このオクテットは、この薬剤は、対応するプロトコルのために提供される特別な機能や能力を示すビットマスクです。 （詳細については、セクション3.2.6を参照してください。）
protocol-parameters string: An octet string, which contains one protocol-parameter for each layer-identifier in the protocol-identifier. This string is identified in the RMON-2 MIB [RFC2021] as the protocolDirParameters object. (See the section 3.2.6 for details.)
プロトコルパラメータストリング：プロトコル識別子の各レイヤ識別子のための1つのプロトコルパラメータが含まオクテットストリング。 protocolDirParametersオブジェクトとしてこの文字列は、RMON-2 MIB [RFC2021]で識別されます。 （詳細については、セクション3.2.6を参照してください。）
protocolDirTable INDEX: A protocol-identifier and protocol-parameters octet string pair that have been converted to an INDEX value, according to the encoding rules in section 7.7 of RFC 1902 [RFC1902].
protocolDirTable INDEX：インデックス値に変換されたプロトコル識別子とプロトコルパラメータオクテットストリング対、RFC 1902のセクション7.7での符号化規則に従って、[RFC1902]。
pseudo-protocol: A convention or algorithm used only within this document for the purpose of encoding protocol-identifier strings.
擬似プロトコル：符号化プロトコル識別子ストリングの目的のためにのみ、この文書内で使用される規則またはアルゴリズム。
protocol encapsulation tree: Protocol encapsulations can be organized into an inverted tree. The nodes of the root are the base encapsulations. The children nodes, if any, of a node in the tree are the encapsulations of child protocols.
プロトコルカプセル化木：プロトコルカプセル化は、逆ツリーに編成することができます。ルートのノードはベースカプセル化されています。ツリー内のノードの子ノードは、もしあれば、子プロトコルのカプセル化されています。
This document is intended to identify the encoding rules for the OCTET STRING objects protocolDirID and protocolDirParameters. RMON-2 tables, such as those in the new Protocol Distribution, Host, and Matrix groups, use a local INTEGER INDEX (protocolDirLocalIndex) rather than complete protocolDirTable INDEX strings, to identify protocols for counting purposes. Only the protocolDirTable uses the protocolDirID and protocolDirParameters strings described in this document.
この文書は、OCTET STRINGのプロトコルディレクトリとprotocolDirParametersオブジェクトの符号化ルールを識別することを意図しています。 RMON-2などの新しいプロトコルの配布、ホスト、およびマトリックスグループのものとテーブルは、目的をカウントするためのプロトコルを識別するために、むしろ完全protocolDirTable INDEX列よりも地元の整数インデックス（のprotocolDirLocalIndex）を使用します。唯一のprotocolDirTableは、この文書で説明するプロトコルディレクトリとprotocolDirParameters文字列を使用しています。
This document is intentionally separated from the RMON-2 MIB objects [RFC2021] to allow updates to this document without any republication of MIB objects.
この文書は、意図的にMIBオブジェクトの再発行せずに、この文書の更新を可能にするRMON-2 MIBオブジェクト[RFC2021]から分離されます。
This document does not discuss auto-discovery and auto-population of the protocolDirTable. This functionality is not explicitly defined by the RMON standard. An agent SHOULD populate the directory with the 'interesting' protocols on which the intended applications depend.
このドキュメントでは、自動検出およびprotocolDirTableの自動人口については説明しません。この機能は、明示的にRMON標準で定義されていません。エージェントは、意図したアプリケーションが依存している「面白い」プロトコルでディレクトリを移入すべきです。
The original RMON Protocol Identifiers document [RFC2074] contains the protocol directory reference material, as well as many examples of protocol identifier macros.
オリジナルRMONプロトコル識別子文献[RFC2074]は、プロトコルディレクトリの参照材料、ならびにプロトコル識別子マクロの多くの例を含んでいます。
These macros have been moved to a separate document called the RMON Protocol Identifier Macros document [RFC2896]. This will allow the normative text (this document) to advance on the standards track with the RMON-2 MIB [RFC2021], while the collection of PI macros is maintained in an Informational RFC.
これらのマクロは、別の文書に移動されましたRMONプロトコル識別子マクロドキュメント[RFC2896]と呼ばれます。これは、PIマクロのコレクションは情報のRFCに維持したまま、RMON-2 MIB [RFC2021]で追跡する規範的なテキスト（この文書は）標準に進出することができます。
The PI Macros document is intentionally separated from this document to allow updates to the list of published PI macros without any republication of MIB objects or encoding rules. Protocol Identifier macros submitted from the RMON working group and community at large (to the RMONMIB WG mailing list at 'rmonmib@ietf.org') will be collected, screened by the RMONMIB working group, and (if approved) added to a subsequent version of the PI Macros document.
PIマクロの文書は、意図的にMIBオブジェクトまたは符号化規則のいずれかの再発行せずに公表されたPIマクロのリストの更新を許可するには、この文書から分離されています。 （「rmonmib@ietf.org」でRMONMIB WGメーリングリストに）大でRMONワーキンググループやコミュニティから提出プロトコル識別子マクロはRMONMIBワーキンググループによってスクリーニングし、収集、および（承認された場合）は、以降のバージョンに追加されますPIマクロドキュメントの。
Macros submissions will be collected in the IANA's MIB files under the directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in the RMONMIB working group mailing list message archive file www.ietf.org/mail-archive/working-groups/rmonmib/current/maillist.htm.
マクロの提出はwww.ietf.org/mail-グループメーリングリストメッセージアーカイブファイルを作業ディレクトリ「ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/」の下でIANAのMIBファイルにとRMONMIBに収集することができるだろうアーカイブ/ワーキング・グループ/ rmonmib /現在/ maillist.htm。
The ATM Forum has standardized "Remote Monitoring MIB Extensions for ATM Networks" (ATM-RMON MIB) [AF-NM-TEST-0080.000], which provides RMON-like stats, host, matrix, and matrixTopN capability for NSAP address-based (ATM Adaption Layer 5, AAL-5) cell traffic.
ATMフォーラムはNSAPアドレスベースのRMONのような統計、ホスト、マトリクス、およびmatrixTopN機能を提供 "ATMネットワークのリモートモニタリングMIB拡張"（ATM-RMON MIB）[AF-NM-TEST-0080.000]を、（標準化されましたATMアダプションレイヤ5、AAL-5）セルトラフィック。
It it possible to correlate ATM-RMON MIB data with packet-based RMON-2 [RFC2021] collections, but only if the ATM-RMON 'portSelGrpTable' and 'portSelTable' are configured to provide the same level of port aggregation as used in the packet-based collection. This will require an ATM-RMON 'portSelectGroup' to contain a single port, in the case of traditional RMON dataSources.
これは、パケットベースのRMON-2 [RFC2021]コレクションをATM-RMON MIBのデータを相関させることが可能それが、で使用されるATM-RMON「portSelGrpTable」と「portSelTable」は、ポート集合の同じレベルを提供するように構成されている場合のみパケットベースのコレクション。これは、伝統的なRMONデータソースの場合には、単一のポートを含むようにATM-RMON「portSelectGroup」を必要とします。
The RMON PI document does not contain explicit PI macro support for "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [RFC1483], or ATM Forum "LAN Emulation over ATM" (LANE) [AF-LANE-0021.000]. Instead, a probe must 'fit' the ATM encapsulation to one of the base layers defined in this document (i.e., llc, snap, or vsnap), regardless of how the raw data is obtained by the agent (e.g., VC-muxing vs. LLC-muxing, or routed vs. bridged formats). See section 3.2 for details on identifying and decoding a particular base layer.
RMON PI文書は、 "ATMアダプテーションレイヤ5以上のマルチプロトコルカプセル化" [RFC1483]、またはATMフォーラム "ATM上のLANエミュレーション"（LANE）[AF-LANE-0021.000]の明示的なPIマクロのサポートが含まれていません。代わりに、プローブは、この文書で定義された基本層の一つにATMカプセル化を「フィット」（すなわち、LLC、スナップ、またはvsnap）にかかわらず、生のデータがエージェントによって得られるかの（例えば、VC-多重化対なければなりません。LLC-多重化、またはルーティングされた対の形式をブリッジ）。同定および特定のベース層を復号化の詳細については、セクション3.2を参照。
An NMS can determine some of the omitted encapsulation details by examining the interface type (ifType) of the dataSource for a particular RMON collection:
NMSは、特定のRMON収集のためのデータソースのインターフェイスタイプ（のifType）を調べることによって省略封入詳細の一部を決定することができます。
RFC 1483 dataSource ifTypes: - aal5(49)
RFC 1483のdataSource ifTypes： - AAL5（49）
LANE dataSource ifTypes: - aflane8023(59) - aflane8025(60)
LANEのdataSource ifTypes： - aflane8023（59） - aflane8025（60）
These dataSources require implementation of the ifStackTable from the Interfaces MIB [RFC2233]. It is possible that some implementations will use dataSource values which indicate an ifType of 'atm(37)' (because the ifStackTable is not supported), however this is strongly discouraged by the RMONMIB WG.
これらのデータソースは、インタフェースMIB [RFC2233]からのifStackTableの実装を必要としています。 （のifStackTableがサポートされていないため）いくつかの実装は、しかし、これは強くRMONMIB WGによって推奨される「ATM（37）」のifTypeのを示すデータソース値を使用することが可能です。
The RMON-2 Application Layer (AL) and Network Layer (NL) (host/matrix/topN) tables require that octet counters be incremented by the size of the particular frame, not by the size of the frame attributed to a given protocol.
RMON-2アプリケーション層（AL）及びネットワーク層（NL）（ホスト/マトリックス/のtopN）テーブルは、オクテットカウンタが特定のフレームのサイズではなく、特定のプロトコルに起因するフレームのサイズだけインクリメントされることを必要とします。
Probe implementations must use the AAL-5 frame size (not the AAL-5 payload size or encapsulated MAC frame size) as the 'frame size' for the purpose of incrementing RMON-2 octet counters (e.g., 'nlHostInOctets', 'alHostOutOctets').
プローブの実装（例えば、「nlHostInOctets」、「alHostOutOctets」をRMON-2オクテットカウンタをインクリメントする目的のための「フレームサイズ」とAAL-5フレームサイズ（非AAL-5ペイロードサイズ又はカプセル化されたMACフレームサイズ）を使用する必要があります）。
The RMONMIB WG has not addressed issues relating to packet capture of AAL-5 based traffic. Therefore, it is an implementation-specific matter whether padding octets (i.e., RFC 1483 VC-muxed, bridged 802.3 or 802.5 traffic, or LANE traffic) are represented in the RMON-1 'captureBufferPacketData' MIB object. Normally, the first octet of the captured frame is the first octet of the destination MAC address (DA).
RMONMIB WGは、AAL-5ベースのトラフィックのパケットキャプチャに関連する問題に対処していません。従って、パディングオクテット（すなわち、RFC 1483 VC-多重化、架橋802.3又は802.5トラフィック、またはLANEトラフィックが）RMON-1「captureBufferPacketData」MIBオブジェクトで表現されているかどうかを実装固有の問題です。通常、捕捉されたフレームの最初のオクテットは、宛先MACアドレス（DA）の最初のオクテットです。
The RMON Protocol Identifiers Reference document is intended for use with the protocolDirTable within the RMON MIB. It is not relevant to any other MIB, or intended for use with any other MIB.
RMONプロトコル識別子の参照文書は、RMON MIB内protocolDirTableで使用するためのものです。これは、他のMIBに関連する、または任意の他のMIBで使用するためのものではありません。
The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID and protocolDirParameters. To encode the table index, each variable-length string is converted to an OBJECT IDENTIFIER fragment, according to the encoding rules in section 7.7 of RFC 1902 [RFC1902]. Then the index fragments are simply concatenated. (Refer to figures 1a - 1d below for more detail.)
protocolDirTableは2つのオクテット文字列、プロトコルディレクトリおよびprotocolDirParametersによってインデックスされます。テーブルインデックスを符号化するために、各可変長文字列は、RFC 1902のセクション7.7で符号化規則[RFC1902]によれば、オブジェクト識別子フラグメントに変換されます。そして、インデックスの断片は、単純に連結されます。 （図1Aを参照してください - 詳細について以下図1d）。
The first OCTET STRING (protocolDirID) is composed of one or more 4- octet "layer-identifiers". The entire string uniquely identifies a particular node in the protocol encapsulation tree. The second OCTET STRING, (protocolDirParameters) which contains a corresponding number of 1-octet protocol-specific parameters, one for each 4-octet layer-identifier in the first string.
最初のオクテット列（プロトコルディレクトリ）は、1つまたは複数の4-オクテット「レイヤ識別子」から構成されています。文字列全体が一意プロトコルカプセル化ツリーの特定のノードを識別する。 1オクテットのプロトコル固有のパラメータ、最初の文字列内の各4オクテットのレイヤ識別子のための1つの対応する数を含む第2のオクテットSTRING（protocolDirParameters）。
A protocol layer is normally identified by a single 32-bit value. Each layer-identifier is encoded in the ProtocolDirID OCTET STRING INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent each byte of the 32-bit value in network byte order. If a particular protocol layer cannot be encoded into 32 bits, then it must be defined as an 'ianaAssigned' protocol (see below for details on IANA assigned protocols).
プロトコル層は、通常、単一の32ビット値によって識別されます。ネットワークバイト順の32ビット値の各バイトを表す「D」 - 各レイヤ識別子が「A」の4つのサブコンポーネント[A.B.C.D]、としてプロトコルディレクトリOCTET STRING INDEXで符号化されます。特定のプロトコル・レイヤが32ビットに符号化することができない場合、それは「ianaAssigned」プロトコル（IANA割り当てプロトコルの詳細については以下を参照）のように定義されなければなりません。
The following figures show the differences between the OBJECT IDENTIFIER and OCTET STRING encoding of the protocol identifier string.
以下の図は、プロトコル識別子列のオブジェクト識別子とOCTET STRINGエンコーディングの違いを示しています。
Fig. 1a
protocolDirTable INDEX Format
-----------------------------
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+
Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
protocolDirID
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
protocolDirParameters
+----------+
| |
| N octets |
| |
+----------+
N is the number of protocol-layer-identifiers required for the entire encapsulation of the named protocol. Note that the layer following the base layer usually identifies a network layer protocol, but this is not always the case, (most notably for children of the 'vsnap' base-layer).
Nは、指定されたプロトコルの全体をカプセル化するために必要なプロトコル層識別子の数です。 （特に「vsnap」ベース層の子供たちのために）、ベース層以下の層は、通常、ネットワーク層プロトコルを識別し、これは常にそうではないことに注意してください。
Fig. 1c
protocolDirTable INDEX Format Example
-------------------------------------
protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | base | L(B+1) | L(B+2) | L(B+3) | n |ba-| L3| L4| L5|
| t |(+flags)| L3 | L4 | L5 | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 | 4 | 4 | 4 | 1 | 1 | 1 | 1 | 1 | count
When encoded in a protocolDirTable INDEX, each of the two strings must be preceded by a length sub-component. In this example, N equals '4', the first 'cnt' field would contain the value '16', and the second 'cnt' field would contain the value '4'.
protocolDirTable INDEXで符号化されたとき、二つの文字列のそれぞれは、長さサブコンポーネントが先行されなければなりません。この例では、Nは、最初の「CNT」フィールドの値が「16」、および値を含むであろう第二の「CNT」フィールドを含むであろう4「」「4」に等しいです。
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 | 4 | 4 | 4 | count
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
Although this example indicates four encapsulated protocols, in practice, any non-zero number of layer-identifiers may be present, theoretically limited only by OBJECT IDENTIFIER length restrictions, as specified in section 3.5 of RFC 1902 [RFC1902].
この例では、4つのカプセル化されたプロトコルを示しているが、実際には、層識別子の任意の非ゼロ数は、RFC 1902のセクション3.5 [RFC1902]で指定されるように、理論的に、唯一のオブジェクト識別子の長さの制約によって制限され、存在してもよいです。
The following PI identifier fragments are examples of some fully encoded protocolDirTable INDEX values for various encapsulations.
以下PI識別子フラグメントは、種々のカプセル化のためのいくつかの完全に符号化されたprotocolDirTable指標値の一例です。
-- HTTP; fragments counted from IP and above ether2.ip.tcp.www-http = 16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
- HTTP; IPからとether2.ip.tcp.www-HTTP = 16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0上に数え断片
-- SNMP over UDP/IP over SNAP snap.ip.udp.snmp = 16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
- SNAPオーバーUDP / IP上のSNMP snap.ip.udp.snmp = 16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- SNMP over IPX over SNAP snap.ipx.snmp = 12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
- SNAPオーバーIPX上でSNMP snap.ipx.snmp = 12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
-- SNMP over IPX over raw8023 ianaAssigned.ipxOverRaw8023.snmp = 12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0
- オーバーIPX上でSNMP raw8023 ianaAssigned.ipxOverRaw8023.snmp = 12.0.0.0.5.0.0.0.1.0.0.144.15.3.0.0.0
-- IPX over LLC llc.ipx = 8.0.0.0.2.0.0.0.224.2.0.0
- LLCオーバーIPX llc.ipx = 8.0.0.0.2.0.0.0.224.2.0.0
-- SNMP over UDP/IP over any link layer ether2.ip.udp.snmp 16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
- 任意のリンク層ether2.ip.udp.snmp上のUDP / IP上のSNMP 16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- IP over any link layer; base encoding is IP over ether2 ether2.ip 8.1.0.0.1.0.0.8.0.2.0.0
- IP上の任意のリンク層と、ベースエンコーディングは、IP経由ether2 ether2.ip 8.1.0.0.1.0.0.8.0.2.0.0です
-- AppleTalk Phase 2 over ether2 ether2.atalk 8.0.0.0.1.0.0.128.155.2.0.0
- AppleTalkのフェーズ2を超えるether2 ether2.atalk 8.0.0.0.1.0.0.128.155.2.0.0
-- AppleTalk Phase 2 over vsnap vsnap.apple-oui.atalk 12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
- vsnap vsnap.apple-oui.atalk以上のAppleTalkフェーズ2 12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
The following example is meant to introduce the protocol-identifier macro. This macro-like construct is used to represent both protocols and protocol-variants.
以下の例は、プロトコル識別子マクロを導入することを意味します。このマクロ状構築物をプロトコルとプロトコル変異体の両方を表すために使用されます。
If the 'VariantOfPart' component of the macro is present, then the macro represents a protocol-variant instead of a protocol. This clause is currently used only for IANA assigned protocols, enumerated under the 'ianaAssigned' base-layer. The VariantOfPart component MUST be present for IANA assigned protocols.
マクロの「VariantOfPart」成分が存在する場合、マクロではなく、プロトコルのプロトコル・バリアントを表します。この句は、現在、「ianaAssigned」ベース層の下に列挙IANA割り当てプロトコルのために使用されます。 VariantOfPart成分は、IANA割り当てプロトコルのために存在していなければなりません。
The PI language defines the following keywords:
PI言語は以下のキーワードを定義します。
ADDRESS-FORMAT
ATTRIBUTES
CHILDREN
DECODING
DESCRIPTION
PARAMETERS
PROTOCOL-IDENTIFIER
REFERENCE
VARIANT-OF
The PI language defines the following punctuation elements:
PI言語は以下の句読点の要素を定義します。
{ left curly brace
} right curly brace
( left parenthesis
) right parenthesis
, comma
::= two colons and an equal sign
-- two dashes
An extended form of the BNF notation is used to specify the syntax of the PI language. The rules for this notation are shown below:
BNF表記の拡張形式は、PI言語の構文を指定するために使用されます。この表記法のための規則を以下に示します。
* Literal values are specified in quotes, for example "REFERENCE"
*リテラル値は、例えば、「REFERENCE」のために、引用符で囲んで指定されています
* Non-terminal items are surrounded by less than (<) and greater than (>) characters, for example <parmList>
*非末端項目がより小さい（<）によって囲まれているよりも、より大きな（>）文字、例えば<PARMLIST>
* Terminal items are specified without surrounding quotes or less than and greater than characters, for example 'lcname'
*ターミナルの項目は、例えば「lcname」、またはより少ないと文字を超える引用符を囲むなしで指定されています
* A vertical bar (|) is used to indicate a choice between items, for example 'number | hstr'
*垂直バー（|）は項目、例えば「数との間の選択を示すために使用されます| HSTR」
* Ellipsis are used to indicate that the previous item may be repeated one or more times, for example <parm>...
*省略記号は、前の項目は、例えば、1回以上繰り返されてもよいことを示すために使用されている<PARM> ...
* Square brackets are used to enclose optional items, for example [ "," <parm> ]
*角括弧は、オプション項目を囲むために使用され、例えば[「」<PARM>]
* An equals character (=) is used to mean "defined as," for example '<protoName> = pname'
*アンは「<protoName> = pnameの」は、例えば「と定義」を意味するために使用される文字（=）に等しいです
The following are "terminals" of the grammar and are identical to the same lexical elements from the MIB module language, except for hstr and pname:
次の文法の「端子」であるとHSTRとPNAMEを除いて、MIBモジュール言語から同じ字句要素と同一です。
<lc> = "a" | "b" | "c" | ... | "z"
<uc> = "A" | "B" | "C" | ... | "Z"
<letter> = <lc> | <uc>
<digit> = "0" | "1" | ... | "9"
<hdigit> = <digit> | "a" | "A" | "b" | "B" | ... | "f" | "F"
<lcname> = <lc> [ <lcrest> ] <lcrest> = ( <letter> | <digit> | "-" ) [ <lcrest> ]
<lcname> = <LC> [<lcrest> <lcrest> =（<文字> | <数字> | " - "）<lcrest>]
<pname> = ( <letter> | <digit> ) [ <pnrest> ] <pnrest> = ( <letter> | <digit> | "-" | "_" | "*" ) [ <pnrest> ]
<PNAME> =（<文字> | <数字>）[<pnrest>] <pnrest> =（<文字> | <数字> | " - " | "_" | "*"）[<pnrest>]
<number> = <digit> [ <number> ] -- to a max dec. value of 4g-1
<番号> = <数字> [<番号>] - 最大12月まで。 4グラム-1の値
<hstr> = "0x" <hrest> -- to a max dec. value of 4g-1 <hrest> = <hdigit> [ <hrest> ]
<HSTR> = "0X" <hrest> - 最大12月に。 4グラム-1 <hrest> = <hdigit> [<hrest>]の値
<lf> = linefeed char <cr> = carriage return char <eoln> = <cr><lf> | <lf>
<LF> =改行文字<CR> =キャリッジリターン文字<eoln> = <CR> <LF> | <LF>
<sp> = " " <tab> = " " <wspace> = { <sp> | <tab> | <eoln> } [<wspace>]
<SP> = "" <タブ> = "" <wspace> = {<SP> | <タブ> | <eoln>} [<wspace>]
<string> = """ [ <strest> ] """ <strest> = ( <letter> | <digit> | <wspace> ) [ <strest> ]
<文字列> = "" "[<ストリート>]" "" <ストリート> =（<文字> | <数字> | <によってWSPA>）<ストリート>]
The following is the extended BNF notation for the grammar with starting symbol <piFile>:
シンボルの開始と文法の拡張BNF表記がされている次の<piFile>
-- a file containing one or more Protocol Identifier (PI)
-- definitions
<piFile> = <piDefinition>...
-- a PI definition
<piDefinition> =
<protoName> "PROTOCOL-IDENTIFIER"
[ "VARIANT-OF" <protoName> ]
"PARAMETERS" "{" [ <parmList> ] "}"
"ATTRIBUTES" "{" [ <attrList> ] "}"
"DESCRIPTION" string
[ "CHILDREN" string ]
[ "ADDRESS-FORMAT" string ]
[ "DECODING" string ]
[ "REFERENCE" string ]
"::=" "{" <encapList> "}"
-- a protocol name <protoName> = pname
- プロトコル名<protoName> = pnameに
-- a list of parameters <parmList> = <parm> [ "," <parm> ]...
- <PARMLIST> = <PARM> [ "" <PARM>]パラメータのリスト...
-- a parameter <parm> = lcname [<wspace>] "(" [<wspace>] <nonNegNum> [<wspace>] ")" [<wspace>]
- パラメータ<PARM> = lcname [<wspace>] "（" [<wspace> <nonNegNum> [<wspace>] "）" [<wspace>]
-- list of attributes <attrList> = <attr> [ [<wspace>] "," [<wspace>] <attr> ]...
- <attrListは> = <ATTR> [[<wspace>] "" [<wspace>] <ATTR>]属性のリスト...
-- an attribute <attr> = lcname [<wspace>] "(" [<wspace>] <nonNegNum> [<wspace>] ")"
- 属性<ATTR> = lcname [<wspace>] "（" [<wspace> <nonNegNum> [<wspace>] "）"
-- a non-negative number <nonNegNum> = number | hstr
- 非負の数<nonNegNum> =数| HSTR
-- list of encapsulation values <encapList> = <encapValue> [ [<wspace>] "," [<wspace>] <encapValue> ]...
- カプセル値のリスト<encapList> = <encapValue> [[<wspace>] "" [<wspace>] <encapValue>] ...
-- an encapsulation value <encapValue> = <baseEncapValue> | <normalEncapValue>
- カプセル値<encapValue> = <baseEncapValue> | <normalEncapValue>
-- base encapsulation value <baseEncapValue> = <nonNegNum>
- ベースのカプセル化値<baseEncapValue> = <nonNegNum>
-- normal encapsulation value <normalEncapValue> = <protoName> <wspace> <nonNegNum>
- 通常のカプセル化値<normalEncapValue> = <protoName> <wspace> <nonNegNum>
-- comment <two dashes> <text> <end-of-line>
- コメント<2つのダッシュ> <テキスト> <行末>
The "protoName" value, called the "protocol name" shall be an ASCII string consisting of one up to 64 characters from the following:
「protoName」値は、次の中から1〜64までの文字からなるASCII文字列でなければならない「プロトコル名」と呼ばれます。
"A" through "Z"
"a" through "z"
"0" through "9"
dash (-)
underbar (_)
asterisk (*)
plus(+)
The first character of the protocol name is limited to one of the following:
プロトコル名の最初の文字は、次のいずれかに限定されます。
"A" through "Z"
"a" through "z"
"0" through "9"
"0" から "9"
This value SHOULD be the name or acronym identifying the protocol. Note that case is significant. The value selected for the protocol name SHOULD match the "most well-known" name or acronym for the indicated protocol. For example, the document indicated by the URL:
この値は、プロトコルを識別する名前または頭字語であるべきです。その場合は、重要であることに注意してください。プロトコル名に選択された値が示されているプロトコルは、「最もよく知られている」名前または頭字語と一致する必要があります。例えば、文書はURLで示されます：
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
ｆｔｐ：／／ｆｔｐ。いし。えづ／いんーのてｓ／いあな／あっしｇんめんｔｓ／ｐろとこｌーぬｍべｒｓ
defines IP Protocol field values, so protocol-identifier macros for children of IP SHOULD be given names consistent with the protocol names found in this authoritative document. Likewise, children of UDP and TCP SHOULD be given names consistent with the port number name assignments found in:
IPプロトコルフィールドの値を定義し、そのIPの子供のためのプロトコル識別子マクロは、この権威ある文書で見つかったプロトコル名と一致名を与えられるべきです。同様に、UDPとTCPの子供たちがで見つかったポート番号名の割り当てと一致名前が与えられるべきです：
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
ｆｔｐ：／／ｆｔｐ。いし。えづ／いんーのてｓ／いあな／あっしｇんめんｔｓ／ぽｒｔーぬｍべｒｓ
When the "well-known name" contains characters not allowed in protocol names, they MUST be changed to a dash character ("-") . In the event that the first character must be changed, the protocol name is prepended with the letter "p", so the former first letter may be changed to a dash.
「よく知られた名前は、」プロトコル名に使用できない文字が含まれている場合、彼らはダッシュ文字（「 - 」）に変更する必要があります。かつての最初の文字がダッシュに変更することができるので、最初の文字を変更しなければならないことをイベントでは、プロトコル名は、文字「P」を付加されます。
For example, z39.50 becomes z39-50 and 914c/g becomes 914c-g. The following protocol names are legal:
たとえば、Z39.50はz39-50なり、914C / gで914C-Gとなります。以下のプロトコル名が有効です：
ftp, ftp-data, whois++, sql*net, 3com-tsmux, ocs_cmu
FTP、FTP-データ、WHOIS ++、SQL *ネット、3comの-tsmux、ocs_cmu
Note that it is possible in actual implementation that different encapsulations of the same protocol (which are represented by different entries in the protocolDirTable) will be assigned the same protocol name. The protocolDirID INDEX value defines a particular protocol, not the protocol name string.
それは（protocolDirTableに異なるエントリによって表される）は、同じプロトコルの異なるカプセル化は、同じプロトコル名を割り当てられること実際の実装で可能であることに留意されたいです。プロトコルディレクトリインデックス値は、特定のプロトコルではなく、プロトコル名の文字列を定義します。
This clause is present for IANA assigned protocols only. It identifies the protocol-identifier macro that most closely represents this particular protocol, and is known as the "reference protocol". A protocol-identifier macro MUST exist for the reference protocol. When this clause is present in a protocol-identifier macro, the macro is called a 'protocol-variant-identifier'.
この句は、IANA割り当てられたプロトコルのために存在しています。これは、最も密接にこの特定のプロトコルを表すプロトコル識別子マクロを識別し、「参照プロトコール」として知られています。プロトコル識別子マクロは、参照プロトコルのために存在しなければなりません。この句は、プロトコル識別子マクロ中に存在する場合、マクロは、「プロトコル・バリアント識別子」と呼ばれます。
Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol-identifier macro SHOULD NOT be duplicated in the protocol-variant-identifier macro, if the 'variant' protocols' semantics are identical for a given clause.
「変異体」プロトコル意味論は、所与の句のために同一である場合、参照プロトコル識別子マクロ内の任意の句（例えばCHILDREN、ADDRESS-FORMAT）は、プロトコルバリアント識別子マクロで複製するべきではありません。
Since the PARAMETERS and ATTRIBUTES clauses MUST be present in a protocol-identifier, an empty 'ParamList' and 'AttrList' (i.e. "PARAMETERS {}") MUST be present in a protocol-variant-identifier macro, and the 'ParamList' and 'AttrList' found in the reference protocol-identifier macro examined instead.
PARAMETERSので句は、プロトコル識別子、空「ParamList」およびプロトコルバリアント識別子マクロ内に存在していなければなりません「ATTRLIST」（すなわち、「パラメータ{}」）、および「ParamList」中に存在する必要がある属性と代わり検査基準プロトコル識別子マクロに見られる「ATTRLIST」。
Note that if an 'ianaAssigned' protocol is defined that is not a variant of any other documented protocol, then the protocol-identifier macro SHOULD be used instead of the protocol-variant-identifier version of the macro.
「ianaAssigned」プロトコルは、任意の他の文書のプロトコルの変形ではないと定義されている場合は、プロトコル識別子マクロ代わりにマクロのプロトコルバリアント識別子バージョンを使用する必要があることに注意してください。
The protocolDirParameters object provides an NMS the ability to turn on and off expensive probe resources. An agent may support a given parameter all the time, not at all, or subject to current resource load.
protocolDirParametersオブジェクトは、NMSに上と高価なプローブリソースオフにする機能を提供します。エージェントは、全く、または対象現在のリソースの負荷に、与えられたパラメータのすべての時間をサポートすることができます。
The PARAMETERS clause is a list of bit definitions which can be directly encoded into the associated ProtocolDirParameters octet in network byte order. Zero or more bit definitions may be present. Only bits 0-7 are valid encoding values. This clause defines the entire BIT set allowed for a given protocol. A conforming agent may choose to implement a subset of zero or more of these PARAMETERS.
PARAMETERS句は、直接ネットワークバイト順に関連ProtocolDirParametersオクテットに符号化することができるビット定義のリストです。ゼロ以上のビットの定義が存在してもよいです。唯一のビット0-7は、有効なエンコード値です。この句は、特定のプロトコルに許可全体ビットセットを定義します。適合剤は、これらのパラメータのゼロ個以上のサブセットを実装することを選択することができます。
By convention, the following common bit definitions are used by different protocols. These bit positions MUST NOT be used for other parameters. They MUST be reserved if not used by a given protocol.
慣例により、以下の共通のビット定義は異なるプロトコルで使用されています。これらのビット位置は、他のパラメータのために使用してはいけません。与えられたプロトコルで使用されていない場合、彼らは予約する必要があります。
Bits are encoded in a single octet. Bit 0 is the high order (left-most) bit in the octet, and bit 7 is the low order (right-most) bit in the first octet. Reserved bits and unspecified bits in the octet are set to zero.
ビットは単一オクテットで符号化されます。ビット0は、高次オクテットの（最も左）ビットであり、ビット7は、第1オクテットの下位（右端）ビットです。オクテットの予約ビットおよび不特定のビットはゼロに設定されています。
Table 3.1 Reserved PARAMETERS Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated within
this protocol will be counted correctly even
if this protocol fragments the upper layers
into multiple packets.
1 tracksSessions correctly attributes all packets of a protocol
which starts sessions on well known ports or
sockets and then transfers them to dynamically
assigned ports or sockets thereafter (e.g. TFTP).
The PARAMETERS clause MUST be present in all protocol-identifier macro declarations, but may be equal to zero (empty).
PARAMETERS句は、すべてのプロトコル識別子マクロ宣言で存在しなければならないが、（空の）ゼロに等しくてもよいです。
This bit indicates whether the probe is correctly attributing all fragmented packets of the specified protocol, even if individual frames carrying this protocol cannot be identified as such. Note that the probe is not required to actually present any re-assembled datagrams (for address-analysis, filtering, or any other purpose) to the NMS.
このビットは、プローブが正しく、このプロトコルを運ぶ個々のフレームは、そのように識別できない場合でも、指定されたプロトコルのすべてのフラグメントパケットを帰属しているかどうかを示します。プローブが実際にNMSに（アドレス解析、フィルタリング、または他の目的のために）任意の再組み立てられたデータグラムを提示する必要はないことに注意してください。
This bit MUST only be set in a protocolDirParameters octet which corresponds to a protocol that supports fragmentation and reassembly in some form. Note that TCP packets are not considered 'fragmented-streams' and so TCP is not eligible.
このビットは、何らかの形で断片化と再アセンブリをサポートするプロトコルに対応するprotocolDirParametersのオクテットに設定しなければなりません。 TCPパケットが「断片化されたストリーム」とみなさないので、TCPは対象外であることに注意してください。
This bit MAY be set in more than one protocolDirParameters octet within a protocolDirTable INDEX, in the event an agent can count fragments at more than one protocol layer.
このビットは、イベント中に、エージェントが複数のプロトコル層でフラグメントをカウントすることができ、protocolDirTable INDEX内に複数のprotocolDirParametersのオクテットに設定されるかもしれません。
The 'tracksSessions(1)' bit indicates whether frames which are part of remapped sessions (e.g. TFTP download sessions) are correctly counted by the probe. For such a protocol, the probe must usually analyze all packets received on the indicated interface, and maintain some state information, (e.g. the remapped UDP port number for TFTP).
「tracksSessions（1）」ビットが再マップセッション（例えば、TFTPダウンロードセッション）の一部であるフレームが正しくプローブによってカウントされるかどうかを示します。そのようなプロトコルの場合、プローブは、通常、すべてのパケットが示されたインターフェイスで受信、分析、および一部の状態情報、（TFTP用の例えば再マップUDPポート番号）を維持しなければなりません。
The semantics of the 'tracksSessions' parameter are independent of the other protocolDirParameters definitions, so this parameter MAY be combined with any other legal parameter configurations.
「tracksSessions」パラメータの意味は、他のprotocolDirParameters定義から独立しているため、このパラメータは、他の法律上のパラメータ構成と組み合わせることができます。
The protocolDirType object provides an NMS with an indication of a probe's capabilities for decoding a given protocol, or the general attributes of the particular protocol.
protocolDirTypeオブジェクトは与えられたプロトコル、または特定のプロトコルの一般的な属性をデコードするためのプローブの能力の指標とNMS提供します。
The ATTRIBUTES clause is a list of bit definitions which are encoded into the associated instance of ProtocolDirType. The BIT definitions are specified in the SYNTAX clause of the protocolDirType MIB object.
ATTRIBUTES句はProtocolDirTypeの関連するインスタンスに符号化されたビットの定義のリストです。 BIT定義はprotocolDirType MIBオブジェクトのSYNTAX句で指定されています。
Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 hasChildren indicates that there may be children of
this protocol defined in the protocolDirTable
(by either the agent or the manager).
1 addressRecognitionCapable
indicates that this protocol can be used
to generate host and matrix table entries.
The ATTRIBUTES clause MUST be present in all protocol-identifier macro declarations, but MAY be empty.
ATTRIBUTES句は、すべてのプロトコル識別子マクロ宣言で存在しなければならないが、空であってもよいです。
The DESCRIPTION clause provides a textual description of the protocol identified by this macro. Notice that it SHOULD NOT contain details about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and REFERENCE clauses.
記述節は、このマクロによって識別プロトコルのテキスト記述を提供します。それはCHILDRENでカバー項目、ADDRESS-FORMAT、DECODINGとREFERENCE句についての詳細を含むべきではないことに注意してください。
The DESCRIPTION clause MUST be present in all protocol-identifier macro declarations.
記述句は、すべてのプロトコル識別子マクロ宣言で存在していなければなりません。
The CHILDREN clause provides a description of child protocols for protocols which support them. It has three sub-sections:
CHILDREN節は、それらをサポートするプロトコルの子プロトコルの記述を提供します。これは3つのサブセクションがあります。
- Details on the field(s)/value(s) used to select the child protocol, and how that selection process is performed
- フィールドの詳細（S）/値（単数または複数）は、子プロトコルを選択するために使用する方法、およびその選択処理が実行されます
- Details on how the value(s) are encoded in the protocol identifier octet string
- 値（複数可）は、プロトコル識別子オクテット文字列に符号化する方法の詳細
- Details on how child protocols are named with respect to their parent protocol label(s)
- 子供プロトコルは、親プロトコルラベルに関して命名されている方法についての詳細（複数可）
The CHILDREN clause MUST be present in all protocol-identifier macro declarations in which the 'hasChildren(0)' BIT is set in the ATTRIBUTES clause.
CHILDREN句は「hasChildren（0）」ビットがATTRIBUTES節で設定されたすべてのプロトコル識別子マクロ宣言で存在していなければなりません。
The ADDRESS-FORMAT clause provides a description of the OCTET-STRING format(s) used when encoding addresses.
ADDRESS-FORMAT句は、アドレスを符号化するときに使用されるオクテットストリング形式（S）の記述を提供します。
This clause MUST be present in all protocol-identifier macro declarations in which the 'addressRecognitionCapable(1)' BIT is set in the ATTRIBUTES clause.
この句は、「addressRecognitionCapable（1）」ビットがATTRIBUTES節で設定されたすべてのプロトコル識別子マクロ宣言で存在していなければなりません。
The DECODING clause provides a description of the decoding procedure for the specified protocol. It contains useful decoding hints for the implementor, but SHOULD NOT over-replicate information in documents cited in the REFERENCE clause. It might contain a complete description of any decoding information required.
DECODING節は、指定されたプロトコルのための復号化手順の説明を提供します。これは、実装のための便利なデコーディングのヒントが含まれていますが、REFERENCE節で引用された文献における過複製情報べきではありません。これは、必要なデコード情報の完全な記述が含まれている場合があります。
For 'extensible' protocols ('hasChildren(0)' BIT set) this includes offset and type information for the field(s) used for child selection as well as information on determining the start of the child protocol.
「拡張可能」プロトコル（「hasChildren（0）」ビット・セット）の場合、これはオフセットを含む、子選択ならびに子プロトコルの開始を決定することについては、使用するフィールド（単数または複数）のための情報を入力します。
For 'addressRecognitionCapable' protocols this includes offset and type information for the field(s) used to generate addresses.
「addressRecognitionCapable」プロトコルの場合、これはフィールド（複数可）のオフセットおよび入力情報を含むアドレスを生成するために使用されます。
The DECODING clause is optional, and MAY be omitted if the REFERENCE clause contains pointers to decoding information for the specified protocol.
DECODING句は任意であり、参照句が指定されたプロトコルの情報を復号化へのポインタが含まれている場合は省略されるかもしれません。
If a publicly available reference document exists for this protocol it SHOULD be listed here. Typically this will be a URL if possible; if not then it will be the name and address of the controlling body.
公に利用可能な参考文献は、このプロトコルのために存在している場合には、ここに書かれています。可能な場合、通常、これはURLになります。いない場合、それは、制御体の名前とアドレスになります。
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses SHOULD limit the amount of information which may currently be obtained from an authoritative document, such as the Assigned Numbers document [RFC1700]. Any duplication or paraphrasing of information should be brief and consistent with the authoritative document.
CHILDREN、ADDRESSフォーマット、および復号句は、現在、割り当て番号文書[RFC1700]として、権威文書から得ることができる情報の量を制限する必要があります。情報の任意の重複や言い換えを簡単かつ権威ある文書と一致している必要があります。
The REFERENCE clause is optional, but SHOULD be implemented if an authoritative reference exists for the protocol (especially for standard protocols).
REFERENCE句は任意であるが、権限の参照（特に標準プロトコル用）プロトコルに対する必要性が存在する場合に実施されるべきです。
The following evaluation is done after a protocolDirTable INDEX value has been converted into two OCTET STRINGs according to the INDEX encoding rules specified in the SMI [RFC1902].
protocolDirTable INDEX値はSMI [RFC1902]で指定されたインデックスの符号化規則に従って2つのオクテットストリングに変換された後、以下の評価が行われます。
Protocol-identifiers are evaluated left to right, starting with the protocolDirID, which length MUST be evenly divisible by four. The protocolDirParameters length MUST be exactly one quarter of the protocolDirID string length.
プロトコル識別子は4で割り切れるされなければならない長さ、プロトコルディレクトリから始まる、左から右に評価されています。 protocolDirParameters長は、プロトコルディレクトリ文字列の長さのちょうど四分の一でなければなりません。
Protocol-identifier parsing starts with the base layer identifier, which MUST be present, and continues for one or more upper layer identifiers, until all OCTETs of the protocolDirID have been used. Layers MUST NOT be skipped, so identifiers such as 'SNMP over IP' or 'TCP over ether2' can not exist.
プロトコル識別子の解析が存在しなければならない基本レイヤ識別子で始まり、そしてプロトコルディレクトリの全てのオクテットが使用されるまで、一つ以上の上位レイヤ識別子続きます。このような「IP上のSNMP」または「ether2上のTCP」などの識別子が存在しないことができるようにレイヤーは、スキップしてはなりません。
The base-layer-identifier also contains a 'special function identifier' which may apply to the rest of the protocol identifier.
ベースレイヤ識別子は、プロトコル識別子の残りの部分に適用することができる「特殊機能識別子」を含みます。
Wild-carding at the base layer within a protocol encapsulation is the only supported special function at this time. (See section 4.1.1.2 for details.)
プロトコルカプセル内のベース層で野生カーディングすると、この時点でのみサポートされている特別な機能です。 （詳細はセクション4.1.1.2を参照してください。）
After the protocol-identifier string (which is the value of protocolDirID) has been parsed, each octet of the protocol-parameters string is evaluated, and applied to the corresponding protocol layer.
（プロトコルディレクトリの値である）プロトコル識別子文字列が解析された後、プロトコルパラメータストリングの各オクテットを評価し、対応するプロトコル層に適用されます。
A protocol-identifier label MAY map to more than one value. For instance, 'ip' maps to 5 distinct values, one for each supported encapsulation. (see the 'IP' section under 'L3 Protocol Identifiers' in the RMON Protocol Identifier Macros document [RFC2896]).
プロトコル識別子のラベルが複数の値にマッピングすることができます。例えば、「IP」は5つの異なった値と、サポートされている各カプセル化のための1にマッピングされます。 （RMONプロトコル識別子マクロドキュメントの「L3プロトコル識別子」下「IP」セクション[RFC2896]を参照）。
It is important to note that these macros are conceptually expanded at implementation time, not at run time.
これらのマクロは、概念的にはない、実行時に、実装時に展開されることに注意することが重要です。
If all the macros are expanded completely by substituting all possible values of each label for each child protocol, a list of all possible protocol-identifiers is produced. So 'ip' would result in 5 distinct protocol-identifiers. Likewise each child of 'ip' would map to at least 5 protocol-identifiers, one for each encapsulation (e.g. ip over ether2, ip over LLC, etc.).
すべてのマクロは、それぞれの子プロトコルの各ラベルのすべての可能な値を代入することによって、完全に展開されている場合は、すべての可能なプロトコル識別子のリストが生成されます。だから、「IP」は5の異なるプロトコル識別子になります。同様に「IP」のそれぞれの子は、少なくとも5つのプロトコル識別子、各カプセル化するための1つ（ether2オーバー例えばIP、LLCオーバーIPなど）にマップします。
The following PROTOCOL IDENTIFIER macros can be used to construct protocolDirID and protocolDirParameters strings.
以下のプロトコル識別子マクロはプロトコルディレクトリとprotocolDirParameters文字列を構築するために使用することができます。
An identifier is encoded by constructing the base-identifier, then adding one layer-identifier for each encapsulated protocol.
識別子は、各カプセル化されたプロトコルの一つの層識別子を付加し、ベース識別子を構築することによって符号化されます。
Refer to the RMON Protocol Identifier Macros document [RFC2896] for a listing of the non-base layer PI macros published by the working group. Note that other PI macro documents may exist, and it should be possible for an implementor to populate the protocolDirTable without the use of the PI Macro document [RFC2896].
ワーキンググループによって発表された非ベース層PIマクロのリストについては、RMONプロトコル識別子マクロドキュメント[RFC2896]を参照してください。他のPIマクロ文書が存在してもよいことに留意されたい、および実装は、PIマクロドキュメント[RFC2896]を使用することなくprotocolDirTableを移入することが可能であるべきです。
The first layer encapsulation is called the base identifier and it contains optional protocol-function information and the base layer (e.g. MAC layer) enumeration value used in this protocol identifier.
第一の層のカプセル化は、ベース識別子と呼ばれ、オプションのプロトコル機能情報と、このプロトコル識別子で使用されるベース層（例えばMAC層）列挙値が含まれます。
The base identifier is encoded as four octets as shown in figure 2.
図2に示すように、ベース識別子は4つのオクテットとして符号化されます。
Fig. 2
base-identifier format
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
The first octet ('f') is the special function code, found in table 4.1. The next two octets ('op1' and 'op2') are operands for the indicated function. If not used, an operand must be set to zero. The last octet, 'm', is the enumerated value for a particular base layer encapsulation, found in table 4.2. All four octets are encoded in network-byte-order.
最初のオクテット（「F」）は表4.1に見られる、特別な機能コードです。次の2つのオクテット（「OP-1」および「OP2」）が示されている関数のオペランドです。使用されていない場合は、オペランドがゼロに設定する必要があります。最後のオクテット、「m」は、表4.2に見られる特定のベース層カプセル化のために列挙された値です。すべての4つのオクテットは、ネットワークバイトオーダーでエンコードされています。
The base layer identifier contains information about any special functions to perform during collections of this protocol, as well as the base layer encapsulation identifier.
ベースレイヤ識別子は、このプロトコル、ならびにベース層カプセル化識別子のコレクション中に実行するために特別な機能についての情報を含みます。
The first three octets of the identifier contain the function code and two optional operands. The fourth octet contains the particular base layer encapsulation used in this protocol (fig. 2).
識別子の最初の3つのオクテットは、機能コードと2つのオプションのオペランドを含みます。 4番目のオクテットは、このプロトコル（図2）で使用される特定のベース層のカプセル化が含ま。
Table 4.1 Assigned Protocol Identifier Functions
-------------------------------------------------
Function ID Param1 Param2
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)
If the function ID field (1st octet) is equal to zero, the 'op1' and 'op2' fields (2nd and 3rd octets) must also be equal to zero. This special value indicates that no functions are applied to the protocol identifier encoded in the remaining octets. The identifier represents a normal protocol encapsulation.
機能IDフィールド（第1オクテット）がゼロに等しい場合、「OP1」と「OP2」フィールド（2番目と3番目のオクテット）もゼロに等しくなければなりません。この特別な値は、何の機能が残っているオクテットで符号化されたプロトコル識別子に適用されていないことを示しています。識別子は、通常のプロトコルカプセル化を表します。
The wildcard function (function-ID = 1), is used to aggregate counters, by using a single protocol value to indicate potentially many base layer encapsulations of a particular network layer protocol. A protocolDirEntry of this type will match any base-layer encapsulation of the same network layer protocol.
ワイルドカードの機能（関数-ID = 1）は、特定のネットワーク層プロトコルの潜在的に多くのベース層のカプセル化を示すために、単一のプロトコルの値を用いて、カウンタを集約するために使用されます。このタイプのprotocolDirEntryは同一のネットワーク層プロトコルのいずれかのベースレイヤのカプセル化と一致します。
The 'op1' field (2nd octet) is not used and MUST be set to zero.
「OP1」フィールド（2オクテット）が使用されず、ゼロに設定しなければなりません。
The 'op2' field (3rd octet) is not used and MUST be set to zero.
「OP2」フィールド（第3オクテット）が使用されず、ゼロに設定しなければなりません。
Each wildcard protocol identifier MUST be defined in terms of a 'base encapsulation'. This SHOULD be as 'standard' as possible for interoperability purposes. The lowest possible base layer value SHOULD be chosen. So, if an encapsulation over 'ether2' is permitted, than this should be used as the base encapsulation. If not then an encapsulation over LLC should be used, if permitted. And so on for each of the defined base layers.
各ワイルドカードプロトコル識別子は「ベースカプセル化」の観点から定義されなければなりません。これは、相互運用性のために、可能な限り「標準」であるべきです。可能な限り低いベース層の値が選択されるべきです。 「ether2」オーバーカプセル化が許可されているのであれば、これよりもベースのカプセル化として使用する必要があります。許可されている場合、その後LLC超えるカプセル化は、使用すべきでない場合。そしてように定義された基本層のそれぞれのために。
It should be noted that an agent does not have to support the non-wildcard protocol identifier over the same base layer. For instance a token ring only device would not normally support IP over the ether2 base layer. Nevertheless it should use the ether2 base layer for defining the wildcard IP encapsulation. The agent MAY also support counting some or all of the individual encapsulations for the same protocols, in addition to wildcard counting. Note that the RMON-2 MIB [RFC2021] does not require that agents maintain counters for multiple encapsulations of the same protocol. It is an implementation-specific matter as to how an agent determines which protocol combinations to allow in the protocolDirTable at any given time.
エージェントが同一のベース層の上に非ワイルドカードプロトコル識別子をサポートする必要はないことに留意すべきです。例えばトークンリングのみデバイスは、通常ether2ベース層上にIPをサポートしないであろう。それにもかかわらず、ワイルドカードのIPカプセル化を定義するためのether2ベース層を使用する必要があります。エージェントは、ワイルドカードカウンティングに加えて、同じプロトコルに対して個別のカプセル化の一部または全部を数えるサポートするかもしれません。 RMON-2 MIB [RFC2021]はエージェントが同じプロトコルの複数のカプセル化のためのカウンタを維持することを必要としないことに留意されたいです。これは、薬剤が組み合わせが任意の時点でprotocolDirTableに許可するプロトコルを判断する方法として、実装固有の問題です。
The base layer is mandatory, and defines the base encapsulation of the packet and any special functions for this identifier.
ベース層は必須であり、この識別子のためのパケットのベースカプセル化し、任意の特別な機能を定義しています。
There are no suggested protocolDirParameters bits for the base layer.
ベース層のための提案protocolDirParametersビットはありません。
The suggested value for the ProtocolDirDescr field for the base layer is given by the corresponding "Name" field in the table 4.2 below. However, implementations are only required to use the appropriate integer identifier values.
ベース層用ProtocolDirDescrフィールドの推奨値を以下の表4.2に対応する「名前」フィールドで与えられます。しかし、実装は、適切な整数の識別子の値を使用する必要があります。
For most base layer protocols, the protocolDirType field should contain bits set for the 'hasChildren(0)' and ' addressRecognitionCapable(1)' attributes. However, the special 'ianaAssigned' base layer should have no parameter or attribute bits set.
最も基本レイヤプロトコルのため、protocolDirTypeフィールドが「hasChildren（0）」と「addressRecognitionCapable（1）」属性に設定されたビットを含むべきです。しかし、特別な「ianaAssigned」ベース層には、パラメータを持っていないか、設定されたビットを属性する必要があります。
By design, only 255 different base layer encapsulations are supported. There are five base encapsulation values defined at this time. Very few new base encapsulations (e.g. for new media types) are expected to be added over time.
設計では、唯一の255異なるベース層カプセル化がサポートされています。この時点で定義されている5つのベースカプセル化の値があります。 （例えば、新しいメディアタイプの）非常に少数の新しいベースのカプセル化は、時間にわたって添加されることが期待されます。
Table 4.2 Base Layer Encoding Values
--------------------------------------
Name ID
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
-- Ether2 Encapsulation
- Ether2カプセル化
ether2 PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "DIX Ethernet, also called Ethernet-II." CHILDREN "The Ethernet-II type field is used to select child protocols. This is a 16-bit field. Child protocols are deemed to start at the first octet after this type field.
ether2 PROTOCOL識別子パラメータは{} {hasChildren（0）、addressRecognitionCapable（1）}説明 "DIXイーサネット（登録商標）は、とも呼ばれるイーサネット（登録商標）II" をATTRIBUTESイーサネットIIタイプフィールドは、子プロトコルを選択するために使用された子どもたちは、」これは16ビットのフィールドである。子供のプロトコルは、このタイプフィールドの後の最初のオクテットで開始することとみなされます。
Children of this protocol are encoded as [ 0.0.0.1 ], the
protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
'a' and 'b' are the network byte order encodings of the high
order byte and low order byte of the Ethernet-II type value.
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
例えば、プロトコルディレクトリのフラグメント値：0.0.0.1.0.0.8.0は、IP ether2中に封入定義します。
Children of ether2 are named as 'ether2' followed by the type field value in hexadecimal. The above example would be declared as: ether2 0x0800" ADDRESS-FORMAT "Ethernet addresses are 6 octets in network order." DECODING "Only type values greater than 1500 decimal indicate Ethernet-II frames; lower values indicate 802.3 encapsulation (see below)." REFERENCE "The authoritative list of Ether Type values is identified by the URL:
ether2の子供たちは、16進数でタイプフィールド値が続く「ether2」と命名されています。イーサネットアドレスはネットワークオーダーで6つのオクテットであるether2 0x0800" でADDRESS-FORMAT 『のみタイプが大きい1500小数がイーサネットIIのフレームを示す値』復号」;上記の例では、として宣言されるであろう。 。低い値は802.3カプセル化（下記参照）「REFERENCE」URLで識別されたイーサタイプ値の正式なリストを示します。
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }
-- LLC Encapsulation
- LLCカプセル化
llc PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "The Logical Link Control (LLC) 802.2 protocol." CHILDREN "The LLC Source Service Access Point (SSAP) and Destination Service Access Point (DSAP) are used to select child protocols. Each of these is one octet long, although the least significant bit is a control bit and should be masked out in most situations. Typically SSAP and DSAP (once masked) are the same for a given protocol - each end implicitly knows whether it is the server or client in a client/server protocol. This is only a convention, however, and it is possible for them to be different. The SSAP is matched against child protocols first. If none is found then the DSAP is matched instead. The child protocol is deemed to start at the first octet after the LLC control field(s).
LLCプロトコル識別子パラメータ{} {hasChildren（0）、addressRecognitionCapable（1）}説明 "論理リンク制御（LLC）802.2プロトコル。" 属性CHILDREN「LLCソース・サービス・アクセス・ポイント（SSAP）と宛先サービスアクセスポイント（DSAP）は、子プロトコルを選択するために使用されている。最下位ビットが制御ビットであり、ほとんどの中でマスクされるべきであるが、これらのそれぞれは、1つのオクテットの長さであります。状況通常、SSAPとDSAP（一度にマスクは）与えられたプロトコルで同じです - それぞれの端部には、暗黙のうちに、それは、クライアント/サーバプロトコルでサーバまたはクライアントであるかを知っているこれは、しかし、唯一の大会であり、それは彼らのために可能です。異なるように。SSAPは、最初の子プロトコルと照合される。いずれもその後DSAP代わりに一致さ見つからない場合、子プロトコルがLLC制御フィールド（複数可）の後の最初のオクテットで開始すると考えられます。
Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
the SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of:
0.0.0.2.0.0.0.240
defines NetBios over LLC.
LLC上でNetBIOSを定義します。
Children are named as 'llc' followed by the SAP value in hexadecimal. So the above example would have been named: llc 0xf0" ADDRESS-FORMAT "The address consists of 6 octets of MAC address in network order. Source routing bits should be stripped out of the address if present." DECODING "Notice that LLC has a variable length protocol header; there are always three octets (DSAP, SSAP, control). Depending on the value of the control bits in the DSAP, SSAP and control fields there may be an additional octet of control information.
子供たちは、16進数でSAP値に続く「LLC」と命名されています。したがって、上記の例では、命名されているでしょう：LLC 0xF0" がADDRESS-FORMAT「アドレスはネットワーク順にMACアドレスの6つのオクテットで構成されています。存在する場合、ソースルーティングビットがアドレスのうち剥離すべきことは、LLCは、可変長プロトコルヘッダを持つ注目「復号します」。 3つのオクテット（DSAP、SSAP、コントロール）は常にあります。 DSAP、SSAP及び制御フィールドにおける制御ビットの値に応じてそこ制御情報の追加のオクテットであってもよいです。
LLC can be present on several different media. For 802.3 and 802.5 its presence is mandated (but see ether2 and raw 802.3 encapsulations). For 802.5 there is no other link layer protocol.
LLCは、いくつかの異なるメディアに存在することができます。 802.3と802.5のためにその存在が義務付けられた（しかしether2と生802.3カプセル化を参照）されます。 802.5のために他のリンク層プロトコルはありません。
Notice also that the raw802.3 link layer protocol may take
precedence over this one in a protocol specific manner such that
it may not be possible to utilize all LSAP values if raw802.3 is
also present."
REFERENCE
"The authoritative list of LLC LSAP values is controlled by the
IEEE Registration Authority:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 2 }
-- SNAP over LLC (Organizationally Unique Identifier, OUI=000) -- Encapsulation
- LLC上SNAP（組織固有識別子、OUI = 000） - カプセル化
snap PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES {
PROTOCOL識別子パラメータをスナップ{}は、{ATTRIBUTES
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC
protocol, allowing Ethernet-II protocols to be run over a media
restricted to LLC."
CHILDREN
"Children of 'snap' are identified by Ethernet-II type values;
the SNAP Protocol Identifier field (PID) is used to select the
appropriate child. The entire SNAP protocol header is consumed;
the child protocol is assumed to start at the next octet after
the PID.
Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b' are the high order byte and low order byte of the Ethernet-II type value.
「スナップ」の子供は、[0.0.ab]「A」と「B」はEthernet-の上位バイト及び下位バイトである場合、続いて「スナップ」するためのプロトコル識別子は、[0.0.0.3]として符号化されますII型の値。
For example, a protocolDirID-fragment value of: 0.0.0.3.0.0.8.0
例えば、プロトコルディレクトリフラグメント値：0.0.0.3.0.0.8.0
defines the IP/SNAP protocol.
IP / SNAPプロトコルを定義します。
Children of this protocol are named 'snap' followed by the Ethernet-II type value in hexadecimal. The above example would be named:
このプロトコルの子供は、16進数でイーサネットII型の値が続く「スナップ」と命名されています。上記の例では、次のような名前になります
snap 0x0800"
ADDRESS-FORMAT
"The address format for SNAP is the same as that for LLC"
DECODING
"SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA
and a single control octet will be present. There are then three
octets of Organizationally Unique Identifier (OUI) and two octets
of PID. For this encapsulation the OUI must be 0x000000 (see
'vsnap' below for non-zero OUIs)."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 3 }
-- Vendor SNAP over LLC (OUI != 000) Encapsulation
- LLC超えるベンダーSNAP（！YES = 000）カプセル化
vsnap PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { hasChildren(0), addressRecognitionCapable(1) } DESCRIPTION "This pseudo-protocol handles all SNAP packets which do not have a zero OUI. See 'snap' above for details of those that have a zero OUI value." CHILDREN "Children of 'vsnap' are selected by the 3 octet OUI; the PID is not parsed; child protocols are deemed to start with the first octet of the SNAP PID field, and continue to the end of the packet. Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol identifier for 'vsnap', followed by [ 0.a.b.c ] where 'a', 'b' and 'c' are the 3 octets of the OUI field in network byte order.
vsnap PROTOCOL識別子パラメータは{} {hasChildren（0）、addressRecognitionCapable（1）} DESCRIPTION「この疑似プロトコルはゼロOUIを持たないすべてのSNAPパケットを処理ATTRIBUTES。ゼロを有するものの詳細については、上記 『スナップ』を参照しますOUI値。」 CHILDREN「『vsnap』は子供が3オクテットOUIによって選択され、PIDが解析されません。子プロトコルがSNAP PIDフィールドの最初のオクテットで開始し、パケットの終わりまで継続すると認められる「vsnapの子供たち。 A 'ここで、[0.abc]続いて、 『vsnap'はのためのプロトコル識別子は、[0.0.0.4]として符号化される』、 『B』及び 『C』がネットワークバイト順にOUIフィールドの3つのオクテットです。
For example, a protocolDirID-fragment value of:
0.0.0.4.0.8.0.7 defines the Apple-specific set of protocols
over vsnap.
Children are named as 'vsnap <OUI>', where the '<OUI>' field is represented as 3 octets in hexadecimal notation.
子供は次のように命名されている「vsnap <OUI>」、「<OUI>」フィールドが16進表記で3つのオクテットとして表現されます。
So the above example would be named:
'vsnap 0x080007'"
ADDRESS-FORMAT
"The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details."
DECODING
"Same as for 'snap' except the OUI is non-zero and the SNAP
Protocol Identifier is not parsed."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 4 }
-- IANA Assigned Protocols
- IANA割り当てプロトコル
ianaAssigned PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { } DESCRIPTION "This branch contains protocols which do not conform easily to the hierarchical format utilized in the other link layer branches. Usually, such a protocol 'almost' conforms to a particular 'well-known' identifier format, but additional criteria are used (e.g. configuration-based), making protocol identification difficult or impossible by examination of appropriate network traffic (preventing the any 'well-known' protocol-identifier macro from being used).
ianaAssigned PROTOCOL識別子パラメータは{} {} DESCRIPTION属性「このブランチは他のリンク層ブランチで利用階層形式に容易に適合していないプロトコルが含まれています。通常、このようなプロトコルは、「ほぼ 『周知』の特定に準拠します識別子フォーマットが、追加の基準が適切なネットワークトラフィックの検査により、プロトコル識別が困難または不可能に、（例えば、構成がベース）が使用される（使用されてから任意「周知」プロトコル識別子マクロを防止します）。
Sometimes well-known protocols are simply remapped to a different
port number by one or more venders (e.g. SNMP). These protocols
can be identified with the 'limited extensibility' feature of the
protocolDirTable, and do not need special IANA assignments.
A centrally located list of these enumerated protocols must be maintained by IANA to insure interoperability. (See section 2.3 for details on the document update procedure.) Support for new link-layers will be added explicitly, and only protocols which cannot possibly be represented in a better way will be considered as 'ianaAssigned' protocols.
これらの列挙されたプロトコルの中心部に位置するリストは、相互運用性を保証するために、IANAによって維持されなければなりません。 （文書更新手順の詳細については、セクション2.3を参照してください。）新しいリンク・レイヤのサポートが明示的に追加されます、そしておそらくより良い方法で表現することができない唯一のプロトコルが「ianaAssignedのプロトコールとさせていただきます。
IANA protocols are identified by the base-layer-selector value [ 0.0.0.5 ], followed by the four octets [ 0.0.a.b ] of the integer value corresponding to the particular IANA protocol.
IANAプロトコルは、特定のIANAプロトコルに対応する整数値の4つのオクテット[0.0.a.b]続いて、ベースレイヤセレクタ値[0.0.0.5]によって識別されます。
Do not create children of this protocol unless you are sure that they cannot be handled by the more conventional link layers above." CHILDREN "Children of this protocol are identified by implementation-specific means, described (as best as possible) in the 'DECODING' clause within the protocol-variant-identifier macro for each enumerated protocol.
あなたは、彼らが上記より、従来のリンクレイヤで扱うことができないことが確実でない限り、このプロトコルの子供を作成しないでください。「CHILDREN」このプロトコルの子供たちは、実装固有の手段によって識別され、「復号化する際に（可能な限り最善のように）説明各列挙プロトコルのプロトコル・バリアント識別子マクロ内 '句。
Children of this protocol are encoded as [ 0.0.0.5 ], the protocol identifier for 'ianaAssigned', followed by [ 0.0.a.b ] where 'a', 'b' are the network byte order encodings of the high order byte and low order byte of the enumeration value for the particular IANA assigned protocol.
このプロトコルの子供[0.0.0.5]として符号化される、[0.0.ab]ここで、「A」、「B」が続く「ianaAssigned」のプロトコル識別子は、上位バイトと下位のネットワークバイト順エンコーディングされ特定のIANA割り当てプロトコルの列挙値のバイト。
For example, a protocolDirID-fragment value of: 0.0.0.5.0.0.0.1
例えば、プロトコルディレクトリフラグメント値：0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3
802.3に直接カプセル化されたIPXプロトコルを定義
Children are named 'ianaAssigned' followed by the numeric value of the particular IANA assigned protocol. The above example would be named:
子供の名前は「ianaAssigned」特定のIANA割り当てのプロトコルの数値が続きます。上記の例では、次のような名前になります
'ianaAssigned 1' "
DECODING
"The 'ianaAssigned' base layer is a pseudo-protocol and is not
decoded."
REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER macros for information
on each child of the IANA assigned protocol."
::= { 5 }
-- The following protocol-variant-identifier macro declarations are -- used to identify the RMONMIB IANA assigned protocols in a -- proprietary way, by simple enumeration.
- 次のプロトコルバリアント識別子マクロ宣言がされている - 単純な列挙することにより、独自の方法 - でRMONMIB IANA割り当てプロトコルを識別するために使用されます。
ipxOverRaw8023 PROTOCOL-IDENTIFIER VARIANT-OF ipx PARAMETERS { } ATTRIBUTES { } DESCRIPTION "This pseudo-protocol describes an encapsulation of IPX over 802.3, without a type field.
ipxOverRaw8023 PROTOCOL識別子VARIANT-OF IPXパラメータ{} ATTRIBUTES {}「この疑似プロトコルは、タイプフィールドなし、802.3上IPXのカプセル化を記載しています。
Refer to the macro for IPX for additional information about this
protocol."
DECODING
"Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document."
::= {
ianaAssigned 1, -- [0.0.0.1]
802-1Q 0x05000001 -- 1Q_IANA [5.0.0.1]
}
Encapsulation layers are positioned between the base layer and the network layer. It is an implementation-specific matter whether a probe exposes all such encapsulations in its RMON-2 Protocol Directory.
封入層は、ベース層とネットワーク層との間に配置されています。これは、プローブがそのRMON-2プロトコルディレクトリ内のすべてのそのようなカプセル化を公開するかどうかインプリメンテーションごとの問題です。
RMON probes may encounter 'VLAN tagged' frames on monitored links. The IEEE Virtual LAN (VLAN) encapsulation standards [IEEE802.1Q] and [IEEE802.1D-1998], define an encapsulation layer inserted after the MAC layer and before the network layer. This section defines a PI macro which supports most (but not all) features of that encapsulation layer.
RMONプローブは、監視対象のリンク上のフレームを「VLANはタグ付け」が発生することがあります。 IEEE仮想LAN（VLAN）カプセル化規格[IEEE802.1Q]と[IEEE802.1D-1998]は、MAC層の後、ネットワーク層の前に挿入された封止層を定義します。このセクションでは、封入層の（すべてではないが）ほとんどの機能をサポートしているPIマクロを定義します。
Most notably, the RMON PI macro '802-1Q' does not expose the Token Ring Encapsulation (TR-encaps) bit in the TCI portion of the VLAN header. It is an implementation specific matter whether an RMON probe converts LLC-Token Ring (LLC-TR) formatted frames to LLC-Native (LLC-N) format, for the purpose of RMON collection.
最も顕著には、RMON PIマクロ「802-1Q」はVLANヘッダのTCI部におけるトークンリングカプセル化（TR-ENCAPS）ビットを公開しません。 RMONプローブはRMON収集の目的のために、LLC-ネイティブ（LLC-N）形式にLLC-トークンリング（LLC-TR）フォーマットされたフレームに変換するかどうか、実装固有の問題です。
In order to support the Ethernet and LLC-N formats in the most efficient manner, and still maintain alignment with the RMON-2 ' collapsed' base layer approach (i.e., support for snap and vsnap), the children of 802dot1Q are encoded a little differently than the children of other base layer identifiers.
RMON-2との位置合わせを最も効率的な方法でイーサネットおよびLLC-Nフォーマットをサポートし、まだ維持するために、ベース層アプローチを「崩壊」（すなわち、スナップおよびvsnapのサポート）は、802dot1Qの子供は少し符号化されます異なった他のベース層識別子の子供たちよりも。
802-1Q PROTOCOL-IDENTIFIER PARAMETERS { } ATTRIBUTES { hasChildren(0) } DESCRIPTION "IEEE 802.1Q VLAN Encapsulation header.
802-1Q PROTOCOL識別子パラメータ{} {hasChildren（0）} DESCRIPTION「IEEE 802.1Q VLANカプセル化ヘッダ属性。
Note that the specific encoding of the TPID field is not
explicitly identified by this PI macro. Ethernet-encoded vs.
SNAP-encoded TPID fields can be identified by the ifType of the
data source for a particular RMON collection, since the SNAP-
encoded format is used exclusively on Token Ring and FDDI media.
Also, no information held in the TCI field (including the TR-
encap bit) is identified in protocolDirID strings utilizing this
PI macro."
CHILDREN "The first byte of the 4-byte child identifier is used to distinguish the particular base encoding that follows the 802.1Q header. The remaining three bytes are used exactly as defined by the indicated base layer encoding.
CHILDREN「4バイトの子識別子の最初のバイトは、802.1Qヘッダーに続く特定のベースエンコーディングを区別するために使用される。示されたベースレイヤ符号化によって定義されるように、残りの3つのバイトを正確に使用されています。
In order to simplify the child encoding for the most common cases, the 'ether2' and 'snap' base layers are combined into a single identifier, with a value of zero. The other base layers are encoded with values taken from Table 4.2.
最も一般的なケースの子符号化を簡単にするために、「ether2」と「スナップ」ベース層はゼロの値を持つ、単一の識別子に結合されます。他のベース層は、表4.2から採取された値を用いて符号化されます。
802-1Q Base ID Values
---------------------
Base Table 4.2 Base-ID
Layer Encoding Encoding
-------------------------------------
ether2 1 0
llc 2 2
snap 3 0
vsnap 4 4
ianaAssigned 5 5
The generic child layer-identifier format is shown below:
一般的な子層識別子の形式を以下に示します。
802-1Q Child Layer-Identifier Format
+--------+--------+--------+--------+
| Base | |
| ID | base-specific format |
| | |
+--------+--------+--------+--------+
| 1 | 3 | octet count
Base ID == 0
------------
For payloads encoded with either the Ethernet or LLC/SNAP headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'ether2' or 'snap' base
layers.
Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q' followed by [ 0.0.a.b ] where 'a' and 'b' are the network byte order encodings of the high order byte and low order byte of the Ethernet-II type value.
子供たちは、[0.0.129.0]と[0.0.ab]「A」および「B」は上位バイトの下位バイトのネットワークバイト順の符号化である場合、続いて「802-1Q」のプロトコル識別子をエンコードされイーサネットIIタイプの値。
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.0.0.8.0 defines IP, VLAN-encapsulated in ether2.
例えば、プロトコルディレクトリのフラグメント値：0.0.0.1.0.0.129.0.0.0.8.0はether2にVLANカプセル化、IPを定義します。
Children of this format are named as '802-1Q' followed by the type field value in hexadecimal.
この形式の子供たちは、16進数でタイプフィールド値が続く「802-1Q」と命名されています。
So the above example would be declared as: '802-1Q 0x0800'.
「802-1Qの0x0800で」：だから、上記の例は次のように宣言されます。
Base ID == 2
------------
For payloads encoded with a (non-SNAP) LLC header following the
VLAN header, children of this protocol are identified exactly as
described for the 'llc' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier component for 802.1Q, followed by [ 2.0.0.a ] where 'a' is the SAP value which maps to the child protocol. For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.2.0.0.240
子供は[2.0.0.a]「」の子プロトコルにマッピングSAP値であり、続いて、802.1Qのために[0.0.129.0]、プロトコル識別子構成要素として符号化されます。例えば、プロトコルディレクトリフラグメント値：0.0.0.1.0.0.129.0.2.0.0.240
defines NetBios, VLAN-encapsulated over LLC.
NetBiosの、VLANカプセル化LLCオーバーを定義します。
Children are named as '802-1Q' followed by the SAP value in hexadecimal, with the leading octet set to the value 2.
子どもたちは、値2に設定有数のオクテットで、16進数でSAP値に続く「802-1Q」と命名されています。
So the above example would have been named: '802-1Q 0x020000f0'
したがって、上記の例では、命名されているでしょう：「802-1Q 0x020000f0」
Base ID == 4
------------
For payloads encoded with LLC/SNAP (non-zero OUI) headers
following the VLAN header, children of this protocol are
identified exactly as described for the 'vsnap' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q', followed by [ 4.a.b.c ] where 'a', 'b' and 'c' are the 3 octets of the OUI field in network byte order.
子供は、[0.0.129.0]としてエンコードされ、「A」、「B」及び「C」がネットワークバイトのOUIフィールドの3つのオクテットである[4.abc]続い「802-1Q」のためのプロトコル識別子注文。
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.4.8.0.7 defines the Apple-specific set of protocols, VLAN-encapsulated over vsnap.
例えば、プロトコルディレクトリのフラグメント値：0.0.0.1.0.0.129.0.4.8.0.7、プロトコル、VLANカプセル化vsnap上のアップル固有のセットを定義します。
Children are named as '802-1Q' followed by the <OUI> value, which is represented as 3 octets in hexadecimal notation, with a leading octet set to the value 4.
子供は値4に設定つながるオクテットと、16進数で3つのオクテットとして表され、<OUI>値、続いて「802-1Q」と命名されています。
So the above example would be named: '802-1Q 0x04080007'.
したがって、上記の例では、次のような名前になります「802-1Q 0x04080007」。
Base ID == 5
------------
For payloads which can only be identified as 'ianaAssigned'
protocols, children of this protocol are identified exactly as
described for the 'ianaAssigned' base layer.
Children are encoded as [ 0.0.129.0 ], the protocol identifier for '802-1Q', followed by [ 5.0.a.b ] where 'a' and 'b' are the network byte order encodings of the high order byte and low order byte of the enumeration value for the particular IANA assigned protocol.
子供たちは、[0.0.129.0]と[5.0.ab]「A」および「B」は上位バイト及び下位バイトのネットワークバイト順の符号化である場合、続いて「802-1Q」のためのプロトコル識別子をエンコードされ特定のIANA割り当てプロトコルの列挙値。
For example, a protocolDirID-fragment value of: 0.0.0.1.0.0.129.0.5.0.0.0.1
例えば、プロトコルディレクトリフラグメント値：0.0.0.1.0.0.129.0.5.0.0.0.1
defines the IPX protocol, VLAN-encapsulated directly in 802.3
802.3に直接VLANカプセル化、IPXプロトコルを定義
Children are named '802-1Q' followed by the numeric value of the particular IANA assigned protocol, with a leading octet set to the value of 5.
子供たちは5の値に設定有数のオクテットで、特定のIANA割り当てのプロトコルの数値が続く「802-1Q」という名前されています。
Children are named '802-1Q' followed by the hexadecimal encoding of the child identifier. The above example would be named:
子供の名前は「802-1Q」子識別子を16進エンコーディングが続きます。上記の例では、次のような名前になります
'802-1Q 0x05000001'. "
DECODING
"VLAN headers and tagged frame structure are defined in
[IEEE802.1Q]."
REFERENCE
"The 802.1Q Protocol is defined in the Draft Standard for Virtual
Bridged Local Area Networks [IEEE802.1Q]."
::= {
ether2 0x8100 -- Ethernet or SNAP encoding of TPID
-- snap 0x8100 ** excluded to reduce PD size & complexity
}
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 document was produced by the IETF RMONMIB Working Group.
このドキュメントはIETF RMONMIBワーキンググループによって作成されました。
The authors wish to thank the following people for their contributions to this document:
作者はこのドキュメントへの貢献のために、以下の人々に感謝したいです。
Anil Singhal
Frontier Software Development, Inc.
Jeanne Haney Bay Networks
ジーン・ハニーベイネットワーク
Dan Hansen Network General Corp.
ダン・ハンセンネットワークジェネラルコーポレーション
Special thanks are in order to the following people for writing RMON PI macro compilers, and improving the specification of the PI macro language:
特別な感謝は、RMON PIマクロコンパイラを書いて、PIマクロ言語の仕様を向上させるため、次の人への順序であります：
David Perkins
DeskTalk Systems, Inc.
Skip Koppenhaver Technically Elite, Inc.
Koppenhaver技術的エリート社をスキップ
[AF-LANE-0021.000] LAN Emulation Sub-working Group, B. Ellington, "LAN Emulation over ATM - Version 1.0", AF-LANE-0021.000, ATM Forum, IBM, January 1995.
"ATM上のLANエミュレーション - バージョン1.0" [AF-LANE-0021.000] LANエミュレーションサブワーキンググループ、B.エリントン、AF-LANE-0021.000、ATMフォーラム、IBM、1995年1月。
[AF-NM-TEST-0080.000] Network Management Sub-working Group, Test Sub-working Group, A. Bierman, "Remote Monitoring MIB Extensions for ATM Networks", AF- NM-TEST-0080.000, ATM Forum, Cisco Systems, February 1997.
[AF-NM-TEST-0080.000]ネットワーク管理サブワーキンググループ、テストサブワーキンググループ、A. Bierman、 "ATMネットワークのリモートモニタリングMIB拡張機能"、AF-NM-TEST-0080.000、ATMフォーラム、シスコシステムズ、 1997年2月。
[IEEE802.1D-1998] LAN MAN Standards Committee of the IEEE Computer Society, "Information technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks -- Common specification -- Part 3: Media Access Control (MAC) Bridges", ISO/IEC Final DIS 15802-3 (IEEE P802.1D/D17) Institute of Electrical and Electronics Engineers, Inc., May 1998.
IEEEコンピュータ学会の[IEEE802.1D-1998] LAN MAN標準委員会、「情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 共通仕様 - 第3部：メディアアクセス制御（MAC）橋」、ISO / IEC DIS 15802-3決勝（IEEE P802.1D / D17）電気電子技術株式会社、1998年5月の研究所。
[IEEE802.1Q] LAN MAN Standards Committee of the IEEE Computer Society, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", Draft Standard P802.1Q/D11, Institute of Electrical and Electronics Engineers, Inc., July 1998.
[IEEE802.1Q] IEEEコンピュータ社会のLAN MAN標準委員会、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：仮想ブリッジローカルエリアネットワーク」、ドラフト標準P802.1Q / D11、電気電子技術者協会、 1998年7月。
[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月。
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[RFC1483] Heinanen、J.、RFC 1483、1993年7月 "ATMアダプテーションレイヤ5の上にマルチプロトコルカプセル化"。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[RFC1901]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "コミュニティベースのSNMPv2の概要"、RFC 1901、1996年1月。
[RFC1902] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
[RFC1902]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡単なネットワーク管理プロトコル（SNMPv2）のバージョン2のための経営情報の構造"、RFC 1902、1996年1月。
[RFC1903] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[RFC1903]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、RFC 1903、1996年1月 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のためのテキストの表記法"。
[RFC1904] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[RFC1904]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、RFC 1904、1996年1月 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための順応文"。
[RFC1905] 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]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、1996年1月。
[RFC1906] 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]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、「、RFC 1906、 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための交通マッピング"、1996年1月。
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)", RFC 2021, January 1997.
[RFC2021] Waldbusser、S.、 "リモートネットワーク監視MIB（RMON-2）"、RFC 2021、1997年1月。
[RFC2074] Bierman, A. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifiers", RFC 2074, January 1997.
[RFC2074] Bierman、A.とR. Iddon、 "リモートネットワーク監視MIBプロトコル識別子"、RFC 2074、1997年1月。
[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月。
[RFC2233] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB Using SMIv2", RFC 2233, November 1997.
"SMIv2のを使用して、インターフェイスグループMIB" [RFC2233] McCloghrie、K.およびF. Kastenholzと、RFC 2233、1997年11月。
[RFC2271] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998.
[RFC2271]ハリントン、D.、PresuhnとR.とB. Wijnen、 "SNMP管理フレームワークを記述するためのアーキテクチャ"、RFC 2271、1998年1月。
[RFC2272] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998.
[RFC2272]ケース、J.、ハリントンD.、Presuhn R.とB. Wijnenの、 "メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のための派遣"、RFC 2272、1998年1月。
[RFC2273] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998.
[RFC2273]レビ、D.、マイヤー、P.とB.スチュワート、 "SNMPv3のアプリケーション"、RFC 2273、1998年1月。
[RFC2274] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998.
、RFC 2274、1998年1月 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）" [RFC2274]ブルーメンソール、U.とB. Wijnenの、。
[RFC2275] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998.
[RFC2275] Wijnenの、B.、Presuhn、R.とK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（VACM）（SNMP）"、RFC 2275、1998年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月。
[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月。
[RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifier Macros", RFC 2896, August 2000.
[RFC2896] Bierman、A.、ブッチ、C.とR. Iddon、 "リモートネットワーク監視MIBプロトコル識別子マクロ"、RFC 2896、2000年8月。
The protocols identified in this specification are almost entirely defined in external documents. In some rare cases, an arbitrary Protocol Identifier assignment must be made in order to support a particular protocol in the RMON-2 protocolDirTable. Protocol Identifier macros for such protocols will be defined under the ' ianaAssigned' base layer (see sections 3. and 4.2).
この仕様で特定されたプロトコルは、ほぼ完全に外部の文書で定義されています。いくつかのまれなケースでは、任意のプロトコル識別子の割り当ては、RMON-2 protocolDirTableで特定のプロトコルをサポートするためになされなければなりません。そのようなプロトコルのプロトコル識別子マクロ「はianaAssigned」ベース層（セクション3および4.2を参照）の下で定義されます。
At this time, only one protocol is defined under the ianaAssigned base layer, called 'ipxOverRaw8023' (see section 4.2).
このとき、一つだけのプロトコルが「ipxOverRaw8023」と呼ばれるianaAssignedベース層、下に定義される（セクション4.2参照）。
This document discusses the syntax and semantics of textual descriptions of networking protocols, not the definition of any networking behavior. As such, no security considerations are raised by this memo.
この文書では、構文とネットワークプロトコルのテキスト記述の意味ではなく、任意のネットワークの振る舞いの定義について説明します。そのように、何のセキュリティに関する考慮事項は、このメモで提起されていません。
Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive 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 Drive 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
Robin Iddon c/o 3Com Inc. Blackfriars House 40/50 Blackfrias Street Edinburgh, EH1 1NE, UK
/ Oの3Com社ブラックフライアーズハウス40/50 Blackfriasストリートエディンバラ、EH1 1NE、英国CロビンIddon
Phone: +44 131.558.3888 EMail: None
電話：+44 131.558.3888 Eメール：なし
Appendix A: Changes since RFC 2074
付録A：RFC 2074からの変更点
The differences between RFC 2074 and this document are:
RFC 2074と本書との違いは以下のとおりです。
- RFC 2074 has been split into a reference document (this document) on the standards track and an informational document [RFC2896], in order to remove most protocol identifier macros out of the standards track document. - Administrative updates; added an author, added copyrights, updated SNMP framework boilerplate; - Updated overview section. - Section 2.1 MUST, SHOULD text added per template - Section 2.1 added some new terms - parent protocol - child protocol - protocol encapsulation tree - Added section 2.3 about splitting into 2 documents:
- RFC 2074の標準トラック文書のうち最もプロトコル識別子マクロを除去するために、標準化過程および情報文書[RFC2896]に基準原稿（本文書）に分割されています。 - 行政のアップデート。 SNMPフレームワークの定型を更新し、著作権を追加、著者を追加しました。 - 概要セクションを更新しました。 - セクション2.1 MUSTは、テンプレートごとに追加されたテキスト必要があります - セクション2.1には、いくつかの新しい用語を追加しました - 親プロトコル - 子プロトコル - プロトコルカプセル化木 - を追加しました2つの文書に分割に関するセクション2.3：
"Relationship to the RMON Protocol Identifier Macros Document" - Added section 2.4 "Relationship to the ATM-RMON MIB" - rewrote section 3.2 "Protocol Identifier Macro Format" But no semantic changes were made; The PI macro syntax is now specified in greater detail using BNF notation. - Section 3.2.3.1 "Mapping of the 'countsFragments(0)' BIT" - this section was clarified to allow multiple protocolDirParameters octets in a given PI string to set the 'countsFragments' bit. The RFC version says just one octet can set this BIT. It is a useful feature to identify fragmentation at multiple layers, and most RMON-2 agents were already doing this, so the WG agreed to this clarification. - Added section 4.3 "Encapsualtion Layers" - This document ends after the base layer encapsulation definitions (through RFC 2074, section 5.2) - Added Intellectual Property section - Moved RFC 2074 section 5.3 "L3: Children of Base Protocol Identifiers" through the end of RFC 2074, to the PI Reference [RFC2896] document, in which many new protocol identifier macros were added for application protocols and non-IP protocol stacks. - Acknowledgements section has been updated
「RMONプロトコル識別子マクロドキュメントとの関係」 - を追加しましたセクション2.4「ATM-RMON MIBとの関係」 - 3.2「プロトコル識別子マクロ形式」しかし、誰セマンティック変更は行われませんでした書き直し部と、 PIマクロ構文についてBNF表記を使用して、より詳細に指定されています。 - セクション3.2.3.1「BIT 『（0）countsFragments』のマッピングを」 - このセクションは、所定のPI列における複数protocolDirParametersオクテットが「countsFragments」ビットを設定することができるように明らかにしました。 RFCバージョンは、ちょうど1つのオクテットは、このビットを設定することができますと言います。これは、複数の層で断片化を識別するための便利な機能であり、最もRMON-2の薬剤はすでにこれをやっていたので、WGはこの明確に合意しました。 - 追加されたセクション4.3「Encapsualtionレイヤー」 - 追加された知的財産部 - - 移転済RFC 2074のセクション5.3「L3：ベースプロトコル識別子の子供」この文書はベース層カプセル化定義（RFC 2074、セクション5.2を介して）後に終了の終わりまでRFC 2074、多くの新しいプロトコル識別子マクロは、アプリケーションプロトコルと非IPプロトコルスタックのために追加されたPIリファレンス[RFC2896]ドキュメントへ。 - 謝辞セクションが更新されました
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。