RFC2896 日本語訳
2896 Remote Network Monitoring MIB Protocol Identifier Macros. A.Bierman, C. Bucci, R. Iddon. August 2000. (Format: TXT=135768 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Bierman
Requests for Comment: 2896 C. Bucci
Category: Informational Cisco Systems, Inc.
R. Iddon
3Com, Inc.
August 2000
コメントを求めるワーキンググループA.Bierman要求をネットワークでつないでください: 2896年のC.ブッチカテゴリ: 情報のシスコシステムズInc.R.Iddon 3Com Inc.2000年8月
Remote Network Monitoring MIB Protocol Identifier Macros
リモートネットワーク監視MIBプロトコル識別子マクロ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base) Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RFC2895].
このメモは様々なプロトコル識別子の例を含んでいます、Remote Network Monitoring MIB(管理Information基地)バージョン2[RFC2021]とRMONプロトコルIdentifier Reference[RFC2895]によって定義されるように。(有効なprotocolDirTable INDEX encodingsを生産するのに例を使用できます)。
This document contains protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing a great deal of RMON related protocol information in one document.
このドキュメントはよく知られるプロトコルのためのプロトコル識別子マクロを含んでいます。 これらのプロトコル識別子の使用なしでRMON-2 MIB[RFC2021]のconformant実装を達成できます、そして、それに従って、このドキュメントはどんなIETF規格も指定しません。 それはRMON-2エージェント実装の間の、より良い相互運用性を奨励するために発行されます、1通のドキュメントの多くのRMONの関連するプロトコル情報を提供することによって。
The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion [RFC2895], and an "RMON Protocol Identifier Macros", document (this document) which contains the non-normative portion of that specification.
RMONプロトコルIdentifiers Document[RFC2074]の最初のバージョンはその仕様の非標準の部分を含む[RFC2895]、および「RMONプロトコル識別子マクロ」が記録する標準化過程のReference部分(このドキュメント)に分けられました。
Table of Contents
目次
1 The SNMP Network Management Framework ......................... 2 2 Overview ...................................................... 3 2.1 Terms ....................................................... 3 2.2 Relationship to the Remote Network Monitoring MIB ........... 4 2.3 Relationship to the RMON Protocol Identifier Reference ...... 4
1 SNMPネットワークマネージメントフレームワーク… 2 2概要… 3 2.1の用語… 3 2.2 リモートとの関係はモニターしているMIBをネットワークでつなぎます… 4 2.3 RMONとの関係は識別子参照について議定書の中で述べます… 4
Bierman, et al. Informational [Page 1] RFC 2896 RMON PI Macros August 2000
Bierman、他 [1ページ]情報のRFC2896RMONパイマクロ2000年8月
2.4 Relationship to Other MIBs .................................. 4 3 Protocol Identifier Macros .................................... 4 3.1 Protocol Stacks And Single-Vendor Applications .............. 5 3.1.1 The TCP/IP protocol stack ................................. 5 3.1.2 Novell IPX Stack .......................................... 44 3.1.3 The XEROX Protocol Stack .................................. 49 3.1.4 AppleTalk Protocol Stack .................................. 51 3.1.5 Banyon Vines Protocol Stack ............................... 56 3.1.6 The DECNet Protocol Stack ................................. 61 3.1.7 The IBM SNA Protocol Stack. .............................. 65 3.1.8 The NetBEUI/NetBIOS Family ................................ 66 3.2 Multi-stack protocols ....................................... 70 4 Intellectual Property ......................................... 72 5 Acknowledgements .............................................. 72 6 References .................................................... 73 7 Security Considerations ....................................... 82 8 Authors' Addresses ............................................ 83 9 Full Copyright Statement ...................................... 84
他のMIBsとの2.4関係… 4 3は識別子マクロについて議定書の中で述べます… 4 3.1 スタックと単一のベンダーアプリケーションについて議定書の中で述べてください… 5 3.1 .1 TCP/IPプロトコル・スタック… 5 3.1 .2 ノベルIPXは積み重ねます… 44 3.1 .3 ゼロックスプロトコル・スタック… 49 3.1 .4のAppleTalkがスタックについて議定書の中で述べます… 51 3.1 .5 Banyonつる植物はスタックについて議定書の中で述べます… 56 3.1 .6 DECNetはスタックについて議定書の中で述べます… 61 3.1 .7 IBM SNAプロトコル・スタック。 .............................. 65 3.1 .8 NetBEUI/NetBIOSファミリー… 66 3.2 マルチスタックプロトコル… 70 4知的所有権… 72 5つの承認… 72 6つの参照箇所… 73 7 セキュリティ問題… 82 8人の作者のアドレス… 83 9 完全な著作権宣言文… 84
1. The SNMP Network Management Framework
1. SNMPネットワークマネージメントフレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [RFC2571].
o RFC2571[RFC2571]で説明された総合的なアーキテクチャ。
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and 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 オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[RFC1155]、STD16、RFC1212[RFC1212]、およびRFC1215[RFC1215]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[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メッセージプロトコルの最初のバージョンは、STD15、RFC1157[RFC1157]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[RFC1901]とRFC1906[RFC1906]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC1906[RFC1906]、RFC2572[RFC2572]、およびRFC2574[RFC2574]でSNMPv3と呼ばれて、説明されます。
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 o
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
o 経営情報にアクセスするための操作について議定書の中で述べてください。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[RFC1157]で説明されます。 操作であって関連しているPDUがフォーマットする2番目のセットoプロトコルはRFC1905[RFC1905]で説明されます。
Bierman, et al. Informational [Page 2] RFC 2896 RMON PI Macros August 2000
Bierman、他 [2ページ]情報のRFC2896RMONパイマクロ2000年8月
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
o RFC2573[RFC2573]で説明された1セットの基礎的応用と視点ベースのアクセス管理機構はRFC2575で[RFC2575]について説明しました。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].
RFC2570[RFC2570]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
This memo does not specify a MIB module.
このメモはMIBモジュールを指定しません。
2. Overview
2. 概要
The RMON-2 MIB [RFC2021] uses hierarchically formatted OCTET STRINGs to globally identify individual protocol encapsulations in the protocolDirTable.
[RFC2021]が階層的で使用するRMON-2 MIBは、protocolDirTableで個々のプロトコルカプセル化をグローバルに特定するためにOCTET STRINGsをフォーマットしました。
This guide contains examples of protocol identifier encapsulations, which can be used to describe valid protocolDirTable entries. The syntax of the protocol identifier descriptor is defined in the RMON Protocol Identifier Reference [RFC2895].
このガイドはプロトコル識別子カプセル化に関する例を含みます。(有効なprotocolDirTableエントリーについて説明するのにカプセル化を使用できます)。 プロトコル識別子記述子の構文はRMONプロトコルIdentifier Reference[RFC2895]で定義されます。
This document is not intended to be an authoritative reference on the protocols described herein. Refer to the Official Internet Standards document [RFC2600], the Assigned Numbers document [RFC1700], or other appropriate RFCs, IEEE documents, etc. for complete and authoritative protocol information.
このドキュメントはここに説明されたプロトコルに関する正式の参照であることを意図しません。 完全で正式のプロトコル情報についてOfficialインターネットStandardsドキュメント[RFC2600]、Assigned民数記ドキュメント[RFC1700]、または他の適切なRFCs、IEEEドキュメントなどを参照してください。
This is the the second revision of this document, and is intended to replace Section 5 of the first RMON-2 Protocol Identifiers document [RFC2074].
これは、このドキュメントの2番目の改正であり、最初のRMON-2プロトコルIdentifiersドキュメント[RFC2074]のセクション5に取って代わることを意図します。
The RMONMIB working group has decided to discontinue maintenance of this Protocol Identifier Macro repository document, due to a lack of contributions from the RMON vendor community. This document is published as an aid in implementation of the protocolDirTable.
RMONMIBワーキンググループは、このプロトコルIdentifier Macro倉庫ドキュメントのメインテナンスを中止すると決めました、RMONベンダー共同体からの貢献の不足のため。 このドキュメントはprotocolDirTableの実装における援助として発表されます。
2.1. Terms
2.1. 用語
Refer to the RMON Protocol Identifier Reference [RFC2895] for definitions of terms used to describe the Protocol Identifier Macro and aspects of protocolDirTable INDEX encoding.
プロトコルIdentifier Macroについて説明するのに使用される用語の定義とprotocolDirTable INDEXコード化の局面についてRMONプロトコルIdentifier Reference[RFC2895]を参照してください。
Bierman, et al. Informational [Page 3] RFC 2896 RMON PI Macros August 2000
Bierman、他 [3ページ]情報のRFC2896RMONパイマクロ2000年8月
2.2. Relationship to the Remote Network Monitoring MIB
2.2. リモートネットワーク監視MIBとの関係
This document is intended to describe some protocol identifier macros, which can be converted to valid protocolDirTable INDEX values, using the mapping rules defined in the RMON Protocol Identifier Reference [RFC2895].
このドキュメントが有効なprotocolDirTable INDEX値に変換できるいくつかのプロトコル識別子マクロについて説明することを意図します、RMONプロトコルIdentifier Reference[RFC2895]で定義された配置規則を使用して。
This document is not intended to limit the protocols that may be identified for counting in the RMON-2 MIB. Many protocol encapsulations, not explicitly identified in this document, may be present in an actual implementation of the protocolDirTable. Also, implementations of the protocolDirTable may not include all the protocols identified in the example section below.
このドキュメントがRMON-2 MIBで数えるために特定されるかもしれないプロトコルを制限することを意図しません。 多くの明らかに本書では特定されなかったプロトコルカプセル化がprotocolDirTableの実際の実装で存在しているかもしれません。 また、protocolDirTableの実装は下の例の部で特定されたすべてのプロトコルを含まないかもしれません。
2.3. Relationship to the RMON Protocol Identifier Reference
2.3. RMONプロトコル識別子参照との関係
This document is intentionally separated from the normative reference document defining protocolDirTable INDEX encoding rules and the protocol identifier macro syntax [RFC2895]. This allows frequent updates to this document without any republication of MIB objects or protocolDirTable INDEX encoding rules. Note that the base layer and IANA assigned protocol identifier macros are located in Reference document, since these encoding values are defined by the RMONMIB WG.
このドキュメントは故意にprotocolDirTable INDEX符号化規則とプロトコル識別子マクロ構文[RFC2895]を定義する引用規格ドキュメントと切り離されます。 これはMIBオブジェクトかprotocolDirTable INDEX符号化規則の少しも再刊なしでこのドキュメントに頻繁なアップデートを許します。 基層とプロトコル識別子マクロが割り当てられたIANAがReferenceドキュメントに位置していることに注意してください、値をコード化するこれらがRMONMIB WGによって定義されるので。
Protocol Identifier macros submitted from the RMON working group and community at large (to the RMONMIB WG mailing list at ' rmonmib@cisco.com') will be collected and added to this document.
RMONワーキンググループと一般社会(' rmonmib@cisco.com 'のRMONMIB WGメーリングリストへの)から提出されたプロトコルIdentifierマクロは、このドキュメントに集められて、追加されるでしょう。
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 "ftp://ftpeng.cisco.com/ftp/rmonmib/rmonmib".
マクロ差出は" ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/ "というディレクトリの下におけるIANAのMIBファイルの中と、そして、" ftp://ftpeng.cisco.com/ftp/rmonmib/rmonmib "というRMONMIBワーキンググループメーリングリストメッセージアーカイブファイルに集められるでしょう。
2.4. Relationship to Other MIBs
2.4. 他のMIBsとの関係
The RMON Protocol Identifier Macros document is intended for use with the RMON Protocol Identifier Reference [RFC2895] and the RMON-2 MIB protocolDirTable [RFC2021]. It is not relevant to any other MIB, or intended for use with any other MIB.
RMONプロトコルIdentifier MacrosドキュメントはRMONプロトコルIdentifier Reference[RFC2895]とRMON-2 MIB protocolDirTable[RFC2021]との使用のために意図します。 それは、いかなる他のMIBにも関連しない、またいかなる他のMIBとの使用のためにも意図していません。
3. Protocol Identifier Macros
3. プロトコル識別子マクロ
This section contains protocol identifier macros for some well-known protocols, although some of them may no longer be in use. These macros reference the base layer identifiers found in section 4 of the RMON Protocol Identifier Reference [RFC2895]. These identifiers are listed below:
それらのいくつかがもう使用中でないかもしれませんが、このセクションはいくつかのよく知られるプロトコルのためのプロトコル識別子マクロを含みます。 基層識別子がRMONプロトコルIdentifier Reference[RFC2895]のセクション4で見つけたこれらのマクロ参照。 これらの識別子は以下にリストアップされています:
Bierman, et al. Informational [Page 4] RFC 2896 RMON PI Macros August 2000
Bierman、他 [4ページ]情報のRFC2896RMONパイマクロ2000年8月
ether2
llc
snap
vsnap
ianaAssigned
802-1Q
ether2 llcスナップvsnap ianaAssigned802-1Q
Refer to the RMON Protocol Identifier Reference [RFC2895] for the protocol identifier macro definitions for these protocols.
これらのプロトコルのために、プロトコル識別子マクロ定義についてRMONプロトコルIdentifier Reference[RFC2895]を参照してください。
3.1. Protocol Stacks And Single-Vendor Applications
3.1. プロトコル・スタックと単一のベンダーアプリケーション
Network layer protocol identifier macros contain additional information about the network layer, and is found immediately following a base layer-identifier in a protocol identifier.
ネットワーク層プロトコル識別子マクロは、ネットワーク層に関する追加情報を含んでいて、すぐにプロトコル識別子のベース層識別子に従うのが見つけられます。
The ProtocolDirParameters supported at the network layer are ' countsFragments(0)', and 'tracksSessions(1). An agent may choose to implement a subset of these parameters.
ネットワーク層でサポートされたProtocolDirParametersは'countsFragments(0)'と、'tracksSessions(1)'です。 エージェントは、これらのパラメタの部分集合を実装するのを選ぶかもしれません。
The protocol-name should be used for the ProtocolDirDescr field. The ProtocolDirType ATTRIBUTES used at the network layer are ' hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may choose to implement a subset of these attributes for each protocol, and therefore limit which tables the indicated protocol can be present (e.g. protocol distribution, host, and matrix tables).
プロトコル名はProtocolDirDescr分野に使用されるべきです。 ネットワーク層に使用されるProtocolDirType ATTRIBUTESは'hasChildren(0)'と'addressRecognitionCapable(1)'です。 エージェントは、各プロトコルのためにこれらの属性の部分集合を実装するのを選ぶかもしれません、そして、したがって、示されたプロトコルを見送る限界は存在している場合があります(例えば、プロトコル分配、ホスト、およびマトリクステーブル)。
The following protocol-identifier macro declarations are given for example purposes only. They are not intended to constitute an exhaustive list or an authoritative source for any of the protocol information given. However, any protocol that can encapsulate other protocols must be documented here in order to encode the children identifiers into protocolDirID strings. Leaf protocols should be documented as well, but an implementation can identify a leaf protocol even if it isn't listed here (as long as the parent is documented).
以下のプロトコル識別子マクロ宣言に例えば目的だけを与えます。 彼らが与えられたプロトコル情報のどれかのために完全なりストか権威筋を構成することを意図しません。 しかしながら、子供識別子をprotocolDirIDストリングにコード化するためにここに他のプロトコルをカプセル化することができるどんなプロトコルも記録しなければなりません。 葉のプロトコルはまた、記録されるべきですが、それがここに記載されないでも(親が記録される限り)、実装は葉のプロトコルを特定できます。
3.1.1. The TCP/IP protocol stack
3.1.1. TCP/IPプロトコル・スタック
arp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"An Address Resolution Protocol message (request or response).
This protocol does not include Reverse ARP (RARP) packets, which
are counted separately."
REFERENCE
"RFC 826 [RFC826] defines the Address Resolution Protocol."
arpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「Address Resolutionプロトコルは通信(要求か応答)にさせる」記述。 「このプロトコルはReverseアルプ(RARP)パケットを含んでいません」。(パケットは別々に数えられます)。 REFERENCE、「RFC826[RFC826]はAddress Resolutionプロトコルを定義します」。
Bierman, et al. Informational [Page 5] RFC 2896 RMON PI Macros August 2000
Bierman、他 [5ページ]情報のRFC2896RMONパイマクロ2000年8月
::= {
ether2 0x806, -- [ 0.0.8.6 ]
snap 0x806,
802-1Q 0x806 -- [ 0.0.8.6 ]
}
::= ether2 0x806--、[0.0 .8 .6] 802-1 0×806、Q0x806を折ってください--、[0.0、.8、.6]
ip PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0) -- This parameter applies to all child
-- protocols.
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The protocol identifiers for the Internet Protocol (IP). Note
that IP may be encapsulated within itself, so more than one of
the following identifiers may be present in a particular
protocolDirID string."
CHILDREN
"Children of 'ip' are selected by the value in the Protocol field
(one octet), as defined in the PROTOCOL NUMBERS table within the
Assigned Numbers Document.
ipプロトコル-IDENTIFIER PARAMETERS、countsFragments(0)(パラメタがすべての子供に当てはまるこれ)プロトコル。 ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述、「インターネットプロトコル(IP)のためのプロトコル識別子。」 「以下の識別子の1つ以上が特定のprotocolDirIDストリングに存在させることができるように、IPがそれ自体の中でカプセル化されるかもしれないことに注意してください。」 CHILDREN、「'ip'の子供はプロトコル分野(1つの八重奏)の値によって選ばれます、Assigned民数記Documentの中のプロトコル民数記テーブルで定義されるように」。
The value of the Protocol field is encoded in an octet string as
[ 0.0.0.a ], where 'a' is the protocol field .
プロトコル分野の値は[0.0.0.a]として八重奏ストリングでコード化されます。そこでは、'a'がプロトコル分野です。
Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a'
where 'a' is the protocol field value. For example, a
protocolDirID-fragment value of:
0.0.0.1.0.0.8.0.0.0.0.1
'ip'の子供は、'a'がプロトコル分野価値であるところで[0.0.0.a]としてコード化されて、'ip a'として命名されます。 例えば、以下のprotocolDirID-断片値 0.0.0.1.0.0.8.0.0.0.0.1
defines an encapsulation of ICMP (ether2.ip.icmp)"
ADDRESS-FORMAT
"4 octets of the IP address, in network byte order. Each ip
packet contains two addresses, the source address and the
destination address."
DECODING
"Note: ether2.ip.ipip4.udp is a different protocolDirID than
ether2.ip.udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by the
agent. E.g. (full INDEX values shown):
ether2.ip.ipip4.udp =
16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0
ether2.ip.udp =
12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
REFERENCE
「ICMPのカプセル化を定義する、(ether2.ip.icmp) 」 「IPの4つの八重奏がネットワークバイトオーダーで扱う」ADDRESS-FORMAT。 「それぞれのipパケットは2つのアドレス、ソースアドレス、および送付先アドレスを含んでいます。」 「以下に注意してください」解読して、 ether2.ip.ipip4.udpはether2.ip.udp protocolDirTableで特定されるように異なったprotocolDirIDです。 そういうものとして、2つの異なった地方のプロトコルインデックス値がエージェントによって割り当てられるでしょう。 例えば (示された完全なINDEX値): ether2.ip.ipip4.udpは16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0ether2.ip.udp=12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0「参照」と等しいです。
Bierman, et al. Informational [Page 6] RFC 2896 RMON PI Macros August 2000
Bierman、他 [6ページ]情報のRFC2896RMONパイマクロ2000年8月
"RFC 791 [RFC791] defines the Internet Protocol; The following
URL defines the authoritative repository for the PROTOCOL NUMBERS
Table:
「RFC791[RFC791]はインターネットプロトコルを定義します」。 以下のURLはプロトコル民数記Tableのために正式の倉庫を定義します:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers"
::= {
ether2 0x0800,
llc 0x06,
snap 0x0800,
-- ip 4, ** represented by the ipip4 macro
-- ip 94, ** represented by the ipip macro
802-1Q 0x0800, -- [0.0.8.0]
802-1Q 0x02000006 -- 1Q-LLC [2.0.0.6]
}
" ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers ":、:= ether2 0x0800(llc0x06)は0×0800--ip4、ipip4マクロによって表された**--ip94を折ります、ipipマクロ802-1Q0x0800によって表された**--、[0.0 .8 .0] 802-1 Q0x02000006--、1Q-LLC、[2.0、.0、.6]
-- **************************************************************** -- -- Children of IP -- -- ****************************************************************
-- 子供
icmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Message Control Protocol"
REFERENCE
"RFC 792 [RFC792] defines the Internet Control Message Protocol."
::= {
ip 1,
ipip4 1,
ipip 1
}
インターネットメッセージ制御は」 REFERENCEについて議定書の中で述べます。icmpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC792[RFC792]はインターネット・コントロール・メッセージ・プロトコルを定義します」。 ::= ip1、ipip4 1、ipip1
igmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Group Management Protocol; IGMP is used by IP hosts to
report their host group memberships to any immediately-
neighboring multicast routers."
REFERENCE
"Appendix A of Host Extensions for IP Multicasting [RFC1112]
defines the Internet Group Management Protocol."
::= {
ip 2,
ipip4 2,
ipip 2
igmpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「インターネット集団経営プロトコル」。 「IGMPはどんなすぐに隣接しているマルチキャストルータにも彼らのホストグループ会員資格を報告するのにIPホストによって使用されます。」 REFERENCE、「IP Multicasting[RFC1112]のためのHost Extensionsの付録AはインターネットGroup Managementプロトコルを定義します」。 ::= ip2、ipip4 2、ipip2
Bierman, et al. Informational [Page 7] RFC 2896 RMON PI Macros August 2000
Bierman、他 [7ページ]情報のRFC2896RMONパイマクロ2000年8月
}
}
ggp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Gateway-to-Gateway Protocol; DARPA Internet Gateway
(historical)"
REFERENCE
"RFC 823 [RFC823] defines the Gateway-to-Gateway Protocol."
::= {
ip 3,
ipip4 3,
ipip 3
}
ggpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ゲートウェー間プロトコル」。 「DARPAインターネットゲートウェイ(歴史的な)」REFERENCE、「RFC823[RFC823]はゲートウェイからゲートウェイへのプロトコルを定義します」。 ::= ip3、ipip4 3、ipip3
ipip4 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"IP in IP Tunneling"
CHILDREN
"Children of 'ipip4' are selected and encoded in the same manner
as children of IP."
ADDRESS-FORMAT
"The 'ipip4' address format is the same as the IP address
format."
DECODING
"Note: ether2.ip.ipip4.udp is a different protocolDirID than
ether2.ip.udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by the
agent. E.g. (full INDEX values shown):
ether2.ip.ipip4.udp =
16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0
ether2.ip.udp =
12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
REFERENCE
"RFC 1853 [RFC1853] defines IP in IP over Protocol 4."
::= {
ip 4,
ipip4 4,
ipip 4
}
ipip4プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述、「IP、」 IPトンネリングCHILDRENでは、「'ipip4'の子供は、IPの子供と同じ方法で選ばれて、コード化されます」。 ADDRESS-FORMAT、「'ipip4'アドレス形式はIPアドレス形式と同じです」。 「以下に注意してください」解読して、 ether2.ip.ipip4.udpはether2.ip.udp protocolDirTableで特定されるように異なったprotocolDirIDです。 そういうものとして、2つの異なった地方のプロトコルインデックス値がエージェントによって割り当てられるでしょう。 例えば (示された完全なINDEX値): 「16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0ether2.ip.udp=12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0"REFERENCE"ether2.ip.ipip4.udp=RFC1853[RFC1853]はプロトコル4の上でIPでIPを定義します。」 ::= ip4、ipip4 4、ipip4
st PROTOCOL-IDENTIFIER
第プロトコル識別子
Bierman, et al. Informational [Page 8] RFC 2896 RMON PI Macros August 2000
Bierman、他 [8ページ]情報のRFC2896RMONパイマクロ2000年8月
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Stream Protocol Version 2 (ST2); (historical) ST2 is an
experimental resource reservation protocol intended to provide
end-to-end real-time guarantees over an internet."
REFERENCE
"RFC 1819 [RFC1819] defines version 2 of the Internet Stream
Protocol."
::= {
ip 5,
ipip4 5,
ipip 5
}
パラメタ、属性、記述「インターネットストリームプロトコルバージョン2(ST2)」。 (歴史的)です。 「ST2は終わりから終わりへのリアルタイムの保証をインターネットの上に提供することを意図する実験資源予約プロトコルです。」 REFERENCE、「RFC1819[RFC1819]はインターネットStreamプロトコルのバージョン2を定義します」。 ::= ip5、ipip4 5、ipip5
tcp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Transmission Control Protocol"
CHILDREN
"Children of TCP are identified by the 16 bit Source or
Destination Port value as specified in RFC 793. They are encoded
as [ 0.0.a.b], where 'a' is the MSB and 'b' is the LSB of the
port value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
転送管理は」 CHILDRENについて議定書の中で述べます。tcpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述、「「TCPの子供は指定されるとしてRFC793で16ビットのSourceかDestination Port値によって特定されます」。 それらは、[0.0.a.b]('a'はMSBと'b'である)がポート価値のLSBであるので、コード化されます。 両方のバイトはネットワークバイトオーダーでコード化されます。 例えば、以下のprotocolDirId-断片 0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
identifies an encapsulation of the telnet protocol
(ether2.ip.tcp.telnet)"
REFERENCE
"RFC 793 [RFC793] defines the Transmission Control Protocol.
telnetのカプセル化は」 (ether2.ip.tcp.telnet)REFERENCEについて議定書の中で述べます。「特定、「RFC793[RFC793]は通信制御プロトコルを定義します」。
The following URL defines the authoritative repository for
reserved and registered TCP port values:
以下のURLは予約されて登録されたTCPポート値のために正式の倉庫を定義します:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= {
ip 6,
ipip4 6,
ipip 6
}
" ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers ":、:= ip6、ipip4 6、ipip6
egp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
egpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES{ }
Bierman, et al. Informational [Page 9] RFC 2896 RMON PI Macros August 2000
Bierman、他 [9ページ]情報のRFC2896RMONパイマクロ2000年8月
DESCRIPTION
"Exterior Gateway Protocol (historical)"
REFERENCE
"RFC 904 [RFC904] defines the Exterior Gateway Protocol."
::= {
ip 8,
ipip4 8,
ipip 8
}
外のゲートウェイは」 REFERENCEについて議定書の中で述べます(歴史的な)。記述、「「RFC904[RFC904]はExteriorゲートウェイプロトコルを定義します」。 ::= ip8、ipip4 8、ipip8
igp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Any private interior gateway."
REFERENCE
"[RFC1700]"
::= {
ip 9,
ipip4 9,
ipip 9
}
igpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「どんな個人的な内部のゲートウェイも。」 以下に参照をつけてください「[RFC1700]」という:= ip9、ipip4 9、ipip9
nvp2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NVP-II; Network Voice Protocol"
REFERENCE
"RFC 741 [RFC741] defines the Network Voice Protocol"
::= {
ip 11,
ipip4 11,
ipip 11
}
nvp2プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「NVP-II」。 」 VoiceプロトコルREFERENCEをネットワークでつないでください。「「RFC741[RFC741]はNetwork Voiceプロトコルを定義する」:、:= ip11、ipip4 11、ipip11
pup PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"PUP Protocol"
REFERENCE
"Xerox"
::= {
ip 12,
ipip4 12,
ipip 12
}
子犬プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「子犬プロトコル」REFERENCEは以下を「コピーします」:= ip12、ipip4 12、ipip12
Bierman, et al. Informational [Page 10] RFC 2896 RMON PI Macros August 2000
Bierman、他 [10ページ]情報のRFC2896RMONパイマクロ2000年8月
xnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Cross Net Debugger (historical)"
REFERENCE
"[IEN158]"
::= {
ip 15,
ipip4 15,
ipip 15
}
xnetプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「[IEN158]」という記述「交差しているネットのデバッガ(歴史的な)」REFERENCE:、:= ip15、ipip4 15、ipip15
chaos PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"CHAOS Protocol; historical"
REFERENCE
"J. Noel Chiappa <JNC@XX.LCS.MIT.EDU>"
::= {
ip 16,
ipip4 16,
ipip 16
}
カオスプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「カオスプロトコル」。 「歴史的な」REFERENCE「J」。 「クリスマス Chiappa <JNC@XX.LCS.MIT.EDU 、gt;、」、:、:= ip16、ipip4 16、ipip16
udp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"User Datagram Protocol"
CHILDREN
"Children of UDP are identified by the 16 bit Source or
Destination Port value as specified in RFC 768. They are encoded
as [ 0.0.a.b ], where 'a' is the MSB and 'b' is the LSB of the
port value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161
ユーザデータグラムは」 CHILDRENについて議定書の中で述べます。udpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述、「「UDPの子供は指定されるとしてRFC768で16ビットのSourceかDestination Port値によって特定されます」。 それらは、[0.0.a.b]('a'はMSBと'b'である)がポート価値のLSBであるので、コード化されます。 両方のバイトはネットワークバイトオーダーでコード化されます。 例えば、以下のprotocolDirId-断片 0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161
identifies an encapsulation of SNMP (ether2.ip.udp.snmp)"
REFERENCE
"RFC 768 [RFC768] defines the User Datagram Protocol.
「SNMP(ether2.ip.udp.snmp)のカプセル化を特定する」、REFERENCE、「RFC768[RFC768]はユーザー・データグラム・プロトコルを定義します」。
The following URL defines the authoritative repository for
reserved and registered UDP port values:
以下のURLは予約されて登録されたUDPポート値のために正式の倉庫を定義します:
Bierman, et al. Informational [Page 11] RFC 2896 RMON PI Macros August 2000
Bierman、他 [11ページ]情報のRFC2896RMONパイマクロ2000年8月
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= {
ip 17,
ipip4 17,
ipip 17
}
" ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers ":、:= ip17、ipip4 17、ipip17
mux PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Multiplexing Protocol (historical)"
REFERENCE
"IEN-90 [IEN-90] defines the Multiplexing Protocol"
::= {
ip 18,
ipip4 18,
ipip 18
}
muxプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「」 プロトコル(歴史的な)REFERENCEを多重送信して、「IEN-90[IEN-90]はMultiplexingプロトコルを定義する」:、:= ip18、ipip4 18、ipip18
hmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Host Monitoring Protocol; historical"
REFERENCE
"RFC 869 [RFC869] defines the Host Monitoring Protocol"
::= {
ip 20,
ipip4 20,
ipip 20
}
hmpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ホストのモニターしているプロトコル」。 「歴史的な」REFERENCE、「RFC869[RFC869]はHost Monitoringプロトコルを定義する」:、:= ip20、ipip4 20、ipip20
xns-idp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XEROX NS IDP"
REFERENCE
"Xerox Corporation"
::= {
ip 22,
ipip4 22,
ipip 22
}
xns-idpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ゼロックスナノ秒IDP」参照「ゼロックス社」:、:= ip22、ipip4 22、ipip22
rdp PROTOCOL-IDENTIFIER
PARAMETERS { }
rdpプロトコル-IDENTIFIER PARAMETERS{ }
Bierman, et al. Informational [Page 12] RFC 2896 RMON PI Macros August 2000
Bierman、他 [12ページ]情報のRFC2896RMONパイマクロ2000年8月
ATTRIBUTES { }
DESCRIPTION
"Reliable Data Protocol"
REFERENCE
"RFC 908 [RFC908] defines the original protocol; RFC 1151
[RFC1151] defines version 2 of the Reliable Data Protocol."
::= {
ip 27,
ipip4 27,
ipip 27
}
確実な資料は」 REFERENCEについて議定書の中で述べます。ATTRIBUTES、記述、「「RFC908[RFC908]はオリジナルのプロトコルを定義します」。 「RFC1151[RFC1151]はReliable Dataプロトコルのバージョン2を定義します。」 ::= ip27、ipip4 27、ipip27
irtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Reliable Transaction Protocol"
REFERENCE
"RFC 938 [RFC938] defines the Internet Reliable Transaction
Protocol functional and interface specification."
::= {
ip 28,
ipip4 28,
ipip 28
}
インターネットの信頼できるトランザクションは」 REFERENCEについて議定書の中で述べます。irtpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC938[RFC938]はインターネットReliable Transactionプロトコル機能的、そして、インタフェース仕様を定義します」。 ::= ip28、ipip4 28、ipip28
iso-tp4 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ISO Transport Protocol Specification"
REFERENCE
"RFC 905 [RFC905] defines the ISO Transport Protocol
Specification; ISO DP 8073"
::= {
ip 29,
ipip4 29,
ipip 29
}
ISO輸送は」 仕様REFERENCEについて議定書の中で述べます。iso-tp4プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC905[RFC905]はISO TransportプロトコルSpecificationを定義します」。 「ISO DP8073」:、:= ip29、ipip4 29、ipip29
netblt PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bulk Data Transfer Protocol; historical"
REFERENCE
"RFC 998 [RFC998] defines NETBLT: A Bulk Data Transfer Protocol."
::= {
netbltプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「バルク・データ転送プロトコル」。 「歴史的な」REFERENCE、「RFC998[RFC998]はNETBLTを定義します」。 「バルク・データ転送プロトコル。」 ::= {
Bierman, et al. Informational [Page 13] RFC 2896 RMON PI Macros August 2000
Bierman、他 [13ページ]情報のRFC2896RMONパイマクロ2000年8月
ip 30,
ipip4 30,
ipip 30
}
ip30、ipip4 30、ipip30
mfe-nsp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MFE Network Services Protocol; historical"
REFERENCE
"Shuttleworth, B., 'A Documentary of MFENet, a National Computer
Network', UCRL-52317, Lawrence Livermore Labs, Livermore,
California, June 1977."
::= {
ip 31,
ipip4 31,
ipip 31
}
mfe-nspプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「MFEネットワーク・サービスプロトコル」。 「歴史的な」REFERENCE、「シャットルワース、B.、'MFENetのドキュメンタリー、国家のコンピュータネットワーク'UCRL-52317、ローレンスリバーモア研究室、リバーモア(カリフォルニア)1977年6月。」 ::= ip31、ipip4 31、ipip31
idpr PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Inter-Domain Policy Routing Protocol"
REFERENCE
"RFC 1479 [RFC1479] defines Version 1 of the Inter-Domain Policy
Routing Protocol."
::= {
ip 35,
ipip4 35,
ipip 35
}
相互ドメイン方針ルート設定は」 REFERENCEについて議定書の中で述べます。idprプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1479[RFC1479]はInter-ドメインPolicyルート設定プロトコルのバージョン1を定義します」。 ::= ip35、ipip4 35、ipip35
idpr-cmtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IDPR Control Message Transport Protocol"
REFERENCE
"RFC 1479 [RFC1479] defines Version 1 of the Inter-Domain Policy
Routing Protocol."
::= {
ip 38,
ipip4 38,
ipip 38
}
IDPRコントロールメッセージ転送は」 REFERENCEについて議定書の中で述べます。idpr-cmtpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1479[RFC1479]はInter-ドメインPolicyルート設定プロトコルのバージョン1を定義します」。 ::= ip38、ipip4 38、ipip38
Bierman, et al. Informational [Page 14] RFC 2896 RMON PI Macros August 2000
Bierman、他 [14ページ]情報のRFC2896RMONパイマクロ2000年8月
sdrp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Source Demand Routing Protocol"
REFERENCE
"RFC 1940 [RFC1940] defines version 1 of the Source Demand
Routing: Packet Format and Forwarding Specification"
::= {
ip 42,
ipip4 42,
ipip 42
}
sdrpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「」 「RFC1940[RFC1940]はSource Demandルート設定のバージョン1を定義する」というソース要求ルーティング・プロトコルREFERENCE 「パケット・フォーマットと推進仕様」:、:= ip42、ipip4 42、ipip42
idrp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Inter-Domain Routing Protocol"
REFERENCE
"RFC 1745 [RFC1745] defines BGP4/IDRP for IP."
::= {
ip 45,
ipip4 45,
ipip 45
}
相互ドメインルート設定は」 REFERENCEについて議定書の中で述べます。idrpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1745[RFC1745]はIPのためにBGP4/IDRPを定義します」。 ::= ip45、ipip4 45、ipip45
rsvp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Resource Reservation Setup Protocol"
REFERENCE
"Resource ReSerVation Protocol (RSVP); Version 1 Functional
Specification [RFC2205]."
::= {
ip 46,
ipip4 46,
ipip 46
}
rsvpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「資源予約セットアッププロトコル」REFERENCE「資源予約プロトコル(RSVP)」。 「バージョン1の機能的な仕様[RFC2205]。」 ::= ip46、ipip4 46、ipip46
gre PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"General Routing Encapsulation"
REFERENCE
"RFC 1701 [RFC1701] defines Generic Routing Encapsulation (GRE);
greプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「一般、」 カプセル化REFERENCEを発送して、「RFC1701[RFC1701]はGenericルート設定Encapsulation(GRE)を定義します」。
Bierman, et al. Informational [Page 15] RFC 2896 RMON PI Macros August 2000
Bierman、他 [15ページ]情報のRFC2896RMONパイマクロ2000年8月
RFC 1702 [RFC1702] defines Generic Routing Encapsulation over
IPv4 networks"
::= {
ip 47,
ipip4 47,
ipip 47
}
「RFC1702[RFC1702]はIPv4ネットワークの上でGenericルート設定Encapsulationを定義する」:、:= ip47、ipip4 47、ipip47
nhrp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NBMA Next Hop Resolution Protocol (NHRP)"
REFERENCE
"RFC 2332 [RFC2332] defines the Next Hop Resolution Protocol."
::= {
ip 54,
ipip4 54,
ipip 54
}
次のNBMAは」 解決プロトコル(NHRP)REFERENCEを飛び越します。nhrpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC2332[RFC2332]はNext Hop Resolutionプロトコルを定義します」。 ::= ip54、ipip4 54、ipip54
priv-host PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any internal host protocol."
REFERENCE
"[RFC1700]"
::= {
ip 61,
ipip4 61,
ipip 61
}
priv-ホストプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「いずれのためにも予約された疑似プロトコルの内部のホストプロトコル。」 以下に参照をつけてください「[RFC1700]」という:= ip61、ipip4 61、ipip61
priv-net PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any local network protocol."
REFERENCE
"[RFC1700]"
::= {
ip 63,
ipip4 63,
ipip 63
}
privネットのプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「いずれのためにも予約された疑似プロトコルのローカルのネットワーク・プロトコル。」 以下に参照をつけてください「[RFC1700]」という:= ip63、ipip4 63、ipip63
priv-distfile PROTOCOL-IDENTIFIER
priv-distfileプロトコル-IDENTIFIER
Bierman, et al. Informational [Page 16] RFC 2896 RMON PI Macros August 2000
Bierman、他 [16ページ]情報のRFC2896RMONパイマクロ2000年8月
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any distributed file system."
REFERENCE
"[RFC1700]"
::= {
ip 68,
ipip4 68,
ipip 68
}
PARAMETERS、ATTRIBUTES、「疑似プロトコルはどんな分散ファイルシステムのためにも予約した」記述。 以下に参照をつけてください「[RFC1700]」という:= ip68、ipip4 68、ipip68
dgp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Dissimilar Gateway Protocol"
REFERENCE
"M/A-COM Government Systems, 'Dissimilar Gateway Protocol
Specification, Draft Version', Contract no. CS901145, November
16, 1987."
::= {
ip 86,
ipip4 86,
ipip 86
}
dgpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「異なったゲートウェイプロトコル」REFERENCE「政府Systems、1COMのM/'異なったゲートウェイプロトコルSpecification、Draftバージョン'Contractノー」 「CS901145、1987年11月16日。」 ::= ip86、ipip4 86、ipip86
igrp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IGRP; Cisco routing protocol"
REFERENCE
"Cisco Systems, Inc."
::= {
ip 88,
ipip4 88,
ipip 88
}
igrpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述"IGRP"。 「コクチマスルーティング・プロトコル」REFERENCE「シスコシステムズInc.」:、:= ip88、ipip4 88、ipip88
ospf PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Open Shortest Path First Interior GW Protocol (OSPFIGP)."
REFERENCE
"RFC 1583 [RFC1583] defines version 2 of the OSPF protocol."
::= {
ospfプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「開いている最短パス最初の内部のGWは議定書の中で述べ(OSPFIGP)」記述。 REFERENCE、「RFC1583[RFC1583]はOSPFプロトコルのバージョン2を定義します」。 ::= {
Bierman, et al. Informational [Page 17] RFC 2896 RMON PI Macros August 2000
Bierman、他 [17ページ]情報のRFC2896RMONパイマクロ2000年8月
ip 89,
ipip4 89,
ipip 89
}
ip89、ipip4 89、ipip89
mtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Multicast Transport Protocol"
REFERENCE
"RFC 1301 [RFC1301] defines the Multicast Transport Protocol."
::= {
ip 92,
ipip4 92,
ipip 92
}
マルチキャスト輸送は」 REFERENCEについて議定書の中で述べます。mtpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1301[RFC1301]はMulticast Transportプロトコルを定義します」。 ::= ip92、ipip4 92、ipip92
ax-25 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AX.25 Frame Encapsulation"
REFERENCE
"RFC 1226 [RFC1226] defines Internet Protocol Encapsulation of
AX.25 Frames."
::= {
ip 93,
ipip4 93,
ipip 93
}
」 .25フレームカプセル化REFERENCEを斧で作ってください。斧-25プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1226[RFC1226]はAX.25フレームのインターネットプロトコルEncapsulationを定義します」。 ::= ip93、ipip4 93、ipip93
ipip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"IP-within-IP Encapsulation Protocol"
CHILDREN
"Children of 'ipip' are selected and encoded in the same manner
as children of IP."
ADDRESS-FORMAT
"The 'ipip' address format is the same as the IP address format."
DECODING
"Note: ether2.ip.ipip.udp is a different protocolDirID than
ether2.ip.udp, as identified in the protocolDirTable. As such,
IPの中のIPカプセル化は」 CHILDRENについて議定書の中で述べます。ipipプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述、「「'ipip'の子供は、IPの子供と同じ方法で選ばれて、コード化されます」。 ipip'アドレス形式はIPアドレス形式と同じである」ADDRESS-FORMAT。 「以下に注意してください」解読して、 ether2.ip.ipip.udpはether2.ip.udp protocolDirTableで特定されるように異なったprotocolDirIDです。 そういうものとして
Bierman, et al. Informational [Page 18] RFC 2896 RMON PI Macros August 2000
Bierman、他 [18ページ]情報のRFC2896RMONパイマクロ2000年8月
two different local protocol index values will be assigned by the
agent. E.g. (full INDEX values shown):
ether2.ip.ipip.udp =
16.0.0.0.1.0.0.8.0.0.0.0.94.0.0.0.17.4.0.0.0.0
ether2.ip.udp =
12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
REFERENCE
"RFC 2003 [RFC2003] defines IP Encapsulation within IP."
::= {
ip 94,
ipip4 94,
ipip 94
}
2つの異なった地方のプロトコルインデックス値がエージェントによって割り当てられるでしょう。 例えば (示された完全なINDEX値): 「16.0.0.0.1.0.0.8.0.0.0.0.94.0.0.0.17.4.0.0.0.0ether2.ip.udp=12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0"REFERENCE"ether2.ip.ipip.udp=RFC2003[RFC2003]はIPの中でIP Encapsulationを定義します。」 ::= ip94、ipip4 94、ipip94
encap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Encapsulation Header; A Scheme for an Internet Encapsulation
Protocol: Version 1"
REFERENCE
"RFC 1241 [RFC1241] defines version 1 of the ENCAP Protocol."
::= {
ip 98,
ipip4 98,
ipip 98
}
encapプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「カプセル化ヘッダー」。 インターネットカプセル化プロトコルの体系: バージョンの1インチのREFERENCE、「RFC1241[RFC1241]はENCAPプロトコルのバージョン1を定義します」。 ::= ip98、ipip4 98、ipip98
priv-encript PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private encryption scheme."
REFERENCE
"[RFC1700]"
::= {
ip 99,
ipip4 99,
ipip 99
}
priv-encriptプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「いずれのためにも予約された疑似プロトコルの個人的な暗号化体系。」 以下に参照をつけてください「[RFC1700]」という:= ip99、ipip4 99、ipip99
-- **************************************************************** -- -- Children of UDP and TCP -- -- ****************************************************************
-- 子供
tcpmux PROTOCOL-IDENTIFIER
tcpmuxプロトコル-IDENTIFIER
Bierman, et al. Informational [Page 19] RFC 2896 RMON PI Macros August 2000
Bierman、他 [19ページ]情報のRFC2896RMONパイマクロ2000年8月
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"TCP Port Service Multiplexer Port."
REFERENCE
"RFC 1078 [RFC1078] defines the TCP Port Service Multiplexer
Protocol."
::= { tcp 1 }
パラメタ、属性、記述「TCPポートサービス回線多重化装置ポート。」 REFERENCE、「RFC1078[RFC1078]はTCP Port Service Multiplexerプロトコルを定義します」。 ::= tcp1
rje PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Job Entry Protocol; RJE Logger Port; (historical)."
REFERENCE
"RFC 407 [RFC407] defines the Remote Job Entry Protocol."
::= { tcp 5 }
rjeプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「リモートジョブエントリプロトコル」。 RJEきこりのポート。 (歴史的)です。「」 . REFERENCE、「RFC407[RFC407]はRemote Job Entryプロトコルを定義します」。 ::= tcp5
echo PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Echo Protocol for debugging TCP and UDP transports."
REFERENCE
"RFC 862 [RFC862] defines the Echo Protocol."
::= {
tcp 7,
udp 7 }
プロトコル-IDENTIFIER PARAMETERSを反響してください、ATTRIBUTES、記述は「デバッグTCPとUDP輸送のためのプロトコルを反映します」。 REFERENCE、「RFC862[RFC862]はEchoプロトコルを定義します」。 ::= tcp7、udp7
discard PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Discard Protocol for debugging TCP and UDP transports."
REFERENCE
"RFC 863 [RFC863] defines the Discard Protocol."
::= {
tcp 9,
udp 9 }
プロトコル-IDENTIFIER PARAMETERSを捨ててください、ATTRIBUTES、記述は「デバッグTCPとUDP輸送のためにプロトコルを捨てます」。 REFERENCE、「RFC863[RFC863]はDiscardプロトコルを定義します」。 ::= tcp9、udp9
systat PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Retrieve the Active Users list; a debugging tool for TCP and UDP
transports."
REFERENCE
"RFC 866 [RFC866] defines the Active Users Protocol."
systatプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述は「Active Usersリストを検索します」。 「TCPとUDP輸送のためのデバッグ用ツール。」 REFERENCE、「RFC866[RFC866]はActive Usersプロトコルを定義します」。
Bierman, et al. Informational [Page 20] RFC 2896 RMON PI Macros August 2000
Bierman、他 [20ページ]情報のRFC2896RMONパイマクロ2000年8月
::= {
tcp 11,
udp 11 }
::= tcp11、udp11
daytime PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Retrieve the current time of day; a debugging tool for TCP and
UDP transports."
REFERENCE
"RFC 867 [RFC867] defines the Daytime Protocol."
::= {
tcp 13,
udp 13 }
昼間プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述は「現在の時刻を検索します」。 「TCPとUDP輸送のためのデバッグ用ツール。」 REFERENCE、「RFC867[RFC867]はDaytimeプロトコルを定義します」。 ::= tcp13、udp13
qotd PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Quote of the Day Protocol; retrieve a short message (up to 512
bytes); a debugging tool for TCP and UDP transports."
REFERENCE
"RFC 865 [RFC865] defines the Quote of the Day Protocol."
::= {
tcp 17,
udp 17 }
qotdプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「今日の名言プロトコル」。 短いメッセージ(最大512バイト)を検索してください。 「TCPとUDP輸送のためのデバッグ用ツール。」 REFERENCE、「RFC865[RFC865]はデープロトコルのQuoteを定義します」。 ::= tcp17、udp17
msp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Message Send Protocol"
REFERENCE
"RFC 1312 [RFC1312] defines the Message Send Protocol."
mspプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「メッセージは「RFC1312[RFC1312]はMessage Sendプロトコルを定義すること」を」 プロトコルREFERENCEに送ります。
::= {
tcp 18,
udp 18 }
::= tcp18、udp18
chargen PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Character Generator Protocol; a debugging tool for TCP and UDP
transports."
REFERENCE
"RFC 864 [RFC864] defines the Character Generator Protocol."
chargenプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「文字発生機構プロトコル」。 「TCPとUDP輸送のためのデバッグ用ツール。」 REFERENCE、「RFC864[RFC864]はキャラクターGeneratorプロトコルを定義します」。
Bierman, et al. Informational [Page 21] RFC 2896 RMON PI Macros August 2000
Bierman、他 [21ページ]情報のRFC2896RMONパイマクロ2000年8月
::= {
tcp 19,
udp 19 }
::= tcp19、udp19
ftp-data PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Data Port; the FTP Server process
default data-connection port. "
REFERENCE
"RFC 959 [RFC959] defines the File Transfer Protocol. Refer to
section 3.2 of [RFC959] for details on FTP data connections."
::= { tcp 20 }
ftp-データプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「ファイル転送プロトコルデータは移植する」記述。 FTP Serverはデフォルトデータ接続ポートを処理します。 "REFERENCE"RFC959[RFC959]はFile Transferプロトコルを定義します。 「FTPデータ接続に関する詳細について[RFC959]のセクション3.2を参照してください。」 ::= tcp20
ftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Control Port; An FTP client initiates
an FTP control connection by sending FTP commands from user port
(U) to this port."
REFERENCE
"RFC 959 [RFC959] defines the File Transfer Protocol."
::= { tcp 21 }
ftpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「ファイル転送プロトコルコントロールは移植する」記述。 「FTPクライアントはユーザポート(U)からこのポートまでのFTPコマンドを送ることによって、FTPコントロール接続を開始します。」 REFERENCE、「RFC959[RFC959]はFile Transferプロトコルを定義します」。 ::= tcp21
telnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Telnet Protocol; The purpose of the TELNET Protocol is to
provide a fairly general, bi-directional, eight-bit byte oriented
communications facility. Its primary goal is to allow a standard
method of interfacing terminal devices and terminal-oriented
processes to each other. "
REFERENCE
"RFC 854 [RFC854] defines the basic Telnet Protocol."
::= { tcp 23 }
telnetプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「テルネット・プロトコル」。 TELNETプロトコルの目的はかなり一般的で、双方向の、そして、8ビットのバイト指向のコミュニケーション施設を提供することです。 プライマリ目標は端末装置と端末指向のプロセスを互いに連結する標準方法を許容することです。 「"REFERENCE"RFC854[RFC854]は基本的なテルネット・プロトコルを定義します。」 ::= tcp23
priv-mail PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private mail system."
REFERENCE
"[RFC1700]"
::= { tcp 24,
udp 24 }
priv-メールプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「いずれのためにも予約された疑似プロトコルの個人的なメールシステム。」 以下に参照をつけてください「[RFC1700]」という:= tcp24、udp24
Bierman, et al. Informational [Page 22] RFC 2896 RMON PI Macros August 2000
Bierman、他 [22ページ]情報のRFC2896RMONパイマクロ2000年8月
smtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Simple Mail Transfer Protocol; SMTP control and data
messages are sent on this port."
REFERENCE
"RFC 821 [RFC821] defines the basic Simple Mail Transfer
Protocol."
::= { tcp 25 }
smtpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「簡単な郵便為替は議定書の中で述べる」記述。 「SMTPコントロールとデータメッセージをこのポートに送ります。」 REFERENCE、「RFC821[RFC821]は基本的なシンプルメールトランスファプロトコルを定義します」。 ::= tcp25
priv-print PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private printer server."
REFERENCE
"[RFC1700]"
::= { tcp 35,
udp 35 }
priv-印刷プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「どんな個人的なプリンタのためにも予約された疑似プロトコルサーバ」 「[RFC1700]」という記述REFERENCE:、:= tcp35、udp35
time PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Time Protocol"
REFERENCE
"RFC 868 [RFC868] defines the Time Protocol."
::= { tcp 37,
udp 37 }
時間プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「」 「RFC868[RFC868]はTimeプロトコルを定義する」時間プロトコルREFERENCE。 ::= tcp37、udp37
rap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Route Access Protocol"
REFERENCE
"RFC 1476 [RFC1476] defines the Internet Route Access Protocol."
::= { tcp 38 }
ルートアクセスは」 REFERENCEについて議定書の中で述べます。プロトコル-IDENTIFIER PARAMETERSを叩いてください、ATTRIBUTES、記述、「「RFC1476[RFC1476]はインターネットRoute Accessプロトコルを定義します」。 ::= tcp38
rlp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Resource Location Protocol"
REFERENCE
"RFC 887 [RFC887] defines the Resource Location Protocol."
::= { udp 39 }
リソース位置は」 REFERENCEについて議定書の中で述べます。rlpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC887[RFC887]はResource Locationプロトコルを定義します」。 ::= udp39
Bierman, et al. Informational [Page 23] RFC 2896 RMON PI Macros August 2000
Bierman、他 [23ページ]情報のRFC2896RMONパイマクロ2000年8月
graphics PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Graphics Protocol"
REFERENCE
"RFC 493 [RFC493] defines the Graphics Protocol."
::= { tcp 41,
udp 41 }
グラフィックスは」 REFERENCEについて議定書の中で述べます。グラフィックスプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC493[RFC493]はGraphicsプロトコルを定義します」。 ::= tcp41、udp41
nameserver PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Host Name Server Protocol"
REFERENCE
"IEN 116 [IEN116] defines the Internet Name Server."
::= { udp 42 }
ネームサーバプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「ホストが「IEN116[IEN116]はインターネットName Serverを定義する」と」 サーバプロトコルREFERENCEを命名する、:、:= udp42
nicname PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NICNAME/WHOIS Protocol"
REFERENCE
"RFC 954 [RFC954] defines the NICNAME/Who Is Protocol."
::= { tcp 43 }
nicnameプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「NICNAME/WHOISプロトコル」REFERENCE、「RFC954[RFC954]がNICNAME/を定義する、だれ、Isプロトコル、」 ::= tcp43
mpm-flags PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"MPM FLAGS Protocol; (historical)."
REFERENCE
"RFC 759 [RFC759] defines the Message Processing Module."
::= { tcp 44 }
mpm旗のプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「mpmはプロトコルに旗を揚げます」。 (歴史的)です。「」 . REFERENCE、「RFC759[RFC759]はMessage Processing Moduleを定義します」。 ::= tcp44
mpm PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Message Processing Module -- Receiver; (historical)."
REFERENCE
"RFC 759 [RFC759] defines the Message Processing Module."
::= { tcp 45 }
mpm、プロトコル識別子パラメタ、属性、記述は「モジュール--受信機を処理して、通信します」。 (歴史的)です。「」 . REFERENCE、「RFC759[RFC759]はMessage Processing Moduleを定義します」。 ::= tcp45
mpm-snd PROTOCOL-IDENTIFIER
PARAMETERS { }
mpm-sndプロトコル-IDENTIFIER PARAMETERS{ }
Bierman, et al. Informational [Page 24] RFC 2896 RMON PI Macros August 2000
Bierman、他 [24ページ]情報のRFC2896RMONパイマクロ2000年8月
ATTRIBUTES { }
DESCRIPTION
"Message Processing Module -- Default Send; (historical)."
REFERENCE
"RFC 759 [RFC759] defines the Message Processing Module."
::= { tcp 46 }
属性、記述、「処理モジュールを通信させてください--デフォルトは発信します」。 (歴史的)です。「」 . REFERENCE、「RFC759[RFC759]はMessage Processing Moduleを定義します」。 ::= tcp46
tacacs PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Login Host Protocol (TACACS)"
REFERENCE
"An Access Control Protocol, Sometimes Called TACACS [RFC1492]."
::= { tcp 49 }
tacacsプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「時々TACACS[RFC1492]と呼ばれて、アクセス制御は議定書の中で述べる」記述「ログインホストプロトコル(TACACS)」REFERENCE。 ::= tcp49
re-mail-ck PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Mail Checking Protocol"
REFERENCE
"RFC 1339 [RFC1339] defines the Remote Mail Checking Protocol."
::= { udp 50 }
リモートメールの照合は」 REFERENCEについて議定書の中で述べます。メールの再ckプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1339[RFC1339]はRemoteメールCheckingプロトコルを定義します」。 ::= udp50
xns-time PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS Time Protocol"
REFERENCE
"Xerox Corporation"
::= { tcp 52,
udp 52 }
xns-時間プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「XNS時間プロトコル」REFERENCE「ゼロックス社」:、:= tcp52、udp52
domain PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Domain Name Service Protocol; DNS may be transported by either
UDP [RFC768] or TCP [RFC793]. If the transport is UDP, DNS
requests restricted to 512 bytes in length may be sent to this
port."
REFERENCE
"RFC 1035 [RFC1035] defines the Bootstrap Protocol."
::= { udp 53,
tcp 53 }
ドメインプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ドメイン名サービスプロトコル」。 DNSはUDP[RFC768]かTCP[RFC793]のどちらかによって輸送されるかもしれません。 「輸送がUDPであるなら、長さ512バイトに制限されたDNS要求をこのポートに送るかもしれません。」 REFERENCE、「RFC1035[RFC1035]はBootstrapプロトコルを定義します」。 ::= udp53、tcp53
Bierman, et al. Informational [Page 25] RFC 2896 RMON PI Macros August 2000
Bierman、他 [25ページ]情報のRFC2896RMONパイマクロ2000年8月
xns-ch PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS Clearinghouse"
REFERENCE
"Xerox Corporation"
::= { tcp 54,
udp 54 }
xns-chプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「XNS情報センター」REFERENCE「ゼロックス社」:、:= tcp54、udp54
xns-auth PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS Authentication Protocol"
REFERENCE
"Xerox Corporation"
::= { tcp 56,
udp 56 }
xns-authプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「XNS認証プロトコル」REFERENCE「ゼロックス社」:、:= tcp56、udp56
priv-term PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private terminal access
protocol."
REFERENCE
"[RFC1700]"
::= { tcp 57,
udp 57 }
priv-用語プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「いずれのためにも予約された疑似プロトコルの個人的な端末のアクセス・プロトコル。」 以下に参照をつけてください「[RFC1700]」という:= tcp57、udp57
xns-mail PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS Mil Protocol"
REFERENCE
"Xerox Corporation"
::= { tcp 58,
udp 58 }
xns-メールプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「XNSミルプロトコル」REFERENCE「ゼロックス社」:、:= tcp58、udp58
priv-file PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private file service."
REFERENCE
"[RFC1700]"
priv-ファイルプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「いずれのためにも予約された疑似プロトコルの個人的なファイルサービス。」 「[RFC1700]」という参照
Bierman, et al. Informational [Page 26] RFC 2896 RMON PI Macros August 2000
Bierman、他 [26ページ]情報のRFC2896RMONパイマクロ2000年8月
::= { tcp 59,
udp 59 }
::= tcp59、udp59
tacacs-ds PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Default Server Port; TACACS Access Control Protocol Database
Service."
REFERENCE
"RFC 1492 [RFC1492] defines the TACACS Protocol."
::= { tcp 65 }
tacacs-dsプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「標準サーバーポート」。 「TACACSは制御プロトコルデータベース・サービスにアクセスします。」 REFERENCE、「RFC1492[RFC1492]はTACACSプロトコルを定義します」。 ::= tcp65
sqlnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Oracle SQL*NET"
REFERENCE
"Oracle Corporation"
::= { tcp 66 }
sqlnetプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「オラクルSQL*ネット」REFERENCE「オラクル株式会社」:、:= tcp66
bootps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Server Protocol; BOOTP Clients send requests
(usually broadcast) to the bootps port."
REFERENCE
"RFC 951 [RFC951] defines the Bootstrap Protocol."
::= { udp 67 }
bootpsプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述は「プロトコルサーバプロトコルを独力で進みます」。 「BOOTP Clientsは要求(通常、放送する)をbootpsポートに送ります。」 REFERENCE、「RFC951[RFC951]はBootstrapプロトコルを定義します」。 ::= udp67
bootpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Client Protocol; BOOTP Server replies are
sent to the BOOTP Client using this destination port."
REFERENCE
"RFC 951 [RFC951] defines the Bootstrap Protocol."
::= { udp 68 }
bootpcプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述は「プロトコルクライアントプロトコルを独力で進みます」。 「この仕向港を使用することでBOOTP Server回答をBOOTP Clientに送ります。」 REFERENCE、「RFC951[RFC951]はBootstrapプロトコルを定義します」。 ::= udp68
tftp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES { }
DESCRIPTION
tftpプロトコル-IDENTIFIER PARAMETERS tracksSessions(1)、ATTRIBUTES、記述
Bierman, et al. Informational [Page 27] RFC 2896 RMON PI Macros August 2000
Bierman、他 [27ページ]情報のRFC2896RMONパイマクロ2000年8月
"Trivial File Transfer Protocol; Only the first packet of each
TFTP transaction will be sent to port 69. If the tracksSessions
attribute is set, then packets for each TFTP transaction will be
attributed to tftp, instead of the unregistered port numbers that
will be encoded in subsequent packets."
REFERENCE
"RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2);
RFC 1782 [RFC1782] defines TFTP Option Extensions;
RFC 1783 [RFC1783] defines the TFTP Blocksize Option;
RFC 1784 [RFC1784] defines TFTP Timeout Interval and Transfer
Size Options."
::= { udp 69 }
「トリビアル・ファイル転送プロトコル」。 69を移植するためにそれぞれのTFTPトランザクションの最初のパケットだけを送るでしょう。 「tracksSessions属性が設定されるなら、それぞれのTFTPトランザクションのためのパケットはtftpの結果と考えられるでしょう、その後のパケットでコード化される登録されていないポートナンバーの代わりに。」 REFERENCE、「RFC1350[RFC1350]はTFTPプロトコル(改正2)を定義します」。 RFC1782[RFC1782]はTFTP Option Extensionsを定義します。 RFC1783[RFC1783]はTFTP Blocksize Optionを定義します。 「RFC1784[RFC1784]はTFTP Timeout IntervalとTransfer Size Optionsを定義します。」 ::= udp69
gopher PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Gopher Protocol"
REFERENCE
"RFC 1436 [RFC1436] defines the Gopher Protocol."
::= { tcp 70 }
インターネットゴーファーは」 REFERENCEについて議定書の中で述べます。リスプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1436[RFC1436]はゴーファープロトコルを定義します」。 ::= tcp70
netrjs-1 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Job Service Protocol; (historical)."
REFERENCE
"RFC 740 [RFC740] defines the NETRJS Protocol."
::= { tcp 71 }
netrjs-1プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「リモート・ジョブサービスプロトコル」。 (歴史的)です。「」 . REFERENCE、「RFC740[RFC740]はNETRJSプロトコルを定義します」。 ::= tcp71
netrjs-2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Job Service Protocol; (historical)."
REFERENCE
"RFC 740 [RFC740] defines the NETRJS Protocol."
::= { tcp 72 }
netrjs-2プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「リモート・ジョブサービスプロトコル」。 (歴史的)です。「」 . REFERENCE、「RFC740[RFC740]はNETRJSプロトコルを定義します」。 ::= tcp72
netrjs-3 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Job Service Protocol; (historical)."
REFERENCE
"RFC 740 [RFC740] defines the NETRJS Protocol."
::= { tcp 73 }
netrjs-3プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「リモート・ジョブサービスプロトコル」。 (歴史的)です。「」 . REFERENCE、「RFC740[RFC740]はNETRJSプロトコルを定義します」。 ::= tcp73
Bierman, et al. Informational [Page 28] RFC 2896 RMON PI Macros August 2000
Bierman、他 [28ページ]情報のRFC2896RMONパイマクロ2000年8月
netrjs-4 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Job Service Protocol; (historical)."
REFERENCE
"RFC 740 [RFC740] defines the NETRJS Protocol."
::= { tcp 74 }
netrjs-4プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「リモート・ジョブサービスプロトコル」。 (歴史的)です。「」 . REFERENCE、「RFC740[RFC740]はNETRJSプロトコルを定義します」。 ::= tcp74
priv-dialout PROTOCOL-IDENTIFIER
priv-ダイヤルアウトプロトコル-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private dial out service."
REFERENCE
"[RFC1700]"
::= { tcp 75,
udp 75 }
PARAMETERS、ATTRIBUTES、記述「どんな個人的なダイヤルのためにも予約された疑似プロトコルの出ているサービス。」 以下に参照をつけてください「[RFC1700]」という:= tcp75、udp75
priv-rje PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private remote job entry
service."
REFERENCE
"[RFC1700]"
::= { tcp 77,
udp 77 }
priv-rjeプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「いずれのためにも予約された疑似プロトコルの個人的なリモートジョブエントリサービス。」 以下に参照をつけてください「[RFC1700]」という:= tcp77、udp77
finger PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Finger User Information Protocol"
REFERENCE
"RFC 1288 [RFC1288] defines the finger protocol."
::= { tcp 79 }
プロトコル-IDENTIFIER PARAMETERSを弄ってください、ATTRIBUTES、記述、「」 「RFC1288[RFC1288]は指のプロトコルを定義する」というユーザー情報プロトコルREFERENCEを弄ってください。 ::= tcp79
www-http PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Hypertext Transfer Protocol"
REFERENCE
"RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol
(HTTP/1.0).
ハイパーテキストは」 プロトコルREFERENCEを移します。www-httpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1945[RFC1945]はハイパーテキストTransferプロトコル(HTTP/1.0)を定義します」。
Bierman, et al. Informational [Page 29] RFC 2896 RMON PI Macros August 2000
Bierman、他 [29ページ]情報のRFC2896RMONパイマクロ2000年8月
RFC 2068 [RFC2068] defines the Hypertext Transfer Protocol
(HTTP/1.1).
RFC 2069 [RFC2069] defines an Extension to HTTP: Digest Access
Authentication.
RFC 2109 [RFC2109] defines the HTTP State Management Mechanism.
RFC 2145 [RFC2145] defines the use and interpretation of HTTP
version numbers."
::= { tcp 80 }
RFC2068[RFC2068]はハイパーテキストTransferプロトコル(HTTP/1.1)を定義します。 RFC2069[RFC2069]はExtensionをHTTPと定義します: アクセス認証を読みこなしてください。 RFC2109[RFC2109]はHTTP州Management Mechanismを定義します。 「RFC2145[RFC2145]はHTTPバージョン番号の使用と解釈を定義します。」 ::= tcp80
priv-termlink PROTOCOL-IDENTIFIER
priv-termlinkプロトコル-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol reserved for any private terminal link
protocol."
REFERENCE
"[RFC1700]"
::= { tcp 87,
udp 87 }
PARAMETERS、ATTRIBUTES、記述「いずれのためにも予約された疑似プロトコルの個人的な端末のリンク・プロトコル。」 以下に参照をつけてください「[RFC1700]」という:= tcp87、udp87
kerberos PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Kerberos Network Authentication Service (V5)"
REFERENCE
"RFC 1510 [RFC1510] defines the Kerberos protocol."
::= { udp 88 }
ケルベロスは」 認証サービス(V5)REFERENCEをネットワークでつなぎます。kerberosプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1510[RFC1510]はケルベロスプロトコルを定義します」。 ::= udp88
supdup PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SUPDUP Display; (historical)"
REFERENCE
"RFC 734 [RFC734] defines the SUPDUP Protocol."
::= { tcp 95 }
supdupプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「SUPDUPディスプレイ」。 (歴史的)です。「"REFERENCE"RFC734[RFC734]はSUPDUPプロトコルを定義します。」 ::= tcp95
dixie PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DIXIE Directory Service"
REFERENCE
"RFC 1249 [RFC1249] defines the DIXIE Protocol."
::= { tcp 96,
udp 96 }
大きな鉄鍋のプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「デキシーディレクトリサービス」REFERENCE、「RFC1249[RFC1249]はデキシープロトコルを定義します」。 ::= tcp96、udp96
Bierman, et al. Informational [Page 30] RFC 2896 RMON PI Macros August 2000
Bierman、他 [30ページ]情報のRFC2896RMONパイマクロ2000年8月
hostname PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NIC Internet Hostname Server Protocol; (historical)"
REFERENCE
"RFC 953 [RFC953] defines the Hostname Server Protocol."
::= { tcp 101 }
ホスト名プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「NICインターネットホスト名サーバプロトコル」。 (歴史的)です。「"REFERENCE"RFC953[RFC953]はHostname Serverプロトコルを定義します。」 ::= tcp101
3com-tsmux PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"3COM-TSMUX"
REFERENCE
"3Com, Inc."
::= { tcp 106,
udp 106 }
3com-tsmuxプロトコル識別子パラメタ、属性、記述"3COM-TSMUX"参照「3Com Inc.」:、:= tcp106、udp106
rtelnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote User Telnet Protocol; (historical)."
REFERENCE
"RFC 818 [RFC818] defines the Remote User Telnet Service."
::= { tcp 107 }
rtelnetプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「リモート・ユーザーテルネット・プロトコル」。 (歴史的)です。「」 . REFERENCE、「RFC818[RFC818]はRemote User Telnet Serviceを定義します」。 ::= tcp107
pop2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Post Office Protocol -- Version 2. Clients establish connections
with POP2 servers by using this destination port number.
Historical."
REFERENCE
"RFC 937 [RFC937] defines Version 2 of the Post Office Protocol."
::= { tcp 109 }
pop2プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「郵便局は議定書を作ります--バージョン2。」 クライアントは、POP2サーバでこの目的地ポートナンバーを使用することによって、関係を樹立します。 「歴史的です」。 REFERENCE、「RFC937[RFC937]はポストオフィスプロトコルのバージョン2を定義します」。 ::= tcp109
pop3 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Post Office Protocol -- Version 3. Clients establish connections
with POP3 servers by using this destination port number."
REFERENCE
"RFC 1725 [RFC1725] defines Version 3 of the Post Office
Protocol."
pop3プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「郵便局は議定書を作ります--バージョン3。」 「クライアントはPOP3サーバでこの目的地ポートナンバーを使用することによって、関係を樹立します。」 REFERENCE、「RFC1725[RFC1725]はポストオフィスプロトコルのバージョン3を定義します」。
Bierman, et al. Informational [Page 31] RFC 2896 RMON PI Macros August 2000
Bierman、他 [31ページ]情報のRFC2896RMONパイマクロ2000年8月
::= { tcp 110,
udp 110 } -- RFC defines tcp use
::= tcp110、udp110--RFCはtcp使用を定義します。
sunrpc PROTOCOL-IDENTIFIER
sunrpcプロトコル-IDENTIFIER
PARAMETERS {
tracksSessions(1) -- learn port mapping of programs
}
ATTRIBUTES {
hasChildren(0) -- port mapper function numbers
}
DESCRIPTION
"SUN Remote Procedure Call Protocol. Port mapper function
requests are sent to this destination port."
CHILDREN
"Specific RPC functions are represented as children of the sunrpc
protocol. Each 'RPC function protocol' is identified by its
function number assignment. RPC function number assignments are
defined by different naming authorities, depending on the
function identifier value.
From [RFC1831]:
hasChildren(0)--マッパ機能番号を移植してください。PARAMETERS、tracksSessions(1)--プログラムに関するポートマッピングを学んでください、ATTRIBUTES、記述「太陽遠隔手続き呼び出しプロトコル。」 「ポートマッパ機能要求をこの仕向港に送ります。」 CHILDREN、「sunrpcの子供が議定書を作るとき、特定のRPC機能は表されます」。 各'RPC機能プロトコル'は機能数の課題で特定されます。 機能識別子価値によって、RPC機能数の課題は異なった命名当局によって定義されます。 [RFC1831]から:
Program numbers are given out in groups of hexadecimal 20000000
(decimal 536870912) according to the following chart:
以下のチャートに応じて、16進20000000のグループにおける外にプログラム番号を与えます(10進536870912):
0 - 1fffffff defined by rpc@sun.com
20000000 - 3fffffff defined by user
40000000 - 5fffffff transient
60000000 - 7fffffff reserved
80000000 - 9fffffff reserved
a0000000 - bfffffff reserved
c0000000 - dfffffff reserved
e0000000 - ffffffff reserved
0-- rpc@sun.com 20000000によって定義された1fffffff--ユーザ40000000によって定義された3fffffff--5fffffffの一時的な60000000--7fffffffは80000000を予約しました--9fffffffはa0000000を予約しました--bfffffffはdfffffffがe0000000を予約したというffffffffが予約したc0000000を予約しました。
Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol
identifier component for 'sunrpc', followed by [ a.b.c.d ], where
a.b.c.d is the 32 bit binary RPC program number encoded in
network byte order. For example, a protocolDirID-fragment value
of:
0.0.0.111.0.1.134.163
'sunrpc'の子供がコード化される、[0.0 .0 .111('sunrpc'のためのプロトコル識別子コンポーネント)は][a.b.c.d]で続きました。そこでは、a.b.c.dはRPCプログラム番号がネットワークバイトオーダーでコード化した32ビットのバイナリーです。 例えば、以下のprotocolDirID-断片値 0.0.0.111.0.1.134.163
defines the NFS function (and protocol).
NFS機能(議定書を作る)を定義します。
Children are named as 'sunrpc' followed by the RPC function
number in base 10 format. For example, NFS would be named:
'sunrpc 100003'."
DECODING
"The first packet of many SUNRPC transactions is sent to the
ベース10形式におけるRPC機能番号に従って'sunrpc'が続いたので、子供は命名されます。 例えば、NFSは命名されるでしょう: 「'sunrpc100003'。」 DECODING、「多くのSUNRPCトランザクションの最初のパケットを送る、」
Bierman, et al. Informational [Page 32] RFC 2896 RMON PI Macros August 2000
Bierman、他 [32ページ]情報のRFC2896RMONパイマクロ2000年8月
port- mapper program, and therefore decoded statically by
monitoring RFC portmap requests [RFC1831]. Any subsequent packets
must be decoded and correctly identified by 'remembering' the
port assignments used in each RPC function call (as identified
according to the procedures in the RPC Specification Version 2
[RFC1831]).
マッパプログラムであって、したがって、RFC portmapをモニターすることによって静的に解読されたポートは[RFC1831]を要求します。 どんなその後のパケットも、解読されてそれぞれのRPCファンクションコールに使用されるポート課題が'覚えている'であることによって、正しく特定していなければなりません(RPC Specificationバージョン2[RFC1831]における手順によると、特定されるように)。
In some cases the port mapping for a particular protocol is well
known and hard coded into the requesting client. In these cases
the client will not send portmap requests; instead it will send
the SUNRPC request directly to the well known port. These cases
are rare and are being eliminated over time. NFS is the most
significant SUNRPC program of this class. Such programs should
still be declared as children of SUNRPC as described under
CHILDREN above. How an implementation detects this behaviour and
handles it is beyond the scope of this document.
いくつかの場合、特定のプロトコルのためのポートマッピングは、要求しているクライアントにコード化されていた状態でよく知られていて確実です。 これらの場合では、クライアントはportmap要求を送らないでしょう。 代わりに、それは直接よく知られているポートにSUNRPC要求を送るでしょう。 これらのケースは、まれであり、時間がたつにつれて、排除予定であるいことにされます。 NFSはこのクラスの最も重要なSUNRPCプログラムです。 そのようなプログラムは上のCHILDRENの下の説明されるとしてのSUNRPCの子供としてまだ申告されているべきです。 実装がどうこのふるまいを検出して、それを扱うかはこのドキュメントの範囲を超えています。
The 'tracksSessions(1)' PARAMETER bit is used to indicate whether
the probe can (and should) monitor portmapper activity to
correctly track SUNRPC connections."
REFERENCE
"RFC 1831 [RFC1831] defines the Remote Procedure Call Protocol
Version 2. The authoritative list of RPC Functions is identified
by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers"
::= { tcp 111,
udp 111 }
「'tracksSessions(1)'PARAMETERビットは徹底的調査がそうすることができるか否かに関係なく、(and should)が正しくSUNRPC接続を追跡するためにポートマッパー活動をモニターするのを示すのに使用されます。」 REFERENCE、「RFC1831[RFC1831]はRemote Procedure Callプロトコルバージョン2を定義します」。 RPC Functionsの正式のリストはURLによって特定されます: " ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers ":、:= tcp111、udp111
auth PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Authentication Service; Identification Protocol."
REFERENCE
"RFC 1413 [RFC1413] defines the Identification Protocol."
::= { tcp 113 }
authプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「認証サービス」。 「識別プロトコル。」 REFERENCE、「RFC1413[RFC1413]はIdentificationプロトコルを定義します」。 ::= tcp113
sftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple File Transfer Protocol; (historical)."
REFERENCE
"RFC 913 [RFC913] defines the Simple File Transfer Protocol."
::= { tcp 115 }
sftpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「簡単なファイル転送プロトコル」。 (歴史的)です。「」 . REFERENCE、「RFC913[RFC913]はSimple File Transferプロトコルを定義します」。 ::= tcp115
uucp-path PROTOCOL-IDENTIFIER
uucp-経路プロトコル-IDENTIFIER
Bierman, et al. Informational [Page 33] RFC 2896 RMON PI Macros August 2000
Bierman、他 [33ページ]情報のRFC2896RMONパイマクロ2000年8月
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"UUCP Path Service"
REFERENCE
"RFC 915 [RFC915] defines the Network Mail Path Service."
::= { tcp 117 }
UUCP経路は」 REFERENCEを調整します。PARAMETERS、ATTRIBUTES、記述、「「RFC915[RFC915]はNetworkメールPath Serviceを定義します」。 ::= tcp117
nntp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Network News Transfer Protocol"
REFERENCE
"RFC 977 [RFC977] defines the Network News Transfer Protocol."
::= { tcp 119 }
ネットニュースは」 プロトコルREFERENCEを移します。nntpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC977[RFC977]はネットワークの電子情報を転送するプロトコルを定義します」。 ::= tcp119
cfdptkt PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"CFDPTKT; Coherent File Distribution Protocol"
REFERENCE
"RFC 1235 [RFC1235] defines the Coherent File Distribution
Protocol."
::= { udp 120 }
cfdptktプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述"CFDPTKT"。 「コヒーレントFile Distributionプロトコル」REFERENCE、「RFC1235[RFC1235]はCoherent File Distributionプロトコルを定義します」。 ::= udp120
ntp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Network Time Protocol"
REFERENCE
"RFC 1305 [RFC1305] defines version 3 of the Network Time
Protocol."
::= { udp 123 }
ntpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「」 「RFC1305[RFC1305]はNetwork Timeプロトコルのバージョン3を定義する」時間プロトコルREFERENCEをネットワークでつないでください。 ::= udp123
pwdgen PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Password Generator Protocol"
REFERENCE
"RFC 972 [RFC972] defines the Password Generator Protocol."
::= { tcp 129,
udp 129 }
パスワードジェネレータは」 REFERENCEについて議定書の中で述べます。pwdgenプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC972[RFC972]はPassword Generatorプロトコルを定義します」。 ::= tcp129、udp129
cisco-fna PROTOCOL-IDENTIFIER
コクチマス-fnaプロトコル-IDENTIFIER
Bierman, et al. Informational [Page 34] RFC 2896 RMON PI Macros August 2000
Bierman、他 [34ページ]情報のRFC2896RMONパイマクロ2000年8月
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"cisco FNATIVE"
REFERENCE
"Cisco Systems, Inc."
::= { tcp 130,
udp 130 }
パラメタ、属性、「シスコシステムズInc.」という記述「コクチマスFNATIVE」参照:、:= tcp130、udp130
cisco-tna PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"cisco TNATIVE"
REFERENCE
"Cisco Systems, Inc."
::= { tcp 131,
udp 131 }
コクチマス-tnaプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「コクチマスTNATIVE」REFERENCE「シスコシステムズInc.」:、:= tcp131、udp131
cisco-sys PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"cisco SYSMAINT"
REFERENCE
"Cisco Systems, Inc."
::= { tcp 132,
udp 132 }
コクチマス-sysプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「コクチマスSYSMAINT」REFERENCE「シスコシステムズInc.」:、:= tcp132、udp132
statsrv PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Statistics Server; (historical)."
REFERENCE
"RFC 996 [RFC996] defines the Statistics Server Protocol."
::= { tcp 133,
udp 133 }
statsrvプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「統計サーバ」。 (歴史的)です。「」 . REFERENCE、「RFC996[RFC996]はStatistics Serverプロトコルを定義します」。 ::= tcp133、udp133
-- defined as nbt-name in IPX section -- netbios-ns 137/tcp NETBIOS Name Service -- netbios-ns 137/udp NETBIOS Name Service -- defined as nbt-data in IPX section -- netbios-dgm 138/tcp NETBIOS Datagram Service -- netbios-dgm 138/udp NETBIOS Datagram Service
-- IPX部--netbios-dgm138/tcp NETBIOSデータグラムService--netbios-dgm138/udp NETBIOSデータグラムServiceでIPX部--netbios-ナノ秒137/tcp NETBIOS Name Service--netbios-ナノ秒137/udp NETBIOS Name Service--nbt-データと定義されるのにおいてnbt-名前と定義されます。
-- defined as nbt-session in IPX section -- netbios-ssn 139/tcp NETBIOS Session Service
-- IPX部でnbt-セッションと定義されます--、netbios-ssn139/tcp NETBIOS Session Service
Bierman, et al. Informational [Page 35] RFC 2896 RMON PI Macros August 2000
Bierman、他 [35ページ]情報のRFC2896RMONパイマクロ2000年8月
-- netbios-ssn 139/udp NETBIOS Session Service
-- netbios-ssn139/udp NETBIOS Session Service
imap2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Interactive Mail Access Protocol v2;
Internet Message Access Protocol v4 (IMAP4) also uses this
server port."
REFERENCE
"RFC 1064 [RFC1064] defines Version 2 of the Interactive Mail
Access
Protocol.
RFC 1730 [RFC1730] defines Version 4 of the Internet Message
Access
Protocol."
::= { tcp 143 }
imap2プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「対話的なメールAccessプロトコルv2」。 「また、インターネットMessage Accessプロトコルv4(IMAP4)はこのサーバポートを使用します。」 REFERENCE、「RFC1064[RFC1064]はInteractiveメールAccessプロトコルのバージョン2を定義します」。 「RFC1730[RFC1730]はインターネットMessage Accessプロトコルのバージョン4を定義します。」 ::= tcp143
iso-tp0 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ISO-IP0; ISO-TP0 bridge between TCP and X.25"
REFERENCE
"RFC 1086 [RFC1086] defines the ISO-TP0 protocol."
::= { tcp 146,
udp 146 }
iso-tp0プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述"ISO-IP0"。 ISO-TP0はTCPとX.25" REFERENCEの間でブリッジします。「RFC1086[RFC1086]はISO-TP0プロトコルを定義します」。 ::= tcp146、udp146
iso-ip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ISO-IP; Use of the Internet as a Subnetwork for Experimentation
with the OSI Network Layer"
REFERENCE
"RFC 1070 [RFC1070] defines the ISO-IP Protocol."
::= { tcp 147,
udp 147 }
iso-ipプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ISO-IP」。 「SubnetworkとしてのインターネットのOSI Network LayerとExperimentationの使用」REFERENCE、「RFC1070[RFC1070]はISO-IPプロトコルを定義します」。 ::= tcp147、udp147
hems PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"HEMS; High Level Entity Management System; (historical)."
REFERENCE
"RFC 1021 [RFC1021] defines HEMS."
::= { tcp 151 }
ヘリプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述は「へりを取ります」。 高い平らな実体マネージメントシステム。 (歴史的)です。「」 . REFERENCE、「RFC1021[RFC1021]はHEMSを定義する」、:、:= tcp151
Bierman, et al. Informational [Page 36] RFC 2896 RMON PI Macros August 2000
Bierman、他 [36ページ]情報のRFC2896RMONパイマクロ2000年8月
bftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Background File Transfer Program"
REFERENCE
"RFC 1068 [RFC1068] defines the Background File Transfer
Program."
::= { tcp 152 }
バックグラウンドファイル転送は」 REFERENCEをプログラムします。bftpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1068[RFC1068]はBackground File Transfer Programを定義します」。 ::= tcp152
sgmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Gateway Monitoring Protocol; (historical)."
REFERENCE
"RFC 1028 [RFC1028] defines the Simple Gateway Monitoring
Protocol."
::= { udp 153 }
sgmpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「簡単なゲートウェイモニターしているプロトコル」。 (歴史的)です。「」 . REFERENCE、「RFC1028[RFC1028]はSimpleゲートウェイMonitoringプロトコルを定義します」。 ::= udp153
pcmail-srv PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"PCMail Server; Distributed Mail System Protocol (DMSP)"
REFERENCE
"RFC 1056 [RFC1056] defines the PCMAIL Protocol."
::= { tcp 158 }
pcmail-srvプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「PCMailサーバ」。 「分配されたメールSystemプロトコル(DMSP)」REFERENCE、「RFC1056[RFC1056]はPCMAILプロトコルを定義します」。 ::= tcp158
sgmp-traps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Gateway Monitoring Protocol Traps; (historical)."
REFERENCE
"RFC 1028 [RFC1028] defines the Simple Gateway Monitoring
sgmp-罠プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「簡単なゲートウェイモニターしているプロトコル罠」。 (歴史的)です。「」 . REFERENCE、「RFC1028[RFC1028]はSimpleゲートウェイMonitoringを定義します」。
Protocol."
::= { udp 160 }
「議定書を作ってください。」 ::= udp160
-- snmp and snmptrap found in the Protocol-Independent section -- snmp 161/udp SNMP -- snmptrap 162/udp SNMPTRAP
-- プロトコルから独立しているセクション--snmp161/udp SNMP--snmptrap162/udp SNMPTRAPで見つけられたsnmpとsnmptrap
cmip-man PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
cmip-男性プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述
Bierman, et al. Informational [Page 37] RFC 2896 RMON PI Macros August 2000
Bierman、他 [37ページ]情報のRFC2896RMONパイマクロ2000年8月
"CMIP/TCP (CMOT) Manager; (historical)."
REFERENCE
"RFC 1095 [RFC1095] defines the Common Management Information
Services and Protocol over TCP/IP."
::= { tcp 163,
udp 163 }
「CMIP/TCP(CMOT)マネージャ」。 (歴史的)です。「」 . REFERENCE、「RFC1095[RFC1095]はTCP/IPの上でCommon Management情報Servicesとプロトコルを定義します」。 ::= tcp163、udp163
cmip-agent PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"CMIP/TCP (CMOT) Agent; (historical)."
REFERENCE
"RFC 1095 [RFC1095] defines the Common Management Information
Services and Protocol over TCP/IP."
::= { tcp 164,
udp 164 }
cmip-エージェントプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「CMIP/TCP(CMOT)エージェント」。 (歴史的)です。「」 . REFERENCE、「RFC1095[RFC1095]はTCP/IPの上でCommon Management情報Servicesとプロトコルを定義します」。 ::= tcp164、udp164
xdmcp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"X Display Manager Control Protocol"
REFERENCE
"X11 Consortium"
::= { udp 177 }
xdmcpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「Xディスプレイマネージャ制御プロトコル」REFERENCE「X11共同体」:、:= udp177
bgp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Border Gateway Protocol"
REFERENCE
"RFC 1267 [RFC1267] defines version 3 of the Border Gateway
bgpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ボーダ・ゲイトウェイ・プロトコル」REFERENCE、「RFC1267[RFC1267]はBorderゲートウェイのバージョン3を定義します」。
Protocol."
::= { tcp 179 }
「議定書を作ってください。」 ::= tcp179
remote-kis PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote-Knowbot Information Service (KIS)"
REFERENCE
"RFC 1739 [RFC1739] describes the KNOWBOT Protocol."
::= { tcp 185,
udp 185 }
リモートKnowbot情報は」 REFERENCEを調整します(キシュ)。リモートkisプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1739[RFC1739]はKNOWBOTプロトコルについて説明します」。 ::= tcp185、udp185
Bierman, et al. Informational [Page 38] RFC 2896 RMON PI Macros August 2000
Bierman、他 [38ページ]情報のRFC2896RMONパイマクロ2000年8月
kis PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Knowbot Information Service (KIS)"
REFERENCE
"RFC 1739 [RFC1739] describes the KNOWBOT Protocol."
::= { tcp 186,
udp 186 }
Knowbot情報は」 (キシュ)REFERENCEを調整します。kisプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1739[RFC1739]はKNOWBOTプロトコルについて説明します」。 ::= tcp186、udp186
irc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Relay Chat Protocol"
REFERENCE
"RFC 1459 [RFC1459] defines the Internet Relay Chat Protocol."
::= { tcp 194,
udp 194 }
インターネットは」 チャットプロトコルREFERENCEをリレーします。ircプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1459[RFC1459]はインターネットRelay Chatプロトコルを定義します」。 ::= tcp194、udp194
smux PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SMUX; SNMP MUX Protocol and MIB; (historical)."
REFERENCE
"RFC 1227 [RFC1227] defines the SMUX Protocol."
::= { tcp 199 }
smuxプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述"SMUX"。 SNMP多重化装置プロトコルとMIB。 (歴史的)です。「」 . REFERENCE、「RFC1227[RFC1227]はSMUXプロトコルを定義します」。 ::= tcp199
-- -- AppleTalk applications are defined in the AppleTalk Stack section -- -- at-rtmp 201/tcp AppleTalk Routing Maintenance -- at-rtmp 201/udp AppleTalk Routing Maintenance -- at-nbp 202/tcp AppleTalk Name Binding -- at-nbp 202/udp AppleTalk Name Binding -- at-3 203/tcp AppleTalk Unused -- at-3 203/udp AppleTalk Unused -- at-echo 204/tcp AppleTalk Echo -- at-echo 204/udp AppleTalk Echo -- at-5 205/tcp AppleTalk Unused -- at-5 205/udp AppleTalk Unused -- at-zis 206/tcp AppleTalk Zone Information -- at-zis 206/udp AppleTalk Zone Information -- at-7 207/tcp AppleTalk Unused -- at-7 207/udp AppleTalk Unused -- at-8 208/tcp AppleTalk Unused -- at-8 208/udp AppleTalk Unused
-- -- AppleTalkアプリケーションはAppleTalk Stack部--rtmpの--rtmpの201/tcp AppleTalkルート設定Maintenance--201/udp AppleTalkルート設定Maintenance--nbpの202/tcp AppleTalk Name Binding--nbpの202/udp AppleTalk Name Binding---3における203/tcp AppleTalk Unused---3における203/udp AppleTalk Unused--エコーの204/tcp AppleTalk Echoで定義されます; エコーの204/udp AppleTalk Echo---5における205/tcp AppleTalk Unused---5における205/udp AppleTalk Unused--zisの206/tcp AppleTalk Zone情報--zisの206/udp AppleTalk Zone情報---7における207/tcp AppleTalk Unused---7における207/udp AppleTalk Unused---8における208/tcp AppleTalk Unused---8における208/udp AppleTalk Unused
Bierman, et al. Informational [Page 39] RFC 2896 RMON PI Macros August 2000
Bierman、他 [39ページ]情報のRFC2896RMONパイマクロ2000年8月
z39-50 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"ANSI Z39.50"
REFERENCE
"RFC 1729 [RFC1729] describes the Z39.50 Protocol."
::= { tcp 210 }
z39-50プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「ANSI Z39.50"参照、「RFC1729[RFC1729]はZ39.50プロトコルについて説明する」、」 ::= tcp210
ipx-tunnel PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Tunneling IPX Traffic through IP Networks"
REFERENCE
"RFC 1234 [RFC1234] defines the IPX Tunnel Protocol."
::= { udp 213 }
ipx-トンネルプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「」 IPネットワークREFERENCEを通してIPXトラフィックにトンネルを堀って、「RFC1234[RFC1234]はIPX Tunnelプロトコルを定義します」。 ::= udp213
mpp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Netix Message Posting Protocol"
REFERENCE
"RFC 1204 [RFC1204] defines the Message Posting Protocol."
::= { tcp 218 }
mppプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「」 プロトコルREFERENCEを掲示して、「RFC1204[RFC1204]はMessage Postingプロトコルを定義する」というNetixメッセージ。 ::= tcp218
imap3 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Interactive Mail Access Protocol v3; (historical)."
REFERENCE
"RFC 1203 [RFC1203] defines version 3 of the Interactive Mail
Access Protocol."
::= { tcp 220 }
imap3プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「対話的なメールAccessプロトコルv3」。 (歴史的)です。「」 . REFERENCE、「RFC1203[RFC1203]はInteractiveメールAccessプロトコルのバージョン3を定義します」。 ::= tcp220
ldap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Lightweight Directory Access Protocol"
REFERENCE
"RFC 1777 [RFC1777] defines Lightweight Directory Access
Protocol; RFC 1798 [RFC1798] defines Connection-less Lightweight
X.500 Directory Access Protocol"
::= { tcp 389, -- RFC 1777
udp 389 } -- RFC 1798
軽量のディレクトリアクセスは」 REFERENCEについて議定書の中で述べます。ldapプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC1777[RFC1777]はライトウェイト・ディレクトリ・アクセス・プロトコルを定義します」。 「RFC1798[RFC1798]はConnectionなしのライト級X.500ディレクトリAccessプロトコルを定義する」:、:= tcp389、--、RFC1777が389をudpする--、RFC1798
Bierman, et al. Informational [Page 40] RFC 2896 RMON PI Macros August 2000
Bierman、他 [40ページ]情報のRFC2896RMONパイマクロ2000年8月
mobileip-agent PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IP Mobility Support"
REFERENCE
"RFC 2002 [RFC2002] defines the IP Mobility Support protocol."
::= { udp 434 }
mobileip-エージェントプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「IPの移動性は、」 REFERENCEが「RFC2002[RFC2002]はIP Mobility Supportプロトコルを定義します」であるとサポートします。 ::= udp434
https PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Secure HTTP; HTTP over TLS/SSL"
REFERENCE
"Netscape; http://home.netscape.com/eng/ssl3/"
::= { tcp 443 }
httpsプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「安全なHTTP」。 「Netscape」という「TLS/SSLの上のHTTP」参照。 " http://home.netscape.com/eng/ssl3/ ":、:= tcp443
smtps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SMTP protocol over TLS/SSL"
REFERENCE
"Netscape; http://home.netscape.com/eng/ssl3/"
::= { tcp 465 }
smtpsプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「SMTPはTLS/SSLの上で議定書を作る」REFERENCE「Netscape」。 " http://home.netscape.com/eng/ssl3/ ":、:= tcp465
isakmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Security Association and Key Management Protocol
(ISAKMP)"
REFERENCE
"RFC 2408 [RFC2408]"
::= { udp 500 }
isakmpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「インターネットセキュリティ協会とKey Managementプロトコル(ISAKMP)」REFERENCE「RFC2408[RFC2408]」:、:= udp500
login PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"BSD Rlogin; remote login a la telnet"
REFERENCE
"RFC 1282 [RFC1282] defines the BSD Rlogin Protocol."
::= { tcp 513 }
ログインプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述"BSD Rlogin"。 」 telnet REFERENCEのようにログインしてください。「リモートである、「RFC1282[RFC1282]はBSD Rloginプロトコルを定義します」。 ::= tcp513
syslog PROTOCOL-IDENTIFIER
PARAMETERS { }
syslogプロトコル-IDENTIFIER PARAMETERS{ }
Bierman, et al. Informational [Page 41] RFC 2896 RMON PI Macros August 2000
Bierman、他 [41ページ]情報のRFC2896RMONパイマクロ2000年8月
ATTRIBUTES { }
DESCRIPTION
"syslog"
REFERENCE
"[RFC1700]"
::= { udp 514 }
属性、記述"syslog"は以下に参照をつけます「[RFC1700]」という:= udp514
uucp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Unix-to-Unix copy protocol"
REFERENCE
"[RFC1700]"
::= { tcp 540 }
uucpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「[RFC1700]」という記述「unixからunixへのコピープロトコル」REFERENCE:、:= tcp540
doom PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DOOM Game;"
REFERENCE
" Id Software"
::= { tcp 666 }
破滅プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「破滅ゲーム」。 「イドソフトウェア」という参照:、:= tcp666
radius PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Remote Authentication Dial In User Service (RADIUS)"
REFERENCE
"RFC 2138 [RFC2138] defines the Radius protocol."
::= { udp 1812 }
リモート認証はユーザサービス(半径)で」 REFERENCEにダイヤルします。半径プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「「RFC2138[RFC2138]はRadiusプロトコルを定義します」。 ::= udp1812
radiusacct PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"RADIUS Accounting Protocol"
REFERENCE
"RFC 2139 [RFC2139] defines the Radius Accounting protocol."
::= { udp 1813 }
radiusacctプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「」 プロトコルREFERENCEが「RFC2139[RFC2139]はRadius Accountingプロトコルを定義します」であると説明する半径。 ::= udp1813
-- -- Portmapper Functions; Children of sunrpc --
-- -- ポートマッパー機能。 sunrpcの子供--
portmapper PROTOCOL-IDENTIFIER
ポートマッパープロトコル-IDENTIFIER
Bierman, et al. Informational [Page 42] RFC 2896 RMON PI Macros August 2000
Bierman、他 [42ページ]情報のRFC2896RMONパイマクロ2000年8月
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"SUNRPC PORTMAPPER program. This is the SUNRPC program which is
used to locate the UDP/TCP ports on which other SUNRPC programs
can be found."
REFERENCE
"Appendix A of RFC 1057 [RFC1057] describes the portmapper
operation."
::= { sunrpc 100000 }
PARAMETERS、ATTRIBUTES、記述「SUNRPC PORTMAPPERプログラム。」 「これは他のSUNRPCプログラムを見つけることができるUDP/TCPポートの場所を見つけるのに使用されるSUNRPCプログラムです。」 REFERENCE、「RFC1057[RFC1057]の付録Aはポートマッパー操作について説明します」。 ::= sunrpc100000
nfs PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Sun Network File System (NFS);"
DECODING
"NFS is a SUNRPC program which may or may not use the port mapper
SUNRPC program to connect clients and servers. In many cases the
NFS server program runs over UDP/TCP port 2049, but an
implementation is encouraged to perform further analysis before
assuming that a packet to/from this port is a SUNRPC/NFS packet.
Likewise an implementation is encouraged to track port mapper
activity to spot cases where it is used to locate the SUNRPC/NFS
program as this is more robust."
REFERENCE
"The NFS Version 3 Protocol Specification is defined in RFC 1813
[RFC1813]."
::= {
sunrpc 100003 -- [0.1.134.163]
}
nfsプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「Sunネットワークファイルシステム(NFS)」。 DECODING、「NFSはクライアントとサーバに接するのにポートマッパSUNRPCプログラムを使用するかもしれないSUNRPCプログラムです」。 多くの場合、UDP/TCPの上のNFSサーバプログラム下痢は2049を移植しますが、実装がこのポートからの/へのパケットがSUNRPC/NFSパケットであると仮定する前にさらなる分析を実行するよう奨励されます。 「同様に実装がそれがこれが、より強健であるのでSUNRPC/NFSプログラムの場所を見つけるのに使用されるケースを見つけるためにポートマッパ活動を追跡するよう奨励されます。」 REFERENCE、「NFSバージョン3プロトコルSpecificationはRFC1813[RFC1813]で定義されます」。 ::= sunrpc100003--、[0.1、.134、.163]
xwin PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES { }
DESCRIPTION
"X Windows Protocol"
DECODING
"The X Windows Protocol when run over UDP/TCP normally runs over
the well known port 6000. It can run over any port in the range
6000 to 6063, however. If the tracksSessions(1) parameter bit is
set the agent can and should detect such X Window sessions and
report them as the X protocol."
REFERENCE
"The X Windows Protocol is defined by TBD"
::= {
X-windowsは」 DECODINGについて議定書の中で述べます。xwinプロトコル-IDENTIFIER PARAMETERS tracksSessions(1)、ATTRIBUTES、記述、「「通常UDP/TCPの上に実行されると、X-windowsプロトコルはよく知られているポート6000を中を走ります」。 しかしながら、それは範囲のどんなポートも6000年から6063に中を走らせることができます。「tracksSessions(1)パラメタビットが設定されるなら、エージェントは、報告できて、そのようなX windowセッションを検出して、Xプロトコルとしてそれらを報告するべきです。」 REFERENCE、「X-windowsプロトコルはTBDによって定義される」:、:= {
Bierman, et al. Informational [Page 43] RFC 2896 RMON PI Macros August 2000
Bierman、他 [43ページ]情報のRFC2896RMONパイマクロ2000年8月
tcp 6000,
udp 6000
-- lat ?
}
tcp6000、udp6000--lat? }
3.1.2. Novell IPX Stack
3.1.2. ノベルIPXスタック
ipx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
ipxプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTEShasChildren(0)、addressRecognitionCapable(1)
DESCRIPTION
"Novell IPX"
CHILDREN
"Children of IPX are defined by the 8 bit packet type field. The
value is encoded into an octet string as [ 0.0.0.a ], where 'a'
is the single octet of the packet type field.
記述「ノベルIPX」CHILDREN、「IPXの子供は8ビットのパケットタイプ分野によって定義されます」。 値は[0.0.0.a]として八重奏ストリングにコード化されます。そこでは、'a'がパケットタイプ分野のただ一つの八重奏です。
Notice that in many implementations of IPX usage of the packet
type field is inconsistent with the specification and
implementations are encouraged to use other techniques to map
inconsistent values to the correct value (which in these cases is
typically the Packet Exchange Protocol). It is beyond the scope
of this document to describe these techniques in more detail.
パケットタイプ分野のIPX用法の多くの実装で仕様に反している通知と実装が正しい値(通常、これらの場合でPacket Exchangeプロトコルである)に矛盾した値を写像するのに他のテクニックを使用するよう奨励されます。 それは、さらに詳細にこれらのテクニックについて説明するためにこのドキュメントの範囲を超えています。
Children of IPX are encoded as [ 0.0.0.a ], and named as 'ipx a'
where a is the packet type value. The novell echo protocol is
referred to as 'ipx nov-echo' OR 'ipx 2'."
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order."
REFERENCE
"The IPX protocol is defined by the Novell Corporation
IPXの子供は、aがパケットタイプ価値であるところで[0.0.0.a]としてコード化されて、'ipx a'として命名されます。 「novellエコープロトコルは'ipx nov-エコー'OR'ipx2'と呼ばれます。」 「4バイトのNetwork番号はそれぞれネットワークバイトオーダーにおける6バイトのHostアドレスで続いた」ADDRESS-FORMAT。 REFERENCE、「IPXプロトコルはノベル社によって定義されます」。
A complete description of IPX may be secured at the following
address:
Novell, Inc.
122 East 1700 South
P. O. Box 5900
Provo, Utah 84601 USA
800 526 5463
Novell Part # 883-000780-001"
::= {
ether2 0x8137, -- [0.0.129.55]
snap 0x8137, -- [0.0.129.55]
以下のアドレスでIPXの完全な記述を保証するかもしれません: ノベルInc.122の東1700南部では、私書箱5900プロボ、ユタ84601米国800 526 5463ノベルは以下を#883-0007801インチ分けます:= ether2 0x8137--、[0.0 .129 .55は]0×8137を折ります--[0.0.129.55]
Bierman, et al. Informational [Page 44] RFC 2896 RMON PI Macros August 2000
Bierman、他 [44ページ]情報のRFC2896RMONパイマクロ2000年8月
ianaAssigned 1, -- [0.0.0.1] (ipxOverRaw8023)
llc 224, -- [0.0.0.224]
802-1Q 0x8137, -- [0.0.129.55]
802-1Q 0x020000e0, -- 1Q-LLC [2.0.0.224]
802-1Q 0x05000001 -- 1Q-IANA [5.0.0.1]
-- (ipxOverRaw8023)
}
ianaAssigned1--、[0.0 .0 .1] (ipxOverRaw8023)llc224--、[0.0 .0 .224] 802-1 Q0x8137--、[0.0 .129 .55] 802-1 Q0x020000e0--、1Q-LLC、[2.0 .0 .224] 802-1 Q0x05000001--、1Q-IANA、[5.0、.0、.1]--、(ipxOverRaw8023)
nov-rip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell Routing Information Protocol"
REFERENCE
"Novell Corporation"
::= {
ipx 0x01, -- when reached by IPX packet type
nov-pep 0x0453 -- when reached by IPX socket number
}
nov-裂け目のプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ノベルルーティング情報プロトコル」REFERENCE「ノベル社」:、:= ipx0x01--IPXパケットで達していたら、IPXソケット番号で達していたら、nov-気力0×0453をタイプしてください。
nov-echo PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell Echo Protocol"
REFERENCE
"Novell Corporation"
::= { ipx 0x02 }
nov-エコープロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ノベルエコープロトコル」REFERENCE「ノベル社」:、:= ipx0x02
nov-error PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell Error-handler Protocol"
REFERENCE
"Novell Corporation"
::= { ipx 0x03 }
nov-誤りプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ノベル誤り操作者プロトコル」REFERENCE「ノベル社」:、:= ipx0x03
nov-pep PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Novell Packet Exchange Protocol. This is really a null protocol
layer as all IPX packets contain the relevant fields for this
protocol. This protocol is defined so that socket-based decoding
has a point of attachment in the decode tree while still allowing
nov-気力プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「ノベルパケット交換プロトコル。」 すべてのIPXパケットがこのプロトコルのための関連分野を含むとき、これは本当にヌルプロトコル層です。 このプロトコルが定義されるのでソケットベースの解読が中に接着点を持っている、まだ許容している間、木を解読してください。
Bierman, et al. Informational [Page 45] RFC 2896 RMON PI Macros August 2000
Bierman、他 [45ページ]情報のRFC2896RMONパイマクロ2000年8月
packet type based decoding also."
CHILDREN
"Children of PEP are defined by the 16 bit socket values. The
value is encoded into an octet string as [ 0.0.a.b ], where 'a'
and 'b' are the network byte order encodings of the MSB and LSB
of the socket value.
「パケットタイプは解読も基礎づけました。」 CHILDREN、「PEPの子供は16ビットのソケット値によって定義されます」。 値は[0.0.a.b]として八重奏ストリングにコード化されます。そこでは、'a'と'b'は、ネットワークバイトオーダーのMSBのencodingsとソケット価値のLSBです。
Each IPX/PEP packet contains two sockets, source and destination.
How these are mapped onto the single well-known socket value used
to identify its children is beyond the scope of this document."
REFERENCE
"Novell Corporation"
::= {
-- ipx 0x00 ** Many third party IPX's use this value always
ipx 0x04 -- Xerox assigned for PEP
-- ipx 0x11 ** Novell use this for PEP packets, often
}
それぞれのIPX/PEPパケットは2個のソケット、ソース、および目的地を含んでいます。 「これらがどう子供を特定するのに使用されるただ一つのよく知られるソケット値に写像されるかはこのドキュメントの範囲を超えています。」 「ノベル社」という参照:、:= --*これが評価するipx0×00**多くの第三者IPXの使用がいつも0×04--PEPのために割り当てられたゼロックス--ipx0x11*をipxして、ノベルがPEPパケットにしばしばこれを使用する
nov-spx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Novell Sequenced Packet Exchange Protocol. This protocol is an
extension of IPX/PEP as it shares a common header."
CHILDREN
"Children of SPX are defined by the 16 bit socket values. The
value is encoded into an octet string as [ 0.0.a.b ], where 'a'
and 'b' are the network byte order encodings of the MSB and LSB
of the socket value.
nov-spxプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「ノベルの配列されたパケット交換プロトコル。」 「一般的なヘッダーを共有するとき、このプロトコルはIPX/PEPの拡大です。」 CHILDREN、「SPXの子供は16ビットのソケット値によって定義されます」。 値は[0.0.a.b]として八重奏ストリングにコード化されます。そこでは、'a'と'b'は、ネットワークバイトオーダーのMSBのencodingsとソケット価値のLSBです。
Each IPX/SPX packet contains two sockets, source and destination.
How these are mapped onto the single well-known socket value used
to identify its children is beyond the scope of this document."
REFERENCE
"Novell Corporation"
::= {
ipx 0x05 -- Xerox assigned for SPX
}
それぞれのIPX/SPXパケットは2個のソケット、ソース、および目的地を含んでいます。 「これらがどう子供を特定するのに使用されるただ一つのよく知られるソケット値に写像されるかはこのドキュメントの範囲を超えています。」 「ノベル社」という参照:、:= SPXのために割り当てられた状態で0×05--ゼロックスのコピーをipxします。
nov-sap PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
nov-体液プロトコル-IDENTIFIER PARAMETERS tracksSessions(1)、ATTRIBUTEShasChildren(0)
Bierman, et al. Informational [Page 46] RFC 2896 RMON PI Macros August 2000
Bierman、他 [46ページ]情報のRFC2896RMONパイマクロ2000年8月
DESCRIPTION
"Novell Service Advertising Protocol. This protocol binds
applications on a particular host to an IPX/PEP or IPX/SPX socket
number. Although it never truly acts as a transport protocol
itself it is used to establish sessions between clients and
servers and barring well-known sockets is the only reliable way
to determine the protocol running over a given socket on a given
machine."
CHILDREN
"Children of SAP are identified by a 16 bit service type. They
are encoded as [ 0.0.a.b ], where 'a' is the MSB and 'b' is the
LSB of the service type.
記述「ノベルサービス広告プロトコル。」 このプロトコルは特定のホストの上でアプリケーションをIPX/PEPかIPX/SPXソケット番号まで縛ります。 「本当にトランスポート・プロトコル自体として決して機能しませんが、それはクライアントとサーバとのセッションを証明するのに使用されます、そして、よく知られるソケットを禁じるのは、与えられたマシンの上で与えられたソケットをひくプロトコルを決定する唯一の信頼できる方法です。」 CHILDREN、「SAPの子供は16ビット・サービスタイプによって特定されます」。 それらは、[0.0.a.b]('a'はMSBと'b'である)がサービスタイプのLSBであるので、コード化されます。
Children of SAP are named as 'nov-sap a' where 'a' is the service
type in hexadecimal notation. The novell NCP protocol is
referred to as 'nov-sap ncp' OR 'nov-sap 0x0004'."
DECODING
"The first packet of any session for a SAP based application
(almost all IPX/PEP and IPX/SPX based applications utilize SAP)
is sent to the SAP server(s) to map the service type into a port
number for the host(s) on which the SAP server(s) is(are)
running. These initial packets are SAP packets and not
application packets and must be decoded accordingly.
SAPの子供は'nov-体液a'として'a'がサービスタイプであるところで16進法で命名されます。 「novell NCPプロトコルは'nov-体液ncp'OR'nov-体液0×0004'と呼ばれます。」 DECODING、「SAPサーバが稼働している(あります)ホストのためにサービスタイプをポートナンバーに写像するためにSAPのベースのアプリケーション(ほとんどすべてのIPX/PEPとIPX/SPXのベースのアプリケーションはSAPを利用する)のためのどんなセッションの最初のパケットもSAPサーバに送ります」。 これらの初期のパケットをアプリケーションパケットではなく、SAPパケットであり、それに従って、解読しなければなりません。
Having established the mapping, clients will then send
application packets to the newly discovered socket number. These
must be decoded by 'remembering' the socket assignments
transmitted in the SAP packets.
マッピングを確立したので、そして、クライアントは新たに発見されたソケット番号にアプリケーションパケットを送るでしょう。 ソケット課題がSAPパケットを伝わったのを'覚えている'であることによって、これらを解読しなければなりません。
In some cases the port mapping for a particular protocol is well
known and SAP will always return the same socket number for that
application.
いくつかの場合、特定のプロトコルのためのポートマッピングはよく知られています、そして、SAPはいつもそのアプリケーションの同じソケット番号を返すでしょう。
Such programs should still be declared as children of nov-sap as
described under CHILDREN above. How an implementation detects a
client which is bypassing the SAP server to contact a well-known
application is beyond the scope of this document.
そのようなプログラムは上のCHILDRENの下の説明されるとしてのnov-体液の子供としてまだ申告されているべきです。 実装が、そうするクライアントがよく知られるアプリケーションに連絡するためにSAPサーバを迂回させるのをどう検出するかがこのドキュメントの範囲を超えています。
The 'tracksSessions(1)' PARAMETER bit is used to indicate whether
the probe can (and should) monitor nov-sap activity to correctly
track SAP-based connections."
REFERENCE
"A list of SAP service types can be found at
ftp://ftp.isi.edu/in-notes/iana/assignments/novell-sap-
numbers"
::= { nov-pep 0x0452 }
「'tracksSessions(1)'PARAMETERビットは徹底的調査がそうすることができるか否かに関係なく、(and should)が正しくSAPベースの接続を追跡するためにnov-体液活動をモニターするのを示すのに使用されます。」 「 ftp://ftp.isi.edu/in-notes/iana/assignments/novell-sap- 番号でSAPサービスタイプのリストを見つけることができる」REFERENCE:、:= nov-気力0×0452
ncp PROTOCOL-IDENTIFIER
ncpプロトコル-IDENTIFIER
Bierman, et al. Informational [Page 47] RFC 2896 RMON PI Macros August 2000
Bierman、他 [47ページ]情報のRFC2896RMONパイマクロ2000年8月
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Netware Core Protocol"
CHILDREN
"Children of NCP are identified by the 8 bit command type field.
They are encoded as [ 0.0.0.a ] where 'a' is the command type
value.
ネットウェアコアは」 CHILDRENについて議定書の中で述べます。PARAMETERS tracksSessions(1)、ATTRIBUTES hasChildren(0)、記述、「「NCPの子供は8ビットコマンドタイプ分野によって特定されます」。 それらは'a'がコマンドタイプ価値である[0.0.0.a]としてコード化されます。
Children of NCP are named as 'ncp a' where 'a' is the command
type in decimal notation. The NDS sub-protocol is referred to as
'ncp nds' OR 'ncp 104'."
DECODING
"Only the NCP request frames carry the command type field. How
the implementation infers the command type of a response frame is
an implementation specific matter and beyond the scope of this
document.
NCPの子供は10進法で'a'がコマンドタイプである'ncp a'として命名されます。 「NDSサブプロトコルは'ncp nds'OR'ncp104'と呼ばれます。」 DECODINGは「コマンドタイプがさばくキャリーを縁どNCPが要求するするだけである」。 実装がどうレスポンス・フレームのコマンドタイプを推論するかは、件とこのドキュメントの範囲を超えて特定の実装です。
The tracksSessions(1) PARAMETERS bit indicates whether the probe
can (and should) perform command type inference."
REFERENCE
"Novell Corporation"
::= { nov-sap 0x0004,
nov-pep 0x0451 }
「tracksSessions(1) PARAMETERSビットは、徹底的調査がそうすることができるか否かに関係なく、(and should)がコマンド型推論を実行するのを示します。」 「ノベル社」という参照:、:= nov-体液0×0004、nov-気力0×0451
nds PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Netware Directory Services sub-protocol."
REFERENCE
"Novell Corporation"
::= { ncp 104 }
ndsプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「Netwareディレクトリサービスサブプロトコル。」 「ノベル社」という参照:、:= ncp104
nov-diag PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell's diagnostic Protocol"
REFERENCE
"Novell Corporation"
::= {
nov-sap 0x0017, -- [ed., this is the right one]
nov-pep 0x0456
nov-diagプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ノベルの診断プロトコル」REFERENCE「ノベル社」:、:= nov-体液0×0017--[教育、これ、正しいもの] nov-気力は0×0456です。
Bierman, et al. Informational [Page 48] RFC 2896 RMON PI Macros August 2000
Bierman、他 [48ページ]情報のRFC2896RMONパイマクロ2000年8月
}
}
nov-sec PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell security - serialization - copy protection protocol."
REFERENCE
"Novell Corporation"
::= { nov-pep 0x0457 }
nov-秒のプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ノベルセキュリティ(連載)コピー保護プロトコル。」 「ノベル社」という参照:、:= nov-気力0×0457
nov-watchdog PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell watchdog protocol."
REFERENCE
"Novell Corporation"
::= { nov-pep 0x4004 }
nov-番犬プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ノベル番犬プロトコル。」 「ノベル社」という参照:、:= nov-気力0×4004
nov-bcast PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell broadcast protocol."
REFERENCE
"Novell Corporation"
::= { nov-pep 0x4005 }
nov-bcastプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「ノベル放送プロトコル。」 「ノベル社」という参照:、:= nov-気力0×4005
3.1.3. The XEROX Protocol Stack
3.1.3. ゼロックスプロトコル・スタック
idp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Xerox IDP"
CHILDREN
"Children of IDP are defined by the 8 bit value of the Packet
type field. The value is encoded into an octet string as [
0.0.0.a ], where 'a' is the value of the packet type field in
network byte order.
idpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述「ゼロックスIDP」CHILDREN、「IDPの子供はPacketタイプ分野の8ビットの値によって定義されます」。 値は[0.0.0.a]として八重奏ストリングにコード化されます。そこでは、'a'がネットワークバイトオーダーで、パケットタイプ分野の値です。
Children of IDP are encoded as [ 0.0.0.a ], and named as 'idp a'
where a is the packet type value. The XNS SPP protocol is
referred to as 'idp xns-spp' OR 'idp 2'."
IDPの子供は、aがパケットタイプ価値であるところで[0.0.0.a]としてコード化されて、'idp a'として命名されます。 「XNS SPPプロトコルは'idp xns-spp'OR'idp2'と呼ばれます。」
Bierman, et al. Informational [Page 49] RFC 2896 RMON PI Macros August 2000
Bierman、他 [49ページ]情報のRFC2896RMONパイマクロ2000年8月
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order."
REFERENCE
"Xerox Corporation, Document XNSS 028112, 1981"
::= {
ether2 0x600, -- [ 0.0.6.0 ]
snap 0x600,
802-1Q 0x600 -- [ 0.0.6.0 ]
}
「4バイトのNetwork番号はそれぞれネットワークバイトオーダーにおける6バイトのHostアドレスで続いた」ADDRESS-FORMAT。 「ゼロックス社、ドキュメントXNSS028112、1981」という参照:、:= ether2 0x600--、[0.0 .6 .0] 802-1 0×600、Q0x600を折ってください--、[0.0、.6、.0]
xns-rip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Routing Information Protocol."
REFERENCE
"Xerox Corporation"
::= { idp 1 }
xns-裂け目のプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「経路情報プロトコル。」 「ゼロックス社」という参照:、:= idp1
xns-echo PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS echo protocol."
REFERENCE
"Xerox Corporation"
::= { idp 2 }
xns-エコープロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「XNSエコープロトコル。」 「ゼロックス社」という参照:、:= idp2
xns-error PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"XNS error-handler protocol."
REFERENCE
"Xerox Corporation"
::= { idp 3 }
xns-誤りプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「XNS誤り操作者プロトコル。」 「ゼロックス社」という参照:、:= idp3
xns-pep PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
xns-気力プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)
}
DESCRIPTION
"XNS Packet Exchange Protocol."
CHILDREN
"Children of PEP are defined by the 16 bit socket values. The
} 記述「XNSパケット交換プロトコル。」 CHILDREN、「PEPの子供は16ビットのソケット値によって定義されます」。 The
Bierman, et al. Informational [Page 50] RFC 2896 RMON PI Macros August 2000
Bierman、他 [50ページ]情報のRFC2896RMONパイマクロ2000年8月
value is encoded into an octet string as [ 0.0.a.b ], where 'a'
and 'b' are the network byte order encodings of the MSB and LSB
of the socket value.
値は[0.0.a.b]として八重奏ストリングにコード化されます。そこでは、'a'と'b'は、ネットワークバイトオーダーのMSBのencodingsとソケット価値のLSBです。
Each XNS/PEP packet contains two sockets, source and destination.
How these are mapped onto the single well-known socket value used
to identify its children is beyond the scope of this document."
REFERENCE
"Xerox Corporation"
::= { idp 4 }
それぞれのXNS/PEPパケットは2個のソケット、ソース、および目的地を含んでいます。 「これらがどう子供を特定するのに使用されるただ一つのよく知られるソケット値に写像されるかはこのドキュメントの範囲を超えています。」 「ゼロックス社」という参照:、:= idp4
xns-spp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Sequenced Packet Protocol."
CHILDREN
"Children of SPP are defined by the 16 bit socket values. The
value is encoded into an octet string as [ 0.0.a.b ], where 'a'
and 'b' are the network byte order encodings of the MSB and LSB
of the socket value.
xns-sppプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述は「パケットプロトコルを配列しました」。 CHILDREN、「SPPの子供は16ビットのソケット値によって定義されます」。 値は[0.0.a.b]として八重奏ストリングにコード化されます。そこでは、'a'と'b'は、ネットワークバイトオーダーのMSBのencodingsとソケット価値のLSBです。
Each XNS/SPP packet contains two sockets, source and destination.
How these are mapped onto the single well-known socket value used
to identify its children is beyond the scope of this document."
REFERENCE
"Xerox Corporation"
::= { idp 5 }
それぞれのXNS/SPPパケットは2個のソケット、ソース、および目的地を含んでいます。 「これらがどう子供を特定するのに使用されるただ一つのよく知られるソケット値に写像されるかはこのドキュメントの範囲を超えています。」 「ゼロックス社」という参照:、:= idp5
3.1.4. AppleTalk Protocol Stack
3.1.4. AppleTalkプロトコル・スタック
apple-oui PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Pseudo-protocol which binds Apple's protocols to vsnap."
CHILDREN
"Children of apple-oui are identified by the ether2 type field
value that the child uses when encapsulated in ether2. The value
is encoded into an octet string as [ 0.0.a.b ], where 'a' and 'b'
are the MSB and LSB of the 16-bit ether type value in network
byte order."
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
りんご-ouiプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述、「アップルのプロトコルをvsnapに縛る疑似プロトコル。」 CHILDREN、「りんご-ouiの子供はether2でカプセル化されると子供が使用するether2タイプ分野価値によって特定されます」。 「値は[0.0.a.b]として八重奏ストリングにコード化されます」。(そこでは、'a'と'b'は、ネットワークバイトオーダーにおける16ビットのエーテル型価値のMSBとLSBです)。 REFERENCE、「AppleTalk Phase2プロトコルSpecification、ドキュメントADPA#C0144LL/A.」 ::= {
Bierman, et al. Informational [Page 51] RFC 2896 RMON PI Macros August 2000
Bierman、他 [51ページ]情報のRFC2896RMONパイマクロ2000年8月
vsnap 0x080007, -- [ 0.8.0.7 ]
802-1Q 0x04080007 -- 1Q-VSNAP [ 4.8.0.7 ]
}
vsnap0x080007--、[0.8 .0 .7] 802-1 Q0x04080007--、1Q-VSNAP、[4.8、.0、.7]
aarp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Address Resolution Protocol."
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x80f3, -- [ 0.0.128.243 ]
snap 0x80f3,
apple-oui 0x80f3,
802-1Q 0x80f3 -- [ 0.0.128.243 ]
}
aarpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「AppleTalkアドレス解決プロトコル。」 REFERENCE、「AppleTalk Phase2プロトコルSpecification、ドキュメントADPA#C0144LL/A.」 ::= ether2 0x80f3--、[0.0 .128 .243] 0x80f3、りんご-oui 0x80f3、802-1Q0x80f3を折ってください--、[0.0、.128、.243]
atalk PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"AppleTalk Protocol."
CHILDREN
"Children of ATALK are defined by the 8 bit value of the DDP type
field. The value is encoded into an octet string as [ 0.0.0.a ],
where 'a' is the value of the DDP type field in network byte
order."
ADDRESS-FORMAT
"2 bytes of Network number followed by 1 byte of node id each in
network byte order."
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x809b, -- [ 0.0.128.155 ]
apple-oui 0x809b,
802-1Q 0x809b -- [ 0.0.128.155 ]
}
atalkプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述「AppleTalkプロトコル。」 CHILDREN、「ATALKの子供はDDPタイプ分野の8ビットの値によって定義されます」。 「値は[0.0.0.a]として八重奏ストリングにコード化されます」。(そこでは、'a'がネットワークバイトオーダーで、DDPタイプ分野の値です)。 「数が続いたNetworkの2バイト×それぞれネットワークバイトオーダーにおける、ノードイドの1バイト」のADDRESS-FORMAT。 REFERENCE、「AppleTalk Phase2プロトコルSpecification、ドキュメントADPA#C0144LL/A.」 ::= ether2 0x809b--、[0.0 .128 .155] りんご-oui 0x809b、802-1Q0x809b--、[0.0、.128、.155]
rtmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
rtmpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述
Bierman, et al. Informational [Page 52] RFC 2896 RMON PI Macros August 2000
Bierman、他 [52ページ]情報のRFC2896RMONパイマクロ2000年8月
"AppleTalk Routing Table Maintenance Protocol."
REFERENCE
"Apple Computer"
::= {
atalk 0x01, -- responses
atalk 0x05 -- requests
}
「AppleTalk経路指定テーブルメインテナンスは議定書を作ります。」 「アップル・コンピューター」という参照:、:= atalk0x01--応答atalk0x05--要求
aep PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Echo Protocol."
REFERENCE
"Apple Computer"
::= { atalk 0x04 }
aepプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「AppleTalkエコープロトコル。」 「アップル・コンピューター」という参照:、:= atalk0x04
nbp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Name Binding Protocol."
DECODING
"In order to correctly identify the application protocol running
over atp NBP packets must be analyzed. The mechanism by which
this is achieved is beyond the scope of this document."
REFERENCE
"Apple Computer"
::= { atalk 0x02 }
nbpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「AppleTalkの名前の拘束力があるプロトコル。」 DECODING、「正しくあふれるアプリケーション・プロトコルを特定するために、atp NBPパケットを分析しなければなりません」。 「これが達成されるメカニズムはこのドキュメントの範囲を超えています。」 「アップル・コンピューター」という参照:、:= atalk0x02
zip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Zone Information Protocol."
REFERENCE
"Apple Computer"
::= {
atalk 0x06,
atp 3
}
プロトコル-IDENTIFIER PARAMETERSをファスナーで閉めてください、ATTRIBUTES、記述「AppleTalkゾーン情報プロトコル。」 「アップル・コンピューター」という参照:、:= atalk0x06、atp3
atp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
atpプロトコル-IDENTIFIER PARAMETERS tracksSessions(1)、ATTRIBUTES、hasChildren(0)
Bierman, et al. Informational [Page 53] RFC 2896 RMON PI Macros August 2000
Bierman、他 [53ページ]情報のRFC2896RMONパイマクロ2000年8月
}
DESCRIPTION
"AppleTalk Transaction Protocol."
CHILDREN
"Children of atp are identified by the following (32 bit)
enumeration:
1 asp (AppleTalk Session Protocol)
2 pap (Printer Access Protocol)
3 zip (Zone Information Protocol)
Children of atp are encoded as [ a.b.c.d ] where 'a', 'b', 'c'
and 'd' are the four octets of the enumerated value in network
order (i.e. 'a' is the MSB and 'd' is the LSB).
} 記述「AppleTalkトランザクションプロトコル。」 CHILDREN、「atpの子供は以下の(32ビット)の列挙で特定されます」。 そして、そして、'1 [a.b.c.d]どこ'a'、'b'としてatpのエジプトコブラ(AppleTalk Sessionプロトコル)2乳首(プリンタAccessプロトコル)3ファスナ(ゾーン情報プロトコル)子供はコード化されるか'、c'、'ネットワークオーダーにおける列挙された価値が4つの八重奏がある、(すなわち、'a'がMSBである、'、LSB)であるだろう
The ZIP protocol is referred to as 'atp zip' OR 'atp 3'."
DECODING
"An implementation is encouraged to examine both the socket
fields in the associated DDP header as well as the contents of
prior NBP packets in order to determine which (if any) child is
present. A full description of this algorithm is beyond the
scope of this document. The tracksSessions(1) PARAMETER
indicates whether the probe can (and should) perform this
analysis."
REFERENCE
"Apple Computer"
::= { atalk 0x03 }
「ZIPプロトコルは'atpファスナ'OR'atp3'と呼ばれます。」 DECODING、「実装がどの(もしあれば)子供が出席しているかを決定するために関連DDPヘッダーのソケット分野と先のNBPパケットのコンテンツの両方を調べるよう奨励されます」。 このアルゴリズムの余すところのない解説はこのドキュメントの範囲を超えています。 「tracksSessions(1) PARAMETERは、徹底的調査がそうすることができるか否かに関係なく、(and should)がこの分析を実行するのを示します。」 「アップル・コンピューター」という参照:、:= atalk0x03
adsp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"AppleTalk Data Stream Protocol."
CHILDREN
"Children of adsp are identified by enumeration. At this time
none are known."
DECODING
"An implementation is encouraged to examine the socket numbers in
the associated DDP header as well as the contents of prior NBP
packets in order to determine which (if any) child of ADSP is
present.
adspプロトコル-IDENTIFIER PARAMETERS tracksSessions(1)、ATTRIBUTES hasChildren(0)、記述「AppleTalkデータ・ストリームプロトコル。」 CHILDREN、「adspの子供は列挙で特定されます」。 「このとき、なにも知られていません。」 DECODING、「実装がADSPのどの(もしあれば)子供が出席しているかを決定するために先のNBPパケットのコンテンツと同様に関連DDPヘッダーでソケット番号を調べるよう奨励されます」。
The mechanism by which this is achieved is beyond the scope of
this document.
これが達成されるメカニズムはこのドキュメントの範囲を超えています。
The tracksSessions(1) PARAMETER indicates whether the probe can
tracksSessions(1) PARAMETERは、徹底的調査がそうすることができるかどうかを示します。
Bierman, et al. Informational [Page 54] RFC 2896 RMON PI Macros August 2000
Bierman、他 [54ページ]情報のRFC2896RMONパイマクロ2000年8月
(and should) perform this analysis."
REFERENCE
"Apple Computer"
::= { atalk 0x07 }
「(and should)はこの分析を実行します。」 「アップル・コンピューター」という参照:、:= atalk0x07
asp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"AppleTalk Session Protocol."
CHILDREN
"Children of asp are identified by the following (32 bit)
enumeration:
1 afp (AppleTalk Filing Protocol)
Children of asp are encoded as [ a.b.c.d ] where 'a', 'b', 'c'
and 'd' are the four octets of the enumerated value in network
order (i.e. 'a' is the MSB and 'd' is the LSB).
エジプトコブラプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「AppleTalkセッションプロトコル。」 CHILDREN、「エジプトコブラの子供は以下の(32ビット)の列挙で特定されます」。 そして、そして、'1 [a.b.c.d]どこ'a'、'b'としてエジプトコブラのafp(AppleTalk Filingプロトコル)子供はコード化されるか'、c'、'ネットワークオーダーにおける列挙された価値が4つの八重奏がある、(すなわち、'a'がMSBである、'、LSB)であるだろう
The AFP protocol is referred to as 'asp afp' OR 'asp 1'."
DECODING
"ASP is a helper layer to assist in building client/server
protocols. It cooperates with ATP to achieve this; the
mechanisms used when decoding ATP apply equally here (i.e.
checking DDP socket numbers and tracking NBP packets).
「AFPプロトコルは'エジプトコブラafp'OR'エジプトコブラ1'と呼ばれます。」 DECODING、「ASPは中に建てているクライアント/サーバプロトコルを補助するアシスタント層です」。 それはこれを達成するためにATPと協力します。 ATPを解読するとき使用されるメカニズムは等しくここ(すなわち、DDPソケット番号をチェックして、NBPパケットの跡をつける)に適用されます。
Hence the tracksSessions(1) PARAMETER of atp applies to this
protocol also."
REFERENCE
"Apple Computer"
::= { atp 1 }
「したがって、atpのtracksSessions(1) PARAMETERはこのプロトコルにも適用します。」 「アップル・コンピューター」という参照:、:= atp1
afp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Filing Protocol."
REFERENCE
"Apple Computer"
::= { asp 1 }
afpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「AppleTalkファイリングプロトコル。」 「アップル・コンピューター」という参照:、:= エジプトコブラ1
pap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Printer Access Protocol."
REFERENCE
乳首プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「AppleTalkプリンタアクセス・プロトコル。」 参照
Bierman, et al. Informational [Page 55] RFC 2896 RMON PI Macros August 2000
Bierman、他 [55ページ]情報のRFC2896RMONパイマクロ2000年8月
"Apple Computer"
::= { atp 2 }
「アップル・コンピューター」:、:= atp2
3.1.5. Banyon Vines Protocol Stack
3.1.5. Banyonバインズプロトコル・スタック
vtr PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Banyan Vines Token Ring Protocol Header."
CHILDREN
"Children of vines-tr are identified by the 8 bit packet type
field. Children are encoded as [ 0.0.0.a ] where 'a' is the
packet type value.
vtrプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「バニヤンバインズトークンリングプロトコルヘッダー。」 CHILDREN、「つる植物-trの子供は8ビットのパケットタイプ分野によって特定されます」。 子供は'a'がパケットタイプ価値である[0.0.0.a]としてコード化されます。
The vines-ip protocol is referred to as 'vines-tr vip' OR 'vines-
tr 0xba'."
REFERENCE
"See vip."
::= {
llc 0xBC, -- declared as any LLC, but really TR only.
802-1Q 0x020000BC -- 1Q-LLC [2.0.0.188]
}
「つる植物-ipプロトコルは'つる植物-tr vip'OR'つる植物tr 0xba'と呼ばれます。」 REFERENCEは「vipを見ます」。 ::= { llc 0xBC--しかし、どんなLLC、本当にTRだけとしても、宣言しています。 802-1 Q0x020000BC--1Q-LLC、[2.0、.0、.188]}
vecho PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Banyan Vines data link level echo protocol."
REFERENCE
"See vip."
::= {
ether2 0x0BAF, -- [0.0.11.175]
snap 0x0BAF,
-- vfrp 0x0BAF,
vtr 0xBB, -- [ed. yuck!]
802-1Q 0x0BAF -- [0.0.11.175]
}
vechoプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「バニヤンバインズデータ・リンクレベルエコープロトコル。」 REFERENCEは「vipを見ます」。 ::= ether2 0x0BAF--、[0.0 .11 .175] 0x0BAF--vfrp 0x0BAF、vtr 0xBB--802-1 [教育yuck!]Q0x0BAFを折ってください--、[0.0、.11、.175]
vip PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
vipプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述
Bierman, et al. Informational [Page 56] RFC 2896 RMON PI Macros August 2000
Bierman、他 [56ページ]情報のRFC2896RMONパイマクロ2000年8月
"Banyan Vines Internet Protocol."
CHILDREN
"Children of vip are selected by the one-byte 'protocol type'
field located at offset 5 in the vip header. The value is
encoded as [ 0.0.0.a ], where a is the 'protocol type.' For
example, a protocolDirId fragment of:
「バニヤンバインズインターネットプロトコル。」 '分野はオフセット5時にvipヘッダーで場所を見つけた」CHILDREN「vipの子供は1バイトによって選ばれ'プロトコルタイプ。 値は[0.0.0.a]としてaが. 'プロトコルタイプ'Forの例、以下のprotocolDirId断片であるところでコード化されます。
0.0.0.1.0.0.11.173.0.0.0.1
0.0.0.1.0.0.11.173.0.0.0.1
identifies an encapsulation of vipc (ether2.vip.vipc)."
ADDRESS-FORMAT
"vip packets have 6-byte source and destination addresses. The
destination address is located at offset 6 in the vip header, and
the source address at offset 12. These are encoded in network
byte order."
REFERENCE
"Vines Protocol Definition - part# 092093-001, order# 003673
「vipc(ether2.vip.vipc)のカプセル化を特定します。」 「6バイトはvipパケットで出典を明示して、目的地は扱う」ADDRESS-FORMAT。 送付先アドレスはオフセット12時にオフセット6時にvipヘッダー、およびソースアドレスに位置しています。 「これらはネットワークバイトオーダーでコード化されます。」 REFERENCE、「バインズプロトコルDefinition--#092093-001、オーダー#003673、を分けてください」
BANYAN,
120 Flanders Road,
Westboro, MA 01581 USA"
::= {
ether2 0x0BAD,
snap 0x0BAD,
-- vfrp 0x0BAD,
vtr 0xBA, -- [ed. yuck!]
802-1Q 0x0BAD -- [0.0.11.173]
}
「バニヤン、120フランダース道路、ウェストバロ、MA01581米国」:、:= ether2 0x0BAD、0x0BAD--vfrp 0x0BAD、vtr 0xBA--802-1 [教育yuck!]Q0x0BADを折ってください--、[0.0、.11、.173]
varp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Banyan Vines Address Resolution Protocol."
REFERENCE
"BANYAN"
::= { vip 0x04 }
varpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「バニヤンバインズアドレス解決プロトコル。」 「バニヤン」という参照:、:= vip0x04
vipc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Banyan Vines Interprocess Communications Protocol."
CHILDREN
"Children of Vines IPC are identified by the packet type field at
offset 4 in the vipc header.
vipcプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「バニヤンバインズプロセス間通信プロトコル。」 CHILDREN、「バインズIPCの子供はオフセット4時にvipcヘッダーでパケットタイプ分野によって特定されます」。
Bierman, et al. Informational [Page 57] RFC 2896 RMON PI Macros August 2000
Bierman、他 [57ページ]情報のRFC2896RMONパイマクロ2000年8月
These are encoded as [ 0.0.0.a ] where 'a' is the packet type
value. Children of vipc are defined as 'vipc a' where 'a' is the
packet type value in hexadecimal notation.
これらは'a'がパケットタイプ価値である[0.0.0.a]としてコード化されます。 vipcの子供は'a'が16進法でパケットタイプ価値である'vipc a'と定義されます。
The Vines Reliable Data Transport protocol is referred to as
'vipc vipc-rdp' OR 'vipc 0x01'."
DECODING
"Children of vipc are deemed to start at the first byte after the
packet type field (i.e. at offset 5 in the vipc header)."
REFERENCE
"BANYAN"
::= { vip 0x01 }
「バインズReliable Data Transportプロトコルは'vipc vipc-rdp'OR'vipc0x01'と呼ばれます。」 DECODINGは「分野(すなわち、5vipcヘッダーのオフセット時の)をパケットの後の最初のバイトでの始めにタイプvipcの子供が考えられるます」。 「バニヤン」という参照:、:= vip0x01
-- Banyan treats vipc, vipc-dgp and vipc-rdp as one protocol, IPC. -- Vines IPC really comes in two flavours. The first is used to -- send unreliable datagrams (vipc packet type 0x00). The second -- used to send reliable datagrams (vipc packet type 0x01), -- consisting of up to four actual packets. -- In order to distinguish between these we need two 'virtual' -- protocols to identify which is which.
-- IPC、1としてのバニヤンの御馳走のvipc、vipc-dgp、およびvipc-rdpは議定書を作ります。 -- バインズIPCは本当に2つの風味で登場します。 第1が使用されている、--頼り無いデータグラム(vipcパケットタイプ0x00)を送ってください。 最大4つの実際のパケットから成る秒(高信頼のデータグラム(vipcパケットタイプ0x01)を送るために、使用されます)。 -- これらを見分けるために、私たちは'仮想であること'で2を必要とします--どれを特定するかプロトコルがそうである、どれですか?
vipc-dgp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Vines Unreliable Datagram Protocol."
CHILDREN
"Children of vipc-dgp are identified by the 16 bit port numbers
contained in the vipc (this protocol's parent protocol) header.
vipc-dgpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「バインズの頼り無いデータグラムプロトコル。」 CHILDREN、「vipc-dgpの子供はポートナンバーがvipc(このプロトコルの親プロトコル)ヘッダーに含んだ16ビットによって特定されます」。
These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
the MSB of the port number in network byte order.
これらは、'a'がMSBである[0.0.a.b]と'b'がネットワークバイトオーダーにおけるポートナンバーのMSBであるので、コード化されます。
Children of vipc-dgp are defined as 'vipc-dgp a' where 'a' is the
port number in hexadecimal notation.
vipc-dgpの子供は'a'が16進法でポートナンバーである'vipc-dgp a'と定義されます。
The StreetTalk protocol running over vipc-dgp would be referred
to as 'vipc-dgp streettalk' OR 'vipc-dgp 0x000F'.
vipc-dgpをひくStreetTalkプロトコルは'vipc-dgp streettalk'OR'vipc-dgp 0x000F'と呼ばれるでしょう。
The mechanism by which an implementation selects which of the
source and destination ports to use in determining which child
protocol is present is implementation specific and beyond the
scope of this document."
DECODING
"Children of vipc-dgp are deemed to start after the single
padding byte found in the vipc header. In the case of vipc-dgp
「実装がどの子供プロトコルが存在しているかが、実装特有であることを決定して、このドキュメントの範囲を超えてソースと仕向港のどれを使用したらよいかを選択するメカニズム。」 「vipcヘッダーで見つけられた単一の詰め物バイトの後に出発vipc-dgpの子供が考えられるさせる」DECODING。 vipc-dgpの場合で
Bierman, et al. Informational [Page 58] RFC 2896 RMON PI Macros August 2000
Bierman、他 [58ページ]情報のRFC2896RMONパイマクロ2000年8月
the vipc header is a so called 'short' header, total length 6
bytes (including the final padding byte)."
REFERENCE
"BANYAN"
::= { vipc 0x00 }
「vipcヘッダーはいわゆる'短い'ヘッダーであり、全長は6バイト(最終的な詰め物バイトを含んでいて)です。」 「バニヤン」という参照:、:= vipc0x00
vipc-rdp PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Vines Reliable Datagram Protocol."
CHILDREN
"Children of vipc-rdp are identified by the 16 bit port numbers
contained in the vipc (this protocol's parent protocol) header.
vipc-rdpプロトコル-IDENTIFIER PARAMETERS countsFragments(0)、ATTRIBUTES hasChildren(0)、記述「バインズの信頼できるデータグラムプロトコル。」 CHILDREN、「vipc-rdpの子供はポートナンバーがvipc(このプロトコルの親プロトコル)ヘッダーに含んだ16ビットによって特定されます」。
These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
the MSB of the port number in network byte order.
これらは、'a'がMSBである[0.0.a.b]と'b'がネットワークバイトオーダーにおけるポートナンバーのMSBであるので、コード化されます。
Children of vipc-dgp are defined as 'vipc-rdp a' where 'a' is the
port number in hexadecimal notation.
vipc-dgpの子供は'a'が16進法でポートナンバーである'vipc-rdp a'と定義されます。
The StreetTalk protocol running over vipc-rdp would be referred
to as 'vipc-rdp streettalk' OR 'vipc-rdp 0x000F'.
vipc-rdpをひくStreetTalkプロトコルは'vipc-rdp streettalk'OR'vipc-rdp 0x000F'と呼ばれるでしょう。
The mechanism by which an implementation selects which of the
source and destination ports to use in determining which child
protocol is present is implementation specific and beyond the
scope of this document."
DECODING
"Children of vipc-rdp are deemed to start after the error/length
field at the end of the vipc header. For vipc-rdp the vipc
header is a so called 'long' header, total 16 bytes (including
the final error/length field).
「実装がどの子供プロトコルが存在しているかが、実装特有であることを決定して、このドキュメントの範囲を超えてソースと仕向港のどれを使用したらよいかを選択するメカニズム。」 「vipcヘッダーの誤り/長さの分野の後端では出発vipc-rdpの子供が考えられるさせる」DECODING。 vipc-rdpに関しては、vipcヘッダーは総16バイト(最終的な誤り/長さの分野を含んでいる)のいわゆる'長い'ヘッダーです。
vipc-rdp includes a high level fragmentation scheme which allows
up to four vipc packets to be sent as a single atomic PDU. The
countsFragments(0) PARAMETERS bit indicates whether the probe can
(and should) identify the child protocol in all fragments or only
the leading one."
REFERENCE
"BANYAN"
::= { vipc 0x01 }
vipc-rdpは最大4つのvipcパケットが独身の原子PDUとして送られるのを許容する高い平らな断片化体系を含んでいます。 「countsFragments(0) PARAMETERSビットは、徹底的調査がそうすることができるか否かに関係なく、(and should)がすべての断片の子供プロトコルか主なものだけを特定するのを示します。」 「バニヤン」という参照:、:= vipc0x01
vspp PROTOCOL-IDENTIFIER
vsppプロトコル-IDENTIFIER
Bierman, et al. Informational [Page 59] RFC 2896 RMON PI Macros August 2000
Bierman、他 [59ページ]情報のRFC2896RMONパイマクロ2000年8月
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Banyan Vines Sequenced Packet Protocol."
CHILDREN
"Children of vspp are identified by the 16 bit port numbers
contained in the vspp header.
パラメタ、属性hasChildren(0)、記述、「バニヤンつる植物はパケットプロトコルを配列しました」。 CHILDREN、「vsppの子供はポートナンバーがvsppヘッダーに含んだ16ビットによって特定されます」。
These are encoded as [ 0.0.a.b ] where 'a' is the MSB and 'b' is
the MSB of the port number in network byte order.
これらは、'a'がMSBである[0.0.a.b]と'b'がネットワークバイトオーダーにおけるポートナンバーのMSBであるので、コード化されます。
Children of vspp are defined as 'vspp a' where 'a' is the port
number in hexadecimal notation.
vsppの子供は'a'が16進法でポートナンバーである'vspp a'と定義されます。
The StreetTalk protocol running over vspp would be referred to as
'vspp streettalk' OR 'vspp 0x000F'.
vsppをひくStreetTalkプロトコルは'vspp streettalk'OR'vspp 0x000F'と呼ばれるでしょう。
The mechanism by which an implementation selects which of the
source and destination ports to use in determining which child
protocol is present is implementation specific and beyond the
scope of this document."
DECODING
"The implementation must ensure only those vspp packets which
contain application data are decoded and passed on to children.
Although it is suggested that the packet type and control fields
should be used to determine this fact it is beyond the scope of
this document to fully define the algorithm used."
REFERENCE
"BANYAN"
::= { vip 0x02 }
「実装がどの子供プロトコルが存在しているかが、実装特有であることを決定して、このドキュメントの範囲を超えてソースと仕向港のどれを使用したらよいかを選択するメカニズム。」 「実装は解読されて、子供に渡されたアプリケーションデータを含むそれらのvsppパケットだけを確実にしなければならない」DECODING。 「パケットタイプと制御フィールドがこのドキュメントの範囲を超えているというこの事実が使用されるアルゴリズムを完全に定義することを決定するのに使用されるべきであると示唆されますが。」 「バニヤン」という参照:、:= vip0x02
vrtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Banyan Vines Routing Update Protocol."
REFERENCE
"BANYAN"
::= { vip 0x05 }
vrtpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「バニヤンバインズルート設定アップデートプロトコル。」 「バニヤン」という参照:、:= vip0x05
vicp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Banyan Vines Internet Control Protocol."
REFERENCE
vicpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「バニヤンバインズインターネット制御プロトコル。」 参照
Bierman, et al. Informational [Page 60] RFC 2896 RMON PI Macros August 2000
Bierman、他 [60ページ]情報のRFC2896RMONパイマクロ2000年8月
"BANYAN"
::= { vip 0x06 }
「バニヤン」:、:= vip0x06
3.1.6. The DECNet Protocol Stack
3.1.6. DECNetプロトコル・スタック
dec PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC"
REFERENCE
"Digital Corporation"
::= {
ether2 0x6000,
802-1Q 0x6000 -- [0.0.96.0]
}
DEC社プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「12月」参照「デジタル社」:、:= 802-1 ether2 0x6000、Q0x6000--、[0.0、.96、.0]
lat PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Local Area Transport Protocol."
REFERENCE
"Digital Corporation"
::= {
ether2 0x6004,
802-1Q 0x6004 -- [0.0.96.4]
}
latプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「12月の局部トランスポート・プロトコル。」 「デジタル社」という参照:、:= 802-1 ether2 0x6004、Q0x6004--、[0.0、.96、.4]
mop PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Maintenance Operations Protocol."
REFERENCE
"Digital Corporation"
::= {
ether2 0x6001, -- mop dump/load
ether2 0x6002, -- mop remote console
802-1Q 0x6001, -- [0.0.96.1] VLAN + mop dump/load
802-1Q 0x6002 -- [0.0.96.2] VLAN + mop remote console
}
プロトコル-IDENTIFIER PARAMETERSを拭き掃除してください、ATTRIBUTES、記述「12月のメインテナンス操作プロトコル。」 「デジタル社」という参照:、:= ether2 0x6001--ダンプ/負荷ether2 0x6002を拭き掃除してください--リモートコンソール802-1Q0x6001を拭き掃除してください--、[0.0 .96 .1] VLAN+モップは、802-1 Q0x6002をどさっと落とすか、またはロードします--、[0.0.96.2]VLAN+モップリモートコンソール
dec-diag PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Diagnostic Protocol."
DEC社-diagプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「12月の診断プロトコル。」
Bierman, et al. Informational [Page 61] RFC 2896 RMON PI Macros August 2000
Bierman、他 [61ページ]情報のRFC2896RMONパイマクロ2000年8月
REFERENCE
"Digital Corporation"
::= {
ether2 0x6005,
802-1Q 0x6005 -- [0.0.96.5]
}
「デジタル社」という参照:、:= 802-1 ether2 0x6005、Q0x6005--、[0.0、.96、.5]
lavc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Local Area VAX Cluster Protocol."
REFERENCE
"Digital Corporation"
::= {
ether2 0x6007,
802-1Q 0x6007 -- [0.0.96.7]
}
lavcプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「12月の局部VAXクラスタプロトコル。」 「デジタル社」という参照:、:= 802-1 ether2 0x6007、Q0x6007--、[0.0、.96、.7]
drp PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(1)
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"DEC Routing Protocol."
drpプロトコル-IDENTIFIER PARAMETERS countsFragments(1)、ATTRIBUTES、hasChildren(0)、addressRecognitionCapable(1)、記述「12月のルーティング・プロトコル。」
CHILDREN
"There is only one child of DRP, NSP. This is encoded as [
0.0.0.1 ]."
ADDRESS-FORMAT
"There are three address formats used in DRP packets, 2-byte
(short data packet and all control except ethernet endnode &
router hello messages), 6-byte (ethernet router & endnode hello
messages) and 8-byte (long data packet). All of these contain
the 2-byte format address in the last 2 bytes with the remaining
bytes being unimportant for the purposes of system
identification. It is beyond the scope of this document to
define the algorithms used to identify packet types and hence
address formats.
CHILDREN、「DRP、NSPの1人の子供しかいません」。 「これがコード化される、[0.0、.0、.1]、」 ADDRESS-FORMAT、「DRPパケットで使用される3つのアドレス形式があります、2バイトである、(イーサネットendnodeとルータを除いて、脆いデータ・パケットとすべてが制御される、こんにちは、メッセージ)、6バイト、(イーサネットルータとendnode、こんにちは、8バイト(長いデータ・パケット)のメッセージ、」 これらはすべて、残っているバイトがシステムの同定の目的のために重要でない最後の2バイトにおける2バイトの形式アドレスを含んでいます。 それは、パケットタイプとしたがって、アドレス形式を特定するのに使用されるアルゴリズムを定義するためにこのドキュメントの範囲を超えています。
The 2-byte address format is the concatenation of a 6-bit area
and a 10-bit node number. In all cases this is placed in little
endian format (i.e. LSB, MSB). The probe, however, will return
them in network order (MSB, LSB). Regardless of the address
2バイトのアドレス形式は6ビットの領域と10ビットのノード番号の連結です。 すべての場合では、これはリトルエンディアン形式(すなわち、LSB、MSB)に置かれます。 しかしながら、探測装置はネットワークオーダー(MSB、LSB)でそれらを返すでしょう。 アドレスにかかわらず
Bierman, et al. Informational [Page 62] RFC 2896 RMON PI Macros August 2000
Bierman、他 [62ページ]情報のRFC2896RMONパイマクロ2000年8月
format in the packet, the probe will always use the 2-byte
format.
パケットの形式、探測装置はいつも2バイトの形式を使用するでしょう。
For example area=13 (001101) and node=311 (0100110111) gives:
0011 0101 0011 0111 = 0x3537 in network order (the order the
probe should return the address in).
例えば領域は311(0100110111)が与える13の(001101)とノード=と等しいです: ネットワークにおける0011 0101 0011 0111=0×3537は注文されます(中に探測装置がアドレスを返すはずであるオーダーがある状態で)。
In packets this same value would appear as (hex):
パケットでは、この同じ値は(十六進法)として現れるでしょう:
2-byte 37 35
6-byte AA 00 04 00 37 35
8-byte 00 00 AA 00 04 00 37 35
2バイトの37 35 6バイトのAA00 04 00 37 35の8バイトの00 00AA00 04 00 37 35
Notice that the AA 00 04 00 prefix is defined in the
specification but is unimportant and should not be parsed.
AA00 04 00接頭語が仕様に基づき定義されますが、重要でなく、分析されるべきでないのに注意してください。
Notice that control messages only have a source address in the
header and so they can never be added into the conversation based
tables."
DECODING
"NSP runs over DRP data packets; all other packet types are DRP
control packets of one sort or another and do not carry any
higher layer protocol.
「コントロールメッセージが会話に基づいているテーブルにそれらを決して加えることができないようにヘッダーにソースアドレスを持っているだけであるのに注意してください。」 DECODING、「NSPはDRPデータ・パケットをひきます」。 他のすべてのパケットタイプは、何らかの種類のDRPコントロールパケットであり、どんなより高い層のプロトコルも運びません。
NSP packets are deemed to start at the beginning of the DRP data
area.
NSPパケットがDRPデータ領域の始めに出発すると考えられます。
Data packets may be fragmented over multiple DRP data packets.
The countsFragments(1) parameter indicates whether a probe can
(and should) attribute non-leading fragments to the child
protocol (above NSP in this case) or not.
データ・パケットは複数のDRPデータ・パケットの上で断片化されるかもしれません。 countsFragments(1)パラメタは、徹底的調査が子供プロトコル(この場合、NSPの上の)への(and should)属性非先導断片であるか否かに関係なく、そうすることができるかどうかを示します。
Recognition of DRP data packets and fragments is beyond the scope
of this document."
REFERENCE
"DECnet Digital Network Architecture
Phase IV
Routing Layer Functional Specification
Order# AA-X435A-TK
Digital Equipment Corporation, Maynard, Massachusetts, USA"
::= {
ether2 0x6003,
snap 0x6003,
802-1Q 0x6003 -- [0.0.96.3]
}
「DRPデータ・パケットと断片の認識はこのドキュメントの範囲を超えています。」 「DECnetのルート設定の層の機能的な仕様オーダー#AA-X435A-TKデジタル・ネットワーク・アーキテクチャフェーズIV DEC、メイナード、マサチューセッツ、米国」という参照:、:= ether2 0x6003、802-1 0×6003、Q0x6003を折ってください--、[0.0、.96、.3]
nsp PROTOCOL-IDENTIFIER
PARAMETERS {
nspプロトコル-IDENTIFIER PARAMETERS
Bierman, et al. Informational [Page 63] RFC 2896 RMON PI Macros August 2000
Bierman、他 [63ページ]情報のRFC2896RMONパイマクロ2000年8月
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"DEC Network Services Protocol."
CHILDREN
"Children of NSP are identified by the SCP 8-bit object type.
Notice that the object type is included only in the session
establishment messages (connect initiate, retransmitted connect
initiate).
tracksSessions(1) 属性hasChildren(0) 記述「12月のネットワーク・サービスプロトコル。」 CHILDREN、「NSPの子供はSCPの8ビットのオブジェクト・タイプによって特定されます」。 オブジェクト・タイプがセッション設立メッセージだけに含まれているのに注意してください(開始に接してください、そして、再送されて、開始に接してください)。
Children of NSP are encoded [ 0.0.0.a ] where 'a' is the SCP
object type. Children of NSP are named as 'nsp' followed by the
SCP object type in decimal. CTERM is referred to as 'nsp cterm'
OR 'nsp 42'."
DECODING
"An implementation is encouraged to examine SCP headers included
in NSP control messages in order to determine which child
protocol is present over a given session. It is beyond the scope
of this document to define the algorithm used to do this.
NSPの子供は'a'がSCPオブジェクト・タイプであるところでコード化されます[0.0.0.a]。 'nsp'が小数でSCPオブジェクト・タイプで続いたので、NSPの子供は命名されます。 「CTERMは'nsp cterm'OR'nsp42'と呼ばれます。」 「NSPコントロールメッセージにSCPヘッダーを含んでいて、どの子供プロトコルが与えられたセッションの間、存在しているかを決定するために実装が調べるよう奨励される」DECODING。 それは、これをするのに使用されるアルゴリズムを定義するためにこのドキュメントの範囲を超えています。
The tracksSessions(1) flag indicates whether the probe can (and
should) perform this analysis."
REFERENCE
"DECnet Digital Network Architecture
Phase IV
NSP Functional Specification
Order# AA-X439A-TK
Digital Equipment Corporation, Maynard, Massachusetts, USA"
::= { drp 1 }
「tracksSessions(1)旗は、徹底的調査がそうすることができるか否かに関係なく、(and should)がこの分析を実行するのを示します。」 「DECnetのIVのNSPの機能的な仕様オーダー#AA-X439A-TKデジタル・ネットワーク・アーキテクチャフェーズDEC、メイナード、マサチューセッツ、米国」という参照:、:= drp1
dap-v1 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Data Access Protocol version 1."
REFERENCE
"Digital Corporation"
::= { nsp 1 }
v1をちょと浸しているプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「12月のData Accessプロトコルバージョン1。」 「デジタル社」という参照:、:= nsp1
dap-v4 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Data Access Protocol versions 4 and above."
REFERENCE
v4をちょと浸しているプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「より12月の、よりData Accessよりプロトコルより多くのバージョン4。」 参照
Bierman, et al. Informational [Page 64] RFC 2896 RMON PI Macros August 2000
Bierman、他 [64ページ]情報のRFC2896RMONパイマクロ2000年8月
"Digital Corporation"
::= { nsp 17 }
「デジタル社」:、:= nsp17
nice PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Network Information and Control Exchange protocol."
REFERENCE
"Digital Corporation"
::= { nsp 19 }
良いプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、「12月のNetwork情報とControl Exchangeは議定書の中で述べる」記述。 「デジタル社」という参照:、:= nsp19
dec-loop PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Loopback Protocol."
REFERENCE
"Digital Corporation"
::= { nsp 25 }
DEC社輪のプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「12月のループバックプロトコル。」 「デジタル社」という参照:、:= nsp25
dec-event PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC Event Protocol."
REFERENCE
"Digital Corporation"
::= { nsp 26 }
DEC社イベントプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「12月のイベントプロトコル。」 「デジタル社」という参照:、:= nsp26
cterm PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"DEC CTERM Protocol."
REFERENCE
"Digital Corporation"
::= { nsp 42 }
ctermプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「DEC CTERMプロトコル。」 「デジタル社」という参照:、:= nsp42
3.1.7. The IBM SNA Protocol Stack.
3.1.7. IBM SNAプロトコル・スタック。
sna-th PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"IBM's SNA TH protocol."
REFERENCE
"IBM Systems Network Architecture
sna、-、プロトコル-第IDENTIFIER PARAMETERS、ATTRIBUTES、「IBMのSNA THは議定書の中で述べる」記述。 「IBMシステム・ネットワーク・アーキテクチャ」という参照
Bierman, et al. Informational [Page 65] RFC 2896 RMON PI Macros August 2000
Bierman、他 [65ページ]情報のRFC2896RMONパイマクロ2000年8月
Format and Protocol
Reference Manual: Architectural Logic
リファレンスマニュアルをフォーマットして、議定書の中で述べてください: 建築論理
SC30-3112-2
SC30-3112-2
IBM System Communications Division,
Publications Development,
Department E02,
PO Box 12195,
Research Triangle Park,
North Carolina 27709."
::= {
llc 0x04, -- [0.0.0.4]
llc 0x08, -- [0.0.0.8]
llc 0x0c, -- [0.0.0.12]
ether2 0x80d5, -- [0.0.128.213]
802-1Q 0x02000004, -- 1Q-LLC [2.0.0.4]
802-1Q 0x02000008, -- 1Q-LLC [2.0.0.8]
802-1Q 0x0200000c, -- 1Q-LLC [2.0.0.12]
802-1Q 0x80d5 -- [0.0.128.213]
}
「IBMシステム・コミュニケーション師団(刊行物開発、02部のE、私書箱12195)はノースカロライナ 三角形公園、27709について研究します。」 ::= llc0x04--、[0.0 .0 .4] llc0x08--、[0.0 .0 .8]llc 0x0c--、[0.0 .0 .12]ether2 0x80d5--、[0.0 .128 .213] 802-1 Q0x02000004--、1Q-LLC、[2.0 .0 .4] 802-1 Q0x02000008--、1Q-LLC、[2.0 .0 .8] 802-1 Q0x0200000c--、1Q-LLC、[2.0 .0 .12] 802-1 Q0x80d5--、[0.0、.128、.213]
3.1.8. The NetBEUI/NetBIOS Family
3.1.8. NetBEUI/NetBIOSファミリー
-- CHILDREN OF NETBIOS
-- The NetBIOS/NetBEUI functions are implemented over a wide variety of
-- transports. Despite varying implementations they all share two
-- features. First, all sessions are established by connecting to
-- locally named services. Second, all sessions transport application
-- data between the client and the named service. In all cases the
-- identification of the application protocol carried within the data
-- packets is beyond the scope of this document.]
--
-- Children of NetBIOS/NetBEUI are identified by the following (32 bit)
-- enumeration
--
-- 1 smb (Microsoft's Server Message Block Protocol)
-- 2 notes (Lotus' Notes Protocol)
-- 3 cc-mail (Lotus' CC Mail Protocol)
--
-- Children of NetBIOS/NetBEUI are encoded as [ a.b.c.d ] where 'a', 'b',
-- 'c' and 'd' are the four octets of the enumerated value in network
-- order (i.e. 'a' is the MSB and 'd' is the LSB).
--
-- For example notes over NetBEUI is declared as
-- 'notes ::= { netbeui 2 }'
-- but is referred to as
-- 'netbeui notes' OR 'netbeui 2'.
-- CHILDREN OF NETBIOS、--、NetBIOS/NetBEUI機能が広いバラエティーの上で実装される--輸送します。 異なった実装にもかかわらず、2を共有します--特徴。 最初に、セッションが接続することによって確立しているすべて--局所的にサービスと命名されます。 2番目に、すべてのセッションがアプリケーションを輸送します--クライアントと命名されたサービスの間のデータ。 すべての場合には、このドキュメントの範囲を超えて--データの中で運ばれたアプリケーション・プロトコルの識別--パケットがあります。] -- -- そして、そして、'以下(32ビット)(列挙)によってNetBIOS/NetBEUIの子供は特定されます--[a.b.c.d]どこ'a'、'b'--'c'として1smb(マイクロソフトのServer Message Blockプロトコル)--2個のメモ(蓮のNotesプロトコル)(3ccメール(蓮のCCメールプロトコル))--NetBIOS/NetBEUIの子供がコード化されるか、'ネットワーク--オーダーにおける列挙された価値が4つの八重奏がある、(すなわち、'a'がMSBである、'、LSB)であるだろう -- -- 例えば、NetBEUIの上の注意として、宣言されます--、'注意:、:、'= '2をnetbeuiします'が、言及される、--'netbeui注意のOR'netbeui2''。
Bierman, et al. Informational [Page 66] RFC 2896 RMON PI Macros August 2000
Bierman、他 [66ページ]情報のRFC2896RMONパイマクロ2000年8月
netbeui PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Lan Manager NetBEUI protocol."
netbeuiプロトコル-IDENTIFIER PARAMETERS tracksSessions(1)、ATTRIBUTES hasChildren(0)、記述「ランマネージャNetBEUIプロトコル。」
CHILDREN
"See `CHILDREN OF NETBIOS`"
DECODING
"NETBEUI provides a named service lookup function. This function
allows clients to locate a service by (locally assigned) name.
An implementation is encouraged to follow lookups and session
establishments and having determined the child protocol, track
them.
「'CHILDREN OF NETBIOS'を見てください」という「NETBEUIは命名されたサービスルックアップ機能を提供する」CHILDREN DECODING。 この機能で、クライアントは(局所的に割り当てられます)の名前のサービスの場所を見つけることができます。 実装がルックアップとセッション施設に続くよう奨励されて、子供プロトコルを決定して、それらを追跡してください。
How the child protocol is determined and how the sessions are
tracked is an implementation specific matter and is beyond the
scope of this document."
REFERENCE
"IBM"
::= {
llc 0xF0, -- [0.0.0.240]
802-1Q 0x020000F0 -- 1Q-LLC [2.0.0.240]
}
「子供プロトコルが決定していて、セッションがどう追跡されるかは、どう実装の特定の問題であり、このドキュメントの範囲を超えているか。」 「IBM」という参照:、:= llc 0xF0--、[0.0 .0 .240] 802-1 Q0x020000F0--、1Q-LLC、[2.0、.0、.240]
nbt-name PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"NetBIOS-over-TCP name protocol."
REFERENCE
"RFC 1001 [RFC1001] defines the 'PROTOCOL STANDARD FOR A NetBIOS
SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS.' RFC 1002
[RFC1002] defines the 'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON
A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS'."
::= {
udp 137,
tcp 137
}
nbt-名前プロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「NetBIOS過剰TCP名前プロトコル。」 REFERENCE、「RFC1001[RFC1001]は'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORTを定義する'、」 '. RFC CONCEPTS AND METHODS'1002[RFC1002]は'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORTを定義します' 「仕様詳細のもの。」 ::= udp137、tcp137
nbt-session PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
nbt-セッションプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述
Bierman, et al. Informational [Page 67] RFC 2896 RMON PI Macros August 2000
Bierman、他 [67ページ]情報のRFC2896RMONパイマクロ2000年8月
"NetBIOS-over-TCP session protocol."
REFERENCE
"RFC 1001 [RFC1001] defines the 'PROTOCOL STANDARD FOR A NetBIOS
SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS.' RFC 1002
[RFC1002] defines the 'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON
A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS'."
::= {
「NetBIOS過剰TCPセッションプロトコル。」 REFERENCE、「RFC1001[RFC1001]は'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORTを定義する'、」 '. RFC CONCEPTS AND METHODS'1002[RFC1002]は'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORTを定義します' 「仕様詳細のもの。」 ::= {
udp 139,
tcp 139
}
udp139、tcp139
nbt-data PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"NetBIOS-over-TCP datagram protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
REFERENCE
"RFC 1001 [RFC1001] defines the 'PROTOCOL STANDARD FOR A NetBIOS
SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS.' RFC 1002
[RFC1002] defines the 'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON
A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS'."
::= {
udp 138,
tcp 138
}
nbt-データプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「NetBIOS過剰TCPデータグラムプロトコル。」 「'CHILDREN OF NETBIOS'を見てください」というCHILDREN REFERENCE、「RFC1001[RFC1001]は'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORTを定義する'、」 '. RFC CONCEPTS AND METHODS'1002[RFC1002]は'PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORTを定義します' 「仕様詳細のもの。」 ::= udp138、tcp138
netbios-3com PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"3COM NetBIOS protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
REFERENCE
"3Com Corporation"
::= {
ether2 0x3C00,
ether2 0x3C01,
ether2 0x3C02,
ether2 0x3C03,
ether2 0x3C04,
netbios-3comプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES hasChildren(0)、記述「3COM NetBIOSプロトコル。」 「'NETBIOSの子供'を見てください」という子供参照「3Com社」:、:= ether2 0x3C00、ether2 0x3C01、ether2 0x3C02、ether2 0x3C03、ether2 0x3C04
Bierman, et al. Informational [Page 68] RFC 2896 RMON PI Macros August 2000
Bierman、他 [68ページ]情報のRFC2896RMONパイマクロ2000年8月
ether2 0x3C05,
ether2 0x3C06,
ether2 0x3C07,
ether2 0x3C08,
ether2 0x3C09,
ether2 0x3C0A,
ether2 0x3C0B,
ether2 0x3C0C,
ether2 0x3C0D,
802-1Q 0x3C00,
802-1Q 0x3C01,
802-1Q 0x3C02,
802-1Q 0x3C03,
802-1Q 0x3C04,
802-1Q 0x3C05,
802-1Q 0x3C06,
802-1Q 0x3C07,
802-1Q 0x3C08,
802-1Q 0x3C09,
802-1Q 0x3C0A,
802-1Q 0x3C0B,
802-1Q 0x3C0C,
802-1Q 0x3C0D
}
ether2 0x3C05、ether2 0x3C06、ether2 0x3C07、ether2 0x3C08、ether2 0x3C09、ether2 0x3C0A、ether2 0x3C0B、ether2 0x3C0C、ether2 0x3C0D、802-1 Q0x3C00、802-1 Q0x3C01、802-1 Q0x3C02、802-1 Q0x3C03、802-1 Q0x3C04、802-1 Q0x3C05、802-1 Q0x3C06、802-1 Q0x3C07、802-1 Q0x3C08、802-1 Q0x3C09、802-1 Q0x3C0A、802-1 Q0x3C0B、802-1 Q0x3C0C、802-1 Q0x3C0D
nov-netbios PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Novell's version of the NetBIOS protocol."
CHILDREN
"See `CHILDREN OF NETBIOS`"
REFERENCE
"Novell Corporation"
::= {
nov-sap 0x0020, -- preferred encapsulation to use, even though
-- the following are typically used also
-- ipx 0x14, -- when reached by IPX packet type
-- nov-pep 0x0455 -- when reached by socket number
}
nov-netbiosプロトコル-IDENTIFIER PARAMETERS、記述「のノベルNetBIOSのバージョンが議定書の中で述べるATTRIBUTES hasChildren(0)、」 「'NETBIOSの子供'を見てください」という子供参照「ノベル社」:、:= nov-体液0×0020--使用する都合のよいカプセル化、--また(ipx0x14)、ソケット番号で達しているとIPXパケットタイプ(nov-気力0×0455)によって連絡されていると以下が通常使用される
burst PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Novell burst-mode transfer"
プロトコル-IDENTIFIER PARAMETERSを押し破いてください、ATTRIBUTES、記述「ノベルバーストモード転送」
Bierman, et al. Informational [Page 69] RFC 2896 RMON PI Macros August 2000
Bierman、他 [69ページ]情報のRFC2896RMONパイマクロ2000年8月
REFERENCE
参照
"Novell Corporation"
::= { nov-pep 0x0d05 }
「ノベル社」:、:= nov-気力0x0d05
3.2. Multi-stack protocols
3.2. マルチスタックプロトコル
smb PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Microsoft Server Message Block Protocol."
REFERENCE
"Microsoft Corporation"
::= {
netbeui 1,
netbios-3com 1,
nov-netbios 1,
nbt-data 1,
nbt-session 1,
nov-pep 0x550,
nov-pep 0x552
}
smbプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「マイクロソフトサーバメッセージブロックプロトコル。」 「マイクロソフト社」という参照:、:= netbeui1、netbios-3com1、nov-netbios1、nbt-データ1、nbt-セッション1、nov-気力0×550、nov-気力0×552
notes PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Lotus Notes Protocol."
REFERENCE
"Lotus Development"
::= {
netbeui 2,
netbios-3com 2,
nov-netbios 2,
nbt-data 2,
tcp 1352,
udp 1352,
nov-sap 0x039b
}
プロトコル-IDENTIFIER PARAMETERSが注意する、ATTRIBUTES、記述「ロータスノーツプロトコル。」 「ロータスディベロップメント」という参照:、:= netbeui2、netbios-3com2、nov-netbios2、nbt-データ2、tcp1352、udp1352、nov-体液0x039b
ccmail PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
ccmailプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES{ }
DESCRIPTION
"Lotus CC-mail Protocol."
REFERENCE
記述「ロータスCCメールプロトコル。」 参照
Bierman, et al. Informational [Page 70] RFC 2896 RMON PI Macros August 2000
Bierman、他 [70ページ]情報のRFC2896RMONパイマクロ2000年8月
"Lotus Development"
::= {
netbeui 3,
netbios-3com 3,
nov-netbios 3,
nbt-data 3,
tcp 3264,
udp 3264
}
「ロータスディベロップメント」:、:= netbeui3、netbios-3com3、nov-netbios3、nbt-データ3、tcp3264、udp3264
snmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol. Includes SNMPv1 and SNMPv2
protocol versions. Does not include SNMP trap packets."
REFERENCE
"The SNMP SMI is defined in RFC 1902 [RFC1902]. Version 1 of the
SNMP protocol is defined in RFC 1905 [RFC1905]. Transport
mappings are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over
IPX) [RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 161,
nov-pep 0x900f, -- [ 0.0.144.15 ]
atalk 8,
tcp 161
}
snmpプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「簡単なネットワーク管理プロトコル。」 SNMPv1とSNMPv2プロトコルバージョンを含んでいます。 「SNMP罠パケットを含んでいません。」 REFERENCE、「SNMP SMIはRFC1902[RFC1902]で定義されます」。 SNMPプロトコルのバージョン1はRFC1905[RFC1905]で定義されます。 輸送マッピングはRFC1906[RFC1906]で定義されます。 RFC1420(IPXの上のSNMP)[RFC1420]。 「RFC1419(AppleTalkの上のSNMP)[RFC1419]。」 ::= udp161、nov-気力0x900f--、[0.0.144.15]atalk8、tcp161
snmptrap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol Trap Port."
REFERENCE
"The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
protocol is defined in RFC 1905 [RFC1905]. Transport mappings
are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 162,
nov-pep 0x9010,
atalk 9,
tcp 162
}
snmptrapプロトコル-IDENTIFIER PARAMETERS、ATTRIBUTES、記述「簡単なネットワーク管理プロトコル罠ポート。」 REFERENCE、「SNMP SMIはRFC1902[RFC1902]で定義されます」。 SNMPプロトコルはRFC1905[RFC1905]で定義されます。 輸送マッピングはRFC1906[RFC1906]で定義されます。 RFC1420(IPXの上のSNMP)[RFC1420]。 「RFC1419(AppleTalkの上のSNMP)[RFC1419]。」 ::= udp162、nov-気力0×9010、atalk9、tcp162
-- END
-- 終わり
Bierman, et al. Informational [Page 71] RFC 2896 RMON PI Macros August 2000
Bierman、他 [71ページ]情報のRFC2896RMONパイマクロ2000年8月
4. Intellectual Property
4. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat."
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 「権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。」
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専務に情報を扱ってください。
5. Acknowledgements
5. 承認
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.
コマツナギSinghal国境のソフトウェア開発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.
デヴィッドパーキンスDeskTalkシステムInc.
Skip Koppenhaver
Technically Elite, Inc.
Koppenhaverをスキップしてください、技術的にエリートのInc.
Bierman, et al. Informational [Page 72] RFC 2896 RMON PI Macros August 2000
Bierman、他 [72ページ]情報のRFC2896RMONパイマクロ2000年8月
6. References
6. 参照
[IEN158] J. Haverty, "XNET Formats for Internet Protocol Version
4", IEN 158, October 1980.
[IEN158]J.Haverty、「XNETは1980年10月にインターネットプロトコルバージョンのために4インチ、IEN158をフォーマットします」。
[RFC407] Bressler, R., Guida. R. and A. McKenzie, "Remote Job Entry
Protocol", RFC 407, October 1972.
[RFC407] Bressler、R.、Guida。 R.とA.マッケンジー、「リモートジョブエントリプロトコル」、RFC407、1972年10月。
[RFC493] Michener, J., Cotton, I., Kelley, K., Liddle, D. and E.
Meyer, "E.W., Jr Graphics Protocol", RFC 493, April 1973.
[RFC493] ミッチェナー、J.、綿、I.、ケリー、K.、Liddle、D.、およびE.マイヤー、「E. w.Jrグラフィックスは議定書を作る」、RFC493、4月1973日
[RFC734] Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
[RFC734] クリスピン、M.、「SUPDUPプロトコル」、RFC734、1977年10月。
[RFC740] Braden, R., "NETRJS Protocol", RFC 740, November 1977.
[RFC740] ブレーデン、R.、「NETRJSプロトコル」、RFC740、1977年11月。
[RFC741] Cohen, D., "Specifications for the Network Voice
Protocol", RFC 741, ISI/RR 7539, March 1976.
[RFC741] コーエン、D.、「ネットワーク声のプロトコルのための仕様」、RFC741、ISI/RR7539、1976年3月。
[RFC759] Postel, J., "Internet Message Protocol", RFC 759, August
1980.
[RFC759] ポステル、J.、「インターネットメッセージプロトコル」、RFC759、1980年8月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC791] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, September 1981.
[RFC791] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、1981年9月。
[RFC792] Postel, J., "Internet Control Message Protocol - DARPA
Internet Program Protocol Specification", STD 5, RFC 792,
September 1981.
[RFC792] ポステル、J.、「インターネットはメッセージプロトコルを制御します--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC792、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD 5, RFC 793,
September 1981.
[RFC793] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC793、1981年9月。
[RFC818] Postel, J., "Remote User Telnet service", RFC 818,
November 1982.
[RFC818] ポステル、J.、「リモートUser Telnetサービス」、RFC818、1982年11月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[RFC821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[RFC823] Hinden, R. and A. Sheltzer, "The DARPA Internet Gateway",
RFC 823, September 1982.
[RFC823] HindenとR.とA.Sheltzer、「DARPAインターネットゲートウェイ」、RFC823、1982年9月。
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol or
Converting Network Protocol Addresses to 48-bit Ethernet
Addresses for Transmission on Ethernet Hardware", STD 37,
RFC 826, November 1982.
[RFC826]プラマー、D.、「イーサネットアドレス解決プロトコルかネットワーク・プロトコルを変換すると、トランスミッションのためのアドレスはイーサネットハードウェアの上で48ビットのイーサネットに扱われます」、STD37、RFC826、1982年11月。
Bierman, et al. Informational [Page 73] RFC 2896 RMON PI Macros August 2000
Bierman、他 [73ページ]情報のRFC2896RMONパイマクロ2000年8月
[RFC854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[RFC854] ポステル、J.、およびJ.レイノルズ(「telnetプロトコル仕様」、STD8、RFC854)は1983がそうするかもしれません。
[RFC862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983.
[RFC862]ポステル(J.、「エコープロトコル」、STD20、RFC862)は1983がそうするかもしれません。
[RFC863] Postel, J., "Discard Protocol", STD 21, RFC 863, May 1983.
[RFC863]ポステル(J.、「破棄は議定書を作る」STD21、RFC863)は1983がそうするかもしれません。
[RFC864] Postel, J., "Character Generator Protocol", STD 22, RFC
864, May 1983.
[RFC864]ポステル(J.、「文字発生機構プロトコル」、STD22、RFC864)は1983がそうするかもしれません。
[RFC865] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865,
May 1983.
[RFC865]ポステル(J.、「今日の名言プロトコル」、STD23、RFC865)は1983がそうするかもしれません。
[RFC866] Postel, J., "Active Users", STD 26, RFC 866, May 1983.
[RFC866]ポステル(J.、「活発なユーザ」、STD26、RFC866)は1983がそうするかもしれません。
[RFC867] Postel, J., "Daytime Protocol", STD 25, RFC 867, May 1983.
[RFC867]ポステル(J.、「昼間のプロトコル」、STD25、RFC867)は1983がそうするかもしれません。
[RFC868] Postel, J., "Time Protocol", STD 26, RFC 868, May 1983.
[RFC868]ポステル(J.、「時間プロトコル」、STD26、RFC868)は1983がそうするかもしれません。
[RFC869] Hinden, R., "A Host Monitoring Protocol", RFC 869,
December 1983.
[RFC869] 1983年12月のHinden、R.、「ホストのモニターしているプロトコル」RFC869。
[RFC887] Accetta, M., "Resource Location Protocol", RFC 887,
December 1983.
[RFC887] Accetta、M.、「リソース位置のプロトコル」、RFC887、1983年12月。
[RFC904] International Telegraph and Telephone Co., D. Mills,
"Exterior Gateway Protocol Formal Specification", STD 18,
RFC 904, April 1984.
国際[RFC904]は、1984年4月に電報を打って、社、D.工場、「外のゲートウェイプロトコル形式仕様」、STD18、RFC904に電話をします。
[RFC905] McKenzie, A., "ISO Transport Protocol Specification - ISO
DP 8073", RFC 905, April 1984.
[RFC905] マッケンジー、A.、「ISO DP ISO輸送プロトコル仕様--8073」、RFC905、1984年4月。
[RFC908] Velten, D., Hinden, R., and J. Sax, "Reliable Data
Protocol", RFC 908, July 1984.
[RFC908] フェルテンとD.とHinden、R.とJ.サクソフォーン、「確実な資料プロトコル」、RFC908、1984年7月。
[RFC913] Lottor, M., "Simple File Transfer Protocol", RFC 913,
September 1984.
[RFC913]Lottor、M.、「簡単なファイル転送プロトコル」、RFC913、1984年9月。
[RFC915] Elvy, M. and R. Nedved, "Network mail path service", RFC
915, December 1984.
[RFC915] ElvyとM.とR.ネドべド、「ネットワークメール経路サービス」、RFC915、1984年12月。
[RFC937] Butler, M., Chase, D., Goldberger, J., Postel, J., and J.
Reynolds, "Post Office Protocol - version 2", RFC 937,
February 1985.
[RFC937] バトラーとM.とチェイスとD.とGoldbergerとJ.とポステル、J.とJ.レイノルズ、「オフィスプロトコルをバージョン2インチ掲示してください、RFC937、1985年2月。」
[RFC938] Miller, T., "Internet Reliable Transaction Protocol", RFC
938, February 1985.
[RFC938] ミラー、T.、「インターネットの信頼できるトランザクションプロトコル」、RFC938、1985年2月。
Bierman, et al. Informational [Page 74] RFC 2896 RMON PI Macros August 2000
Bierman、他 [74ページ]情報のRFC2896RMONパイマクロ2000年8月
[RFC951] Croft, W. and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)",
RFC 951, September 1985.
[RFC951] 耕地とW.とJ.ギルモア、「プロトコル(BOOTP)を独力で進んでください」、RFC951、1985年9月。
[RFC953] Feinler, E., Harrenstien, K. and M. Stahl, "Hostname
Server", RFC 953, October 1985.
[RFC953] FeinlerとE.とHarrenstienとK.とM.スタール、「ホスト名サーバ」、RFC953、1985年10月。
[RFC954] Feinler, E., Harrenstien, K. and M. Stahl,
"NICNAME/WHOIS", RFC 954, October 1985.
[RFC954]FeinlerとE.とHarrenstienとK.とM.スタール、「NICNAME/WHOIS」、RFC954、1985年10月。
[RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, October 1985.
[RFC959] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[RFC972] Wancho, F., "Password Generator Protocol", RFC 972,
January 1986.
[RFC972] Wancho、F.、「パスワードジェネレータプロトコル」、RFC972、1986年1月。
[RFC977] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol: A Proposed Standard for the Stream-Based
Transmission of News", RFC 977, February 1986.
[RFC977] カンター、B.、およびP.ラプスリー、「ネットニュースはプロトコルを移します」。 「ニュースのストリームベースの伝達の提案された標準」、RFC977、1986年2月。
[RFC996] Mills, D., "Statistics server", RFC 996, February 1987.
[RFC996] 工場、D.、「統計サーバ」、RFC996、1987年2月。
[RFC998] Clark, D., Lambert, M. and L. Zhang, "NETBLT: A Bulk Data
Transfer Protocol", RFC 998, March 1987.
[RFC998] クラーク、D.、ランバート、M.、およびL.チャン、「NETBLT:」 「バルク・データ転送プロトコル」、RFC998、1987年3月。
[RFC1001] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, End-to-End
Services Task Force. "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Concepts and methods",
STD 19, RFC 1001, March 1987.
ディフェンスにおける[RFC1001]NetBIOS作業部会は研究計画代理店、インターネット活動ボード、終わりから終わりへのサービス特別委員会を進めました。 「TCP/UDP輸送のときにNetBIOSサービスの規格について議定書の中で述べてください」 「概念とメソッド」、STD19、RFC1001、3月1987日
[RFC1002] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, End-to-End
Services Task Force. "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Detailed
specifications.", STD 19, RFC 1002, March 1987.
ディフェンスにおける[RFC1002]NetBIOS作業部会は研究計画代理店、インターネット活動ボード、終わりから終わりへのサービス特別委員会を進めました。 「TCP/UDP輸送のときにNetBIOSサービスの規格について議定書の中で述べてください」 「仕様詳細」、STD19、RFC1002、3月1987日
[RFC1021] Partridge, C. and G. Trewitt, "High-level Entity
Management System HEMS", RFC 1021, October 1987.
[RFC1021] ヤマウズラとC.とG.Trewitt、「ハイレベルの実体管理システムヘリ」、RFC1021、1987年10月。
[RFC1028] Case, J., Davin, J., Fedor, M. and M. Schoffstall, "Simple
Gateway Monitoring Protocol", RFC 1028, November 1987.
[RFC1028] ケースとJ.とデーヴィンとJ.とヒョードルとM.とM.Schoffstall、「簡単なゲートウェイモニターしているプロトコル」、RFC1028、1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC1056] Lambert, M., "PCMAIL: A distributed mail system for
personal computers", RFC 1056, June 1988.
[RFC1056]ランバート、M.、「PCMAIL:」 「パーソナルコンピュータの分配されたメールシステム」、RFC1056、1988年6月。
Bierman, et al. Informational [Page 75] RFC 2896 RMON PI Macros August 2000
Bierman、他 [75ページ]情報のRFC2896RMONパイマクロ2000年8月
[RFC1057] Sun Microsystems, Inc, "RPC: Remote Procedure Call
Protocol Specification version 2", RFC 1057, June 1988.
[RFC1057]サン・マイクロシステムズ、Inc、「RPC:」 リモートProcedure CallプロトコルSpecification、バージョン2インチ、RFC1057、6月1988日
[RFC1064] Crispin, M., "Interactive Mail Access Protocol: Version
2", RFC 1064, July 1988.
[RFC1064] クリスピン、M.、「対話的なメールアクセスは以下について議定書の中で述べます」。 バージョン2インチ、RFC1064、1988年7月。
[RFC1068] DeSchon, A. and R. Braden, "Background File Transfer
Program BFTP", RFC 1068, August 1988.
[RFC1068]DeSchonとA.とR.ブレーデン、「バックグラウンドファイル転送プログラムBFTP」、RFC1068 1988年8月。
[RFC1070] Hagens, R., Hall, N. and M. Rose, "Use of the Internet as
a subnetwork for experimentation with the OSI network
layer", RFC 1070, February 1989.
[RFC1070] HagensとR.とHallとN.とM.ローズ、「サブネットワークとしてのインターネットのOSIネットワーク層がある実験の使用」、RFC1070、1989年2月。
[RFC1078] Lottor, M., "TCP port service Multiplexer TCPMUX", RFC
1078, November, 1988.
M.、「TCPポートサービスMultiplexer TCPMUX」、RFC1078 1988年11月の[RFC1078]Lottor。
[RFC1086] Onions, J. and M. Rose, "ISO-TP0 bridge between TCP and
X.25", RFC 1086, December 1988.
[RFC1086] たまねぎ、J.、およびM.ローズ、「ISO-TP0は1988年12月にTCPとX.25"、RFC1086の間でブリッジします」。
[RFC1095] Warrier, U. and L. Besaw, "Common Management Information
Services and Protocol over TCP/IP (CMOT)", RFC 1095, April
1989.
[RFC1095] WarrierとU.とL.Besaw、「一般的な経営情報は、TCP/IP(CMOT)の上で修理して、議定書を作る」RFC1095、1989年4月。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets", STD
16, RFC 1155, May 1990.
M.とK.McCloghrie、[RFC1155]は上昇して、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1157] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[RFC1203] Rice, J., "Interactive Mail Access Protocol - Version 3",
RFC 1203, February 1991.
[RFC1203] ライス、J.、「バージョン3インチ、RFC1203、1991年対話的なメールアクセス・プロトコル--2月。」
[RFC1204] Lee, D. and S. Yeh, "Message Posting Protocol (MPP)", RFC
1204, February 1991.
[RFC1204]リーとD.とS.イップ、「メッセージの投稿プロトコル(MPP)」、RFC1204 1991年2月。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD
16, RFC 1212, March 1991.
[RFC1212] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, March 1991.
[RFC1213] McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、STD17、RFC1213、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、1991年3月のM.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
Bierman, et al. Informational [Page 76] RFC 2896 RMON PI Macros August 2000
Bierman、他 [76ページ]情報のRFC2896RMONパイマクロ2000年8月
[RFC1226] Kantor, B., "Internet Protocol Encapsulation of AX.25
Frames", RFC 1226, May 1991.
[RFC1226]カンター(B.、「斧.25のフレームのインターネットプロトコルカプセル化」、RFC1226)は1991がそうするかもしれません。
[RFC1227] Rose, M., "SNMP MUX Protocol and MIB", RFC 1227, May 1991.
[RFC1227] ローズと、M.と、「SNMP多重化装置プロトコルとMIB」(RFC1227)は1991がそうするかもしれません。
[RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks",
RFC 1234, June 1991.
[RFC1234] Provan、D.、「IPネットワークを通したトンネリングIPXトラフィック」、RFC1234、1991年6月。
[RFC1235] Ioannidis, J. and G. Maguire, Jr., "The Coherent File
Distribution Protocol", RFC 1235, June 1991.
[RFC1235] IoannidisとJ.とG.マグワイア、Jr.、「コヒーレントファイル分配プロトコル」、RFC1235、1991年6月。
[RFC1241] Mills, D. and R. Woodburn, "A Scheme for an Internet
Encapsulation Protocol: Version 1", RFC 1241, July 1991.
[RFC1241] 工場、D.、およびR.Woodburn、「インターネットカプセル化の体系は議定書を作ります」。 バージョン1インチ、RFC1241、1991年7月。
[RFC1249] Howes, T., Smith, M. and B. Beecher, "DIXIE Protocol
Specification", RFC 1249, August 1991.
[RFC1249] ハウズとT.とスミスとM.とB.ビーチャー、「デキシープロトコル仕様」、RFC1249、1991年8月。
[RFC1267] Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3)", RFC 1267, October 1991.
[RFC1267]ロッキードとK.とY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP-3)」、RFC1267 1991年10月。
[RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991.
B.、"BSD Rlogin"、RFC1282 1991年12月の[RFC1282]カンター。
[RFC1288] Zimmerman, D., "The Finger User Information Protocol", RFC
1288, December 1991.
[RFC1288] ジンマーマン、D.、「指のユーザー情報プロトコル」、RFC1288、1991年12月。
[RFC1301] Amstrong, S., Freier, A. and K. Marzullo, "Multicast
Transport Protocol", RFC 1301, February 1992.
[RFC1301] AmstrongとS.とフライアとA.とK.Marzullo、「マルチキャストトランスポート・プロトコル」、RFC1301、1992年2月。
[RFC1305] Mills, D., "Network Time Protocol (v3)", RFC 1305, April
1992.
[RFC1305] 1992年4月の工場、D.、「ネットワーク時間プロトコル(v3)」RFC1305。
[RFC1312] Nelson, R. and G. Arnold, "Message Send Protocol", RFC
1312, April 1992.
[RFC1312] ネルソンとR.とG.アーノルド、「メッセージはプロトコルを送る」RFC1312、1992年4月。
[RFC1339] Dorner, S. and P. Resnick, "Remote Mail Checking
Protocol", RFC 1339, June 1992.
[RFC1339] デルナーとS.とP.レズニック、「リモートメール照合プロトコル」、RFC1339、1992年6月。
[RFC1350] Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, July
1992.
[RFC1350] Sollins、K.、「TFTPプロトコル(改正2)」、RFC1350、1992年7月。
[RFC1413] St. Johns, M., "Identification Protocol", RFC 1413,
February 1993.
[RFC1413] 聖ジョーンズ、M.、「識別プロトコル」、RFC1413、1993年2月。
[RFC1419] Minshall, G. and M. Ritter, "SNMP over AppleTalk", RFC
1419, March 1993.
[RFC1419]MinshallとG.とM.リッター、「AppleTalkの上のSNMP」、RFC1419、1993年3月。
[RFC1420] Bostock, S., "SNMP over IPX", RFC 1420, March 1993.
[RFC1420]Bostock、1993年3月のS.、「IPXの上のSNMP」RFC1420。
Bierman, et al. Informational [Page 77] RFC 2896 RMON PI Macros August 2000
Bierman、他 [77ページ]情報のRFC2896RMONパイマクロ2000年8月
[RFC1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
John, D., Torrey, D. and B. Alberti, "The Internet Gopher
Protocol (a distributed document search and retrieval
protocol)", RFC 1436, March 1993.
[RFC1436] AnklesariaとF.とMcCahillとM.とリントナーとP.とジョンソンとD.とジョンとD.とトーリーとD.とB.アルベルティ、「インターネットゴーファープロトコル(分配されたドキュメント検索と検索プロトコル)」、RFC1436、1993年3月。
[RFC1459] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol",
RFC 1459, May 1993.
[RFC1459] Oikarinen、J.、およびD.リード(「インターネットリレーチャットプロトコル」、RFC1459)は1993がそうするかもしれません。
[RFC1476] Ullmann, R., "RAP: Internet Route Access Protocol", RFC
1476, June 1993.
[RFC1476] ウルマン、R.は「以下を叩きます」。 「インターネットルートアクセス・プロトコル」、RFC1476、1993年6月。
[RFC1479] Steenstrup, M., "Inter-Domain Policy Routing Protocol
Specification: Version 1", RFC 1479, July 1993.
[RFC1479]ステーンストルプ、M.、「相互ドメイン方針ルート設定は仕様を議定書の中で述べます」。 バージョン1インチ、RFC1479、1993年7月。
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM
Adaptation Layer 5", RFC 1483, July 1993.
[RFC1483] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は1993年7月に5インチ、RFC1483を層にします」。
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
TACACS", RFC 1492, July 1993.
[RFC1492]Finseth、1993年7月のC.、「時々TACACSと呼ばれるアクセス制御プロトコル」RFC1492
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]コールとJ.とB.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[RFC1583]Moy、J.、「OSPF、バージョン2インチ、RFC1583、1994インチ年3月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[RFC1700] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701]ハンクスとS.と李とT.とファリナッチとD.とP.Traina、「一般ルーティングのカプセル化(GRE)」、RFC1701 1994年10月。
[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC 1702,
October 1994.
[RFC1702]ハンクスとS.と李とT.とファリナッチとD.とP.Traina、「IPv4ネットワークの上のジェネリックルート設定Encapsulation」、RFC1702、1994年10月。
[RFC1725] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
RFC 1725, November 1994.
[RFC1725] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、RFC1725、1994年11月。」
[RFC1729] Lynch, C., "Using the Z39.50 Information Retrieval
Protocol in the Internet Environment", RFC 1729, December
1994.
[RFC1729] リンチ、C.、「インターネット環境でZ39.50情報検索プロトコルを使用します」、RFC1729、1994年12月。
[RFC1730] Crispin, M., "Internet Message Access Protocol - Version
4", RFC 1730, December 1994.
[RFC1730] クリスピン、M.、「バージョン4インチ、RFC1730、1994年インターネットメッセージアクセス・プロトコル--12月。」
[RFC1739] Kessler, G. and S. Shepard, "A Primer On Internet and
TCP/IP Tools", RFC 1739, December 1994.
[RFC1739] ケスラーとG.とS.シェパード、「インターネットとTCP/IPツールに関する入門書」、RFC1739、1994年12月。
Bierman, et al. Informational [Page 78] RFC 2896 RMON PI Macros August 2000
Bierman、他 [78ページ]情報のRFC2896RMONパイマクロ2000年8月
[RFC1745] Varadhan, K., Hares, S. and Y. Rekhter, "BGP4/IDRP for
IP---OSPF Interaction", RFC 1745, December 1994.
[RFC1745] VaradhanとK.と野兎とS.とY.Rekhter、「IPのためのBGP4/IDRP」---「OSPF相互作用」、RFC1745、1994年12月。
[RFC1757] Waldbusser, S., "Remote Network Monitoring MIB", RFC 1757,
February 1995.
S.、「リモートネットワーク監視MIB」、RFC1757 1995年2月の[RFC1757]Waldbusser。
[RFC1777] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol", RFC 1777, March 1995.
[RFC1777] YeongとW.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1777、1995年3月。
[RFC1782] Malkin, G. and A. Harkin, "TFTP Option Extension", RFC
1782, March 1995.
[RFC1782] マルキンとG.とA.ハーキン、「TFTPオプション拡張子」、RFC1782、1995年3月。
[RFC1783] Malkin, G. and A. Harkin, "TFTP BlockOption Option", RFC
1783, March 1995.
[RFC1783] マルキンとG.とA.ハーキン、「TFTP BlockOptionオプション」、RFC1783、1995年3月。
[RFC1784] Malkin, G. and A. Harkin, "TFTP Timeout Interval and
Transfer Size Options", RFC 1784, March 1995.
[RFC1784] マルキン、G.、A.ハーキン、および「TFTPタイムアウト間隔と転送サイズオプション」(RFC1784)は1995を行進させます。
[RFC1798] Young, A., "Connection-less Lightweight Directory Access
Protocol", RFC 1798, June 1995.
[RFC1798] ヤング、A.、「コネクションレスなライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1798、1995年6月。
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version
3 Protocol Specification", RFC 1813, June 1995.
[RFC1813] キャラハンとB.とポロウスキーとB.とP.ストーバック、「NFSバージョン3プロトコル仕様」、RFC1813、1995年6月。
[RFC1819] Delgrossi, L. and L. Berger, "Internet Stream Protocol
Version 2 (ST2)", RFC 1819, August 1995.
[RFC1819]DelgrossiとL.とL.バーガー、「インターネットストリームプロトコルバージョン2(ST2)」、RFC1819 1995年8月。
[RFC1831] Srinivasan, R., "Remote Procedure Call Protocol Version
2", RFC 1831, August 1995.
[RFC1831] Srinivasan、R.、「遠隔手続き呼び出しプロトコルバージョン2インチ、RFC1831、1995年8月。」
[RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[RFC1853]シンプソン、1995年10月のW.、「IPトンネリングにおけるIP」RFC1853。
[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"への紹介、RFC1901、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、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのManagement情報の構造」RFC1902(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、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための原文のConventions」、RFC1903、1996年1月。
Bierman, et al. Informational [Page 79] RFC 2896 RMON PI Macros August 2000
Bierman、他 [79ページ]情報のRFC2896RMONパイマクロ2000年8月
[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、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための順応Statements」、RFC1904、1996年1月。
[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)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、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)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。
[RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K. and D.
Zappala, "Source Demand Routing: Packet Format and
Forwarding Specification (Version 1)", RFC 1940, May 1996.
[RFC1940] EstrinとD.と李とT.とRekhterとY.とVaradhanとK.とD.Zappala、「以下を掘るソース要求」 「パケット・フォーマットと推進仕様(バージョン1)」(RFC1940)は1996がそうするかもしれません。
[RFC1945] Berners-Lee, T. and R. Fielding, "Hypertext Transfer
Protocol -- HTTP/1.0", RFC 1945, November 1995.
「ハイパーテキストはプロトコルを移します--HTTP/1インチ、RFC1945、1995年11月。」[RFC1945]バーナーズ・リー、T.、およびR.がさばいて、
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October
1996.
[RFC2002] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2003] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[RFC2021] Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)",
RFC 2021, January 1997.
S.、「リモートネットワーク監視MIB(RMON-2)」、RFC2021 1997年1月の[RFC2021]Waldbusser。
[RFC2037] McCloghrie, K. and A. Bierman, "Entity MIB using SMIv2",
RFC 2037, October 1996.
[RFC2037] McCloghrieとK.とA.Bierman、「1996年10月にSMIv2"、RFC2037を使用する実体MIB。」
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997.
[RFC2068] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月」。
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Luotonen, P.
A. and E. L. Stewart, "An Extension to HTTP: Digest Access
Authentication", RFC 2069, January 1997.
[RFC2069] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、Luotonen、P.A.、およびE.L.スチュワート、「HTTPへの拡大:」 「ダイジェストアクセス認証」、RFC2069、1997年1月。
[RFC2074] Bierman, A. and R. Iddon, "Remote Network Monitoring MIB
Protocol Identifiers", RFC 2074, January 1997.
[RFC2074] BiermanとA.とR.Iddon、「リモートネットワーク監視MIBプロトコル識別子」、RFC2074、1997年1月。
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997.
[RFC2109] クリストルとD.とL.Montulli、「HTTP国家管理メカニズム」、RFC2109、1997年2月。
Bierman, et al. Informational [Page 80] RFC 2896 RMON PI Macros August 2000
Bierman、他 [80ページ]情報のRFC2896RMONパイマクロ2000年8月
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and W. Willens,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2138, April 1997.
[RFC2138]RigneyとC.とルーベンとA.とシンプソン、W.とW.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[RFC2139] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[RFC2139] Rigney、C.、「半径会計」、RFC2139、1997年4月。
[RFC2145] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use
and interpretation of HTTP version numbers", RFC 2145, May
1997.
[RFC2145]ムガール人、J.、Fielding、R.、「HTTPバージョンの使用と解釈は付番する」Gettys J.とH.Frystyk、RFC2145(1997年5月)
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September, 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2233] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB Using SMIv2", RFC 2233, November, 1997.
[RFC2233] McCloghrie、K.、およびF.Kastenholz、「インタフェースは1997年11月にSMIv2"、RFC2233を使用するMIBを分類します」。
[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管理フレームワークについて説明するためのアーキテクチャ」、RFC2271、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)について議定書の中で述べます」、RFC2272、1998年1月。
[RFC2273] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications",
RFC 2273, January 1998.
[RFC2273] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2273、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.
[RFC2274]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2274、1998年1月。
[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)について議定書の中で述べます」、RFC2275、1998年1月。
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N.
Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)", RFC
2332, April 1998.
[RFC2332] Luciani、J.、キャッツ、D.、Piscitello、D.、コール、B.、およびN.Doraswamy、「次のNBMAは解決プロトコル(NHRP)を飛び越します」、RFC2332、1998年4月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
RFC 2408, November 1998.
[RFC2408]MaughanとD.とSchertlerとM.とシュナイダーとM.とJ.ターナー、RFC2408、1998年11月。
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC 2570, April 1999.
[RFC2570]ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメントフレームワークのバージョン3への序論」RFC2570(1999年4月)。
Bierman, et al. Informational [Page 81] RFC 2896 RMON PI Macros August 2000
Bierman、他 [81ページ]情報のRFC2896RMONパイマクロ2000年8月
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 1999.
[RFC2571] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、1999年4月。
[RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen,
"Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", RFC 2572, April 1999.
[RFC2572] ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications",
RFC 2573, April 1999.
[RFC2573] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2573、1999年4月。
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC2574]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年4月。
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2575] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年4月。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2600] Reynolds, J. and R. Braden, "Internet Official Protocol
Standards", STD 1, RFC 2600, March 2000.
[RFC2600] レイノルズとJ.とR.ブレーデン、「インターネット公式プロトコル標準」、STD1、RFC2600、2000年3月。
[RFC2895] Bierman, A., Bucci, C. and R. Iddon, "RMON Protocol
Identifier Reference", RFC 2895, August 2000.
[RFC2895] BiermanとA.とブッチとC.とR.Iddon、「RMONプロトコル識別子参照」、RFC2895、2000年8月。
7. Security Considerations
7. セキュリティ問題
This document contains textual descriptions of well-known networking protocols, not the definition of any networking behavior. As such, no security considerations are raised by its publication.
このドキュメントはどんなネットワークの振舞いの定義ではなく、よく知られるネットワーク・プロトコルの原文の記述も含んでいます。 そういうものとして、セキュリティ問題は全く公表によって提起されません。
Bierman, et al. Informational [Page 82] RFC 2896 RMON PI Macros August 2000
Bierman、他 [82ページ]情報のRFC2896RMONパイマクロ2000年8月
8. Authors' Addresses
8. 作者のアドレス
Andy Bierman Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
カリフォルニア米国 アンディBiermanシスコシステムズInc.170の西タスマン・Driveサンノゼ、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
カリフォルニア米国 クリスブッチシスコシステムズInc.170の西タスマン・Driveサンノゼ、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
ロビンIddon気付3Com株式会社ブラックフライアーズ家40/50のBlackfrias通りエディンバラ、EH1 1NE、イギリス
Phone: +44 131.558.3888 EMail: None
以下に電話をしてください。 +44 131.558 .3888 メール: なし
Bierman, et al. Informational [Page 83] RFC 2896 RMON PI Macros August 2000
Bierman、他 [83ページ]情報のRFC2896RMONパイマクロ2000年8月
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Bierman, et al. Informational [Page 84]
Bierman、他 情報[84ページ]
一覧
スポンサーリンク
