RFC5097 日本語訳
5097 MIB for the UDP-Lite protocol. G. Renker, G. Fairhurst. January 2008. (Format: TXT=48944 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Renker
Request for Comments: 5097 G. Fairhurst
Category: Standards Track University of Aberdeen
January 2008
Renkerがコメントのために要求するワーキンググループG.をネットワークでつないでください: 5097年のG.Fairhurstカテゴリ: 規格は2008年1月にアバディーン大学を追跡します。
MIB for the UDP-Lite Protocol
UDP-LiteプロトコルのためのMIB
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite). It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite. UDP-Lite resembles UDP, but differs from the semantics of UDP by the addition of a single option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram.
このドキュメントはManagement Information基地(MIB)のモジュールをライト級ユーザー・データグラム・プロトコル(UDP-Lite)に指定します。 それは、UDP-Liteを配備するトランスポート層終点のふるまいと性能を特徴付けるために1セットの新しいMIB物を定義します。 UDP-LiteはUDPに類似していますが、ただ一つのオプションの添加でUDPの意味論と異なっています。 これは可変長のデータチェックサム適用範囲に能力を加えます。(それは、データグラムを捨てることに優先して(部分的に)崩壊したデータグラムペイロードデータの配送を好むアプリケーションのクラスのためになることができます)。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Relationship to the UDP-MIB ................................2
1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB .........4
1.3. Interpretation of the MIB Variables ........................5
1.4. Conventions ................................................8
2. The Internet-Standard Management Framework ......................8
3. Definitions .....................................................8
4. Security Considerations ........................................19
5. IANA Considerations ............................................20
6. Acknowledgments ................................................20
7. References .....................................................20
7.1. Normative References ......................................20
7.2. Informative References ....................................21
1. 序論…2 1.1. UDP-MIBとの関係…2 1.2. ホストリソースMIBとSYSAPPL-MIBとの関係…4 1.3. MIB変数の解釈…5 1.4. コンベンション…8 2. インターネット標準の管理枠組み…8 3. 定義…8 4. セキュリティ問題…19 5. IANA問題…20 6. 承認…20 7. 参照…20 7.1. 標準の参照…20 7.2. 有益な参照…21
Renker & Fairhurst Standards Track [Page 1] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[1ページ]RFC5097MIBは2008年1月に議定書を作ります。
1. Introduction
1. 序論
The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] (also known as UDPLite) is an IETF standards-track transport protocol. The operation of UDP-Lite is similar to the User Datagram Protocol (UDP) [RFC768], but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. This is achieved by changing the semantics of the UDP Length field to that of a Checksum Coverage field. If this feature is not used, UDP-Lite is semantically identical to UDP.
ライト級ユーザー・データグラム・プロトコル(UDP-Lite)[RFC3828](また、UDPLiteとして、知られている)はIETF標準化過程トランスポート・プロトコルです。 UDP-Liteの操作は、ユーザー・データグラム・プロトコル(UDP)[RFC768]と同様ですが、また、誤り傾向があるネットワーク環境における捨てるよりむしろ届けられたペイロードを部分的に破損したのを好むアプリケーションに役立つことができます。 これは、UDP Length分野の意味論をChecksum Coverage分野のものに変えることによって、達成されます。 この特徴が使用されていないなら、UDP-LiteはUDPと意味的に同じです。
The interface of UDP-Lite differs from that of UDP by the addition of a single option, which communicates a length value. At the sender this specifies the intended datagram checksum coverage; at the receiver it signifies a minimum coverage threshold for incoming datagrams. This length value may also be modified during the lifetime of a connection. UDP-Lite does not provide mechanisms to negotiate the checksum coverage between the sender and receiver. Where required, this needs to be communicated by another protocol. The Datagram Congestion Control Protocol (DCCP) [RFC4340] for instance includes a capability to negotiate checksum coverage values.
UDP-Liteのインタフェースはただ一つのオプションの添加でUDPのものと異なっています。(オプションは長さの値を伝えます)。 送付者では、これは意図しているデータグラムチェックサム適用範囲を指定します。 受信機では、それは受信データグラムのための最小の適用範囲敷居を意味します。また、この長さの値は接続の生涯変更されるかもしれません。 UDP-Liteは、送付者と受信機の間のチェックサム適用範囲を交渉するためにメカニズムを前提としません。必要であるところでは、これは、別のプロトコルでコミュニケートされる必要があります。 例えば、データグラムCongestion Controlプロトコル(DCCP)[RFC4340]はチェックサム適用範囲値を交渉する能力を含んでいます。
This document defines a set of runtime statistics (variables) that facilitate network management/monitoring as well as unified comparisons between different protocol implementations and operating environments. To provide a common interface for users and implementors of UDP-Lite modules, the definitions of these runtime statistics are provided as a MIB module using the SMIv2 format [RFC2578].
このドキュメントは異なったプロトコル実現と操作環境でのネットワークマネージメント/モニターしていて統一された比較を容易にする1セットのランタイム統計(変数)を定義します。 UDP-Liteモジュールのユーザと作成者に一般的なインタフェースを提供するために、MIBモジュールとしてSMIv2形式[RFC2578]を使用することでこれらのランタイム統計の定義を提供します。
1.1. Relationship to the UDP-MIB
1.1. UDP-MIBとの関係
The similarities between UDP and UDP-Lite suggest that the MIB module for UDP-Lite should resemble that of UDP [RFC4113], with extensions corresponding to the additional capabilities of UDP-Lite. The UDP- Lite MIB module is placed beneath the mib-2 subtree, adhering to the familiar structure of the UDP-MIB module to ease integration.
UDPとUDP-Liteの間の類似性は、UDP-LiteのためのMIBモジュールがUDP[RFC4113]のものに類似するべきであると示唆します、UDP-Liteの追加能力に対応する拡大で。 UDP- Lite MIBモジュールはmib-2下位木の下に置かれます、統合を緩和するためにUDP-MIBモジュールの身近な構造を固く守って。
In particular, these well-known basic counters are supported:
特に、これらの周知の基本的なカウンタは支持されます:
o InDatagrams
o InDatagrams
o NoPorts
o NoPorts
o InErrors
o InErrors
o OutDatagrams
o OutDatagrams
Renker & Fairhurst Standards Track [Page 2] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[2ページ]RFC5097MIBは2008年1月に議定書を作ります。
The following read-only variables have been added to the basic structure used in the UDP-MIB module:
UDP-MIBモジュールで使用される基本構造に以下の書き込み禁止変数を追加してあります:
InPartialCov: The number of received datagrams, with a valid
format and checksum, whose checksum coverage is strictly less than
the datagram length.
InPartialCov: 有効な形式とチェックサムがある容認されたデータグラムの数。(チェックサムのチェックサム適用範囲はデータグラムの長さより厳密に少ないです)。
InBadChecksum: The number of received datagrams with an invalid
checksum (i.e., where the receiver-recalculated UDP-Lite checksum
does not match that in the Checksum field). Unlike NoPorts, this
error type also counts as InErrors.
InBadChecksum: 無効のチェックサム(すなわち、受信機-recalculated UDP-LiteチェックサムはChecksum分野でそこでそれに合っていない)がある容認されたデータグラムの数。 また、NoPortsと異なって、この誤りタイプはInErrorsにみなします。
OutPartialCov: The number of sent datagrams with a valid format
and checksum whose checksum coverage is strictly less than the
datagram length.
OutPartialCov: 有効な形式とチェックサム適用範囲がデータグラムの長さより厳密に少ないチェックサムがある送られたデータグラムの数。
All non-error counters used in this document are 64-bit counters. This is a departure from UDP, which traditionally used 32-bit counters and mandates 64-bit counters only on fast networks [RFC4113]. This choice is justified by the fact that UDP-Lite is a more recent protocol, and that network speeds continue to grow.
本書では使用されるすべての非誤りカウンタが64ビットのカウンタです。 これはUDPからの出発です。(UDPは32ビットのカウンタを伝統的に使用して、速いネットワーク[RFC4113]だけの64ビットのカウンタを強制します)。 この選択はUDP-Liteが、より最近のプロトコルであり、ネットワーク速度が、成長し続けているという事実によって正当化されます。
Another difference from the UDP MIB module is that the UDP-Lite MIB module does not support an IPv4-only listener table. This feature was present only for compatibility reasons and is superseded by the more informative endpoint table. Two columnar objects have been added to this table:
UDP MIBモジュールからの別の違いはUDP-Lite MIBモジュールがIPv4だけリスナーテーブルを支えないということです。 この特徴は、単に互換性理由で存在していて、より有益な終点テーブルによって取って代わられます。 2個の円柱状の物がこのテーブルに加えられます:
udpliteEndpointMinCoverage: The minimum acceptable receiver
checksum coverage length [RFC3828]. This value may be manipulated
by the application attached to the receiving endpoint.
udpliteEndpointMinCoverage: 最小の許容できる受信機チェックサム適用範囲の長さ[RFC3828]。 この値は受信終点に取り付けられたアプリケーションで操られるかもしれません。
udpliteEndpointViolCoverage: This object is optional and counts
the number of valid datagrams with a checksum coverage value less
than the corresponding value of udpliteEndpointMinCoverage.
Although being otherwise valid, such datagrams are discarded
rather than passed to the application. This object thus serves to
separate cases of violated coverage from other InErrors.
udpliteEndpointViolCoverage: この物は、任意であり、udpliteEndpointMinCoverageの換算値ほどチェックサム適用範囲価値がある有効なデータグラムの数を数えません。 そうでなければ、有効ですが、データグラムはむしろアプリケーションに通過されるのと同じくらい捨てられます。 その結果、この物は、他のInErrorsから違反された適用範囲に関するケースを分離するのに役立ちます。
The second entry is not required to manage the transport protocol and hence is not mandatory. It may be implemented to assist in debugging application design and configuration.
2番目のエントリーは、トランスポート・プロトコルを管理するのが必要でなく、またしたがって、義務的ではありません。 それは、アプリケーション設計と構成をデバッグするのを助けるために実行されるかもしれません。
The UDP-Lite MIB module also provides a discontinuity object to help determine whether one or more of its counters experienced a discontinuity event. This is an event, other than re-initialising the management system, that invalidates the management entity's understanding of the counter values.
また、UDP-Lite MIBモジュールは、カウンタのより多くのひとりが不連続出来事を経験したかどうか決定するのを助けるために不連続物を提供します。 マネージメントシステムを再初期化するのを除いて、これは経営体の対価の理解を無効にする出来事です。
Renker & Fairhurst Standards Track [Page 3] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[3ページ]RFC5097MIBは2008年1月に議定書を作ります。
For example, if UDP-Lite is implemented as a loadable operating system module, a module load or unload would produce a discontinuity. By querying the value of udpliteStatsDiscontinuityTime, a management entity can determine whether or not a discontinuity event has occurred.
例えば、UDP-Liteが「負荷-可能」オペレーティングシステムモジュールとして実行されるなら、モジュール負荷かアンロードが不連続を生産するでしょう。 udpliteStatsDiscontinuityTimeの値について質問することによって、経営体は、不連続出来事が起こったかどうか決定できます。
1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB
1.2. ホストリソースMIBとSYSAPPL-MIBとの関係
The UDP-Lite endpoint table contains one columnar object, udpliteEndpointProcess, reporting a unique value that identifies a distinct piece of software associated with this endpoint. (When more than one piece of software is associated with this endpoint, a representative is chosen, so that consecutive queries consistently refer to the same identifier. The reported value is then consistent, as long as the representative piece of software is running and still associated with the endpoint.)
UDP-Lite終点テーブルは1個の円柱状の物を含んでいます、udpliteEndpointProcess、異なったソフトウェア一本を特定するユニークな値がこの終点に関連していると報告して。 (1つ以上のソフトウェア一本がこの終点に関連しているとき、代表は選ばれています、連続した質問が一貫して同じ識別子を示すように。 次に、報告された値は一貫しています、代表しているソフトウェア一本が走って、まだ終点に関連づけられている限り。)
The value of udpliteEndpointProcess is reported as an Unsigned32, and it shares with the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] and the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287] the requirement that, wherever possible, this should be the native and unique identification number employed by the system.
udpliteEndpointProcessの値はUnsigned32として報告されます、そして、それはHOST-RESOURCES-MIBのhrSWRunIndex[RFC2790]とSYSAPPL-MIBのsysApplElmtRunIndex[RFC2287]とこれがどこでも、可能であるところでは、システムによって使われたネイティブの、そして、ユニークな識別番号であるという要件を共有します。
If the SYSAPPL-MIB module is available, the value of udpliteEndpointProcess should correspond to the appropriate value of sysApplElmtRunIndex. If not available, an alternative should be used (e.g., the hrSWRunIndex of the HOST-RESOURCES-MIB module).
SYSAPPL-MIBモジュールが利用可能であるなら、udpliteEndpointProcessの値はsysApplElmtRunIndexの適切な値に対応するべきです。 そうでなければ、利用可能であることで、代替手段は使用されるべきです(例えば、HOST-RESOURCES-MIBモジュールのhrSWRunIndex)。
Renker & Fairhurst Standards Track [Page 4] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[4ページ]RFC5097MIBは2008年1月に議定書を作ります。
1.3. Interpretation of the MIB Variables
1.3. MIB変数の解釈
Figure 1 shows an informal survey of the packet processing path, with reference to counter names in parentheses.
図1は括弧のカウンタ名に関してパケットプロセシング・パスの非公式の調査を示しています。
Received UDP-Lite Datagrams
|
| +- Full Coverage ---------------------+-> Deliver
| | |
+- Valid Header--+ +- >= Rec. Coverage --+
| (InDatagrams) | |
| +- Partial -----+
| (InPartialCov) |
| +- < Rec. Coverage --+
| (EndpointViolCoverage) |
| |
| |
+- Header Error ---+ |
| | |
+- Checksum Error -+-----------------------------------+-> Discard
| (InBadChecksum) (InErrors)
|
+- Port Error -------------------------------------------> Discard
(NoPorts)
容認されたUDP-Liteデータグラム| | +完全適用範囲---------------------+->は配送されます。| | | +有効なヘッダー--+ +>=Rec。 適用範囲--+| (InDatagrams) | | | +部分的です。-----+ | (InPartialCov) | | +<Rec。 適用範囲--+| (EndpointViolCoverage) | | | | | +ヘッダー誤り---+ | | | | +チェックサム誤り-+-----------------------------------+->破棄| (InBadChecksum) (InErrors) | +ポート誤り------------------------------------------->破棄(NoPorts)
Figure 1: UDP-Lite Input Processing Path
図1: UDP-Lite入力プロセシング・パス
A platform-independent test of the UDP-Lite implementations in two connected end hosts may be performed as follows.
2人の接続終わりのホストでのUDP-Lite実現のプラットホームから独立しているテストは以下の通り実行されるかもしれません。
On the sending side, OutDatagrams and OutPartialCov are observed. The ratio OutPartialCov/OutDatagrams describes the fraction (between 0 and 1) of datagrams using partial checksum coverage.
送付側では、OutDatagramsとOutPartialCovが観測されます。 比率OutPartialCov/OutDatagramsは、部分的なチェックサム適用範囲を使用することでデータグラムの部分(0〜1)について説明します。
On the receiving side, InDatagrams, InPartialCov, and InErrors are monitored. If datagrams are received from the given sender, InErrors is close to zero, and InPartialCov is zero, no partial coverage is employed. If no datagrams are received and InErrors increases proportionally with the sending rate, a configuration error is likely (a wrong value of receiver minimum checksum coverage).
受信側では、InDatagrams、InPartialCov、およびInErrorsがモニターされます。 与えられた送付者からデータグラムを受け取って、ゼロの近くにInErrorsがあって、InPartialCovがゼロであるなら、どんな部分的な適用範囲も採用していません。 どんなデータグラムも受け取られていないで、送付レートに従ってInErrorsが比例して増加するなら、構成誤りはありそうです(受信機の最小のチェックサム適用範囲の間違った値)。
The InBadChecksum counter reflects errors that may persist following end-host processing, router processing, or link processing (this includes illegal coverage values as defined in [RFC3828], since checksum and checksum coverage are mutually interdependent). In particular, InBadChecksum can serve as an indicator of the residual
終わりホスト・プロセッシング、ルータ処理、またはリンク処理に続いて、InBadChecksumカウンタは持続するかもしれない誤りを反映します(これが[RFC3828]で定義されるように不法な適用範囲値を含んでいます、チェックサムとチェックサム適用範囲が互いに互いに依存しているので)。 特に、InBadChecksumは残差のインディケータとして機能できます。
Renker & Fairhurst Standards Track [Page 5] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[5ページ]RFC5097MIBは2008年1月に議定書を作ります。
link bit error rate: on links with higher bit error rates, a lower value of the checksum coverage may help to reduce the values of both InErrors and InBadChecksum. By observing these values and adapting the configuration, a setting may then be found that is more adapted to the specific type of link, and the type of payload. In particular, a reduction in the number of discarded datagrams (InErrors), may indicate an improved performance.
ビット誤り率をリンクしてください: より高いビット誤り率とのリンクの上では、チェックサム適用範囲の下側の値は、InErrorsとInBadChecksumの両方の値を減少させるのを助けるかもしれません。 これらの値を観測して、構成を適合させることによって、次に、設定は見つけられたかもしれなくて、すなわち、以上はリンクの特定のタイプ、およびペイロードのタイプに順応しました。 特に捨てられたデータグラム(InErrors)の数の減少は向上した性能を示すかもしれません。
The above statistics are elementary and can be used to derive the following information:
上の統計は、基本であり、以下の情報を引き出すのに使用できます:
o The total number of incoming datagrams is InDatagrams + InErrors +
NoPorts.
o 受信データグラムの総数はInDatagrams+InErrors+NoPortsです。
o The number of InErrors that were discarded due to problems other
than a bad checksum is InErrors - InBadChecksum.
o 悪いチェックサム以外の問題のため捨てられたInErrorsの数はInErrorsです--InBadChecksum。
o The number of InDatagrams that have full coverage is InDatagrams -
InPartialCov.
o 完全適用範囲を持っているInDatagramsの数はInDatagramsです--InPartialCov。
o The number of OutDatagrams that have full coverage is OutDatagrams
- OutPartialCov.
o 完全適用範囲を持っているOutDatagramsの数はOutDatagramsです--OutPartialCov。
Renker & Fairhurst Standards Track [Page 6] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[6ページ]RFC5097MIBは2008年1月に議定書を作ります。
The following Case diagram [CASE] summarises the relationships between the counters on the input processing path.
以下のCaseダイヤグラム[CASE]は入力プロセシング・パスのカウンタの間の関係について略言します。
Transport Layer Interface
-------------------------------------------------------------
/\
||
----------------------------- InDatagrams
|| ^
|| |
|| |
||----------------------> InPartialCov
|| |
|| |
|| v
|| EndpointViolCoverage
|| |
NoPorts <--------|| |
|| |
||------> InBadChecksum ------>|
|| |
|| |
|| v
||------------------------> InErrors
||
||
-------------------------------------------------------------
Network Layer Interface
トランスポート層インタフェース------------------------------------------------------------- /\ || ----------------------------- InDatagrams|| ^ || | || | ||---------------------->InPartialCov|| | || | || v|| EndpointViolCoverage|| | NoPorts<。--------|| | || | ||------>InBadChecksum------>| || | || | || v||------------------------>InErrors|| || ------------------------------------------------------------- ネットワーク層インタフェース
Figure 2: Counters for Received UDP-Lite Datagrams
図2: 容認されたUDP-Liteデータグラムのためのカウンタ
A configuration error may occur when a sender chooses a coverage value for the datagrams that it sends that is less than the minimum coverage configured by the intended recipient. The minimum coverage is set on a per-session basis by the application associated with the listening endpoint, and its current value is recorded in the udpliteEndpointTable. Reception of valid datagrams with a checksum coverage value less than this threshold results in dropping the datagram [RFC3828] and incrementing InErrors. To improve debugging of such (misconfigured) cases, an implementer may choose to support the optional udpliteEndpointViolCoverage entry in the endpoint table (Section 1.1) that specifically counts datagrams falling in this category. Without this feature, failure due to misconfiguration can not be distinguished from datagram processing failure.
送付者がそれが送るデータグラムのための意図している受取人によって構成された最小の適用範囲以下である適用範囲値を選ぶと、構成誤りは発生するかもしれません。 最小の適用範囲は聴取終点に関連しているアプリケーションによる1セッションあたり1個のベースに設定されます、そして、現行価値はudpliteEndpointTableに記録されます。 チェックサム適用範囲価値がこの敷居より少ない有効なデータグラムのレセプションはデータグラム[RFC3828]を落として、増加しているInErrorsをもたらします。 そのような(misconfiguredしました)場合のデバッグを改良するために、implementerは、明確にこのカテゴリで落ちるデータグラムを数える終点テーブル(セクション1.1)で任意のudpliteEndpointViolCoverageエントリーを支持するのを選ぶかもしれません。 この特徴がなければ、データグラム処理の故障とmisconfigurationによる失敗を区別できません。
Renker & Fairhurst Standards Track [Page 7] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[7ページ]RFC5097MIBは2008年1月に議定書を作ります。
1.4. Conventions
1.4. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. The Internet-Standard Management Framework
2. インターネット標準の管理枠組み
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概観について、RFC3410[RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 一般に、MIB物はSimple Network Managementプロトコル(SNMP)を通してアクセスされます。 MIBの物は、Management情報(SMI)のStructureで定義されたメカニズムを使用することで定義されます。 このメモはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[RFC2580]で説明されるSMIv2に対応であるMIBモジュールを指定します。
3. Definitions
3. 定義
UDPLITE-MIB DEFINITIONS ::= BEGIN
UDPLITE-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
mib-2, Unsigned32,
Counter32, Counter64 FROM SNMPv2-SMI -- [RFC2578]
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、mib-2、Unsigned32、Counter32、Counter64 FROM SNMPv2-SMI--[RFC2578]
TimeStamp FROM SNMPv2-TC -- [RFC2579]
SNMPv2-Tcからのタイムスタンプ--[RFC2579]
MODULE-COMPLIANCE,
OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580]
SNMPv2-CONFからのモジュールコンプライアンス、物グループ--[RFC2580]
InetAddress,
InetAddressType,
InetPortNumber FROM INET-ADDRESS-MIB; -- [RFC4001]
INETアドレスMIBからのInetAddress、InetAddressType、InetPortNumber。 -- [RFC4001]
udpliteMIB MODULE-IDENTITY
LAST-UPDATED "200712180000Z" -- 18 December 2007
ORGANIZATION "IETF TSV Working Group (TSVWG)"
CONTACT-INFO
"IETF TSV Working Group
http://www.ietf.org/html.charters/tsvwg-charter.html
Mailing List: tsvwg@ietf.org
udpliteMIBモジュールアイデンティティは"200712180000Z"をアップデートしました--2007年12月18日の組織「IETF TSV作業部会(TSVWG)」、コンタクトインフォメーション、「IETF TSVワーキンググループ http://www.ietf.org/html.charters/tsvwg-charter.html メーリングリスト:」 tsvwg@ietf.org
Renker & Fairhurst Standards Track [Page 8] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[8ページ]RFC5097MIBは2008年1月に議定書を作ります。
Gerrit Renker, Godred Fairhurst
Electronics Research Group
School of Engineering, University of Aberdeen
Fraser Noble Building, Aberdeen AB24 3UE, UK"
DESCRIPTION
"The MIB module for managing UDP-Lite implementations.
Copyright (C) The IETF Trust (2008). This version of
this MIB module is part of RFC 5097; see the RFC
itself for full legal notices."
「ゲリットRenker、Godred Fairhurst Electronics Research Group工学部、アバディーン大学フレーザNoble Building、アバディーンAB24 3UE、イギリス」記述、「UDP-Lite実現を管理するためのMIBモジュール。」 IETFが信じる著作権(C)(2008)。 このMIBモジュールのこのバージョンはRFC5097の一部です。 「完全な法定の通知に関してRFC自身を見てください。」
REVISION "200712180000Z" -- 18 December 2007
DESCRIPTION
"Initial SMIv2 revision, based on the format of the UDP
MIB module (RFC 4113) and published as RFC 5097."
::= { mib-2 170 }
REVISION"200712180000Z"--2007年12月18日の記述は「UDP MIBモジュール(RFC4113)の形式に基づいていて、RFC5097として発行されたSMIv2改正に頭文字をつけます」。 ::= mib-2 170
udplite OBJECT IDENTIFIER ::= { udpliteMIB 1 }
udplite OBJECT IDENTIFIER:、:= udpliteMIB1
udpliteInDatagrams OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of UDP-Lite datagrams that were
delivered to UDP-Lite users.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 1 }
udpliteInDatagrams OBJECT-TYPE--UDP-MIB SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述における「UDP-Liteユーザに届けられたUDP-Liteデータグラムの総数」として。 「このカウンタの値における不連続はマネージメントシステムの再初期化処理においてudpliteStatsDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= udplite1
udpliteInPartialCov OBJECT-TYPE -- new in UDP-Lite
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of UDP-Lite datagrams that were
delivered to UDP-Lite users (applications) and whose
checksum coverage was strictly less than the datagram
length.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 2 }
udpliteInPartialCov OBJECT-TYPE--UDP-Lite SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述では、新しく、「UDP-Liteユーザ(アプリケーション)とチェックサム適用範囲に届けられたUDP-Liteデータグラムの総数はデータグラムの長さより厳密に少なかったです」。 「このカウンタの値における不連続はマネージメントシステムの再初期化処理においてudpliteStatsDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= udplite2
Renker & Fairhurst Standards Track [Page 9] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[9ページ]RFC5097MIBは2008年1月に議定書を作ります。
udpliteNoPorts OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of received UDP-Lite datagrams for
which there was no listener at the destination port.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 3 }
udpliteNoPorts OBJECT-TYPE--UDP-MIB SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述における「リスナーが全く仕向港にいなかった容認されたUDP-Liteデータグラムの総数」として。 「このカウンタの値における不連続はマネージメントシステムの再初期化処理においてudpliteStatsDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= udplite3
udpliteInErrors OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received UDP-Lite datagrams that could not
be delivered for reasons other than the lack of an
application at the destination port.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 4 }
udpliteInErrors OBJECT-TYPE--UDP-MIB SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述のように、「アプリケーションの不足を除いて、それを渡すことができなかった容認されたUDP-Liteデータグラムの数は仕向港で推論します」。 「このカウンタの値における不連続はマネージメントシステムの再初期化処理においてudpliteStatsDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= udplite4
udpliteInBadChecksum OBJECT-TYPE -- new in UDP-Lite
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received UDP-Lite datagrams whose checksum
could not be validated. This includes illegal checksum
coverage values, as their use would lead to incorrect
checksums.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
REFERENCE "RFC 3828, section 3.1"
::= { udplite 5 }
udpliteInBadChecksum OBJECT-TYPE、新しさ、UDP-Lite SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述における「チェックサムを有効にすることができなかった容認されたUDP-Liteデータグラムの数。」 これは不法なチェックサム適用範囲値を含んでいます、彼らの使用が不正確なチェックサムにつながるだろうというとき。「このカウンタの値における不連続はマネージメントシステムの再初期化処理においてudpliteStatsDiscontinuityTimeの値によって示される他の時に起こることができます。」 REFERENCE、「RFC3828、以下を何3.1インチも区分してください」= udplite5
udpliteOutDatagrams OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
udpliteOutDatagrams OBJECT-TYPE、UDP-MIB SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
Renker & Fairhurst Standards Track [Page 10] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[10ページ]RFC5097MIBは2008年1月に議定書を作ります。
"The total number of UDP-Lite datagrams sent from this
entity.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 6 }
「UDP-Liteデータグラムの総数はこの実体から発信しました。」 「このカウンタの値における不連続はマネージメントシステムの再初期化処理においてudpliteStatsDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= udplite6
udpliteOutPartialCov OBJECT-TYPE -- new in UDP-Lite
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of udpliteOutDatagrams whose
checksum coverage was strictly less than the
datagram length.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 7 }
udpliteOutPartialCov OBJECT-TYPE、新しさ、UDP-Lite SYNTAX Counter64のマックス-ACCESSの読書だけのSTATUSの現在の記述における「チェックサム適用範囲がデータグラムの長さより厳密に少なかったudpliteOutDatagramsの総数。」 「このカウンタの値における不連続はマネージメントシステムの再初期化処理においてudpliteStatsDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= udplite7
udpliteEndpointTable OBJECT-TYPE
SYNTAX SEQUENCE OF UdpLiteEndpointEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing information about this entity's
UDP-Lite endpoints on which a local application is
currently accepting or sending datagrams.
「局所塗布が現在、受け入れるか、またはデータグラムを送るこの実体のUDP-Lite終点の情報を含んでいて、Aはテーブルの上に置く」udpliteEndpointTable OBJECT-TYPEのSYNTAX SEQUENCE OF UdpLiteEndpointEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
The address type in this table represents the address
type used for the communication, irrespective of the
higher-layer abstraction. For example, an application
using IPv6 'sockets' to communicate via IPv4 between
::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use
InetAddressType ipv4(1).
このテーブルのアドレスタイプは、より高い層の抽象化の如何にかかわらずコミュニケーションに使用されるアドレスタイプの代理をします。 例えば、IPv4を通って以下の間に交信するのにIPv6'ソケット'を使用するアプリケーション:そして、ffff: 10.0 .0、.1、:、:ffff: 10.0 .0 .2はInetAddressType ipv4(1)を使用するでしょう。
Like the udpTable in RFC 4113, this table also allows
the representation of an application that completely
specifies both local and remote addresses and ports. A
listening application is represented in three possible
ways:
また、RFC4113のudpTableのように、このテーブルは地方の、そして、リモートなアドレスとポートの両方を完全に指定するアプリケーションの表現を許容します。 聴取アプリケーションは3つの可能な方法で表されます:
1) An application that is willing to accept both IPv4
and IPv6 datagrams is represented by a
udpliteEndpointLocalAddressType of unknown(0) and a
udpliteEndpointLocalAddress of ''h (a zero-length
1) それがIPv4とIPv6データグラムの両方を受け入れるのが未知(0)のudpliteEndpointLocalAddressTypeとudpliteEndpointLocalAddressによって表されることを望んでいるアプリケーション、「h、(ゼロ・レングス、」
Renker & Fairhurst Standards Track [Page 11] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[11ページ]RFC5097MIBは2008年1月に議定書を作ります。
octet-string).
八重奏ストリング)
2) An application that is willing to accept only IPv4
or only IPv6 datagrams is represented by a
udpliteEndpointLocalAddressType of the appropriate
address type and a udpliteEndpointLocalAddress of
'0.0.0.0' or '::' respectively.
2) 'IPv4だけかIPv6データグラムだけを受け入れても構わないと思っているアプリケーションが適切なアドレスタイプのudpliteEndpointLocalAddressTypeと'0.0のudpliteEndpointLocalAddressによって表される、.0、.0、'、'、:、:'それぞれ'。
3) An application that is listening for datagrams only
for a specific IP address but from any remote
system is represented by a
udpliteEndpointLocalAddressType of the appropriate
address type, with udpliteEndpointLocalAddress
specifying the local address.
3) 特定のIPのためだけにアドレスにもかかわらず、どんなリモートシステムからもデータグラムの聞こうとしているアプリケーションは適切なアドレスタイプのudpliteEndpointLocalAddressTypeによって表されます、udpliteEndpointLocalAddressがローカルアドレスを指定していて。
In all cases where the remote address is a wildcard,
the udpliteEndpointRemoteAddressType is unknown(0),
the udpliteEndpointRemoteAddress is ''h (a zero-length
octet-string), and the udpliteEndpointRemotePort is 0.
h(ゼロ・レングス八重奏ストリング)、およびudpliteEndpointRemotePortはそうです。リモートアドレスがワイルドカードである、udpliteEndpointRemoteAddressTypeが未知(0)であるすべての場合では、udpliteEndpointRemoteAddressがそうである、「0インチ。
If the operating system is demultiplexing UDP-Lite
packets by remote address/port, or if the application
has 'connected' the socket specifying a default remote
address/port, the udpliteEndpointRemote* values should
be used to reflect this."
::= { udplite 8 }
「オペレーティングシステムが遠く離れたアドレス/ポートのそばの逆多重化UDP-Liteパケットである、またはアプリケーションが遠く離れたアドレス/ポート、udpliteEndpointRemote*がこれを反映するのに使用されるべきであるのを評価するデフォルトを指定するソケットを'接続した'なら。」 ::= udplite8
udpliteEndpointEntry OBJECT-TYPE
SYNTAX UdpLiteEndpointEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular current UDP-Lite endpoint.
Implementers need to pay attention to the sizes of
udpliteEndpointLocalAddress/RemoteAddress, as Object
Identifiers (OIDs) of column instances in this table must
have no more than 128 sub-identifiers in order to remain
accessible with SNMPv1, SNMPv2c, and SNMPv3."
INDEX { udpliteEndpointLocalAddressType,
udpliteEndpointLocalAddress,
udpliteEndpointLocalPort,
udpliteEndpointRemoteAddressType,
udpliteEndpointRemoteAddress,
udpliteEndpointRemotePort,
udpliteEndpointInstance }
::= { udpliteEndpointTable 1 }
udpliteEndpointEntry OBJECT-TYPE SYNTAX UdpLiteEndpointEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定の現在のUDP-Lite終点に関する情報。」 「Implementersは、udpliteEndpointLocalAddress/RemoteAddressのサイズに注意を向ける必要があります、このテーブルのコラムインスタンスのObject Identifiers(OIDs)に128未満のサブ識別子がSNMPv1、SNMPv2c、およびSNMPv3と共にアクセスしやすいままで残るためになければならないとき。」 udpliteEndpointLocalAddressType、udpliteEndpointLocalAddress、udpliteEndpointLocalPort、udpliteEndpointRemoteAddressType、udpliteEndpointRemoteAddress、udpliteEndpointRemotePort、udpliteEndpointInstanceに索引をつけてください:、:= udpliteEndpointTable1
UdpLiteEndpointEntry ::= SEQUENCE {
UdpLiteEndpointEntry:、:= 系列
Renker & Fairhurst Standards Track [Page 12] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[12ページ]RFC5097MIBは2008年1月に議定書を作ります。
udpliteEndpointLocalAddressType InetAddressType,
udpliteEndpointLocalAddress InetAddress,
udpliteEndpointLocalPort InetPortNumber,
udpliteEndpointRemoteAddressType InetAddressType,
udpliteEndpointRemoteAddress InetAddress,
udpliteEndpointRemotePort InetPortNumber,
udpliteEndpointInstance Unsigned32,
udpliteEndpointProcess Unsigned32,
udpliteEndpointMinCoverage Unsigned32,
udpliteEndpointViolCoverage Counter32
}
udpliteEndpointLocalAddressType InetAddressType、udpliteEndpointLocalAddress InetAddress、udpliteEndpointLocalPort InetPortNumber、udpliteEndpointRemoteAddressType InetAddressType、udpliteEndpointRemoteAddress InetAddress、udpliteEndpointRemotePort InetPortNumber、udpliteEndpointInstance Unsigned32、udpliteEndpointProcess Unsigned32、udpliteEndpointMinCoverage Unsigned32、udpliteEndpointViolCoverage Counter32
udpliteEndpointLocalAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address type of udpliteEndpointLocalAddress. Only
IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or
unknown(0) if datagrams for all local IP addresses are
accepted."
::= { udpliteEndpointEntry 1 }
udpliteEndpointLocalAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「udpliteEndpointLocalAddressのアドレスタイプ。」 「すべてのローカルアイピーアドレスのためのデータグラムを受け入れるなら、IPv4、IPv4z、IPv6、および唯一のIPv6zアドレスは予想されたか、または未知の(0)です。」 ::= udpliteEndpointEntry1
udpliteEndpointLocalAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The local IP address for this UDP-Lite endpoint.
「ローカルアイピーはこのUDP-Lite終点に扱う」udpliteEndpointLocalAddress OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
The value of this object can be represented in three
possible ways, depending on the characteristics of the
listening application:
聴取アプリケーションの特性によって、3つの可能な方法でこのオブジェクトの値を表すことができます:
1. For an application that is willing to accept both
IPv4 and IPv6 datagrams, the value of this object
must be ''h (a zero-length octet-string), with
the value of the corresponding instance of the
EndpointLocalAddressType object being unknown(0).
1. IPv4とIPv6データグラムの両方を受け入れても構わないと思っているアプリケーションのために、このオブジェクトの値は「未知(0)であるEndpointLocalAddressTypeオブジェクトの対応するインスタンスの値のh(ゼロ・レングス八重奏ストリング)」でなければなりません。
2. For an application that is willing to accept only
IPv4 or only IPv6 datagrams, the value of this
object must be '0.0.0.0' or '::', respectively,
while the corresponding instance of the
EndpointLocalAddressType object represents the
appropriate address type.
2. 'アプリケーションにおいて、それが、'0.0が.0であったに違いないならこのオブジェクトのIPv4だけかIPv6データグラム、値だけを受け入れても構わないと思っている、.0、'、'、:、:'EndpointLocalAddressTypeオブジェクトの対応するインスタンスが適切なアドレスを表している間、それぞれ、タイプしてください'。
3. For an application that is listening for data
3. データの聞こうとしているアプリケーションのために
Renker & Fairhurst Standards Track [Page 13] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[13ページ]RFC5097MIBは2008年1月に議定書を作ります。
destined only to a specific IP address, the value
of this object is the specific IP address for
which this node is receiving packets, with the
corresponding instance of the
EndpointLocalAddressType object representing the
appropriate address type.
特定のIPアドレスだけに運命づけられています、このオブジェクトの値はこのノードがパケットを受けている特定のIPアドレスです、EndpointLocalAddressTypeオブジェクトの対応するインスタンスが適切なアドレスタイプの代理をしていて。
As this object is used in the index for the
udpliteEndpointTable, implementors should be careful
not to create entries that would result in OIDs with
more than 128 sub-identifiers; this is because of SNMP
and SMI limitations."
::= { udpliteEndpointEntry 2 }
このオブジェクトがudpliteEndpointTableにインデックスで使用されるので、作成者は128以上がサブ識別子でOIDsをもたらすエントリーを作成しないように慎重であるはずです。 「SNMPとSMI制限のためにこれはそうです。」 ::= udpliteEndpointEntry2
udpliteEndpointLocalPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The local port number for this UDP-Lite endpoint."
::= { udpliteEndpointEntry 3 }
udpliteEndpointLocalPort OBJECT-TYPE SYNTAX InetPortNumberのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このUDP-Lite終点への地方のポートナンバー。」 ::= udpliteEndpointEntry3
udpliteEndpointRemoteAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address type of udpliteEndpointRemoteAddress. Only
IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or
unknown(0) if datagrams for all remote IP addresses are
accepted. Also, note that some combinations of
udpliteEndpointLocalAdressType and
udpliteEndpointRemoteAddressType are not supported. In
particular, if the value of this object is not
unknown(0), it is expected to always refer to the
same IP version as udpliteEndpointLocalAddressType."
::= { udpliteEndpointEntry 4 }
udpliteEndpointRemoteAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「udpliteEndpointRemoteAddressのアドレスタイプ。」 すべてのリモートIPアドレスのためのデータグラムを受け入れるなら、IPv4、IPv4z、IPv6、および唯一のIPv6zアドレスは予想されたか、または未知の(0)です。 また、udpliteEndpointLocalAdressTypeとudpliteEndpointRemoteAddressTypeのいくつかの組み合わせがサポートされないことに注意してください。 「特に、このオブジェクトの値が未知(0)でないなら、いつもudpliteEndpointLocalAddressTypeと同じIPバージョンを示すと予想されます。」 ::= udpliteEndpointEntry4
udpliteEndpointRemoteAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The remote IP address for this UDP-Lite endpoint. If
datagrams from any remote system are to be accepted,
this value is ''h (a zero-length octet-string).
Otherwise, it has the type described by
udpliteEndpointRemoteAddressType and is the address of
「リモートIPはこのUDP-Lite終点に扱う」udpliteEndpointRemoteAddress OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 どんなリモートシステムからのデータグラムも受け入れるつもりであるなら、この値は「h(ゼロ・レングス八重奏ストリング)」です。 さもなければ、それは、udpliteEndpointRemoteAddressTypeによって説明されたタイプがあって、演説です。
Renker & Fairhurst Standards Track [Page 14] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[14ページ]RFC5097MIBは2008年1月に議定書を作ります。
the remote system from which datagrams are to be
accepted (or to which all datagrams will be sent).
どのデータグラムが受け入れられることになっていたらよいかからのリモートシステム(または、すべてのデータグラムが送られる)。
As this object is used in the index for the
udpliteEndpointTable, implementors should be careful
not to create entries that would result in OIDs with
more than 128 sub-identifiers; this is because of SNMP
and SMI limitations."
::= { udpliteEndpointEntry 5 }
このオブジェクトがudpliteEndpointTableにインデックスで使用されるので、作成者は128以上がサブ識別子でOIDsをもたらすエントリーを作成しないように慎重であるはずです。 「SNMPとSMI制限のためにこれはそうです。」 ::= udpliteEndpointEntry5
udpliteEndpointRemotePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The remote port number for this UDP-Lite endpoint. If
datagrams from any remote system are to be accepted,
this value is zero."
::= { udpliteEndpointEntry 6 }
udpliteEndpointRemotePort OBJECT-TYPE SYNTAX InetPortNumberのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このUDP-Lite終点へのリモートポートナンバー。」 「どんなリモートシステムからのデータグラムも受け入れるつもりであるなら、この値はゼロです。」 ::= udpliteEndpointEntry6
udpliteEndpointInstance OBJECT-TYPE
SYNTAX Unsigned32 (1..'ffffffff'h)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The instance of this tuple. This object is used to
distinguish among multiple processes 'connected' to
the same UDP-Lite endpoint. For example, on a system
implementing the BSD sockets interface, this would be
used to support the SO_REUSEADDR and SO_REUSEPORT
socket options."
::= { udpliteEndpointEntry 7 }
udpliteEndpointInstance OBJECT-TYPE SYNTAX Unsigned32、(1 'ffffffff'h) 「このインスタンスはtupleする」マックス-ACCESSのアクセスしやすくないSTATUS現在の記述'。 このオブジェクトは、同じUDP-Lite終点に'接続された'複数のプロセスの中で区別するのに使用されます。 「例えば、BSDソケットインタフェースを実装するシステムの上では、これはSO_REUSEADDRとSO_REUSEPORTがソケットオプションであるとサポートするのに使用されるでしょう。」 ::= udpliteEndpointEntry7
udpliteEndpointProcess OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique value corresponding to a piece of software
running on this endpoint.
udpliteEndpointProcess OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この終点で走るソフトウェア一本に対応するユニークな値。」
If this endpoint is associated with more than one piece
of software, the agent should choose one of these. As
long as the representative piece of software
is running and still associated with the endpoint,
subsequent reads will consistently return the same
value. The implementation may use any algorithm
satisfying these constraints (e.g., choosing the entity
この終点が1つ以上のソフトウェア一本に関連しているなら、エージェントはこれらの1つを選ぶべきです。 代表しているソフトウェア一本が稼働していて、まだ終点に関連づけられている限り、その後の読書は一貫して同じ値を返すでしょう。 実装がこれらの規制を満たしながらどんなアルゴリズムも使用するかもしれない、(例えば、実体を選ぶこと。
Renker & Fairhurst Standards Track [Page 15] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[15ページ]RFC5097MIBは2008年1月に議定書を作ります。
with the oldest start time).
最も古い開始時刻)
This identifier is platform-specific. Wherever possible,
it should use the system's native, unique identification
number as the value.
この識別子はプラットホーム特有です。 どこでも、可能であるところでは、それが値としてシステムのネイティブの、そして、ユニークな識別番号を使用するべきです。
If the SYSAPPL-MIB module is available, the value should
be the same as sysApplElmtRunIndex. If not available, an
alternative should be used (e.g., the hrSWRunIndex of the
HOST-RESOURCES-MIB module).
SYSAPPL-MIBモジュールが利用可能であるなら、値はsysApplElmtRunIndexと同じであるべきです。 そうでなければ、利用可能であることで、代替手段は使用されるべきです(例えば、HOST-RESOURCES-MIBモジュールのhrSWRunIndex)。
If it is not possible to uniquely identify the pieces of
software associated with this endpoint, then the value
zero should be used. (Note that zero is otherwise a
valid value for sysApplElmtRunIndex.)"
::= { udpliteEndpointEntry 8 }
唯一この終点に関連しているソフトウェアの断片を特定するのが可能でないなら、値ゼロは使用されるべきです。 (そうでなければ、ゼロがsysApplElmtRunIndexのための有効値であることに注意してください。)" ::= udpliteEndpointEntry8
udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum checksum coverage expected by this endpoint.
A value of 0 indicates that only fully covered datagrams
are accepted."
REFERENCE "RFC 3828, section 3.1"
::= { udpliteEndpointEntry 9 }
udpliteEndpointMinCoverage OBJECT-TYPE--「最小のチェックサム適用範囲はこの終点のそばで予想した」UDP-Lite SYNTAX Unsigned32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述では、新しいです。 「0の値は、完全にカバーされたデータグラムだけが受け入れられるのを示します。」 REFERENCE、「RFC3828、以下を何3.1インチも区分してください」= udpliteEndpointEntry9
udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of datagrams received by this endpoint whose
checksum coverage violated the minimum coverage threshold
set for this connection (i.e., all valid datagrams whose
checksum coverage was strictly smaller than the minimum,
as defined in RFC 3828).
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udpliteEndpointEntry 10 }
udpliteEndpointViolCoverage OBJECT-TYPE--「データグラムの数はチェックサム適用範囲がこの接続(チェックサム適用範囲がRFC3828で定義されるように最小限より厳密に小さかったすなわちすべての有効なデータグラム)のために最小の適用範囲敷居セットに違反したこの終点のそばで受けた」UDP-Lite SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述で新しいか、または任意です。 「このカウンタの値における不連続はマネージメントシステムの再初期化処理においてudpliteStatsDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= udpliteEndpointEntry10
Renker & Fairhurst Standards Track [Page 16] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[16ページ]RFC5097MIBは2008年1月に議定書を作ります。
udpliteStatsDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the most recent occasion at
which one or more of the UDP-Lite counters suffered a
discontinuity.
A value of zero indicates no such discontinuity has
occurred since the last re-initialisation of the local
management subsystem."
::= { udplite 9 }
udpliteStatsDiscontinuityTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「UDP-Liteの1つ以上が反対する最新の時のsysUpTimeの値は不連続を受けました」。 「ゼロの値は、現地管理職者サブシステムの最後の再初期化処理以来どんなそのような不連続も起こっていないのを示します。」 ::= udplite9
-- Conformance Information
-- 順応情報
udpliteMIBConformance OBJECT IDENTIFIER ::= { udpliteMIB 2 }
udpliteMIBConformanceオブジェクト識別子:、:= udpliteMIB2
udpliteMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for systems that implement
UDP-Lite.
udpliteMIBCompliance MODULE-COMPLIANCE STATUSの現在の記述、「UDP-Liteを実装するシステムのための承諾声明。」
There are a number of INDEX objects that cannot be
represented in the form of OBJECT clauses in SMIv2,
but for which we have the following compliance
requirements, expressed in OBJECT clause form in this
description clause:
SMIv2の私たちがこの記述節のOBJECT節フォームで言い表された以下の承諾要件を持っている、OBJECT節の形に表すことができない多くのINDEXオブジェクトがあります:
-- OBJECT udpliteEndpointLocalAddressType
-- SYNTAX InetAddressType { unknown(0), ipv4(1),
-- ipv6(2), ipv4z(3),
-- ipv6z(4) }
-- DESCRIPTION
-- Support for dns(16) is not required.
-- OBJECT udpliteEndpointLocalAddress
-- SYNTAX InetAddress (SIZE(0|4|8|16|20))
-- DESCRIPTION
-- Support is only required for zero-length
-- octet-strings, and for scoped and unscoped
-- IPv4 and IPv6 addresses.
-- OBJECT udpliteEndpointRemoteAddressType
-- SYNTAX InetAddressType { unknown(0), ipv4(1),
-- ipv6(2), ipv4z(3),
-- ipv6z(4) }
-- DESCRIPTION
-- Support for dns(16) is not required.
-- OBJECT udpliteEndpointRemoteAddress
-- OBJECT udpliteEndpointLocalAddressType--未知(0)、ipv4(1)--ipv6(2)、ipv4z(3)--ipv6z(4)(記述)がdns(16)のためにサポートするSYNTAX InetAddressTypeは必要ではありません。 -- そして、OBJECT udpliteEndpointLocalAddress--、SYNTAX InetAddress、(SIZE、(8|16|20、0|4|)、--記述--サポートが八重奏ゼロ・レングス--ストリングに必要であるだけである、見られて、「非-見」られる、--IPv4とIPv6アドレス。 -- OBJECT udpliteEndpointRemoteAddressType--未知(0)、ipv4(1)--ipv6(2)、ipv4z(3)--ipv6z(4)(記述)がdns(16)のためにサポートするSYNTAX InetAddressTypeは必要ではありません。 -- オブジェクトudpliteEndpointRemoteAddress
Renker & Fairhurst Standards Track [Page 17] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[17ページ]RFC5097MIBは2008年1月に議定書を作ります。
-- SYNTAX InetAddress (SIZE(0|4|8|16|20))
-- DESCRIPTION
-- Support is only required for zero-length
-- octet-strings, and for scoped and unscoped
-- IPv4 and IPv6 addresses.
"
MODULE -- this module
MANDATORY-GROUPS { udpliteBaseGroup,
udplitePartialCsumGroup,
udpliteEndpointGroup }
GROUP udpliteAppGroup
DESCRIPTION
"This group is optional and provides supplementary
information about the effectiveness of using minimum
checksum coverage thresholds on endpoints."
::= { udpliteMIBConformance 1 }
-- そして、SYNTAX InetAddress、(SIZE、(8|16|20、0|4|)、--記述--サポートが八重奏ゼロ・レングス--ストリングに必要であるだけである、見られて、「非-見」られる、--IPv4とIPv6アドレス。 「MODULE--、このモジュールMANDATORY-GROUPS、udpliteBaseGroup、udplitePartialCsumGroup、udpliteEndpointGroup、GROUP udpliteAppGroup記述、「このグループは、任意であり、終点で最小のチェックサム適用範囲敷居を使用する有効性に関する補助情報を提供する」、」 ::= udpliteMIBConformance1
udpliteMIBGroups OBJECT IDENTIFIER ::= { udpliteMIBConformance 2 }
udpliteMIBGroupsオブジェクト識別子:、:= udpliteMIBConformance2
udpliteBaseGroup OBJECT-GROUP -- as in UDP
OBJECTS { udpliteInDatagrams, udpliteNoPorts, udpliteInErrors,
udpliteOutDatagrams, udpliteStatsDiscontinuityTime }
STATUS current
DESCRIPTION
"The group of objects providing for counters of
basic UDP-like statistics."
::= { udpliteMIBGroups 1 }
udpliteBaseGroup OBJECT-GROUP、UDP OBJECTS、udpliteInDatagrams、udpliteNoPorts、udpliteInErrors、udpliteOutDatagrams、udpliteStatsDiscontinuityTime、STATUSの現在の記述、「基本的なUDPのような統計のカウンタに備えるオブジェクトのグループ。」 ::= udpliteMIBGroups1
udplitePartialCsumGroup OBJECT-GROUP -- specific to UDP-Lite
OBJECTS { udpliteInPartialCov,
udpliteInBadChecksum,
udpliteOutPartialCov }
STATUS current
DESCRIPTION
"The group of objects providing for counters of
transport layer statistics exclusive to UDP-Lite."
::= { udpliteMIBGroups 2 }
UDP-Lite OBJECTSに特定のudplitePartialCsumGroup OBJECT-GROUP、udpliteInPartialCov、udpliteInBadChecksum、udpliteOutPartialCov、STATUSの現在の記述、「輸送のカウンタに備えるオブジェクトのグループはUDP-Liteに限っている統計を層にします」。 ::= udpliteMIBGroups2
udpliteEndpointGroup OBJECT-GROUP
OBJECTS { udpliteEndpointProcess, udpliteEndpointMinCoverage }
STATUS current
DESCRIPTION
"The group of objects providing for the IP version
independent management of UDP-Lite 'endpoints'."
::= { udpliteMIBGroups 3 }
udpliteEndpointGroup OBJECT-GROUP OBJECTS、udpliteEndpointProcess、udpliteEndpointMinCoverage、STATUSの現在の記述、「UDP-Lite'終点'のIPのバージョンの独立している管理に備えるオブジェクトのグループ。」 ::= udpliteMIBGroups3
Renker & Fairhurst Standards Track [Page 18] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[18ページ]RFC5097MIBは2008年1月に議定書を作ります。
udpliteAppGroup OBJECT-GROUP
OBJECTS { udpliteEndpointViolCoverage }
STATUS current
DESCRIPTION
"The group of objects that provide application-level
information for the configuration management of
UDP-Lite 'endpoints'."
::= { udpliteMIBGroups 4 }
udpliteAppGroup OBJECT-GROUP OBJECTS udpliteEndpointViolCoverage、STATUSの現在の記述、「UDP-Lite'終点'の構成管理のためのアプリケーションレベル情報を提供するオブジェクトのグループ。」 ::= udpliteMIBGroups4
END
終わり
4. Security Considerations
4. セキュリティ問題
There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations.
それがマックス-ACCESS節を持っているこのMIBモジュールで定義された管理オブジェクトが全くありません。読書して書く、そして/または、読書して作成します。 それで、このMIBモジュールが正しく実装されるなら、侵入者が変更できる危険が全くないか、またはダイレクトSNMP SET操作でこのMIBモジュールのあらゆる管理オブジェクトを作成してください。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
このMIBモジュール(すなわち、アクセスしやすくないのを除いたマックス-ACCESSがあるオブジェクト)によるいくつかの読み込み可能なオブジェクトがいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 SNMPを通してネットワークの上にそれらを送るとき、その結果、GET、そして/または、これらのオブジェクトへのNOTIFYアクセスさえ制御して、ことによるとこれらのオブジェクトの値を暗号化するのさえ重要です。 これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です:
The indices of the udpliteEndpointTable contain information about the listeners on an entity. In particular, the udpliteEndpointLocalPort index objects can be used to identify ports that are open on the machine and which attacks are likely to succeed, without the attacker having to run a port scanner. The table also identifies the currently listening UDP-Lite ports.
udpliteEndpointTableのインデックスリストは実体のリスナーの情報を含んでいます。 特に、攻撃がマシンで開いて、引き継ぎそうであるポートを特定するのにudpliteEndpointLocalPortインデックスオブジェクトを使用できます、ポートスキャナを動かさなければならない攻撃者なしで。 また、テーブルは現在聴いているUDP-Liteポートを特定します。
The udpliteEndpointMinCoverage provides information about the requirements of the transport service associated with a specific UDP-Lite port. This provides additional detail concerning the type of application associated with the port at the receiver.
udpliteEndpointMinCoverageは特定のUDP-Liteポートに関連している輸送サービスの要件の情報を提供します。 これは受信機のポートに関連しているアプリケーションのタイプに関して追加詳細を明らかにします。
Since UDP-Lite permits the delivery of (partially) corrupted data to an end host, the counters defined in this MIB module may be used to infer information about the characteristics of the end-to-end path over which the datagrams are communicated. This information could be used to infer the type of application associated with the port at the receiver.
UDP-Liteが(部分的に)崩壊したデータの配送を終わりのホストに可能にするので、このMIBモジュールで定義されたカウンタは終わりから端へのデータグラムが伝えられる経路の特性の情報を推論するのに使用されるかもしれません。 受信機のポートに関連しているアプリケーションのタイプを推論するのにこの情報を使用できました。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec),
SNMPv3の前のSNMPバージョンは十分な安全性を含んでいませんでした。 ネットワーク自体が安全であっても(例えば、IPsecを使用するのによる)
Renker & Fairhurst Standards Track [Page 19] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[19ページ]RFC5097MIBは2008年1月に議定書を作ります。
even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが安全なネットワークにこのMIBモジュールでだれに許容されているかに関してコントロールが全くありません。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see RFC 3410 [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは(RFC3410[RFC3410]を見てください、セクション8)、RECOMMENDEDです、SNMPv3の暗号のメカニズム(認証とプライバシーのための)の全面的な支援を含んでいて。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
さらに、SNMPv3の前のSNMPバージョンの展開はNOT RECOMMENDEDです。 代わりに、それはSNMPv3を配布して、暗号のセキュリティを可能にするRECOMMENDEDです。 そして、このMIBモジュールのインスタンスへのアクセスを与えるSNMP実体が本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
5. IANA Considerations
5. IANA問題
The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
MIBモジュールは本書ではSMI民数記登録に記録された以下のIANAによって割り当てられたOBJECT IDENTIFIER値を使用します:
+------------+-------------------------+
| Descriptor | OBJECT IDENTIFIER value |
+------------+-------------------------+
| udpliteMIB | { mib-2 170 } |
+------------+-------------------------+
+------------+-------------------------+ | 記述子| OBJECT IDENTIFIER値| +------------+-------------------------+ | udpliteMIB| mib-2 170| +------------+-------------------------+
6. Acknowledgments
6. 承認
The design of the MIB module presented in this document owes much to the format of the module presented in [RFC4113].
本書では提示されたMIBモジュールのデザインは[RFC4113]に提示されたモジュールの形式から多くを借りています。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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月の原文のコンベンション。」
Renker & Fairhurst Standards Track [Page 20] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[20ページ]RFC5097MIBは2008年1月に議定書を作ります。
[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月のための順応声明。」
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon、L-A.、デーゲルマルク、M.、ピンク、S.、イェンソン、L-E.、およびG.Fairhurst、「軽量のユーザー・データグラム・プロトコル(UDP-Lite)」、RFC3828 2004年7月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
7.2. Informative References
7.2. 有益な参照
[CASE] Case, J. and C. Partridge, "Case Diagrams: A First Step to
Diagrammed Management Information Bases", ACM Computer
Communications Review, 19(1):13-16, January 1989.
[ケース]ケース、J.、およびC.ヤマウズラ、「ダイヤグラムをケースに入れてください」 「図解された管理情報ベースへの第一歩」、ACMコンピュータコミュニケーションレビュー、19(1): 13-16と、1989年1月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level
Managed Objects for Applications", RFC 2287, February
1998.
[RFC2287]KrupczakとC.とJ.Saperia、「アプリケーションのためのシステムレベル管理オブジェクトの定義」、RFC2287、1998年2月。
[RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC
2790, March 2000.
2000年の[RFC2790]WaldbusserとS.とP.グリロ、「ホストリソースMIB」(RFC2790)行進。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3410] ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」、RFC3410(2002年12月)。
[RFC4113] Fenner, B. and J. Flick, "Management Information Base for
the User Datagram Protocol (UDP)", RFC 4113, June 2005.
[RFC4113] フェナーとB.とJ.軽打、「ユーザー・データグラム・プロトコル(UDP)のための管理情報ベース」、RFC4113、2005年6月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。
Renker & Fairhurst Standards Track [Page 21] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[21ページ]RFC5097MIBは2008年1月に議定書を作ります。
Authors' Addresses
作者のアドレス
Gerrit Renker University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland
アバディーン工学部フレーザ・素晴らしい建築物アバディーンAB24 3UEスコットランドのゲリットRenker大学
EMail: gerrit@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk
メール: gerrit@erg.abdn.ac.uk ユリ: http://www.erg.abdn.ac.uk
Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland
アバディーン工学部フレーザ・素晴らしい建築物アバディーンAB24 3UEスコットランドのGodred Fairhurst大学
EMail: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk
メール: gorry@erg.abdn.ac.uk ユリ: http://www.erg.abdn.ac.uk
Renker & Fairhurst Standards Track [Page 22] RFC 5097 MIB for the UDP-Lite Protocol January 2008
UDP-LiteのためのRenker&Fairhurst標準化過程[22ページ]RFC5097MIBは2008年1月に議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Renker & Fairhurst Standards Track [Page 23]
Renker&Fairhurst標準化過程[23ページ]
一覧
スポンサーリンク
